[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]