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

Hi Hugo and Mark,

-----Original Message-----
From: Hugo Haas [mailto:hugo@w3.org]
Sent: Friday, March 22, 2002 3:54 PM
[snip]

Service reliability as I would understand it would merely be, as Mark
was discussing it[2], about careful maintenance of Web resources:
advertisement of availability (e.g. use of HTTP's 503 error code[3]),
relocation (e.g. 301[4]), discontinuation (e.g. 410[5]), etc. Note
that we could have something in the architecture document recommending
such behaviors.

  2. http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0363.html
  3. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.4
  4. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2
  5. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.11

<sd>

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.

Given these I propose we change the goal of D-AG0019 from

"[To develop a standard reference architecture for ]reliable, stable, and
predictably evolvable web services"

to 

"[To develop a standard reference architecture that supports ]reliable,
stable, and predictably evolvable web services"

or something equivalent (better wording solicited). 
The key difference is that the REQUIREMENT for reliability,(...)
is no longer there for *implemented* web services, though supporting
reliability, stability, and predictable evolution is a REQUIREMENT of the
architecture.

Comments?

Regards,
-Suresh 

</sd>

Received on Wednesday, 27 March 2002 11:07:37 UTC