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

[Matthew MacKenzie <matt@mac-kenzie.net>]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature