Hi Chris, thanks for reply. Well, you're right...there a finite number of resources.
Let me show an overview of the domain. Qpid is basically a MOM and therefore it has to do with queues, sessions, topic, connections, etc... The protocol that needs to be used for communicating with Qpid is AMQP. In addition there's a special set of extensions of AMQP base protocol (not standard) that are use for management. They are basically a set of messages that are exchanged between the broker (QPid) and the management clients. There a lot of management messages but in order to give you a big picture lets say that there are 2 types : - Content indication message - Schema message The first one is unsolicited. That means when a client connects to Qpid using management protocol, qpid start to send content indication messages about its domain. Each content indication message will contains a state detail of a management domain object (a queue instance for example) : for example : ------------------------------------------------- broker id : skldjasldkjaskldasjdlkja package name : a.b.c.d class name : queue object id : 3742389472347238 1,44,22,true,2837283728937 ------------------------------------------------ Broker id : the identifier of the Qpid server; package name : the logicla grouping of the instance; class name : the class of the instance; object id : instance identifier. The last section is the state of the instance. 1 for example is the value of an instance property...what property? boh I don't know...the same applies for the remaining values... So, in order to be able to create and populate the instance, I need the schema (class definition) of that object. Well, at this point QMan sends a Schema message request and receives (asynchronously) the Schema message response which is something like that : ------------------------------------------------- broker id : skldjasldkjaskldasjdlkja package name : a.b.c.d class name : queue (there's no longer the object id because the queue schema is valid for all queues instances) *** Properties ***** priority depth durable creationTime *** Methods **** purge (int) .... ------------------------------------------------- Note that I simplified all. The messages are binary and are a little bit complicated. Just to answer to your question that only now I can create the class definition, the object instance and populate with the previous incoming data. Now, after that, I have a local representation of that object. Specifically it is registered as an MBean so it will be accessible via JMX : It has 4 properties and one method. After that, I need to expose those object as a WS-Resource but only at this moment I know how is composed its interface (what are properties, their types, if they are read-only, read-write, how many methods the object have, their signature, etc...) So, basically, I developed three builders that are using the MBeanInfo of the just created MBean : 1) WSDL Builder : starting from a WSDL template (which contains some commons features like GetMetadata interface) adds all properties and operations; 2) RMD Builder : creates the Resource Metadata Descriptor associated with resource; 3) Capability Builder : creates a concrete subclass of Capability that expose the management interface of the resource (the purge() method for example). That's (moreless) all! ...It's hard with few words to give you an exact idea of the environment... Let me know what do you think and if you need detailed info about the whole process... Regards, Andrea 2009/2/23 Chris Twiner <[email protected]> > Hi Andrea, > > it sounds like an interesting project especially the use of dynamic > resources. > > Just out of interest whilst I can understand that different queues / > channels require different resources and wsdl I don't understand why > there isn't still a finite number of interfaces. Could you please > expand on that? > > Re util.logging, perhaps a simple wrapper could be used instead like > sl4j. Any such change would have to wait until 2.3.0 which is some way > off I'm afraid. > > cheers, > Chris > > On Mon, Feb 23, 2009 at 4:11 PM, Andrea Gazzarini <[email protected]> > wrote: > > Hello Muse devs, > > I'd like to inform you that Apache Muse has been (widely) used as WSRF > > engine on Apache Qpid WS-DM adapter. > > What is that? > > First of all, Apache Qpid (http://qpid.apache.org) is an implementation > > of the latest Advanced Message Queuing Protocol (AMQP) specification; It > > provides transaction management, queuing, distribution, security, > > management, clustering, federation and heterogeneous multi-platform > support. > > > > As part of that, a sub-module called QMan > > (http://cwiki.apache.org/qpid/qman-qpid-management-bridge.html) has been > > developed (its development is still in progress). It enables Qpid remote > > management using two technologies : > > - JMX : http://cwiki.apache.org/qpid/jmx-interface-specification.html > > - WS-DM : http://qpid.apache.org/ws-dm-interface-specification.html > > Note that the documentation is still in progress too :) > > Concerning the WS-DM adapter I strongly used Apache Muse framework in > order > > to expose domain objects for management. I just override some default > > behaviours (extending them) because the basic requirement was to enable > > WS-Resource definition at runtime. I mean, domain objects that need to be > > exposed for management are built at runtime so the corresponding WSDL > cannot > > be static and cannot be determined at startup, > > Just a little question : while I was poking around the code, I saw that > It's > > not possible to change the logging implementation (java.util.Logger) > > ...isn't that a limit from an extensibility point of view? > > > > Best Regards, > > Andrea > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
