W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2002

D-AG0007- reliable, stable, predictably evolvable - v0x1

From: Damodaran, Suresh <Suresh_Damodaran@stercomm.com>
Date: Fri, 8 Mar 2002 19:17:36 -0600
Message-ID: <40AC2C8FB855D411AE0200D0B7458B2B07C59361@scidalmsg01.csg.stercomm.com>
To: www-ws-arch@w3.org

Please consider this proposal.

D-AG0007 Proposal
[1] states D-AG0007 as:
"To develop a standard reference architecture for web services that is
reliable, and stable, and whose evolution is predictable over time"
The goal of this proposal is to identify some "critical success factors"
that will help in evaluating these attributes in the emerging architecture,
as well as define the requirements the architecture must meet to attain
these attributes.
This document does not address the critical success factors, though it does
the requirements. I would argue both are the same in this case.

General Analysis of D-AG0007 statement

The goal is to ensure the architecture is reliable, stable, and evolvable. 
The goal is NOT to ensure web services themselves are reliable, stable, and
I find this distinction a bit amusing, in that we could potentially have a
very reliable,
stable, and evolvable architecture that does not ensure the same things
for the web services built with it! I will stick to the stated goal of
ensuring the architecture has the stated goal, and visit the non-goal if
there is public outcry(personally, I think the non-goal is more useful).

Reliability of Architecture
Note on glossary: Since the WS Arch. would be a framework of standards,
I refer to the components of architecture as standards.

Reliability is measured against some deliberate/non-deliberate abuses
on the architecture. Let me recount such potential abuses:
	RA1. Implement the interface specified in a standard incorrectly,
	and complain it doesn't work with another standard within the
	RA2. Extend a standard so that it does not work with another
	RA3. Specify a standard using/depending on at least one proprietary

 To ensure that the architecture is reliable it should demonstrate the

	R1. All standards should be versioned.
	R2  Each release of the WS-A also should be versioned with the
versions of the standards that go in the WS-A. Such a consistent set of
versions will be called a "C-set" - for consistent set.
	R3. Each such combination, as in R2 must be tested with a set of
conformance tests.

	R4. Extension to a standard by anybody must be submitted to WS-A
with a C-set and
	a set of conformance tests.
	R5. Non-circular standards: Each standard in the architecture should
be specifiable without the use of another standard within the framework.
	R6. Each standard or the architecture itself should be dependent on
non-proprietary standards - standards developed  within open standards
bodies (W3C, ISO, OASIS,...), where anybody may join and participate in the
standardization process by paying the requisite dues. (In the absence of R6,
even a single vendor could make WS-A unreliable).

Stability of Architecture

	Stability means a reliable C-set (see R2) does not change

To ensure that the architecture is stable, it should demonstrate the

	S1. WS-A will limit a new release of C-set to once in two quarters,
unless serious bugs appear.
	S2. Only WS-A has the right to release new C-sets

Predictable Evolution of Architecture

I am not sure we can predict the exact way an architecture may evolve. Steps
may be taken to ensure that the evolution is along understandable guidelines
or axes, though.

To ensure the architecture is predictable evolvable, it must demonstrate the

	PE1. The architecture has identified axes for evolution of the
	For WS-A, a suggestion of axes are the following [2].
		unique identification,  - URI/2nd order IDs/...
		independent specification, - WSDL/vocabulary/ontology
		interaction - XMLP/intermediary/collaboration/patterned

	PE2. Each standard must be mappable to one of these axes. 
	(I am inclined not to include a standard within the architecture
that is mappable to only two or more of these axes, because, then I almost
tend call it an non-core standard, outside the scope of WS-A)

	PE3. The definitions of the architectural elements should be, as far
as possible, devoid of jargons and technical terms that may be irrelevant in
10 years
	PE4. Extension guidelines should be specified for each standard.


[1] http://www.w3.org/2002/ws/arch/2/wd-wsawg-reqs-03042002.html
[2] http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0113.html

Received on Friday, 8 March 2002 20:18:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:54 UTC