RE: D-AG0007.1- defining reliable and stable WS [was RE: Status: D-A G0007 - reliable, stable, predictable evolution]

The plot thickens by the minute (assuming a steady state of one e-mail
per minute) :o) Now we need to define Architecture before we start
thinking about web services architecture. 

May be while Suresh is championing "reliable, stable, and predictably
evolvable web services", we could solicit a champion for "reliable,
stable, and predictably evolvable architecture". 

Or better yet let us get to the root, be bold and champion for
"reliable, stable, and predictably evolvable definition mechanisms"  :o)

Before anybody gets mad at me, these are just silly dilbertian
observations .... with friendship towards all and malice towards none
....

cheers

 | -----Original Message-----
 | From: www-ws-arch-request@w3.org 
 | [mailto:www-ws-arch-request@w3.org] On Behalf Of Cutler, 
 | Roger (RogerCutler)
 | Sent: Tuesday, March 19, 2002 1:22 PM
 | To: 'Hao He'; 'Damodaran, Suresh'; www-ws-arch@w3.org
 | Subject: RE: D-AG0007.1- defining reliable and stable WS 
 | [was RE: Status: D-A G0007 - reliable, stable, predictable evolution]
 | 
 | 
 | I'm sorry to raise this again, but I had thought that 
 | "reliable, stable and
 | predictable evolution" referred to the architecture, not the 
 | web service
 | itself.
 | 
 | -----Original Message-----
 | From: Hao He [mailto:Hao.He@thomson.com.au] 
 | Sent: Monday, March 18, 2002 9:26 PM
 | To: 'Damodaran, Suresh'; Hao He; www-ws-arch@w3.org
 | Subject: RE: D-AG0007.1- defining reliable and stable WS 
 | [was RE: Status:
 | D-A G0007 - reliable, stable, predictable evolution]
 | 
 | 
 | Damodaran,
 | 
 | I agree with most of your arguments.  I do agree that 
 | reliability does not
 | imply stability.
 | 
 | I feel that the stability is more to do with the way to 
 | access services, in
 | other words, an interfacing issue, which is yet to be 
 | defined in this WG. 
 | 
 | I would support you to be the champion. Maybe you want to 
 | raise this at the
 | next phone meeting.
 | 
 | Hao
 | 
 | -----Original Message-----
 | From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
 | Sent: Tuesday, March 19, 2002 9:59 AM
 | To: 'Hao He'; www-ws-arch@w3.org
 | Subject: D-AG0007.1- defining reliable and stable WS [was 
 | RE: Status: D-A
 | G0007 - reliable, stable, predictable evolution]
 | 
 | 
 | Hao,
 | 
 | I am considering the goal 
 | "reliable, stable, and predictably evolvable web services" 
 | as D-AG0007.1
 | till we get a formal number for it. I volunteer to be the 
 | champion of this
 | goal (unless somebody else (do you want to be?) wants it, that is:-)
 | 
 | Let us be clear on the terms "reliable" and "stable" 
 | (www.dictionary.com)
 | ---------------------------------------------------
 | re*li*a*ble   Pronunciation Key  (r-l-bl)
 | adj. 
 | 	Capable of being relied on; dependable: a reliable assistant; a
 | reliable car. 
 | 	Yielding the same or compatible results in different clinical
 | experiments or 	statistical trials. 
 | ---------------------------------------------------
 | sta*ble   Pronunciation Key  (stbl)
 | adj. sta*bler, sta*blest 
 | 
 | Resistant to change of position or condition; not easily 
 | moved or disturbed:
 | a house built on stable ground; a stable platform. 
 | Not subject to sudden or extreme change or fluctuation: a 
 | stable economy; a
 | stable currency. 
 | Maintaining equilibrium; self-restoring: a stable aircraft. 
 | Enduring or permanent: a stable peace. 
 | 
 | Consistently dependable; steadfast of purpose. 
 | Not subject to mental illness or irrationality: a stable 
 | personality. 
 | Physics. Having no known mode of decay; indefinitely 
 | long-lived. Used of
 | atomic particles. 
 | Chemistry. Not easily decomposed or otherwise modified chemically. 
 | ---------------------------------------------------
 | 
 | Note that stability does not necessarily imply reliability - 
 | let us say that
 | a phone doesn't work for 6 months - its situation is stable, 
 | but cannot be
 | relied upon for phone calls within that period! Again, 
 | reliability does not
 | necessarily imply stability - My phone number could change 
 | every week - as
 | long as the new number is reliably available from the old number -
 | reliability of "reaching me by phone" is guaranteed.
 | 
 | My view of reliability & stability w.r.t. WS is as follows. 
 | Please critique
 | these definitions to get the bugs out of them.
 | 
 | Reliable - A WS is reliable as long as accessing (SD: a very 
 | "loaded" term
 | here) a WS is guaranteed under clearly specified conditions 
 | to all potential
 | users.
 | 
 | Defining stability is tricky. I am looking to see what in WS 
 | world would
 | require to be most stable and under what force field, and 
 | how a change to
 | that would be resilient. "WS implementation" is my candidate 
 | for this under
 | the "force field" of Independent specification. ("the best 
 | implementation is
 | a ball - you push it, it never falls:-)")
 | 
 | Stable - A WS is stable as long as any change in WS 
 | implementation conforms
 | to the independent specification (say WSDL) of the WS for 
 | all potential
 | users. Note that the specification of WSDL could change, and 
 | as long as all
 | users/service requesters are "aware"/notified of it.
 | 
 | Note again that a stable WS does not mean a reliable WS. A 
 | WS implementation
 | could be stable in an erroneous way ( thus not reliable). 
 | Similarly, we can have a reliable WS (for some "preferred service
 | requesters" who happen to know the new access point of the 
 | WS) that is not
 | stable (to those service requesters who did not know that 
 | new the access
 | point!). On the other hand, if a WS is not stable, there is 
 | a good chance it
 | is also not reliable. (btw, I have to thank a Model theory 
 | expert colleague
 | who assured me that I am not contradicting myself here in any way!)
 | 
 | My comments are inline,
 | and thanks for your response.
 | 
 | Regards,
 | -Suresh
 | 
 | -----Original Message-----
 | From: Hao He [mailto:Hao.He@thomson.com.au]
 | Sent: Thursday, March 14, 2002 6:35 PM
 | To: Damodaran, Suresh; Hao He; www-ws-arch@w3.org
 | Subject: RE: Status: D-AG0007 - reliable, stable, 
 | predictable evolution
 | 
 | 
 | hi, Damodaran,
 | 
 | I would regard the stability of a web service as the stability of the
 | identifier (the URI) and the logic concepts associated with 
 | it. For example,
 | if a company sells car at http://xys.com/buy/car, one 
 | expects the URI to be
 | stable so one can bookmark this URI and one expect to buy a 
 | car not a book. 
 | 
 | <sd>
 | Would you not consider this a "reliability of URI" than a 
 | stability issue 
 | in light of the discussion above?
 | </sd>
 | 
 | 
 | The second part is more tricky.  How about: "the 
 | architecture should enable
 | a web service to reveal its attributes to its consumers and verified
 | independently by its consumers or third parties so a 
 | selection mechanism can
 | be enforced. "?
 | 
 | 
 | Note the attributes can be more than just those needed in 
 | order to discover
 | the web service. <sd> We need a new goal for this (and a 
 | champion). Sounds
 | fine to me.
 | 
 | may be we need 2 - one for "discovery" and another for 
 | "criteria based
 | selection?" </sd>
 | 
 | Hao
 | 
 | -----Original Message-----
 | From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
 | Sent: Friday, March 15, 2002 3:08 AM
 | To: 'Hao He'; www-ws-arch@w3.org
 | Subject: RE: Status: D-AG0007 - reliable, stable, 
 | predictable evolution
 | 
 | 
 | Hao,
 | 
 | -----Original Message-----
 | From: Hao He [mailto:Hao.He@thomson.com.au]
 | Sent: Wednesday, March 13, 2002 6:32 PM
 | To: Damodaran, Suresh; www-ws-arch@w3.org
 | Subject: RE: Status: D-AG0007 - reliable, stable, 
 | predictable evolution
 | 
 | 
 | I belive that the "Reliability, stability, and predictable 
 | evolution of web
 | services" are more important and useful than those of the reference
 | architecture, so we should add it as a goal. <sd> I 
 | generally agree. I am
 | unsure of what "stable webservice" means, though. What is it 
 | to you, and how
 | is it different from "reliable web service?" </sd>
 |  
 | It might also be desirable if a web service can be easily 
 | evaluated from
 | consumers' point of view. This would allow 'natual 
 | selections' on competing
 | service providers and service implementations. Should this 
 | be a non-goal or
 | part of the new goal?
 | 
 | <sd>
 | It would make sense to add this as a goal if web services 
 | world is seen as
 | an ecology, where Darwinian selections may occur. (I have 
 | visions of striped
 | web services lengthening their neck and becoming tall web
 | services:-)
 | 
 | Seriously, how would you word the goal statement?
 | "architecture has the goal of enabling selection of web 
 | services" Note that
 | the implications are profound - just as an example, discovery of web
 | services will immediately come under the scope of WS-A.
 | 
 | Cheers,
 | -Suresh
 | </sd>
 |  
 | Regards, 
 | Hao
 | 
 | -----Original Message-----
 | From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
 | Sent: Thursday, March 14, 2002 10:48 AM
 | To: www-ws-arch@w3.org
 | Subject: Status: D-AG0007 - reliable, stable, predictable evolution
 | 
 | 
 | Goal:
 |     Goal statement "To develop a standard reference 
 | architecture for web
 | services that is reliable, and stable, and whose evolution 
 | is predictable
 | over time"  This goal has not been revised, and thus, stands.
 |     "Reliability, stability, and predictable evolution of 
 | web services" is
 | noted in [1] as a non-goal, and perhaps
 |     should be added to our goals.
 |  
 | A proposal was submitted to the WG [1], and was evaluated. 
 | The proposal
 | included measures that can be taken by WS-A to address reliability,
 | stability, and predictable evolution through the formation 
 | of C-sets, or
 | "consistent sets" of standards within WS framework.
 |     A question was raised whether C-sets could stall 
 | predictable evolution
 | [3].
 |     Similar question was posed in [2] in terms of extension.
 |     Ensuring "backward compatibility" of individual standards could
 | potentially address this issue [4]. This will also address 
 | the "principle of
 | partial understanding" in [5].
 |  
 | For other questions and responses, please refer to the mails 
 | directly.
 |  
 | Further, I was referred to [5] as a possible important 
 | source. If anybody
 | has any other source, 
 | please send them to me. A new rev of the proposal will be 
 | made later in
 | light of the comments and [5]. Date TBD.
 |  
 | Regards,
 | -Suresh
 |  
 |  
 | [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0148.html
 | <http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0148.html> 
 | [2] http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0158.html
 | <http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0158.html> 
 | [3] http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0180.html
 | <http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0180.html> 
 | [4] http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0234.html
 | <http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0234.html> 
 | [5]  <http://www.w3.org/DesignIssues/Evolution.html>
 | http://www.w3.org/DesignIssues/Evolution.html
 | 
 |  
 | 
 |

Received on Wednesday, 20 March 2002 13:13:26 UTC