[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
-----Original Message-----
From: duker.jp@pg.com [mailto:duker.jp@pg.com]
Sent: Wednesday, February 12, 2003 4:10 PM
To: ebXML Development; ebxml-msg@lists.oasis-open.org
Cc: Matthew MacKenzie; 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
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC