W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2002

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

From: Hugo Haas <hugo@w3.org>
Date: Wed, 20 Mar 2002 20:06:12 -0500
To: www-ws-arch@w3.org
Message-ID: <20020321010611.GO3477@jibboom.w3.org>
Hi Anne and Mark.

I am replying here to both of your emails, since they are on the same

* 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.


* 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

> 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.



  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:06:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:55 UTC