Manuel Santillan wrote:
I understand, I was thinking to a different model where the device are
instrumented on the fly. The UPnP philosophy is plug and use, in case
of devices on the LAN, discovered by the Base Driver, and published on
the framework you would break such tenet if you have to install a
probe for it.
That's fairly easy on the agent side. If you've got both the upnp
object and the interface, you can just use the StandardMBean class. On
the other hand, if you have to introspect or read the metadata to create
the management interface, we could create a UPnPDynamicMBeanFactory that
handled those issues. It shouldn't be too hard, but DynamicMBeans,
although powerful, are a bit cumbersome, as you have to manually define
everything..
Yes we have both, the problem I suspect, but give me the time to
understand better JMX, could be the hierarchical structure of the UPnP
device, the OSGi UPnP specification map the nested devices in a flat
structure. I guess that a composed UPnP device would be divided in many
"tabs" on the console. The user should look for the ParentUDN property
of the device to understand how are logically assembled.
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...
So my doubts are founded. The Type of MBean I decide to use will
influence the possibility of representation on a standard console.
Yep, but consider decoupling both sides. You can create your mbeans in a
way that can be handled by generic consoles: mc4j, jconsole, mishell,
etc, and then create a custom plugin/tab for stephane's jmxconsole. I
think it would be much more useful in this way, as many use cases
disallow having a Swing GUI.
I've figured out that the plugin/tab for stephane' console is already
deployed in a separate bundle, the only think needed in the Mbean is a
description (identifier ?) of the plugin. Maybe this small information
is compatible with you.
- 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 <...>
Sorry I had condensed all the JMX layers in the JMX token
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.
I've not read the JMX console specification yet, so I was asking if
the JMX specification can be used to abstract from the communication
protocol used between the gateways.
I was thinking to, let me say a "smart console", acting as the UPnP
Base Driver. The console should register on the local framework a
UPnPDevice service that is a proxy to the remote one. If there is also
another UPnP Base driver on the same framework it would export the
device to the local network of the Control center.
So starting from the Control Center the chain should be:
Control Center -- Remote Gateway
Local UPnP Alarm <-> UPnP driver <-> UPnPDevice <-> "Smart Console"
<-> JMXConnector <-> JMXAgent <-> MBean <-> UPnP-MbeanBridge <->
UPnPDevice <-> Remote UPnP BaseDriver <-> remote UPnPdevice
As said we could also adopt ad hoc protocols to bridge the two UPnP
networks, I was asking if such approach is feasible for you, and
convenient.
Yep, that approach is possible. However, in practice making it
protocol-agnostic through JMX in fact makes it JMX-over-RMI or
JMX-over-JRMP, as they seem to be the only connector implementations
readily available.
:-)
Nobody is working with soap?
