RE: Issue 5 and "webarch"

> -----Original Message-----
> From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
> Sent: Sunday, January 05, 2003 10:05 AM
> To: Champion, Mike; www-ws-arch@w3.org
> Subject: RE: Issue 5 and "webarch"
> 
> 
> With respect to URIs, isn't it true that namespace URIs can 
> qualify multiple resources?  Of do I misunderstand namespaces?

That's kindof what I was getting at: URIs can be used to identify abstract
"resources" or a whole collection of related things in a "namespace".
That's a Good Thing in that it makes URIs a universal space of unique
identifiers.  Thus, one could use URIs to identify web service resources
that are not "on the Web" in the conventional sense, e.g. 
  http://t-rex.example.com/accounting 
might identify a mainframe acounting program on a mainframe called T-Rex for
the purposes of describing what it does, what its web service interfaces
are, reasoning about it with RDF, or whatever.  That's something that I
suspect that the TAG and the WS working groups can probably agree on.

What I seem to disagree with Mark on is whether that implies that one can
assume that these URIs are always useful in a hypermedia sense.  He gives an
example (which I've tweaked for my rhetorical purposes):

<some-doc>
  ...
  <invoice>249827348237432</invoice>
  ...
</some-doc>

versus

<some-doc>
  ...
  <invoice>http://bronto.example.com/9238d928jd298sdfi9</invoice>
  ...
</some-doc>

Let's say that the T-Rex accounting system has to access this invoice (which
let's assume is physically on another mainframe Bronto at a remote site.
Mark seems to be suggesting that it dereference
http://bronto.example.com/9238d928jd298sdfi9 and get the data.  That assumes
that the accounting system (first deployed in 1975, let's say) understands
HTTP, and is connected to the internet (which for some odd reason mainframe
sysadmins tend to be paranoid about). In the current world, let's say that
T-Rex communicates with Bronto via a proprietary MOM (that provides
reliabile messaging, security,etc.), and 249827348237432 is the primary key
of the invoice of interest in some database.  In this type of scenario, it
makes a lot more sense for the SOAP client to gather up all the data that
the back-end system needs, pass it through the HTTP/SOAP gateway, and let
the back end do what it was built to do, than to rebuild all that back
office stuff with Web technology and model the interactions with hypermedia.

I'm suggesting (well, insisting!) that the Web services architecture reflect
this reality as well as the scenario in which all these exchanges are done
with HTTP over the Web per se.

Received on Sunday, 5 January 2003 11:44:40 UTC