Responsibility 7: Provide business eventing, where applicable (e.g. asynchronously via JMS).
This blog post is one in a series. An overview and general outline of this series is linked here.
Background
In a nutshell, according to Wikipedia, an Event Driven Architecture (EDA) is one that promotes the publication, consumption of, and subsequent reaction to events. Publishing applications are independent and decoupled from one to many consumer applications. And consumption is usually performed asynchronously after the producer's unit of work is complete. Java Message Service (JMS) is a common asynchronous messaging specification. An emerging asynchronous messaging specification is AMQP. While it is possible to implement synchronous event processing, tread carefully.
EDA is complementary to the objectives of SOA but this is sometimes misunderstood. The complementary relationship might be best described with an example:
- An AccountService is invoked to Open an Account.
- Once all the required attributes are validated, the account is created. The customer proceeds to use the account to transact business.
- As part of creating and committing the Service's unit of work, a "business event" is published to JMS. The event contains the channel (e.g. 800 number, sales person, or website) used to open the account and other basic meta data about the account that was opened.
- Asynchronously and in parallel, one or more separate consumer applications receive the business event as a notification that an account was opened.
Let's continue the example and assume two applications receive the event that was published and process the event independently and in parallel.
Application #1 receives the event and sends a "thank you" email or letter via Postal Mail, depending on the customer's contact preferences. This correspondence may include invoice and payment terms, return policies, etc. that are specific to the account.
In parallel, Application #2, a SalesForce Automation (SFA) application, receives the event. If the account meets certain criteria (e.g. it is for a corporation) the sales person assigned to the customer's city, state, region, etc. is notified. The SFA application might analyze/classify the account and make key details readily accessible to the sales person--examples include:
- This is an account for a customer that has never transacted business before, or this is a second account for a customer that has not transacted business since X date.
- The customer's business is in industry Y per SIC code 1234.
An event driven approach is more effective than the SFA application waking up on a timed interval to poll the customer service database for new accounts. Or the customer service database creating a daily extract of new accounts to send to the SFA application.
A few benefits of asynchronous messaging include:
- An Event driven architecture provides the ability to react to business events as they occur.
- Consumers are decoupled from producers. Events will simply queue up for one specific consumer application if a planned or unplanned outage is experienced. When the application becomes available again all messages queued during the outage will be processed.
- An application may process messages off the queue in parallel. This is achieved by creating multi-threaded consumers that connect to the queue. This is a simple means to achieve increased throughput.
Considerations
Typically, business services parallel a durable business process it supports. As part of analysis, it is useful to identify the actors that initiate or interact with the business process and also the events (outcomes) that result. Events are often described as a noun plus a verb (or vice versa if you prefer). It is useful to identify and catalog these events as part of business process analysis, capability mapping, etc. Examples of business events:
When required, the service provider carries the responsibility to successfully publish the appropriate business events to the messaging infrastructure. The general objectives and challenges are very similar to SOA. There should be a common approach/strategy to do this. For event/messaging to be effective as an enterprise resource, publishing business events that are of high-value across the enterprise requires planning and coordination across the organization.
Typically, business services parallel a durable business process it supports. As part of analysis, it is useful to identify the actors that initiate or interact with the business process and also the events (outcomes) that result. Events are often described as a noun plus a verb (or vice versa if you prefer). It is useful to identify and catalog these events as part of business process analysis, capability mapping, etc. Examples of business events:
- Account Opened
- Customer Order Placed
- Customer Order Shipped
- Inventory Replenished
When required, the service provider carries the responsibility to successfully publish the appropriate business events to the messaging infrastructure. The general objectives and challenges are very similar to SOA. There should be a common approach/strategy to do this. For event/messaging to be effective as an enterprise resource, publishing business events that are of high-value across the enterprise requires planning and coordination across the organization.
While we've only covered some basics, an effective approach for business eventing is required to spring board into other areas such as event correlation, complex event processing, etc. In using a football analogy, it is important to get blocking and tacking right before focusing too much on the other complexities of the game.
