RE: [ebxml-msg] Intermediary I-cloud "requirements" draft

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

 

 

From: Moberg Dale 
[mailto:] 
Sent: Thursday, February 07, 2008 8:50 
AM
To: 
Subject: [ebxml-msg] 
Intermediary I-cloud "requirements" draft

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.