axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Burati <>
Subject RE: document style web services
Date Wed, 30 Apr 2003 14:01:15 GMT

>       My question is from the SOAP message above nowhere is the method
>       "method" mentioned above. So how does the Axis framework understand
>       which method to invoke? All the SOAP msg contains is the
>       PurchaseOrder XML .

Hmm, I was about to say keep reading, it's in the doc somewhere, but then I
went to take a look and couldn't find what I thought was there (a section on
"dispatch"ing).  Maybe it says more in the Sun JAX-RPC docs and tutorial and
that's what I was thinking of.

Anyway, the best way to learn how AXIS works is to grab the source and skim
enough of it to get a better picture of what's going on.  A quick read of
the architecture guide (in addition to / after reading the user guide) helps

Here's a very brief summary of my very rough understanding of an
over-simplified flow :-)

In src/org/apache/axis/handlers/http there are two handlers that look at
incoming requests and set the service name in the MessageContext based on
what they find. looks for a SOAP Action HTTP header (not used by many
services) and if found, sets the service name in the MC based on that. looks for a service name in the URL (eg, after /service/ )
and if there, sets the service name in the MC based on that.

With a service name, there's now a mapping to a provider - see your
service's config in in server-config.wsdd (assuming you've deployed your

 <service name="Version" provider="java:RPC">
 <service name="AdminService" provider="java:MSG">

So from the service name Version, you can tell that it uses the RPC provider
and AdminService uses the MSG provider.

In src/org/apache/axis/providers/java you'll find both and

These two classes are both straightforward enough for a quick skim through
to see what they do, although RPCProvider takes a little bit of re-reading
to understand since it handles both SOAP RPC and non-axis-message SOAP
Document style services.  Personally, (and I'm no AXIS expert yet, so I
could be wrong) I would've preferred separate providers for RPC vs Document
style and separate config types so that more could be determined at config
time instead of doing extra work to infer it at runtime in the provider...  

Anyway, if you read through there, for SOAP RPC style in the RPC provider it
looks for the method name in the body, and deserializes the args so that it
can then call the right method via reflection.  For Document style in the
RPCProvider, it gets the QName of the body (eg, from your
<myNS:PurchaseOrder xmlns:myNS=""> ) and looks for a
service method claiming to take one of those:

        if (operation == null) {
            QName qname = new QName(body.getNamespaceURI(),
            operation = serviceDesc.getOperationByElementQName(qname);

        if (operation == null) {
            throw new AxisFault(Messages.getMessage("noSuchOperation",

If on the other hand, you're using message style, take a look through which grabs the method to be called out of the
MessageContext's OperationDesc...

 * Deal with message-style Java services.  For now, these are services
 * with exactly ONE OperationDesc, pointing to a method which looks like
 * one of the following:
 * public Element [] method(Vector v);
 * (NOTE : This is silly, we should change it to either be Vector/Vector
 * or Element[]/Element[])
 * public Document method(Document doc);
 * public void method(MessageContext mc);


-----Original Message-----
Sent: Wednesday, April 30, 2003 9:30 AM
Subject: Re: document style web services

Hi All
I am attaching this from the Axis documentation:

A good place to start in describing the difference between document and
wrapped services is with a sample SOAP message containing a purchase order:

       <soap:Envelope xmlns=""
           <myNS:PurchaseOrder xmlns:myNS="">
             <description>Sushi Knife</description>

       The relevant schema for the PurchaseOrder looks like this:

       <schema targetNamespace="">
         <complexType name="POType">
             <element name="item" type="xsd:string"/>
             <element name="quantity" type="xsd:int"/>
             <element name="description" type="xsd:string"/>
         <element name="PurchaseOrder" type="POType"/>

       For a document style service, this would map to a method like this:

       public void method(PurchaseOrder po)
       ------------------------------------??? How

       My question is from the SOAP message above nowhere is the method
       "method" mentioned above. So how does the Axis framework understand
       which method to invoke? All the SOAP msg contains is the
       PurchaseOrder XML .




                      Mitch Gitman

                      <>        To:


                      04/29/2003 01:19         Subject:  Re: document style
web services                                               

                      Please respond to




Not that this answer helps you directly.

"What else one can buy with using Doc/literal type service" (as opposed to
RPC/encoded or RPC/literal):
* Arguably a more comprehensible, transparent Web service description. Same
for the SOAP messages. (Of course, ideally with a Web services toolkit, you
might not be poring over the XML at all.)
* The ability to piggyback on the use of XML Schema elsewhere. For
the XSD definitions of objects you're passing via SOAP could just as well
used in a non-SOAP context. Likewise, document/literal lets you readily
perform XML Schema validation on the contents of the <soap:Body>. Also, if
you're going to be poring over the XML and you already need to know XML
Schema, then SOAP 1.1 Section 5 encoding is just one fewer thing you need
be well-versed in. (Goes back to "more comprehensible.")
* Greater interoperability with Web service engines that only fully and
reliably support document/literal. (Yes, this is very much a political
Just stating facts, not necessarily applauding those facts.)

While you may certainly have valid reasons for wanting to deal with DOM/SAX
representations of your objects rather than the objects themselves, it is a
misconception to think that document/literal is necessarily associated with
XML representations. wrote:

Hi Davinder
I am going to try out what you suggested - but before that I would ask one
question - this Add and AddResponse which are the parameters [input and
return] of the services "add" method - can you invoke the add method from
the client just by passing XML and not dealing with the Add object? Because
I am not getting what else one can buy with using Doc/literal type service
if they are not able to pass XML and are forced to deal with Objects.

View raw message