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: FW: [ebxml-dev] ebXML MS Headers and Application layer processin g


Good People,
 
I forwarded two messages on this topic to the ebxml-msg@lists.oasis-open.org list.  Here is one response I received with request to forward to the ebxml-dev list.  Those of you who can post to both lists should do so on this topic, as I am not the most reliable of middle men (I'm semi-retired, and have long absences form the office.
 
Cheers,
              Bob Miller
-----Original Message-----
From: Matthew MacKenzie [mailto:matt@mac-kenzie.net]
Sent: Wednesday, February 12, 2003 10:46 AM
To: Miller, Robert (GXS)
Cc: ebxml-msg@lists.oasis-open.org; goffinf@hotmail.com; kcyee@cecid.hku.hk
Subject: Re: [ebxml-msg] FW: [ebxml-dev] ebXML MS Headers and Application layer processing

[Please forward to ebXML-Dev]

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>



[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