ebxml-msg — archive

RE: [ebxml-msg] FW: [ebxml-dev] ebXML MS Headers and Application layerprocessing

From: System
To: [email protected]
Date: Thu, 13 Feb 2003 13:18:00 -0000

 MHonArc v2.5.2 -->
















ebxml-msg message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








Subject: RE: [ebxml-msg] FW: [ebxml-dev] ebXML MS Headers and Application layerprocessing




From: Dale Moberg <[email protected]>
To: Matthew MacKenzie <[email protected]>, [email protected]
Date: Thu, 13 Feb 2003 11:14:37 -0700






Hi Matt,

I think that the UNCEFACT ATG effort on standardizing the semantic
elements of a Standard Business Data Header is best construed as leading
to defining an "in-line" form of MSI API.

That is, there is no IDL defining the MSI interface layers (both to and
from ebMS  and the Business Application). This proposal builds on
standard EDI practice (in the ISA and GS or UNB and UNH elements) of
providing information about the collaboration and payload (who is
involved, what is being done). Applications can then rummage through the
payload to find those elements that let them figure out what to do with
the data in a potentially standardized way. So, for example, an EDIFACT
syntactical binding for Standard Business Data Header already exists. An
XML schema and namespace for XML document types is one work item in the
ATG group. One hope is the UBL and OAGIS and similar projects will at
least leave room in their extensibility provisos so that the header
element information items can be inserted as needed or desired.

Obviously, there is much more to the MSI than just this-- relaying error
conditions, offering a status inquiry service, notifying of data
arrival. This is just a measure that allows XML defined documents to at
least support inter-protocol-stack layer interfacing and integration
that is no worse than what is available with EDI.

Presumably, eventually, out-of-band (RPC or local call) IDL
specifications for MSI will allow for cleaner integration options.

I think this project is largely orthogonal to CPPA myself. 

Dale Moberg