Re: [ebxml-dev] ebXML MS Headers and Application layer processing

[Patrick Yee <kcyee@cecid.hku.hk>]

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