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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: No Subject





OK, having a full in-basket this morning leads me to offer some
observations:
1.   I think we're entering a religious debate on XML purity for the ebXML
transport. I believe that the the performance implications of adopting a
pure approach is potentially
     unworkable. The purist approach says that there should be a single
root document per message with all the sub-parts of the message in XML. The
explosion in data   once binary data is UUENCODEd together with the need to
parse the ENTIRE message (SAX or DOM) means that any server implementing
this is going to perform      like a dog !! Coming up with a complete
schema that (potentially) allows multiple business objects or multiple
enveloped messages inside a single envelope is I        believe too complex
for this group to achieve in a respectable timescale. We have to come up
with a proposal that allows us to envelope different data components
which over the medium to long term will migrate to XML - though I believe
binary won't go away for a long time even with the expectations of XML
compression.
2.   What are we standardising on ? This section may appear to be rather a
political compromise argument !! Is our role to define the message
structure or the services (API     or otherwise) that the messages support
? If the second (services), then the message structure is hidden behind the
service definitions. The service definitions can then   support "pure XML".
The enveloping/structure of the message is then hidden behind the service
interface definition and gives us some flexibility in implementation. OK, I
     realise that the units of interchange are the messages themselves so
we do need to expose the structure - I did say this was a political
argument :-)
3.   We must support different transports. Email is going to be around for
a long time as well as fax and telephone. Businesses are going to use these
and we risk alienating
     communities if we adopt an inverse-Luddite approach and ignore them.

Fine, I guess I'll have another full in-basket tomorrow !!

Cheers,
John

MQSeries Technical Strategy & Planning,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: +44 (0)1962 815188
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC