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

Eric,

Your arguments could be used to support a slightly different requirement: A
requirement for the web services architecture to support stable, reliable and
predictable web services.  That's very different from creating an architecture
imposing such requirements on the web services without providing the
infrastructure necessary.  In essence, we would provide interoperable "tools"
for those services choosing to meet additional non-functional requirements.  (In
some sense, this relates to the modularity of the overall web services
architecture and any requirements that all modules are used to create a
compliant web service.)

Mark Baker said on a separate splinter from this thread that the web
architecture includes reliability features in the form of redirection and the
410 status codes.  Those may not be a complete solution for the web services
architecture and say nothing about stable or predictable (noone expects anything
except the 200 status code :).  So, we could use them as a starting point to
meeting a goal such as

    D-AG007.1 (??) Support the development, deployment and use of reliable,
stable and predictably evolvable web services.

thanx,
    doug

Eric Newcomer wrote:

> 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 Thursday, 21 March 2002 21:43:32 UTC