- From: Mark Baker <distobj@acm.org>
- Date: Wed, 27 Mar 2002 21:55:06 -0500 (EST)
- To: Suresh_Damodaran@stercomm.com (Damodaran, Suresh)
- Cc: hugo@w3.org ('Hugo Haas'), www-ws-arch@w3.org
Suresh, > I think the above ideas on defining/refining service reliability are > excellent. Good! > 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). Thoughts? MB -- 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