[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: UBL payload and client-server integration tools
Stephan et al:
I am leveraging your note regarding UBL payload, but in a somewhat different
context - hence the different subject line. The parallel with your note is
that there are various ways to leverage the payload IP of UBL, even though
the middleware and transport would be something different.
As is widely known, there are various tools and techniques used to recreate
client-server selective updates, under the rubric "rich internet
applications" (RIA). For example Adobe's Flash brings back 1990's style
field-at-a time-update/validation with "Flash Remoting." Flash is certainly
not the only RIA option, but it holds some high ground because of the
ubiquity of Flash agents.
For reference, see http://www.amfphp.org, which is the home page of an open
source Flash Remoting gateway. As it happens, the example shown on that page
is a configuration-style order transaction for pizza. Presumably, as the
user adds or deletes ingredients, the client-side software updates the price
and perhaps validates the feasibility of the pizza, via calls to the server.
Given that client-server responses need to flow consistently with the user's
thought processes and rate of data input, RIA proponents are concerned about
performance and therefore prefer binary data transfer rather than text and
cannot afford a lot of XML overheads.
As RIA tools become more commonplace and accepted, thousands of programmers
will use RIA calls to create or to consume what are or should be UBL
transactions. Unfortunately, designers in the RIA world tend to be unaware
of any of the relevant payload standards or are dismissive of those
standards because they do not see a way to achieve high performance with
text. There is also the issue that for RIA there may be a marked preference
for dealing with a UBL transaction in pieces rather than as an entire
document - e.g., call for the deliver-to address first to see if the vendor
even wants to consider this order.
What are the implications of fairing UBL into RIA architectures?
One proposition would be to repackage UBL for RIA client-server use. Doing
so is particularly helpful in avoiding a downstream need to translate some
ideosynchratic ad hoc transaction design into something useful to the other
party to the transaction.
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.
It is still early days for RIA, but perhaps not too early to consider the
implications for UBL and other Oasis standards.
Fulton Wilcox
Colts Neck Solutions lLC
-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk]
Sent: Thursday, November 09, 2006 3:51 AM
To: Stephen Green; ebxml-dev@lists.ebxml.org; ubl-dev@lists.oasis-open.org
Subject: RE: [ubl-dev] A UBL Customisation (beta) for general use
Offlist I was reminded that assimilation of the payload
is the key consideration here so I guess we're talking
fast infoset for the binary so as to allow the payload
to be treated similarly to XML for those used to XML
but for those receiving messages who already have
telecoms technology then other binary formats may
be appropriate.
Stephen Green
>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 08/11/06 16:23:14
>>>
Hi David,
Is this confusing ASN.1 and AS2?
I think the use of ASN.1 would be non-XML payloads using one of
several binary formats which rely on a schema written not in XSD
but in ASN.1 notation (though mappable to XSD). It gives the
advantage of preformance and/or small size and allows greater
compression than with .zip or .gz, I believe. I think it predates
XML in its use in the telecoms industries but nicely complements
XML now that the latter is at the fore. So we are here talking
payload, but with some bearing on other layers perhaps. And
I guess what I'm after is any info on whether/how ebXML layers
might need adapting to cater for it (e.g. I guess the list of schema
formats in the ebBP references to schema type won't include 'asn.1'
so implementers might have to use 'other') - plus any general
stories about successful use or otherwise of the ASN.1 provisions
in UBL - either with ebXML or otherwise. Would, in fact, it be
prudent/advantageous to use ASN.1 with ebXML? Or - a key
question - is there already a preferred framework used with such
binary payloads? I haven't come across any previous questions
about this on these lists so maybe this is still virgin ground. It
could be important for large files though.
All the best
Stephen Green
>>> "David RR Webber (XML)" <david@drrw.info> 08/11/06 15:32:29 >>>
Stephen,
I just noticed this post. This week on the Hermes 2 dev list - some
people are looking to use Hermes 2 as
a bridging server.
Basically Hermes 2 is pluggable - and supports both ebMS and AS2 - so it
can talk on either channel.
You'd have to have something in between to extract payload and then
repackage it - but I suspect all the parts are there to make it so.
Cheers, DW
-------- Original Message --------
Subject: Re: [ubl-dev] A UBL Customisation (beta) for general use
From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
Date: Thu, November 02, 2006 11:44 am
To: <ebxml-dev@lists.ebxml.org>, <ubl-dev@lists.oasis-open.org>,
<stephen.green@systml.co.uk>
By the way, folk might note, following on from UBL's packages,
we included a set of ASN.1 schemas for our subsets.
Has anyone actually managed to implement UBL with ASN.1
and are they able to comment on their experience of this?
I'd be especially interested to know what might be involved
using ASN.1 with ebXML, such as ebMS. Is it feasible? I
suppose it would mean transforming the binary into MIME.
What would be the preferred binary format and how would
MIME handle it? What values would be in the ebXML artefacts?
Are there any products doing this?
All help appreciated.
All the best
Stephen Green
>>> <stephen.green@systml.co.uk> 01/11/06 15:07:10 >>>
I'm happy to say, on behalf of SystML, we have finished a beta
customisation of UBL versions 1.0 and 2.0 which is freely available
at
www.systml.co.uk/xml/
for use at your own risk. We hope you will provide feedback which
could go to us at
info@systml.co.uk
It was produced by SystML and by HavanaWave AG
(Sacha.Schlegel@HavanaWave.com).
Obviously, it being at the beta stage, it is subject to possible
change (though we'd bear in mind that we should consider possible
users when contemplating any change) and how you use it is up to
you provided you do so at your own risk. Maybe if this is all
sufficiently satisfactory we will find the means to preserve it,
long term, as it is (perhaps just changing the status to 'complete').
Zip packages are provided for those who prefer the possible extra
security of storing it locally (much as you would with the source
code of opensource, say).
I'm very grateful to all who've helped us with this project to get
it to this stage - to God and to colleagues : Thanks. :-)
All the best
Stephen Green
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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] | [List Home]