[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] MOU on intermediate support by conformance profile and other auxiliary documents for ebMS 3.0
Some comments in bold
green.
Pim From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] Sent: 29 May 2008 04:48 To: Pim van der Eijk; Moberg Dale; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] MOU on intermediate support by conformance profile and other auxiliary documents for ebMS 3.0 Pim:
as discussed today, we have two solutions to pick from,
none of them being a clear win...
Let me just try to alleviate some of the drawbacks you see
to WS-addressing: From: Pim van der Eijk [mailto:pvde@sonnenglanz.net] Sent: Wednesday, May 28, 2008 2:02 PM To: 'Moberg Dale'; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] MOU on intermediate support by conformance profile and other auxiliary documents for ebMS 3.0 Here are some reasons why I would prefer to use ebMS headers for routing rather than WS-Addressing Reference Parameters: Conformance to v3.0 Core The ebMS 3.0 Part 1 Core does not specify the use of WS-Addressing. Avoid yet another standard to
support Requiring support for WS-Addressing in a multihop context adds a burden to implement ebMS 3.0 in general and the multihop profile in particular.It is also true that the counterproposal requires adding ebMS headers in some situations where v3.0 Core does not require them, but any ebMS 3.0 implementation needs to know how to construct or handle ebMS 3.0 headers anyway, so this is just a reuse of that general functionality. 1) Yes, 1.6.2/1.6.1 of
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document_id=28337 is about on reverse routing of errors. If people see
errors in the proposed mechanism, please let me
know.
2) Errors are generated for user messages, are you
suggesting to use WS-Addressing for ordinary user messages too and not just for
WS helper messages?
- we still have the problem of routing eb:Signals (Receipts, Errors) that originate from the ultimate receiver. Although we can generally assume the eb:header of the related User message can be used for reverse-routing of these, I feel more comfortable with an alternate capability that allows for different routing data including a direct URL when possible (in same way as wsrm:AcksTo does for RM Acks). wsa:ReplyTo and wsa:From support this. Let me repeat that my use cases for multihop are
communities where direct URLs don't ever work. We can't even assume a DNS.
- what if some User messages have new header data that are intended to the same MSH as others, but for which I-Cloud routing functions have not yet been updated (e.g. a business partner behind a MSH decides that its sub-departments will now have their own PartyId). I like the idea that one can still reuse an old EPR data that is known to route properly, assuming that when both wsa ref param headers AND eb:header are present, routers look first at wsa ref param headers. I think the communities
that go through the trouble to deploy this type of sophisticated intermediary processing can be trusted to have
the ITIL service management processes in place to handle the right configuration
of routing tables. Some registry will be useful to
propagate routing information to intermediaries in the I-Cloud,
especially in large or very dynamic
communities.
Section 1.1.2 in http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document_id=28435.
Inconsistency If we start using WS-Addressing reference parameters in the multihop context, the question comes up why we did not use them in ebMS 3.0 Core. There are already elements in the ebMS header that are also in WS-Addressing, such as MessageId. Nevertheless, v3.0 Core does not use WS-Addressing even for these header fields, let alone use reference parameters for the information types that are in an ebMS 3.0 header but are not regular WS-Addressing field. I think the ebMS 3.0 header is richer than WS-Addressing header, so that this decision was right at the time. But even if it were not, I think a multihop profile should stick to the approach taken in v3.0 Core. I was just picking on MessageId as an example.
There is also wsa:To, wsa:Action. Even if there is a less precise match or
the ebMS 3.0 header has more information, those other/extra bits could have been
added as reference parameters too instead of in a separate ebMS structure.
Version 3.0 Part 1 for good or bad reasons decided not to but sticks to the ebMS
header. My concern is that I can't explain why Part 2 can't be consistent with
that approach.
Limited reuse It might look as if using WS-Addressing is an instance of reusing a more general specification instead of defining ebMS specific mechanisms. But unlike the reuse of WS-Security or WS-Reliability/WS-ReliableMessaging, this reuse is only a syntactic issue. We would just be adding information to some defined extension points in the schema. Any processing of that information would require ebMS-specific processing, rather than using generic WS-Addressing functionality. Any intermediary that provides WS-Addressing functionality and wants to conform to this profile would still need to have ebMS-specific functionality. <JD> But we could say as well that it is in the nature of wsa to be a "syntactic specification", i.e. unlike WS-RM or WSS it does not define precise mechanisms: only some mappings between EPR construct and header content, as well as some limited control of the HTTP binding and some cross-message correlation features. Now, besides the header aspect, the notion of EPR appears to be a convenient modeling construct that can be reused in PModes, and is able to wrap up all data needed for routing, with ref parameters. Duplication in message
structure Having to store or retrieve the same type of information in two different locations usually smells of missed generalizations, and I think that is true here too. We looked at putting the equivalent of an ebMS header in a URL (the earlier HTTP URL query parameters), I don’t find putting it in WS-Addressing parameters a lot more elegant. It also raises issue like how to handle any inconsistencies in situations where there is both a WS-Addressing structure and an ebMS header. Also, the WS-Addressing specification says that using reference parameters to store information that would otherwise be in other SOAP headers could cause “unintended or erroneous semantics in the resultant SOAP message". Generalized routing This is related to duplication. When using just ebMS headers, assuming routing is done on destination PartyId, any message (user, signal, WS-* helper, bundles, piggy backs) can be routed based on the single following XPath expression: S:Envelope/S:Header/eb3:Messaging/eb3:UserMessage[1]/eb3:PartyInfo/eb3:To/eb3:PartyId From: Moberg Dale [mailto:dmoberg@axway.com] Sent: 07 May 2008 23:14 To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] MOU on intermediate support by conformance profile and other auxiliary documents for ebMS 3.0 Yes, I agee that adding
metadata to ebMS signals or to other messages used in WS protocols is what
is agreed upon as a MOU item. The way or ways to do
this is apparently TBD J I think that since we
have several ways to attach the metadata, we probably want to prune these down
into a simple convention to do it in a standard
way. (Incidentally, would we
then provide CPPA support for these messages? Would they be treated as msh level
messages from the default packaging and delivery channel
standpoint?) From: Pim van
der Eijk [mailto:pvde@sonnenglanz.net] We agreed to add ebMS
metadata also to signals and helper messages. And we also looked in some
detail at one option for adding this metadata, by adding it to a WSA
header. Imo we did not fully compare this option to using a an
eb:Messaging header (containing an eb:UserMessage but one that has
no eb:PayloadInfo) to convey the ebMS metadata. I want to fully
understand both options and compare their pros and
cons. Unfortunately, due to travel I will not be able to attend next
week's meeting. Pim From: Moberg
Dale [mailto:dmoberg@axway.com] Goals Transparency where feasible Signature intact where feasible (important aspect of
transparency) WSI Conformance where feasible (especially with respect
to WSI RSP policy that WS-RX Reliable Messaging headers be signed, including
WS-Addressing elements where used within
ReliableMessaging) Spoke configuration to services within an I-Cloud should
have simplicity of configuration change management.
Specifically, rerouting to services (within the I-Cloud
) can be accomplished without spoke configuration
changes”) Hub service destinations and spoke clients have
“vanilla” ebMS 3 conformance where feasible. (Some specializations of general
functionality and of extension points is allowed.) Additional
Implicit Constraints The internal addresses within an I-Cloud can have
private IP addresses and DNS names that are not publicly reachable or resolvable
in the Internet. Proposed
Rerouting by intermediaries can be based on ebMS
“metadata” both in forward and return paths. This functionality is referred to as a “table” mapping
ebMS metadata to next hop URLs so that the HTTP POST (or other?) command can be
rewritten. TBD: This map may be augmented for return
paths by keeping a map involving Message-Id and Relates-To values.
For ebMS user messages, no special treatment is needed
(so far anyway). For ebMS signal messages and for WS clerical messages
(such as CreateSequence, CreateSequenceResponse, etc.) several approaches are
under consideration 1. Define a ebMS Reference Parameter that allows
the wsa attribute “isReferenceParameter” applied and that contains the metadata
needed for routing. 2. Allow use of WS-Addressing headers such as
From or ReplyTo or FaultTo that have an EndpointReference model (and include
ReferenceParameter within the EPR). 3. For return path, if WS-Addressing Messaging-Id
was present in incoming message, require use of RelatesTo in response
message. 4. For using the request connection for a
response, some read-only access to ReplyTo is needed to check for the
“anonymous” URL value. In this case, all
intermediaries would be expected to hold the connection open (?) to allow the
final service to use the HTTP backchannel for its
response. For Pull MEP-binding, allow first intermediary to handle
MPC requests and let internal I-Cloud arrangements for this option be
implementation specific. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]