I would add the following requirement as
well:
Ease - and coherency - of
implementation:
a. An ebMS intermediary should leverage the features
provided by the WS stack it is deployed on, and not duplicate or override
built-in features.
We can expect WS-ReliableMessaging to become native to
several stacks, including Apache. An MSH must be able to reuse such
libraries/modules: redeveloping them (or using your own version "on top") will
complicate interoperability, create maintenance issues, raise eyebrows,
etc.
But this is precisely what I am concerned would be needed
with the "ack relay" technique.
Indeed, to implement relayed Acks requires a deep control
and access into RM functions that a WS stack will almost certainly never allow.
For example an RM module should be able to :
- wait for the "user" layer (the MSH) to give the OK
for sending back each Ack.
- not send the Acks according to its internal logic (i.e.
signaling you have received and "accepted" messages [WS-RX, Section 2.1
glossary]), but based on the result of the future processing of this message.
Needless to say this is hardly compliant with WS-RM spec...
- the sequence number associated with each message -
and automatically incremented by the RM engine - is not supposed to be visible
outside the RM module. Most implementations hide it. Yet here the RM module must
pass this seq num to the MSH layer.
- worse: the MSH will tell which seq num to
use for messages to be sent out - e.g. when passing a message to its RM
module, the MSH would need to say something like "send it over sequence XYZ, and
with seq number #456000123" , because the seq num associated with a message must
preferably not change from one RM seq to the other. Allowing it to change would
require a horrible mapping between the range intervals when mapping one Ack to
the next Ack.
- the resending mechanism will need to be adjusted (based
on round-trip time for the Acks) and also because some missing seq nums in Acks
only mean there was no message sent for them in the first place (these
messages never arrived to the intermediary).
Existing stacks will be more trouble than help for these intricate
interactions RM-MSH.
Jacques
Here are some of the goals (not
axioms!) that we have been discussing for building various I-clouds. It is too
early for axioms IMO.
Routing
a. intermediary cloud can
remap an original sender’s message types to a new recipient without the original
sender changing its configuration
b. intermediary should strive
to maintain transparency by not modifying message
excessively
Transparency
aspects
a. original signatures remain
unbroken (and probably need to be designed to withstand some I-cloud
modifications)
b. reliability assurances are
preserved to the extent possible – end to end if
possible
c. data confidentiality is
preserved (and may also need to be designed/constrained to enable I-cloud
presence)
Endpoints
a. Core conformance endpoints
(original sender and ultimate receiver) should not need to modify behavior [at
all | excessively].
b. MSH intermediaries will
have special conformance profile
SOAP
intermediary
a. A MSH intermediary is also
a SOAP intermediary, but may be constrained in certain ways by SOAP (probably
underconstrained by SOAP Intermediary rules)
b. A MSH SOAP intermediary
can be targeted by headers and those headers
removed.
c. Addition of headers must
be carefully scrutinized with respect to Transparency
aspects.