RE: Summary D-AG0007- reliable, stable, predictably evolvable

I suspect the CSFs listed in the summary sent earlier look more like
requirements.
Therefore, I am taking a fresh stab at CSFs. 
[Editors: please list the earlier CSFs as Requirements as appropriate]

Reliability of Architecture
	CSF 1. WSA ensures the reliability of components/standards used and
recommended by providing accurate and precise identification of the
standards, clear description of their interdependencies, and clear
guidelines for consistent use of the standards.
	CSF 2. When recommending the use of specifications developed outside
of W3C, WSA ensures they are reliable and stabile.

Stability of Architecture
	CSF 3. Any standard within WSA will be changed with proper
considerations for its interoperability with other standards within WSA, how
it is used in its customer base,  as well as how the standard may evolve.
	CSF 4. WSA ensures changes to a standard within WSA is specified
clearly with respect to the existing version.

Predictable Evolution of Architecture
	CSF 5. WSA has a framework for its evolution.
	CSF 6. WSA can map its components to this framework.
	CSF 7. It is possible to predict the extensions of components and
new components of WSA when a set of constraints are applied to this
framework.
	CSF 8. WSA promotes the "principle of partial understanding[3]" in
its standards.




-----Original Message-----
From: Damodaran, Suresh 
Sent: Friday, March 29, 2002 5:22 PM
To: www-ws-arch@w3.org
Subject: 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 Monday, 1 April 2002 15:44:24 UTC