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

We already covered this. see [1] and [2].

Cheers,

Chris

[1] http://www.w3.org/2002/ws/arch/2/03/07-minutes
[2] http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0090.html

Krishna Sankar wrote:

> 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 17:23:21 UTC