> Archive > Issue XV: February 2008 > Integration with Process-Centric Service Composition
Matjaz B. Juric

Matjaz B. Juric


Matjaz B. Juric holds a Ph.D. in Computer and Information Science. He is an Associate Professor at the University of Maribor and the Director of the Science Park project.

He has authored and co-authored several publications, including "SOA Approach to Integration", "Business Process Execution Language for Web Services" (English and French editions), "BPEL Cookbook: Best Practices for SOA-Based Integration and Composite Applications Development", "Professional J2EE EAI", "Professional EJB", "J2EE Design Patterns Applied", and ".NET Serialization Handbook".

He has contributed chapters to "More Java Gems" (Cambridge University Press) and "Technology Supporting Business Solutions" (Nova Science Publishers), and has also been published in various journals and magazines, including "SOA World Journal", "Web Services Journal", "Java Developer's Journal", "Java Report", "Java World", "EAI Journal",, OTN, and ACM.

Mr. Matjaz has been involved in several large-scale projects and has been a consultant for several large companies on the SOA projects. In cooperation with the IBM Java Technology Centre, he worked on performance analysis and optimization of RMI-IIOP, an integral part of the Java platform. He is also a member of the BPEL Advisory Board.


rss  subscribe to this author


Integration with Process-Centric Service Composition

Published: February 9, 2008 • SOA Magazine Issue XV

Abstract: Integration is a concept that changes with the adoption of a service-oriented architecture. Whereas in silo-based environments, programs had to be explicitly connected using technologies and strategies to overcome incompatibilities, with SOA, connectivity is a characteristic you build into each service. This article, comprised of excerpts from the book "SOA Approach to Integration" [REF-1], explores how integration can be approached in support of SOA via the use of process-centric design techniques.

Introduction: Historical Integration Challenges

The ability to instantly access vital information that may be stored in a variety of different locations will influence the ultimate level of success a company is able to achieve. For any business the presence of an effective information infrastructure that avoids the need for employees to perform numerous manual tasks (like filling in paper forms, and other bureaucracy) is crucial.

Employees should not have to contend with the inefficiencies or "irritations" of switching between different applications, reentering the same data more than once, or waiting for extended periods for data to be processed. A well-integrated enterprise should offer end-to-end support for business processes with instant access to information, no matter which part of the applications are used. Similar requirements hold true for organizations that want to be successful in e-business or that want to improve their position in the virtual world.

Since the early 90s, companies have come to realize the importance of integration at different speeds. Some are still fully involved in integration projects while others are aware that integration is important but do not yet have justifiable results because their projects are either on-going or simply have not been successful.

Further still, some companies are only now realizing the importance of integration. For those that fall into this category, it could, quite frankly, be too late. Such companies may be looking for ways to achieve integration fast, without spending too much money and without assigning too many resources. Cutting corners and attempting to implement only the most needed parts of an integration architecture in the shortest possible time will inevitably result in partial solutions achieving a subset of their potential.

The fact is that integration is an important strategic priority for almost all organizations today, mainly because new and innovative business solutions demand integration of different business units, enterprise data, applications, and business systems. Integrated information systems improve the competitive advantage with unified and efficient access to information. Integrated applications make it much easier to get at relevant, coordinated information from a variety of sources. In effect, the total becomes more than the sum of its parts.

However, as this article will highlight, traditional integration methods have had their share of problems. A key revelation and shift in mindset brought on by modern SOA platforms is that the concept of "natural integration" becomes native to service development. Services are built to be compatible and then assembled into compositions that leverage this compatibility into inherent connectivity. Of course, services still need to "integrate" with various legacy environments in order to exploit their resources. However, on the service layer, it is a matter of interoperability more that integration.

Process-Centric SOA

The main objective of IT has traditionally been to provide support for business operations. Initially IT focused on the support of business functions, such as accounting and human resources. This narrow perspective resulted in so-called "stove-pipe" applications that were isolated into their own silos. With the advent of service-oriented computing, the focus has been shifted towards end-to-end support for business processes.

Organizations have started to realize that:

  • It is important to automate processes. This holds true for business as well as technical processes.
  • It is important to optimize business process execution by measuring the efficiency of existing processes and improving upon them. In an automated provisioning process for example it would be possible to measure the time for each process activity and identify those activities that require the longest time to fulfill. This way, a company can focus on optimizing its most critical activities and improving in overall performance.

