Re: Yet another attempt to fix D-AC004

On Tue, Jun 25, 2002 at 10:25:51PM -0400, michael.mahan@nokia.com wrote:
> There are other WS architecture components that benefit from loose coupling
> which have little to do with early or late binding of services.  So when
> you say late-binding are you architectural covering these other components?
> (For instance, components responsible for discovery, inspection, authenication, 
> confidentiality, reliable messaging, transactions, etc.) 

Ah, I think we have a terminology issue here.

I've been using the term "component" in the context of an architecture.
From our glossary;

Architecture

  The software architecture of a program or computing system is the
  structure or structures of the system, which comprise software
  components, the externally visible properties of those components,
  and the relationships among them."

I'm talking about that kind of component; like a Web client, proxy,
gateway, server, tunnel, etc..

> My preference is to keep the loosely-coupled verbiage at the top level
> and add a lower requirement in the theme of:
> 
> AR00X.6 support both early and late client binding to web services.

Sure.  This should probably be related to D-AR003.6 in some manner,
since it not only suggests "support", it says that we should define
how late binding occurs.

http://www.w3.org/2002/ws/arch/2/06/wd-wsa-reqs-20020605.html#ar003.6

Not sure how best to do that though.

> Moving on, to address another point between Mark and I:
> 
> >>I don't really see what "minimally" adds, but I agree that describing
> >>components by roles and responsibilities is a good thing.
> 
> Minimally was offered in the context that a well-defined interface is necessary
> but not sufficient to describing a component.

Ah, understood.  I agree.

> Since we have some concensus,
> lets add the other two:
> 
> AR00X.7 components must described by their functional roles and responsibilities.

Modulo a "be" in there, that's great.

> Next issue. Lets attempt to converge on this debate:
> AR00X.3 component relationships are described in terms of messages and 
>         message transmission protocols.
> ...
> > 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).
> ...
> 
> If you agree that describing the relationship between architectural components
> is in scope, do you have a better suggestion.

How about just "The relationships between components must be well described"?

> Note that I can see some further 
> issue here that not all component to component interactions would necessarily be 
> via messages. For instance, a programatic interface may be appropriate for a client 
> to access security-related components. 

I agree that a programmatic interface is different than a protocol, but
I believe that at the architectural level, both can be logically
represented as a message being sent from one component to the other.
Certainly, the difference may become visible in other views of the
architecture, such as those describing concurrency.

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 23:01:42 UTC