QMF / QMan Events handling

[Andrea Gazzarini <a....@gmail.com>]

Hi Ted, long time no see :)
Just a question about how should be events handling on QMan...
This is the current situation :

- When a new event or object content message is received, a new MBean is
built on the fly (this really happens on JMX core) ;
- JMX Core notifies the WS-DM adapter about that MBean metadata (properties
& methods);
- WS-DM Adapter builds WS artifacts; I mean, all resources needed to expose
the mbean (the qpid entity) as Web Service (WSDL, RMD, capability class);
- WS-DM Adapter has two "lifecycle" topics : one for events and another one
for objects. Therefore a message is publihsed on the corresponding topic
(depending if the qpid message belongs to an object or an event). Message
has entity info (resource-id, name, package, etc) and a type that can be
CREATED (events and objects) and REMOVED (only objects).

Now, the question :

- Does it make sense to build persistent WS artifacts for events? After all
they are transient objects so I think the notification (on the lifecycle
topic) should be enough to inform management clients.
- If a client connects to QMan do you think it could be interested to
receive past event notifications? Does QMF give me that capability? If it is
not implemented we could add that feature on QMan storing received events
somewhere...In that situation when a management client estabilshes a
connection with QMan it could request all past events... what do you think?

Regards,
Andrea

Re: QMF / QMan Events handling

[Andrea Gazzarini <a....@gmail.com>]

Sorry, I forgot the dev list ------------------------------------

Hi Ted, thanks for reply.
T: I think that event storage would typically be done with a database or a
flat-file storage system since you may wish to keep them for a long time.
A: We could use something like HypersonicSQL which is a good compromise
between database & file storage. Fast & very light.

T: Are you asking whether event storage should be a feature of QMan?
A: Yes, I think it should be a nice feature.

T: Should it be a separate component with WS-DM accessibility?
A: Great idea! It could be a separated (from a logical point of view)
component that is registering itself as a listener of QMan events topic.
When an event notification arrives, it stores the relevant data on a
storage. At the same time it should (using QMan) be exposed as a WS-Resource
with a service that allows requestors to retrieve events history.

What do you think?

Regards
Andrea

2009/2/17 Ted Ross <tr...@redhat.com>

> Andrea Gazzarini wrote:
>
>> Hi Ted, long time no see :)
>>
>> Just a question about how should be events handling on QMan...
>> This is the current situation :
>>
>> - When a new event or object content message is received, a new MBean is
>> built on the fly (this really happens on JMX core) ;
>> - JMX Core notifies the WS-DM adapter about that MBean metadata
>> (properties & methods);
>> - WS-DM Adapter builds WS artifacts; I mean, all resources needed to
>> expose the mbean (the qpid entity) as Web Service (WSDL, RMD, capability
>> class);
>> - WS-DM Adapter has two "lifecycle" topics : one for events and another
>> one for objects. Therefore a message is publihsed on the corresponding topic
>> (depending if the qpid message belongs to an object or an event). Message
>> has entity info (resource-id, name, package, etc) and a type that can be
>> CREATED (events and objects) and REMOVED (only objects).
>>
>> Now, the question :
>>
>> - Does it make sense to build persistent WS artifacts for events? After
>> all they are transient objects so I think the notification (on the lifecycle
>> topic) should be enough to inform management clients?
>> - If a client connects to QMan do you think it could be interested to
>> receive past event notifications? Does QMF give me that capability? If it is
>> not implemented we could add that feature on QMan storing received events
>> somewhere...In that situation when a management client estabilshes a
>> connection with QMan it could request all past events... what do you think?
>>
> QMF provides the transport for objects and events but does not store old
> events.  I think that event storage would typically be done with a database
> or a flat-file storage system since you may wish to keep them for a long
> time.  Are you asking whether event storage should be a feature of QMan?
>  Should it be a separate component with WS-DM accessibility?
>
>>
>> Regards,
>> Andrea
>>
>>
> -Ted
>

Re: QMF / QMan Events handling

[Ted Ross <tr...@redhat.com>]

Andrea Gazzarini wrote:
> Hi Ted, long time no see :)
>
> Just a question about how should be events handling on QMan...
> This is the current situation :
>
> - When a new event or object content message is received, a new MBean 
> is built on the fly (this really happens on JMX core) ;
> - JMX Core notifies the WS-DM adapter about that MBean metadata 
> (properties & methods);
> - WS-DM Adapter builds WS artifacts; I mean, all resources needed to 
> expose the mbean (the qpid entity) as Web Service (WSDL, RMD, 
> capability class);
> - WS-DM Adapter has two "lifecycle" topics : one for events and 
> another one for objects. Therefore a message is publihsed on the 
> corresponding topic (depending if the qpid message belongs to an 
> object or an event). Message has entity info (resource-id, name, 
> package, etc) and a type that can be CREATED (events and objects) and 
> REMOVED (only objects).
>
> Now, the question :
>
> - Does it make sense to build persistent WS artifacts for events? 
> After all they are transient objects so I think the notification (on 
> the lifecycle topic) should be enough to inform management clients?
> - If a client connects to QMan do you think it could be interested to 
> receive past event notifications? Does QMF give me that capability? If 
> it is not implemented we could add that feature on QMan storing 
> received events somewhere...In that situation when a management client 
> estabilshes a connection with QMan it could request all past events... 
> what do you think?
QMF provides the transport for objects and events but does not store old 
events.  I think that event storage would typically be done with a 
database or a flat-file storage system since you may wish to keep them 
for a long time.  Are you asking whether event storage should be a 
feature of QMan?  Should it be a separate component with WS-DM 
accessibility?
>
> Regards,
> Andrea       
>
>   
-Ted

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org