OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [ubl-dev] UBL payload and client-server integration tools

Thanks David

David wrote:
"Now if you have different ports on your server depending on the
packaging - that's a different story - then its easy for the partner to
connect to the right port depending on his needs. "

That sounds like an excellent idea and probably near enough to the
'just throw a switch' concept.

I guess using the binary as a MIME attachment too is as far as tools
might reliably support with ebXML for now too. Once tool support 
improves it might be that ebMS TC opts to produce ASN.1 schemas
as well as the W3c XML Schemas as part of the package like UBL does

All the best


>>> "David RR Webber (XML)" <david@drrw.info> 14/11/06 14:26:11 >>>
To me this is nothing more than FAX 3, 2, 1 - you negoitate at the
highest speed and then drop back from there till you find a connection
the partner will accept. 
I'm not sure this happens at the CPA level though - its at the
communications firmware / connection negiotation below that.  All the
CPA cares about is a stable connection. 
Now if you have different ports on your server depending on the
packaging - that's a different story - then its easy for the partner to
connect to the right port depending on his needs. 
I would suggest that would be the best path.  In which case you have
deltas of your CPA - with different port #s in the endpoint URL -
depending on the service you want - and that descreet CPA is stored on
the system where needed - cellphone, PDA, etc. 
Remember the binary can travel as binary attachment with the regular
ebMS enveloping - we're doing that already.  Plus - you can selective
break the payload into parts - so you have a staged delivery -
push/pull model - where the low bandwidth connection retrieves the
summary of available packages first - then requests more later - or
routes those requests to higher bandwidth service. 

 -------- Original Message --------
Subject: [ubl-dev] UBL payload and client-server integration tools
From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
Date: Tue, November 14, 2006 5:56 am
To: <ebxml-dev@lists.ebxml.org>, <ubl-dev@lists.oasis-open.org>


Rushing too much

read "don't have ADSL or cable modem" - I hope you know what I mean

>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 14/11/06 10:45:57 >>>
I meant instead of "don't have much more than cable modem..."
"don't have more than ADSL modem" :-)

>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 14/11/06 10:42:15 >>>
Another consideration the article doesn't mention so much
is situations where bandwidth may still be a limiting factor -
such as when a large number of people use WiMax in a
particular area or the fact that much of the world still
doesn't have more than cable modem internet access.
Others still don't have TCP. So here there might be a good
application with websites such as those with interactive


>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 14/11/06 10:15:15 >>>
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":

This seems compatible without any special effort with ebMS 2 and 3 when
to encode attachments stored as MIME parts with a special
"application/fastinfoset" MIME type. Packaging information in the CPA
reference this too. 

A more drastic approach would be to encode the ebXML SOAP envelope in
binary format. In ebMS3 an application payload can be in a SOAP body, so
UBL payload stored as subelement of the SOAP envelope would be in this
compact format too.  This would probably require some changes to some
parts of the ebXML Messaging version 3 spec, but nothing essential.  

In ebXML, we would not need the "optimistic"/"pessimistic" HTTP
negotiation mentioned in
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
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

-----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

Chee-Kai / Fulton,

Thanks for opening up the view of the possible applications for the use
binary parallels to XML here. We could view the XML and the XML Schema
as the theory (essential as such) and the binary as the practical.
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
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
UBL does) and using the
ASN.1 optionally to determine the content of binary messages (for
reasons such as interoperability improved compres- sion). Making this
'standard practice' seems to me to offer the optimal (by current state
art) solution for messages, whether for RIA or for modern equivalents to
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
nicely so it should be very easy for developers and information
to understand. First the text, then the compilation to binary. Here we
first the message composition and the message equivalent of the source
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
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
aspect is interesting to explore for UBL.

From UBL instances' perspective, this could either be viewed or
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
going for the really highly interactive sort of communication
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
each and every BBIE, ABIE and ASBIE, using possibly a 16-bit word and
being assigned authoritatively only through/by UBL TC.ipar Government,
Business and the Citize
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
Tel: +65-6820-2979
Fax: +65-6820-2979
Email: cheekai@SoftML.Net 

To unsubscribe, e-mail: st-server integration
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org 

To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org 
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org 

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]