Return-Path: Delivered-To: apmail-ws-axis-user-archive@ws.apache.org Received: (qmail 68579 invoked by uid 500); 26 Feb 2003 18:45:35 -0000 Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-user@ws.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-user@ws.apache.org Received: (qmail 68554 invoked from network); 26 Feb 2003 18:45:35 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Accessing the XML in the SOAP message body directly Date: Wed, 26 Feb 2003 13:45:37 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Accessing the XML in the SOAP message body directly Thread-Index: AcLcO+mMQsE3T0PaR9O0Vw7py0Ak1gAE/mjAAFrnTMA= From: "Naresh Bhatia" To: X-OriginalArrivalTime: 26 Feb 2003 18:45:38.0114 (UTC) FILETIME=[41279A20:01C2DDC7] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Okay, I have waited long enough for the experts to respond. Below I am summarizing my issues with SOAP/Axis and an alternative approach. If you have any feedback please feel free to respond. Issues ------ 1) I am disappointed by SOAP's (or Axis'?) serialization/deserialization mechanisms in general. Take for example Lists and Maps - I cannot use them interoperably. I must use arrays instead! Lists and Maps are fundamental data structures that I leverage in my Java applications all the time. And I do not want to convert back and forth between these data structures and arrays - this approach just does not scale well when the data structures increase in complexity. I don't see why serializers/deserializes cannot look at a nice XML Schema and (with some developer help) produce the right data structures desired by the developer. I see several folks on the list wrestling with the same problem (e.g. check out the thread "Design review and general axis questions"). 2) I guess SOAP's answer to issue #1 is to use doc/literal, where the payload could be pure XML conforming to some schema - SOAP will not try to enforce its encoding on it. So I switched to this technique, serializing/deserializing my Java objects myself. But now I am finding that Axis insists on converting my serialized objects (basically XML text) back to DOM and reconvert it to XML (text) on transmission. Same is true when receiving a SOAP message. Proposed Approach ----------------- Reception of SOAP messages: 1) Extract the XML text from the SOAP body. 2) Convert the text to Java Objects directly using traditional parsing techniques. I am thinking of using an XMLPull parser. Note that there is no intermediate conversion to DOM. I can use standard XML schemas and convert XML elements to Lists or Maps or whatever is appropriate. Transmission of SOAP messages: 1) Convert Java objects directly to XML text using traditional serialization techniques. Again Lists and Maps can be converted to valid XML constructs conforming to some schema. 2) Compose a SOAP message by wrapping the XML produced above. 3) Transmit the SOAP message. The XML schema used in this approach would be published in the WSDL in the section. If somebody is creating a client against this WSDL, they could use WSDL2Java or WSDL2C# etc. to generate their Java or C# objects automatically. Of course, they would have to live with arrays in their application. Or, as an alternative, they could write a customized parser to produce their favorite data structures. Now I could be easily overlooking some subtleties with this approach, so please let me know if you find any flaws. On the flip side, if you are experiencing the same issues and like this approach, please chime in. Thanks. Naresh -----Original Message----- From: Naresh Bhatia=20 Sent: Monday, February 24, 2003 6:11 PM To: axis-user@ws.apache.org Subject: RE: Accessing the XML in the SOAP message body directly Hi Mike, You wrote that: > You're not actually "transform"ing it to a SOAPBodyElement, it's just being "wrapped" in a SOAPBodyElement... Well, if you look at the SOAPBodyElement code, the text of the XML document IS being transformed to a DOM: The constructor SOAPBodyElement(InputStream input) calls super( getDocumentElement(input) ) - which first converts the input file to a DOM - it then sends the DOM to the super's constructor where it is saved in MessageElement.elementRep When the time comes to send the body on the wire, I imagine that the DOM is reconverted to XML. I feel that this is totally unnecessaty for a message style service. When I use this option I am essentially telling Axis that I am supplying the XML and don't mess with it! What I am thinking is that MessageElement keep an attribute called, say xmlDoc, which is of type String. If this attribute is initialized, Axis would not look at elementRep and simply send the xmlDoc on the wire. Developers, could you please comment on this approach? I may be totally wrong on this, but I need your input. Thanks. Naresh. -----Original Message----- From: Mike Burati [mailto:mburati@bowstreet.com]=20 Sent: Monday, February 24, 2003 2:34 PM To: 'axis-user@ws.apache.org' Subject: RE: Accessing the XML in the SOAP message body directly > So the question still remains - is there any way to insert my own XML > into the SOAP body > - without Axis having to transform it to SOAPBodyElement and back. You're not actually "transform"ing it to a SOAPBodyElement, it's just being "wrapped" in a SOAPBodyElement... But I agree with your intent - it would be nice to be able to take an XML Document object and just pass it across the wire in a SOAP Document style call. It appears (at least in 1.1beta source which I happen to have handy), that the AXIS Client Call object is basing it's Message vs RPC style decision on whether or not the arguments are all SOAPBodyElement or not, as shown in the following code snippet from Call.invoke(Object[] params) /* First see if we're dealing with Messaging instead of RPC. */ /* If ALL of the params are SOAPBodyElements then we're doing */ /* Messaging, otherwise just fall through to normal RPC processing. */ =20 /********************************************************************/ SOAPEnvelope env =3D null ; int i ; for ( i =3D 0 ; params !=3D null && i < params.length ; i++ ) if ( !(params[i] instanceof SOAPBodyElement) ) break ; What would be nice is if you could set=20 call.setOperationStyle("document"); and then call.invoke(new Object[] { myDOMDocument }); and have it serialize the Document as the body contents, and make an outgoing SOAP Document style (AXIS message style) call, serializing the DOM Document as the SOAP Body, rather than forcing the use of SOAPBodyElement and implicitly determining that it's SOAP Message/Document style based on a known type of all the arguments... Unfortunately, if you do that, because it's only checking for SOAPBodyElement arguments and ignoring the setOperationStyle() property, you will get a No Operation Specified (as if it were an RPC operation) even if you explicitly set the operation style to Document. Is this a design decision of AXIS (eg, an unexpected behavior forced by JAX-RPC compliance) or is this just a bug (that it ignores operation style and only decides between messaging vs RPC based on existence of SOAPBodyElement args)? ..Mike -----Original Message----- From: Naresh Bhatia [mailto:NBhatia@sapient.com] Sent: Monday, February 24, 2003 12:58 PM To: axis-user@ws.apache.org Subject: RE: Accessing the XML in the SOAP message body directly Interesting approach - try to send the XML as an attachment! That's a good workaround for me to keep in mind. However, I still prefer to send the XML in the SOAP body. This allows me to include the associated schema in the WSDL and then clients could choose to deserialize the body however they think is appropriate. So the question still remains - is there any way to insert my own XML into the SOAP body - without Axis having to transform it to SOAPBodyElement and back. =20 Thanks. Naresh =20 -----Original Message----- From: Ghershony, Arie [mailto:Arie.Ghershony@GDC4S.Com]=20 Sent: Monday, February 24, 2003 12:04 PM To: 'axis-user@ws.apache.org' Subject: RE: Accessing the XML in the SOAP message body directly hi, I did an example of a clinet attach a document, then receive the same document back from the server. what showld be different in the code if a client want to receive the document from the the service only. =20 =20 this is the piece of code to add an attachment: what showld be different if it is only receiving a file instead of attaching and receiving? =20 if(doTheDIME) call.setProperty(call.ATTACHMENT_ENCAPSULATION_FORMAT, call.ATTACHMENT_ENCAPSULATION_FORMAT_DIME); Object ret =3D call.invoke( new Object[] { dhSource }=20 ); //Add the attachment. =20 =20 thanks, Aria -----Original Message----- From: Naresh Bhatia=20 Sent: Friday, February 21, 2003 7:44 PM To: axis-user@xml.apache.org Subject: Accessing the XML in the SOAP message body directly I am using the Axis "Message" style service to populate the SOAP body myself. My payload originates in an XML file, which I read into a SOAPBodyElement. When I invoke the call, Axis obviously reconverts the SOAPBodyElement into XML and sends it out to the server: SOAPBodyElement[] params =3D new SOAPBodyElement[1];=20 params[0] =3D new SOAPBodyElement(new FileInputStream("message.xml")); ...=20 Vector resultElements =3D (Vector)call.invoke(params);=20 Is there any way to avoid these unnecessay conversions from XML to SOAPBodyElement and back? There is a similar problem with the returned result - I don't want Axis to convert the XML returned in the response message, I want to access the XML directly. Ah, and of course, the same problem on the server side! Where do I start? Thanks,=20 Naresh=20