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

Please consider this proposal.
Thanks,
-Suresh                           

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
address
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
evolvable.
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
architecture.
	RA2. Extend a standard so that it does not work with another
standard.
	RA3. Specify a standard using/depending on at least one proprietary
standard.

 To ensure that the architecture is reliable it should demonstrate the
following.

	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
arbitrarily.

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

	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
following.

	PE1. The architecture has identified axes for evolution of the
architecture. 
	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
communities

	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.


References

[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