RE: [ebxml-msg] Addition to Gateway Conformance Profile

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

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]
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.