OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC