felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Furfari <francesco.furf...@isti.cnr.it>
Subject Re: JMX and UPnP
Date Fri, 15 Sep 2006 14:26:26 GMT


Manuel Santillan wrote:
> 
> Francesco Furfari escribió:
>> I re-send this message because I don't see it on the ML
>> ------------------------------------------------
>>
>>
>>
>> Well referring to the Manuel' message, unifying the implementations
>> would be a great move.
>>
>> stephane.frenot@insa-lyon.fr wrote:
>>> Yes that's it. You can have two implementing ways :
>>>
>>> - UPnPdev <-> MBean <-> JMXConsole
>>> In this case each UPnP device declares an MBean which represent
>>> himself. So the JMXConsole can be considered as a controlPoint
>>>
>> I guess this approach is more general and so compatible also with
>> Jmood, isn't?
>> Here I need some hint on JMX architecture because I was wondering
>> whether a DynamicMbean is the right way for probing the UPnP devices.
>> Thinking to the data exchanged, my doubt are related to the mapping of
>> UPnP\Java data type. Would a generic JMX console be able to build
>> automatically the  right interface to interact with the probed UPnP
>> device?
> Generic consoles are only able to handle CompositeData (as well as
> java.lang.*, of course). When there is a complex data type, you can:
> 1. Just use it, but then the remote client has to know about it (and
> probably be designed to handle it)
> 2. Encapsulate it in a CompositeData, which is boring and error-prone
> 3. Register an MBean for that element.  It is effectively equivalent to
> exporting it as a RMI remote object. It has lots of drawbacks, basically
> those of RMI: latency, network overuse and so on. On the client side,
> you can handle this issue by creating a "SnapshotProxy" (i.e, a local
> object that contains snapshot info on the remote object instead of
> accessing it directly)
> 
> So as you see, there are not many options here. Usually, #3 is the most
> flexible. #2 is the most consistent with handling content. 
> JMX's guys are dealing with this issues in Java 6. Basically they are
> creating a new type of MBean: MXBean (the same as
> java.lang.management.*MXBean) which automatically wraps and unwraps
> complex types in composite data. But, then again, Java 6's still in beta.
> 
> Regarding DynamicMBeans, the StandardMBean class is in fact a
> DynamicMBean that exports the interface you pass to the constructor as
> the management interface. For many use cases is by far the simplest
> approach. Consider using DynamicMBeans if you need to add some
> transformations and you have to generate the management interface by
> introspection.

thanks for the useful clarification

francesco

>>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>> In this case the control point declares a MBean that enable the
>>> JMXConsole to manage it.
>>> I have done the second one in a simple example.
>> Great, I'm curious to know how you have instrumented the Generic
>> Control Point :-) . Do you have also implemented the GUI for the console?
>> Why not commit it in your sandbox ;-)
>>
>> There would be also another interesting implementation for remote
>> management, I don't know if JMX can come into help.
>> I'm thinking a scenario where a Control Center installs a blinking
>> light alarm, a physical UPnP device, on its local network and connects
>> the Alarm device to some remote device of one or more managed gateways.
>> There are also other interesting use cases  ...
>>
>> Thus the path should be:
>> Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver
<-> Local
>> UPnP Alarm
>>
>> Of corse we could choose other protocols in order to connect the two
>> UPnP networks, but you are more experienced than me to tell if such
>> chain is a convenient approach.
>>
>> francesco
>>
>>
>>
>>> /stephane
>>> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>>>> The question I don't understand is if you want to do some UPnP
>> control
>>>>> point out of JMX ?
>>>>>
>>>>> /stephane
>>>> I'm not sure to understand your question. Are you asking if I want
>> to create a new GUI (Tab) for your console acting as a Generic Control
>> Point, that is similar to GUI of the bundle we have developed for
>> testing UPnP?
>>>> or the question is about bridging two local UPnP networks ?
>>>>
>>>> francesco
>>>>
>>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> stephane.frenot@insa-lyon.fr wrote:
>>> Yes that's it. You can have two implementing ways :
>>>
>>> - UPnPdev <-> MBean <-> JMXConsole
>>> In this case each UPnP device declares an MBean which represent
>>> himself. So the JMXConsole can be considered as a controlPoint
>>>
>>>
>>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>> In this case the control point declares a MBean that enable the
>>> JMXConsole to manage it.
>>> I have done the second one in a simple example.
>>> /stephane
>>> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>>>> The question I don't understand is if you want to do some UPnP control
>>>>> point out of JMX ?
>>>>>
>>>>> /stephane
>>>> I'm not sure to understand your question. Are you asking if I want
>>>> to create a new GUI (Tab) for your console acting as a Generic
>>>> Control Point, that is similar to GUI of the bundle we have
>>>> developed for testing UPnP?
>>>> or the question is about bridging two local UPnP networks ?
>>>>
>>>> francesco
>>>>
>>>>

Mime
View raw message