avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <ifedore...@thinkdynamics.com>
Subject Re: JMX Integration
Date Sun, 22 Sep 2002 01:37:43 GMT
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:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message