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 <[email protected]> > 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 >
