axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eric kong <>
Subject Re: Web Service RMI
Date Sat, 25 Feb 2006 23:32:24 GMT
>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 ?
  > 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) ???

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) :
WSDL spec(s) :

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 :
WS-I Attachments profile :

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

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.


Yahoo! Mail
Bring photos to life! New PhotoMail  makes sharing a breeze. 
View raw message