|[swordfish-dev] Re: Chat transcript 11/11/2008 - some remarks|
I think we should differentiate between two types of events:
Internal events can be used to perform service (participant) activity monitoring. Typically these would be generated by the components that perform message handling and processed by a monitoring component. This component creates and updates corresponding MBeans to make the activities observable for management tools. It also tracks message exchanges and sends out operational messages as described below according to the respective policy. Currently these event types are:
- Message tracking, as described above
- Participant lifecycle, whenever an application using the library registers or unregisters
- a consumer or provider for a service
- a handler for a service operation
Operational events are events that are of potential interest to an operator or administrator. In an exemplary implementation, they would be written to a logfile, other sinks would send them to management systems etc. Operational events should either indicate a processing event that might be of interest or they should indicate an error condition that an operator would want to see. Basically it would be a subset of log messages, so it would make sense to think about integrating the log mechanism with the mechanism for generating operational events .
Andrey, Volodymyr: Please take Jerry’s remark into account when you discuss the Event part of the API.
That would cover events during the processing of messages within swordfish. It would also be really nice if we could track some events within the binding components. Could we perhaps weave something in via AOP? I’d guess that would be specific for a given BC, but we could do it for the ones that we are using and provide a howto for someone who wants to use his own BC with Swordfish.
That’s exactly the way we intend to deal with BCs (and SEs for that matter). For this to work, we need an API that concrete aspects can use to send events into the system.
How would reconfiguration of existing components during runtime be handled?
If the configuration agent receives a new configuration from a backend, it updates the corresponding configuration object in ConfigurationAdmin service which propagates this change down to the component.
Back to the top