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

I agree most strongly with Anne's original statement, which summarized
is "the web isn't reliable."  It's realistic but reliability,
stability and predictable evolution need to be addressed.  IMO this is
most easily addressed by defining the guarantees around addresses and
interface definitions.  What is the lifetime expectation of a service
with an interface published in WSDL.  There is an implied semantic in
Katia's statements that "if a service is locatable in WSDL it should
be reachable."  The actual mechanical semantic is probably more like
the service was available when it published.  I would add a
time-to-live to the published definition that needs to be refreshed.  

Predictable evolution, the first question is "is the
address-to-service binding immutable."  If so then predictable
evolution is handled by creating a new addressable service for any
change.  If that's too difficult to manage then "can the service
interface be rev'd and keep the same address" maintains the semantic
expectation if not the exact syntax.  Weaker guarantee yet would be no
semantic or syntactic consistency requirement at all (WSDL hell?).
A fixed time-to-live guarantee for address-to-service bindings would
bound the lifetime for this too. 

On a more specific topic I don't have a problem with a service
"remembering" its previous versions.  In most implementations I've
seen the service doesn't actually have to remember, the service
dispatcher does.  For the length of time that the previous service was
guaranteed to be available the dispatcher needs to be able to route to
the appropriate instance.

=bill

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Katia Sycara
Sent: Wednesday, March 20, 2002 8:43 PM
To: Hugo Haas; www-ws-arch@w3.org
Cc: katia@cs.cmu.edu
Subject: RE: D-AG0007.1- defining reliable and stable WS [was RE:
Status: D-A G0007 - reliable, stable, predictable evolution]


> Hugo,
>  I agree with your view and Ann's regarding "reliability", i.e. it is not in
> our charter to impose requirements of reliability.
>  If a producer withdraws the service, the service should be able to
> un-advertise itself with a matchmaker registry, so it is un-discoverable for
> the period of its withdrawal.
> 
>  I am not totally sure I agree with you on stability. it is not our charter
> to impose this requirement (we let market forces do that :)).
>  What I mean is that if a provider suddenly changes his/her/its service so
> that service consumers cannot invoke it any more, then obviously service
> consumers will go discover another substitutable service. The producer loses
> clientelle. So, it is to the producer's benefit to have a stable service.
> 
>  As to predictability and predictably evolving service, again
> a. I agree that the service will not be the one to notify its consumers
> about changes.
> b. the service should unadvertise itself and advertise itself as a
> "different" service (ie with different service name or identifier, but
> essentially with the same service "profile", e.g. "selling books" and taking
> 3 parameters as inputs in version1 is essentially the same  as "selling
> books" and taking 2 parameters in version2). This will ensure that a
> requester/consumer that needs a "selling books" service will be able to
> discover it.
> 4. I do not hink that the service should "remember" its previous versions
> explicitly. Of course, if it is a Web based service describable by a URI,
> then the URI mechanism, I think, can ensure that a previous version
> description can be accessed. Otherwise, it would be rather cumbersome for
> the service itself in its advertisement, for example, to say "previously I
> was taking 3 parameters but now I am taking 2". I do not think such
> information will help the consumer (whether it is available through a URI
> mechanism or not). If the consumer uses the service for the first time, it
> does not care what the service did in the past; if the consumer uses the
> service for the nth time, it knows the service used to take 3 parameters;
> but, anyway, this does not help in solving the problem of how to invoke the
> current version of the service with the 2 parameters.
>     Cheers, Katia
> ---------------------------
> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Hugo Haas
> Sent: Wednesday, March 20, 2002 8:06 PM
> To: 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]
> 
> 
> Hi Anne and Mark.
> 
> I am replying here to both of your emails, since they are on the same
> subject.
> 
> * Anne Thomas Manes <anne@manes.net> [2002-03-20 19:03-0500]
>> Ramblings on the subject:
>>
>> Web resources are not reliable, stable, or predictable. Links break all
>the
>> time. Web sites aren't necessarily available 24 hours a day. Is it
>> appropriate to impose a higher level of reliability, stability, and
>> predictability on Web services?
>>
>> I don't think it is. To some degree this issue is dealt with in the realm
>of
>> discovery. If your link to a web service fails, you can rediscover
>> it. Not all web services will be available all the time. Some web
>> service providers may want to arbitrarily terminate the services
>> that they offer. 
>>
>> I don't think it's within our charter to impose these requirements
>> on people who build web services.
> 
> I think that you disagree with the "reliable" part of the proposed
> requirement.  Hmmm... Rereading Suresh's email[1], reliability
> (guaranteed access as I understand Suresh's wording) does seem
> unreasonable; I had missed that in my first reading.
> 
> However, it seems to me that stability is valuable if you want to get
> the things you were expected to get from the service. Regarding
> predictability, see the answer to Mark's email below.
> 
>> I do think it's appropriate to ensure the reliability, stability, and
>> predictability of both web services technology and web services standards.
> 
> Agreed.
> 
> * Mark Potts <mark.potts@talkingblocks.com> [2002-03-20 15:51-0800]
> [..]
>> Not sure if I agree with the definition of "predictable evolvable" and its
>> correlation to Stability. In the Architecture who is responsible
>> for knowing the consumers of a service and managing the
>> notification of detrimental change? I would not say that notifying
>> a consumer at the time of invocation that the service has changed
>> would not constitute a stable system!  Even notifying them prior
>> depends on the time you give them to react. This leads me to
>> believe someone else is responsible for managing this task. 
>>
>> I am presuming we are not advocating the service itself tracks its
>> consumers, such that it can notify them of detrimental change.
> 
> Actually, I agree with that. I think that the confusing part was the
> words '"aware"/notified' that I copied from Suresh's definition. I was
> thinking about advertizing the new service differently from the old
> one.
> 
>> So that means a third party outside the producer and consumer. If
>> this is true then I would say "predictably evolvable" should include
>> the ability of a Web Service to define its compatibility ( i.e. its
>> WSDL and the relationship it has to other WSDL ), such that the
>> third party can manage that relationship and make services
>> "predictable evolvable" not just from a consumers perspective but a
>> producers perspective also and thus more stable.
> 
> You are right, that is one of the things I had in mind when I talked
> about versioning:
> - do not change things under people's feet: this is stability.
> - be able to identify some kind of relationship between two versions
>   of a service: e.g. I am performing the same task but I only need 2
>   parameters instead of 3 now.
> 
> Regards,
> 
> Hugo
> 
>   1. http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0309.html
> --
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

Received on Wednesday, 20 March 2002 22:40:12 UTC