axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@usa.net>
Subject Re: document style webservice fundamental question
Date Tue, 29 Apr 2003 03:43:49 GMT
Anamitra,
I know you write, “? I would really love to see the client not have to
bother (about) the PurchaseOrderBean and just deal with XML.” Typically,
someone using a Web service toolkit will want to do just the opposite and deal
with the PurchaseOrderBean and let the toolkit do the XML. So my answer is
predicated on that assumption.

From a Web service toolkit user’s standpoint, the Web service’s style
shouldn’t affect whether you’re working directly with your objects or
indirectly with XML representations of your objects. The Web service style is
something the toolkit user should be able to choose, but the choice should
then be relatively transparent. 

Regardless of whether you’re using document or RPC style, the tool that
generates client proxy source code from WSDL (+XSD) should ultimately expose
an interface of:
public String processPO(PurchaseOrderBean poBean)

This WSDL-to-whatever tool will have recreated the PurchaseOrderBean probably
using public members.

Now, I’m saying this is the way things SHOULD be. The onus should be on the
Web service toolkit to give the user Web service delivery choices but also to
encapsulate the details of those choices. 

I know the behavior in the example above is what .NET’s wsdl.exe does. I
know this is what Axis does this for RPC/encoded Web services. I haven’t
tried Axis yet for document/literal or RPC/literal Web services.

Likewise, you should have some way of starting from a server-side method
like:
public String processPO(PurchaseOrderBean poBean)
and then specifying that the Web service toolkit publish that method using a
certain style.

I know .NET does this using the attributes construct, where you’re adding
metadata to types, methods, and instances. I don’t know how other Web
service runtimes give these choices. With Axis, I’ve always just let it do
its default RPC/encoded thing. Naturally, server-config.wsdd would have this
information, but I don’t know; I haven’t tried this.

My understanding is that with Axis, if you want to do something other than
RPC/encoded, you would just have to start from a WSDL (+ XSD) and use
WSDL2Java to generate the server-side interfaces. Again, I haven’t tried
this, but the developer SHOULD still wind up seeing:
public String processPO(PurchaseOrderBean poBean)
That would still require the Axis runtime to change its behavior, so somehow
the choice would have to be stated in the WSDD.

Someone also recommended Systinet WASP. Haven’t tried it yet. 

As for the difference between document style and RPC style, document style
lets you fully specify the contents of the <soap:Body> using XML Schema
definitions either directly in your WSDL or in an imported XSD.

RPC style takes the TYPES you specify as parameters and as return types and
wraps extra XML elements around them to make the contents of the <soap:Body>
resemble a method call.

So for the method:
public String processPO(PurchaseOrderBean poBean)
you might have:

<soap:Body>
___<ns1:processPO xmlns:ns1=”...”>
______<poBean>
_________<ns2:PurchaseOrderBean xmlns:ns2=”...”>
____________<name>anna</name>
____________<id>1213</id>
_________</ns2:PurchaseOrderBean>
______</poBean>
___</ns1:processPO>
</soap:Body>

The element <processPO> (or is it <processPORequest>?) is your method. For a
SOAP response, this would be <processPOResponse>. Its namespace, ns1, is taken
from the namespace attribute of the WSDL element
wsdl:definitions/wsdl:binding/wsdl:operation/wsdl:input/wsdlsoap:body.
(wsdlsoap is “http://schemas.xmlsoap.org/wsdl/soap”.)

The element <poBean> is a parameter and is not namespace-qualified (at least
according to one convention). Only in the contents of this element do you get
to your types, possibly in another namespace, ns2.

(This example assumes literal formatting of the XML types themselves, as
opposed to SOAP encoding. From what I understand, the RPC/literal combination
is not broadly supported.)

The differences between document and RPC have been explained previously on
this list.


Anamitra.Bhattacharyya@mro.com wrote:




Hi
I am confused abt the doc style webservices. I am not asking this question
in the light of Axis - but a generic Java Webservices question. If I have a
method like:


public class DocService
{
      public String processPO(PurchaseOrderBean poBean)
      {

      }
}

Here PurchaseOrderBean represents a XML which has a schema.
Q1>In that case if I build this as a RPC style Web service - then the
client of this service will have to invoke this method by passing a
PurchaseOrderBean object and not by the literal XML - right?

Q2> If I go for a document style webservice then the client should be able
to just pass the XML without having to use the PurchaseOrderBean - right?
becaseu if this is not the case then whats the difference between doc and
rpc style webservice? I would really love to see the client not have to
bother abt the PurchaseOrderBean and just deal with XML. But the I am not
sure how I can write the client. I have to use the Call object of the
JAX-RPC right? Does anyone has any sample JAXRPC client for doc style
servicves passing XML [not to a String parameter - but  to a schema
complexType like PurchaseOrderBean]?


So my question is for a doc/literal situation should I be able to pass a
XML like

<PurchaseOrder>
   <name>anna</name>
   <id>1213</id>
</PurchaseOrder>

from my client to invoke the method processPO in Axis or in any other tool.

I strongly beleive I should be - but just wondering if anyone have tried
it.

thanks
Anamitra







Mime
View raw message