[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
We here ni Moscow are waiting for results :-)
>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/
>
>
>----------------------------------------------------------------
>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>
--
Regards
P bI K O B B. B. MOCKBA
Vladimir Rykov, PhD in Computational Linguistics,
MOSCOW
http://rykov.narod.ru/
Engl. http://www.blkbox.com/~gigawatt/rykov.html
Tel +7-903-749-19-99
--
Сегодня удачный день, чтобы завести почту на Яндексе (http://mail.yandex.ru)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC