Service orchestration and SOA

Similar to an organizational workflow, service orchestration is the coordination and arrangement of multiple services exposed as a single aggregate service. Developers utilize service orchestration to support the automation of business processes by loosely coupling services across different applications and enterprises and creating “second-generation,” composite applications. In other words, service orchestration is the combination of service interactions to create higher-level business services.

Service orchestration works through the exchange of messages in the domain layer of enterprise applications. Since individual services are not programmed to communicate with other services, messages must be exchanged according to a predetermined business logic and execution order so that the composite service or application can run as it is demanded by the end-user. This is usually accomplished through enterprise application integration (EAI), which enables data integration, and the use of a central messaging engine such as an enterprise service bus (ESB), which routes, transforms and enriches messages.

Service choreography is also related to service orchestration, as both are employed to create composite services and applications in service oriented architectures; however, it is still worth pointing out the differences. A service choreography model works without a central messaging engine or orchestrator while a service orchestration model relies on a central controller to couple services. In the former, the participating services each know the business logic and sequence and timing of message exchanges. In the latter, the participating services don’t know that they are being orchestrated as part of a higher-level service; only the central controller knows the business logic and messaging sequence.

To get a better sense of service orchestration, let’s take a look at the following example. A loan broker wants to make a loan request on behalf of a customer and uses an automated Loan Request Service. The broker accesses the Loan Request Service in the enterprise system to make the initial loan request, which is sent to an orchestrator (the central messaging engine) that then calls and invokes other services in the enterprise, partner systems and/or the cloud to process that request. The individual sub-services involved in the loan request include a service to obtain credit scores from a credit agency, a service to retrieve a list of lenders, a service to request quotes from a bank service, and a service to process quotes with the data from the other services. Together, the orchestrated services comprise the Loan Request Service, which then returns a list of quotes from potential lenders to the broker who made the original request.

As the above example illustrates, service orchestration is a fundamental aspect of successfully implementing SOA. In a truly service oriented architecture, new applications are created by new orchestrations of existing services - not by writing new code.

From the surface, service orchestration and SOA are relatively simple concepts. For enterprises faced with integration challenges, skyrocketing IT budgets and increasingly complex infrastructures, building new applications with granular and reusable software components is an understandably attractive approach to creating more agile and competitive systems and reducing time to market.

Service orchestration and SOA, however, can be difficult to achieve without the right set of tools. In its early days, CTOs of large companies eagerly adopted SOA and went about implementing it with a rip and replace model. Such an approach resulted in high financial costs as well as major time investments since it often required developers to orchestrate services programmatically (i.e. write new code), defeating the ultimate purpose of adopting SOA.

What was needed was a simpler and more flexible way to perform service orchestrations and implement SOA. The enterprise service bus (ESB) emerged as the go-to mechanism for service orchestration and SOA.

ESBs and other integration platforms make the service orchestration process much simpler and eliminate the need for custom coding. ESBs enable enterprise application integration (EAI) and act as orchestrators by allowing services to communicate with each other.

Mule as an ESB offers unparalleled interoperability and flexibility by making it possible to reuse service components of any type and exchange messages of any format both within the enterprise and without. In fact, the most recent version of Mule as an ESB has made it easier to perform service orchestration by introducing a new way to combine services with its Flow feature. Mule Flow allows you to pick and choose components to generate a linear flow of message processes and create a composite service in an intuitive way.

With the right platform, SOA delivers on its promises to align business processes with IT systems and reduce costs while remaining agile and robust enough to handle changes in customer demands and the integration of new applications. When the composition of new business services is made simple and intuitive, SOA can be successfully adopted - one service orchestration at a time.

Want to know more about the future of Mule as an ESB? Sign up today.