I'll keep only the most relevant parts.
I think you got the idea :-)
Stephen McConnell wrote:
>
> Nicola Ken Barozzi wrote:
>
> Nicola:
>
>> Stephen McConnell wrote:
>> >
>> >
> components under the Phoenix/Merlin model are constrained in that they
> cannot acquire a service type that is not known at build time,
> furthermore, the scope of the role is constrained to a handful of services.
Correct.
>> -oOo-
>>
>> Basically, it seemed natural to me and to others to specify the
>> component as a role+behaviour.
>>
>> role=java interface
>> behaviour="way" of working
>
>
>
> Which makes sense in the ECM context. Within ECM, the component has the
> overhead of having to be concerned about getting the right component
> implementation. The <ecm-role> includes a <service-interface-class-name>
> which means you will get the right type, but the <hint> becomes a
> sensitive subject because this is the mechanism for ensuring you get the
> right service implementation class.
Usually true ATM, but not necessarily.
A hint is now mapped to an implementation, but it also could be mapped
to a class of implementations that can be seen for the user as the same
implementation.
> In Phoenix/Merlin this issue simply
> does not exist because the set of services in the component manager are
> restricted to only those declared by the component and tagged using a
> string to represent the usage (which also happens to be called the
> "role).
Correct.
ECM in cocoon is used as a base for a second container, which is the
sitemap.
In essence we have two containers, one serving the other.
> 1. Cocoon starts.
> 2. Cocoon reads a configuration containing component class names and
> the associated <ecm-role> declarations and registers these with a
> root ECM instance.
> 3. Cocoon reads a sitemap during which it creates an ECM instance for
> the sitemap processing and during evaluation of the map, it locates
> processing instruction which can be de-referenced to <ecm-role> values.
> 4. Cocoon causes these instructions to be materialized by instantiating
> and pipelining a component to the job.
+1
> I'm going to try and rephrase this. In the context of ECM (as a
> component factory serving dynamic request - and lacking support for
> component dependency declarations), a single flat key is insufficient to
> describe both an interface name and preferred implementation.
Preferred behaviour.
If I request a Transformer (role), and specify Jaxp (hint), I could get
any comapatible one.
> Open Questions:
> ---------------
>
> And what about Fortress ? Where does Fortress fit within this picture?
> What is the potential for Fortress extending a generic abstract assembly
> framework. Are the ECM constraints concerning the CM lookup argument
> semantics also applicable? Does Fortress bring any new
> issues/opportunities to the table?
>
> And what about Phoenix? What are the specific assumptions that Phoenix
> makes with respect to a <ecm-role> lookup arguments in the context of
> it's strict declaration of implementation to service usage mappings?
Any reply takers? ;-)
> Interim Conclusions:
> --------------------
>
> 1. ECM places a specific implementation constraint on a component
> resulting from
> lookup argument value semantics.
> 2. A component implementation that accesses these lookup semantics
> should, as a
> minimum, declare this assumption in the meta-info for the type.
> 3. A generic container should be able to access via a simple API, such a
> policy
> and provide for rapid failure if it is unable to provide support for the
> declared policy.
> 4. The impact of point (3) is that pre-runtime-validation can occur
> through tools
> and this can include ECM dependent components (keeping in mind that an ECM
> component may also have a policy of not declaring dependencies - i.e.
> negating
> the potential validation against the benefit of dynamic lookup).
> 5. Enabling the runtime selection of an appropriate component manager
> capable of
> handling the policy implied by the client requires a more formal
> definition of
> a CM provider (i.e. we are not talking about a container here). Merlin II
> would need to be able to instantiate an ECM (as ComponentManager /
> Component
> Implementation Repository / Service Registry) to service a component
> exposing an CUSTOM_CM_TYPE policy (and I haven't really thought through the
> implications of this just yet).
> 6. Looking at this from the opposite direction, ECM (as ComponentManager /
> Component Implementation Repository / Service Registry ) should be able to
> handle recognition of non-ECM components. Actually, the totally elegant
> solution would be for ECM to be re-cut as an extension of a generic
> service such that the only time it actually got involved in the process
> would be in relation to ECM specific components (a.k.a. dynamic lookup
> component).
Seems correct.
The question now: how do we handle-specify the key of the locator?
> (who is now much more confident that "role" == "different things for
> different people")
;-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
