Build Your SOA: Creating Reusable Service Patterns

*Editor’s note: This article was first published in the Winter ebizQ Buyer’s Guide print edition, a supplement to the Business Integration Journal.

It seems the virtues of SOA are finally beginning to pervade the corporate consciousness.  While architects have considered it a best practice for decades, business managers are beginning to catch onto the fact that SOA may be their best ticket to business agility, and they’re starting to invest. 

According to a recent ebizQ online survey of over 300 members from 21 industries, increasing business agility is the number one reason for SOA adoption. In fact the basic tenet of SOA is agility. The goal of SOA design is to minimize impact of change.

However, while it is fairly straight forward to teach programmers how to write or call a Web service interface, it is far more difficult to teach them how to create loosely coupled reusable services that can easily be changed.  This is truly a new programming paradigm.

This article is based on an event-driven service design method that helps business analysts, architects and developers design services optimized for agility and reuse.  Part of this method provides a framework for identifying service characteristics and patterns that can used to create reusable services.      

Types of Services

A service is a software component or module that can be combined with other services to create a business solution or application. Types of services include: 

  • Process oriented services. These are business processes that have multiple steps but fulfill a single business purpose, such as opening an account, or placing an order. 
  • Function oriented services. This includes both business and system functions. Examples of a business function include a software module that calculates a mortgage, or performs a credit check.  Examples of system functions include error handling and security authentication.   
  • Data oriented services. There are a myriad of data oriented services required to maintain the integrity of distributed data across the architecture.  These include accessing distributed data and presenting a single view, data mapping and transformation, maintaining data quality and integrity, and maintaining metadata. 

A single process can include all of these types of services.  But it is useful to classify the type of service because different types of services inherently have different characteristics, including behavior patterns and communication style.

Levels of granularity

A service can be comprised of one or more services.  Getting the level of granularity right is the greatest factor in enabling reuse.  To aid developers in defining the right level of granularity for the services we have defined three levels of granularity.

  • Business Services represent the coarsest level of granularity.  A business service performs a logical business function or process, such as opening a customer account.  This is the level that business monitoring and metrics would be applied to. 
  • Intermediary Services provide location, semantic, and technology independence between service consumers, business services and provider services.  For example, if the business service requires customer information that is sourced in several different back end systems, an intermediary service performs the distributed query and aggregates the data into a single view.  Many of the system function oriented services, including integration services, can be characterized as intermediary services.
  • Provider Services are the finest level of granularity.  Provider services map to application level interfaces.  For example, if a business service or process includes functions from several different back end systems, the functionality in each of these systems would be a provider level service. Examples include retrieving a customer record or doing a mortgage calculation. 

When levels of granularity are defined for different types of services, patterns begin to emerge.  For example, data oriented provider services will probably need to be provisioned for each of the CRUD operations for critical enterprise data to maximize reuse.   

Service Communication Style

Given the pervasive use of Web Services in SOA implementations, request-reply is often thought to be the only single communication style. In fact, SOA has several communication styles, including asynchronous no reply mechanisms which enable event-driven SOA.

The types of possible communication styles include:

  • Synchronous communication requires direct connection between services.  Like a telephone call, the other party must be available in order for the communication to take place.  Synchronous communications are often blocking - no further processing can occur until a reply is received.
  • Asynchronous communication is like an email or telephone message.  The message is sent to a queue, and read at another time.  There is no live session maintained with the requestor. The actions are non-blocking, meaning that the requestor continues processing while waiting for a reply.  Asynchronous communications are more scalable than synchronous communications.
  • Request reply is a communication where a consumer, or another service, makes a direct request to a provider service, and the provider replies. The interaction is usually synchronous and blocking, although it is possible to have non-blocking asynchronous request/reply interactions. 
  • One-to-one message based communications are generally asynchronous and non-blocking.  An event triggers a request to a service.  The provider service processes the request when it becomes available, and then (optionally) replies via a message.  This creates loosely coupled communications which provide greater agility and scalability.
  • Publish and subscribe communications are a broadcast type of communication.  Services subscribe to information based on topic or event, and the information is distributed to those on the subscription list. Publish and subscribe is an asynchronous non-blocking form of communication useful when the originating service does not need to be aware of the downstream consuming services. 

An enterprise SOA will likely include all types of interactions. The key is to know when to use which type of interaction. 

Service Behavior Patterns

We have defined three groups of service behavior patterns. An individual service can include a combination of behavior patterns.

The first group reflects the job of the service.

  • Worker is a service that performs a requested function or process.  A worker can be information bearing, or change the state of the entity it works on.  
  • Monitor is a service that observes something and report on its findings based on monitoring and notification rules.
  • Agent is a service that observes something and then acts on its findings, such as providing information to a monitor, generating an event, or invoking a service. 

A service can either be stateful or stateless.  It must be one or the other.

  • Stateful behavior means that the state of the service is actively managed, for example in a transaction. Until the transaction has committed, the resource(s) may need to remain locked.  The transaction then either must successfully commit or be rolled back. Process-oriented services are examples of stateful services.
  • Stateless behavior means that the state of the service is not retained between service invocations, or over time.  The vast majority of services are stateless.    

Services that include transactions can either be short or long lived.  Essentially this refers to the shelf life of the transaction. 

  • Short-lived transactions are measured in nanoseconds or machine processing time.  An example would be updating an account balance.  Short-lived transactions are usually stateful and synchronous. 
  • Long-lived transactions can take minutes, hours, days, even weeks. Distributed processes which cross organizational boundaries often include long-lived transactions.  An example would be provisioning a telephone service, or a drop shipment from a third party supplier.  Long-lived transactions are asynchronous. They have state that must be persisted in the system.                          


The above framework for characterizing types of services serves a number of purposes. It helps developers understand the different types of services that need to be designed.  It will help classify service templates for common patterns, such as a stateless service that aggregates information from multiple sources, or publishes information. Over time these templates will become building blocks for creating reusable business services. 

In the short term, one of the low-hanging fruits for reuse is intermediary system services.  These are the services that integrate and manage disparate services, especially while evolving existing IT systems into SOA services.  Examples include common security services, translation and transformation services, run-time policy management, etc.  Currently companies are gaining substantial ROIs from deploying common intermediary services that are reused across projects.  Increased business agility will come from developing business services and processes that can easily be changed.  Increased reuse will come from developing the finer grained provider services. As organizations progress down the SOA path and build out all the types of services, ROI and business agility will increase exponentially.

About the Authors

Beth Gold-Bernstein is an author and independent consultant specializing in SOA solutions.

More by Beth Gold-Bernstein

Brenda Michelson is an IT strategist, hands-on practitioner, and the voice of business-driven architecture. Brenda’s day job is principal consultant for Elemental Links. Brenda also contributes architecturally to the Patricia Seybold Group. Brenda spent 19 years in corporate IT, most recently as Chief Enterprise Architect for L.L. Bean. At L.L. Bean, Brenda was responsible for the articulation and execution of the enterprise architecture strategy (J2EE transformation, enterprise integration, SOA and EDA), strategic planning, portfolio management and talent development. Previous to L.L. Bean, over the span of 10 years, Brenda provided development services for Insurance, Banking, a Chip Manufacturer and a world leader in Aircraft Engine Design & Manufacturing. Email Brenda.

More by Brenda M. Michelson

About Elemental Links

Elemental Links is an IT consulting and advisory practice specializing in strategy, architecture, and portfolio planning for business-driven IT.