[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Turpin 9/7/2002: [ebxml-iic] Conformance Profiles
Keep it simple and discrete.
Allow for aggregation of profiles (and the capability to track that)
within interoperability
Could aggregation concept be used to across conformance and
interoperability?
Just a thought.
Monica
-----Original Message-----
From: Jeff Turpin [mailto:jturpin@cyclonecommerce.com]
Sent: Thursday, September 05, 2002 12:27 PM
To: Jacques Durand; ebxml-iic@lists.oasis-open.org
Subject: 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
<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
<http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC