- From: Hugo Haas <hugo@w3.org>
- Date: Wed, 20 Mar 2002 20:06:12 -0500
- To: www-ws-arch@w3.org
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:06:12 UTC