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

RE: Status: D-AG0007 - reliable, stable, predictable evolution

From: Mark Potts <mark.potts@talkingblocks.com>
Date: Wed, 20 Mar 2002 16:35:35 -0800
To: "'Anne Thomas Manes'" <anne@manes.net>, "'Hugo Haas'" <hugo@w3.org>, <www-ws-arch@w3.org>
Message-ID: <006701c1d070$5171c690$9a68fea9@talkingblocks.com>
Anne, agreed there is a distinction here for the "ables" in terms of the
services themselves, the overall technology, and the standards, however...

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

I have to disagree here completely with reference to services. What you are
advocating is "WSDL Hell". I'll buy the argument about you cant ensure that
services are 100% available, but I think stability and predictability are
goals we have to strive for at a service level.

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.

Discovery or re-discovery is only a part solution to availability and
therefore the overall reliability of the architecture. I don't think
re-discovery addresses stability or predictability, but it depends if you
think stability or predictability are important at the service level. Even
if you use rediscovery as a mechanism for addressing these issues,
compatibility has to be declared such that new services can be discovered
that has declared compatibility to other services or previous versions of
itself, in essence another service, such that providers can retire services
predictably.

>
> I don't think it's within our charter to impose these
> requirements on people
> who build web services.
>
> I do think it's appropriate to ensure the reliability, stability, and
> predictability of both web services technology and web
> services standards.

Agreed, but I don't think the break is a clean between services, standards
and technology as we are making it out to be.

>
> Anne
>
> > -----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 5:30 PM
> > To: www-ws-arch@w3.org
> > Subject: Re: Status: D-AG0007 - reliable, stable,
> predictable evolution
> >
> >
> > * Damodaran, Suresh <Suresh_Damodaran@stercomm.com> [2002-03-14
> > 17:48-0600]
> > > Good point.
> > > "reliability, stability, and predictable evolution of web services
> > > technology"
> > > is the non-goal that I referred to below, which we should
> make a goal.
> > >
> > > "reliability, stability, and predictable evolution of web services
> > > standards"
> > > is the goal that was addressed in the proposal for D-AG0007.
> > > Why?
> > >  Because, web service architecture = framework of web
> services standards
> >
> > I think that the third option (option 1 in her email) that Anne was
> > raising deserves attention:
> >
> > * Anne Thomas Manes <anne@manes.net> [2002-03-14 16:46-0500]
> > > When we say "reliability, stability, and predictable
> evolution of web
> > > services" are we talking about the services themselves or
> the technology
> > > used to implement them, or perhaps the standards underneath the
> > technology?
> > > Perhaps we need to say, "reliability, stability, and
> > predictable evolution
> > > of web services technology" or "reliability, stability,
> and predictable
> > > evolution of web services standards"?
> >
> > I am cathing up on lots of threads, no I will ask the following: has
> > "reliability, stability, and predictable evolution of [..] the
> > services themselves" been discussed?
> >
> > What I have in mind is a service making use of others and therefore
> > having a dependency on different services which have a particular
> > version. One might say that the identifier for the service should
> > change because it can be considered as a different service, but I
> > guess that it's already part of the discussion about how to address
> > the problem.
> >
> > Regards,
> >
> > Hugo
> >
> > --
> > Hugo Haas - W3C
> > mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ -
> tel:+1-617-452-2092
> >
>
>
>
Received on Wednesday, 20 March 2002 19:36:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:24:56 GMT