RE: [ebxml-msg] Requirements Draft

Hello Hamid,

 

I was thinking of a situation where an intermediary (say a national hub) 
connects to 24 organizations (e.g. provinces/districts) that each have their own 
MSH. Then there is a reorganization of data centers where the number of 
data centers is reduced to four (e.g. North/South/East/West), each 
with its own gateway, so a gateway serves on average six regional 
organizations.  With ebMS 2.0 today, we only need to edit 26 routing 
table entries (PartyId->URI) at the intermediary.  
All organizations that communicate with those 26 organizations via the 
intermediary (there may be  thousands of these) need not change their 
configurations at all.

 

Another case is where a particular service is hosted by one organization 
(with its own MSH gateway), and then outsourced to a specialized organization 
(with its own MSH gateway).  If the service is identified by the PartyId, 
it is the same as the previous case. If the service is identified by eb:Service 
or a combination of eb:To/eb:PartyId and eb:Service, then the routing logic is a 
bit more complex but could still be handled at the intermediary. 

 

Pim

From: Ben Malek, Hamid 
[mailto:] 
Sent: 14 February 2008 
05:02
To: 
Subject: RE: 
[ebxml-msg] Requirements Draft

Thanks 
Pim for the info. I certainly think that we need a formal document (one single 
document) that should group together the use cases/requirements and this 
document should be posted to Oasis site. In this document, it is important to 
clearly explain each use case and label it so that we can at any time refer back 
to any use case by just mentioning the use case number or name. Any 
requirement/use-case that is not in the formal document will not be considered 
in the solutions. Someone needs to take this action very urgently if you want 
the solution to Multi-Hop be released quickly…

 

Your 
last point is not clear to me (when you say: … service provided by A shifts to a 
specialized organization…). The new organization that took over the service, is 
it connected to the same Gateway as A or can it be in a different country far 
away? If it is connected to the same Gateway as A, then there is no problem. But 
if new organization is in a different country (and therefore connected to its 
own separate Gateway), there is no way that traffic would go to the new 
organization without the sender being informed of such a big change. I need to 
know which case you are talking about in order for me to design a 
solution…

 

Hamid.

 

From: Pim van der Eijk 
[mailto:] 
Sent: Saturday, February 09, 2008 3:30 
AM
To: Ben Malek, Hamid; 'Moberg Dale'; 

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

 

Hello,

 

Let 
me attempt to explain how I interpret Routing Requirement 
(a):

 

Organization A interacts 
with a service S provided by organization B by exchanges messages via 
Intermediary Int. The configuration reflects some end-to-end agreement 
features (e.g. Service, Action, PartyId, XML schema of attached business 
documents) and some features that are specific to adjacent nodes (e.g. TLS 
certificates, URI of Int's ebMS endpoint, Pull or Push, HTTP or other protocol 
binding).  The remapping requirement means that it should be possible 
to reconfigure Int such that these messages are delivered to B without the need 
to notify A.

 

Some real life 
scenarios:  

- B 
updates his TLS certificate

- B 
pulls messages from Int instead of Int pushing them (or vice versa) 

- Responsibility for a 
particular service provided by A shifts to a specialized organization, 
messages should flow directly to that organization's MSH. 
 

- 
"C" acting as a desaster recovery site for "B", with traffic remapped at the 
Intermediary.

 

Pim

 

 

From: Ben Malek, Hamid 
[mailto:] 
Sent: 08 February 2008 
02:18
To: Moberg Dale; 

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

Thanks 
Dale for the effort to tackle the “Goals” topic which was not addressed very 
extensively. My comments are inine…

 

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.

 

[Hamid]: 
I don’t know if you are joking with your comment (not axioms!) or you are 
serious. If you are joking, I need not comment on this. If you are serious, I 
may need to clarify what I meant by axioms: When I was talking to Sander, I used 
the term axiom in a “joke” way (not a serious talk). The meaning of my joke was 
that the design principles should be considered as axioms (meaning that they are 
extremely important holy law that can never be broken or violated). Indeed, the 
axioms come after the goals have been specified. Once we know the goals, we 
write down the axioms (the design principles) that any solution must conform to 
in order to be an acceptable and a very good solution to standardize. I thought 
the goals were already specified, otherwise why would we be discussing Sander’s 
solution on the conf call? If the goals are not yet defined, then Sander should 
not even propose a solution. In any case, I am very glad that we are starting to 
tackle the “goals” topic, and I wish I can get more and more information on this 
topic so that the solution we will propose would be the best. Thank you for 
providing such an information, but I still have some questions about it as my 
comments below will show you…

 

