[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] Fwd: Re: [ebxml-msg] FW: [ebxml-dev] ebXML MS Headers andApplication layer processing
Review and think about this. Regards, Marty >X-Apparently-To: martin_w_sachs@sbcglobal.net via web80104.mail.yahoo.com; >12 Feb 2003 13:58:55 -0800 (PST) >X-Track: 1: 100 >X-Originating-IP: [128.103.219.45] >Date: Wed, 12 Feb 2003 13:57:11 -0800 >From: Matthew MacKenzie <matt@mac-kenzie.net> >Subject: Re: [ebxml-msg] FW: [ebxml-dev] ebXML MS Headers and Application >layer > processing >To: duker.jp@pg.com >Cc: ebXML Development <ebxml-dev@lists.ebxml.org>, > ebxml-msg@lists.oasis-open.org, Robert.Miller@gxs.com, > Patrick Yee <kcyee@cecid.hku.hk>, Fraser Goffin <goffinf@hotmail.com>, > ECE - Communication with Applied Technology Group > <cefact-atg@list.unicc.org> >X-Accept-Language: en-us, en >User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) > Gecko/20021130 >List-Owner: <mailto:ebxml-msg-help@lists.oasis-open.org> >List-Post: <mailto:ebxml-msg@lists.oasis-open.org> >List-Subscribe: <http://lists.oasis-open.org/ob/adm.pl>, > <mailto:ebxml-msg-request@lists.oasis-open.org?body=subscribe> >List-Unsubscribe: <http://lists.oasis-open.org/ob/adm.pl>, > <mailto:ebxml-msg-request@lists.oasis-open.org?body=unsubscribe> >List-Archive: <http://lists.oasis-open.org/archives/ebxml-msg/> >List-Help: <http://lists.oasis-open.org/elists/admin.shtml>, > <mailto:ebxml-msg-request@lists.oasis-open.org?body=help> >List-Id: <ebxml-msg.lists.oasis-open.org> > >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> > > ************************************************* Martin W. Sachs email: m.w.sachs@post.harvard.edu phone: 203-226-0524
Attachment:
smime5.p7s
Description: application/pkcs7-signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC