Service Orchestration Guidelines

Many SOA articles, white papers, and vendor documents talk about “service orchestration”. But understanding of the underlying concepts and orchestration best practices remain elusive.

A quick Google search will produce a number of articles and links that discuss service orchestration and related topics. Most of them will talk about BPM engines, ESBs, and BPEL. This, unfortunately, pollutes the true definition of service orchestration and gives it a much more technology centric view.

In my opinion, Service Orchestration is an automated way to combine several services together to achieve new functionality. The end result is a new composite service that provides a distinct business capability and can be invoked independently. It must have all the appropriate attributes as discussed in my previous article.

Orchestration is a technology independent concept. It can be achieved via a descriptive language such as BPEL, built-in tools within a specific platform (ESBs typically provide their own orchestration mechanisms), or programmatically. Depending on your needs, situation, or technology available, the best way to perform service orchestration may be different. Here are a few guidelines to help you create service orchestrations faster and make them more flexible, maintainable, and scalable.

• Use the platform with built-in orchestration capabilities as your first choice
• Avoid implementing service orchestrations programmatically whenever possible
• Choose a platform or mechanism that can easily perform flow logic, result aggregation, message transformation, and business rule application
• Ensure the composite service fits the definition of a service, i.e. has all the attributes of a service

The rationale behind the above guidelines is very simple. You want to choose a platform that already provides most of the capabilities you will need when creating new service orchestrations. You will typically need to call several services, aggregate their results in some way or chain the calls together through some kind of logic, transform the end result to match the exposed contract(s), and return it. The less work you have to do and the more you can rely on the platform’s capabilities, the more efficient your orchestration will be. If you can complete your orchestration work through a visual interface and never see the code, you are on the right path. This way, you will spend less time maintaining the orchestration, it will be easier to make changes, and you don’t have to build all the necessary mechanisms from scratch.

Many would argue that a programming language will give you the most flexibility when implementing an orchestration. While this is true, the overhead is pretty large and efficiency is low. First of all, no programming language seamlessly integrates all the mechanism you need to create an orchestration, especially in a visual way. Secondly, every time an orchestration needs to change in some way, no matter how small, new code needs to be written, deployed, and tested. While the same steps need to be performed on any orchestration platform, the level of effort will be a lot smaller on full featured orchestration platforms.

When creating service orchestrations, it is important to maintain proper relationships between composite and atomic services. The diagram below shows which services should be allowed to interact with each other.

The following list details the rules and guidelines for establishing relationships between composite and atomic services.

1. Atomic business services should not call each other. Use orchestration to combine several business services together.
   The goal of service orchestration is to combine several services together through a series of logical steps and expose new capability to the consumers. Orchestration platforms, as discussed above, provide a lot of functionality to make this work easy and efficient. If individual services are allowed to call each other, they would not be taking advantage of the orchestration platform’s capabilities. Furthermore, when business services call each other, it establishes a tight coupling between them, which makes them less reusable and harder to maintain. Atomic business services should provide specific, well defined business capabilities and be reusable in their own right. Reliance on other services to complete work indicates plurality of purpose and lack of specificity.
   
2. Business services can call Utility services.
   While coupling services together should be avoided as much as possible, sometimes generic, low level functionality that needs to be invoked from a business service is exposed via utility services. It would be an overkill and sometimes even impossible to use an orchestration platform in order to allow business services to take advantage of such functionality as logging, retrieving or storing configuration information, and authorization.
   
3. Utility services cannot call Business services.
   Utility services should not be tied to any business processes or capabilities. Thus, a utility service calling a business service would violate this rule.
   
4. Business services cannot call Composite services.
   The logic behind this guideline is the same as in disallowing business services call each other. A composite service is also a business service. Thus, a business service calling a composite service should not be allowed.
   
5. Composite services can call other Composite services.
   Other composite services are allowed to participate in orchestrations. They should be treated as regular atomic services in this case.

Note that, even though atomic business services and composite services are, in essence, business services, they are different and guidelines provided above are not contradictory in their treatment. There are two levels at which they should be compared -- logical and physical. From a logical perspective, atomic business services and composite services are the same. They expose some kind of unique business capability and adhere to the service definition guidelines. From a physical perspective, however, they are different. Atomic business services, as opposed to composite services, rely solely on internal business logic and direct interaction with backend data sources to perform their work. Thus, by definition, atomic business services should not call other business services as part of their implementation. By the same token, since composite services already rely on other business services to complete their work, they should not differentiate between calling atomic business services or other composite services.

Service orchestration is a complex topic and might take a series of articles to discuss completely. However, the rules outlined above should establish a good foundation for creating and managing composite services.

Services Explained

