|[swordfish-dev] Re: Chat transcript 11/11/2008 - some remarks|
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
yes, it's interecting process)
who are publisher and who are subscribers in this scheme?
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
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?
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
[some interesting stuff regarding the event API deleted because I didn’t have anything useful to add]
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
Back to the top