Interoperability Goal (long)

Currently, DAG001 reads:

       D-AG001 Interoperability

The Web Services Architecture SHOULD enable the development of 
interoperable Web Services across a wide array of environments.


Comments that were made to this goal -- during the vote --  (as opposed 
to CSFs -- see below) seem to be slightly off the point:

Comment 1:

I do not like the word "platform".  Replace with "framework".

Use of the term in "platform independence" has a different meaning.  I 
understand platform to refer
to the combination of hardware and operating system.  platform-1 = x86 + 
windows, platform-2 = x86 +
linux, platform-3 = sparc + solaris, etc.

So when D-AG001 says "to provide a reference platform", it could mean 
that we'll describe the
architecture in terms of platform-x, and it is an exercise for the 
student to extrapolate to a
different platform.  I don't think that's what we intend, so I think 
"framework" works better.

Comment 2:

An architecture is not a platform.  May just be nomenclature issues here.

Proposal:

I see no problem with the goal itself. Indeed, if there were, we would 
be in some trouble ;-)

==========================

The current wording of DAC001 is:

D-AC001

provides a complete reference framework that encourages the development 
of interoperable software products from multiple vendors and provides a 
defensible basis for conformance and interoperability test suites

Comments to this CSF during the vote were:

Comment 1:

Replace the current text with:

provides a reference platform that integrates existing specifications 
and standards to support Web
Services interoperability across multiple 
platforms/applications/programming languages.


Comment 2:

  I think we need to further discussion. I'm not sure what "complete" 
adds.
I don't like using the term "products" and "vendors" unless we make a 
statement that open source
software can be considered products and the developers who contribute to 
the project are considered
vendors.
We also need to discuss the notion of test suites for the reference 
architecture.

I can see a test suite for a protocol spec, which conforms (fits nicely 
into) one or more areas
(components) of the web services architecture.

Comment 3:

An architecture is not a framework.  Also concerned with the last part:
"and provides a defensible basis for conformance and interoperability 
test
suites".  What does this mean?

It is unclear why and how conformance and interoperability are related in
general, at least at the architectural level.  A correct implementation 
of
the standards identified in the architecture seems two steps removed.

My comments:

The heart of this CSF is that by offering a reference implementation you 
make it easier for people to understand a proposal and it serves as a 
kind working model that can capture many semantic characteristics that 
are hard to write down on paper. For an architecture it is harder to 
build a reference implementation but the intention is similar.

Proposal:

I would suggest that we try to capture the laudable intention thus:

provides a reference architecture that includes all the elements 
necessary to ensure interoperability between multiple implementations of 
web services and provides a demonstrable basis for identifying 
conformance and interoperability test suites


===============

D-AC001.1 Was accepted in the vote, the requirements document needs to 
be updated accordingly.

===============

D-AC001.1.1 reads:

Ensure that no individual implementor is favored over others.

Comment 1:

out of the scope

Comment 2:

How are we going to achieve this goal?

Proposal

That we drop this requirement as being too motherhood and apple-ish; and 
furthermore not reflecting political reality!


================
D-AC001.2

Ensures that the development of standards-based technologies identify 
conformance in such a way that testing software can be constructed

Voting comments were:

Comment 1:

replace it with:

Liaison with WS-I Testing WG to ensure that the development of 
standards-based technologies identify
conformance in such a way that testing software can be constructed

Comment 2:

Sounds awkward to me.  Other working groups would be responsible for 
producing protocol specs
that are testable.  I don;t see how the architecture document 
"ensures ... that testing software can
be constructed."

Comment 3:

Since we do not develop technologies, does this imply that we impose 
conformance requirements on the WGs we charter and, potentially, on 
previously chartered WGs in the W3C WS Activity?

Comment 4:

  This is definitely too ambitious for a reference architecture.  That's 
a job for an
individual specification.

Proposal:

D-AC001.2 should be removed as it would be would be subsumed by the 
proposal above for the requirement as a whole.

================

D-AC004 currently reads:

     does not preclude any programming model

    D-AC004.2 Interfaces to web resources must be properly defined and 
designed.

    D-AC004.3 Focus on defining the architecture in terms of components 
