J
Johann Blake
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
entirely in C#.
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
entirely in C#.