[ubl-comment] FW: [CEFACT-ATG:131] RE: [ebxml-msg] FW: [ebxml-dev]ebXML MS Headers and Application layer processing

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

Passed back to the UBL list as there is a reference to UBL.

Mark

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Thursday, February 13, 2003 1:15 PM
To: ECE - Communication with Applied Technology Group
Cc: ebXML Development; ebxml-msg@lists.oasis-open.org;
Robert.Miller@gxs.com; Patrick Yee; Fraser Goffin; ECE - Communication
with Applied Technology Group
Subject: [CEFACT-ATG:131] RE: [ebxml-msg] FW: [ebxml-dev] ebXML MS
Headers and Application layer processing


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



-----Original Message-----
From: Matthew MacKenzie [mailto:matt@mac-kenzie.net] 
Sent: Wednesday, February 12, 2003 2:57 PM
To: duker.jp@pg.com
Cc: ebXML Development; ebxml-msg@lists.oasis-open.org;
Robert.Miller@gxs.com; Patrick Yee; Fraser Goffin; ECE - Communication
with Applied Technology Group
Subject: Re: [ebxml-msg] FW: [ebxml-dev] ebXML MS Headers and
Application layer processing


John,

I certainly hope you folks aren't duplicating the years of work we've 
done on CPPA and ebMS.  I suggest you look at how ebMS meshes with CPPA 
very closely, and also examine the ebMS manifest.

-Matt

duker.jp@pg.com wrote:

>
> All,
>
> The UN/CEFACT Applied Technologies Group (ATG) and the EAN.UCC
> eCommerce Global Implementation Forum (ecGIF)  are developing a 
> "Standard Business Data Header" that will address some of the "Message

> Service Interface" issues you discussed. The concept will allow 
> application message handlers to process and route messages in a data 
> driven fashion, based on standard information in the Header (which 
> would be contained in the body of the message). The objective is to 
> develop a conceptual Header that is syntax and data format 
> independent; however the initial emphasis is on XML messages.
>
> The standard information would include logical data elements (known to
> back-end applications and/or transformation applications) such as 
> "Sender", "Receiver", "Document Type", "Unique Message Reference", and

> "Creation Date/Time". This standard information would be related to 
> but different than the physical data elements contained in the actual 
> communications transport envelope of the message. So for example, an 
> XML instance document would contain the "Standard Business Data 
> Header" and the values in the Header could be used by the outbound 
> communications infrastructure to determine the destination and what 
> communications protocol to use.
>
> Because this Header information will be in a standard format,
> different implementations using different architectures and 
> combinations of applications all can utilize the information to make 
> routing and processing decisions. Thus the sending and receiving 
> organizations have the flexibility to choose the best approach for 
> their situation,  independent of what approach their counterpart
chooses.
>
> So taking an XML instance document containing a "Standard Business
> Data Header" through the various processes would look like this:
> 1. An XML instance document containing the Header is created.
> 2. The outbound communications application can do a high level parse 
> of the XML for the Header data tags (or acquire the information via an

> API). The communications application can then determine (e.g. via 
> table look-up) the physical destination and the communications 
> protocol to use to send the XML document.
> 3. The receiving (inbound) communications application can do a high 
> level parse of the XML looking for the standard Header data tags. 
> (Because the Header format is standard, contained in the XML instance 
> document, and independent of the communications protocol used, the 
> information is easily found, regardless of what communications 
> software the sender used.) Based on the tag information, the 
> communications application can determine where to route the XML 
> instance document (e.g. one of several transformation applications, or

> an XML-capable back-end application).
> 4. A receiving transformation application can further use the standard

> Header to determine which "map" to invoke to transform the XML 
> instance document into the appropriate internal data format.
>
> Any interested individuals are invited to join our discussions.
>
> John Duker
> Document Editor, UN/CEFACT ATG Generic Header project & co-chair, 
> EAN.UCC e-Commerce Global Implementation Forum
>
>
>
> *Matthew MacKenzie <matt@mac-kenzie.net>*
>
> 02/12/2003 12:21 PM
>
>        
>         To:        ebxml-dev@lists.ebxml.org
>         cc:        (bcc: John Duker-JP/PGI)
>         Subject:        Re: [ebxml-msg] FW: [ebxml-dev] ebXML MS 
> Headers and Application layer processing
>
>
> Gentlemen,
>
>  >From my ebxml-msg point of view, any definition of how the message 
> is passed onto the application is out of scope from the point of view 
> of the ebMS specification.  What is important, specification wise, is 
> that the protocol is followed closely by the MSH.
>
>  >From my practical point of view, I think implementations should pass

> envelope details to the application along with the payloads, just to 
> give the application more flexibility during processing.  On the 
> outbound side, the application should be allowed to request overides 
> of envelope resident variables, and the MSH would honour those 
> requests if its CPA or generic configuration allowed it.  In other 
> words, inbound message details should be supplied in a read-only 
> format, and outbound message details should be writable with no 
> guarantees (only to be applied if their invocation matches a 
> "PerMessage" value in the CPA). This allows for a clean separation of 
> responsibilities with regard to maintenance of agreements (CPA) and 
> development of services & applications.
>
> BTW -> These opinions are formed through trial and error!
>
> As an aside...
>
> I also have a strong view regarding how much visibility the 
> application layer should have of the CPA/config layer.  In my opinion,

