[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
Yes, there is an effort to arrange a meeting on Wednesday Mar 12 with (some or all interested) of the OASIS ebXML groups. Melanie Kudela will coordinate with us. No time is set yet though. Dale -----Original Message----- From: Matthew MacKenzie [mailto:matt@mac-kenzie.net] Sent: Thursday, February 13, 2003 4:50 PM To: Dale Moberg Cc: duker.jp@pg.com; 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 Dale, My main concern was that this work may be carried out without any co-operation with some of the OASIS-resident ebXML teams. Given your explanation and trustworthy opinion, I will hold off judgement here until I can learn more. I assume this team will meet in San Diego? Regards, Matt Dale Moberg wrote: >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> >>> >>> > >---------------------------------------------------------------- >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