You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by eric kong <ui...@yahoo.com> on 2006/02/25 18:55:51 UTC
Web Service RMI
1) So web serivces is basically == RPC (Remote Procedure Call) == RMI (similar if only using Java) ??
2) Web services is a way of doing remote Method Invocation?
3) Then Web Services is == Java RMI + ability to invoke methods on other languages / platforms (e.g. .NET / Perl / PHP ..etc) ???
4) besides RPC / remote Method Invocation, what web services can do ? Or that's it for web serivce which is RPC?
---------------------------------
Brings words and photos together (easily) with
PhotoMail - it's free and works with Yahoo! Mail.
Re: Web Service RMI
Posted by Tom Oinn <tm...@ebi.ac.uk>.
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
Re: Web Service RMI
Posted by eric kong <ui...@yahoo.com>.
>From my understanding
1) WSDL = document describe a list of function / methods skeletons + function / methods parameters + return type
3) In Axis for example there are only 2 ways to call up web services on the internet
A) (without using / generate stub + skeletons) --> example1 in axis samples
--> call web service using --> Call call = (Call) service.createCall();
B) (generate stub + skeletons using WSDL2Java) example6 in axis samples
--> call web service using --> WidgetPriceServiceLocator().getWidgetPrice()
For Case B ( generate stub + stkeletons) it's exactly what RMI did
1) you know the methods + method parameters + return type -->
2) make call and then get a return
For case A you make a call to a method then "CAST" the return objects
Plus I heard other SOAP toolkit works same way, although some use a call interface(Case A) instead of a stub interface (Case B)
Informally I can view Web Services as a list of methods / functions somewhere on the internet, i make a call to 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 ?
tmo@ebi.ac.uk wrote:
> 1) So web serivces is basically == RPC (Remote Procedure Call) == RMI
> (similar if only using Java) ??
No
> 2) Web services is a way of doing remote Method Invocation?
Ditto
> 3) Then Web Services is == Java RMI + ability to invoke methods on other
> languages / platforms (e.g. .NET / Perl / PHP ..etc) ???
See above
> 4) besides RPC / remote Method Invocation, what web services can do ? Or
> that's it for web serivce which is RPC?
Web services are a way of passing messages from one endpoint to another
and corresponding mechanisms for describing those messages. Web services
have absolutely no concept of objects whatsoever.
Toolkits such as Axis may expose functionality that looks as if you're
moving objects around or exposing references to them but it lies to you -
do not be fooled.
If you want to know the answer to these questions you should, along with
anyone else claiming to have expertise in web services, read the
specifications - they are relatively short and sane. Relative for a W3C
specification document that is, I actually mean they're overly long,
poorly defined and tedious but unfortunately that's the way the world is.
Understand SOAP first - then understand how Axis presents SOAP to you as a
toolkit user. Do this in the wrong order and you will shoot yourself in
the foot with a slow acting poison which will only become apparent after a
significant amount of (now wasted) development time.
SOAP spec(s) : http://www.w3.org/TR/soap/
WSDL spec(s) : http://www.w3.org/TR/wsdl
In addition you must read and fully understand the WS-I profile documents,
I suggest reading them alongside the above as they help to remove some of
the swirling mists of dank fetid uncertainty and confusion. Some of them.
They'll also help you create interoperable services:
WS-I Basic profile :
http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html
WS-I Attachments profile :
http://www.ws-i.org/Profiles/AttachmentsProfile-1.0-2004-08-24.html
For more complex service patterns that are much closer to what RMI and
CORBA give you in terms of state binding and a more object oriented view
you should probably also take a look at the WS-RF specifications and
overview at http://www.globus.org/wsrf/#relevant
If you don't care about service interop and want genuine remote method
invocation use CORBA or RMI, don't bother with SOAP. If you insist on
using SOAP and have requirements which are in any way unusual or non
standard be prepared to patch and roll your own version of Axis, Crossfire
or in fact any of the other toolkits. I'd suggest using .net but to be
honest it's just as bad as far as I can tell.
Tom
---------------------------------
Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.
Re: Web Service RMI
Posted by tm...@ebi.ac.uk.
> 1) So web serivces is basically == RPC (Remote Procedure Call) == RMI
> (similar if only using Java) ??
No
> 2) Web services is a way of doing remote Method Invocation?
Ditto
> 3) Then Web Services is == Java RMI + ability to invoke methods on other
> languages / platforms (e.g. .NET / Perl / PHP ..etc) ???
See above
> 4) besides RPC / remote Method Invocation, what web services can do ? Or
> that's it for web serivce which is RPC?
Web services are a way of passing messages from one endpoint to another
and corresponding mechanisms for describing those messages. Web services
have absolutely no concept of objects whatsoever.
Toolkits such as Axis may expose functionality that looks as if you're
moving objects around or exposing references to them but it lies to you -
do not be fooled.
If you want to know the answer to these questions you should, along with
anyone else claiming to have expertise in web services, read the
specifications - they are relatively short and sane. Relative for a W3C
specification document that is, I actually mean they're overly long,
poorly defined and tedious but unfortunately that's the way the world is.
Understand SOAP first - then understand how Axis presents SOAP to you as a
toolkit user. Do this in the wrong order and you will shoot yourself in
the foot with a slow acting poison which will only become apparent after a
significant amount of (now wasted) development time.
SOAP spec(s) : http://www.w3.org/TR/soap/
WSDL spec(s) : http://www.w3.org/TR/wsdl
In addition you must read and fully understand the WS-I profile documents,
I suggest reading them alongside the above as they help to remove some of
the swirling mists of dank fetid uncertainty and confusion. Some of them.
They'll also help you create interoperable services:
WS-I Basic profile :
http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html
WS-I Attachments profile :
http://www.ws-i.org/Profiles/AttachmentsProfile-1.0-2004-08-24.html
For more complex service patterns that are much closer to what RMI and
CORBA give you in terms of state binding and a more object oriented view
you should probably also take a look at the WS-RF specifications and
overview at http://www.globus.org/wsrf/#relevant
If you don't care about service interop and want genuine remote method
invocation use CORBA or RMI, don't bother with SOAP. If you insist on
using SOAP and have requirements which are in any way unusual or non
standard be prepared to patch and roll your own version of Axis, Crossfire
or in fact any of the other toolkits. I'd suggest using .net but to be
honest it's just as bad as far as I can tell.
Tom