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

Re: D-AG0019 [RE: D-AG0007.1- defining reliable and stable WS ]

From: Mark Baker <distobj@acm.org>
Date: Wed, 27 Mar 2002 21:55:06 -0500 (EST)
Message-Id: <200203280255.VAA10360@markbaker.ca>
To: Suresh_Damodaran@stercomm.com (Damodaran, Suresh)
Cc: hugo@w3.org ('Hugo Haas'), www-ws-arch@w3.org

> I think the above ideas on defining/refining service reliability are
> excellent.


> WSA might specify these "techniques" (relocation, discontinuation, advt....)
> as ways to support/enable reliability. Same goes for messaging
> reliability (guaranteed delivery at most once/at least once/ once and once
> only).
> (I am assuming we can separate the service reliability to messaging
> reliability)
> Just like security, we cannot REQUIRE that all implemented web services
> provide these techniques, though we could REQUIRE the WS standards to
> provide primitives to support these goals. Same for stability, predictable
> evolution.

Well, given that all Web services have URIs per our definition, and the
meaning of the response codes Hugo mentioned are applicable to all
things with URIs, would it really be out of scope for us to require this
behaviour?  Not that we're requiring the use of HTTP, but requiring that
this sort of generic information be part of the a priori contract
between Web services seems like a good idea to me.

The definition of architecture that we've worked with so far is;

  "The software architecture of a program or computing system is the
   structure or structures of the system, which comprise software
   components, the externally visible properties of those components,
   and the relationships among them."

I think it's fair to classify this type of generic behaviour as being
part of the relationship between components (a client, and a Web
service, in this case).


Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Wednesday, 27 March 2002 22:11:07 UTC

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