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:]
Sent: Thursday, April 12, 2007 1:35 PM
To: Ben Malek,
Hamid; ebXML Messaging TC
Cc: Ric Emery; Persson Ulf; Colombier
Guillaume
Subject: RE: [ebxml-msg] Addition to Gateway Conformance
Profile
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.
