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.
