Title: some issues affecting header design
Jeff:
inline
-----Original Message-----
From: Jeff Turpin
[mailto:]
Sent: Friday, September 17,
2004 9:09 AM
To: Jacques Durand;
Subject: RE: [ebxml-msg] some issues
affecting header design
Comments
inline:
From: Jacques
Durand [mailto:]
Sent: Thursday, September 16, 2004 6:12
PM
To:
''
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.
Jacques
