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. > > [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. > 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. > > > > > - 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 > >> > >> > > > > > > > > > > > > > > > > > [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 >>> >>> >>
