Re: RMI vs. Sockets vs. ?
jawadhashmi@gmail.com wrote:
As far as I know only sockets and RMI are available for distributed
programming. RMI is easier than socket programming, but socket
programming gives more control.
RMI will provides the opertunity to talk with another Java
application. But sockets can help to connect with application written
in any language and listening on the specific port.
Soap is another option to do just like RMI. And is cross platform like
sockets.
SOAP is slower then plain sockets.
"Plain" sockets still require a formatted message of /some/ type to be of any
use. Neglecting for a microsecond the labor cost of creating the apps, by the
time you compare the parsing, error-handling and related tasks for a custom
message infrastructure against a SOAP-based one with, say Apache and Sun
tools, you may find that message sizes are not quite so different, and
processing costs closer still. Nevertheless, typical custom message formats
do tend to be more compact than SOAP-based standard ones, albeit at a cost of
complexity and fragility, not to say inflexibility. Plu
Arguably the real cost of a system is human time, both to develop an
application and to use it effectively in production. Use of standards
libraries naturally reduce the development cost. A key factor of SOAP-based
infrastructures is the division of labor between the architect, who devises
the distributed API and concomitant WSDLs, and the app developer (possibly the
same person wearing a different hat), who creates implementations of the API
virtually automatically with standard tools. I've seen in practice how widely
disparate programming shops, comprising both .Net and J2EE cultures, could
develop web-service clients extremely quickly from the WSDL, much faster than
I have seen with any kind of custom infrastructure.
In maintenance and production the text format of XML messages makes
troubleshooting ridiculously easier than with binary formats. If the
architect did their job right, the tags tell a story that helps the
maintainer. WSDL is an example of "literate programming" - it encodes all
kinds of documentary information about the interfaces in human-readable form
that is present in the runtime messages.
The next question is how you measure "slower". Undoubtedly SOAP messages
would require more bytes than "equivalent" custom-format compact messages; I'd
be dubious of claims that there are significant differences in "speed" once a
message reaches its destination. However, the SOAP message contains much more
information than more compact representations. If you measure some unit of
information (noons?) you might find that SOAP messages transmit more
information per unit time than other formats.
The real-world decision of what to use would consider arbitrary, tangential
measures of message "speed" far, far down the list, particularly absent
evidence of significant performance impact.
--
Lew