Title: RE: [ebxml-msg] Re: Use cases for messageOrdering
Doug:
see
comments in line.
-----Original Message-----
From: Doug Bunting
[mailto:]
Sent: Tuesday, December 04, 2001 12:47
PM
To:
Subject: Re:
[ebxml-msg] RE: COnformance Clause
To restate some of what I said on this topic during the
face-to-face meeting: This seems to be on a collision course with
Collaboration Party Profiles. Rather than having an enterprise say "I
support the MSH features described in the CPP", the IIC team would like them
to say "My MSH is conformant at this level". This doesn't appear
particularly worthwhile and goes against the mix-and-match nature of the
features we've included in the specification.
[Jacques Durand]
Seems to me there is confusion going on between
conformance and CPP. First of all, an MSH implementation does not require the
existence of a CPP/CPA, at least in 1.1. Even so, it would not make much sense
for a user/enterprise to say "I support the MSH features described in the
CPP". Which CPP? An enterprise will use an MSH to support many business
processes, requiring different CPP/CPA values. Conformance levels are a way to
define broad categories of MSH implementations - but not too many, so that
functional mismatches between communicating MSH is reduced upfront and at
least well understood. A marketplace can tell its trading parties: "you'll
need a level 1 MSH." That in fact defines a class of communication and QoS agreements (e.g. as
in CPA) that the market place expects you to meet.
In reality, there's three levels here:
1. A MSH may support 95% of the ebXML-MSH
specification. Side note: The other 5% MUST result in SOAP
mustUnderstand Fault or an ebXML error.
The current IIC
definition of "weak conformance" doesn't seem to require errors
when an unsupported features is requested, just when that feature
corresponds to a top-level SOAP extension. The phrase "behave
consistently either as if the feature were absent from the material..." allows
a receiving application to silently ignore requests for unsupported features,
violating the requirements we've specified.
[Jacques Durand] I concede the current wording of "weak conformance" leaves a lot
to the implementors on the way to handle unsupported features, as it requires
errors (always for mustUnderstand SOAP faults) only if this causes
"undesirable behavior" otherwise. We can fix this. But frankly, I would rather
see the level of warning as configurable. The reason is, generating an error
message each time you do not support a feature in another message may create
unacceptable overhead - and annoyance - in some deployments. (Could we relax
the "error notification" required in 1.2.4? or make it OK to log the error
locally?)
2. The enterprise managing the MSH may choose to advertise
their support for 75% of the ebXML-MSH specification. They will
configure their MSH to reject requests for the other 25% as described
above or no longer be a conformant MSH implementation.
3. Two parties interacting using their MSH implementations
will choose to collaborate using 45% of the ebXML-MSH specification.
Again, requests for the non-contract 55% over this channel will consistently
result in an error.
[Jacques Durand] The notion of conformance level is precisely there to not have
to define what "75%" or 45%
means. I frankly would not know
what to do of a vendor who sells "75% conformant" MSHs. I would not know
upfront if I that would be good enough to do business with my partners, one
having a 70%, the other a 80%, etc... But if my trading partners have all
decided to use Level 1 conforming MSH, then I know what to shop for, and I
know there will be no surprise. (Furthermore, I know I am OK with a Level 2
MSH...) We see conformance levels really as a product attribute.
While CPP and CPA documents might be used to describe the
supported features at some of these levels, they aren't a necessary
condition.
Depending upon the configuration of the MSH, features
rejected at levels 1 and 2 might (MAY) result in SOAP mustUnderstand
Fault errors. Because level 3 rejections require checking the partner
agreements and therefore invocation of the ebXML handler, features rejected at
that level should (MUST?) never result in such a Fault.
I would propose a conformant MSH implementation MUST include
support for all Core Features in the specification and errors MUST result
whenever a request is received for a non-supported, non-configured or
not-contracted feature. Any optional feature implemented MUST be
supported in accordance with the "strong conformance" requirements.
That's it.
[Jacques Durand]
See my comments before. I agree that the "core
features" should match the lowest level of conformance. Note that NOT everyone
agrees what should be in "core"...
I believe the current "core/additional"
partition is the only thing that may collide with a conformance clause (as it
is one in itself). Not the CPP/CPA.
Thanks for commenting,
Jacques
Since we've already required most of these errors, it's
unclear a new clause is necessary in the document.
thanx,
doug
----- Original Message -----
From: Jacques
Durand
To:
Cc: Jacques Durand
Sent: Monday, 03 December 2001 14:11
Subject: [ebxml-msg] RE: COnformance Clause
Hi all:
In order to
prepare for the conformance agenda item (next conference call, next
week)
here are the two candidate conformance clauses for MS 1.1 that are most favored by the
IIC group (Options 2
and 3),
for your review. (Option 1 was
"all or nothing" conformance.)
A
conformance clause should normally be included in the final spec
document.
IIC is
actually recommending Option 2 ( 9
members preferred it, while 4 members preferred option 3)
As voters
could also express - or not - second choices, we actually used a "weighted"
vote that reflects more precisely
the total
preference for each option (weight=3 for most preferred, 2 for second if any
is mentioned, 1 for third if any mentioned).
Result
is:
33 (thirty
three) for Option 2,
30 (thirty)
for Option 3,
8 (eight)
for Option 1.
I think this
vote - starting with the design of the clause candidates - indicates how
important
some
features like Reliability and Ordering have been
perceived.
You'll note
that a special attention has been given to the interpretation of the keyword
"optional" , as
this used to
cause some trouble in past MS POC performances (see "definitions").
.
Note
that these clauses define
conformance levels (rather than profiles),
based on implementation
and usage investigation
(see the "rationale"
section at the end)
These levels do
not attempt to match functionally all possible profiles/agreements (CPP/A),
but should rather be considered as properties of the MSH implementation
itself -
establishing a few broad classes of implementations (yet coherent
from usage perspective),
so that the
number of MSH certification options can be limited.
(A same
conformance level roughly guarantees the same CPA playing field for all communicating
parties,
supporting several usage
profiles, the detailed definition of which being done/enforced at
CPP/A level.)
Regards,
Jacques Durand
Fujitsu Software
IIC, conformance clause group
