You're right. There is a SOAP connector being developed as a JSR. There is also an implementation in mx4j which provides a WSDL for the MBeanServerConnection class (superclass of MBeanServer). I had some problems with it last time. Anyway, as it provides an MBeanServer-like view, the other side has to be aware of JMX and the number of messages passed is high, so the only advantage I really do find useful is to go through firewalls that block RMI. But that's an opinion :-)
-- Manuel Santillán <[EMAIL PROTECTED]> http://www.dit.upm.es/santillan Departamento de Ingeniería de Sistemas Telemáticos Escuela Técnica Superior de Ingenieros de Telecomunicación Universidad Politécnica de Madrid Avda. Complutense, s/n 28040 Madrid SPAIN Tel. +34 913367366 ext.3034 -----Mensaje original----- De: Francesco Furfari [mailto:[EMAIL PROTECTED] Enviado el: viernes, 15 de septiembre de 2006 16:10 Para: felix-dev@incubator.apache.org Asunto: Re: JMX and UPnP 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?
