RE: Yet another attempt to fix D-AC004

I'm not sure why you think that early binding is such a bad thing.  In many
instances late binding is a bad thing for various practical reasons.  I
myself tend to avoid late binding if I possibly can.  This is not just me --
it is an accepted architectural principle in our company's development
community, and I believe that there are other companies with similar views.

Actually, I don't think that a discussion of whether early or late binding
is a "good" or "bad" thing is likely to be very productive.  I think that
both are necessary and both must be supported.  I would be very, very
resistant to a suggestion that early binding should somehow be forbidden or
made impossible.  If you feel that supporting late binding is critical I
won't argue with you -- as long as you leave my early binding alone.

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org] 
Sent: Tuesday, June 25, 2002 2:27 PM
To: michael.mahan@nokia.com
Cc: www-ws-arch@w3c.org
Subject: Re: Yet another attempt to fix D-AC004



On Tue, Jun 25, 2002 at 02:57:02PM -0400, michael.mahan@nokia.com wrote:
> >What does "loosely coupled" refer to here?  In my experience, the 
> >most common use is wrt coupling between interface and implementation, 
> >but it has other meanings.  We should be clear what we mean.
> 
> Well, my intention was that the components are decoupled relative to
> each other (a change in one component doesn't force a change in another
> component) and also in the common use you describe above. If we can agree 
> on that then I can try rewording this to make it clear.

Ah ok, that makes sense.  But I believe the term "late binding" (or
similar) is typically what is used to refer to two separate software
components and their ability to be integrated together at runtime.

We haven't talked about this much as a group, but I personally believe that
"late binding" is critical.  Of course, like so much else in Web
architecture, the generic, a priori interface gives you this.  The IDL or
WSDL approach provides a much earlier form of binding (not a good thing).

> >An interface is definitely an important part of a component, but I 
> >wouldn't say that it defines the component.
> 
> I agree - that's why I threw in the bracketed 'minimally' term. I was 
> also thinking that descriptors like role and responsibilities should 
> be included, but I was first trying to translate the existing text in 
> D-AC004.3.

I don't really see what "minimally" adds, but I agree that describing
components by roles and responsibilities is a good thing.

> >What did you mean by "form" here?
> 
> This was from the original text. I left it in to hopefully solicit
> the author's intent and not throw out an expressed concept 
> indiscriminately. 

Sorry, I wasn't looking at the original when I responded.

> The original text defines component relationships as
> 1. messages 
> 2. protocols by means of which these messages are transmitted
> 
> I was trying to express this. Do you disagree with the level of 
> abstraction
> here (component relationship) or the verbiage?

The verbiage, I guess.  I disagree that a protocol, even an application
protocol, defines or describes much of the relationship between components,
except where that relationship relates to the interface (which an
application protocol does define).

As an example, HTTP clients and proxies both speak HTTP, but the
relationship between them is mostly independant of that(*); it's that a
client can use a proxy to add some value to its connection with origin
servers and gateways (such as getting it over a firewall, or performing
language conversion, etc..).

(*) HTTP proxy authentication would be the one part of the interface that
does relate to the relationship between a client and a proxy.

> >Well, we've talked about using SMTP and HTTP for Web services, for 
> >example, and those don't use XML.  So I'd like to remove this one.  
> >I'd suggest toning it down, but as it's a requirement, it wouldn't do 
> >much good to do that, so might as well remove it.
> 
> In the vein of toning it down, maybe replace 'use' with 'support'.

Good idea.  That both tones it down, and makes it measurable.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Tuesday, 25 June 2002 16:09:33 UTC