SoapUI looks very interesting and not a tool I had seen before, Thanks I will take a look at that.
Basically my SOAP Server needs to know how to interrogate the incoming SOAP request to determine what function to execute. This is similar to Axis Server's JWS idea I guess. Does Axis Server just support document/literal or does it try and interogate the SOAP Request in some way to determine which JWS function to call? -----Original Message----- From: Paul Fremantle [mailto:[EMAIL PROTECTED] Sent: Wed 06/06/2007 11:33 To: [email protected] Subject: Re: How does Axis Server determine style and encoding? Adam Firstly, you've done the right thing to work with doc/literal. This is the predominant style. If you use Apache Axis2 it should support interop well as it was designed around doc/lit as the main approach. The reason you are having trouble is that the style/encoding is *mainly* an aspect of WSDL not an aspect of the actual message. The fact is that SOAP is actually a very simple protocol. WSDL unfortunately adds a lot of complexity that isn't always useful. Basically the style and encoding are really talking about how do you map the abstract interface in WSDL (the porttype) into actual messages. So its actually possible to write say a RPC/Encoded WSDL and a doc/lit WSDL where the SOAP messages on the wire are *exactly the same*. If this doesn't seem logical don't worry. Basically what happened was that IBM and MS merged two different approaches and didn't take long enough to really sort it out, so instead we got both approaches plus subcombinations! There are some on-the-wire differences which are that sometimes encoded messages have extra typing information in the SOAP message (xsi:type attributes) and also, in some situations you can have "graph" structures in encoded message. My suggestion is to use a tool like SOAPUI to play around: try some different WSDLs and look at the resulting SOAP messages. It may be that simply by offering your Axis1 clients a different WSDL you can accomodate them without changing your server. Paul On 6/5/07, Adam Retter <[EMAIL PROTECTED]> wrote: > Hi, > > I have written a small SOAP Server for a very specific purpose, it was > designed to support Document/literal style requests initially and this > works well certainly with Apache SOAP and .NET. > > However, it does not seem to work nicely with Apache Axis clients and in > the interests of interoperability I would like to now extend it to also > support other styles and encodings. If I understand correctly there are > 2 request styles - Document and RPC and 2 main encoding styles SOAP and > literal. > > I would like to support 3 (I think) of these 4 types of requests - > Document/literal (done), RPC/SOAP and RPC/literal, I think I am correct > in saying that Document/SOAP is not really used? > > Anyways, I have glanced over the W3C specs and have done some Googling, > but I am having a hard time finding concise rules on how to detect the > request type of the incoming SOAP document - i.e. the style and > encoding. > > I was hoping that someone could point me to where in the Axis Server > code the style and encoding of the SOAP Request is determined or perhaps > provide me with a concise set of rules on determining the SOAP request > type? > > Thanks > > -- > Adam Retter > > Principal Developer > Devon Portal Project > Room 310 > County Hall > Topsham Road > Exeter > EX2 4QD > > t: 01392 38 3683 > f: 01392 38 2966 > e: [EMAIL PROTECTED] > w: www.devonline.gov.uk > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
