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