RE: D-AR003.2

In 3.2, I also don't see how <abstract,concrete> maps 1-1 to
<design,run-time>.
It is unclear to me how <abstract, concrete> maps 1-1 to <declarative,
procedural>

I can understand <description, realization> mapping 1-1 to both
<design,run-time> and
<declarative, procedural>.
I prefer dropping the words "abstract" and "concrete" from 3.2, as well as
the reference
to "design/run-time"

Actually, the reqs in 3.3 to 3.6 match in substance reqs made for
"predictable
and stable evolution of architecture" which we will reconsider in
"reliability" TF.
If these are still under "D" category, reliability TF can take these.

Cheers,

-Suresh
Sterling Commerce, Inc.


-----Original Message-----
From: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com]
Sent: Thursday, May 30, 2002 5:24 PM
To: Dave Hollander
Cc: www-ws-arch@w3.org
Subject: RE: D-AR003.2



Can someone explain to me why separation of declarative concepts from
procedural concepts is bad for the architecture?

If I draw a component relationship diagram separately from a state
transition diagram, that is good. It would be real nasty if I try to mix
those together.

My take is that the requirement being discussed prevents us from doing the
later. 

So I'm inclined to keep it, possibly dropping the second part which talks
about design/run time.

-- Igor Sedukhin .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



-----Original Message-----
From: Dave Hollander [mailto:dmh@contivo.com] 
Sent: Thursday, May 30, 2002 4:32 PM
To: www-ws-arch@w3.org
Subject: D-AR003.2



There are two separate issues with D-AR003.2.

a. Does this csf belong in the requirements document?

b. If so, is it correct and necessary to equate abstract/concrete
descriptions and
	design/run time aspects.

My Opinions:
a. No. Extensibility and evolution are heavily dependent on the structure
and design of the underling architecture. 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 (for
example, 
is the number of occurrences part of the how or what? )

Given that XML Schemas have both abstract and concrete constructs (at least
by some definitions) I do not think we can fully support this CSF.

b. No, they are not the same.

Dave Hollander

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

D-AR003.1 separates the transport of data or means of access to Web Services
from the Web Services themselves

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

D-AR003.3 technologies following this architecture should not impede the
development of complex interaction scenarios likely for future business
interactions

D-AR003.4 modules that are orthogonal must be allowed to evolve
independently of each other and still work within the architecture

D-AR003.5 modularity must support common business functions such as
reliability, security, transactions, etc.

D-AR003.6 specs that are created in conformance with the architecture do not
have to go through a formal process to be considered conformant

Received on Thursday, 30 May 2002 19:59:21 UTC