Re: [ebxml-msg] RE: COnformance Clause

[Christopher Ferris <chris.ferris@sun.com>]

Jacques,

Please see below.

Cheers,

Chris

Jacques Durand wrote:

> Doug:
> 
>  
> 
> see comments in line.
> 
>     -----Original Message-----
>     From: Doug Bunting [mailto:dougb62@yahoo.com]
>     Sent: Tuesday, December 04, 2001 12:47 PM
>     To: ebxml-msg@lists.oasis-open.org
>     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


If you will recall, the TC did agree at the last F2F that there
*was* indeed a requirement for a CPA between parties. Whether that
CPA is in the physical form of a CPA document as defined by the CPP/A
spec is for the parties to decide. The key point was that the
CPAId needs to be able to be resolved to the information that
is expressed in a CPA so that the MSH can function. How this
information is represented inside an MSH implementation is
immaterial and up to the vendor to determine.


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


You are missing the whole point of the CPP then. The CPP defines
the technical bindings for (potentially) all of the services/business
processes supported by a party. The party wishing to engage another
simply looks for the business process that they wish to use and
drills down to the specifics of which features are supported, etc.


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


The marketplace you describe could also simply state that
prospective users of the market place are required to have
an ebXML MSH which supports the following features as well
as being conformant with the core features specified in the
ebMS v1.1 spec. Let the vendors determine for themselves which
of the optional features to support based on their customer's
or prospective customer's requirements.


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


I don't think that Doug was suggesting that the conformance
level would be a percentage like "75%" or "45%" I think he was
generalizing.


> 
>      
> 
>     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 that it is the prerogative of the OASIS Messaging TC
to determine what is core, not IIC. If there is disagreement
among the IIC members as to what should be considered core, then
I would encourage them to formally join the Messaging TC so that
they can make their views count through votes.

That aside, let me explain why RM is not in core ( as I believe
that is the one which seems to be the most contentious of the
"optional" features/modules.) The RM protocol is provided for
use with protocols that are inherently unreliable such as HTTP
and SMTP. If the ebXML MS were bound to a reliable protocol,
then the RM feature would be unnecessary overhead. In addition,
since the RM feature is fairly heavyweight, it seems to me
that a perfectly valid use of the ebMS is in "best effort"
mode for use by SMEs lets say to enable them to conduct
business, yet without the overhead of full-blown reliability.
In conjunction with a synchronous use of the ebXML MSH,
RM is also potentially unnecessary overhead for a simple
implementation.

Now, if you wanted to define a *profile* of the ebXML MSH that
included the HTTP/S transport binding and the RM module, that
would be fine. However, a *profile* of the specification is
IMO quite distinct from a conformance specification. Conformance
IMO deals with the likes of testable assertions that can be
applied to an implementation that can be used to ascertain
the level/degree of conformance with what has been specified
that is tangible and can be presented to a prospective customer.

A conformance clause for the ebMS spec should be (IMO) that
an complaint/conformant implementation SHALL pass the test
suite defined <a href="here">here</a> by the OASIS ebXML IIC TC.
For optional features, if supported, then the corresponding test
cases must be passed. For unsupported features, the test assertion
may fail...


> 
>     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 <mailto:JDurand@fs.fujitsu.com>
> 
>     To: ebxml-msg@lists.oasis-open.org
>     <mailto:ebxml-msg@lists.oasis-open.org>
> 
>     Cc: Jacques Durand <mailto:JDurand@fs.fujitsu.com>
> 
>     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
> 
>      
>