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

We should be sure to clearly separate functional descriptions and
requirements (i.e. how a feature works) from non-functional descriptions and
requirements (i.e. how well a feature works).

The former is more appropriate for industry specification, the latter for
product implementation of the specificiation.

We can, for example, specify how a transaction achieves reliability by
stating the requirement to log all state changes to stable storage before
completing.  But we should avoid simply stating a requirement for a
transaction to be reliable in the abstract.

The same for Web services.  If we can state requirements for how they can
achieve reliability, that's fine.  But to state a requirement that they
should have the quality of reliability in the abstract is relevant to
implementation but not specification, and therefore would be outside the
scope of our work.

Eric

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Anne Thomas Manes
Sent: Wednesday, March 20, 2002 4:03 PM
To: Hugo Haas; www-ws-arch@w3.org
Subject: RE: Status: D-AG0007 - reliable, stable, predictable evolution


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 do think it's appropriate to ensure the reliability, stability, and
predictability of both web services technology and web services standards.

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 21:30:09 UTC