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

RE: Generic/specific connectors

From: Newcomer, Eric <Eric.Newcomer@iona.com>
Date: Mon, 22 Jul 2002 18:24:52 -0400
Message-ID: <DCF6EF589A22A14F93DFB949FD8C4AB2916AF6@amereast-ems1.IONAGLOBAL.COM>
To: "Mark Baker" <distobj@acm.org>
Cc: <www-ws-arch@w3.org>


Well, in that case you may improve interoperability, but you push more of the burden for processing onto the application level.  Meaning whatever is behind the generic interface now has much more work to do to figure out what type of message it's receiving, where it should go, etc.  Ok, so Web servers work more or less this way, but does that really mean Web services should work that way as well?  Why not leave the choice to the developer, or to the parties wishing to interoperate?

I really do not think people are going to develop Web services that are published as widely as Web pages.  Web pages are for the purpose of publishing information, after all, while Web services are for the purpose of connecting programs or applications.  We are not imagining that every program is going to want to connect to every other program in the world, are we?

If I have a program that I want to connect to another program, I'm going to want to know something about the other program, how it fits into the application I'm building, what purpose the other program serves, what data I want to send it and what I expect to receive in return.  I can't build an application using generic interfaces and know what I'm going to get out of it.


-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Monday, July 22, 2002 6:30 PM
To: Newcomer, Eric
Cc: www-ws-arch@w3.org
Subject: Re: Generic/specific connectors

On Mon, Jul 22, 2002 at 05:37:12PM -0400, Newcomer, Eric wrote:
> Perhaps I missed the point about connectors somehow, but I was thinking that interfaces can be generic or specific, that technology doesn't constrain them.
> Service oriented architectures, in particular, support any level of granularity that you want to define.
> It's a constant point of discussion -- should I write a generic(generic) interface and put all the application logic within the called program?  Or should I write a customerUpdate(customerData) interface and send only messages to the interface that pertain to updating customer data?

Yes, that is most definitely a point of discussion!!  So much so, that
IMO, the Web's principle value add is one answer to that question for a
very large class of applications!

With software in general, we make it more reusable by generalizing.
That comes at a cost, but not in terms of what can be done, only in
terms of things like performance and optimization.  So, using your
customerUpdate example, customerUpdate() is only good for updating
customer information, so any optimzation will be specific to that
operation.  A more general update() method would permit larger network
effects to be realized by widening the domain of applicability of any
optimization made to messages of that type.  The more general, the
greater the network effects.

The Web generalizes the world into two (I'm oversimplifying, slightly)
types of messages; safe retrievals with GET, and making of commitments
with POST.

> I must have missed the question because I thought this was what you were asking.

Close enough. 8-)  I think focusing on the above point is more fruitful
at this point.

Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Monday, 22 July 2002 18:25:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:57 UTC