Thursday, January 29, 2009

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.

7 comments:

RNB Research said...

I came to your blog just when I was surfing on this topic. I am happy that I found your blog and information I wanted.

Habin said...

Thanks for the nice article.I would like to know more about service orchestration and how BPEL is useful in achieving it.

-Habin

otr214426 said...

Problem: HP Printer not connecting to my laptop.

I had an issue while connecting my 2 year old HP printer to my brother's laptop that I had borrowed for starting my own business. I used a quick google search to fix the problem but that did not help me.
I then decided to get professional help to solve my problem. After having received many quotations from various companies, i decided to go ahead with Online Tech Repair (www.onlinetechrepairs.com).
Reasons I chose them over the others:
1) They were extremely friendly and patient with me during my initial discussions and responded promptly to my request.
2) Their prices were extremely reasonable.
3) They were ready and willing to walk me through the entire process step by step and were on call with me till i got it fixed.
How did they do it
1) They first asked me to state my problem clearly and asked me a few questions. This was done to detect any physical connectivity issues with the printer.
2) After having answered this, they confirmed that the printer and the laptop were functioning correctly.
3) They then, asked me if they could access my laptop remotely to troubleshoot the problem and fix it. I agreed.
4) One of the tech support executives accessed my laptop and started troubleshooting.
5) I sat back and watched as the tech support executive was navigating my laptop to spot the issue. The issue was fixed.
6) I was told that it was due to an older version of the driver that had been installed.

My Experience
I loved the entire friendly conversation that took place with them. They understood my needs clearly and acted upon the solution immediately. Being a technical noob, i sometimes find it difficult to communicate with tech support teams. It was a very different experience with the guys at Online Tech Repairs. You can check out their website www.onlinetechrepairs.com or call them on 1-914-613-3786.
Would definitely recommend this service to anyone who needs help fixing their computers.
Thanks a ton guys. Great Job....!!

fmad said...

Hi,

I´m a bit confused on your saying that at the end an orchestration and composition of services will be the same.
The way I see it is that service composition is the aggregation of services "without" any intelligence behind, think on it as just to put lego pieces together without having any kind of rule decision between one piece and the other, e.g., a atomic service to get basic customer data and another service to get additional customer data come together to bring a new service to get all the customer data.
On service Orchestration it is the same the add of lego pieces but with some rules/intelligence behind it, e.g., for providing a business function to get all customer with a specific type of home loan product and that payments missing it will be provided by an aggregation of a unit service to get the customer list with that loan type and after for each call the service to get the payment info, and if some payments will be missing the aggregate service will add the customer to the list.
Although these are simple examples I think that will be enough to state the difference between what I consider a service composition (data management) and a orchestrated one (data management + a "bit" of process/decision).
Do you think this makes sense to have this scope separation or should all be considered service composition/orchestration?
Thanks

Darren Demers said...

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. cotton bed sheets online wholesale , bridal bed sheet set with price

Anusha said...

Advanced kitchen software plays an important role for modular kitchen outcome...

Modular Kitchen Chennai
Office Interiors in Chennai
Home Interiors in Chennai

Anusha said...

Are you worried about your dream home design, then venus space designs is there for you... Our Premium Interior Designers in chennai can handle any type of interior design projects.