Rafael, The primary criterion for choosing between the message provider (message style) and the RCP provider (RPC/wrapped/document styles) is based on whether you prefer to parse the XML yourself (message style) or if you'd rather work with Java objects (RPC provider). When using the message provider, Axis always maps the input message to a DOM. When using the RPC provider, Axis always maps the input message to one or more Java objects -- but that Java object could be a DOM when using document style. So I think you can use either message style or document style for this application. In either case, the request should be dispatched to the "put" method that interprets the input parameters and figures out what to do with the request.
My recommendation stands. Start with the WSDL/XSD description. It's not clear to me from your description, but I think you're saying you want your input message structure to be dynamic -- it can be any number of levels deep. You can define such a structure by defining optional elements with the attribute minOccurs="0". In answer to your question about wsdl-first and wrapped style -- today, when using the latest version of Axis, you pretty much have to use the wsdl-first approach to be successful with the wrapped style. That's not true of many of the commercial implementations, though. Anne -----Original Message----- From: Rafael Gomez [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 9:06 AM To: [EMAIL PROTECTED] Subject: Re: message style SOAP service First of all, thanks for your answer. I was testing a bit and I finally managed to get Option #1 working. But I have to say that I am a bit confused and I have no idea why this is working. So I decided to take a look at MsgProvider source code. Its 'invoke' method gets a OperationDesc object from the msgCtx. And from that OperationDesc it gets a Method object ('reflection' is used to actually call the method of the service class). But I got lost trying to find where those objects ( OperationDesc and Method ) are created and set to the msgCtx. So it seems like several methods can be associated with a service URL like in Axis rpc/document/wrapped cases. I will continue looking at the source code but I would appreciate if anyone has a clue about how this is working. If the Option #1 is a correct option then you don't need to extract the operation from the message. You get it for free using a method per possible operation. Then it might be a good idea to use it. But if this is unexpectably working, i.e, it is not meant to work like that, then let's forget Option #1. The reason why I want to use Axis message style is mainly because I am using soap messages like this: (always one only child in soap env. body) <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/";> <soap-env:Body> <a:put xmlns:a="http://mysite.com/a.xsd";> <a:A> <a:A1> <a:A11>a_string_here</a:A11> </a:A1> <a:A2>a_string_here</a:A2> </a:A> </a:put> </soap-env:Body> </soap-env:Envelope> i.e, the 'parameters' to the operation 'put' are more kind of a xml structure that could get deeper than for example a:A11. Then the service class' involved method ( for that operation...) would extract the needed xml data to be passed to a back-end system component. Is this reasoning ok? I mean, choosing to use Axis message style in this case? My first idea was to develop the service class (and needed handlers) and then get the wsdl via the '?wsdl' trick. That way I suppose users of the service can create clients. But after reading this conversation I got confused: - is it better to design the wsdl first? [That way you can follow the steps in your article...] - isn't designing-the-wsdl-first the only way to get the wrapped convention working? - or is my first idea ok as well? What I try is to implement my service(s) the right way from the beginning and using concepts properly. Thanks in advance. Regards, -R >I apologize -- I'm not an expert on the Axis message handler, so I'm not >100% sure about this answer -- perhaps someone else can pipe up and correct >me if I'm wrong. > >But here's my reasoning about how it should work: > >When using a message style service with a message signature such as > Public void method( SOAPEnvelope req, SOAPEnvelope resp ) > >you're telling Axis not to process the SOAP body, so it will dispatch the >method before processing the child element of SOAP Body (the operation >name). Option #1 won't work. You have to use option #2: one method for all >operations. Your method must process the XML, extract the operation from the >message, and perform the requested operation. > > >I'm not quite sure how Axis goes about dispatching the method -- I'm >assuming that the message provider permits only one method to be associated >with a service URL. I'm also not quite sure how to configure this service >such that the WSDL associated with it actually exposes the wrapped >doc/literal interface. But you should be able to do so. > >- Anne > >-----Original Message----- >From: Rafael Gomez [mailto:[EMAIL PROTECTED] >Sent: Monday, September 27, 2004 2:15 PM >To: [EMAIL PROTECTED] >Subject: Re: message style SOAP service > >Anne, > >I am following this conversation and I would like to ask one more thing >based on the wsdl example at >http://www.burtongroup.com/weblogs/annethomasmanes/archives/cat_apache_axis . >html > >Suppose we add 2 new 'operations' to the service, say 'multiply' and >'divide', both taking again two 'int' arguments and returning an 'int'. >We could complete the wsdl using the same approach used for the >operation 'add' (, i.e, via wrapped convention) > >Suppose I choose Axis MESSAGE programming style for the service class, >and for example, the method signature 'public void method( SOAPEnvelope >req, SOAPEnvelope resp )'. > >What's the normal/correct thing to do when implementing my service class?: > >1) implementing one method per operation, i.e: > >public void add(SOAPEnvelope req, SOAPEnvelope resp) >{....} >public void multiply(SOAPEnvelope req, SOAPEnvelope resp) >{....} >public void divide(SOAPEnvelope req, SOAPEnvelope resp) >{....} > >Would Axis call correct method based on the operation name (i.e, based >on the wrapper element name in soap request) ? >If yes, when is the correct method determined? Who finds the correct method? > >2) implementing only one method for all the operations, i.e: > >public void myMethod(SOAPEnvelope req, SOAPEnvelope resp) >{....} > >Then myMethod could extract 'operation name' and parameters from the >request, compute and create/modifiy the resp. > >-R > > > > > > >Message examples from a client: > ><?xml version="1.0" encoding="UTF-8"?> ><SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > <SOAP-ENV:Body> > *<add*> > <arg1 xsi:type="xsd:int">*2*</arg1> > <arg2 xsi:type="xsd:int">*5*</arg2> > *</add*> > </SOAP-ENV:Body> ></SOAP-ENV:Envelope> > > ><?xml version="1.0" encoding="UTF-8"?> ><SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > <SOAP-ENV:Body> > *<multiply*> > <arg1 xsi:type="xsd:int">*2*</arg1> > <arg2 xsi:type="xsd:int">*5*</arg2> > *</**multiply*> > </SOAP-ENV:Body> ></SOAP-ENV:Envelope> > > > > > >
