[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Addition to Gateway Conformance Profile
See inline… From: Dale Moberg
[mailto:dmoberg@us.axway.com] I do not see why adding the required functionality of being able to
support ebMS 2 (at the Drummond interop level, for example) prevents the
gateway profile from being a profile such that we would have interoperability
out of the box. [Hamid]: You are right it does not prevent interop if there is only
one gateway profile and that gateway profile is supporting v2. But this is not
the main issue here. However, talking about interop, there would be a problem
if there are multiple gateway profiles or different kinds of gateway profiles.
Plus, supporting v2 still needs to be defined with a mathematical precision and
that has not yet been done. If I may outline the meaning of supporting v2, I
would say that the MSH v3 only needs to understand ebms v2 headers, and not
XMLDSig, Reliability as defined in proprietary way in v2, or any headers not
belonging to the ebms v2 namespace. From a market perspective, I think preserving a mode of
interoperation with ebMS 2.0 is essential. I think this should be in the
main/gateway proposal (the full-featured MSH). [Hamid]: I do agree with you on the importance of supporting v2. Our
disagreement point is just the main profile. I take it you don’t want it that way, and I don’t
really get much insight into a reason why from a market or functionality
standpoint. [Hamid]: One of the reasons is that v3 is really independent of v2.
V3 was built from scratch (in a certain sense). We did not build v3 as a
modification of v2 of just an extension of v2. V3 is really a different beast,
is compatible with webservices, uses latest standards (WSS, WS-Reliability and
WRM, etc…). Basically, you can implement v3 without knowing an atom about
v2 spec. However, I do agree with you on the market functionality standpoint,
but this unfortunately does not affect the nature of ebms3 spec itself which is
really totally different from v2. So I guess we need to have a vote on it. [Hamid]: We can have a vote on it, but I don’t think we have
to vote on it now. I don’t consider this an urgent matter. What is urgent
on the table is that we vote today for the second PR. At a later time, we can
discuss this more on conf calls or in private until we agree on something. But
I don’t think this is urgent. Dale Moberg From: Ben Malek, Hamid
[mailto:HBenMalek@us.fujitsu.com] Dale, I think Jacques summarizes very well what I was trying to
say. I, however, still disagree on few points: The first point is about the terminology concerning the word “Gateway”.
For Dale, gateway is just an attribute (not even a role) and different MSHs
(with different capabilities –meaning not necessarily
interoperable–) can fulfill the gateway attribute or role. This is even
against Dale’s principle that two MSHs implementing the main profile
should be interoperable out of the box. I definitely push for this principle
(that two MSHs implementing the main profile should be interoperable out of the
box), but having different kinds of main profile (the main profile is what
we call “gateway”) is not the right idea. The second point is, even if I accept the terminology suggested
by Jacques (just for the purposes of explaining things to Dale), I would
personally choose “Approach B” than “Approach A” (see
Jacques email below).But, again, as I said in the first point, I don’t
agree with a terminology like gateway 1, gateway 2, etc… because this
creates different kinds of the gateway conformance profile. There is only one
main conformance profile (what Jacques calls the baseline) and that main
conformance profile directly relates to the core spec alone and not to a
previous version of it. I emphasize again that I am not against supporting version 2 in
a conformance profile. Just create a second profile (not called gateway or main
profile) and have version 2 supported in it. Hamid. From: Durand, Jacques R. Agree that the proposal to create a main Gateway conformance
profile that requires ebMS2 backward compatibility, is not the same as
requiring it in the core spec. I think the question is more what should the
"baseline" conf profile require: approach A: (suggested by Dale) "Gateway One" conformance profile (the B2B
baseline): supports V2+V3 "Gateway Next" conformance profile: supports V3 only approach B: "Gateway One" conformance profile (the B2B
baseline): supports V3 only "Gateway Transition" conformance profile: supports V2+V3 I tend to favor (A) : even if it sets the bar higher for the
baseline, it would address major backward compatibility concerns from users, by
coercing vendors to provide V2+V3 MSHs. Most of future V3 vendors are
already V2 vendors, I assume. As for those communities that do not have to deal
with ebMS legacy, they can always choose to use implementations conforming
to Gateway Next only (e.g. some ebMS V3 open source). Jacques From: Dale Moberg [mailto:dmoberg@us.axway.com] Hamid writes: I perfectly understand the issue Dale is pointing to and would
like to resolve. However I don’t think the resolution is the correct one.
We cannot require the gateway profile to support version 2. This would be
equivalent in saying the ebMS-3 is a super-set of version 2. This is because
the gateway profile is directly related to the core spec and represents the
normal implementation of it. Other conformance profiles are
“exotic” (in a sense) or derivative. Creating a new conformance
profile in which version 2 must be supported as well is fine, but to put this
directly in the main conformance profile (gateway) is the same thing as putting
this in the core spec itself, and this is not a good approach. Hamid, I do not share your assumptions about the purpose of our
profiles. Our profiles are not like WS-I restrictive profiles on
specifications. Instead our profiles specify a more or less complete MSH role
that an aggregate of software components can fulfill, much in the way a class
can implement an interface. A gateway MSH can be required to do some
functionality described in XMLDsig, some in WS-RX, some in WSS, some in ebMS 3
core, and for market sanity, some in ebMS 2. So your argument that ebMS 2 would
have to be a part of ebMS 3 specification is to me off-base. There are many
things that are called “profiles” and I simply reject the assertion
that a gateway profile has to be restricted to profiling the ebMS 3 core spec.
A profile is a good place to specify the required behavior of a MSH playing the
gateway role; nothing requires that there be a single software component
associated with that role. In fact, the component level design is left to the
implementer, as it should be IMO. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]