It's important to distinguish between the message encoding style and the programming style. You specify the message encoding style using the WSDL style and use attributes. You specify the programming style in the WSDD style attribute.
There are three types of message encoding style: - rpc/encoded - rpc/literal - doc/literal Note that there is no such thing as doc/encoded. Note also that wrapped is a programming convention, not a message encoding style. There are fundamentally two types of programming style: - method invocation - messaging Axis supports three types of method invocation styles (RPC, WRAPPED, and DOCUMENT) and one type of messaging style (MESSAGE). The names of these styles are proprietary to Axis -- none of the WSF specs define any programming styles -- it's outside the scope of SOAP or WSDL. As I said in the previous message, the Axis WSDD styles correspond to the WSDL encoding styles as follows: WSDD WSDL ==== ==== RPC rpc/encoded WRAPPED doc/literal using wrapped convention DOCUMENT doc/literal unwrapped MESSAGE doc/literal unwrapped Nearly all SOAP tools support both a method invocation and a messaging interface. The JCP has defined two separate APIs -- JAX-RPC and JAXM to represent the two programming styles. Axis RPC, WRAPPED, and DOCUMENT styles implement JAX-RPC. Note that Axis does not implement JAXM. The Axis MESSAGE style is proprietary, although it is the equivalent to JAXM. Note also that JAXM is not a required component of J2EE 1.4. The difference between JAX-RPC and JAXM is equivalent to the difference between RMI and JMS. With JAX-RPC, the runtime engine automatically marshals the message contents for the application. With JAXM, the application is responsible for constructing the message. In other words, use JAX-RPC when your application wants to work with Java objects; and use JAXM when your application wants to work with XML. Regards, Anne -----Original Message----- From: Rahul Jain [mailto:[EMAIL PROTECTED] Sent: Thursday, June 17, 2004 3:19 PM To: [EMAIL PROTECTED] Subject: RE: Exposing an EJB as a doc-literal web service Anne, Hmmm. Now things are making some sense. Do other web services toolkit also differentiate between MESSAGE and DOCUMENT style services or is it just Axis-specific? Because as far as I know, I haven't heard of any MESSAGE style service as such outside of Axis docs. Everybody refers to the regular 4 style/use combinations and the additional doc-lit wrapped style. Also, in general when somebody refers to a doc-lit web service, how does that map to the Axis style - MESSAGE or DOCUMENT? Thanks for your detailed earlier reply. Really appreciate that. Rahul. >From: "Anne Thomas Manes" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: <[EMAIL PROTECTED]> >Subject: RE: Exposing an EJB as a doc-literal web service >Date: Wed, 16 Jun 2004 18:17:00 -0400 > >Rahul, > > > 1.) What is the "Message" message style you referred to below? I have > > seen that being referred in Axis docs too. What are the differences > > between the "Message" and "Document" message styles? > >Message style maps the SOAP message to a DOM; Document style maps the SOAP >message to a Java object. > >To elaborate ... > >The Axis WSDD style parameter (RPC, WRAPPED, DOCUMENT, or MESSAGE) reflects >the programming model supported by the service, while the WSDL style >parameter (rpc or document) refers to the on-the-wire message format. >There's also an unofficial WSDL style known as the wrapped convention, >which >is a form of document style that simulates the rpc style. (It's an >alternative to rpc/literal.) .NET uses the wrapped convention by default. > >These styles correspond as follows: > >WSDD WSDL >==== ==== >RPC rpc/encoded >WRAPPED doc/literal using wrapped convention >DOCUMENT doc/literal unwrapped >MESSAGE doc/literal unwrapped > >From a programming perspective, the WSDD styles do this: > >RPC: RMI-style method invocation with parameters; Axis automatically maps >Java parameters to XML string >WRAPPED: RMI-style method invocation with parameters; Axis automatically >maps Java parameters to XML string >DOCUMENT: RMI-style invocation with objects; parameters must by >programmatically marshaled into an object before invocation; Axis >automatically maps Java object to XML string >MESSAGE: messaging-style invocation using DOM; Axis automatically maps DOM >to XML string > >As you can see, from a programming perspective, there's no difference >between RPC and WRAPPED style. > > > 2.) > The first thing to understand about SOAP and WSDL is that the > > WSDL service interface is an abstraction of the method signature. > > There's no specific requirement for the two to map one-to-one. > > > As per what I gather from above, there are no specific restrictions > > on how the object interface could look like for a wrapped-literal or > > a pure doc-literal service (or for any style of service), especially > > in terms of the parameters it accepts/returns. But from some of the > > posts on the Axis archive, it would seems that if one wants to use a > > doc-literal service the web service method should (or at least > > ideally) have a signature that looks something like this (note the > > input and output param types): > > > > public SOAPBodyElement [] method(SOAPBodyElement []) > > public void method(SOAPEnvelope, SOAPEnvelope) > > public Element [] method(Element []) > > public Document method(Document) > > > > Is the above true? Or is it that any web service method (irrespective > > of its signature) could be a candidate for a doc-literal service? > >Given that the purpose of RPC and WRAPPED is to supply you with an >RMI-style >interface, the interface used with these styles typically maps one to one >with the class interface, e.g.: > > string result method(string arg1, string arg2) > >As a developer, you want to work with Java objects, not with SOAP >structures. > >When working with DOCUMENT style the interface looks more like this: > > object result method(object request) > >When working with MESSAGE style, it looks like this: > > Document result method(Document request) (for request/response) > Or > void method(Document request) (for one-way messages) > >At least that's the way it works with the supplied providers. But you can >always implement a custom provider that maps invocations anyway you like. > > > 3.) Regarding the web service I am trying to develop, I have a > > stateless Session bean with the following method signature: > > > > public String loadXMLData(String xmlString) > > > > What it does is that it accepts an xml string and processes that xml > > and returns a xml string that gives info about the success/failure of > > the process. I want to expose this as a doc-literal web service. The > > xmlString param is an xml string. Internally, I validate the xml > > string using a DTD and then if the xml is well-formed and valid do I > > proceed to process the xml, else I return an error XML string right > > away as a return value. > > Now, I want to expose this as a web service. I have also developed > > an XSD from the DTD to be used for the web service implementation. > > The questions that arise are: > > > > * What style of web service should I use? > > I understand that I want to use a doc-literal service. But trying to > > decide whether to use wrapped or non-wrapped (pure doc-lit) style. > > From what I have read about your comments on wrapped, I am now more > > inclined towards pure doc-lit just so that it does not put restrictions > > as you mentioned. But still trying to make sense before I take the > > final plunge. > >Ah. I see the source of your confusion. Your EJB is working with XML rather >than Java objects. Axis is working on the assumption that the runtime >converts all the XML to Java objects. Hmmm. I assume you're using SAX to >process this XML string? If you were using DOM, then the obvious choice is >to use MESSAGE style, which converts the SOAP message payload into a DOM. >But if your app uses SAX, then I suggest that you use the SAAJ API, which >allows you retrieve the SOAP Body element: > > public SOAPBodyElement method(SOAPBodyElement) > >In SAAJ you get the SOAPBodyElement as a string and then invoke the EJB >using its existing interface. > >You could use WRAPPED or DOCUMENT style, too, but in this case Axis would >have to treat your XML document as an opaque string, and it would have to >escape all the XML characters -- a lot of overhead, but it should work. > > > * How and where does the XSD I developed fits into the whole web > > service thingee? > > Would I import/reference the XSD in the WSDL for the service? Do > > I need to validate the XML using the XSD or is this just an > > unnecessary step because the loadXMLData() method internally does > > validate the XML string against the DTD anyway? > >You should import the XSD into the <types> section of the WSDL. You do not >need to validate the XML using the XSD (SOAP doesn't validate by default). >If you want to send multiple documents in a single message, then you need >to >define a wrapper element to hold an array of your documents. > >If you use WRAPPED or DOCUMENT, though, you should not import the XSD. In >this case, Axis has to view your payload as an opaque string. > > > * Do I need a wrapper for the EJB and in turn expose that wrapper as a > > web service instead of the EJB itself? Are there any best practices for > > exposing web services? > >You will need a SAAJ wrapper that pulls the XML string from the SOAP >message >and invokes your EJB. If you were exposing an ordinary Java object >interface >then you wouldn't need a wrapper. You could simply invoke the service using >the EJB provider. JSR 109 (WSEE) defines standards for exposing EJB >stateless session beans as Web services. > >-----Original Message----- >From: Rahul Jain [mailto:[EMAIL PROTECTED] >Sent: Wednesday, June 16, 2004 2:32 PM >To: [EMAIL PROTECTED] >Subject: RE: Exposing an EJB as a doc-literal web service > >Anne, > >Thanks for the explanation Anne. > >Now some more question: > >1.) What is the "Message" message style you referred to below? I have seen >that being referred in > Axis docs too. What are the differences between the "Message" and >"Document" message > styles? > > >2.) > >The first thing to understand about SOAP and WSDL is that the WSDL >service > >interface is an abstraction of the method signature. There's no >specific > >requirement for the two to map one-to-one. > > As per what I gather from above, there are no specific restrictions on >how the object interface > could look like for a wrapped-literal or a pure doc-literal service >(or >for any style of service), > especailly in terms of the parameters it accepts/returns. But from >some >of the posts on the Axis > archive, it would seems that if one wants to use a doc-literal service >the web service method > should (or atleast ideally) have a signature that looks something like >this (note the input and > output param types): > > public SOAPBodyElement [] method(SOAPBodyElement []) > public void method(SOAPEnvelope, SOAPEnvelope) > public Element [] method(Element []) > public Document method(Document) > > Is the above true? Or is it that any web service method (irrespective >of > >its signature) could be a > candidate for a doc-literal service? > >3.) Regarding the web service I am trying to develop, I have a stateless >Session bean with the > following method signature: > > public String loadXMLData(String xmlString) > > What it does is that it accepts a xml string and processes that xml >and > >returns a xml string that > gives info about the success/failure of the process. I want to expose >this as a doc-literal > web service. The xmlString param is an xml string. Internally, I >validate the xml string using a > DTD and then if the xml is well-formed and valid do I proceed to >process the xml, else I return > an error XML string right away as a return value. > Now, I want to expose this as a web service. I have also developed an >XSD from the DTD to be > used for the web service implementation. The questions that arise >are: > > * What style of web service should I use? > I understand that I want to use a doc-literal service. >But >trying to decide whether to > use wrapped or non-wrapped (pure doc-lit) style. From what >I > >have read about your > comments on wrapped, I am now more inclined towards pure >doc-lit just so that it does > not put restrictions as you mentioned. But still trying to >make sense before I take the > final plunge. > * How and where does the XSD I developed fits into the whole web >service thingee? > Would I import/reference the XSD in the WSDL for the service? >Do > >I need to validate the > XML using the XSD or is this just an unnecessary step because >the loadXMLData() method > internally does validate the XML string against the DTD >anyway? > * Do I need a wrapper for the EJB and in turn expose that wrapper >as a web service instead > of the EJB itself? Are there any best practices for exposing >web > >services? > >Hopefully the above questions would give you more insight about the >doubts/confusion I have. > >Thanks very much. > >Rahul. > > > > > > > > > > > > > > > >From: "Anne Thomas Manes" <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: <[EMAIL PROTECTED]> > >Subject: RE: Exposing an EJB as a doc-literal web service > >Date: Tue, 15 Jun 2004 20:38:21 -0400 > > > >Rahul, > > > >Per the WS-I Basic Profile, a document/literal style service (whether > >wrapped or not wrapped) must contain at most one message part. > > > >The first thing to understand about SOAP and WSDL is that the WSDL >service > >interface is an abstraction of the method signature. There's no specific > >requirement for the two to map one-to-one. Axis tends to tie the WSDL > >interface pretty closely to the object interface (it makes automatic > >generation much more straightforward), but it doesn't have to work that > >way. > >You can create a custom provider that processes the message exactly the >way > >you want it to. > > > >Regardless of the message style (RPC/Wrapped/Document/Message), the >message > >is received by the Axis runtime. It looks at the message signature (the > >QName of the child element of the <soap:Body>) and maps it to a >deployment > >descriptor to determine how to process the message. The deployment > >descriptor indicates which provider to route the message to (RPC, EJB, >MSG, > >or a custom provider). The provider processes the message, maps the >message > >elements to Java or DOM objects, and invokes the appropriate method. > > > >The key distinction between RPC/encoded and Doc/Literal is in the way the > >message is constructed. In the first case, the message is constructed > >according to the SOAP encoding data model (which is under-specified, and > >therefore a source of interoperability problems). In the second case, the > >message is constructed according to the schema that defines your message. > > > >The routing of messages is orthogonal to the method used to construct the > >message. > > > >Anne > > > >-----Original Message----- > >From: Rahul Jain [mailto:[EMAIL PROTECTED] > >Sent: Monday, June 14, 2004 2:28 PM > >To: [EMAIL PROTECTED] > >Subject: RE: Exposing an EJB as a doc-literal web service > > > >Hi Anne, > > > >Attached is the WSDL file. > >Your hunch was right. And as soon as I changed the service to a > >wrapped-literal, it started working. I don't know why the Java2WSDL tool > >would generate the wrong WSDL when I used the flags ( --style DOCUMENT > >--use > > > >LITERAL). I then changed the style to WRAPPED and it was fine. So does >this > >mean that doc-literal services should always take one param and not more? > > > >Also can you clarify something: According to me, say there is a class >with > >a > > > >method signature (from my case) > >public String loadXMLData(String user, String xmlData) > > > >and if one wants to expose this as a web service, then one can/should > >either > > > >expose this as a RPC-encoded service or as a doc-literal web service > >(wrapped or non-wrapped). The difference between the three being how the > >SOAP request and response message looks. Now what I don't get is this: >For > >the RPC-encoded the method will be invoked like a RPC call, while > >doc-literal is supposed to act in a different manner and I don't see how. > >The method still gets invoked for a doc-literal service and the same data > >gets passed in and worked upon. I don't see a difference in how >RPC-encoded > >and doc-literal is different in the example above. Obviously, I am >missing > >something here and I would really appreciate if you can clarify this. > > > >Thanks. > > > >Rahul. > > > > > > >From: "Anne Thomas Manes" <[EMAIL PROTECTED]> > > >Reply-To: [EMAIL PROTECTED] > > >To: <[EMAIL PROTECTED]> > > >Subject: RE: Exposing an EJB as a doc-literal web service > > >Date: Thu, 10 Jun 2004 10:29:26 -0400 > > > > > >Can you send us your WSDL? > > > > > >My first hunch is that you aren't using a wrapper element for your two > > >parameters. A doc/literal message must contain only one child element >in > > >the > > ><soap:Body>. Axis will process only the first element and ignore any > > >subsequent elements. That first child element should be a wrapper >element > > >that contains all your parameters. > > > > > >Anne > > > > > >-----Original Message----- > > >From: Rahul Jain [mailto:[EMAIL PROTECTED] > > >Sent: Tuesday, June 08, 2004 8:20 PM > > >To: [EMAIL PROTECTED] > > >Subject: RE: Exposing an EJB as a doc-literal web service > > > > > >Hi, > > > > > >Thanks for the help, Wei. > > > > > >I did what you suggested and it worked, but partially. > > > > > >The issue is there is a method called loadXMLData(String param1, String > > >param2) on the EJB. I deployed the EJB as a web service exposing this > > >method. I then wrote a client to invoke (actually used the Junit test > >case > > >generated by WSDL2Java) to test the service. What happens is the EJB on > >the > > >server only get the value for param1, but param2 is null. On the client > > >side > > > > > >I checked that the Axis generated <ServiceName>SoapBindingStub which > > >actually invoked the call using org.apache.axis.client.Call instance > > >invoke(Object[]) method, passes in the proper values to the invoke() > > >method. > > > > > >But somehow on the server (EJB) only the first param (param1) is >obtained > > >fine...param2 is somehow null. Also checked the EJB code and its is not > > >doing anything funky. It just receives the param2 as null and hence > >throws > > >an exception. > > > > > >Thanks. > > > > > >Rahul. > > > > > > > > > > > > >From: Wei Hsu <[EMAIL PROTECTED]> > > > >Reply-To: [EMAIL PROTECTED] > > > >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > > >Subject: RE: Exposing an EJB as a doc-literal web service > > > >Date: Mon, 7 Jun 2004 15:53:45 -0700 > > > > > > > >Actually, the build-in Axis EJB Provider can expose the EJB as a > > > >doc-literal > > > >web service. In the simplest case, all you have to do is change one > >line > > > >in > > > >your deploy.wsdd: > > > > > > > >From > > > > > > > ><service name="MyService" provider="java:EJB"> > > > > > > > >to > > > > > > > ><service name="MyService" provider="java:EJB" style="wrapped" > > > >use="literal"> > > > > > > > >If you want to use straight up doc-lit and not wrapped style, just >set > > > >style="document" instead. > > > > > > > >-Wei > > > > > > > >-----Original Message----- > > > >From: Rahul Jain [mailto:[EMAIL PROTECTED] > > > >Sent: Monday, June 07, 2004 10:12 AM > > > >To: [EMAIL PROTECTED] > > > >Subject: Exposing an EJB as a doc-literal web service > > > > > > > >Hi, > > > > > > > >Can somebody plz gudie me how I would expose an EJB as a doc-literal > >web > > > >service? The build-in Axis EJB Provider exposes it as a RPC service > >only. > > > > > > > >Thanks. > > > > > > > >Rahul. > > > > > > > >_________________________________________________________________ > > > >Looking to buy a house? Get informed with the Home Buying Guide from > >MSN > > > >House & Home. http://coldwellbanker.msn.com/ > > > > > >_________________________________________________________________ > > >Getting married? Find great tips, tools and the latest trends at MSN >Life > > >Events. http://lifeevents.msn.com/category.aspx?cid=married > > > > > > >_________________________________________________________________ > >MSN 9 Dial-up Internet Access fights spam and pop-ups - now 3 months >FREE! > >http://join.msn.click-url.com/go/onm00200361ave/direct/01/ > > > >_________________________________________________________________ >Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! >http://join.msn.click-url.com/go/onm00200362ave/direct/01/ > _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page - FREE download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/
