[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-dev] Re: [ubl-dev] UBL payload and client-serverintegration tools
Thanks Pim for pointing to this excellent article. I guess there may be problems with implementation though - hence a request for any interesting notes about anyone's experience with this. For example: 1. How do firewalls cope with the binary rather than the XML text? 2. To quote the article "Fast has to work well with existing Web Services standards and APIs so that there is minimal impact on the developers. A developer should not have to maintain two code bases with different APIs for the same Web Service, nor should (s)he have to define two different Web Service contracts for any particular service. Ideally, a developer should be able, at the flick of a switch, to specify: "I want my service to go Faster when talking to Fast-enabled peers." - how does use of ebXML fare with this? Would it not be necessary to have a different CPA for 'Fast'? Hence that might make the 'just flick a switch' ideal a bit of a challenge. Of course it's just early days in standards terms and in terms of tools support such as in Java, by the looks of things. Many thanks Stephen Green >>> "Pim van der Eijk" <pim.vandereijk@oasis-open.org> 13/11/06 18:00:05 >>> Hello Stephen, There is some related work called "Fast Web Services": http://java.sun.com/developer/technicalArticles/WebServices/fastWS/ This seems compatible without any special effort with ebMS 2 and 3 when used to encode attachments stored as MIME parts with a special "application/fastinfoset" MIME type. Packaging information in the CPA can reference this too. A more drastic approach would be to encode the ebXML SOAP envelope in this binary format. In ebMS3 an application payload can be in a SOAP body, so the UBL payload stored as subelement of the SOAP envelope would be in this compact format too. This would probably require some changes to some core parts of the ebXML Messaging version 3 spec, but nothing essential. In ebXML, we would not need the "optimistic"/"pessimistic" HTTP Accept-based negotiation mentioned in http://java.sun.com/webservices/docs/1.6/jaxrpc/fastinfoset/manual.html as the partner-agreed result of negotiation could be in set in the CPA. The main benefits of compact formats are support for environments where bandwidth is scarce or expensive, such as mobile environments, or where very large XML messages are exchanged. For UBL, I'm not sure either of these conditions apply. Pim van der Eijk Register for OASIS Adoption Forum 2006: Enabling Efficiency between Government, Business and the Citizen 27-29 Nov 2006, London www.oasis-open.org/events/adoptionforum2006/ -----Original Message----- From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] Sent: 13 November 2006 15:28 To: ebxml-dev@lists.ebxml.org; ubl-dev@lists.oasis-open.org Subject: [ebxml-dev] Re: [ubl-dev] UBL payload and client-server integration tools Chee-Kai / Fulton, Thanks for opening up the view of the possible applications for the use of binary parallels to XML here. We could view the XML and the XML Schema (XSD) as the theory (essential as such) and the binary as the practical. Another analogy might be to view the XML/XSD as the score and the binary as the audible music but the binary 'sings' not to the score but to an adaptation of the score by its use of the ASN.1 equivalent of the XSD. So we need to have the practice of composing the score, then having it adapted, then reading the adaptation and turning it into music; in other words, architecting the schemas in XML Schema, turning those into ASN.1 (as UBL does) and using the ASN.1 optionally to determine the content of binary messages (for various reasons such as interoperability improved compres- sion). Making this 'standard practice' seems to me to offer the optimal (by current state of art) solution for messages, whether for RIA or for modern equivalents to the traditional uses of EDI or to whatever is just around the corner. It's looking good. It seems to closely parallel the standard practises of coding software quite nicely so it should be very easy for developers and information architects to understand. First the text, then the compilation to binary. Here we have first the message composition and the message equivalent of the source code which is kept for posterity and maintenance, then we have the binary equivalent which is actually used at runtime. All the best Stephen Green >>> Chin Chee-Kai <cheekai@SoftML.Net> 13/11/06 05:25:55 >>> At 06:58 PM 2006-11-09 -0500, Fulton Wilcox wrote: >Stephan et al: > >What are the implications of fairing UBL into RIA architectures? >..... >The second is to consider use of RIA techniques within the more typical >eBusiness server-to-server exchange of transactions. RIA calls are >built for speed and light touch on bandwidth, so the fit would be to >highly repetitive transactions - e.g., price checks, inventory >availability checks, transportation scheduling, etc. > Fulton Wilcox > Colts Neck Solutions lLC Very interesting thoughts about RIA & the "built for speed and light touch" stuff. I'm much delighted to hear about this conversation. I don't know much about RIA stuff, but do think the "speed and light touch" aspect is interesting to explore for UBL. From UBL instances' perspective, this could either be viewed or translated as (A) an encoding problem, or (B) a translation problem. One could use specifications from binary XML to do (A) with significant reduction in textual bytes in the instance payload. But I suspect RIA is going for the really highly interactive sort of communication environment and might need a more rudimentary (B) solution. In a way, while UBL TC produces schemas as normative output, there's no limitation that the instances cannot be mapped and stored in another manner. One quick thought that comes to mind is to assign a UBL-wide unique ID to each and every BBIE, ABIE and ASBIE, using possibly a 16-bit word and values being assigned authoritatively only through/by UBL TC. Structural composition of the BIEs could be easily done through usual header/trailer byte style, or header-fixed-length packets. Best Regards, Chin Chee-Kai SoftML Tel: +65-6820-2979 Fax: +65-6820-2979 Email: cheekai@SoftML.Net http://SoftML.Net/ --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]