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

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

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:dmoberg@axway.com]
Sent: Thursday, February 07, 2008 8:50 AM
To: ebxml-msg@lists.oasis-open.org
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.