Re: Issue 5 and "webarch"

On Sun, Jan 05, 2003 at 11:44:37AM -0500, Champion, Mike wrote:
> 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.

Right, though it need not dereference it to use it.  i.e. it could forge
a list of invoices for a customer and include that URI in that list,
without ever dereferencing those URI.

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

Yes, that's right.  It assumes that accounting system has been "put on
the Web".

That's hardly challenging or uncommon though.  What's challenging is
that most of that data is in HTML, rather than XML and/or RDF.

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

If T-Rex and Bronto are part of the same trust domain, this is a
reasonable approach.

If they're not, it doesn't make as much sense.

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

I have no objection to that, but I'd recommend that this be identified
as a separate architectural style.  It doesn't need the same properties
because there's no trust boundary to cross (and therefore doesn't need
to be built around a coordination language, like every other system
which crosses trust boundaries).

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Sunday, 5 January 2003 13:27:29 UTC