Integration technology and techniques have evolved and matured over the past decade and we are now at a point where SOA platforms and practices have taken the concept of integration to a whole new level.

A process-centric approach to SOA enables companies to streamline business processes and discharge their employees from routine activities. This allows companies to become more agile and responsive to market opportunities and customer needs.

There are four major categories of forces that influence business process automation through the use of information technologies

  • business aspects (such as agility, competition, new opportunities, customer demands and contact)
  • organizational aspects (such as the need for optimizations, improvements of efficiency, and cost reductions)
  • increased complexity (due to integration demands and new standards)
  • the introduction of new technologies (such as those that build upon SOA as part of the emerging Web 2.0 framework)

Although companies have taken care of their processes in the past (via BPM or otherwise) there has been a considerable gap between business processes designed on paper and their runtime execution. This is primarily due to the following shortcomings:

  • Business processes are often only partially supported by applications. Sometimes several different applications have to support the activities of a single process. This requires that users switch between different applications to complete a task.
  • Several activities of a process have to still be carried out manually because there is simply no software to support them.
  • Business process workflows are not always accurately documented because of the involvement of business clients without the necessary business analysis skills.
  • It is difficult to achieve a clear picture about how business processes work, how long their activities take, and where the bottlenecks are.

These issues represent important risk factors that have slowed progress. The resulting semantic gap between business processes and IT has led to other consequences:

  • The complexity of applications has been growing considerably, which impacts the ability to make changes and modifications reliably.
  • As changes have been difficult to make, it usually takes too long to implement new functionality or adapt existing functions.
  • Because of the increased complexity, a lot of effort has to be put into maintenance, which results in high operating costs.

SOA addresses these problems. It enables agile change through the constant opportunity to assemble and reassemble services. It allows the application of these changes in small, manageable steps, which results in faster, safer adoption of the application logic required to fulfil business needs. This is why SOA introduces a layered architecture that can consist of the following logical layers:

  • presentation layer
  • process layer
  • business services layer
  • technical services layer
  • existing information systems layer

In addition, a typical SOA initiative will introduce the need for infrastructure resources, such as these:

  • enterprise service bus
  • registry and repository
  • rules engine
  • business activity monitoring
  • security

Figure 1 shows how these common infrastructure extensions can relate to the previously listed logical layers.

Figure 1: Common logical layers (left) can tie into a centralized implementation of an ESB and other infrastructure extensions (right).

Service Compositions

In SOA, the composition of services is a fundamental concept with which we provide support for business processes in a flexible and relatively simple way. Services are composed in a particular order and introduce a set of rules that determine how a business process executes. Business processes are essentially comprised of service composition logic that carries out service invocations, transformations of data, dependencies, correlations, and any necessary fault, event, and compensation handlers.

Service compositions enable us to modify business processes quickly and therefore provide support to changed requirements faster and with less effort. Only when we fully exploit the potential of service compositions can we realize all of the benefits of service-oriented computing.

To be successful with service composition, we first have to understand what a business service is. We have already seen that the notion of a service composition is integral to designing service-oriented architectures. Let's take a closer look at certain fundamental characteristics we need to establish:

  • loose coupling
  • easier changes and reduced maintenance costs
  • faster development and improved flexibility
  • resilience to change in the future

Business services in an enterprise provide those functions that fulfill requests, whether internal or external. Business services are a reaction to client requests and always perform an action that leads to a business result.

To be usable in business processes, a business service should expose a contract capable of providing business results to service consumers. In other words, the operations or capabilities exposed by a service contract must make business sense, not technical sense.

Web services can be business services as long as they are designed according to service-orientation rules. Business services that exist as Web services can be composed as a set of standalone programs or via more formal composition frameworks, like orchestration and choreography:

  • Orchestration follows the notion of centrally located process logic which takes control over the involved business services and coordinates the execution of different operations on the services involved in the process. The orchestration (also referred to as a "executable business process") is centralized with explicit definitions of operations and the order of invocation of the composed business services.
  • Choreography on the other hand does not rely on a central coordinator. Rather, each business service involved in the composition knows exactly when to execute its operations and whom to interact with. Choreography is a collaborative effort focused on the exchange of messages in business processes. All participants of the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges.

