michlmayr 2008 - two papers

1. publish/subscribe in the VRESCO SOA Runtime

The overall architecture for VRESCO looks very similar to a combination of ReCoIn and OSGiBroker. Client Programs make a call to the system using DAIOS and the client library. VRESCO runtime provides support for publishing/subscribing/querying/notification using the engines that VRESCO offers.

Also, persistence is supported for storing events into the DataBase and for querying a history of events, etc.

Below is a snapshot for VRESCO event architecture, which is again very close to the Event architecture that OSGiBroker offers
VRESCO makes use of ESPER event processing engine in order to enable filtering of events and managing events when it comes to their collection and aggregation to infer some meanings from the published events.

Listeners are Esper EQL commands that request for a specific type of event to be delivered to the subscriber registered with the event processing engine.

Persistence is supported in their VRESCO pub/sub system by using NHibernate engine which persists all the events. The events history can then be queried for specific set of exchanged events.


2. Advanced Event Processing and Notifications in Service Runtime Environments

VRESCO supports the following set of events

• Binding and Invocation Events
• Query information events
• user information events

They consider two types of external consumers

1. human
2. services
3. WS-Eventing
4. WS-Notification

Even Ranking

• Priority-based
• Hierarchical
• root events have higher importance compared to leaf events
• Type-based
• Content-based (the keyword exception is more important than warning)
  
• Probability-based (frequent events are less important than infrequent events)
  
• Event Patterns
  

Event-correlations are used to avoid losing track of events and their relationships. something like an event identifier can be used to correlate events to one another.
I think event correlation can be done either by scanning the content for events or by looking into channels and separating events based on the channels they get published to.

Correlation sets enable users to track all relevant events for a correlation ID without losing the track of what is happening between these correlation sets.

VRESCO Web service Eventing specifies 5 different operations

• subscribe
• unsubscribe
• renew
• expires
• subscription ends

important: due to the large set of published events, relational databases are not always preferrable as a more efficient indexing strategy is required. Vector space engine as described in [17] might be a better choice. The advantage is that the search returns a list of fuzzy matches together with a similarity rating.

Throughput for different methods of publishing events can be measured. Also, since we are using caching, it is easier to see how throughput affects the overall behavior of the system. As for events, we can also store all the events in the DB and query the DB only in situations needed. This decreases the chance of having low preformance as a result of dealing with the relational DB.

Their related work is very interesting and important. It is a MUST READ set of papers.