avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: JMX Integration
Date Sat, 21 Sep 2002 12:07:45 GMT

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:mcconnell@osm.net
http://www.osm.net




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


Mime
View raw message