W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2002

Re: TAG Architecture Draft

From: Mark Baker <distobj@acm.org>
Date: Mon, 9 Sep 2002 14:30:59 -0400
To: "Newcomer, Eric" <Eric.Newcomer@iona.com>
Cc: "Champion, Mike" <Mike.Champion@softwareag-usa.com>, www-ws-arch@w3.org
Message-ID: <20020909143059.A14393@www.markbaker.ca>

Some excellent questions from Eric.  I'll just contribute my 2c.

On Mon, Sep 09, 2002 at 12:09:55AM -0400, Newcomer, Eric wrote:
> General question:  Should this spec include Web services? In other words, are Web services considered part of the Web Architecture?  Or are Web services considered a completely different, unrelated architecture?  If so perhaps we should consider renaming them?  (Internet Services or something?)  

As deployed so far, and as specs like WSDL suggest, yes, I believe that
they are a completely different things and so should have a different
name.  Roy and DaveO discussed this here;

http://lists.w3.org/Archives/Public/www-tag/2002Mar/0153

> -- Is XML not a data format?  Perhaps strictly speaking it's a language for defining other languages, but in practice isn't it often used as a data format?  (I am relatively new to XML so I may not be understanding correctly.)

It's a format for data formats, I'd say.  But certainly some of the
architectural constraints on formats should apply to XML.  For
example, statelessness, which I managed to get mention of here
(section 4.13);

http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guidelines-06.txt

> Section 2 -- are Web services resources?  A resource is identified to include "documents, files, menu items, machines, and services, as well as people, organizations, and concepts."  What about programs and/or agents?  It's hard to tell whether the definition is intended to encompass them or exclude them.  Web services could be included as either documents or services, I suppose.

Web services are resources, because a resource is anything with identity
and Web services have identity.

> -- examples do not include any mention of Web services, should they?

See above. 8-)

> Section 2.1 -- States that "one resource refers to another...the large-scale effect is a shared information space" but earlier text mentioned agents as the things that exchange  information.  How do agents relate to resources, if resources refer to one another to create the information space?  Is what's really meant that agents refer to resources to link information, and therefore does it follow that agents can link to agents also (possibly through resources?)

Agents can be resources, since they also have identity.  But they don't
need to be.  That's not a complete answer, I know.

> -- interesting comment that searching is "serendipitous" -- I understand this wasn't part of the Web by design, and more of a side effect of unique URIs.  But what about Web services? Aren't they also "serendipitous" occurrences?

I'm quite sure that Tim intended searching to happen.  But I wouldn't
call Web services serendipitous, because they aren't really part of the
Web (yet).

> -- Could a middleware system be a software agent?  Or a database management system?  Or an ERP or CRM system?

Sure.

> Section 2.2.2 -- comment: dereference semantics sound a lot like dequeue semantics in message queueing middleware systems

Not as I understand "dequeue".  "dereference" is just as you do with C
pointers, ala "*p".  "dequeue" would be analogous to popping an entry
off a stack, I think.

> -- Doesn't this discussion about URN schemes indicate that URLs are really the only things that make sense for dereferencing resources?

Not everything that is dereferencable is a URL.

> -- It's not clear what "obligation" means in the context of "a user does not incur an obligation by following an HTML link that causes the user agent to retrieve a representation."  Perhaps this is explained in another document, in which case a reference would be helpful.

It means that by invoking GET, you're not committing to anything, so
that nobody could come to you and say "See, you clicked my link which
I said means that you agree to pay me $100!!  Pay up!".

> -- Also the qualifier "user" on agent seems to indicate (as other examples and references throughout the architecture do) that the architecture is centered around rendering documents for users.  Is that correct?

For the sentence that you're referring to, the subject of it is "user",
so IMO saying "user agent" is fine.  It would equally hold for machines
taking action on behalf of a corporation.

> -- Is it correct to conclude from the URI discussion that it is not recommended to use the same URL to GET a WSDL file and also refer to the Web services endpoint in a subsequent POST?

I believe so, especially sentences such as;

"One interacts with a resource by the exchange of representations of resource state."

and clearly a WSDL document doesn't describe the state of the service,
though it does describe the state of the interface to a service.  But
that would be a related resource.

> -- Context sensitivity in URI absolute references would seem to defeat interoperability...? (assuming Web services could be resources I guess)

That depends in what way it's context sensitive, but yes, it is possible
that interoperability is hurt if this isn't handled correctly.

> -- "equivalent" with repsect to URI consistency, is that similar to the problem space addressed by XML info set, or canonical XML?

IMO, it's not as strict a concept as those things.

> Section 4.1 -- Client/server model -- what about a case in which there's no rendering? i.e. only processing?  (this may assume of course that agents can refer to agents, and that agents are programs that can talk to each other, at least indirectly through linked resources)

Yes, I think the description here isn't great.  Rendering has little
to do with client/server.

> -- Caching -- can no caching be forced? i.e. caching is allowed, but can it be prevented?

Sure.  The caching constraint isn't well described there.  The
constraint is just that cache directives must be implicitly or
explicitly provided (i.e. not assumed).

> -- Uniform interface -- the term "components" is used but I could not find a definition of the term -- also, would be good to relate the term to agents and programs

Yes, it should punt to Roy's definition IMO;

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_3

> -- general comment -- stateless interactions is common to middleware software systems, meaning perhaps they are viable candidates for agents?

Not sure.  Any piece of software can simultaneously participate in
multiple systems with different architectural styles, but I'm not sure
that there's much advantage if some of those styles share common
constraints (such as statelessness).

> -- the role of components is defined but again not the components themselves.  Is it a fair statement to conclude that a resource or agent discovers the programs to which Web services are mapped?  (i.e. that would preserve the hiding principle)

I think an agent just discovers the resource, not the program.  It need
not know anything about the program which purports to speak for the
resource it's interacting with, except that it lets it interact with
the resource with HTTP.

> -- "hypertext" is used as the typical system example once again, and examples are given of rendering but not what I would call "processing" or "mapping" to programs -- in other words are there comparable cases for Web services in which rendering = mapping to web services implementations?  If not, should there be?

I always view "rendering" as a specialized form of "processing", just
for humans instead of machines.  For example, if I retrieved some XML
document as a result of a GET request, then my browser wouldn't likely
know how to render it unless it came with an xml-stylesheet PI, in
which case it could render it.  But I might have an agent without a UI
which just retrieves the XML document and then processes it.

MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Monday, 9 September 2002 14:31:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:05 GMT