Re: [ebxml-msg] FW: [ebxml-dev] ebXML MS Headers and Application layerprocessing

[Matthew MacKenzie <matt@mac-kenzie.net>]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature