W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2003

"Conformance" discussion on WSA document

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Fri, 30 May 2003 09:34:03 -0400
Message-ID: <9A4FC925410C024792B85198DF1E97E405C6EF70@usmsg03.sagus.com>
To: www-ws-arch@w3.org


[This is more of my "make sense out of the minutes from Rennes" action item.
There was a rather difficult discussion of "conformance" as we reviewed
section 2.1 on Wednesday ... this tries to propose a way forward that takes
into account the various comments.]


This text is currently in section 2.1 but we discussed in Rennes whether it
should be moved to the FUNDAMENTAL_CONCEPTS section or the INTRODUCTION.
What follows is a proposed re-wording based on what I understood to be the
very rough consensus in Rennes.  (I don't say that wearing my co-chair
"identify consensus" hat but my WG member "propose a strawman and see who
flames it" hat).

So, here's some proposed text, flame away, and please offer suggested
improvements.

----------------------------------------------------------------
WSA_CONFORMANCE

WSA "Conformance" is a difficult and controversial subject, for two basic
reasons:

- As a "reference architecture" it makes assertions about specifications
rather than about software.  It is not meaningful to say that a particular
product conforms with the W3C WSA, only that it implements a specification
that is consistent with the WSA.

- As the product of a consensus-driven industry consortium, it tries to
impose order on a somewhat chaotic reality rather than being a "top down"
design for how this should all work if it were just being invented. [1]

Nevertheless, the objective is to make testable normative assertions about
the desireable properties of Web services-related specifications and
standards. For example, the architecture asserts that [2] a Web service
interface HAS-A formal description in an language that is at least as rich
as the WSDL conceptual model. [I'm thinking of endpoints, interfaces,
bindings, operations].  That implies that Web service specifications SHOULD
document their interfaces in WSDL or a language that can be mapped into WSDL
... and it implies that future versions of WSDL should be conceptually rich
enough to describe the range of Web services interfaces allowed in the WSA.
Conversely, the architecture notes that a message is a unit of interaction
between software agents. This means that the architecture is not concerned
about messages between objects that are within an implementation of a Web
service. We also state that messages have a message sender; any
specification realizing this architecture that does not permit a message to
be associated with its sender is not in conformance with the architecture.

Unlike language specifications, or protocol specifications, conformance to
an architecture is necessarily a somewhat imprecise art. However, the
presence of a concept [in the CONCEPTS AND RELATIONSHIPS section] is a
normative statement [3] that, in any specification claiming to conform to
the architecture,  then it SHOULD be possible to map the relevant WSA
concepts onto features in the specification. [4]  Furthermore, if a
relationship is identified in [the CONCEPTS AND FEATURES section], then
there should be corresponding relationships implied by conformant
specifications. 

The WSA is not a foundation on which real interoperability can be defined,
but without agreement on the core concepts and relationships, it is unlikely
that different Web services "stacks" will align in a way that fosters
interoperability.  For example, the WSA defines [5] the concept of "reliable
messaging".  There are multiple technologies by which reliable messaging can
be implemented, and design techniques that allow reliable applications to be
built without a reliable messaging infrastructure. It is unrealistic to
expect the WSA or W3C to define the "one true reliable messaging
specificiation" that will ensure universal interoperability, but it is a
realistic goal to make the normative assertion that the reliable messaging
"box" be as loosely coupled as possible from other "boxes" in an actual
implementation architecture.  [6]

--------------------------------------------------------------------

[1] Walden took issue with me privately on this sentiment.  It is not
clearly stated in our charter or requirements that we are trying to impose
an ordering scheme on existing reality and that our goal is to reflect
consensus rathe than vision, but that seems to be the practical reality we
are in. Does anyone think that we can legitimately and realistically aspire
to be more visionary? Individually we could probably all come up with a
cleaner and clearer vision than we can collectively, but who pay attention?

[2] Obviously I'm guessing about what we will eventually agree to here.

[3] Is that too strong?  I know there was a lot of discomfort about the word
"normative" in Rennes ...

[4] Sorry, words don't come to describe this well ... basically, if a spec
is relevant to some "area" of the WSA "space", then it SHOULD be possible to
map its features from the WSA concepts in that space.

[5] Again I'm anticipating a future draft ...

[6] I'm struggling to say "we want to help avoid another COM vs CORBA war"
without saying that bluntly :-) Obviously "boxes" is not a good term here.
Received on Friday, 30 May 2003 09:34:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:19 GMT