Hmm, I think I am starting to understand what I wanted to ask. ;-) I already have block factories which could be used as a generic way to use external services in phoenix application. My question -- do we need another solution which is optimized/simplified for a case when both phoenix application and "external" service live inside same java VM?
Stephen McConnell wrote: > > 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. >>> >> > -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