Routing

 

a.     intermediary cloud 
can remap an original sender’s message types to a new recipient without the 
original sender changing its configuration

[Hamid]: 
First of all, I will be very grateful that you define terminology very precisely 
before any talk. I never heard the term I-Cloud (or intermediary cloud), and it 
should be defined before you propose the goals. This is not just for this term, 
but any terms you will be using in the list of goals need to be defined with 
great precision and on the front. I will assume here that you mean a chain of 
Intermediaries (or a network of intermediaries) unless I am 
mistaken.

Second, 
I am not sure I really understand your sentence (and forgive my stupidity). What 
do you mean by “remap” and what do you mean by “type”? Remap a message type: 
does that mean changing the type of a message to another type? (an Intermediary 
receives an “Ack” type of message, and it changes that message to something else 
like an ebms3 user message piggy-backed with the Ack or maybe to another 
 type of message?

What 
do you mean “to a new recipient”? The original sender is sending for example a 
user message with a To-Party equals to “sun.com”, and your I-Cloud is giving the 
message to a receiver that might not even be the party with the name 
“sun.com”?

b.    intermediary should 
strive to maintain transparency by not modifying message 
excessively

[Hamid]: 
I am against any modification of the message being passing through the 
Intermediaries. “Not excessively” is a very vague word (and very dangerous to 
use). It does not give a measure of what kind of modifications are allowed. My 
position on this is very clear: I don’t allow any Intermediary to modify the 
message.

 

Transparency 
aspects

 

a.     original signatures 
remain unbroken (and probably need to be designed to withstand some I-cloud 
modifications)

[Hamid]: 
Sometimes, there is a huge difference between theory and practice. In theory, we 
can elegantly state that signatures should be designed to not be broken easily. 
In practice, it is extremely difficult for a SOAP node to know whether the 
modification it wants to do may or may not break existing signatures. The 
position on this should be very clear by simply not allowing modifications of 
the message except the headers that are only intended for the Intermediaries. 
Your sentence I-cloud modifications smells lots of trouble and it scares me a 
lot. There is only one type of modification (not modifications): the 
Intermediary may remove the header that is intended for the Intermediaries only. 
Only the last Intermediary may remove such a header.

b.    reliability 
assurances are preserved to the extent possible – end to end if 
possible

[Hamid]: 
There is no problem with this goal. We were aware of this, and it was taken care 
of in our solution.

c.     data confidentiality 
is preserved (and may also need to be designed/constrained to enable I-cloud 
presence)

[Hamid]: 
I agree with data confidentiality, but I don’t agree that as a sender, I should 
constrain my confidentiality just because my message will go through 
intermediaries as opposed to peer-to-peer. The design of Intermediaries 
architecture should take into consideration that a sender is free to encrypt 
everything (except the headers that are intended for Intermediaries 
only).

Endpoints 

 

a.     Core conformance 
endpoints (original sender and ultimate receiver) should not need to modify 
behavior [at all | excessively].

The 
sender and receiver are not modifying their behavior at all (this was implicit 
in axiom 5 J)

b.    MSH intermediaries 
will have special conformance profile

[Hamid]: 
Totally agree on this: an “Intermediary” is a separate role by itself, and it 
obviously deserves a 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)

[Hamid]: 
Intermediary rules only cover the nature of the processing itself: that is what 
are the actions an Intermediary should do as part of the “header processing”. 
This is outside the SOAP spec.

b.    A MSH SOAP 
intermediary can be targeted by headers and those headers 
removed.

[Hamid]: 
Yes that is the case. The last intermediary is the one who can remove those 
headers.

c.     Addition of headers 
must be carefully scrutinized with respect to Transparency 
aspects.

[Hamid]: 
What type of addition of headers you are talking about? Do you mean an 
Intermediary may add headers that are not even intended for Intermediaries but 
rather intended for an MSH or a Reliability module for example (like sending a 
create sequence as Sander’s diagram is illustrating)? The answer is no. 
Intermediaries are not allowed to add headers that are not intended for them. 
There will be no transparency if the message can be modified in weird 
ways.