Igor:
I think you definately on the right track here. I have been thinkinng about something similar in the work I've been doing in Merlin. If I understand correctly, what your describing is the ability for an application to be able to declare dependecies and export services. I'm thinking/experimenting and working on the same thing in terms of Merlin Containers. In both cases - (Phoenix and Merlin) the desired result is that the result of application/container deployment is the establishment of a new set of services. These services can then be picked up and used by other services (indepedently of the deployment infrastructure). Igor Fedorenko wrote: > I am thinking about implementing this in a generic way, so > (theoretically) block can access components deployed into Embeddor and > (later) into any application deployed into phoenix. I think we already > agreed that block developer will declare these external dependencies > as any other dependency, however we did not talk about assebly.xml > syntax that would support this. I see two slightly different solutions > and need your help to choose one of them. > > One option is to use block factory to define foreign blocks in > assembly.xml and use these blocks as any other block. Emberddor would > extend BlockFactory interface and phoenix would provide it as implicit > "system-manager" factory (i.e. it does not need to be configured). For > example, > > <assembly> > <block name="system-manager" factoyr="phoenix-kernel" > implementation="org.apache.avalon.phoenix.interfaces.SystemManager"/> > <block name="my-block" class="test.MyClass"> > <provide name="system-manager" > role="org.apache.avalon.phoenix.interfaces.SystemManage"/> > </block> > </assembly> > > > Another option is to define new tag "foreign", "external" or something > like that that could be used in place of "provide" tag. For example > > <assembly> > <block name="my-block" class="test.MyClass"> > <foreign container="phoenix-kernel" > role="org.apache.avalon.phoenix.interfaces.SystemManage"/> > </block> > </assembly> > > In this case we will need to define new interface that will be > implemented by all block containers and will provide access to blocks > deployed into the containers. > > So, what do you think? I think that we need to keep the concepts of importing and exporting services as parrallel (equivalent?) to the component model. In the case of a Phoneix assembly defintion this would suggests that the assembly is defining a set of exported services. In the case of Merlin this would suggst that a container is defining/exporting the same thing. In both cases there is the problem of scalability - a block providing a management service runing under machine A should be assignable as a service provider to a component running under machine B without concern for the infrastructure support the component deployment - i.e.a Merlin hosted business component dependent on a Phoneix hosted management service or whatever. This ends up raising the requirement for a portable service defintion and protocol. Cheers, Steve. > > > > Stephen McConnell wrote: > >> >> >> Igor Fedorenko wrote: >> >>> >>> >>> Nicola Ken Barozzi wrote: >>> >>>> >>>> Stephen McConnell wrote: >>>> >>>>> >>>>> >>>>> Peter Donald wrote: >>>>> >>>>> >On Mon, 2 Sep 2002 02:45, Huw Roberts wrote: >>>>> > >>>>> > >>>>> >>>>Rather than this I think I may prefer something simpler - at >>>>> least >>>>> >>>>initially. Something like >>>>> >>>> >>>>> >>>>BlockContext.register( String topic, String name, Object >>>>> object ) >>>>> >>>>BlockContext.unregister( String topic, String name ) >>>>> >>>> >>>>> >>>>Job jobOne = ... get the job somehow >>>>> >>>>ctx.register( "jobs", jobOne.getName(), jobOne ); >>>>> >>>>... >>>>> >>>>ctx.unregister( "jobs", jobOne.getName() ); >>>>> >>>> >>>>> >>>>The reason for this is that then we don't have to expose >>>>> SystemManager >>>>> >>>>to clients and thus we are free to evolve it as we see fit. >>>>> However it >>>>> >>>>exposes all the information needed to manage object. >>>>> >>>>Like? >>>>> >>>> >>>>> >>>> >>>>> >>I have 3 issues: >>>>> >>1) The ability to add more than one level of hierarchy beneath >>>>> the blocks. >>>>> >>2) Using an interface will make the client code cleaner and >>>>> more portable. >>>>> >>3) Client code will be hooking into this, meaning we are >>>>> committed to >>>>> >>supporting it going forward. >>>>> >> >>>>> >>I can live with this for now, but i want to consider how it >>>>> fits into >>>>> >>the longer term direction. What I'd like to do, is add a >>>>> >>ManagementContext interface to Framework, and then have >>>>> SystemManager >>>>> >>extend this. That would be the first step towards making the >>>>> >>functionality available in other containers. Does that sound >>>>> ok? If >>>>> >>so, how do we proceed in that direction? If its not too big a >>>>> deal >>>>> >>maybe we could skip this intermediate step? >>>>> >> >>>>> >> >>>>> > >>>>> >I would still prefer to go with the >>>>> > >>>>> >BlockContext.register( String topic, String name, Object object ) >>>>> >BlockContext.unregister( String topic, String name ) >>>> >>>> >>>> >>>> >>>> >>>> -1 a Context should never be used by a Container for its services. >>>> If it is used, it's basically giving a service to everyone without >>>> IoC. >>>> >>>>> >The reason is that we have discussed that feature in the past >>>>> without > really coming to any conclusion. >>>>> >>>>> Adding behaviour to an context implementation over and above the >>>>> framework defintion of context means that you are defining a >>>>> specilization of the Avalon Component Model for Phoenix. Components >>>>> that include a dependency on that model are no longer portable. >>>>> Alternative solutions to introducing the functionality you are >>>>> describing is totally possible without introducing the complication >>>>> associated with BlockContext - i..e. use the context object to >>>>> aquire an >>>>> abject implementing the interface the component needs, then apply >>>>> register/unregister against that interface, or, havbe the copmponent >>>>> declare a depedency on a registery service of some kind. >>>> >>>> >>>> >>>> >>>> >>>> I resist also this, since we are using services in a context, >>>> rather than be given them by the Container. >>>> >>>> I have looked in the archives and seen that once upon a time, >>>> Context was indeed used as a common service, and a common place to >>>> put services. >>>> >>>> I think that Context should never keep services where possible. >>>> >>>> For example, ServletContext is about instance data, not services. >>>> >>>>> This was discussed in respect to the shutdown request handler - this >>>>> requirement is no different. >>>> >>>> >>>> >>> >>> What if we provide instance of SystemManager via >>> ServiceManager.lookup()? I would not bother getting block's >>> management subcontext -- it does not map into anything in JMX >>> anyways -- just put root system manager into appropriate >>> ServiceManager instance. >>> >> >> Sounds perfect - assuming that the component aquiring the >> SystemManager declares this as a dependency. >> >> Cheers, Steve. >> > -- 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]>
