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.
