W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

Re: Dynamic invocation vs. late/dynamic binding

From: Mark Baker <distobj@acm.org>
Date: Wed, 8 Jan 2003 01:34:05 -0500
To: James M Snell <jasnell@us.ibm.com>
Cc: www-ws-arch@w3.org
Message-ID: <20030108013404.K29146@www.markbaker.ca>

On Tue, Jan 07, 2003 at 12:48:35PM -0800, James M Snell wrote:
> > Of course you can!  All you need in order to create an abstraction
> > is commonality.  Can't you "meaningfully" treat brown cows and black
> > cows as cows?
> 
> Not unless you *first* know: a) what "brown" is, b) what "black" is and c) 
> what a "cow" is.

I think only c) is needed, because that's the only interface that I'm
writing my code to.  "brown" or "black" become values in a color element
in the returned document.  I may not even write code that looks at that
datum.

>  But I don't thing that's the point. It's easy to collect 
> information about an object at runtime (e.g. what color the cow is, 
> whether you're using a square vs. a circle, etc)...

Well, it's easy if you have an interface that lets you do it.  The more
things in your system that respond to the same "give me some info"
request, the easier things get, no?  At one extreme, where every object
has its own method for doing that, you need a big switch() statement;

  switch(type):
   cow: getCowInfo;
   dog: getDogInfo;

etc..

At the other extreme, every object has the same method for the "give me
some info" request;

  object.get()

Do we at least agree that different approaches to this problem have
different architectural properties?  If so, perhaps then we could
explore what those different properties are.

For example, it seems clear to me at least, that the latter approach
is superior from the point of view of simplicity[1].

If deployed on a network, other properties become important.  For
example, visibility.  For the same reasons that simplicity is
improved (I hope we agree on that), the property of visibility[2] is
improved.  Visibility refers to the ability of a firewall admin and
their software to understand what the message means as it's trying to
get through.  Since doing so in the former case would require keeping up
with understanding what all the getCowInfo, getDogInfo, getFooInfo
requests (and new ones as they come along) mean, a firewall admin simply
shuts them off because they can't risk them being insecure.  Having a
single getInfo request makes that *much* more manageable, and therefore
visible, for them and their software.

Can we agree to that too?

> it's a completely 
> different matter to assign *meaning* to that information.  E.g. what does 
> it *mean* to get a brown cow vs. a black cow? 

In both cases, it just means what "getCowInfo" means, since that's the
abstraction being used.  Perhaps I don't understand what you mean.

 [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3_3
 [2] http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3_5

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Received on Wednesday, 8 January 2003 01:33:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:12 GMT