Posts Tagged ‘Event Driven Architecture’

Governing events and architect anti-patterns

As the name suggests, SOA is all about services. What about events? In the past, several SOA-efforts tended to neglect events; ultimately causing SOA not to deliver on its full potential or fail altogether. So SOA-practitioners evangelized the use of events. And of course we as IT-industry came up with new terminology to emphasize this: EDA, SOA 2.0, and event-driven SOA to name a few.

This blog is not about promoting events since its importance is (hopefully!) recognized and events are mainstream in nowadays SOA-initiatives. If not, I encourage you to read this blog that explains why events are important from both business and technical perspective. There can be no real SOA without events. Events are just as important as services!

Best practices for BPM, SOA and EDA

While visiting ODTUG Kaleidoscope 2009 in Monterey and talking to fellow BPM, SOA and EDA adepts I got this idea about creating a best practices and lessons learned blog series. This first blog is dedicated to best practices in the BPM and SOA-space based on cases from a presentation by Lonneke Dikmans. Subsequent blogs will dive into best practices and lessons learned for a specific product, methodology or technology.

Case I: Introducing BPM. Mistake: Organizational impact underestimated. Explanation: Successful delivery of BPM project, business heavily involved. Never used because they realized after delivery that changes in both the organization and the software were needed. Best practice 1. BPM and SOA are about business, IT and humans. Observe how people work, don’t just ask them.

Case II: Notifications. Mistake: Dependencies between processes modeled directly in the processes itself. Explanation: Process flow sometimes is influenced by other processes. This was modeled into every process: this makes processes tightly coupled to each other and hard to change. It resulted in deadlocks. Best practice 2. Use events to notify running processes. Best practice 3. Monitor & avoid exceptions.

Case III: New technology. Mistake: Use BPEL as a general purpose language. Explanation: BPEL is a domain specific language; it was designed to orchestrate (web) services. Someone coming from a homogeneous -for example PL/SQL environment- in their back office, could decide to rewrite everything in BPEL, even the service implementations. The progress of such a project is very slow, and doing things that used to be easy becomes very hard. Best practice 4. BPEL is a Domain Specific Language (DSL); use BPEL for orchestration only. Best practice 5. Use an Enterprise Service Bus (ESB) to expose services to consumers including BPEL. Best practice 6. Use Java for service implementation. Best practice 7. Use PL/SQL for persistent data manipulation and data integrity rules. Best practice 8. Use rules when you need customization, inference or when business rules are volatile.

Case IV: Quality of Service. Success: involve administrators early. Explanation: Someone designed their first SOA project with quality of service in mind. In production all the non-functional demands were met. Best practice 9: Design architecture for Quality of Service from the start … but only what you really need! Not everyone needs clustering, fail-over, high-availability, and so on.

Case V: Domains. Success: combine a top down with a bottom up approach. Explanation: By defining 6 business domains and one supporting domain, the service taxonomy and event definitions were easier to keep track of. Also defining an owner for some of the services and design guidelines for services that cross domains become possible. Best practice 10. Use domains and layers to facilitate making a taxonomy of services and defining design guidelines.

Conclusion. Think big, start small. Meet in the middle requires aligning Business, IT and People. Architects can be intermediaries. Sharing knowledge and experience is necessary.

The next blog in this series will dive into Web Services best practices.

Events and SOA

In my opinion events are just as important in a SOA as services. I think it’s not possible to achieve a “real” SOA without addressing events separately, just as we do for services. It can be somewhat confusing that events have there own acronym emphasizing their importance, namely Event Driven Architecture (EDA). Some coin this as the upgraded version of SOA, or SOA 2. How we love 3 (or 4 or 5) letter acronyms Most of these different acronyms only add to the confusion, so I prefer sticking to SOA and emphasize events as integral part of it.

So why are events important?
A service-oriented approach should result in business-value (ROI), otherwise SOA only introduces technical complexity through additional middleware. One of the ways to achieve this is through business-IT alignment. Events play a major role in both of these worlds (business and IT).

Business
Businesses deal with (and are causing) events all the time: a customer moving to a different address, a new purchase order, receiving an invoice from a supplier, sending a bill to a partner, and so on. Entities in a business’ ecosystem such as employees, partners, suppliers and customers all react to these events. They initiate new processes, perform activities, propagate events, and so on. It is therefore logical to incorporate events when modeling business processes, which are at the heart of SOA. Just as in all modellng practices, one wants to model and focus on important aspects. In case of SOA this includes processes, services and events.

IT
From a technical point of view events can achieve asynchronicity and de-coupling. By using publish/subscribe and queueing mechanisms, software components are not required to know of each others existence. They simply subscribe to a topic and act based on received (and subscribed to) events. The other way around, if components have some (intermediate) result or state, they can share this with the rest of the world by publishing an event and then forget about it. These components don’t need to know what other components are interested in this information. Of course you’ll need some glue (i.e. middleware) to implement this.

So what does this mean concretely in a SOA-project? For one thing, besides trying to identify what types of services you have (business services, composite technical services, etc.), also investigate what types of events can be identified. There should be an event-registry besides a service-registry. This does not need to be a full-blown tool at first but can simply be documented using Excel in the beginning. Also define the relationship between processes, services and events. What services publish what type of events? What processes are initiated by what events? What running processes are influenced by what events?