Identifying Services

Services can be identified and defined differently depending the SOA delivery strategy being employed. In a top-down approach, services are identified as activities of business processes. This strategy is process-centric and requires good knowledge of the process itself. Therefore it helps if the business process has been modeled in advance using various notations, such as Event Process Chain (EPC) or Business Process Modeling Notation (BPMN), and using different methodologies, such as ARIS, the Architecture of Integrated Information Systems. ARIS, in fact, is an enterprise modelling method that is widely used for analyzing processes and taking a holistic view of process design, management, workflow, and application processes.

Services identified using the top-down approach are usually composite business services and have to be further decomposed into discrete business services via a separate service modeling process. Discrete business services then often rely on separately modeled technology or utility services, which are either exposed from existing systems or developed from scratch.

The bottom-up approach looks at the existing applications and tries to figure out what functionality is available and how this functionality could be exposed for application access. This type of functionality originates from existing systems and is therefore usually technology-centric as opposed to business-centric. Usually several utility services have to be combined in support of business services.

In the real world we generally need to use a combination of both approaches. As shown in Figure 2, service identification represents the first stage in the overall service delivery lifecycle. How this candidate service participates in a compositions is also defined during the initial identification and analysis stages, prior to the actual service and composition logic being designed and delivered.

Figure 2: Service compositions tie into all of the typical stages of the service delivery lifecycle because composition is a natural part of a service's existence.

Figure 3 shows a sample business process that, once subjected to service modeling, led to the identification of the following three entity-centric business services:

  • Resource Service (handles resource data collection and resource data processing)
  • Rating Service (handles record rating including pricing and discounting)
  • Billing Service (handles calculation of the total sum and bill creating and delivery)

Figure 3: A simple process that, subsequent to service modeling efforts, resulted in the identification of three entity-centric business services that will be composed together by an orchestrated service to automate the process.

Subsequent to identification, these three business services will need to be composed by a parent process-centric service that may be implemented as part of an orchestration or a choreography.

After this type of modeling exercise, each service is then designed and connected to other services in an implemented form as per the implementation and deployment phases in Figure 1. Then, of course, the service composition as a whole is subject to the standard governance stages as it essentially represents a service-oriented solution.

BPEL for Service Composition

When building services as Web services, the most common form of orchestrated service is one that encapsulates composition logic expressed in the Web Services Business Process Execution Language (WS-BPEL).

BPEL is an XML-based language based on WSDL, XML Schema, and XPath. From a historical perspective BPEL can be seen as a convergence of IBM WSFL (Web Services Flow Language) and Microsoft XLANG.

Listed below are the most important features that WS-BPEL provides:

  • describes business process logic through the composition of services
  • can compose larger business processes out of smaller processes and services
  • can handle synchronous and asynchronous (often long-running) service invocations and manage call-backs that occur at later times
  • can invoke Web service operations sequentially or in parallel
  • selectively compensates completed activities in case of failures
  • is capable of maintaining multiple, long-running transactional activities (which are also interruptible)
  • resumes interrupted or failed activities to minimize work that may need to be redone
  • routes incoming messages to the appropriate processes and activities
  • correlates requests within and across business processes
  • schedules activities based on the execution time and defines their order of execution
  • executes activities in parallel and defines how parallel flows merge based on synchronization conditions
  • structures business processes into several scopes
  • handles message-related and time-related events

WS-BPEL also offers constructs, such as loops, branches, variables, and assignments that are very similar to the those used in traditional programming languages. These essentially allow us to define business processes in an algorithmic manner. Overall, however, WS-BPEL is far less complex than traditional programming languages.


Approaching SOA with a process-centric design strategy is key to fulfilling integration through the composition of services. In this article we explored common design considerations associated with this approach and then focused on the use of WS-BPEL as a means of expressing and executing composition logic. However, it is important to understand that successful integration with SOA requires more than a knowledge of technology. On the most fundamental level, you must appreciate the change in mindset that comes with service-orientation and how we are always striving to establish a native level of interoperability within services so that integration, as a separate task, becomes less of a burden and more of a natural method by which we effectively combine services into a variety of compositions.


[REF-1] "SOA Approach to Integration" by Matjaz B. Juric, PackT 2008,