Our company keeps debating on whether we should be using custom API DLLs or creating a web service farm to have our programs to communicate data between themselves. To me web services make the most sense in regards to compatibility and flexibility of upgrading, but I have heard some good reasons to use DLLs as well.
Is there an emerging preference for .NET applications, or a choice that you have found that works best? And if so, why?
Thanks!
We use a mixture of things, mostly depending on where they get deployed, who is the "customer" and who are the "threats." We mostly use webservices for things that desktop applications touch, but for the parts of the server-based application that need to talk to each other, we use remoting (because that doesn't get routed past the load balancers, while a webservice would be visible to everyone).
DLLs or assemblies by themselves do not resolve the communication issue between programs. However, when building assemblies in the past, what I have done is utilize a shared memory space, which the custom dll uses to access shared objects across applications. I've done this for applications that have an accompanied Outlook add-in and it has been quite successful.
The pros to that approach is that it will be faster than using the web services route.
However, I think this really boils down to your situation, because I could see using multiple venues for different circumstances.
Shared Memory/Web Services/Remoting/WCF, just to name a few.
All .net/MS shops usually do process communications with web services since microsoft makes that relatively easy.
The only problem I've found with it in practice is we once had a production failure due to a limit on the size of a passed message. It defaulted to a megabyte and a very large serialized object failed to fit in that space. It used serialization to text instead of binary.
In our setup it was all internal for an SOA architecture and we didn't have to worry about threats.
For our application, we chose a mix. We use web services to go across the internet to allow for load balancing and 3rd party development but use tcpchannel remoting to allow for fast communication between servers. It depends upon the issue.
There's pros & cons of each - if you'll always be running .net apps then you could arguably get better performance from the dll approach. Remoting can work well too.
For greater long term flexibility that will allow you to easily integrate with other platforms & internal/external clients should the need arise you could look at building RESTful web service APIs to your applications.
In some circumstances I've worked at places that did intra-app communication in the data tier via some well crafted stored procedures which worked perfectly in that scenario.
I always consider the tools that best fit the task at hand rather than trying to fit in with any specific trends, however, if your doing anything that could involve external client interaction I'd definitely look at whether there are published communications standards already in place that you can pick up - there's a lot of standards out there that you can employ to aid interoperability within your industry.
If the processes are one separate machines, your choices are mainly web services/WCF, .NET remoting or a direct TCP/IP connection. If the processes are on the same machine you have those choices and more, including shared memory and the filesystem. .NET remoting deserves a close look if you don't need to interop with any other technologies - it doesn't need codegen to do its work and so is simpler with decent performance.
I guess I would say WCF. The reasons are manifold:
In the old days, remoting was da-bomb because web services couldn't really do stuff like Security etc, without having to know WS-*, which was daunting. Not true now with WCF. Yes there is a learning curve that comes with it, but you'd be learning something that can transfer to any other Microsoft shop.
Just make sure you read up on the right way to do WCF. For example, seperate all of your messaging stuff into it's own seperate DLL.
WCF really is the way to go here--write the service, let configuration decide the transport medium.
In terms of picking transport mediums, alot of really has to do with your network architecture and requirements. Http is great for remote stuff and getting through firewalls but bloody inefficient whereas Tcp can be fast but unreliable.
As most of the other posters have pointed out, it's difficult to provide advice without some more specifics.
If your requirements allow for asynchronous messaging, you might want to consider using System.Messaging in conjunction with Message Queue as a third option.