RE: "Conformance" discussion on WSA document

This seems to me to be in the right general direction, and a brave
attempt, but in detail to be a bit rough.  The two initial bullets seem
"right on" to me (see footnote at end of note), but then I think there
are some problems.  I'm going to try as hard as I can to suggest
improvements, but I'm afraid that some of this is just going to be
whining with no positive suggestion.

1 - "language that can be mapped into WSDL" -- this sounds backwards to
me.  If a language is richer than WSDL, I think WSDL might be mapped
into it but probably not the other way around.  Moreover, one could have
a language "at least as rich as the WSDL conceptual model" which has a
different structure so that mapping either way doesn't really make
sense.  I'm trying to figure out how to make this mapping thing work,
but I'm having difficulty.  Perhaps the best way is simply to say that
the statement in the architecture imposes a requirement on the spec ...
Period?  An exercise to the reader to figure out how to impose that
requirement in each particular case?

Personally I am very uncomfortable with anything that equates "Web
service" narrowly with "WSDL", for reasons that I think I have detailed
previously.  Exemplar, Si -- specific requirement, No.

2 - "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.".  I'm sorry, I guess I just don't
understand this -- how one statement follows from the other.  They seem
to me to be about two entirely different things -- one says that a
message is between two agents that correspond to different services
(more or less), the other refers to things that happens inside the shell
of the turtle (I think).  If there is a better meaning I think you
should clarify.

3 - "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."  Do we really mean that?  I think that we have seen usage
cases in which anonymous access to Web services is a requirement.
Health care industry, for example.  Perhaps I am not understanding
correctly what is meant?

4 - "Unlike language specifications ... corresponding relationships
implied by conformant specifications."  This looks to me like it's
basically in the right direction, but that as it is currently stated I
think it may be too strong because it seems to imply that EVERY concept
and relationship must be expressed in EVERY spec.  GAG!!

5 - "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."  Well stated.  I think you've got
exactly the right balance here.  However, when you go onto specifics, I
don't understand your "normative assertion" about RM.  I'm afraid I
don't even have a clue what is in the back of your mind on this one, so
I don't know what to suggest.  Maybe that somebody look at the infant RM
section I contributed and mess around with it so it actually does make
some reasonable normative statements.

OK, well let me give a more detailed analysis a shot here.  I think your
"design techniques" that increase reliability (at the app level, I
think) are a red herring here and should not be mentioned.  Recall,
"Reliability" is the big concept (including potential implementations at
all levels of the "stack"), but we specilize in the WSA to "reliable
messaging" which is implemented via an "acknowledgement infrastructure"
at the messaging level.  Stuff at other levels of the stack are out of
scope or a different subject. OK, so what is the requirement from the
WSA?  I guess that a spec not define some sort of messaging that somehow
makes it impossible to bolt on an acknowledgement infrastructure?  I'm
not sure how you'd do that, but perhaps by making it so tightly coupled
or proprietary that the "bolting" won't work.

********

Incidentally, about the second bullet and the "imposing order on
reality" vs "vision", I don't see any reason why one cannot do both.  In
fact, either one without the other would, IMO, make the WSA kind of
useless.  That is, a visionary architecture that ignored current reality
would be ... useless. An architecture that provides a conceptual
framework for current specs and no guidance for future specs would be
... Embarassing.


-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Friday, May 30, 2003 8:34 AM
To: www-ws-arch@w3.org
Subject: "Conformance" discussion on WSA document




[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 13:48:40 UTC