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.
