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 20:43:52 UTC