Summary D-AG0007- reliable, stable, predictably evolvable

Goal:

"To develop a standard reference architecture for web services that is
reliable, and stable, and whose evolution is predictable over time"

The most recent status is [1]. Some of the CSFs may overlap with CSFs of
some other goals.

Critical Success Factors:
[Some new ones came from the list, while the rest came from [2],
and are the products of my faulty imaginations. There are some new ones
too.]

Nomenclature: 
	reference architecture components are referred to as "standards"
below.

Reliability of Architecture

CSF RA1. All standards are versioned. 

CSF RA2. Non-circular standards: Each standard is specified without the use
of another standard within the reference architecture except when a standard
is an extension of another standard.
CSF RA3. A standard may depend only on non-proprietary standards - standards
developed  within open standards bodies (W3C, IETF, ISO, OASIS,...). 
CSF RA4. When a standard uses other standards outside of the reference
architecture, the exact versions of other standards will be specified. If
the other standards do not have version numbers, WSA will create and assign
version numbers and map to a particular
instance of the external standard [4].

[Some additional CSFs that have met resistance - listed here for wider
debate
D-CSF RA4 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.
D-CSF RA5. Each such combination, as in R2 must be tested with a set of
conformance tests.
D-CSF RA6. Extension to a standard by anybody must be submitted to WS-A
with a C-set and a set of conformance tests.
]

Stability of Architecture
-------------------------
Stability of Architecture is defined under the "force field" of the
reference architecture, i.e., when a standard changes, then the change will
be clear and consistent
with the rest of the reference architecture components [this is a funny idea
- but
this is all I could think of as a guidance]

CSF SA1. A new version of a standard will clearly describe its "backward
compatibility"
status with its earlier version in text.
CSF SA2. A new version of a standard will not conflict with other standards
in the reference architecture that do not conflict with the old version of
the standard.
[added for consistence sake]
CSF SA3. Evolvability in identified technologies/standards should be
considered up front
as much as possible from the point of view of interoperability with other
standards [to prevent hasty change of standards] [5] 


[Debatable:
SA3. WS-A will limit a new release of C-set to once in two quarters,
unless serious bugs appear.
SA4. Only WS-A has the right to release new C-sets
]


Predictable Evolution of Architecture
-------------------------------------

[We can predict evolution of architecture if we can understand its growth
within
an abstract framework. Using axes is one idea - so here it is]

CSF PE0. The reference architecture must define a framework for growth of
the architecture.

[
CSF PE1. The reference architecture should identify its axes for evolution.
	[e.g., independent specification of WS
		interaction with WS
		selection of WS
		measure WS]
CSF PE2. The standards should be mapped to these axes.
	[e.g., independent specification, - WSDL
		interaction - XMLP
		selection - ?
		measure - ?]
]

CSF PE3. Non-normative extension guidelines to be specified for each
standard

CSF PE4. Stagger "features" in a standard so that even software that
implemented only the     minimal features in the standard can interoperate
with another software that implemented more features
[to support "principle of partial understanding [3]]
CSF PE5. The version number is available for verification from the software
that implements the standard to support CSF PE4.


[1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0405.html
[2] http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0148.html
[3] http://www.w3.org/DesignIssues/Evolution.html
[4] http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0408.html

Received on Friday, 29 March 2002 18:22:15 UTC