You can add socket-based communication (TCP/UDP) to the list, as well as
message queuing.
One way to choose the "appropriat e" mechanism is to look at the platform(s)
both applications will be running on (both .NET CLR, .NET and Java, etc.),
and the bandwidth that will be available (both in memory on the same
machine, LAN, Internet, WAN, etc.). These two facets will narrow down your
choices. For instance, if both applications are .NET apps running on the
same computer or your LAN, most literature will say Remoting or Web Services
are your best bet (Remoting being the more performant). If the applications
are connected on different platforms where a firewall might sit between
them, exposing the applications via web services becomes the best strategy.
Plain vanilla sockets might be your best bet if both applications are
connected by a very low bandwidth pipe, as SOAP messages can be much larger
than a binary or character-based protocol you develop for your needs.
Hope this helps.
--
Jeffrey Wynn
so********@nosp am.net
"Vince Apesa" <va****@hotmail .com> wrote in message
news:a8******** *************** ***@posting.goo gle.com...
"Sput" <sp********@pos t.htnet.hr> wrote in message
news:<bv******* ***@ls219.htnet .hr>...
Is there a simple way of communication between applications
I would need to send or receive some data from time to time?
you may want to consider creating a web-service on each end to
communicate. although not as fast as remoting ...
Vince
