Steve Jones wrote: > So is the issue with performance actually performance of SOAP, or is it > that people aren't good at building distributed applications. > > NB to the REST people out there, don't snigger around this as the chatty > nature of REST is liable to create equally large problems against the > weight of SOAP.
I think it should be fairly obvious that "slow" on a network is almost always related to "latency" of transfer/transport between systems. There are a couple of issues to consider, for me. One is connection setup time for a transfer/transport operation. Many HTTP based systems will experience this latency on every remote operation unless some very specific features of HTTP are configured/available. The other is what coding/decoding is needed which represents overhead in the exchange between remote systems. The JERI stack in Jini provides for endpoint reuse so that a single endpoint can handle multiple, exported service instances. This can allow optimization of connection setup for clients using multiple services resident in the same JVM instance (the ServiceStarter framework makes this easy). Thus, a single connection is opened, and then multiple services are available through a single connection. This can help conserve certain resources. But, it also focuses execution of multi-threading through a single resource which implies synchronization which can inject unneeded latency. I.e. one large tranfer can block several small transfers until it completes because they are all going across a single connection. The amount of data transported becomes a big issue as does any processing required on either end where a CODEC of some sort (XML, IIOP etc.) is in place. The fact that the Jini platforms standards allow for varied endpoints means that you could put in an endpoint and invocation layer which required a CODEC. The default implementation that is widely used, passes native Java types through the Java Serialization mechanism. In many cases, you can optimize Serialization using platform specfic features which remain portable to all Java enabled OSes/Hardware. WS, REST and IIOP, because they lack mobile code (as a foundation, there is some mobile code possible in custom use of these technologies for transport instead of transfer), require you to make changes on the client and server to optimize latency. With mobile code in the typical use of Jini, you can exploit mobile code to change and optimize the transfer/transport layer so that evolving client usage can be optimized more readily without external infrastructure development in many cases. For extreme bandwidth needs, you might have to use some the data warehousing and transport services which will distribute copies of your data around the planet and then provide a DNS based redirection to the closest (network wise) location. Gregg Wonderly
