RE: Issue 5 and "webarch"

Mike,

Right, I'm in complete agreement with you.  In fact, by most definitions, Web services are loosely-coupled descriptions of programs, objects, and databases that a SOAP gateway can map to (or transform to).   I think this also is pretty much the definition of the "middle ground" Walden was asking about. 

Web services are definitely a superset of the Web, and again often we seem to be suffering from an over-association of the "Web" part of "Web services" with HTTP.  Maybe we should rename them, but then again, I don't think W3C or anyone else is in control of what gets accepted as a name of something like that, or how.

In the example below, couldn't we solve Mark's problem by assigning a URI for the entire collection of data items (i.e. a namespace URI) and include within the collection of data items (as represented in XML of), a pointer to a schema that defined how to map those data items to a (or possibly more than one) program?  Again this would seem a sensible use of a URI within the context of a Web services processing model.

Eric

-----Original Message-----
From: Champion, Mike 
Sent: Sunday, January 05, 2003 11:45 AM
To: www-ws-arch@w3.org
Subject: 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 13:28:20 UTC