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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg 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


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