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 Tuesday, 19 March 2002 18:39:04 UTC