On Fri, Sep 15, 2006 at 12:58:49PM +0200, Francesco Furfari wrote: > 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. > > [EMAIL PROTECTED] 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. Actually it depends on your business model. I am refering to a model where I know which devices I manage. So a device brings its own MBean and I don't need dynamicity. A bundles contains both the device and its management layers.
> 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? Our jmxconsole is not generic, each gateway declares its own management tab. It's not a generic/all discovery MBeans. You manage the Beans you want, provided you have the corresponding tab in the console. This is the main difference with generic consoles like MC4J or JConsole. It is based on a very simple plugin mecanism like many other... > > > > > - 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? As I told before, the console is aimed at device specific management tasks. In my case it was a fridge management. So it's behaves like a CP but for fridge devices. (Discovery, Sending requests...) > Why not commit it in your sandbox ;-) Legal property issues... > > 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. Humm, your schema is a bit confusing. JMX is an agent, so it only stores beans and provide a remote connectivity to them. JMXConsole <-> JMXConnector <-> JMX Agent <-> MBean <...> The communication between the console and the connector is remote and is standardized with jmxremoting protocol. If I understand what you want to do is to substitue JMXConsole by a remote UPnPdev. So you can have something like UPnP Control Point <-> UPnP Remote Device <- jmxremoting -> JMXConnector <...> I think there are no problems doing this. /stephane > > 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 > >> > >> > > > > > > > > > > > > > > > > > [EMAIL PROTECTED] 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 > >> > >> > > -- Stephane Frenot - Associate professor | CITI/INRIA Ares - INSA lyon | mailto:[EMAIL PROTECTED] Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/ 21 av Jean Capelle | ICQ:643346 (et oui !) 69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714 ----------------------------------------------------------------------------
