[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Addition to Gateway Conformance Profile
|
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]