> the application _can not_ be given access to the CPA because that 
> would in some cases make it impossible to change the CPA details 
> without changing the service code.
>
> Best Regards,
>
> Matthew MacKenzie
> Document Editor, ebxml-msg
>
> Miller, Robert (GXS) wrote:
>
> >
> >
> > -----Original Message-----
> > From: Patrick Yee [mailto:kcyee@cecid.hku.hk]
> > Sent: Wednesday, February 12, 2003 2:26 AM
> > To: ebxml-dev@lists.ebxml.org
> > Cc: Fraser Goffin
> > Subject: Re: [ebxml-dev] ebXML MS Headers and Application layer 
> > processing
> >
> >
> > We have the same question. The specification have not covered how 
> > the MSHs deliver received messages to applications. Only an abstract

> > term
> "Message
> > Service Interface" is mentioned. I guess the intention of the TC is 
> > to leave it implementation dependent, as generally there is no need 
> > to
> standardize
> > the application integration interface.
> >
> > On one hand, we think the application should not bother to touch on 
> > ebMS headers. Ideally, the application should deal with payloads 
> > only. On the other hand, we face the same problem as Fraser, the 
> > application may need some information from ebMS for payload 
> > processing. Conversation ID is a good example, there might be more, 
> > depending on how the Message Service Interface
> > is implemented.
> >
> > Another similar issue is error reporting. There may be some error 
> > messages related to application. Should the MSHs deliver those error

> > messages to the
> > applications as well. For example, if there is MIME problem in
> > payload, the
> > receiving MSH may generate ebMS error message to the sender. Should
the
> > sender MSHs inform the application of such event so that the
> > application can
> > take appropriate action to eliminate the error?
> >
> > What do you think? Would some ebMS experts please clarify?
> >
> > Regards, -Patrick
> > --
> > Patrick Yee
> > System Architect
> > Center for E-Commerce Infrastructure Development (CECID) Dept. of 
> > Computer Science and Information Systems The University of Hong Kong
> > Tel: (852) 22415674
> > Fax: (852) 25474611
> >
> >
> > ----- Original Message -----
> > From: "Fraser Goffin" <goffinf@hotmail.com>
> > To: <ebxml-dev@lists.ebxml.org>
> > Sent: Wednesday, February 12, 2003 12:31 AM
> > Subject: [ebxml-dev] ebXML MS Headers and Application layer 
> > processing
> >
> >
> > > Should application message handlers ever need to refer to ebXML
> > headers or
> > > are such headers regarded as information that is targeted at 
> > > protocol handlers that perform non application specific tasks such

> > > as
> > authentication
> > > or routing (i.e. the ebXMLMS protocol handler) ?
> > >
> > > If when designing a SOAP service the same piece of data is
> required for
> > > application and non application specific purposes, should it be
> > carried in
> > a
> > > SOAP Header AND as part of the SOAP Body payload ?
> > >
> > > An ebXMLMS example :
> > >
> > > As a service provider I decide to use the ConversationId of the 
> > > MessageHeader header to relate a quote request to a quote response
> that
> > will
> > > be provided later (i.e. asynchronously). This ConversationId is 
> > > used
> > as a
> > > key to [say] a database row which will at some point contain the
> > response
> > > message and it is the application message service handler that
> goes and
> > > checks for it and returns it to the original caller.
> > >
> > > Is this reasonable, or does it smack of a poor implementation 
> > > which is muddling protocol level and application level data ??
> > >
> > >
> > > A general SOAP example:
> > >
> > > Say I pass authentication credentials as a SOAP Header (as 
> > > follows).
> > During
> > > the processing of this message, I perform the authentication step
> > extracting
> > > the credentials from the SOAP header and passing to an 
> > > authentication process. If authentication is successful I call the

> > > service specific
> > message
> > > handler and use the authentication UserID as a lookup for other
> > information
> > > (say a commission rate). Would you expect the UserId data to 
> > > appear as
> > part
> > > of the payload definition as well ? :-
> > >
> > > <SOAP-ENV:Envelope xmlns:SOAP-ENV="..."
> > >   <SOAP-ENV:Header>
> > >     <frg:Authentication xmlns:frg="some-uri">
> > >       <frg:UserId>0123456789</frg:CustomerRef>
> > >       <frg:Pwd>135246</frg:Pwd>
> > >     </frg:Authentication>
> > >   </SOAP-ENV:Header>
> > >   <SOAP-ENV:Body>
> > >     <ns1:myPayload xmlns:ns1="..."
> > >     ...
> > >
> > > Regards
> > >
> > > Fraser.
> > >
> > > _________________________________________________________________
> > > Stay in touch with MSN Messenger http://messenger.msn.co.uk
> > >
> > >
> > > ----------------------------------------------------------------
> > > The ebxml-dev list is sponsored by OASIS.
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.ebxml.org/ob/adm.pl>
> > >
> >
> >
> > ----------------------------------------------------------------
> > The ebxml-dev list is sponsored by OASIS.
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.ebxml.org/ob/adm.pl>
>