You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Andrea Gazzarini <a....@gmail.com> on 2008/12/18 09:39:54 UTC
WS-DM : Status of work (part II)
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!
Re: WS-DM : Status of work (part II)
Posted by Andrea Gazzarini <a....@gmail.com>.
Hi Marnie, I don't know the project plan exactly but your assumption is
right : something needs to be done on Java broker side in order to enhance
it with management capabilities.Fortunately, if it will be done in respect
of QMF rules then QMan will transaparently integrate with that (because it
is not using JMX but AMQP Mmgt extension in order to communicate with
broker).
That means, for example, that QMan is not affected by changes on management
schema because it is sent & built (on QMan side) at runtime by the connected
broker. If some change occur (at runtime) on for example the queue
definition (attributes or operations) a schema for that class is requested
again by QMan and its definition is updated conseguently.
I think that briefly I'll have commit rights so I will be able to update the
documentation of QMan in order to explain (from a user and developer point
of view) how things are working...
Best regards,
Andrea
2008/12/22 Marnie McCormack <ma...@googlemail.com>
> Hi Andrea,
>
> Thanks very much for the speedy response.
>
> I may have misunderstood (apologies if so) but I'd assumed that some
> integration was planned for the existing management objects in the Java
> broker (JMX interfaces and underlying MBeans) and the Qman stuff. However,
> I'm not very plumbed into the QMan/QMF design so apologies if I'm
> incorrect.
>
> Just wanted to be sure that when we're discussing the management schema,
> this doesn't refer to wholesale changes to the existing management objects
> in the Java broker - which might then have impact on the functionality of
> the existing toolset.
>
> I'll try to get a better handle on the QMF/QMan designs over the next
> couple
> of weeks !
>
> Thanks & Regards,
> Marnie
>
> On Mon, Dec 22, 2008 at 11:35 AM, Andrea Gazzarini <a.gazzarini@gmail.com
> >wrote:
>
> > Hi Marnie, from that point of view (backwars compatibility) I think that
> > there's no problem at all because
> >
> > - QMan is not part of JMXConsole or CLI;
> > - It is not affecting the communication protocol between those clients
> and
> > the broker; I think (I don't know exacly) those tools are communicating
> > with
> > Java broker using JMX while QMan is using AMQP;
> > - QMan WS-DM adapter is communicating with QMan using JMX but the managed
> > objects are those under QMan domain and not Qpid; When the Java broker
> will
> > be management enabled its obejcts (connectiosn, queues, exchanges, ) will
> > be
> > transparently proxied by QMan;
> >
> > I did some steps ahead on WS-DM Adapter development and I was just trying
> > to
> > write something about that...I'll send shortly.
> >
> > Best regards
> > Andrea
> >
> > 2008/12/22 Marnie McCormack <ma...@googlemail.com>
> >
> > > Hi Andrea,
> > >
> > > This is a really interesting thread.
> > >
> > > On the java side, the challenge will be to make the changes reuqired
> > whilst
> > > maintaing backwars compatibility with the Eclipse JMX console and the
> > CLI,
> > > both of which are important tools in use.
> > >
> > > I know that Robbie & Martin are both working quite a bit in this area
> so
> > > can
> > > probably help/discuss any changes required here.
> > >
> > > Hth,
> > > Marnie
> > >
> > > On Fri, Dec 19, 2008 at 3:38 PM, Carl Trieloff <cctrieloff@redhat.com
> > > >wrote:
> > >
> > > >
> > > > Andrea,
> > > >
> > > > Great, as you know the QMF stuff now, a starting point might be to
> help
> > > > work out how
> > > > to add QMF to the Java Broker. That is the big elephant that needs to
> > be
> > > > tackled on the Java
> > > > management side which will require the mgnt schema cleaned up between
> > the
> > > > two.
> > > >
> > > > The second big missing piece is being able to push JMX objects onto
> the
> > > QMF
> > > > bus.
> > > >
> > > > When you get there, shout, and I will gladly give you pointers.
> > > >
> > > > regards,
> > > > Carl.
> > > >
> > > >
> > > >
> > > > Andrea Gazzarini wrote:
> > > >
> > > >> Ok Carl it's clear and I agree with you. Concerning the area of
> > > >> interests, I'd like to be involved (when the work on WSDM adapter
> will
> > > >> be completed or at least stable) in the implementation of AMQP
> > > >> management extension on java broker... :)
> > > >>
> > > >> Best regards
> > > >> Andrea
> > > >>
> > > >> On 12/19/08, Carl Trieloff <cc...@redhat.com> wrote:
> > > >>
> > > >>
> > > >>> Andrea Gazzarini wrote:
> > > >>>
> > > >>>
> > > >>>> 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
> > > >>>>
> > > >>>>
> > > >>> Andrea,
> > > >>>
> > > >>> I think the value of the WS-DM Adapter is so that HP Openview, BMC
> > > >>> patrol etc can be plugged
> > > >>> into a Qpid QMF install. i.e. WS-DM provides the way to integrate
> > with
> > > >>> the big brand name
> > > >>> consoles
> > > >>>
> > > >>> However, in writing a console specific to Qpid I would not go via
> > > WS-DM,
> > > >>> but rather directly from
> > > >>> the QMFC interfaces. Two examples are such consoles done from QMF
> are
> > > >>> oVirt (done in Ruby) and
> > > >>> the Red Hat MRG console done in Python. Both of these are web based
> > > Ajax
> > > >>> consoles.
> > > >>>
> > > >>> I can post some screen shots on the wiki, and if you want to hack
> in
> > > >>> that area shout.
> > > >>> Carl.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
> >
>
Re: WS-DM : Status of work (part II)
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Andrea,
Thanks very much for the speedy response.
I may have misunderstood (apologies if so) but I'd assumed that some
integration was planned for the existing management objects in the Java
broker (JMX interfaces and underlying MBeans) and the Qman stuff. However,
I'm not very plumbed into the QMan/QMF design so apologies if I'm incorrect.
Just wanted to be sure that when we're discussing the management schema,
this doesn't refer to wholesale changes to the existing management objects
in the Java broker - which might then have impact on the functionality of
the existing toolset.
I'll try to get a better handle on the QMF/QMan designs over the next couple
of weeks !
Thanks & Regards,
Marnie
On Mon, Dec 22, 2008 at 11:35 AM, Andrea Gazzarini <a....@gmail.com>wrote:
> Hi Marnie, from that point of view (backwars compatibility) I think that
> there's no problem at all because
>
> - QMan is not part of JMXConsole or CLI;
> - It is not affecting the communication protocol between those clients and
> the broker; I think (I don't know exacly) those tools are communicating
> with
> Java broker using JMX while QMan is using AMQP;
> - QMan WS-DM adapter is communicating with QMan using JMX but the managed
> objects are those under QMan domain and not Qpid; When the Java broker will
> be management enabled its obejcts (connectiosn, queues, exchanges, ) will
> be
> transparently proxied by QMan;
>
> I did some steps ahead on WS-DM Adapter development and I was just trying
> to
> write something about that...I'll send shortly.
>
> Best regards
> Andrea
>
> 2008/12/22 Marnie McCormack <ma...@googlemail.com>
>
> > Hi Andrea,
> >
> > This is a really interesting thread.
> >
> > On the java side, the challenge will be to make the changes reuqired
> whilst
> > maintaing backwars compatibility with the Eclipse JMX console and the
> CLI,
> > both of which are important tools in use.
> >
> > I know that Robbie & Martin are both working quite a bit in this area so
> > can
> > probably help/discuss any changes required here.
> >
> > Hth,
> > Marnie
> >
> > On Fri, Dec 19, 2008 at 3:38 PM, Carl Trieloff <cctrieloff@redhat.com
> > >wrote:
> >
> > >
> > > Andrea,
> > >
> > > Great, as you know the QMF stuff now, a starting point might be to help
> > > work out how
> > > to add QMF to the Java Broker. That is the big elephant that needs to
> be
> > > tackled on the Java
> > > management side which will require the mgnt schema cleaned up between
> the
> > > two.
> > >
> > > The second big missing piece is being able to push JMX objects onto the
> > QMF
> > > bus.
> > >
> > > When you get there, shout, and I will gladly give you pointers.
> > >
> > > regards,
> > > Carl.
> > >
> > >
> > >
> > > Andrea Gazzarini wrote:
> > >
> > >> Ok Carl it's clear and I agree with you. Concerning the area of
> > >> interests, I'd like to be involved (when the work on WSDM adapter will
> > >> be completed or at least stable) in the implementation of AMQP
> > >> management extension on java broker... :)
> > >>
> > >> Best regards
> > >> Andrea
> > >>
> > >> On 12/19/08, Carl Trieloff <cc...@redhat.com> wrote:
> > >>
> > >>
> > >>> Andrea Gazzarini wrote:
> > >>>
> > >>>
> > >>>> 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
> > >>>>
> > >>>>
> > >>> Andrea,
> > >>>
> > >>> I think the value of the WS-DM Adapter is so that HP Openview, BMC
> > >>> patrol etc can be plugged
> > >>> into a Qpid QMF install. i.e. WS-DM provides the way to integrate
> with
> > >>> the big brand name
> > >>> consoles
> > >>>
> > >>> However, in writing a console specific to Qpid I would not go via
> > WS-DM,
> > >>> but rather directly from
> > >>> the QMFC interfaces. Two examples are such consoles done from QMF are
> > >>> oVirt (done in Ruby) and
> > >>> the Red Hat MRG console done in Python. Both of these are web based
> > Ajax
> > >>> consoles.
> > >>>
> > >>> I can post some screen shots on the wiki, and if you want to hack in
> > >>> that area shout.
> > >>> Carl.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >
> > >
> >
>
Re: WS-DM : Status of work (part II)
Posted by Andrea Gazzarini <a....@gmail.com>.
Hi Marnie, from that point of view (backwars compatibility) I think that
there's no problem at all because
- QMan is not part of JMXConsole or CLI;
- It is not affecting the communication protocol between those clients and
the broker; I think (I don't know exacly) those tools are communicating with
Java broker using JMX while QMan is using AMQP;
- QMan WS-DM adapter is communicating with QMan using JMX but the managed
objects are those under QMan domain and not Qpid; When the Java broker will
be management enabled its obejcts (connectiosn, queues, exchanges, ) will be
transparently proxied by QMan;
I did some steps ahead on WS-DM Adapter development and I was just trying to
write something about that...I'll send shortly.
Best regards
Andrea
2008/12/22 Marnie McCormack <ma...@googlemail.com>
> Hi Andrea,
>
> This is a really interesting thread.
>
> On the java side, the challenge will be to make the changes reuqired whilst
> maintaing backwars compatibility with the Eclipse JMX console and the CLI,
> both of which are important tools in use.
>
> I know that Robbie & Martin are both working quite a bit in this area so
> can
> probably help/discuss any changes required here.
>
> Hth,
> Marnie
>
> On Fri, Dec 19, 2008 at 3:38 PM, Carl Trieloff <cctrieloff@redhat.com
> >wrote:
>
> >
> > Andrea,
> >
> > Great, as you know the QMF stuff now, a starting point might be to help
> > work out how
> > to add QMF to the Java Broker. That is the big elephant that needs to be
> > tackled on the Java
> > management side which will require the mgnt schema cleaned up between the
> > two.
> >
> > The second big missing piece is being able to push JMX objects onto the
> QMF
> > bus.
> >
> > When you get there, shout, and I will gladly give you pointers.
> >
> > regards,
> > Carl.
> >
> >
> >
> > Andrea Gazzarini wrote:
> >
> >> Ok Carl it's clear and I agree with you. Concerning the area of
> >> interests, I'd like to be involved (when the work on WSDM adapter will
> >> be completed or at least stable) in the implementation of AMQP
> >> management extension on java broker... :)
> >>
> >> Best regards
> >> Andrea
> >>
> >> On 12/19/08, Carl Trieloff <cc...@redhat.com> wrote:
> >>
> >>
> >>> Andrea Gazzarini wrote:
> >>>
> >>>
> >>>> 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
> >>>>
> >>>>
> >>> Andrea,
> >>>
> >>> I think the value of the WS-DM Adapter is so that HP Openview, BMC
> >>> patrol etc can be plugged
> >>> into a Qpid QMF install. i.e. WS-DM provides the way to integrate with
> >>> the big brand name
> >>> consoles
> >>>
> >>> However, in writing a console specific to Qpid I would not go via
> WS-DM,
> >>> but rather directly from
> >>> the QMFC interfaces. Two examples are such consoles done from QMF are
> >>> oVirt (done in Ruby) and
> >>> the Red Hat MRG console done in Python. Both of these are web based
> Ajax
> >>> consoles.
> >>>
> >>> I can post some screen shots on the wiki, and if you want to hack in
> >>> that area shout.
> >>> Carl.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
>
Re: WS-DM : Status of work (part II)
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Andrea,
This is a really interesting thread.
On the java side, the challenge will be to make the changes reuqired whilst
maintaing backwars compatibility with the Eclipse JMX console and the CLI,
both of which are important tools in use.
I know that Robbie & Martin are both working quite a bit in this area so can
probably help/discuss any changes required here.
Hth,
Marnie
On Fri, Dec 19, 2008 at 3:38 PM, Carl Trieloff <cc...@redhat.com>wrote:
>
> Andrea,
>
> Great, as you know the QMF stuff now, a starting point might be to help
> work out how
> to add QMF to the Java Broker. That is the big elephant that needs to be
> tackled on the Java
> management side which will require the mgnt schema cleaned up between the
> two.
>
> The second big missing piece is being able to push JMX objects onto the QMF
> bus.
>
> When you get there, shout, and I will gladly give you pointers.
>
> regards,
> Carl.
>
>
>
> Andrea Gazzarini wrote:
>
>> Ok Carl it's clear and I agree with you. Concerning the area of
>> interests, I'd like to be involved (when the work on WSDM adapter will
>> be completed or at least stable) in the implementation of AMQP
>> management extension on java broker... :)
>>
>> Best regards
>> Andrea
>>
>> On 12/19/08, Carl Trieloff <cc...@redhat.com> wrote:
>>
>>
>>> Andrea Gazzarini wrote:
>>>
>>>
>>>> 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
>>>>
>>>>
>>> Andrea,
>>>
>>> I think the value of the WS-DM Adapter is so that HP Openview, BMC
>>> patrol etc can be plugged
>>> into a Qpid QMF install. i.e. WS-DM provides the way to integrate with
>>> the big brand name
>>> consoles
>>>
>>> However, in writing a console specific to Qpid I would not go via WS-DM,
>>> but rather directly from
>>> the QMFC interfaces. Two examples are such consoles done from QMF are
>>> oVirt (done in Ruby) and
>>> the Red Hat MRG console done in Python. Both of these are web based Ajax
>>> consoles.
>>>
>>> I can post some screen shots on the wiki, and if you want to hack in
>>> that area shout.
>>> Carl.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
Re: WS-DM : Status of work (part II)
Posted by Carl Trieloff <cc...@redhat.com>.
Andrea,
Great, as you know the QMF stuff now, a starting point might be to help
work out how
to add QMF to the Java Broker. That is the big elephant that needs to be
tackled on the Java
management side which will require the mgnt schema cleaned up between
the two.
The second big missing piece is being able to push JMX objects onto the
QMF bus.
When you get there, shout, and I will gladly give you pointers.
regards,
Carl.
Andrea Gazzarini wrote:
> Ok Carl it's clear and I agree with you. Concerning the area of
> interests, I'd like to be involved (when the work on WSDM adapter will
> be completed or at least stable) in the implementation of AMQP
> management extension on java broker... :)
>
> Best regards
> Andrea
>
> On 12/19/08, Carl Trieloff <cc...@redhat.com> wrote:
>
>> Andrea Gazzarini wrote:
>>
>>> 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
>>>
>> Andrea,
>>
>> I think the value of the WS-DM Adapter is so that HP Openview, BMC
>> patrol etc can be plugged
>> into a Qpid QMF install. i.e. WS-DM provides the way to integrate with
>> the big brand name
>> consoles
>>
>> However, in writing a console specific to Qpid I would not go via WS-DM,
>> but rather directly from
>> the QMFC interfaces. Two examples are such consoles done from QMF are
>> oVirt (done in Ruby) and
>> the Red Hat MRG console done in Python. Both of these are web based Ajax
>> consoles.
>>
>> I can post some screen shots on the wiki, and if you want to hack in
>> that area shout.
>> Carl.
>>
>>
>>
>>
>>
>>
>>
>
>
Re: WS-DM : Status of work (part II)
Posted by Andrea Gazzarini <a....@gmail.com>.
Ok Carl it's clear and I agree with you. Concerning the area of
interests, I'd like to be involved (when the work on WSDM adapter will
be completed or at least stable) in the implementation of AMQP
management extension on java broker... :)
Best regards
Andrea
On 12/19/08, Carl Trieloff <cc...@redhat.com> wrote:
> Andrea Gazzarini wrote:
>> 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
>
> Andrea,
>
> I think the value of the WS-DM Adapter is so that HP Openview, BMC
> patrol etc can be plugged
> into a Qpid QMF install. i.e. WS-DM provides the way to integrate with
> the big brand name
> consoles
>
> However, in writing a console specific to Qpid I would not go via WS-DM,
> but rather directly from
> the QMFC interfaces. Two examples are such consoles done from QMF are
> oVirt (done in Ruby) and
> the Red Hat MRG console done in Python. Both of these are web based Ajax
> consoles.
>
> I can post some screen shots on the wiki, and if you want to hack in
> that area shout.
> Carl.
>
>
>
>
>
>
--
Sent from my mobile device
Re: WS-DM : Status of work (part II)
Posted by Andrea Gazzarini <a....@gmail.com>.
Hi Robert at the moment I'm not at home and it's hard to explain that
using this damned blackberry keyboard :) . tomorrow I'll send a
detailed email about that topic
Regards
Andrea
On 12/19/08, Robert Greig <ro...@gmail.com> wrote:
> 2008/12/19 Carl Trieloff <cc...@redhat.com>:
>
>> However, in writing a console specific to Qpid I would not go via WS-DM,
>> but
>> rather directly from
>> the QMFC interfaces.
>
> Can you expand on this? Is QMFC richer than WS-DM and if so in what ways?
>
> RG
>
--
Sent from my mobile device
Re: WS-DM : Status of work (part II)
Posted by Robert Greig <ro...@gmail.com>.
2008/12/19 Carl Trieloff <cc...@redhat.com>:
> However, in writing a console specific to Qpid I would not go via WS-DM, but
> rather directly from
> the QMFC interfaces.
Can you expand on this? Is QMFC richer than WS-DM and if so in what ways?
RG
Re: WS-DM : Status of work (part II)
Posted by Carl Trieloff <cc...@redhat.com>.
Andrea Gazzarini wrote:
> 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
Andrea,
I think the value of the WS-DM Adapter is so that HP Openview, BMC
patrol etc can be plugged
into a Qpid QMF install. i.e. WS-DM provides the way to integrate with
the big brand name
consoles
However, in writing a console specific to Qpid I would not go via WS-DM,
but rather directly from
the QMFC interfaces. Two examples are such consoles done from QMF are
oVirt (done in Ruby) and
the Red Hat MRG console done in Python. Both of these are web based Ajax
consoles.
I can post some screen shots on the wiki, and if you want to hack in
that area shout.
Carl.
Re: WS-DM : Status of work (part II)
Posted by Andrea Gazzarini <a....@gmail.com>.
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 <cc...@redhat.com>
> 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.
>
>
>
>
Re: WS-DM : Status of work (part II)
Posted by Carl Trieloff <cc...@redhat.com>.
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.
Re: WS-DM : Status of work (part II)
Posted by Andrea Gazzarini <a....@gmail.com>.
Hi Robert,
"Is the model not static in the sense that there are queues and
exchanges and connections etc that can all be managed and the
definition does not change?"
I'm sorry but I did not get the point of this phrase...see below.
"Why do we want each queue *instance* to be a type in WSDL?"
Each queue instance won't be a type in WSDL.
There will be a WSDL for the WsResource Queue (and one WSDL for session,
etc...) , with its capabilities (I mean, attributes & operations).
You can see that WSDL as the definition of the "class" queue.
Next, for each queue object (instance), there will be created an instance
of that WsResource. That instance will be managed using WS-DM.
The "dynamic" word used previously means that until Qpid notifies QMan about
the existence of a class named Queue with (for example)
those attributes :
- msgDepth;
- name;
- bytePending;
and this methods:
purge(int)
I don't know (from QMan side and cnseguently from the Adapter) that I must
expose a WsResource instance named queue with those attributes and
operations. I must build this definition (WSDL) at runtime. This happens
when the "schema" arrives on QMan.
After that, when the content indication messages (containing instances)
arrive :
- QMan is instrumenting those instances as MBeans;
- WS-DM Adapter uses the previously created "on-the-fly" WSDL and creates
and instance of that WSResource.
>From a client perspective (ex. HP OpenView) there will be another manageable
resource where it will possibile to invoke :
1) GetMetadata : in order to get the metadata of this resource. This
include a) WSDL, b) XMLSchema or metadata descriptor containing additional
constraints on attributes;
2) SetProperty / SetMultipleProperties : in order to set change the state
of the resource (for Queue at the moment we have only read only attributes
so invoking this operation will produce an "
UnableToModifyResourcePropertyFault");
3) GetProperty / GetMultipleProperties : in order to get the state of the
resource.
4) QueryResourceProperties : has the same meaning of the GetResource but
with query capability;
These are capabilities coming from WS-DM specs so therefore they will be
shared among all managed resources. After those, there will be capabilities
(basically) operations defined by the qpid class in this example there will
be only one operation (the following is the corresponding method generated
on-the-fly on the QueueCapability class) :
public void purge(int request) throws
OperationInvocationFault,
MalformedEntityNameFault,EntityInstanceNotFoundFault,QManFault
where
- the signature of the method is taken from the "schema indication message"
and the corresponding generated WSDL;
- OperationInvocationFault is thrown when the statusCode returned by the
invocation is not 1 (OK);
- MalformedEntityNameFault : when the resourceId contained in the request is
not a valid object name (used for identifying the target resource);
- EntityInstanceNotFoundFault : when the target entity is not found (for
example if it is a temporary queue it could have been deleted by someone
else).
- QManFault : generaka and not well known failure;
Best regards.
Andrea
2008/12/19 Robert Greig <ro...@gmail.com>
> 2008/12/18 Andrea Gazzarini <a....@gmail.com>:
>
> > 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) :(.
>
> Hi Andrea,
>
> I don't know much about WS-DM I'm afraid so I apologise in advance if
> my questions are naive or uninformed.
>
> > 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!
>
> Is the model not static in the sense that there are queues and
> exchanges and connections etc that can all be managed and the
> definition does not change? Why do we want each queue *instance* to be
> a type in WSDL?
>
> RG
>
Re: WS-DM : Status of work (part II)
Posted by Robert Greig <ro...@gmail.com>.
2008/12/18 Andrea Gazzarini <a....@gmail.com>:
> 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) :(.
Hi Andrea,
I don't know much about WS-DM I'm afraid so I apologise in advance if
my questions are naive or uninformed.
> 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!
Is the model not static in the sense that there are queues and
exchanges and connections etc that can all be managed and the
definition does not change? Why do we want each queue *instance* to be
a type in WSDL?
RG