Re: AXIS serialization/deserialization of XML payloads without SOAP/WSDL processing

[Anne Thomas Manes]

Thanks for sending this. I think they'll have a lot of trouble meeting their schedule (end of 2004) -- especially if they plan to support WSDL 1.2. I doubt that WSDL 1.2 will be finished by then. ----- Original Message ----- From: Robert Lowe To: [EMAIL PROTECTED] Sent: Monday, August 04, 2003 4:20 PM Subject: Re: AXIS serialization/deserialization of XML payloads without SOAP/WSDL processing From JSR 224 (http://jcp.org/en/jsr/detail?id=224):   "Due primarily to scheduling concerns, JAX-RPC 1.0 had to define its own data binding facilities. Now that the JAXB 1.0 technology ( JSR-31) has gone final, there is no reason to maintain two separate sets of XML mapping rules in the Java(TM) platform. Hence we anticipate that JAX-RPC 2.0 will strongly align with JAXB, effectively delegating to the JAXB 2.0 specification (developed in parallel with the present one) all data binding-related tasks."   - Rob     ----- Original Message ----- From: Anne Thomas Manes To: [EMAIL PROTECTED] Sent: Monday, August 04, 2003 9:37 PM Subject: Re: AXIS serialization/deserialization of XML payloads without SOAP/WSDL processing Hmmm...   Axis is designed to be XML protocol-agnostic, but the current product implements support for only SOAP 1.1 and (in preliminary form) SOAP 1.2. So to ask Axis to do raw XML message processing, you will have to implement support for your raw protocol. (You'd have to rewrite a pretty significant piece of Axis.)   Considering that the primary focus behind Axis is to perform SOAP processing, I probably wouldn't recommend using it to perform raw XML over HTTP processing. I'd recommend using a servlet with some type of Java/XML binding framework, such as Castor or JAXB.   I'm not yet convinced that "Axis will eventually need to support JAXB". I haven't seen a requirement from the JAX-RPC expert group that says that serialization will have to use JAXB. JAXB is a relatively heavy-weight binding framework, so I suspect that SOAP builders and users will resist this type of requirement. We'll see how things work out.   Anne ----- Original Message ----- From: Tony Opatha To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Monday, August 04, 2003 1:01 AM Subject: Re: AXIS serialization/deserialization of XML payloads without SOAP/WSDL processing Anne,   I understand that we can process XML payload delivered by AXIS run-time via JAXB.   However, is it possible to make AXIS process a message (e.g., non-SOAP message) that contains a XML payload given the .xsd schema for the payload?   E.g., given a message stream that represents a raw  XML payload will it be possible to unmarshall the XML stream into its Java bean objects corresponding to its XML schema specification?   Is not AXIS messaging architecture message protocol agnostic?   Also, is it possible to use WSDL2Java tool to generate the Java bean object corresponding to the XSD schema specification of the XML payload and marshall the Java objects into raw XML streams rather than SOAP message stream?   I agree that it would be useful to compare the performance, stability, footprint, and XML schema support levels between JAXB 1.x and AXIS 1.1.   It seems that AXIS will eventually need to support JAXB particularly once JAXB 2.0 is ready. However, my question above have to do with the question of exploting AXIS XML processing without using SOAP message packaging. Thank you very much for all your help.     Anne Thomas Manes <[EMAIL PROTECTED]> wrote: Tony,   Axis MESSAGE style tells Axis that you don't want to use the Axis serialization engine. In this case Axis delivers the contents of the SOAP body directly to the application as a DOM element. Your application can process the XML as it sees fit (e.g., using JAXB).   Note that this style of communication isn't "outside the SOAP processing realm". Axis still implements the SOAP processing model -- it manages the network communications; it creates and manages the SOAP envelope, it processes any SOAP headers that exist; it invokes the appropriate handlers; it loads and manages the application agent for you. The only thing it doesn't do is convert the XML into Java for you.   You might want to do some benchmark comparisons between Axis serialization and JAXB serialization. I'd look at performance, scalability, and footprint differences.   Anne ----- Original Message ----- From: Tony Opatha To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, August 02, 2003 4:51 PM Subject: AXIS serialization/deserialization of XML payloads without SOAP/WSDL processing 1. Is there a way to use AXIS to process and generate XML payload streams using the     XML schema (in .xsd) specifications of the payloads such that the payload streams     are not serialized or deserialized to/from a SOAP message envelope?   2. If AXIS has general schema-driven XML payload serialization and serialization     capability using the payload schema definition than wouldn't this be basically     similar functionality as JAXB?   3. What are step to configure AXIS run-time for such XML payload support outside     the SOAP processing realm? What do we have to design -time to compile     and generate the corresponding serialization/deserialization classes using the     XSD?     Thanks you very much for all your help.   Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software