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