RE: D-AR003.2

I guess orchestration flow, message exchange pattern, transaction processing, policy enforcement, etc. are all examples of procedural descriptions of Web services.
Business description (metadata, registry entry), data types, messages, operations, security context, etc. are examples of declarative descriptions.
It would be really nice to have them separate.

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

-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com] 
Sent: Friday, May 31, 2002 1:06 PM
To: Sedukhin, Igor; Dave Hollander; www-ws-arch@w3.org
Subject: RE: D-AR003.2


Sounds good to me.
I would like to see a non-normative example of a procedural description of WS, though.
 
Cheers,

-Suresh 
Sterling Commerce, Inc. 

-----Original Message-----
From: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com]
Sent: Friday, May 31, 2002 11:54 AM
To: Damodaran, Suresh; Dave Hollander; www-ws-arch@w3.org
Subject: RE: D-AR003.2



Ok, indeed it applied to WS descriptions. 

Here is wording for specifically rephrasing that requirement. 

"Descriptions of Web Services are clearly separated into declarative (what) and procedural (how) definitions." 

I'd like to keep one about Architecture and concepts too. It's always helpful to state good practices upfront as requirements.

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



-----Original Message----- 
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com <mailto:Suresh_Damodaran@stercomm.com> ] 
Sent: Friday, May 31, 2002 12:12 PM 
To: Sedukhin, Igor; Dave Hollander; www-ws-arch@w3.org 
Subject: RE: D-AR003.2 


I like Igor's wording below. 

Only problem is, 3.2 as stated refers to Web Services, not WS Architecture! It appears we need 3.2.1 for WS & 3.2.2 for WSA, both along the lines of Igor's wording below.

Cheers, 

-Suresh 
Sterling Commerce, Inc. 


-----Original Message----- 
From: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com <mailto:Igor.Sedukhin@ca.com> ] 
Sent: Friday, May 31, 2002 10:02 AM 
To: Dave Hollander; www-ws-arch@w3.org 
Subject: RE: D-AR003.2 



Ok. So, then I'm +1 to keep what/how separation as the content of the requirement. Basically that is the only thing that I sensed important when reading it.

What about this wording: "The WS Architecture must clearly spearate and identify declarative (what) and procedural (how) concepts."

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



-----Original Message----- 
From: Dave Hollander [mailto:dmh@contivo.com <mailto:dmh@contivo.com> ] 
Sent: Friday, May 31, 2002 10:28 AM 
To: www-ws-arch@w3.org 
Subject: RE: D-AR003.2 



Abstract/concrete does not equal declarative/procedural. I can write XSLT in either declarative or procedural mode, but it is still concrete.

The modeling books I use explain the abstract/concrete difference as concrete adds storage and/or physical constraints. 

The abstract/concrete design line is spanned by XML Schema and WSDL. I believe that Schema made the right decision in doing this; regardless, we use schema/WSDL in the archtecture now and can not imagine adding a goal/csf that would cause us to reconsider and change.

Dave 

-----Original Message----- 
From: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com <mailto:Igor.Sedukhin@ca.com> ] 
Sent: Thursday, May 30, 2002 4: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 <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