[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
I would like to suggest that thsi be done in coordination with the joint meeting between Melanie's group and the UN/.CEFACT architecture group Tuesday between 1-3 PM in the architecture room. I suggest this since we are discussing the same issues. Dale - good to hear you're coming!!!! Duane Dale Moberg wrote: > 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> >> >> > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > -- VP Strategic Relations, Technologies Evangelist XML Global Technologies **************************** ebXML software downloads - http://www.xmlglobal.com/prod/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC