Seems to me the only reason to go to SOAP would be if your clients can no longer use RMI for some reason - firewalls maybe?
Originally posted by Scott DiNucci:
I am working on a project to add additional functionality to an existing client-side Java application. The client was built using RMI to call EJBs. The new functionality will be built using WSAD 4.0.3 and deployed on a WAS 4.0.1 server. We are being asked to look at using SOAP instead of RMI. Using SOAP, can the client application call the EJBs directly or will a servlet need to be written? The reason I ask is the EJBs are written to the 1.1 specification since WAS 4.0.x does not support the 2.0 specification. Will we use JAXM or JAX RPC? Are these supported by the version of WSAD and WAS we are using. Does SOAP provide a clear reason for moving away from RMI? If anyone can point me to a good source of information or example as it relates to our environment, it would be appreciated.
Read the documentation on Web Services that comes with WebSphere Studio 4.03. Also, read the "Web Services Wizardry" redbook on www.redbooks.ibm.com. You will not use either JAXM or JAX-RPC -- the Web Services support in WSAD 4.0 is through Apache SOAP. It can all be done through the wizards -- you won't need to write any of the client or server code yourself.
However, I would recommend you NOT do this for performance sake. You will notice a HUGE, HUGE drop in performance when moving to SOAP. It's OK to provide an additional interface for clients that can't use RMI/IIOP (like MS clients) but it's a BAD idea in general to try and replace RMI/IIOP with SOAP.