Since the SOA term was coined, many discussions raged on what a service was from a business and technical perspectives. In this article, I offer my views on the topic.

There are several categories of services. Many leading SOA vendors and thinkers typically break them down into Business and Utility types. A Business service represents a business capability that is needed to complete a step within a larger business process. Examples may include retrieving customer information, making payments, or checking order status. Utility services represent a technical capability that is business process agnostic. Examples are e-mail, logging, or authentication services.

Services can be combined together to create composite services. This is called orchestration. An example of this can be a Money Transfer service that needs to debit one account and deposit money into another one. Composite services can also be categorized as Business and Utility. Best practices and general orchestration guidelines as related to orchestrations, atomic services, and their relationships will be discussed separately.

Regardless of the type, a service is comprised of three components.

• Interface
• This defines how services are exposed and can be accessed by its consumers.
• Interfaces are not limited to Web Services and can be represented by any remote messaging protocol.
• Contract
• This defines what services expect during the interaction with the consumer. Message structures, relevant policies, and related security mechanisms are all part of a contract.
• Contract defines a “legal” agreement on how the service and its consumers should interact.
• Implementation
  
  • This is the actual service code.

A service may have multiple interfaces. Different consumers may have the need to access the service via different protocols. For example, a Java consumer would like to access a service via a Web Service protocol while a Mainframe application can only use MQ Series. Even though a service may itself expose multiple interfaces, it is more effective to let the ESB platform handle this. For more details about the rationale behind this recommendation, see “To ESB or Not to ESB?" post.

A service may also have multiple contracts. I have recommended in the past that for a service to be maximally reusable, it needs to implement the Service Façade pattern (see “SOA Façade Pattern” post and “Service Façade” pattern). This pattern recommends that multiple different interfaces and contracts for the same service be created. The Concurrent Contracts pattern also addresses this issue.

It is important to understand that while the interface, contract, and implementation describe a service as a whole, they are not closely tied together. An interface is not dependent on the contract details and should not be tied to the specific messaging structure. The opposite is also true – the contract should not be tied to any specific communication protocols. Additionally, the implementation should be flexible enough to accommodate the potential for multiple interfaces and contracts. Ideally, however, I would recommend that a service expose only a single contract and interface and the ESB would take care of exposing additional endpoints and facades as necessary.

EA & SOA in Down Economy

Many articles, discussions, and presentations have been made on how the recent economic downturn affects the companies’ EA and SOA efforts. Some, like Joe McKendrick of ZDNet, believe that slow economy can spell boon for SOA but subprime SOA will suffer. Dave Linthicum published the results of his survey indicating the same. Beth Gold-Bernstein of ebizQ suggests that we bet the farm on Complex Event Processing. Ronald Schmelzer of ZapThink advocates that companies should continue to invest in SOA in a down economy. I would go a step further. EA and SOA investment is critical to the companies’ success – it will enable them to stay competitive, achieve significant efficiencies, and potentially even gain market share.

Pretty bold statement, some would say. I don’t think so. Let’s consider the facts.

When the times are tough, the first thing most companies do is slash budgets. IT budget gets reduced just like everyone else’s. The focus shifts from the strategic initiatives to simply keeping the lights on and completing projects as quickly as possible. Enterprise Architecture efforts are usually the first ones to be eliminated or significantly reduced. Point solutions become the norm resulting in duplication of software, hardware, and overall efforts. Smokestack applications rise up from the ashes of the Enterprise Architecture. Everyone becomes more concerned about keeping their jobs rather than doing the right thing for the company. IT managers shift to the aggressive empire building mode in order to protect their jobs and eliminate their own risks. (The old mentality of “I own more than you, therefore I am more important than you” is still alive and well, unfortunately. IT managers also think that if they can “own” and control every piece of their application, it will reduce their risk and allow them to deliver results faster.) Governance becomes unenforceable and largely forgotten.

Through this chaos, interesting trends emerge. While the initial IT budget is reduced through a series of staff reductions and some technology rationalization efforts, the costs begin to creep back up in subsequent years. When the economy finally turns around and the pressure to keep the budget low eases, the IT budget suddenly becomes larger than what it was prior to the cuts. Why? The explanation is simple. The empire building and unfettered decision making by IT management finally bears fruit. There are more software, licenses, hardware, and code in the data center, all of which requires more people to support. There is very little reuse and sharing because each group has built silo applications residing on their own unique platforms. Costs increase, efficiencies decrease, and it takes longer to deliver new capabilities especially if they require several applications to integrate with each other.

