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

Mark,

In response to the 410 like generic behavior has two aspects.
	1. create a response signal such as 410
	2. create a protocol that will point to the "where it has gone" if
it is known to the responding entity.

I think you are suggesting only (1) above. Which I consider a very useful
enabler for reliability (may even be thought of as a performance enhancer
from an implementation perspective).
OTOH (2)is useful, but likely debatable (may be a "judgment" issue).
Personally, I think even 2 could be a core reliability primitive for WS
access.

Regards,
-Suresh

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Tuesday, April 02, 2002 12:32 PM
To: Damodaran, Suresh
Cc: 'Mark Baker'; hugo@w3.org; www-ws-arch@w3.org
Subject: Re: D-AG0019 [RE: D-AG0007.1- defining reliable and stable WS ]


Suresh,

> 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>

I was actually thinking of something lower level, alluding to my last
post on knowledge manipulation.

Basically, what I think it would be useful to do is for us to answer the
following question; if all you have is a URI, and no other information,
what is the richest possible application interface that can be specified
a priori?

If we defined that, then we could bootstrap the rest of Web services on
top.  For example, in my last email I talked about how people were using
HTTP GET to return WSDL.  This is incredibly powerful, because you don't
need any other a priori information except that the URI is a HTTP URI.

So, I consider a GET-like operation, and as previously mentioned, the
information communicated by a 410 status code, to be generic to all
URIs, including those identifying Web services.

We should fill out this interface further, IMO.

> 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?

Well, let's see what you think of my suggestion above. 8-)

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, 3 April 2002 17:27:55 UTC