RE: [ASN.1] GDMO/CMIP, WSDL-XML/SOAP-XML, FWS-ASN.1/SOAP-ASN.1
Paul, thank you for pointing to XBIS and providing performance results. I am surprised at the performance of (Fast Schema, X.694) compared to FastInfoSet - I thought run-time conversion from ASN.1 to XML and vice versa using X.694 is more processor intensive than FastInfoSet - a blind conversion from XML to ASN.1 and vice versa. -Manohar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul Sandoz Sent: Monday, April 26, 2004 2:47 AM To: [EMAIL PROTECTED] Subject: Re: [ASN.1] GDMO/CMIP, WSDL-XML/SOAP-XML, FWS-ASN.1/SOAP-ASN.1 Manohar Naidu Ellanti wrote: 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
RE: [ASN.1] GDMO/CMIP, WSDL-XML/SOAP-XML, FWS-ASN.1/SOAP-ASN.1
Since my initial post on this, I was brought to attention x.finf - fast info set and the potential it may have compared to X.694 (thank you Steve Legg). 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). 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. 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. Your views/feedback appreciated. -Manohar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Manohar Naidu Ellanti Sent: Thursday, April 22, 2004 7:59 AM To: [EMAIL PROTECTED] Subject: RE: [ASN.1] GDMO/CMIP, WSDL-XML/SOAP-XML, FWS-ASN.1/SOAP-ASN.1 Probably I used a terminology that is new and needs some explanation. 1.WSDL-XML/SOAP-XML : Service Described/specified using WSDL+XMLSchema. The correspondence between client/server is done using SOAP messages with character-based XML representation. 2.WSDL-XML/SOAP-ASN.1 : Service Described/specified using WSDL+XMLSchema. The correspondence between client/server is done using SOAP messages using ASN.1 representation as specified in X.FWS and using BER/PER efficient encodings. 3.FWS-ASN.1/SOAP-ASN.1: Service Described/specified using ASN.1 (not yet defined but a possibility, see below my logic). The correspondence between client/server is done using SOAP messages using ASN.1 representation as specified in X.FWS and using BER/PER efficient encodings. Currently - 2 can be collectively called FWS. The purpose and benefits of 3 (where everything is ASN.1) would come from legacy ASN.1 applications that need to be retrofitted with WS features yet they need to retain their current ASN.1 implementation needs. I am not sure such legacy need exists in IT but for telecom and data com yes. A while ago JIDM group did work on interworking of CORBA and SNMP domains and specified static and interaction translation methods. There is also CORBA to WSDL translation document I have come across - I can send you reference if you are interested. Possible logic for seeing WS specified using ASN.1 rather than XML Schema as done (i.e current WSDL spec) : A F/WS is specified using WSDL, which contains data type definitions as per XML schema. Using X.694 translation rules the data types can be converted to ASN.1. However, in the future it should be possible to describe services directly using ASN.1 i.e. there could be ASN.1 version of WSDL. There is already an ASN.1 version of SOAP [X.FWS]. While WS SOAP message is transferred and hence need to be in ASN.1 form to make use of bandwidth efficient BER/PER encodings, the same is not the case with F/WS WSDL XML specification as usually it is used to generate client and server side code only. However, since it contains data type definitions and ultimately instance values of these data types are transferred, it makes sense to use ASN.1 for the service specification itself. -Manohar -Original Message- From
RE: [ASN.1] GDMO/CMIP, WSDL-XML/SOAP-XML, FWS-ASN.1/SOAP-ASN.1
Probably I used a terminology that is new and needs some explanation. 1.WSDL-XML/SOAP-XML : Service Described/specified using WSDL+XMLSchema. The correspondence between client/server is done using SOAP messages with character-based XML representation. 2.WSDL-XML/SOAP-ASN.1 : Service Described/specified using WSDL+XMLSchema. The correspondence between client/server is done using SOAP messages using ASN.1 representation as specified in X.FWS and using BER/PER efficient encodings. 3.FWS-ASN.1/SOAP-ASN.1: Service Described/specified using ASN.1 (not yet defined but a possibility, see below my logic). The correspondence between client/server is done using SOAP messages using ASN.1 representation as specified in X.FWS and using BER/PER efficient encodings. Currently - 2 can be collectively called FWS. The purpose and benefits of 3 (where everything is ASN.1) would come from legacy ASN.1 applications that need to be retrofitted with WS features yet they need to retain their current ASN.1 implementation needs. I am not sure such legacy need exists in IT but for telecom and data com yes. A While JIDM group some work on interworking of CORBA and SNMP domains and specified static and interaction translation methods. There is also CORBA to WSDL translation document I have come across - I can send you reference if you are interested. Possible logic for seeing WSDL use of ASN.1 notation rather than XML Schema: A F/WS is specified using WSDL, which contains data type definitions as per XML schema. Using X.694 translation rules the data types can be converted to ASN.1. However, in the future it should be possible to describe services directly using ASN.1 i.e. there could be ASN.1 version of WSDL. There is already an ASN.1 version of SOAP [X.FWS]. While WS SOAP message is transferred and hence need to be in ASN.1 form to make use of bandwidth efficient BER/PER encodings, the same is not the case with F/WS WSDL XML specification as usually it is used to generate client and server side code only. However, since it contains data type definitions and ultimately instance values of these data types are transferred, it makes sense to use ASN.1 for the service specification itself. -Manohar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul Sandoz Sent: Thursday, April 22, 2004 3:12 AM To: [EMAIL PROTECTED] Subject: Re: [ASN.1] GDMO/CMIP, WSDL-XML/SOAP-XML, FWS-ASN.1/SOAP-ASN.1 Hi Steen, Steen Oluf Karlsen wrote: I would like to request opinions on how to map (if ever there would be need) GDMO/CMIP models to WSDL-XML/SOAP-XML or FWS-ASN.1/SOAP-ASN.1? Also, I have few questions with respect to some of the XML--ASN.1 and FWS efforts: This mailing list has been silent for a long time... when suddenly Very interesting discussion... Somewhere underways I missed the acronym FWS-ASN.1. What is this pls ? FWS = Fast Web Services. Fast Web Services is the term applied to the use of ASN.1 to provide message exchanges based on a SOAP envelope and WSDL specification of services that can have a higher transaction-processing rate and less bandwidth requirements than use of a character-based XML representation. See the links for more information [1-3] for more info. Paul. [1] http://java.sun.com/developer/technicalArticles/WebServices/fastWS/ [2] http://asn1.elibel.tm.fr/xml/#fast-web-services [3] https://jwsdp.dev.java.net/fast/ -- | ? + ? = To question \ Paul Sandoz x19219 +353-1-8199219
[ASN.1] GDMO/CMIP, WSDL-XML/SOAP-XML, FWS-ASN.1/SOAP-ASN.1
I would like to request opinions on how to map (if ever there would be need) GDMO/CMIP models to WSDL-XML/SOAP-XML or FWS-ASN.1/SOAP-ASN.1? Also, I have few questions with respect to some of the XML--ASN.1 and FWS efforts: Currently there is vast amount of GDMO/ASN.1 specifications (M.3100,G.774 etc). So my thought is that GDMO will continue to be around. I can send a figure that I drew to map GDMO to WSDL(+schema) to any one interested (please mail me seperately). But behind the plethora of information available in X.693,x.694,x.FWS I find it difficult to come to some elementary understanding of how GDMO/CMIP to fGDMO(fast GDMO) will look like. Your help will be greatly appreciated. a comment on the GDMO part of the above Mr Thorpe [Thorpe] Please note, however, that GDMO is considered obsolete since the introduction of Information Object Classes to ASN.1. See additional comments below. Are there any tools to convert legacy GDMO models to FWS (or XML). Also, I believe all newer ITU-T specs, such as for FTTP/PON, are being developed using UML. Is this correct? If so how is FWS (ASN.1 schema notation) going to fit with UML approah? Overall, I wish there are more figures in X.fws and X.694 that depict the architecture and use cases before the translation rules or information items. The two figures in X.694(the draft X.694, not the final doc) do help - and Particularly, figure 1 in X.694 - there is lot of conversion from XML document to ASN.1 purely for the purpose of encoding. It seems to me that this is too much of processing by the device - probably will make sense if the final encoded data is to be transferred on a bandwidth limited connection. But would it make sense for HPC to bother with this conversion? - one response I got from Mr Thorpe: [Thorpe]Please note that the conversion from XSD to ASN.1 is not necessarily intended to be done on the device. A tool (such as one created by OSS Nokalva) can read the XSD schema once (the compiler) and generate control information that just knows how to encode/decode the messages in either XML or BER, or PER etc. with the same static control information. There is no need for the device to do the X.694 translation on the fly. Next, in figure 2 - first sending schema using ASN.1 (+encoding) followed by sending instance document using ASN.1(+encoding) - seems little odd. In legacy WSDL/SOAP , isn't the receiver expected to feed the schema to the XML parser? In either case, both figures seem to imply that the server and client applications still use XML (DOM/SAXP) - it is only for the purpose of using ASN.1's efficient encoders - BER/PER etc that the conversion from XML to ASN.1 and vice versa is done. Is my understanding correct? Also, would XER (XML Encoding for ASN.1) then not be relavent for FWS? I did get some response from Mr Thorpe and Mr Leg for this: [slegg] XER is relevant for FWS implementations that use an ASN.1 compiler rather than DOM or SAX. If there is a need to interwork with a client or server that is not enabled for FWS then an XER encoder can be used to produce the XML representation of a document. [Thorpe] WS would use one of the binary encoding rules of ASN.1, but a Web Service should fall back to use of XML if its peer does not understand the compact binary FWS encodings. Finally - ASN.1 schema notation for XML - I think it looks quite verbose and difficult to read compared to XML schema. Do you think my view is reflective of some others ? If so, any comments?
