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

Subject: RE: [ebxml-msg] some issues affecting header design

Title: some issues affecting header design
Jeff: inline
-----Original Message-----
From: Jeff Turpin [mailto:jturpin@cyclonecommerce.com]
Sent: Friday, September 17, 2004 9:09 AM
To: Jacques Durand; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] some issues affecting header design

Comments inline:


From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Thursday, September 16, 2004 6:12 PM
To: 'ebxml-msg@lists.oasis-open.org'
Subject: [ebxml-msg] some issues affecting header design


A few topics that need be discussed and that directly affect the header design:

1. ebMS MEPs:
- We have outlined 3 MEPs (ebMS One-way, Request-response, Pull). The message ebMS header needs to indicate somehow:
(a) which type of MEP it belongs to (includes whether the MEP is synchronous or asynchronous),

[JWT] Currently we have a SyncReply element to indicate whether the ebXML message requires a synchronous reply. In addition if CPAs are used, the CPA will indicate what type of synchronous reply is requested (mshSignalsOnly, responseOnly, signalsAndResponse, signalsOnly, none). Is your proposal to enhance the current SyncReply element? 
[Jacques Durand] I suspect that "syncReply" may be too low level, and we might have to support an MSH behavior specific for Request-response MEPs that may be independent from whether this MEP is synchronous or async. I'll try to clarify this concern in a separate email. (beside this, I note that all the syncReply options listed in ebMS 2.0 will have a constrained relationship with reply patterns of WS-R: )

(b) which role the message plays in the MEP (e.g. an asynchronous response),

[JWT] Is it really necessary to indicate within the message, what stage of an MEP the message is in? Currently the Role/Service/Action of the ebXML Message describe what stage of the business process the message is in. This coupled with the RefToMessageId/ConversationId elements gives a fairly accurate picture of the current state of the business process.
[Jacques Durand] possibly (b) can be resolved by (c)  below. And possibly we don't need an explicit mention in the header for this. But I would consider Role/Service/Action as relevant to business process, and not appropriate to define an ebMS MEP (should not have ebMS semantics). This said, nothing would prevent a BSI to decide that such and such Bus transactions will map to such ebMS MEP, and therefore the MSH services associated with this MEP can be interpreted at BSI level as having BSI semantics (e.g. timing of the MEP in case we support this.., )

(c) which MEP instance the message belongs to (may be concretized by a RefToMessageId link, in which case
the role of RefToMessageId would have to be refined).

2. Reliability info in ebMS header:
- the WS-Rel header will already have RM requirements for Request / One-way messages,
so no need to duplicate these in ebMS headers.

[JWT] Given the SOAP processing model, it is not guaranteed that the WS-Rel headers will be made available to the MSH. Do we want to mandate in our spec that these headers be made available to the MSH?
[Jacques Durand] Right, it would be constraining if we do so. But here my assumption does not go that far: on Sending side, RM info will be fed to the RMP in a way that is independent from ebMS message header (e.g. implementation specific, via API, etc.). On Receiving side, the MSH (or processor of ebMS headers) does not have to be aware of any RM info, which would be handled by RMP. So unless for some reason we need some RM awareness beyond the RMP, I do not see a need for RM info in ebMS headers (besides a pointer to the CPA)

If reliability of responses (both in Request-response MEPs, and in "pull" MEP) is supported,
this new RM info is likely to be out of  WS-R headers (because not supported in current WS-R,
and extension mechanism would not help if the consumer of this data is ebMS MSH)
- Will this RM info have to appear (i) in ebMS header of the Request or (ii) of the Response or (iii) both?
I tend to favor (i) or (iii).
- Another simpler alternative could also be: the reliability level of a (synchronous) ebMS Response
is automatically the same as of its Request. (e.g. if a Request has guaranteed deliv + dupl elim, so has its Response)
That way, no need for extra RM info.

[JWT] I agree that the reliability of a synchronous response is in part tied to the reliability of the request. So for example, if the sync response is lost or for some reason not received by the Sender, the Sender will resend, and the Receiver will respond with the original sync response that it had previously attempted to send( from it’s cache). This scenario is assuming DuplicateElimination functionality as described in the version 2.0 spec. I would prefer to avoid extra RM info if possible, however, I feel we need to analyze the reliability of responses in a bit more detail to identify any gaps.
[Jacques Durand] Right. However, even if we tie the reliability of responses to the reliability of corresponding requests, the MSH will need to have a minimum of info to do its part. For example,  the response caching (in MSH) on Receiving side depends on whether the Request had guaranteed delivery or not. So the MSH will have to be aware of that, and preferably not through WS-R headers. Similarly, a Sending MSH will have to be aware that duplicate elimination was needed, so it can implement the duplicate elimination of (synchronous) responses. On Sending side, CPA will give this info. On Receiving side, either some explicit info in ebMS header, or CPA access would do it.

3. CPA configuration:
- An important decision that will affect message header design is where the agreement (including Reliability contract)
needs be configured (Sender only vs. Sender+Receiver)
The aproach in current WS-R, is the Sender only needs be configured. If we keep this approach, then a Receiver will only need

to obtain CPA info from message header. This is not currently the case in ebMS 2.0.
Could that be achieved at least for messaging functions? Need to evaluate the value of this.
There seems to be some exception with security info (e.g. certificates).

[JWT] IMO the CPA(or similar mechanism) should continue to define the entire messaging(RM, transports, security, etc.) contract between two parties. I would like to discuss this further since this topic has been debated often in the past.
[Jacques Durand] I only mention here a property of WS-R that we may or may not want to extend to ebMS.

4. The "pull" (or pop) ebMS MEP:
 It has similarities with a publish-subscribe mode. What should the granularity of the channel be?
"To" Destination? destination URL? within these, a conversation ID?
Also, in case no message is available (yet) on Receiver, what should be the behavior
for sending a response: wait until a response is available (asynchronous)? wait for a timeout (synchronous)?
return an empty response? should that polling be transparent to the requesting party (app level), meaning initiated
automatically by MSH?

[JWT] IMO, in the synchronous case, if no messages are available, then the receiver should either respond with some sort of status message that indicates there are no messages available, or simply close the transport session (HTTP 200 OK for example). As for asynchronous, we could also use this status message to indicate to the requesting MSH how many messages are available and will be sent asynchronously. Or the sender can simply fire the “pull” request and await any async messages the receiving MSH has available. This might not be the best way to accomplish this but it is one alternative. Also, IMO the polling should be transparent to the App, it should be something that is automatically initiated by the MSH based on some configuration parameter.

5. Message identity:
do we need an identity in addition to RM identity. That is still unclear.
Implementation aspects (which MSH+RMP architectures will/not handle a single indentity?) need be considered.

[JWT] Although multiple identities(MessageIds) in the Message would seem redundant and confusing, it might be necessary to correlate messages within an MEP at the MSH level. However, you are correct, this is still unclear, and arguments can be made for and against this. We definitely need to discuss this further.
[Jacques Durand] I see one case where the MSH needs to correlate Response wirth Request . In case this is implemented with SOAP request-response MEP, we can assume the correlation is supported by the layer below. But depending on what kind of duplicate scenarios we expect, and whether we still want this correlation even for asynchronous ebMS Request-response MEPs, we may need a distinct ebMS ID. It also depends on the role we expect from RefToMessageId.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]