Re: Issue 5 and "webarch"

----- Original Message -----
From: "Newcomer, Eric" <Eric.Newcomer@iona.com>
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>;
<www-ws-arch@w3.org>
Sent: Sunday, January 05, 2003 1:27 PM
Subject: 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.

I was wondering if you'd return to my question.

I'm curious why you say "descriptions" above, instead of just
"loosely-coupled programs, objects and databases...".
Is there any significance to that?

As I recall, the "middle ground" was supposed to be something between REST
and RPC, but the language
in the quote above could easily be REST, as far as I know.  Programs,
objects and databases are all reasonable
resources.

This may seem a naive question, but it seems to fit here.  I've noticed
elsewhere that people complain that
REST is no good for invoking a query in which a large amount of information
needs to be sent from the
client to the server.  Reason: you'd need to POST that, most likely, but by
so doing you'd lose the advantages
of using GET for queries.  My question: why on earth would anyone ever want
to invoke a query like that?
In addition to brilliant theories as answers, I'd like to know if there are
any concrete use cases to be inspected.

>
> Web services are definitely a superset of the Web

Forgive me here, but I'm a bit of a relational calculus guy.  What sets are
you talking about?

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

I like this suggestion.  If "web services" are so much about XML, why aren't
they called "XML services"?
It's an earnest question.

Last summer I did a web service front-ending of an entitlements database
(entitlements for receiving
real-time stock quotes, folks, your favorite example).  I "sold" the team on
a REST approach, which we
implemented successfully.  During the "sales" process, I encountered this
problem: the system wasn't
really destined for web-scale deployment (although it does bridge across
corporate boundaries), and so
in a sense the REST architecture was overkill in some areas.  I suspect a
lot of folks gearing up to do
"web services" could do about as well using EJB or CORBA.  Their idea of
"trust boundary" is going
between the accounting department and the programming department of the same
company (or should
I have said the HCM department, for a more thoroughly trustworthy group?).

Even so, I could appreciate the economy of the REST approach on this
project.  XML schema design
became an adaptation of SQL schema, instead of becoming a much larger
messaging design task.  The
application is heavy on the query side (but aren't they all?), and so the
convenience of a browser as the
only test tool needed was a savings.  In addition, the design team learned
how to develop an application
that steers clients toward valid states, instead of allowing anything as
input and spinning circles around
itself recovering from errors in a "client friendly" fashion.  These were
some of the positive experiences.
On the negative side, it took us about three rounds of URI schema design
before we got to something
that wasn't RCP calls embedded in URI strings, and something that eased the
burden of the servlet
programmer by making the most of how servlet mapping works (well, we sort of
got there, not all the
way).  And of course the most negative aspect was that management never "got
it", and continuously
pushed for some form of RPC.  Kinda like some of you. <big smile>

I view this as a "small" project, perhaps missing many of the requirements
intracies that developers of
"web services" will find themselves burdened with, but nonetheless it was
quite educational for me, and
I'd encourage others to try to get similar small-project experience with
REST if they would understand
it better.

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

I sincerely beleive that the only way to solve Mark's problem is to do what
I did, as explained above. ;-)

Walden

>
> 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 22:56:47 UTC