Building SOA composite business services, Part 1: Develop SOA composite applications to enable business services

Integrate existing SOA services by composing them in different ways. Part of our focus will be on how this is done within the framework of a Service Component Architecture.


Javier Garcia (, Software Engineer, IBM

Javier Garcia is an advisory software engineer with over 20 years of development experience. He is currently working in the SWG Strategy and Technology department with a focus on SOA and composite applications.

German Goldszmidt (, Senior Technical Staff Member, IBM

Dr. German Goldszmidt is a Senior Technical Staff Member working in IBM Software Group, with focus on architecture of an integrated platform to deliver, customize, and deploy SOA composite applications to enable business services.

03 October 2006

Also available in Chinese Russian


Composite applications provide the ability to integrate existing Service-Oriented-Architecture (SOA) services and/or create new services that can be composed in different ways. The key to composite applications are the creation of reusable software assets as the implementation of the SOA Services using SCA. We developed a demonstration composite application in the banking domain using WebSphere Process Server, WebSphere Portal, WebSphere Service Registry and Repository, WebSphere Enterprise Bus, WebSphere Portlet Factory and WebSphere Application Server along with their corresponding development tools. The scenarios selected provide examples of the realization of different features that are required to develop efficient composite applications. We first examine the benefits and challenges of composite applications using the sample scenarios that we developed for illustration. Finally we will examine the technical features in the IBM products and how they can be used in order to develop composite applications.

In this article we first define composite applications, points of variability, roles, use cases, the runtime environment and a list of business intents that need to be realized in order to create composite applications that enable business services.

The following articles in this series will explore in more detail multiple relevant issues, including design patterns for multi-tenancy, applying selectors and business rules to achieve dynamicity, publishing services, self-care patterns and assets, configurable User Interfaces using dynamic profiles, automated build and deployment, using CEI to develop measurable applications, and similar topics.

What are composite applications?

A SOA Composite application is defined as "a set of dynamic service components solving a specific business problem or task. Composite applications often provide a set of services, which in turn may be part of other composite applications." A Business Service is a service that a business unit elects to expose at its boundary, interfacing with its clients, partners, or other business units. A business service implements a meaningful business process or task. A Composite Application is comprised of one or more components or component aggregations, each of which exposes a service interface. A composite application enables a business service.

Figure 1. Composite application for retail banking loan origination
Composite application for retail banking loan origination

As we see in Figure 1, a composite application choreographs a set of configurable services. In this example the rectangles, for example, Retail Lending, correspond to business components that expose business services such as validate. The red lines indicate the invocation sequence that is followed by a specific use case of the Composite Application. Following the red lines the loan application is received, a credit score is generated, the loan is then validated, analyzed and an offer is made. After the loan has been approved it must be initiated, configured, settled and recorded. Finally correspondence is initiated in order to communicate with the customer.

In this context Service Component Architecture (SCA) is the service-oriented component model. It provides an abstraction that covers stateless session EJBs, Web services, Plain Old Java Objects (POJOs), WS-Business Process Execution Language (WS-BPEL) processes, database access, Enterprise Information System (EIS) access, and other service implementations as can be seen in Figure 2, below. SCA separates business logic from infrastructure logic so that application programmers can focus on the business problem.

Figure 2. SCA implementation types
SCA implementation types

Points of variability

Points-of-variability are locations where decisions are implemented which are likely to change and thus should be externalized. Service components with built-in points-of-variability allow users to configure these services to meet different requirements. Configurable applications can be achieved by working in extensibility mechanisms into the UI, the interfaces of the service components, the service components themselves and the data models.

It is important to contrast configurability to customization. Configurability gives us the ability to adapt a component to different requirements without changing the code base (writing code). Configurability is built into the services (the switches, dials and levers) and can be invoked by the user of the application. In contrast, customization requires the development of additional code (in a programming language) to extend and change a software component in order to support a specific a"custom" behavior.

We can group these points of variability into three major categories, user interface, business logic and persistence.

User interface (UI)

Points of variability in the user interface allow a user to change the look and feel of the UI along with its semantic content (data fields) through configuration. Examples of configuring points of variability in a user interface are:

  1. Rebranding the Web site with customer-specific logos and banners. For example, let's say there are two banks, Bank A and Bank B. Each of these banks have their own logos or brand and would like their respective Web sites to reflect this.
  2. Changing the labels and text that appear in the user interface so that they are appropriate and familiar to the employees and customers that use it. For example, one bank could use the term Preferred Account as a label for an entry field while another could use the term Advantage Account.
  3. Changing the entry fields that are exposed to the user. One bank could allow the user to enter an alternate cell phone number while another bank does not.
  4. Changing the endpoints of the SOA Services that are invoked by the user. It could be that the credit check service used varies depending on the country of residence therefore externalizing the end point allows it to be configured.

Business process

Since multiple Composite Application solutions can use the same business process it is possible (in fact probable) that each application implementation may desire slight variations of the same business process. Therefore, it is important that business processes have points-of-variability giving the user of the composite application the ability to configure the business process to their specific requirements. For example, consider a bank that decides to give away a gift choice, such as a toaster, to everyone that opens a new account during a certain time period. This bank would require that the open account business process have an activity to dispatch a gift to all new account holders. However, for other banks this activity should be disabled.

To realize this requirement composite applications implementations need the ability to disable optional activities in a business process. WebSphere Process Server provides a mechanism for externalizing points-of-variability to allow users a way of configuring business processes without customizing them. A simple way of doing this within a BPEL business process is retrieving a business rule before performing an activity which returns a Boolean indicating if the activity is enabled or disabled. In the example presented in the previous paragraph we would have a gift rule that could be turned on or off by an administrator and would eventually end up enabling or disabling the corresponding "send gift" activity in the Business Process.

Data layer

Points of variability must also exist in the data layer. Since composite applications may have different views of the data, there needs to be a way of providing data variability at the database schema layer. For example, one bank could capture the nationality of its customers while another bank does not. Since we are using the same component implementation for both banks we are accessing the same underlying data base schema. Therefore we need to provide variability in the data layer so we can store the nationality of the customer for one bank but not require it for the other.

One possible way of providing this capability is to store data attributes in an XML file that resides in a database. Holding data attributes in XML could allow a very flexible schema in which attributes can be removed or added without changing the logical database schema. This is possible since the database stores this XML document in one database attribute (a feature of DB2® V9), thus the logical data base schema would not change.

The following sections describe some of the main roles of the Jivaro banking composite application, and some of the major use cases.


Let's briefly define some of the roles that are relevant to our sample banking application.

This is the organization, usually a commercial firm, which provides hosted, off site banking services to multiple banks. The personnel of the provider includes administration staff, the Banking Provider Administrators, which can be further divided into roles such as Operations Administrator and Service Administrator. The former handles the day-to-day operations while the latter configures the services that are used by each Bank. A master administrator can perform all duties. Figure 3 describes these relationships in an UML diagram.

Figure 3. Banking provider administrator roles
Banking provider administrator roles

Banking administrators

The banking administrators are employees of the individual bank, for example, Bank A, which uses services hosted by the provider. Their task is to administer the instance of the system for Bank A. This role can be further divided following the same taxonomy as the provider administrator role.

Banking end-users

Banking end-users are divided into three major categories: the employees of a bank, business partners, and actual retail customers. This is shown in Figure 4. The inclusion of business partners allows a more complex environment in which some of the banking services are actually outsourced to another service provider. In the banking domain it could be that processing mortgages is outsourced to a mortgage provider. Therefore the mortgage provider would be a business partner to the bank and require corresponding actors.

Figure 4. Banking end users
Banking end users

Use cases

In this section, we briefly cover some of the use cases in our sample composite application. These use cases are grouped in four major functional areas based on the main actor that initiates the use cases, as shown in Figure 5.

Figure 5. Functional areas of use-case model
Functional areas of use-case model

Banking service provider administration

The first set of use cases are initiated by the banking provider. This actor can create banks along with bank administrators. Administrators have the ability to configure the provided services, create internal users, set up security, and so on. The provider administrator can also view metering data or data that tracks the amount of usage by a customer in order to monitor the solution. These use cases are shown in Figure 6.

Figure 6. Bank service provider administration use cases
Bank service provider administration use cases

Bank administration use cases

Bank administrators can configure business processes, such as the Loan Process, add other administrators, add users (in bulk) and create the individual brand of a bank. This is shown in Figure 7. The bank brand supplies a unique look-and-feel to the bank's Web site.

Figure 7. Bank administration use cases
Bank administration use cases

Bank employee use cases

The use cases in this group are performed by the actual employees of the bank. There are different bank employees, including platform sales and tellers. Employees of the bank can manage customers and their corresponding accounts. They can create loan mortgage products and categories of users for subsequent UI configuration. These use cases are shown in Figure 8.

Figure 8. Bank employee use cases
Bank employee use cases

Bank customer service use cases

The use cases in this group are initiated by the actual customers of the bank via the Bank’s Web site. These, of course, are transparently routed to the Provider's hosted site. As shown in Figure 9, customers can view their accounts and transactions, transfer funds, apply for a loan and view their loan application status.

Figure 9. Bank customer services use cases
Bank customer services use cases

Topology diagrams

After describing the highlights of the use cases, we now turn our attention to the runtime environment. In our sample banking scenarios we distribute our application over three nodes. The number of nodes used (in this case 3) is dependent on many quality-of-service issues such as scalability. The topology diagrams that follow show where we have decided to run our middleware products.

Figure 10. Topology diagram
Topology diagram

Presentation services

Presentation services are executed in the presentation Services Node that is tasked with running the user interface. In this case WebSphere Portal provides an out-of-the-box feature rich runtime environment for web applications. Figure 11 identifies the Middleware products needed to run WebSphere Portal while Figure 12 is a view of some of the Portlets in our sample banking application.

Figure 11. Presentation services
Presentation services

Figure 12. WebSphere Portal user interface for sample banking application
WebSphere Portal user interface for sample banking application

Business services

Business services run on the business service node. This is where our business logic resides. Since our invocation mechanism is based on Service Component Architecture (SCA) we use WebSphere Process Server as can be seen in Figure 13.

Figure 13. Business services contain the business logic of the application
Business services contain the business logic of the application

Enterprise services

Enterprise services run on the enterprise services node that contains the products that provide the data, security and other infrastructure services such as a service registry. The Tivoli Directory server provides a Lightweight Directory Access Protocol (LDAP) infrastructure that is the foundation for identity management. The WebSphere Service Registry and Repository allows services to be registered by providers and selected by consumers.

Figure 14. Enterprise services
Enterprise services

Features of composite applications to enable business services

Composite applications that enable business services need to reflect certain desirable business intents. The implementation of these business intents enable composite applications to be easily developed, deployed and reused. A brief summary of some examples of such intents follow and will be the basis of future articles that will delve into the technical features that make the realization of these intents possible.

Multi-tenancy: Multi-tenancy is the ability of a composite application to service multiple clients from a shared, common hosting environment.

Dynamicity: Dynamicity can be defined as the ability to react to events that occur during execution (i.e., at run time) rather than at a predetermined or fixed time. For example, in WebSphere Process Server dynamicity is especially supported by selectors and business rules.

Published: Composite applications can be users and providers of services that are published in a directory. For example, the WebSphere Service Registry and Repository can help manage and govern the registration of such services.

Self-serviceable: The configuration and control of capabilities enabled by composite application such as business rules, users and roles, and configurable options, should be delegated to the consumer of the service. For example, an administrator should be able to change the rules that govern loan origination.

Secure: Authenticated consumers should be permitted only to invoke services and access information for which they are authorized. Information must be encrypted and privacy maintained in accordance with established policies, according to the role of the consumer. For example in a loan origination scenario some loans are automatically approved and rejected while others are dispatched to a loan officer for manual processing. In a secure environment only a loan officer would have the authority to manually approve or reject a loan.

Configurability: Behavior can be tailored to meet client specific needs through items such as business policies, business rules, business service level agreements and configuration parameters. For example, the WebSphere Portlet Factory Dynamic Profiles feature can provide a degree of dynamic configurability in the user interface.

Automation: Automation is the replacement of predominantly manual task with a scripted, "hands off" computerized process. For example, an automated deployment mechanism provides a controlled repeatable deployment process.

Measurable: Composite business services must quantify their business value. For example, a business service can use the Common Event Infrastructure (CEI) to generate events that can later be analyzed to provide business level measurements.

Reusable: Services and components must be created with the intent of being reused in different solutions. SOA design techniques provide a way of structuring solutions and components so that they can be reused in different contexts.

Flexibility: Composite business services must accommodate change as the underlying business and technical requirements evolve. For example, using the WebSphere Enterprise Service Bus a single SCA application can support synchronous and asynchronous communication across SOAP/HTTP and SOAP/JMS protocols without any changes to the application code.


The authors would like to thank Paul Bate for this input on the features of a composite application.



Get products and technologies

  • Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks

Zone=SOA and web services
ArticleTitle=Building SOA composite business services, Part 1: Develop SOA composite applications to enable business services