RE: [ebxml-iic] Conformance Profiles

[Jeff Turpin <jturpin@cyclonecommerce.com>]

Title: RE: [ebxml-iic] Conformance Profiles

Yes, I meant "own custom interoperability profiles...". Basically I wanted allow these custom interop profiles to be comprised of groupings of our various conformance levels. Does anyone have a different proposal for our conformance levels/profiles? Cheers!

 

 

 

Jeff Turpin

Cyclone Commerce, Inc.

 

-----Original Message-----
From: Jacques Durand [mailto:JDurand@fsw.fujitsu.com]
Sent: Thursday, September 05, 2002 11:18 AM
To: Jeff Turpin; ebxml-iic@lists.oasis-open.org
Subject: RE: [ebxml-iic] Conformance Profiles

Jeff:

 

This grouping sounds better... I think interop tests from industry will certainly require some

specific conformance level, as prerequisite to their tests (e.g. UCC/DGI) (as our interop suites will)

but I don't think the various interop test profiles need be "helped" by tight association with some

matching conformance profile that would delineate what is to be tested: 

Interop tests are really of different nature (e.g. "large payloads", modes of accessing public key, etc.).

 

What can be done is: designers of an Interop test suite may point to which specific spec modules

are assumed to be implemented for this Interop test profile. So users preparing for such interop tests

can verify they qualify by running our conformance suite (the conf report would be detailed enough for this).

But we do not need to match every such conf requirements  with a formal conformance / certification level.

Would that address your concern?

 

(BTW, I assume you meant "...own custom interoperability profiles" not "...own custom conformance profiles"?)

 

 

Regards,

 

Jacques

-----Original Message-----
From: Jeff Turpin [mailto:jturpin@cyclonecommerce.com]
Sent: Thursday, September 05, 2002 9:30 AM
To: Jacques Durand; ebxml-iic@lists.oasis-open.org
Subject: RE: [ebxml-iic] Conformance Profiles

What I was hoping to do with these conformance levels is to group them together and create 2 or 3 conformance profiles. My intention was that by creating more detailed conformance levels, industry interop efforts could also mix and match these conformance levels to create their own custom conformance profiles. Thoughts?

 

-----Original Message-----
From: Jacques Durand [mailto:JDurand@fsw.fujitsu.com]
Sent: Wednesday, September 04, 2002 5:20 PM
To: Jeff Turpin; ebxml-iic@lists.oasis-open.org
Subject: RE: [ebxml-iic] Conformance Profiles

Jeff and al:

I am concerned that we will end-up with too many profiles of conformance...
(remember the group decided on a very small number last year after discussions,
choosing between 2 and 3 levels.)
The rationale behind this is:
We need also to consider the meaning of these conformance profiles in relation
to the notion of "certification" for the market.

A few things the group considered last year are:

- a very small set of certification levels(/profiles) that vendors would
strive to comply with, will promote the implementation of similar sets of features
from one implementation to the other, increasing their chance to interoperate globally.

- So every party, and buyers as well, know how to compare a vendor's MSH with another MSH
(e.g. used by their partners). They won't be faced with such tough choices as "my partner X
has profile 9 and my partner Y has profile 7, will I be OK with profile 8 and what kind of
interoperability will be supported?")
(no complex  compatibility chart to be used when you have only 2 or 3 levels...
there will be enough other parameters to make things more complex with interoperability parameters
and other intra-module options...)

- of course, nothing prevents vendors to implement the combination of feature of their choice,
(as long as optional modules permit) and even to advertize these.
Our test suite can still inform ad-hoc implementations on which spec module it passes,
which one it does not.
But such an MSH would still be *certified* for one of the few standard profiles, so the market knows
how to situate it globally, what can be counted upon by other certified partners.
The value added by vendors would also show-up in many aspects unrelated to conformance:
throughput, performance, recovery, application integration, manageability...

(Note that if we appear as if we try to support several module combinations,
we will have even more trouble to justify "favoring" one feature vs. the other, e.g.
why should "Ping"  take precedence over "message status", etc. Sometimes, taking
a bold and square approach, based on high-level considerations,
will reduce opportunity for disagreement!)

So I think we should consider this, when defining conformance profiles: the real
meaning is rather about certification and its implications on the market.
But I am open to other opinions on this.

Regards,

Jacques

-----Original Message-----
From: Jeff Turpin [mailto:jturpin@cyclonecommerce.com]
Sent: Tuesday, September 03, 2002 10:58 AM
To: ebxml-iic@lists.oasis-open.org
Subject: [ebxml-iic] Conformance Profiles

Per our earlier conversation regarding conformance levels/profiles, the
following levels/profiles map closely to the modules listed in the ebXML
2.0 Messaging specification. Thoughts?

Conformance Level/Profile 1: Core Modules
                                Modules:
                                        a. Security Module
                                        b. Error Handling Module
                                        c. SyncReply Module

Conformance Level/Profile 2: Message Service Handler Ping Service
(requires Conformance Level/Profile 1: Core Modules)

Conformance Level/Profile 3: Reliable Messaging Module (requires
Conformance Level/Profile 1: Core Modules)
                                Modules:
                                        a. AckRequested/Acknowledgment
                                        b. DuplicateElimination
                                Reliable Messaging Parameters/Behaviour:
                                        a. Retries
                                        b. Retry Interval
                                        c. TimeToLive
                                        d. PersistDuration
                                        e. syncReplyMode

Conformance Level/Profile 4: Message Status Service (requires
Conformance Level/Profile 2: Reliable Messaging Module):
                                Modules:
                                        a. StatusRequest/StatusResponse

Conformance Level/Profile 5: Message Order Module: (requires Conformance
Level/Profile 2: Reliable Messaging Module):
                                Modules:
                                        a. MessageOrder

Conformance Level/Profile 6: Multi-Hop Module: (requires Conformance
Level/Profile 1: Core Modules)

Conformance Level/Profile 7: Multi-Hop Reliable Messaging Module:
(requires Conformance Level/Profile 2: Reliable Messaging Module)

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>