Re: Dynamic invocation vs. late/dynamic binding

Comments inline..

- James Snell
     IBM Emerging Technologies
     jasnell@us.ibm.com
     (559) 587-1233 (office)
     (700) 544-9035 (t/l)
     Programming Web Services With SOAP
         O'Reilly & Associates, ISBN 0596000952

     Have I not commanded you? Be strong and courageous. 
     Do not be terrified, do not be discouraged, for the Lord your 
     God will be with you whereever you go.    - Joshua 1:9

Mark Baker <distobj@acm.org> wrote on 01/07/2003 10:34:05 PM:

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

Agreed.

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

Good Design Patterns 101 :-)

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

Agreed

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

The judgement of superiority of one approach over another must be based 
strictly on a situational basis. Blanket statements suck ;-)

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

Agreed.

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

I'm not talking about the meaning of the operation, I'm talking about the 
contextual meaning of the data.  "getCowInfo" obviously means you are 
getting information about a cow, but what does that information mean? Why 
are you requesting information about a cow? What are you going to do with 
that information once you get it? What does it mean to get a black cow 
instead of a brown cow? What is the relevance of cows to your application 
in the first place? On the purely protocol level, none of this information 
is relevant since -- on the protocol level -- all you're concerned with is 
moving the data around.  On the application level, this information is 
vital.  What should NOT be vital to the application level is an 
understanding of how the data is moved around.  Given this, on an 
application level, the choice between an RPC style interface, a RESTfull 
interface, an async messaging interface, etc should be largely irrelevant, 
which is why tools like WSIF are useful to create the necessary layer of 
abstraction.

Anyway, overall I think we are in agreement.  The biggest disconnect, as 
it always is, is one of language -- e.g. we need to be sure we're talking 
about the same things.

> [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 13:23:24 UTC