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:] 
Sent: 29 May 2008 04:48
To: 
Pim van der Eijk; Moberg Dale; 
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:] 
Sent: Wednesday, May 28, 2008 2:02 
PM
To: 'Moberg Dale'; 

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. 

 <JD> Right, although we know the use of RM (WS-RX) 
automatically requires some level of support to wsa. RM Acks need be routed 
based on the content of wsrm:CS/ AcksTo, which is an EPR. It will be expected 
this EPR has enough value to either directly send the Acks, or to route them. 
The associated ref parameters are supposed to be put in the header and are a 
natural fit for routing... All this was not so crucial for point-to-point 
exchanges where an "anonymous" value is expected most of the times in the 
AcksTo

Our 
engineering believes it is easier to do an "wsa extension" to a Core MSH 
vs. to add generating a (dummy) eb:header in some cases and is a bit cleaner 
from architecture viewpoint.

 

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. 

 <JD> WS-addressing support is greatly facilitated by current 
WS stacks which provide APIs to add / consume wsa headers. 

We 
need to look at the corner cases as well, where I think wsa may have an 
edge:

- if an 
ebMS intermediary has to generate an eb:Error, the routing of this error cannot 
always rely on a "reverse reading" of the eb:Header of the faulty message for 
back routing. Wsa provides wsa:From and wsa:ReplyTo headers that contain the 
same value type (EPR) as the wsrm:AcksTo, and that could be used for 
this.

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.

- 
bundling: as discussed in F2F, it could be that several UserMessage 
elements have to be bundled. Relying on eb:headers for routing in such cases, 
imposes several restrictions on how bundling can be done. Giving precedence to 
wsa ref param headers for routing is an unambiguous solution (see previous 
case of not up-to-date routing 
functions).

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.  

 <JD> we discussed a lot about wsa:MessageId in the past. One 
of the reasons to not rely on it was in case of bundling: the identity has to be 
per message unit (eb:UserMessage or eb:SignalMessage). We already have in Core 
V3 some limited cases of bundling Signal + User units. eb:Errors may need to 
selectively refer to these based on 
eb:messageId.

 

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

 <JD> this is a possibility. But if we make it clear what the 
routing precedence rules are, we have to consider the good side of 
discrepancies: in some cases - e.g. delay in updating the routing 
functions: you don't want to or can't rely on the eb:header. So discrepancy may 
be intentional. Given taht the eb:header is primarily intended for message 
binding after reception, while wsa ref params are only for routing, having an 
exact map should not be always expected or 
required.

 

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

 <JD> assuming the use of dummy eb:headers, yes. But again, 
there are seveal other factors to consider. 

From: Moberg Dale [mailto:] 

Sent: 07 May 2008 23:14
To: Pim van der Eijk; 

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:] 
Sent: Wednesday, May 07, 2008 1:04 
PM
To: Moberg Dale; 

Subject: RE: [ebxml-msg] MOU on 
intermediate support by conformance profile and other auxiliary documents for 
ebMS 3.0

 

 

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:] 
Sent: 07 May 2008 19:42
To: 

Subject: [ebxml-msg] MOU on intermediate 
support by conformance profile and other auxiliary documents for ebMS 
3.0

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.