Nicola Ken Barozzi wrote:
Nicola: First of all - thanks for the reply - I really appreciate the time and effort. Not everything is clear just yet but the reasons for the problem/issues/differences and rationale behind the ECM implementation approach are starting to come into focus. I'll try to summarize my interpretation of these points as I go though your email. If I'm asserting something that is incorrect - please jump up and down - some of my notes are making quantum leaps based on principals which may not be supported by facts. > Stephen McConnell wrote: > > > > > > Peter Donald wrote: > > > >>> Attempt at enforcing the "principal" that a key corresponds to an > >>> interface effectively negates the potential for multiple service > >>> provision where a interface is shared by more than one provided > service > >> > >> > >> No it does not. Decorate it at end with a "/key" and voila multiple > >> service provision of service with same interface. > > > > Ok, I'll try to give my opinion on this. > > <note> > BTW, it seems I'm not the only one that gets frustrated ;-) on these > discussions that are full of meaning and where it's humanly hard to > understand what the others think. It's because we *really* want to > understand and get the best, and this is good :-) > </note> > > > > LET ME MAKE THIS REAL CLEAR, > > I WANT TO KNOW WHY "org.apache.Thing/key" is any different to > > "something" in the context of a component lookup key value. > > Not different. > Your phrase is correct. > > The point is: what do you want to lookup? > > a) a component in a named list of components > b) a component in a *hierarchy* of components > > > IF THE ANSWER IS THAT IT MUST BE DONE THAT WAY TO BE COMPATABLE WITH A > > PARTICULAR CONTAINER THEN THIS IS PLAIN BAD, BAD, BAD - AND SHOULD BE > > DRAGGED IN THE OPEN - REVIWED, AND DISCUSSED OPENLY. If it is not the > > case - then *please* explain *what* my stubborn, irrational and > > ill-informed actions are breaking. > > We could break the *hierarchy* use of the lookup. > > What do I mean by hierarchical? > Basically the same thing as in OOP classes. > > An example that I like is the (made up) Connection role. > > CASE 1 > -------- > Let's say that we have a Connection role that is mapped (in some way, > let's not get into classname-versus-id thing) to the > org.apache.ciao.Connection. > > Then we have three implementations: > org.apache.ciao.TcpConnection > org.apache.ciao.UdpConnection > org.apache.ciao.TcpSSLConnection > org.apache.ciao.UdpSSLConnection > > If a component wants a Connection Component, the container can give > any and the user is ok with it. > > CASE 2 > -------- > Now, let's say that the Component wants to have a Connection Component > that is secure, such as org.apache.ciao.TcpSSLConnection. > > I could create the role SecureConnection, and map it to > org.apache.ciao.SecureConnection that /extends/ Connection. > I have > org.apache.ciao.TcpSSLConnection > org.apache.ciao.UdpSSLConnection > that the container can give. > > Or I could create the "subrole" Secure, and ask for a > "Connection/Secure" Object. To summarize - ECM is maintaining a hierarchy that follows the pattern of a structured definition of what a role string is, where: <ecm-role> == <service-interface-class-name> [ <hint> ] <hint> == <path> [ <reserved-element> ] <path> == <delimiter> <key> [ <path> ] <key> == string representing a node in the hierarchy <reserved-element> == <delimiter> "Selector" | ??? <delimiter> == "/" A second import difference that should be recognized is that ECM does not appear to recognize a dependency. When a client requests a new component by invoking lookup, ECM attempts to resolve that request by interpreting the <ecm-path> resulting in the return of an existing component instance, or, the instantiation of a new Component and the processing of the component's lifecycle and providing itself as the ComponentManager and source for active component resolution of dependencies (i.e. the component being composed can ask for a subsidiary dependency <ecm-role> which implies that a single ECM instance in some form or another represents a security scope). On the rash assumption that I have got this correct, I would like to emphasize that this is very different to Phoenix/Merlin approaches in which the CM supplied instance only contains the services that are explicitly declared under <dependency/> declarations. This difference is significant in that 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. > > > -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. 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). Phoenix goes further than Merlin in that Phoenix provides support for the explicit association of a service reference to the implementation class. In Merlin the equivalent is on the drawing board - it basically follows the same pattern as the rest of Merlin - if there is an unambiguous default solution then use it. > > > Now, as you are not using interfaces as markers, I understand that you > have a defined list of roles with the components to give to your app... > > Which you cannot do in all cases. > > Take Cocoon for example. > The sitemap uses and assembles Components based on their role, but > requests them based on the behaviour (hint). Let me summarize that using different words: 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. > > In essence, it uses Roles as generic interfaces to the Role+hint key. > > *************** > What single flat keys lack is the possibility of requesting different > components that have different behaviours in different moments, while > keeping the same role. > *************** 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. 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? 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). Cheers, Steve. (who is now much more confident that "role" == "different things for different people") SJM -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
