axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Oinn <...@ebi.ac.uk>
Subject Re: Web Service RMI
Date Sun, 26 Feb 2006 01:30:10 GMT
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

Mime
View raw message