Considerations with event driven solutions in a Linked Data / OSLC world

I've often been asked about OSLC's plans to support some technology that allows for an event driven model.  Often what this request comes down to is that customers would like to have an open way to subscribe to certain events from a tool and then have that tool (or intermediary) notify them when their criteria has been met.  Once I drill down in the use case a bit further it is often the case that have some clear logic they want to run on the notification receiver side.

For example, let's look at the scenario between a bug tracking system a development team uses and a ticketing system the operations team uses to track customer reported problems.  We've already established how we leverage OSLC to easily relate the ticket from ops to dev.  Though the ops team has a process by which they modify the ticket's status to indicate a fix from development is ready.  The ops team has a number of tools, scripts and reports that run against the ticking system for these 'fix ready' tickets.

There are many ways this problem could be solved, let's take a look at some:

Event driven - this would require new software to be written on both the ticking and bug tracking tool end (perhaps with some eventing software) to make this work.

Polling or cross tool query - there really is no need to promote the state of the ticket to 'fix ready', the ticketing system could just look at (fetch directly) the status of the linked bug.  This would require processes to change on the ops side to not be driven based on that specific state of the ticket but the combined view.

• A variant of this is to just have the ticketing system poll the bug tracking tool (either when ops person is viewing the ticket or an agent) and set the status of the ticket to 'fix ready'.

Manual - dev sends ops an email/IM/txt, ops loads dashboard with sees bugs from dev that have a fix ready, or NCIS-like where ops shows up to dev with giant slushy asking if and when their reported bug will get fixed.

I think we all have seen the manual way of working, which I don't think I need to highlight what is so not fantastic about this.  I touched briefly on the the impact of the two other automated ways to solved this.  Each requires change --  though in the case of polling, only the consumer needs to change (assuming linking is already there).  Here's a quick summary of considerations with each approach:

• Event driven
• Need to manage subscriptions
• Need to process notifications (which could include processing subscription rules and handling authentication)
• May require a 3rd party bus (message broker) tool.  This comes with its own costs to acquire and maintain
• Administration to handle failed notifications (authentication, firewall, server down, etc)
• Easy model for consumers to just subscribe
• Polling / query
• Responses could be cached, polling requests to origin could be intercepted by caching servers and therefore taking the load off the backend tool
• Linked-to tools never needs to know about external apps

Some of these considerations are of course potentially offset if your organization already has an ESB deployed, so that cost may have already been sunk and the investment in administration expertise has been made.  One aspect of event driven solutions is often a problem of mismatch of models and conflicts of change.  For example, if the configuration (state model) of one of the tools changes it may make it so the ESB can't deliver and process the event to the desired end point.  Also if there is a desired to use this approach to synchronize data, in 1-to-1 or many-to-many, then conflicts will arise and the authority (or master) of the data is perhaps lost.

There are many other factors to consider.  It is often best to sit down and look at the topology of tools today, expected view into the future, and scenarios to see what is right for you.  I'm not saying one is better than the other and there is a clear answer for every integration question that will be asked.  I wanted to elaborate on some of the considerations when looking at each alternative.  Some day OSLC may define or endorse a RESTful event driven approach that meets the scenarios provided by the community.  After all that is what drives the work and those the work in the various groups agree with that, that is what get done.