OASIS Specification Template
Running Notes
#1 Action
This is a potential interoperability issue with the core spec and the multihop profile about header fields for “action”. There are multiple levels where “action” occurs:
• SOAP HTTP binding level:
– For SOAP 1.2, HTTP request parameter "action"
– For SOAP 1.1, special purpose header SOAPaction
• wsa:Action. WS-Addressing says this action must be used in HTTP header, or '' (the empty string).
• [WSRM] specifies the wsa:Action must be set to WSRM actions.
• ebMS3 also has eb:Actions, available in ebint:RoutingInput. ebMS3 intermediaries would use this for routing.
How do all these “actions” relate? In general, and in the specific case when there is a wsrm:CreateSequence?
• How does the Initiator set the SOAP HTTP action?
– To comply with WS-Addressing, this needs to be either the empty string ('') or the value from the wsa:Action. It makes sense to use the empty string as in a multi-hop context intermediaries read the SOAP-with-attachments “action” too, while its value is really targeted to the ultimate receiver, which may be confusing or cause interop issues. Also, the initiator may not know if all hops are TLS-secured and the action value may be confidential. So the proposal is to always set the HTTP SWA “action” or “SOAPaction” to ‘’.
– WS-I BP20 (R1144) requires Content-Type parameter action *if present* to be same as wsa:Action. So we could as well recommend to NOT use it
• How does the initiator set the WSA Action?
– When sending WS-ReliableMessaging lifecycle messages, the value for wsa:Action is defined in WS-ReliableMessaging to values like . This is required to comply with WSRM
– For ebMS signal response messages (errors, receipts) the proposal is to derive this value from the P-Mode.
– For ebMS user messages, they don’t seem to need wsa:Action. If a value is needed one approach would be to set a value based on the eb:Action and/or eb:Service. WS-Addressing does not have a counterpart for eb:Service, and the eb:Action may be ambiguous for use in multiple eb:Services. So an idea would be to construct the value of wsa:Action as the concatenation of : for regular UserMessages, if they need one.
– Yes, whenever a wsa header is there, e.g. a ref parameter, wsa:Action should be there. The value : you propose should just be a recommendation: in other contexts, there might be a WSDL on the other side and whoever sets the wsa:Action value n the Sender side, may want it to comply with whatever this WSDL declares for it. On a Receipt response message, we could use by default: :’receipt’, unless the PMode says otherwise.
• How does the initiator set the eb3:Action? This would be based on the Pmode as per the Core spec.
• Yes.
•
To summarize, the fact that WSRM claims the wsa:Action for its lifecycle messages means that the wsa:Action is in general not very useful for routing. Basically any pair of endpoints that exchanges SOAP messages may want to use WSRM, hence will need to exchange WSRM protocol messages. So something like the ebint:RoutingInput is needed in any multihop network that wants to support routing based on business action.
Right. In general, we must have an answer about what is the content of wsa:Action. Its value may be predetermined (WSRM) or may be PMode-defined (which in some case is itself may reflect some broader context e.g. presence of a WSDL on the backend). Ouside these cases, a default value must be proposed (e.g. derived from other PMode elements).
Note that the wsa:Action attribute MUST be an IRI as defined in RFC3987 and has basically the same structure as an URL. I think this can be a problem when constructing the Action value from P-Mode property values as the concatenation might not form a valid IRI.
Can’t we just use more general wsa:actions like and ? The wsa:action is something we don’t really need for routing as that will be based on the reference parameter.
#2 Pmode parameter for reliable messaging protocol
This is a minor issue with the core spec rather than the multihop profile.
In eb3 Core, appendix D, what Pmode parameter does one use to indicate which reliable messaging protocol to use? There is a parameter to specify the version of WS-Security to use, but its counterpart for selecting (versions of) WS-R or WS-RM seems to be missing.
Proposal: add a new parameter:
PMode[1].Reliability.Protocol
Values would be the namespaces:
•
•
OK. AT this point we can just add this more generally to “Part 2”, not to multihop? (i.e. a PMode complement section, outside the Multihop section)
#3 Pmode for eb:Receipt URL
This is a minor issue with the core spec rather than the multihop profile.
In eb3 Core, appendix D, there are parameters to indicate the URL where to post acknowledgments (PMode[1].Reliability.AtLeastOnce.Contract.AcksTo) and errors (PMmode[1].Errorhandling.Report.ReceiverErrorsTo), but not for eb:Receipts.
Proposal: add a new parameter:
Pmode[1].Security.SendReceipt.ReplyTo
The value could be the URI (as visible to Responder) of the intermediary.
Just add this to Part 2? (i.e. a PMode complement section, outside the Multihop section)
Isn’t PMode group BusinessInfo a more logical place for this parameter as this more related to the business process than security?
#4 Pmode for WSA reference parameter in initiating messages
Draft 0.22 discusses this in section 1.7.2. It discusses three cases:
1) ebMS messages. These don’t need ebint:RoutingInput.
2) ebMS signals such as eb3:PullRequest
This is discussed in example C and #10.
3) non-ebMS messages
Draft 0.22 mentions a P-mode for routing and non-ebMS messages, such as wsrm:CreateSequence.that defines the values to populate the ebintRoutingInput. But it may be sufficient to have just one additional Boolean parameter:
Pmode[1].Reliability.AtleastOnce.Contract. WSA.RefParam
If this value is true, the regular P-Mode parameters for From, FromRole, To, ToRole, Service, Action, MPC could be used. See section A.2.1 in the document “Examples.doc” and example B.
Since these are all statically configured parameters, the sequences could be created ahead-of-time as well as just-in-time.
OK. As long as the “minimum” content of the ebint:RoutingInput ref parameter is specified as above.
I think you should be able to define in the PMode which properties of the reference parameter you want to use. If the reference parameter properties are always filled with all available P-Mode parameters each combination of PMode property values (like To, From, Service, Action, etc.) will result in a separate EPR and therefore a separate RM sequence.
This might not be a problem but I don’t see a reason why to restrict it this way. Maybe it’s better to use a PMode property to indicate whether such a default EPR should be used?
#5 Pmode for WSA reference parameter in response messages
There is also a need to define Pmode parameters for the WSA reference parameter for acknowledgments, errors and receipts as described in section 1.7.3, lines 739-751 in draft 0.22. That section mentions two options. One is to use a wsa:ReplyTo (option b1). The other option is to use P-mode. Here is an elaboration of the P-mode approach, and a third alternative, viz. an algorithm to construct a reference parameter from other P-mode parameters:
1) Section 1.8 in draft eb3 intermediary protocol specification has a proposal, but this assumes there is just a single reference parameter for all three cases. But the value of some of the parameters (such as Action) could be different for the various cases.
For RM Acks and other RM signals, we restrict all these to be destined to the wsrm:AcksTo EPR given in the CreateSequence. In fact, In our current draft we further require that this EPR be the one associated with the Sender of the user message (though we could relax that) This EPR would have the right ref parameters needed for routing. So the PMode need not be involved for these, on the Receiver side. The Sender side sets the AcksTo value.
Jacques, I also assume that only the wsrm:AcksTo EPR is used for RM Acks and signals. The RM spec however doesn’t say anything about this aspect of combining WSRM with WSA so I was wondering if this restriction might lead to interoperability issues?
Maybe it’s better to define just one EPR for RM Acks and Signals but use this EPR in both wsa:ReplyTo and wsrm:AcksTo? Or is that what you meant?
2) We could add different parameters, (at least) nine for each of the three cases. The following is a table for SendReceipt, there would be two others for acknowledgments (Pmode[1].Reliability.AtleastOnce.Contract.Acknowledgment) and errors (Pmode[1].Errorhandling.Report.WSA.RefRaram).
|P-mode parameter |Definition |
|Pmode[1].Security.SendReceipt.WSA.RefParam |Indicates whether an ebint routing input parameter is to be |
| |attached to the receipt (Boolean) |
|Pmode[1].Security.SendReceipt.WSA.To |The value to use in the wsa:To element (could default to |
| |
| |11/icloud) |
|Pmode[1].Security.SendReceipt.WSA.RefParam.From | |
|Pmode[1].Security.SendReceipt.WSA.RefParam.FromRole | |
|Pmode[1].Security.SendReceipt.WSA.RefParam.To | |
|Pmode[1].Security.SendReceipt.WSA.RefParam.ToRole | |
|Pmode[1].Security.SendReceipt.WSA.RefParam.Service | |
|Pmode[1].Security.SendReceipt.WSA.RefParam.Action | |
|Pmode[1].Security.SendReceipt.WSA.RefParam.MPC | |
SO only two such tables might be needed: 1 for Receipts (by default, Receipts go to original Sender), 1 for Errors (if need to be routed differently than to original Sender).
I think the PMode BusinessInfo group would be a better location for the Receipt EPR
Pim, on which side (Initiator / Responder) should these EPR definitions be set? From your example A I conclude the Responder side. I would however think that these would be used on the Initiator side to fill the WS-A ReplyTo (for Receipts) and FaultTo (for Errors).
This way the Initiator has full control over where return messages are sent to and doesn’t depend on changes to made at the Responders side,
Option 3 below might be a good default although the same remark as on note #4 applies.
3) We could define a default algorithm to generate the WSA reference parameter from the incoming message as follows:
• Swap eb3:To and eb3:From
• Copy Service
• Create a value for Action using concatenation of the Action in the incoming message and either ‘Error’, ‘Acknowledgment, ‘Receipt’. (And possibly other values for future enhanced WS-* helper messages). So for example an eb3:Receipt in an eb3:SignalMessage sent in response to a user message with eb3:Action SendInvoice would have a value SendInvoiceReceipt. The value Acknowledgment could also go with other RM response messages as these have the same routing requirements.
• The only field that would need to be specified as a separate parameter is Pmode[1].Security. SendReceipt.WSA.RefParam.MPC, as it cannot be predicted from any of the fields in the message it is a receipt for.
This would result in less redundant CPAs or similar.
Proposal: option 3 seems the most elegant option to me !?
Option 3 does not replace Option 2. We can also in Option 3 derive a new MPC Id by concatenating “Receipt” or “Error”, e.g. on the first hop, a One-way / Push is sent to MPC “abc”. The Receipt is automatically routed back to MPC “abc:Receipt” (unless specified otherwise by Option 2). Same for errors: “abc:Error”. So the Sender can then pull on these MPCs.
#6 How to indicate streaming?
If an intermediary can serve both in streaming mode (use the backchannel on the incoming connection to transmit results arriving from the outgoing connection) and in store-and-forward mode, how does it determine which of these options it takes?
Options:
• The intermediary inspects messages for wsa:ReplyTo elements and associates the value anonymous with streaming and other values with non-streaming processing. But regular ebMS3 user messages don’t (have to) use WS-Addressing, so absence of a wsa:ReplyTo should not always be interpreted as anonymous EPR as in WS-Addressing.
• It becomes part of the routing function, allowing for fine grained control (e.g. one action may be streaming, the other not). The decision to forward-by-pushing or to forward-by-storing-for-pulling is a routing decision anyway, so the decision to use streaming or not is just a sub-case of the forward-by-pushing case.
• The intermediary is configured to have certain URLs that trigger streaming and others that trigger storing-and-forwarding. For instance using a parameter versus .
The last option could actually be more general, and just indicate that the intermediary should keep the connection from initiator open to pass back the response from the I-Cloud, whether received synchronously on the backchannel of the outgoing connection or otherwise. Within the I-Cloud the response may come back (to the first intermediary) asynchronously and perhaps via a different route. Impact:
• Endpoints: don’t need to be changed to support this, as long as the value for streaming or non-streaming is set appropriately for Pmode[1].Protocol.Address. The administrator responsible for the MSH needs to use the right URL for the PMode.
• Intermediaries: leaving the decision to stream or not to stream to the client simplifies their configuration (routing function).
Some ebMS products may not support streaming mode well or at all. Support for streaming could be an optional feature, specified as a conformance target. More generally, a community that communicates via an intermediary that does not support streaming should not use messaging involving any of the following values or combinations of values:
• Pmode.MEPBinding value .
• Pmode[1].Errorhandling.Report.AsResponse value “true”.
• PMode[1].Security.SendReceipt.ReplyPattern value “response”.
• Pmode[1].Reliability.AtLeastOnce.ReplyPattern value “response”.
#7 WSRM lifecycle messages
WS-ReliableMessaging message can be exchanged both synchronously (using the anonymous ReplyTo EPR) or asynchronously. Question: How does a sending MSH know which option to use?
Lines 3699-3701 of the Core spec state that:
When an underlying two-way protocol is used, any pair of sequence lifecycle message (CreateSequence/CreateSequenceResponse, CloseSequence/ CloseSequenceResponse, TerminateSequence/ TerminateSequenceResponse) SHOULD be exchanged over a single request response MEP of the protocol.
This does not work with some uses of intermediaries, so the proposal would be to relax this in a multihop context and instead propose that:
In a multihop environements, the value for Pmode[1].Reliability.AtLeastOnce.ReplyPattern SHOULD be used to determine if WSRM lifecycle message exchange is synchronous (“Response”) or asynchronous (“Callback”), just as it determines whether acknowledgments on the sequence to be established will be synchronous or asynchronous.
Yes, although we have to clearly distinguish the two “edge hops”. More generally we need to make it clear that a PMode that governs an MEP across multihop partners, needs be split in two PModes to be deployed respectively on the Initiator side and on the Responder side. Of course, some parameters will be same (or shared) on both sides, but not all. And among those that can (and generally will) be different, are those that govern the channel binding and MEPs, e.g. the ReplyPattern parameters. First, we should set some convention for the PMode ID: it should be respectively of the form: :’init” and :’resp’ for each one of these PModes that govern the same exchange over edge hops. Then, Pmode[:init, 1].Reliability.AtLeastOnce.ReplyPattern would govern the way Acks + RM messages are expected over the 1st edge hop, while Pmode[:resp, 1].Reliability.AtLeastOnce.ReplyPattern would govern this for the last hop.
When using asynchronous exchanges, the SOAP messages use the wsa:ReplyTo element and therefore (WS-I BP 2.0) also the wsa:MessageId element and, in the response, a wsa:RelatesTo element.
#8 WSRMP extension
Line 3657 to 3675 in [ebMS3 Core] specify the use of wsrmp extension elements for delivery assurances and indicate that these MUST be supported as extensions of sequence creation messages. Is this possible using off-the-shelf WS-RM implementations? What does this mean for implementing ebMS3? I’m not sure if the core spec has enough information here for implementers.
I think the information is sufficient: the PMode reliability contract parameters (PMode[1].Reliability.AtLeastOnce.Contract , etc) will provide all input needed to populate these extensions.All whats needed from an implementation, is the ability to add such extensions.
The WSRMP spec being referenced in the Core spec doesn’t include a definition of the elements presented on line 3651-3653. From what I understand the correct assertions would be:
[ |
|
]
?
#9 ConversationId in RoutingInput
Potential interoperability issues:
ConversationId can occur in multiple RoutingInput elements.
Proposal: In any SOAP message, the value of the following occurrences of eb3:ConversationId, if present, MUST be the same.
• S:Header/wsa:ReplyTo/ebint:RoutingInput/ebint:UserMessage/ebint:CollaborationInfo/eb3:ConversationId
• S:Header/ ebint:RoutingInput/ebint:UserMessage/ebint:CollaborationInfo/eb3:ConversationId
• S:Body/wsrm:CreateSequence/wsrm:AcksTo/wsa:ReferenceParameters/ebint:CollaborationInfo/eb3:ConversationId
Explanation:
• the first two to make sure response messages (even if not ebMS messages) are in the same “conversation”, if only for monitoring purposes.
But this is more a Core V3 update here: So far it appears that Core V3 stayed away from giving any MEP semantics to ConversationId. That could be the role of a subsequent profile, but do we want to enforce this here?
•
• The third one to link acknowledgments uniquely to the established sequence.
Proposal: N.B. once a sequence is established, there is no requirement that acknowledgments for ebMS messages have the same ConversationId in their RoutingInput as the ConversationId in the UserMessage that is being acknowledged.
Right. But even the CS message should ignore ConversationId, because a same RM seq could be shared among several MEPs and several conversations.
#10 MPC in RoutingInput
Potential interoperability issues:
• When sending messages over some established sequence with identifier Identifier the value of s:Header/ebint:RoutingInput/ebint:UserMessage/@mpc (if present) must be the same as the value of the s:Header/ebint:RoutingInput/ebint:UserMessage/@mpc in the CreateSequence message that produced a corresponding resulting CreateSequenceResponse message containing the identifier as s:Body/wsrm:CreateSequenceResponse/wsrm:Identifier.
So far, Core V3 only RECOMMEND that messages sent over same sequence use same MPC. The general idea is that sequences may be established up-front between pairs of partners, and the same sequence may be used across conversations and MEPs, especially if all these need same reliability QoS (as indicated in the CS extensions). So sure it is expected that routing info for a CS is same as for messages over this sequence. But @mpc might not be relevant to this routing.
• In a CreateSequence message, the value of s:Body/wsrm:CreateSequence/wsrm:AcksTo/wsa:ReferenceParameters/ebint:RoutingInput/ebint:UserMessage/@mpc MUST be the same as the value of s:Header/wsa:ReplyTo/ebint:RoutingInput/ebint:UserMessage/@mpc.
We may indeed want all RM signals and Acks to go to same destination. I believe we stated that somewhere, and we can add this below. But why single out @mpc if the routing function does not use it?
• In fact, it is recommended that in a CreateSequence message, the value of s:Body/wsrm:CreateSequence/wsrm:AcksTo/wsa:ReferenceParameters/ebint:RoutingInput is the same as the s:Header/wsa:ReplyTo/ebint:RoutingInput.
Isn’t this a more general issue for all attributes of the EPR used for establishing a RM sequence? When a sequence is established for one EPR, i.e. an ebint:RoutingInput, you cannot send messages over that sequence that have different values for some of the EPR’s attributes because that will be a new EPR which can be routed to another MSH.
#11 Routing PullRequest
Section 1.7.2 of Draft 0.22 has this:
2. Case of ebMS Signal Messages: The main case of “initiating” ebMS signal, is the eb:PullRequest message (see Case 4 of On-way edge-bindings in section …). Some eb:Errors may be generated as initiating messages, i.e. not as responses to faulty messages. The ebms header of such messages does not contain an eb:UserMessage element. However, the PMode associated with the messages to be pulled (i.e. defining a One-way / Pull MEP) is shared between partners, along with the EPR of the sender of the pulled message. From this EPR is extracted the eb:routinginput reference parameter, added as. WS-Addressing header to the PullRequest signal.
But:
• There may be many different message types are sent on the same MPC, all with different actions, services, from/to settings etc. So there is no functional mapping from MPC to a single ebint:RoutingInput.
Right. But in my view, that is not an issue: different ebint:RoutingInput may resolve to the same destination. E.g., the routing function may use just a subset of ebint:RoutingInput, e.g. the To and MPC. Maybe we can make this clearer in the draft. In one Use Case not listed in the draft, a One-Way message may be pushed to the first intermediary, then the Receiver will Pull it all the way (single PullRequest) from this Intermediary that manages authorization on behalf of the Sender. In that case, the Sender (which may be not addressable) would still specify an EPR that will allow routing of the PullRequest up to this first Intermediary. This EPR will have routingInfo that might just have To + MPC.
• More importantly, it is possible to read Draft 0.22 (1.5.2.2 lines 258-262) as describing a second way of forwarding, not based on an ebint:RoutingInput in the SOAP header, but on a special type of routing tables based only on eb3:Messaging/eb3:SignalMessage/eb3:PullRequest/@mpc. Some MPCs will be local (so the intermediary can serve the messages directly, and authenticate the polling MSH based on its own credentials). Other MPCs will be remote, and the authentication is passed along with the message. In that case an endpoint that sends a PullRequest should never attach an ebint:RoutingInput. Routing rules for PullRequest only reference MPC. And there is also no need for any WS-Addressing headers.
We could assume that the routing function can be defined to be able to look at any part of the message header (not just eb:UserMessage or ebint:RoutingInput), But even if @mpc is the only routing input, we could still rely on ebint:RoutingInput, void of any other value. So I see what you suggest as an option, not a strict requirement.
#12 SOAP 1.2 attributes in Core spec
Here is another comment on the ebMS 3.0 core spec. Line 1475-1479 of the core spec state that:
1475 The eb:Messaging element has the following attributes:
1476 • eb:Messaging/@S11:mustUnderstand: indicates whether the contents of the element
1477 MUST be understood by the MSH. This attribute is REQUIRED, with namespace qualified to the
1478 SOAP namespace (). It MUST have value of '1' (true) 1479 indicating the element MUST be understood or rejected.
Yet the ebMS 3.0 Core schema says it is optional:
if SOAP 1.1 is being used, this attribute is required
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.