We have done a binary encoding of XML (what we call tML - not the ITU-T M.3030 though, incidently what will happen to M.3030? with ASN.1 being pushed again?) document primarily because we had bandwidth pipe of 10Mbps and suddenly we had to support transfer of those documents on links with 192Kbps! So it became a necessity to use our own binary encoding (the method we used was similar to x.finf - all infosets in the XML documents were coded/given type code). We had a receiver XML application using the DOM model, and so the received binary XML document was converted to DOM. But I thought there could be even more optimization though we never had time to explore further - one of the ideas was to skip DOM and pass the Java object to the application (which was the final outcome of DOM processing anyway).
If you do not have a schema available going from SAX to Java will be faster than using a DOM.
If you have a schema but you do not want to use X.694 then something like JAXB can be used and a binary infoset format, like X.finf, can be plugged into JAXB. (note X.694 can also be plugged into JAXB, see below).
This brings back my initial question - what is the impact of all the discussion around X.694, X.FWS (and X.finf) on run-time representation or modifications to senders and receivers considering the following possibilities.
A. Existing Sender with ASN.1 run-time (with pre-existing ASN.1 spec) and using XER to send information to XML App receiver
B. Existing Sender with ASN.1 run-time (but ASN.1 spec derived from an XML spec using X.694) and using XER to send to XML App receiver
C. Existing Sender with ASN.1 run-time but augmented to support WS. Responses are sent using SOAP-XML character representation with ASN.1 values converted to XML using XER. The Sender need to have XML run-time to process incoming SOAP requests and generate SOAP responses.
I cannot answer these directly since i do not use a generic ASN.1 tool (see below). However the FWS JavaOne presentation and thew FWS article show comparisons betweeen JAX-RPC (XML) and JAX-RPC (Fast Schema, X.694)
I have attached some results presented at XML 2003 that also show Fast Infoset (a prototype based on XBIS) comparing with Fast Schema (X.694) when using JAX-RPC.
D.Existing Sender with ASN.1 run-time but augmented to support FWS. Responses are sent using SOAP-ASN.1 PDUs with contents encoded using BER/PER. The Sender need to have ASN.1 run-time to generate SOAP ASN.1 PDUs and process received SOAP ASN.1 response PDUs. Plus it will need to have access to ASN.1 specification plus the original XML XSD to understand and translate a received SOAP ASN.1 response to in-memory XML representation so DOM/SAX can work transparently. (The sender need not have any XML run-time, other than access to some information derived through XML Schema->ASN.1 translation to get QNames etc. However, the receiver need to have both ASN.1 run time and XML run -time.
If FWS is supported then the ASN.1 schema is not always necessary. For example we have implemened X.694 support directly into JAXB. The XSD is processed and mapped internally using X.694 to an ASN.1 representation which is then processed. It is all performed under the covers.
It all very much depends what Web services tools you are using. The most important points IMHO are that:
1) a Web services toolkit does not have two APIs, one for XML and one for X.fws. 2) minumum impact on the service descriptions. X.fws can use WSDL (conforming to the WS-I BP 1.0) out of the box.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x19219
+353-1-8199219
results.pdf
Description: Adobe PDF document
