[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:pvde@sonnenglanz.net] 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:HBenMalek@us.fujitsu.com] Thanks Dale for the effort to tackle the “Goals”
topic which was not addressed very extensively. My comments are inine… From: Moberg Dale
[mailto:dmoberg@axway.com] 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]