and the relationships between them. Components are defined in terms of 
interfaces, that define their inputs and outputs and also the form and 
constraints on those inputs and outputs. The relationships between 
components are described in terms of messages and the protocols by means 
of which these messages are transmitted among the interfaces of the 
components that make up the architecture.

     The Web Services Architecture should:

          AR004.2 provide well-defined interfaces for Web Services

     D-AR004.3 use XML based techniques for defining messages/protocols 
for invoking web resources

Comments during the vote:

Comment 1:

The Web Services Architecture must allow the development of secure 
online processes.

Comment 2:

  replace it with:

ensure platform and device independence of Web Services to support 
interoperable standardized
programming languages

Comment 3:
I think that saying that we are not going to "assume any particular mode 
of communication
between the individual components" is not well stated and/or not really 
true.  See D-AR004.3, which
says that the architecture will use "XML based techniques ..." (which I 
think is well stated,
incidentally), the charter of the WG and so on.  If there is something 
really to be said here I
think it should be said more accurately.  Otherwise I think that this 
statement should not be made.

In like spirit, it would seem to me better to say that one will not 
assume any particular
programming model rather than that no programming model will be 
precluded.  The latter statement is,
in my view, asking for trouble since it could be interpreted to include 
really nasty, stupid or
unsafe models.

Comment 4:
see: http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0096.html

Comment 5:
I don't know what is meant by "mode of communication".  It's important 
that we be specific here,
because it could be used to exclude otherwise valid technologies based 
on people's interpretation of
what it meant to them.

My comments:

The CSF here can be informally re-expressed as "I don't care how you 
implement the service as long as it works"

In particular its not true that we wish not to preclude any programming 
model: we do wish to prevent models that don't implement the web service 
properly.

More formally, we might say:

Proposal:
The WSA should ensure proper separation of implementation from 
specification, allowing, for example, multiple implementations of 
equivalent specifications to interoperate.


=======
D-AC004.2

Comment 1:
  replace it with:

Define and design web resources interfaces to ensure interoperability.


Comment 2:
What is a web resource?


Comment 3:
  I'm not sure what "properly" means.

