- From: Damodaran, Suresh <Suresh_Damodaran@stercomm.com>
- Date: Thu, 28 Mar 2002 12:58:54 -0600
- To: "'Mark Baker'" <distobj@acm.org>
- Cc: hugo@w3.org, www-ws-arch@w3.org
Mark, -----Original Message----- From: Mark Baker [mailto:distobj@acm.org] Sent: Wednesday, March 27, 2002 8:55 PM > 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. <sd> I generally agree - I clarify below what I am agreeing with. 1. "REQUIRE the WS standards to provide primitives to support these goals" does mean the WS standards provide whatever support necessary so that reliability techniques/protocols can be carried out by participating web services. It does not mean that all implemented WS are required to implement these techniques/protocols. It may be that after some study of these protocols, we may find some of these to be REQUIRED behavior, but I would leave that discussion to a later stage. Right now let us concentrate on the goal, and then CSF. 2. "requiring that this sort of generic information be part of the a priori contract" This is a great idea. Actually, ebXML CPA does specify such information for reliable messaging in it btw, CPA (Collaboration Protocol Agreement) is the contract. Then of course, note that business collaboration is traditionally done under contract. In the web services world, I suspect there is also a requirement to be able to interact with WS without a contract (or with the least common denominator of a contract) with no implied warranties (just like web page access for information - redirection is not required). Therefore, I would relax *requiring* to *suggesting*, and, of course, it would be great to have this information in the contracts. The "minimum requirement" does also support the notion of "partial understanding" (TBL) </sd> 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). <sd> Yes, part of relationship between components, but an attribute (non-functional feature) of the relationship (components are network components in my defn.!). Again, as I have said earlier, after careful study of the reliability protocols, we may decide to make them functional features at a later point. This is a gray area and it is easy to debate much on how much of reliability is a required behavior, and how much is an optional. This is a judgment call, and I would err on the side of not making REQUIRED anything that is not critical (can definitely make them OPTIONAL). Since we are still figuring out what are critical goals, may be we can revisit this at the next stage. Does this sound right? Regards, -Suresh </sd>
Received on Thursday, 28 March 2002 13:59:31 UTC