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 17:37:12 -0400
Message-ID: <DCF6EF589A22A14F93DFB949FD8C4AB2916AF3@amereast-ems1.IONAGLOBAL.COM>
To: "Mark Baker" <distobj@acm.org>
Cc: <www-ws-arch@w3.org>

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?

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


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

(woohoo, got email)

Hi Eric,

> Anyway, let me try to summarize my views for a new thread and let's see if we can move toward convergence.

Rather than respond to that point in the new thread, I'll just respond
here.  You suggest that the architecture should permit both generic and
specific interfaces.

I suggest that this is either impossible, or that you are in effect
designing two systems, depending upon whether you think that's a valid
thing to do or not - I don't think it is.  As you define the rest of
the architecture, you won't be able to assume anything about connector
semantics, which will impact the overall architecture substantially.

Architectural constraints are a *good* thing, not a bad thing.  They
don't necessarily (like generic interfaces) restrict *what* can be
done, only *how* they're done.  You can have too many, as Gopher
demonstrated, but you can also have too few.  Web services provide too
few constraints because they're missing the architectural constraint
that *EVERY* single successful system on the Internet has; generic
connector semantics.

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 17:37:44 UTC

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