Enterprise Architecture and SOA can help reverse these trends and, in fact, keep the IT budgets low. Most companies have a number of redundant systems, applications, and capabilities that have grown through the type of uncontrolled behavior described above. EA, through an effective discovery and governance mechanisms, can eliminate these redundancies while maintaining the same capacity and level of operational responsiveness. Additionally, EA groups can influence or implement new architecture approaches to help consolidate resources and gain efficiencies. Examples of this could be virtualization, green technologies, cloud computing, etc. SOA, as a subset of EA, provides much the same benefits. Encapsulating key business functions as reusable services will help achieve more consistency, save money, and enable faster project delivery. An effective EA program can protect companies’ IT budgets from ballooning by establishing and enforcing standards, promoting reuse opportunities, and ensuring transparency across all IT systems.

The bottom line is that companies can not afford not to invest in EA and SOA. These programs will make organizations more efficient through the economic downturn and help achieve the necessary savings. On the long run, EA and SOA will keep the costs down while increasing business agility. Effective EA and SOA programs are a competitive advantage, not an overhead. They will easily pay for themselves and, what’s more important, enable organizations to avoid uncontrolled spending in the future. Enterprise Architecture and SOA is a must, not an option!

SOA Ecosystem

In the previous post, I’ve discussed the role of the ESB in the SOA ecosystem. However, I failed to adequately describe what an SOA ecosystem was and what were all the inter-relationships that must exist in order to make it truly effective.


If you refer to the diagram above, you will notice several major components that make up the SOA Ecosystem.

1. ESB
2. Registry/Repository (RegRep)
3. Security
4. Service Management
5. Shared Service Environments
6. Service Consumers
   

The SOA Ecosystem also encompasses all the related elements such as the application and service developers and testers as well as all the tools being used to accomplish these activities.

To truly comprehend how the SOA ecosystem operates, a clear understanding must be developed of what each component does and what its role is. Let’s start from the service consumer side.

• Service Consumers
  
  • Application Developers build applications that consume services. They use IDEs and other development tools to construct service requests and parse responses. Developers interact with the Registry/Repository to find the right services, obtain service metadata, and understand usage patterns.
  • Application Testers perform quality assurance tasks on the final product.
  • Application Servers that execute the application code interact directly with the SOA platform hosting the services.
• SOA Infrastructure
• Service Management Platform acts as an entry point into the SOA infrastructure. It retrieves policy information about the service being executed and applies it appropriately to the request. The policy is used to understand service security and authority, associated SLAs, constraints, contracts, etc. The Service Management Platform is often utilized to keep track of the service consumption and run-time metrics, which are then fed into the Registry/Repository.
• The role of the Enterprise Service Bus has already been discussed.
• Registry/Repository acts as a central repository for services and their metadata. Its uses and integrations are discussed at each related point.
• Security / Authentication Platform is a part of the larger IT infrastructure and is typically represented by either LDAP or Active Directory technology.
• Shared Service Environments are used to host reusable services. While different organizations choose to approach service hosting differently, if a common service hosting platform can be established, many issues related to service scalability, performance, reuse, security, implementation, standardization, etc. can be easily resolved. A centrally managed platform can be easily upgraded to accommodate additional – foreseen or unforeseen – volume. Standard capabilities can be provided to perform security, authentication, logging, monitoring, instrumentation, deployment, and many other tasks.
• Service Creation
• Service Architects and Developers create reusable services using the appropriate design and development tools. They also interact with the Registry/Repository to discover existing services and register new services and related metadata. The created services should ideally be deployed into a Shared Service Environment.
• Service Testers perform quality assurance tasks on the new or modified services. They use special SOA testing tools to create test cases and automate their execution. These tools interface with the Registry/Repository to retrieve metadata about the services and update related information once testing is complete.
  

Many vendors have slightly different view of how their products integrate and interact with the SOA ecosystem, what components exist, and where they are located. One can also include other elements into the SOA ecosystem such as the EA Repository, CMDB, IT Governance Tools, Monitoring Tools, etc. However, the general dynamics remain the same. The key point is that the SOA infrastructure interacts with the rest of the IT platforms and people in a certain way. In order for SOA to be truly successful, these interactions must become natural, automated, and symbiotic.

To ESB or Not to ESB?

That is the question. Many SOA thought leaders have addressed this topic. Most recently, David Linthicum wondered if ESBs were evil. He also talked about ESBs hurting SOA in his blog. Eric Roch has chimed in on the debate by providing some general guidelines for how to use the ESBs. Joe McKendrick has summarized the recent debate in his blog.

There seems to be a lot of pent up emotions in the industry when it comes to the ESBs. A lot of people tend to view ESBs as over-engineered, complicated, and unnecessary. Maybe, it is a backlash from the vendor hype or consistent experiences with a failed ESB implementation. Maybe, it is a reaction to the industry’s push towards choosing the tools first and fitting the solution into them later rather than vice versa. Maybe, it is a response to the architects calling the ESB implementation Enterprise SOA. I don’t know. What I do know is that ESBs have its place and when properly used are very useful.