I envision an architecture diagram with boxes that represent 
"components" and lines between some of
them to represent "interfaces".  The architecture would describe the 
functions of the components and
the interfaces at an abstract level.  (I don't know if that means XML 
Infoset, since SOAP 1.2 uses
that and I'm not sure what would be more abstract than Infoset).  Other 
WG's would use these
abstract descriptions to design more concrete definitions of the 
functions and interfaces, while
still leaving room for different implementation.  "Properly" means at 
the right level of abstraction
to be useful to WGs that design protocols, but not too prescriptive 
(unless we really decide to
limit choices for some good reason, like interoperability; ah, a 
tradeoff!).

Comment 4
This is a nice goal, but has little to do with this AC004.

Comment 5
Any design we do should be done properly, so I think that the design
part of the goal is unnecessary.

Originally, D-AC004.2 was talking about Web components. I asked
whether components were resources, and the goal was updated. I now
wonder if the CSF didn't want to talk about Web services. If not, I
don't think that it is our job to define the interface to a Web
resource, and it is already done: get a representation of a resource,
get metadata about this resource, store specified entity, etc.

My comments:
A modern way of separating implementation from specification is through 
interfaces: we offer a public interface and let anyone implement to that 
interface.

Proposal:
Drop in favor of a revised AC004.3 below.

============

D-AC004.3

currently reads:

Focus on defining the architecture in terms of components and the 
relationships between them. Components are defined in terms of 
interfaces, that define their inputs and outputs and also the form and 
constraints on those inputs and outputs. The relationships between 
components are described in terms of messages and the protocols by means 
of which these messages are transmitted among the interfaces of the 
components that make up the architecture.

Comment 1:

  not clear what the critical success factor is.

Comment 2:

This is phrased neither as a CSF nor a requirement.

Comment 3:

  I guess I'm having some trouble understanding the difference between 
"relationships between
components" and components being defined interms of "interfaces".  I can 
see "interfaces" being like
a layer 2 (OSI) data link protocol or even a transport (layer 4), and 
the "relationship" being
higher layer messages and protocols.  Maybe that has too much of a 
network topology focus.

To use the OSI analogy, we sometimes see a 7 layer stack of boxes with 
vertical lines between them;
this stack lives in a single end-system.  We also see diagrams showing 
two end systems (each with a
7 layer stack), and horizontal lines between adjacent layers to 
reprenent peer-to-peer protocols.
Sometimes the vertical lines are considered "interfaces".

I envision multiple views of the web services architecture: some that 
represent the components of
the architecture than live within an end-system or intermediary, and 
other views that show
connections between like architectural components in two or more 
machines (similar to the horizontal
P2P lines in OSI diagrams).  It may be an end-system publishing to a 
registry, not necessarily P2P.

Anyway, getting into protocols and messages transmitted among interfaces 
sounds a little too
concrete for an architecture document.

Maybe using the term "interactions" instead of "protocol" and the term 
"information exchanges"
instead of "messages" would help set this in the proper abstraction 
level.  A WG would convert the
interactions into particular protocols sequences, and would map 
information exchanges into messages.

SOAP 1.2 introduces the "Message Exchange Pattern" (MEP).  Perhaps the 
architecture would deal with
certain MEPs.  Then, as in SOAP 1.2 Part 2, the MEP can be cast onto a 
particular binding.

Comment 4:

This is a good goal. However, I do not see strong relevance to 
programming models, modes of communication, or even platform 
independence.

My comments:

A reasonable definition of an architecture is the set of "components and 
the relationships between them". I believe that we could make this 
requirement simpler and crisper.

Proposal

This replaces D-AC004.2 and D-AC004.3

The web services architecture shall consist of a set of components and 
the relationships between them. Components are defined in terms of 
interfaces that define constraints on the behavior of the components.

==============

D-AR004.3

currently reads

use XML based techniques for defining messages/protocols for invoking 
web resources

This was accepted, however, some comments were:

Comment 1:

  s/resources/services/

Also, how about using XML based technologies for describing
and discovering web services. Why is just invocation mentioned?

Comment 2:

  Again, I think that we are talking here about services, not resources.
This is related to the discussion of whether you need XML to invoke a
service, and I am not convinced that the answer is yes yet.

We've been down this road several times, but I don't think that we
ever reached a conclusion. What if the very last step of a complex
transaction involving many individual services is an HTTP GET request
(with some parameters computed from the previous interactions)
returning a PNG diagram?

My comment:
This requirement doesn't directly follow from the CSF, but I would hate 
to be the (first) person to suggest that we shouldn't use XML ;-)


Proposal:

  s/resources/services/


================== (nearly there)

D-AC016 currently reads:

examine architectural and technology issues that might prevent 
interoperability, and recommend existing standards and technologies 
where available. Also to recommend the formation of new Working Groups 
to develop areas of the Web Services Architecture where the need for 
standardization and specification has been identified.


Voting comments:


Comment 1:
Unclear what "examine architectural and technology issues that might 
prevent
interoperability" means.

Comment 2:
Separate the two CSFs. Move the latter to a team goal as it is not an
interoperability specific issue.

Comment 3:

The recommendation of forming new working groups is applicable for all 
the
Web services requirements not just for D-AG001 Interoperability goal or
D-AC016, therefore, should be a separate requirement.

My comments:

I fail to see how a CSF relating to forming additional WGs belongs in a 
specification document. However, making sure that we play nice with 
existing standards is critical

Proposal

Identify those architectural and technology issues that might prevent 
interoperability, and to reference existing standards and technologies 
where available.

========
D-AR016.4 Currently reads

           Formation of WGs to address gaps

                 D-AR016.4.1 in architectural realms
                 D-AR016.4.2 in technological realm.

Comments:


Comment 1:

  Out of scope. Change "formation" to "recommendation"

Comment 2:
Not clear what the text means.

Comment 3:

We *are* the WG for the architectural realm, no new WGs needed.

Comment 4:

This does not follow from D-AC016 (which says "... recommend the 
formation
of new WGs to develop areas of the Web Services Architecture ..."). Will 
we
be recommending the formation of WGs to address technology gaps?


Proposal:
s/formation/recommendation/

Received on Monday, 15 July 2002 14:46:38 UTC