[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Addition to Gateway Conformance Profile
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. 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). 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. So I guess we need to have a vote on it. 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: 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]