A third approach would be to allow the routing function
to determine the MPC that can be pulled from. Just as the URL in HTTP posts is
rewritten from hop to hop.
The default option would be the identity mapping:
to pull a <eb3:UserMessage mpc="abc">..</eb3:UserMessage>, the
eb3:SignalMessage MUST have an <eb3:PullRequest mpc="abc">.
But the intermediary could have a mapping "abc" -->
"xyz", specifying that the message can only be pulled from the "xyz"
MPC. This routing rule would only affect this intermediary,
as the message itself is not changed and still has "abc". So if the
pulling client is itself an intermediary, it would apply its own routing rules
to the UserMessage with the original MPC value, if
any. This assumes a pulling ebMS 3.0 MSH does not
reject a pulled user message that has a different MPC value for the
mpc attribute than it specified in the PullRequest.
Pim
We need to decide how to handle
this specific multi-hop situation (a Use Case originated by Pim), which
could mean deciding which sub-case is most
important :
Use Case:
A party is sending messages to a large number of recipients
over the I-Cloud. These recipients are supposed to pull these messages from
their edge-intermediary (the forwarding pattern used by this intermediary is
either "push-pull" or "pull-pull".) Each
recipient must pull its own messages.
However the sending party does not want to be concerned with several MPCs, one for each recipient, and is sending
all messages over the same MPC. The last intermediary alone is aware of which
message should be forwarded to which recipient -
i.e. must be able to distinguish pulling recipients and return only a message
intended to its recipient.
Two solutions are considered:
Solution (1): the "sub-channels" solution described in 1.6.4 of latest
posted V30 draft (4/15).
Solution (2): An Intermediary MAY be able to associate several
"access points" with an MPC. Each access point has its own authorization data.
When "multiple access points" are supported for an MPC, the Intermediary MUST be
able: (a) to associate each received user message over this MPC with a
particular access point, based on header information. (b) when receiving a
PullRequest for the MPC , to determine which access point is concerned based on
authorization credentials, and to only return messages matching this access
point to the requestor.
Advantage of Solution 1: works well in cases when there is no
authorization data associated with PullRequest (see sub-case B), as it works
independently whether authorization is used or
not.
Advantage of Solution 2: On the
endpoint, does not require knowledge of any "sub-channel": only authorization
info is needed to pull messages. The PullRequest is still targeting the same
MPC. Seems better for sub-case
(A).
Sub-case (A): This sub-case applies when all recipients are un-related
and yet associated with the same Intermediary (Hub): Each recipient must be
prevented from pulling messages of other recipients. Each pull signal is
therfore authorized differently from one recipient to the other. All PullRequest
signals must be authorized.
Sub-case (B): This sub-case
applies when all recipients belong to the same entity (say various departments
of a same company). Pull authorization is not considered worth the overhead, as
it is not critical if a department accidentally pulls a message for another
department. However each pulling must be selective for efficiency reason - each
dept pulling its own messages.
Jacques