eric kong wrote:
Informally I can view Web Services as a list of methods /
functions somewhere on the internet, i make a call t o one of the
function / method, passing in some XML (compare to java method
parameters), then i get some data in return (compare to return type in java)
Although not exactly as RMI but as least it's very similar to RMI right ?
There are fundamental differences, the primary one being that when a
method on an object exposed with RMI returns an object reference this
may be just that, a reference to an object on the server. SOAP never
does this, it is a pure pass by value scheme.
Consider an object structure where a bank object has a getCustomer(...)
method and the customer object has a setNewBalance(...) method.
In RMI you can do this :
bank.getCustomer("foo").setNewBalance(0);
This works because the customer object returned by getCustomer is a
reference to an object on the remote machine - invoking a method on this
remote object therefore does something sensible.
If you do this with Axis, assuming you had the appropriate classes
mapped, you would get a copy of the customer object devoid of any
context on your local machine which would then have the balance set in
that local copy. Similarly, a subsequent call to the same getCustomer
method would return _another_ copy of the same 'object'.
RMI :
bank.getCustomer("foo").equals(bank.getCustomer("foo")) == true
SOAP :
bank.getCustomer("foo").equals(bank.getCustomer("foo")) == false
The above assumes that the customer object has no comparison method
defined, the point is that they are different objects in the JVM in the
SOAP case and identical ones in the RMI case. This kind of distinction
is subtle and can trip you up very badly if you don't consider what is
actually going on rather than what Axis wants you to think.
RMI and SOAP are equivalent if and only if every single class used
within the RMI scheme is Serializable rather than Remote - when an RMI
service returns a non-Remote Serializable object it performs a deep copy
and returns a copy of the object which then lives on the client side -
the same as the behaviour that SOAP must have at all times.
What we think of as an object - a capsule of data with associated code
is not what you get back from a SOAP call, no matter how smart the
toolkit is. What you get back is closer to a C struct, it is pure data.
If your client side toolkit then uses that data to populate a full
object then it gives the illusion an object has been transported but in
fact no such thing has taken place.
The upshot is that if your problem can be expressed in terms of the
manipulation of a complex server side object graph you are better
avoiding SOAP where possible - it simply does not have the ability to
express these interactions cleanly. Because of this deficiency we have
toolkits such as WS-RF which provide those features but they add even
more complexity to your implementation and deployment.
Tom
