SOA: Responsibilities of Service Providers (Part 8)

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:

1. 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.
2. The customer's business is in industry Y per SIC code 1234.

The SFA application might even alert the sales person's Blackberry if the account meets criteria specified in his/her alert preferences within the SFA app.  If so, this could be done automatically in a matter of seconds or minutes after the account was opened.

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:

1. An Event driven architecture provides the ability to react to business events as they occur.
2. 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.
3. 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:

• 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.

SOA: Responsibilities of Service Providers (Part 7)

Responsibility 6:  Implement formalized change management. And implement interface versioning to limit the number of clients impacted by changes (decoupling).

This blog post is one in a series.  An overview and general outline of this series is linked here.

Background

Service Oriented Architecture (SOA) typically targets reducing duplication and increasing reuse as a means to promote a more cost effective and agile operating model.

As part of growing a SOA, we hope applications use existing services to solve business problems.  Over time this translates to a service having interface dependencies with many client applications.  Conversely, if a service only interacts with a single client this is not optimal as point-to-point solutions are not the primary focus of SOA.

As the number of interface dependencies grows for a service, there can be challenges.  Examples:

1. Implementing changes to the interface definition can be a lengthy "ocean boiling" experience when many client applications are impacted.
2. A change is needed to a service to meet a new set of requirements.  How do you pinpoint all applications that are impacted?  And can we spend less time and energy assessing impact?
3. Unexpected outages can occur if impact analysis is inaccurate.

Considerations

It is the responsibility of the service provider to follow a standard, generally accepted versioning strategy.  This consistency is in keeping with Responsibility 4.  A complete strategy supports major versions (breaking changes) and minor versions (compatible changes within a given major) of the interface definition or contract.  The service provider must assess whether a change to the interface contract is a major or minor change.

A minor change is a compatible change.  For example, adding an optional element to the service's request or response for a customer's "maiden name" would be considered a minor change.  Only clients needing visibility to "maiden name" would need to upgrade to adopt the new interface version.  All other clients will continue to work without any changes.

It is important to identify opportunities leverage minor versioning.  These changes can be implemented much easier than major changes but always in keeping with Responsibility 5.  No hacks please :-).

The service provider must maintain effective communication with all application owners that invoke a given service.  It is the responsibility of the service provider to ensure awareness and coordinate all upcoming changes.

Leveraging security is an effective method to identify client applications that invoke a given service.  Air-tight impact analysis can be achieved by all services implementing a common enterprise-wide security mechanism.  This can be justified through the benefits of enabling effective impact analysis and through Responsibility 4.  The basic mechanics include:

• Each client application should be issued a unique identifier or token to use as a credential.  This is passed by the client to all services it invokes.
• The service authorizes client-specific access using the unique identifier or token.  An authorization rule must exist for a client to invoke a service successfully--anonymous access should not be allowed.
• Consider measures to prevent the client's unique identifier or token from being spoofed or shared among multiple applications. Addressing this is part technology (think public key encryption) and part governance (or "g8e" for those that cringe at the term governance :-).
• Authorization rules (and secondarily usage metrics) are used to perform air-tight impact analysis.

View security as your friend in managing interface dependencies between all clients and services.

In a later series, I plan to blog about the details of an effective major/minor interface versioning strategy.  An effective versioning and decoupling strategy is a key component to realize the benefits of agility and reduced complexity.