Closing AG005 issues - AC003 CSFs

I'm championing the cause of getting closure on this goal and the associated
CSFs.

============================================================
"AG005 Scalability and Extensibility -- the web services architecture must
promote implementations that are scalable and extensible.

Critical Success Factors for this goal: 

D-AC002 provides modularity of Web Services components, allowing for a level
of granularity sufficient to meet business goals

AC003 is sufficiently extensible to allow for future evolution of technology
and of business goals

D-AC005 applies the principle of simplicity and is defined such that it does
not impose high barriers to entry for its intended audience

D-AC017 provides guidance for the development of the Web Services
infrastructure needed to implement common business functions in a
standards-based environment

====================================================================
So we've agreed on the wording of the goal and the "is sufficiently
extensible" subgoal, and have a lot of work to nail down or eliminate the
others.
My bias, as I've said before is to a) eliminate 'motherhood' statements that
have little real meaning to us; and b) "when in doubt, throw it out".  

I'll deal with the AC003 CSF in this message, and send separate messages for
the others.

"D-AR003.1 separates the transport of data or means of access to Web
Services from the Web Services themselves."  The intent here seems to be
that web services architecture should be neutral with respect to the
mechanism by which the producer and consumer of the service exchange data. 

On the preliminary ballot, there were 12 Y's, 2 L's, and 1 D.  The
disagreement comes from the REST perspective that stresses the difference
between "application" and "transport" protocols.  The counter-argument is
that services may be accessed across protocol bridges, and there is a use
case for "tunneling" over HTTP even if this is not best practice for the Web
itself.  This has been extensively discussed, with no resolution in sight.
I suggest we vote; if a supermajority agrees to keep it in, remove the draft
status.


"D-AR003.2 description of Web Services be clearly separated into abstract
descriptions ("what") from their concrete realizations ("how"), or put
another way, separate design time aspects from run-time aspects".  The
intent seems to be to require the WSA to favor "declarative" rather than
"procedural" definitions, i.e. to define what happens, not how it happens.
This is related to the scalability goal because it is widely believed that
declarative approaches give the implementation much more scope to operate
efficiently, whereas procedural descriptions are too constraining.  For
example, SQL queries just specify the characteristics of the result,
old-style hierarchical database  queries specified how to navigate the
structure to find the result, and SQL has proven much more scalable.

The preliminary balloting was Y 10, L 3, D 1, O 1.  The "O" vote suggested
that it's an issue for the WSD WG.  Others suggest it's not clearly enough
worded.  In the mailing list Dave Hollander believes it's out of scope: "I
believe the idea comes from the often discussed modeling practice of
separation of abstract (what) from concrete (how). Unfortunately, there are
often reasons to violate this principle and there is disagreement in the
modeling community in where the line sits."  Others disputed the equation
between "abstract/concrete? and "declarative/procedural", and suggested a
re-wording to remove the "separate design time aspects from run time
aspects" to clarify that this is just a re-statement of the "declarative
definitions of a language are more scalable" orthodoxy.

I suspect that this issue could benefit from a bit more discussion to see if
Dave Hollander and others do indeed fundamentally disagree with the
"declarative is scalable" position.  If we can't come to a quick consensus,
I'd suggest dropping the CSF because the whole "declarative vs procedural
controversy" has been going on for a generation and will probably outlive us
all.


"D-AR003.3 technologies following this architecture should not impede the
development of complex interaction scenarios likely for future business
interactions"   I believe that the intent here is to insist that the WSA not
favor simplification for scalability at the cost of making it useless for
real-world business scenarios.  

The balloting on this was 10/2/2/1, with the comments suggesting that the
success  factors are not really measurable.  I find no email discussion.
I'd suggest that anyone who strongly favors this CSF speak up on email,
otherwise it seems a bit too "motherhood and apple pie" for my tastes.   We
have plenty of other requirements to support "complex interaction scenarios"
and don't think we need to reiterate this in the scalability section.

"D-AR003.5 modularity must support common business functions such as
reliability, security, transactions, etc."  Uhh, I don't understand the
intent here.

The balloting was 7/6/2/0 with the comments suggesting that others didn't
understand the relationship between modularity and reliability, security,
transactions, etc.  either.  I'd suggest invoking the "when in doubt, throw
it out" rule unless someone can propose a clearer rationale and wording for
this CSF.

"D-AR003.6 defines or identifies a base interface that all Web services can
implement, that permits communication without a priori knowledge of the
service."  The intent here is to promote a CRUD/REST set of basic operations
that all web services should support without a formal service description,
e.g. GET-ing a stock quote service's URI would retrieve something meaningful
even if it supported all sorts of other methods.

The balloting on this was 5/1/4/5.  Comments suggested that people didn't
understand the goal, or that it didn't belong in the
scalability/extensibility section, or that one couldn't do much of practical
value without the schema of the data returned by the apriori method.  I
personally like this CSF, but admit that it has little to do with
scalability/extensibility except in the sense that "the web is scalable, and
the web is RESTful, so RESTful web services will be scalable."  Others have
pointed out the flaws in this syllogism ... ("Socrates is a mortal, Socrates
has white hair, thus mortals have white hair"), so I'd suggest that we
either drop it (under the "if in doubt, throw it out" rule) or the
originator should clarify the rationale and propose it under another goal.


To summarize my recommendations:

D-AR003.1 - No consensus likely, we should just vote
D-AR003.2 - Needs more discussion, Dave Hollander should probably lead it
D-AR003.3 - Remove unless someone can clarify/justify why we need it
D-AR003.5 - Originator should clarify and probably associate with another
goal
D-AR003.6 - Originator should clarify and associate with another goal

Received on Tuesday, 16 July 2002 10:19:44 UTC