Hi all, another piece of ws-dm info concerning notifications & events : While JMX Notification listener is a normal java class running on a standalone application, WS-DM event listeners must be a valid web service endpoint (not a standalone application) so I think that in order to demonstrate the (future) capabilities of the WS-DM adapter we could create a management console that is a web application able to connect with QMan (and therefore to a Qpid management enabled) via WS-DM. So the final scenario will be :
Mgmt Console / Mgmt client (ex: HP Openview) --(wsdm)--> WS-DM Adapter --(jmx)--> QMan --(amqp)--> Qpid What do you think? It should be great for example to develop that management console using Ajax in order to have the user interface automatically refreshed after subscribed notifications... ...but before of that the WS-DM adapter must be completed :) Best Regards, Andrea 2008/12/19 Carl Trieloff <[email protected]> > Andrea Gazzarini wrote: > >> Hi all, >> having studied a little bit more the WS-DM specs ( and all the universe of >> related WS-* specs) I basically re-wrote the prototype(s) :(. >> >> I'm going to explain : >> >> The first version of the prototype (the one I mentioned in my previous >> mail) >> was a WS-DM proxy for QMan; >> It is built "ad hoc" on top of QMan capabilities (and not on a generic >> MBeanServer) because I had datatype conversion problems (WS-DM to Java and >> viceversa). >> >> Briefly this is the problem currently I have : >> >> QMan is a JMX bridge able to expose via JMX Qpid broker domain model(s); >> So >> on top of that we could say that it is instrumenting Qpid using JMX; >> WS-DM is a set of specs for enabling distribuited management using Web >> services. Management of what? a resource (or a set of resources); >> Well, in our perspective the "managed resource" is not QMan but Qpid! >> What is the problem? The Qpid (and as conseguence of that QMan) doesn't >> have >> a static interface! It is dynamic because its domain model is built at >> runtime! >> >> I'll try to explaing better. >> When you declare a managed resource using WS-DM specs the management >> interface of your managed resource should be described on the >> corresponding >> WSDL(s). >> Obviously this is a static declaration so at startup the engine detects >> the >> presence of that web service using its definition (properties & >> operations). >> >> The problem with QMan is that its interface is not static; I mean, it >> proxies several broker domain model(s) and therefore at a certain moment, >> from QMan perspective, >> there could be an object named "queue" with a purge(int) operation that >> can >> be invoked, but after 10 seconds that objects couldn't be there because >> the >> queue has been removed! >> >> In this scenario things became hard... >> >> At the moment I'm trying to do the following : >> >> - A WS-ServiceGroup implementation that is basically the QMan bridge. >> - When the broker notifies QMan that some object is created on its side, >> QMan ServiceGroup creates a WSResource corresponding to this object so its >> WSDL will be generated "on the fly" and >> the properties & operations of that object will be exposed as part of >> WS-DM >> bridge. >> >> - From the requestor side, a query is made to ServiceGroup service in >> order >> to see how many resources we have; This is the request : >> >> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope";> >> <soap:Header> >> <wsa:To xmlns:wsa="http://www.w3.org/2005/08/addressing";> >> http://192.168.197.51:8080/qman/services/QMan</wsa:To> >> <wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing";> >> >> http://docs.oasis-open.org/wsrf/rpw-2/GetResourceProperty/GetResourcePropertyRequest >> </wsa:Action> >> <wsa:MessageID xmlns:wsa="http://www.w3.org/2005/08/addressing";> >> uuid:ac53dfcd-509d-6a07-5d7e-4467b84951a1</wsa:MessageID> >> <wsa:From xmlns:wsa="http://www.w3.org/2005/08/addressing";> >> <wsa:Address> >> http://www.w3.org/2005/08/addressing/role/anonymous >> </wsa:Address> >> </wsa:From> >> </soap:Header> >> <soap:Body> >> <wsrf-rp:GetResourceProperty >> xmlns:wsrf-rp="http://docs.oasis-open.org/wsrf/rp-2"; >> xmlns:wsrf-sg="http://docs.oasis-open.org/wsrf/sg-2";>wsrf-sg:Entry >> </wsrf-rp:GetResourceProperty> >> </soap:Body> >> </soap:Envelope> >> >> - The service returns all the resources known at the moment (note that the >> muse-wsa:ResourceId is the JMX ObjectName). In the following example there >> are 2 queues: >> >> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope";> >> <soap:Header> >> <wsa:To xmlns:wsa="http://www.w3.org/2005/08/addressing";> >> http://www.w3.org/2005/08/addressing/role/anonymous</wsa:To> >> <wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing";> >> >> http://docs.oasis-open.org/wsrf/rpw-2/GetResourceProperty/GetResourcePropertyResponse >> </wsa:Action> >> <wsa:MessageID xmlns:wsa="http://www.w3.org/2005/08/addressing >> ">uuid:9a1c1816-6b68-aef1-b19c-1042de282c41</wsa:MessageID> >> <wsa:RelatesTo RelationshipType="wsa:Reply" xmlns:wsa=" >> http://www.w3.org/2005/08/addressing >> ">uuid:ac53dfcd-509d-6a07-5d7e-4467b84951a1</wsa:RelatesTo> >> <wsa:From xmlns:wsa="http://www.w3.org/2005/08/addressing";> >> <wsa:Address>http://192.168.197.51:8080/qman/services/QMan >> </wsa:Address> >> </wsa:From> >> </soap:Header> >> <soap:Body> >> <wsrf-rp:GetResourcePropertyResponse xmlns:wsrf-rp=" >> http://docs.oasis-open.org/wsrf/rp-2";> >> <wsrf-sg:Entry xmlns:wsrf-sg=" >> http://docs.oasis-open.org/wsrf/sg-2";> >> <wsrf-sg:ServiceGroupEntryEPR> >> <wsa:Address xmlns:wsa=" >> http://www.w3.org/2005/08/addressing";> >> http://192.168.197.51:8080/qman/services/ServiceGroupEntry</wsa:Address> >> <wsa:ReferenceParameters xmlns:wsa=" >> http://www.w3.org/2005/08/addressing";> >> <muse-wsa:ResourceId xmlns:muse-wsa=" >> http://ws.apache.org/muse/addressing >> ">uuid:ab678928-9a50-d2fe-6cc8-f78611138e53</muse-wsa:ResourceId> >> </wsa:ReferenceParameters> >> </wsrf-sg:ServiceGroupEntryEPR> >> <wsrf-sg:MemberServiceEPR> >> <wsa:Address xmlns:wsa=" >> http://www.w3.org/2005/08/addressing";> >> http://192.168.197.51:8080/qman/services/WsResource</wsa:Address> >> <wsa:ReferenceParameters xmlns:wsa=" >> http://www.w3.org/2005/08/addressing";> >> <muse-wsa:ResourceId xmlns:muse-wsa=" >> http://ws.apache.org/muse/addressing";> >> >> qman:brokerID=cd4ebcc5-fb27-4ae9-8418-3a331aa1a367,objectID=ab678128-9d51-d2fe-6cc8-f78611138x42,type=Class,name=queue >> </muse-wsa:ResourceId> >> </wsa:ReferenceParameters> >> </wsrf-sg:MemberServiceEPR> >> <wsrf-sg:MemberServiceEPR> >> <wsa:Address xmlns:wsa=" >> http://www.w3.org/2005/08/addressing";> >> http://192.168.197.51:8080/qman/services/WsResource</wsa:Address> >> <wsa:ReferenceParameters xmlns:wsa=" >> http://www.w3.org/2005/08/addressing";> >> <muse-wsa:ResourceId xmlns:muse-wsa=" >> http://ws.apache.org/muse/addressing";>q >> >> man:brokerID=869e41a2-3f16-4032-875a-7b65e5e13adb,objectID=869e41a2-3f16-4032-875a-7b65q5e13exe,type=Class,name=queue >> </muse-wsa:ResourceId> >> </wsa:ReferenceParameters> >> </wsrf-sg:MemberServiceEPR> >> </wsrf-sg:Entry> >> </wsrf-rp:GetResourcePropertyResponse> >> </soap:Body> >> </soap:Envelope> >> >> - Now, using the ResourceID the client can request object properties and >> metadata (WSDL, XML Schema, etc...) in order to interact with that >> resource. >> >> In this way the bridge is not the interface to QMan but it is only >> managing >> the lifecyle of WS-Resource(s). >> As I told you previously, this is a little bit hard because in a usual >> scenario >> >> - you have your resource instrumented with JMX; >> - you know its capabilities because it has a static interface; >> - you declare those capabilities following WS deployment procedures (WSDL, >> etc...); >> - and finally you deploy that unit on a WS-DM engine; >> >> At the moment I can't do a patch to show you what I mean...I developed all >> those prototypes (experiments) outside the QMan workspace and at the >> moment >> I have (on my eclipse workspace) about 15 projects (!); >> Each of them is trying to explore one WS-DM aspect (notification, >> eventing, >> dynamic add & remove, etc...); >> >> I hope to arrive at the end of the year with something more >> concrete...today >> is my last working day (for this year) and therefore I'll have more time >> at >> home to spend on that topic. >> >> Best regards, >> Andrea >> >> P.S. : If you are more confused after this mail don't worry...me too! >> >> >> > > Wow, does WS-DM from a dynamic interface seem feasible or dreaming.... > > Carl. > > > >
