RE: Yet another attempt to fix D-AC004

It seems that the focus is on late binding of services. This
should certainly be supported by the requirement I was trying
to express. Recall the discussion:

>'is comprised of loosely-coupled components and their 
>interrelationships' 

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

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

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.


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. Since we have some concensus,
lets add the other two:

AR00X.7 components must described by their functional roles and responsibilities.


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

Received on Tuesday, 25 June 2002 22:26:23 UTC