RE: Seeking closure on D-AR019.1.1 and D-AR019.1.3

>Assess which categories are in good shape (e.g., description is probably
>in good hands with the WS description activity and WSDL, security *may* be
>in the good hands of the OASIS WS-Security TC), and which are not.- 

+1. I always thought this was one of the major responsibilities of our WG.

>Startup working groups in the W3C to build actual standards where they are
>not; "choreography" / " orchestration" / "coordination" comes to mind.

+1. If it is true, as I hope, that security is in the good hands of OASIS,
then that should free a good deal of resources within our WG. Orchestration
seems to me like a natural direction where to channel those newly available
resources.

Ugo

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
Sent: Wednesday, July 24, 2002 3:40 PM
To: WSA W3C Public (E-mail)
Subject: RE: Seeking closure on D-AR019.1.1 and D-AR019.1.3





> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Wednesday, July 24, 2002 5:21 PM
> To: Damodaran, Suresh
> Cc: WSA W3C Public (E-mail)
> Subject: Re: Seeking closure on D-AR019.1.1 and D-AR019.1.3
> 

> If I understand the position of the group (or at least of 
> those members who have spoken up on the topic), they see unreliability in 
> the network as an issue that has to be addressed.  
> And I agree.  But I also hear
> that they want it addressed by building a "transparency layer" which
> fits in above the unreliable network, and exposes a reliable network.
> I consider that a mistake.

This issue goes to the heart of what exactly we are trying to do here.
I [not speaking from the Chair, of course] think that what we're
doing is building a *reference* architecture within which to organize the
actual standards by which interoperable web services can be built. By way of
analogy, consider the architecture of physical buildings and the various
means by which components can be connected to one another. The current state
of the art might be likened to an earlier age where builders invented their
own means of joning pieces together -- with wooden pegs, iron fasteners,
tongue and groove fittings, and so on. Not only would it be generally
impossible for the work of two craftspeople to be used interchangeably, they
might not even understand each other's basic technology (when asked to build
the frame for a house, one might get out his forge and make nails, the other
get out a drill and whittle pegs). 

Our reference architecture essentially presents a way of organizing
technologies into more well-defined categories (e.g., "nails", "wood
screws", "nuts and bolts") so that web services builders and consumers can
have some confidence that they are talking about the same thing, and have
options about different suppliers or approaches to building a category of
component. It will also identify specific standards (comparable to standards
for the sizes and geometry of screw threads in the analogy) that need to be
defined to move to the next level of portability and interoperability.

So, in my view of what we're doing, there's no question that "the
unreliability of the network has to be addressed."  Some will choose to
address that in the application, and that has to be mentioned; some will
build one or more layers in the infrastructure with which to address it, but
those layers have fit in the rest of the architecture in a predictable way.
Our job is to disentangle reliability (and orchestration, various aspects of
security, etc.) from one another so that a) specs can be written for one
particular layer (or component, or protocol, whatever) that can be
independent of other layers; and b) vendors can build / consumers buy
implementations of those layers without having to buy into a whole paradigm
that is incompatible with other vendors' paradigms. 

So, IMHO out job is to:
 
- Sort out aspects of web services into categories that mesh with existing
theory, practice, and standardization.

- Assess which categories are in good shape (e.g., description is probably
in good hands with the WS description activity and WSDL, security *may* be
in the good hands of the OASIS WS-Security TC), and which are not.

- Startup working groups in the W3C to build actual standards where they are
not; "choreography" / " orchestration" / "coordination" comes to mind --
there are multiple proto-standards that don't use the same concepts, and
somebody needs to provide some perspective and guidance.

- Communicate all this to both the member companies who are looking for a
coordinated perspective, and to consumers who are looking for some order
amidst the chaos that our respective marketing departments have created :~)

... which is a VERY long winded way of suggesting that it is premature and
counterproductive to worry too much within this WG right now about whether
one strategy or another that end-users might consider is a "mistake" or not.

Received on Wednesday, 24 July 2002 21:20:12 UTC