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

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