dotnet distributed apps: Communication between Web Services, Windows Services and Remoting -- dotnet distributed apps

Communication between Web Services, Windows Services and Remoting

johannblake NO[at]SPAM yahoo.com
3/26/2004 7:07:26 AM

dotnet distributed apps: I have an XML web service that can be customized by customers. The
goal is this...

A process must run *somewhere* that acts as an interface between the
web service and some foreign system. Whatever that foreign system is
doesn't matter. It can be anything. The process could run on the same
server where the web service is located or it could be located
somewhere on the Internet including the customer's own machine.

The process must always be running. The process must implement an
interface that is defined by us (the developers of the web service).
This is because various customers around the world will implement the
interface differently, but they must all use the same interface to
interact with the web service.

So these processes might come from us or they might come from
customers. They might be installed locally or they might be running on
a remote machine on the Internet.

The web service can call the process or the process can call the web
service. Either end can initiate the communication.

So the question is, what would be the best solution to implement this
scenario? The best I can come up with is to have the processes
designed as a Windows service. The web service would communicate with
the Windows service via Remoting. But this only works for .NET. Some
customers might be using Linux for all I know and for all I care.

So if Remoting is thrown out, that only leaves an XML web service
interface or possibly a TCP socket interface. TCP sockets however are
ugly since they require proprietary messaging schemes built into them.

The problem with XML web services is that if the processes run on the
same machine as the web service, you are probably looking at a large
overhead just to transport data between process boundaries.

Any other suggestions?

Thanks for your insight,
Johann Blake

CloserWorlds
www.closerworlds.com

GPS tracking for vehicle, people, cell phones over GSM, GPRS. Uses an
XML web service, supports various mapping software including MapPoint
and OziExplorer, is hardware independent, supports data in multiple
languages and can be adapted by programmers. Uses SQL Server. Built

Re: Communication between Web Services, Windows Services and Remoting

Paul Glavich [MVP - ASP.NET]
3/28/2004 5:41:03 PM

I think web services would be one of the few choices. If your systems could
potentially be "anything" (ie. Linux, window etc...) then you need some form
of universal protocol and web services are an obvious choice.

<quote>
The problem with XML web services is that if the processes run on the
same machine as the web service, you are probably looking at a large
overhead just to transport data between process boundaries.
</quote>

There will be overhead but not as much as you would think, and it will work.
There are many more efficient methods but they usually boil down to
platform/technology specific choices (eg. remoting for .Net, sockets, other
forms of RPC for each platform/technology). IMHO, you can save yourself some
pain by going the web services route.

- Paul Glavich.
Microsoft ASP.NET MVP

[quoted text, click to view]