SOA in not just about exposing services via a ubiquitous protocol and letting people use them. A successful SOA must have the following elements in place:

• Governance and Processes
• SOA Governance
• SOA Methodology
• SOA Reference Architecture (and possible Reference Implementations)
• SOA Maturity Model
• Service testing and versioning approaches
• SOA design patterns
• Technology
  
  • ESB
  • Service Management platform
  • SOA Governance platform
  • Registry / Repository (often is part of the SOA Governance platform)
  • SOA testing tools

The diagram below depicts the preferred SOA ecosystem and relationships between all of its different components and actors.



Note that the ESB plays a central role in the SOA ecosystem. It needs to be tightly integrated with the Registry/Repository tool that will store policy information and service metadata, service management platform that will ensure compliance to the predefined policies, and platforms exposing the physical service endpoints. ESBs are very useful when utilized to perform the following tasks:

• SLA and policy management
• Security reconciliation
• Protocol reconciliation
• Message transformation
• Orchestration (possibly, in conjunction with a BPM tool)
• Integration
• Logging and instrumentation
• Metrics collection

ESBs can provide all these capabilities in a central location and in a consistent fashion, so that every service does not have to implement them individually. Every service has to perform each of these tasks in some way, shape, or form. Without a central tool, implementations, tools, and approaches will vary. At the end of the day, you will end up with a hodge-podge of different things, which will be hard and costly to maintain.

When services are created, it is impossible to know who and how will consume them. In fact, it should be irrelevant. Services should not worry about all of the potential consumers, protocols, and contracts. It is the job of the ESB to reconcile all of them. Services should not have to include all of this complexity in their designs and implementations. They should only make sure that the business logic is properly implemented and a standard interface is provided. The ESB will take care of the rest.

Obviously, without proper planning and architectural oversight, ESBs can fail. Using an ESB to support only a handful of services is an overkill. Blindly choosing a product without performing adequate analysis always leads to problems. However, putting ESBs in the right place in the SOA ecosystem and utilizing them for the right purposes will only simplify the development, increase efficiency, clearly distribute the responsibilities between architectural components, and improve standardization. ESBs are not evil when used correctly.

Project-Oriented SOA

Read my article on the Project-Oriented SOA in the SOA Magazine.

http://www.soamag.com/I21/0808-2.asp

SOA Testing

Many articles, books, and conferences dealing with the SOA tend to ignore one of the most important topics in software development – testing. Often, testing is just an afterthought in many software development efforts. A lot has been said and written about this problem. However, it is important to note that testing in an SOA program plays a much more important and prominent role than in any other software development effort. Without a proper testing foundation, the whole SOA initiative will either fail or become too unwieldy or expensive to maintain.

One of the cornerstones of SOA is service reuse. Success of the SOA program is often measured through the amount of services created and reused. The biggest problem with testing in an SOA environment manifests itself when a service has several consumers and changes are made to it. How do you validate that this change does not impact service consumers? How do you determine the best way to deal with this change? Do you ask all of the service consumers to perform their own regression testing to make sure internal service changes do not impact them? Obviously, this is not an effective solution. With more and more services getting more and more reuse, you need a solution that minimizes the amount of manual testing you need to do but, at the same time, provides a clear understanding of how the service changes impact its consumers.

The services are composed of three primary elements – interface, contract, and implementation. Interface represents the protocol and communication mechanism between service and its consumers. Contract defines all of the interaction details such as message formats, SLAs, policies, etc. Service implementation is self-explanatory. A service can expose multiple interfaces and may potentially support multiple contracts. The key to understanding the impact on service consumers is to verify whether or not changes to any of the service elements invalidate how it behaves today. Changes that have no impact are called non-breaking; changes that modify the behavior are called breaking.

Each shared service needs to have an automated test created as part of its normal implementation. It will address two issues – provide an initial test bed for the service and automate all future testing needs. The test should inspect what changes are made to each service element. When service is modified in any way, the automated test suite should be executed to understand the impact of the changes. If all tests pass, the changes should be considered non-breaking and consumers should be unaffected. If any of the tests fail, this would indicate a breaking change and a new version of the service would need to be created. Alternatively, the impacted consumers can change but, ideally, breaking changes should trigger a new service version.

The biggest problem with SOA many companies face is lack of a consistent, comprehensive testing approach. Without automated regression testing for shared services, organizations are exposed to risk of high manual testing costs every time a service is changed or new consumer is added. Additionally, it can drive service versioning and serve as a formal validation mechanism that service consumers can trust. Automation can save millions of dollars in manual labor and ensure stability of the whole SOA platform.