[swordfish-dev] Re: Chat transcript 11/11/2008 - some remarks

[Gerald Preissler <gerald.preissler@xxxxxxxxx>]

Title: Re: Chat transcript 11/11/2008 - some remarks

Hi,

I’ve just seen your discussion and I’d like to add a couple of remarks. Please look for the <Jerry> </Jerry>-Tags in the quote below.

regards
    Jerry


On 12.11.08 16:54, "Oliver Wolf" <oliver.wolf@xxxxxxxxx> wrote:
> Oliver Wolf
> ok, let's use skype for talking and twiddla for drawing and we'll lokk for a whiteboarding solution for skype
> ok, back to the topic:
> in the current sopera implementation, there is a facility that allows software components in the core to send events of two types
> operational events and messge tracking events
> message tracking events are used to track the progress of message processing in the core, operational events are used to notify administrators or other software components of events like failure situations etc.
> what we'd like to do for swordfish is to introduce a concept like this based on the OSGi EventAdmin Service, but a bit more general than we did in the sopera implementation
> let's talk about event sources first
> message tracking events will probably be generated from two types of components: first of all from a special kind of interceptor that lives in the swordfish core and generates events as messages flow through the chain. This interceptor will probably be configured by policy.
> a second source of tracking events will be binding components and service engines if we require events that are generated more closely to the application code or to the wire (but we won't be bothered about them right now, it's only important to keep in mind)
> (BTW, if you have questions please interrupt)
> the source of operational events can be just about anything in the system: the swordfish core itself or any plugin that needs to create notifications about soecial situations
> just take a look at the twiddla drawing that dietmar is just creating
<Jerry>
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
  
  • itself
  • 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 . 
 </Jerry>
> Andrey Kopachevsky
> yes, it's interecting process)
> who are publisher and who are subscribers in this scheme?
>
> Oliver Wolf
> i think it gets clearere when i continue 
> now let's talk about event sinks
> in sopera, we currently have two types of event sinks: first one is a logger that takes events and creates log entries
> second one is an event sink that buffers events for a specified time or until a size threshold is reached and then sends them a single package to a remote service called notification receiver which stores them in a database for reports etc.
> As is said, we intend to use the OSGI EventAdmin Service as the basis for this mechanism
>
> Volodymyr Zhabiuk
> A small question about <<message tracking events will probably be generated from two types of components: first of all from a special kind of interceptor that lives in the swordfish core and generates events as messages flow through the chain. This interceptor will probably be configured by policy.>>
> Could any interceptor in the chain generate that events instead of some centralized interceptor tracker?
>
> Oliver Wolf
> sure, any interceptor can create events
> but it might make sense to have a special kind of interceptor which is dedicated to only this single task
> independent from any other processing steps
<Jerry>
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.
</Jerry>
> [some interesting stuff regarding the event API deleted because I didn’t have anything useful to add]
>
> Oliver Wolf
> ok, next topic: configuration
> question is: where do configurations that are distributed to components by the OSGi ConfigurationAdmin come from?
> the OSGi way of doing this is by using bundle that has special privileges and acts as a configuration agent
<Jerry>
    How would reconfiguration of existing components during runtime be handled?
</Jerry>