qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Gazzarini <a.gazzar...@gmail.com>
Subject Re: QMF / QMan Events handling
Date Tue, 17 Feb 2009 14:05:22 GMT
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 <tross@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message