[EMAIL PROTECTED] wrote:
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.
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.
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.
- 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.
francesco
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
