Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-ID: <3DE0F2B6.7080802@apache.org>
Date: Sun, 24 Nov 2002 16:39:34 +0100
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
Subject: Re: reduction ad unum
References: <5.1.0.14.2.20021124153246.00bc2e68@mail.sutic.nu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Leo Sutic wrote:

> Stephen,
>
> your point is taken that all operations that are not a lookup of a
> constant value based on a key (such as getHomeDirectory)
> can be seen as a peer service.
>
> First, everything can be seen as a peer service. We don't really
> need the Configurable interface. Instead, one could lookup a
> configurator service:
>
>     interface Configurator {
>         Configuration getConfiguration ();
>     }
>
> and use the returned Configuration. The container would ensure you
> got the correct config.


But you and I both know that the notion of configuring a container 
configurating a target component is different to the idea of the 
component having to handle the overhead of getting a configuration and 
configuring itself.  The distinct difference is the active role of the 
contaner is the current scenario.  

What we have in the framework today are nice set of abstractions.  They 
don't define any paricular service - they simply provide the defintion 
of many aspects of the contract from a container to the compoent.

This thread is talking about the laying in of specific services into the 
framework contract.

I think that is dangerouse.

>
> However, while it reduces the set of classes one has to deal with
> ("everything is a service") there are practical issues with this.
> Peter D. mentioned a few of them here:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=103809692826408&w=2
>
> and I believe he's right.


I believe he believes he's right.

Lets look at what Pete has to say:

> The difference is essentially that Context provides "runtime" / "contextual" 
> or "environmental" data. ie It essentially provides the component with 
> data/services that only the parent container can provide. 

I would agree with the first half of this - that context is used to 
provide runtime/contextual or environmental data.  And I really want to 
emphasis DATA not SERVICES.  Pete goes on to say that context is the 
vehicle for a parent container to provide data and services - and here I 
think that (a) this statement has nothing to do with the Context 
interface contract from the framework - its simply Pete's interpriation 
of how he sees it in terms of things he does with frameworks.  Secondly, 
(b) - the whole notion of mixing in services into context simply defeats 
the purpose of the existing framework service management contract 
(Serviceable/Composable, etc).

Pete goes on to say:

> You could mix concerns but that makes for a more complex configuration setup 
> as now you have to be aware of the differences between container provided and 
> peer provided services and how that effects interaction with them. It also 
> makes the internals of the container much harder to maintain. We actually 
> started to do that about 2 years ago but after a few months decided to back 
> it out. 

I understand why Pete is this.  He has attempted to deal with this from 
the context (no pun intended) of a monalithic container where 
functionity appears from within the container implemetation, not as a 
result of peer services.  But there are working solutions.  If you look 
at Merlin - its a minimal container - it depends on peer services for 
its own extension, peer services through which compoent can exit the 
container, etc.  Take for example lifecycle extension providers, they 
are compoents with zero restrictions, can have depedencies, etc., etc. 
 And soon, the extension manager will be rolled into a component as well 
and factored out the core.

This allows Merlin to to bootstrap and from there to deploy components 
into itself, into extensions, into components.  This works because 
Merlin is *very* focussed on just providing support for framework 
contracts and no contaier specific services.  In fact, if you were to 
build Phoenix using Merlin, you would have one Merlin container handling 
assembly the services that made up Phoenix functinality, and another 
Merlin instance handling the client components.  

Now before someone accuses me of just foing another Merlin pitch - here 
is the important point.  There are issues that we are discussing that 
have the potential to take the framework we have today, and extend it in 
order to solve a problem.  Pete has a problem managing internal verus 
peer services.  ECM users and Fortress users will problems managing 
statically bound services.  These problems are being cast as framework 
problems - I think that's a mistake.  

I do belive there is an unresolved issue concerning service access and 
how that is resolved without breaking ECM or Fortress - but that is real 
different to extending the framework Context abstract to include 
workarounds to Phoneix limitations.  I don't dispute that Phoenix may 
need to expose services via context, but that does not need to disrupt 
the Context interace or its existing contact and semantics.

Pete concludes with:

> The end result? You have replaced container specific context with container 
> specific services and container specific configuration/parameters blending. 
> And this all becomes more complex for end user and harder for us to maintain.

I agree with Pete's conclusions from the point of view of handling internal versus peer within 
an application like Phoenix - because Phoneix has lots of features that are icorporated into 
the application and that does complicate things.  I cannot agree with Pete's conclusion in the 
general sence after all - the Merlin model demonstrates that this issue is container specific.


>
> My analysis would be that the real problem *is* the Context interface.
> Specifically, that it is a total mess. What is it for? Constant value 
> lookup?
> Container specific services only? Container provided services in general?


The Context object is a sealed readonly map for providing tagged data to 
a component  In enforced the notion of loose coupling and is consistent 
with the service access patterns within the framework.  Context as it is 
is fine - its functional - its easily manageable for a container 
providing meta exists - and it can be supplied with portable container 
indepedent sugar coating.

>
> If anything, this is something that has to be solved before we go on.


Assume for a moment that

   1. we ignore the Phoenix issue concerning internal service management.
   2. we have only ECM and Fortress, and an engine for static service
      management (static in terms of assembly based dependency info
      declared statically with a type).
   3. we have a solution to solve the ECM lookup() semantics conflict

In tis hyperthetical scenario - what is the problem with getting 
SERVICEs from a ServiceManager and getting DATA from a context?

If you answer is NONE - we can move forward with resolution of the real 
problems that are inhibiting the proper use of the framework.

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>