SOA and BPM, a more consistent and manageable
approach
Alison H. R. Silva
EAI Project - TCS Brazil
SCN Área 5 Bl. A # 50 T. Sul sl. 501
55 61 3426 3611
alison.silva@br-tcs.com
ABSTRACT
A service-oriented architecture (SOA) is a way of building an
enterprise IT infrastructure out of loosely coupled components
known as "services" that perform discrete functions. Composite
applications are a key element of an SOA environment. These
applications are created by invoking and orchestrating multiple
services, events and models in such a way that they collectively
perform a higher-order business function. This functionality
increases business agility by enabling IT departments to reuse
components that have already been tested in production and have
known scalability and quality-of-service characteristics. Such
reuse can help reduce time to market and lower IT development
costs.
This decentralized application environment provides a great deal
of flexibility for business units and IT departments, but it also
creates difficulty in managing the consistency of business
decisions delivered through various applications. Business
Process Management (BPM) [11] is the key to providing a
comprehensive path and implementation plan from the top of the
organization to the bottom. Modeling offers a reliable, objective
mechanism to better understand enterprise-wide operations,
identify crucial flaws in current practices and determine how to
make necessary amendments and improvements. Modeling
enables the clear visualization of business process across the
enterprise, aligning both IT and business users, with the end goals
to identify, analyze and evaluate how the company is doing
business today and to rethink and improve how it might be done
better tomorrow. In conjunction with an enterprise service bus,
BPM and SOA also make enterprise application integration (EAI)
more straightforward, reliable and manageable.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice. To copy otherwise, or republish, to post on
servers or to redistribute to lists, requires prior specific permission
and/or a fee.
TACTiCS – TCS Technical Architects’ Conference’06
Alipio Getulio Krohn Jr.
EAI Project - TCS Brazil
SCN Área 5 Bl. A # 50 T. Sul sl. 501
55 61 3426 3611
alipio.junior@br-tcs.com
1. Introduction
The combination of business process management and service-
oriented architecture will benefit IT professionals and business
users. A service-oriented architecture cannot be useful without a
business process management infrastructure [13]. Each business
process is modeled as a set of individual processing tasks. These
tasks are typically implemented as services within the enterprise.
BPM helps in creating process models, process automation, in the
form of invoking services.
SOA exposes services, and BPM, which demands process flow
completion, consumes services. SOA opens a vast inventory of
services for BPM to "bond together" into a comprehensive flow.
Regardless of whether this is composite or not, this flow addresses
critical business processes.
The convergence of BPM, SOA, Web services, and XML
promises to significantly improve corporate agility, reduce time-
to-market for new products and services, reduce costs, and
improve operational efficiency of IT systems.
2. SOA and Web Services
Services Oriented Architecture (SOA) is an application
development paradigm which goal is to create functional modules
called Services. These Services attend to a specific business
necessity with a loose coupling and allowing code reuse.
The CDBI Forum [1], responsible for document and discuss the
best practices involving SOA, describes SOA in this way: "it is a
software architecture that defines the interfaces topology,
implementation and calling. SOA is a relationship between
Services Providers and Consumers, both software modules big
enough to represent a complete business function".
Service is a component that implements a specific business
function for its clients, which receives a request and answer to it,
abstracting the processing rules and details having loose coupling
in respect with its platforms.
In the Service Oriented Architecture, there are the Provider and
Consumer roles. The provider is responsible to offer the Service,
or to guarantee that the Service is available for who wants to use
it. The Consumer is the Service user that needs the service to
accomplish a specific goal.
A known example of SOA implementation is the use of Web
Services, which are distributed services that process SOAP [2]
(Simple Object Access Protocol) messages coded in XML [2]
(eXtensible Markup Language), sent through HTTP [2] (Hyper-
Text Transfer Protocol) and described through WSDL [2] (Web
Services Description Language).
Web Services give interoperability between software components
that can be in different companies and can reside in different
infrastructures. SOAP is based upon XML and uses the HTTP as
communication protocol using the port 80 (the standard port for
HTTP requests). This guarantees the interoperability between
different platforms.
The WSDL (also based upon XML and uses HTTP) gives a
description for the Services, which allow the integration of
Services, development and component management tools. In a
Web Service WSDL description are defined: a URL to access de
service, the web service name, the description of each method and
the way to request the service using SOAP, through GET or
POST HTTP requests.
3. ESB -Enterprise Service Bus
In an IT corporative environment, where there are many defined
and available services for use, the ESB arise. This concept was
originally created by the Gartner Group a few years ago that
defines a service abstraction layer using a solution based on
message exchange which provides the integration architects with
the necessary confidence to use the corporative services. The ESB
acts as a message share layer to connect applications and other
services through an enterprise computational structure being
considered as a Middleware for SOA support.
4. BPM - Business Process Management
The Business Process Management [11] originated from the
necessity of enterprise directors, involving CEO's, CIO's and
Managers, in view and support the enterprise business processes
accessible in a clear and easy way for everybody who needs to
acquire these information.
The business process of an enterprise are rarely visible and
accessible to every department of the company, for example, the
marketing knows deeply its internal processes, although does note
make any idea how the sales department works, and probably has
little knowledge about the billing process.
Along with this universe of processes spread through the internal
enterprise departments, the Business Process Management arose
derived from the old Workflow Management trying to provide the
integration, management and visibility of the business processes
through graphical and technological resources.
The Business Process Management uses the Business Process
Modeling as a mean to ease the business and systems analyst and
designers work, because it permits the use of the BPMN (Business
Process Modeling Notation) from the design of activity flows till
the services innovation, exception treatment, human interaction,
etc.
5. SOA and BPM, a more consistent and
manageable approach
Many companies have worked continuously in activities of
process improvement. The efforts in the process improvement
began with Frederick Winslow Taylor, author of the book
Principles of Scientific Management [3], published in 1911, same
period that Henry Ford released the continuous production line
that caused a revolution in the industrial production process. The
first computational system designed to attend a business need was
an application used to process the Pay Roll, developed in the
General Electric in 1954. Since then, many companies have
developed systems that automate its business processes.
Nowadays, we are in a process of system architecture
improvement, which look for flexible components, software
components based architectures, large use of the HTTP protocol
together with a variety of applications based in XML, all of them
tracking the business requirements and resolving some
"corporative chaos" scenery.
In these sceneries, SOA can be used in many ways, since that well
defined services exists and these services really attend business
requirements.
SOA can be associated with an integration middleware and
internet protocols where each application individually invokes
services to attend their internal requirement.
Broadly used, SOA can be used just as another business model
component, where the process managers define the process flow
through BPMN and reference the existent services (sending and
receiving information) in the ESB.
The design of a business process, in the majority of the cases, is
defined in a top-down fashion, where the managers define the
work flows and business rules in a macro vision, then passes
through a refinement processes until it is attended by the IT area
with software development and hardware infra-structure
acquisition to support the solution. One of the BPM goals is to
shorten the distance between the diverse "business areas" and the
IT, allowing managers define and maintain the business process
using tools capable of provide them the whole picture of the
processes and services already existent, such that a better reuse
and control of this process can be done.
Through these tools, depending on the design level of detail, it is
possible to generate a BPEL (Business Process Execution
Language) code, which technically define, through XML, what
services will be used by a business process, interfaces and further
technical requirements such that a business process can be
controlled by a business process control specialist system such as
IBM WBI [4], Microsoft BizTalk [8], TIBCO Business Integrator
[9], Vitria BusinessWare [10], among others.
The next picture describes the life cycle of a business process,
from its conception to its installation in the runtime environment.

Figure 1 - Graphical representation of an elaboration flow for
a business process. [12]
The services organization, its interaction with each other, the pre
and post conditions, rules and flows inside a process aiming to
attend a business function is called Orchestration.
Through the orchestration, managers and/or system architects can
define and/or maintain business processes by including services,
automated processes, human interaction, scheduled activities, etc.
The combination of BPM and SOA represents a new paradigm to
the business automation. This paradigm will delay for a few years
to totally materialize, but represents our better hope regarding
flexibility and agility.
Under a technology point of view, SOA, or Service Oriented
Architecture, allows a loose coupling and independency of the
various structure and functional software elements that an
enterprise will acquire or build for support its business, allowing
flexibility and agility in terms of modification in the existing
elements and the change between them.
BPM, in its turn, allows the optimization in the use of the services
provided by SOA, managing the relationship between them in a
business process point of view. With BPM agility and flexibility
get better, because the BPM allows the fast change of the
automated process, as well as the automation of new ones,
contributing for the enterprise reaches its strategic goals.
BPM and SOA combined are a very interesting option that makes
the technology works for the business and makes the automated
processes follow in an effective way the agility that the business
demand currently.
6. From theory to practice: an example of
BPM with SOA
In order to demonstrate the use of a BPM using BPMN calling
SOA services, we are going to show a Retailer Process.
A retailer process does not operate in isolation, but rather
collaborates with consumer processes to receive orders and
warehouse processes to have orders filled. The choreography can
be described as follows:
• A consumer sends a purchase order to a retailer.
• The retailer sends to the consumer an acknowledgement
that it received the purchase order.
• The retailer forwards the purchase order to a warehouse,
passing to it the electronic address of the consumer. The
warehouse will use this address to notify the consumer
when the order is complete.
• If the warehouse accepts the order, it sends a positive
acknowledgement to the retailer. If the warehouse
rejects the order, it sends a negative acknowledgement
to the retailer. In each case, the retailer forwards to the
consumer the result from the warehouse.
• Assuming it accepted the order, when the warehouse
has finished its processing and is ready to ship the
goods, it sends a notification directly to the consumer.
Using the WS-CDL (Web Services Choreography Description
Language) as an example we can see that the WS-CDL can
encode these steps formally in an XML language. The first two
steps in the English description above are represented in WS-CDL
by the code in picture 2 [12].
Figure 2 - WS-CDL consumer-retailer interaction
This code describes an interaction with two exchanges: in the first
exchange (lines 5-8) the consumer sends (action="request") a
purchase order (informationType="tns:PO") to the retailer; in the
second (lines 9-12), the retailer responds (action="response") with
a purchase order acknowledgment
(informationType="tns:POAck").
The first step in building the retailer process is to generate a
BPMN diagram that satisfies the retailer's required role in the
choreography. The manual approach is to look at the
choreography and draw a process that fits the role; Figure 3 shows
the BPMN diagram representing the retailer as a participant in the
choreography.
Figure 3 - Retailer process to satisfy choreography (BPMN
representation) [12]
The logic of the process is straightforward. The process starts
when it receives a purchase order (PO) message from the
consumer ("PO From Consumer"). It then successively sends an
acknowledgement of receipt to the consumer ("Send Receipt Ack
to Consumer") and forwards the PO to the warehouse ("Send PO
to Warehouse"), before waiting until it receives a response from
the warehouse ("Wait Warehouse Response"). When the response
arrives, the retailer process forwards it to the consumer ("Send
Warehouse Response to Consumer"), and the process completes.
The notation is clear and intuitive: the boxes perform "activities,"
the circles with enclosed letter symbols wait for "events," the
empty circle marks the endpoint of the process.
Figure 4 shows the process with the addition of private steps (i.e.,
steps not required by the choreography but driven by internal
requirements). These steps are italicized: "Write PO to DB"
persists the purchase order to an internal retailer database when it
arrives from the consumer; "Update PO Status in DB" updates the
database record with the status of the warehouse response (i.e.,
accept or reject); "Sales Followup" is a manual task, assigned to a
sales representative to help the consumer resubmit the order in Figure 6 – Retailer BPEL code
case it was rejected by the warehouse. (The diamonds in the figure
are called XOR gateways. When combined, they form a
conditional code structure that works like an if statement.
Gateways are discussed at length in Essential Business Process
Modeling.)

Figure 4 - Complete retailer process (BPMN) [12]

As it turns out, the mapping to BPEL is straightforward: the

"events" of the BPMN process (e.g., "Wait Warehouse
Response") are BPEL "receive" activities (or activities that wait
for events to occur); the "activities" (e.g., "Send PO to
Warehouse") are BPEL "invoke" activities (or activities that call
services); the conditional structure enclosing "Sales Followup" is
a BPEL "switch" activity; and the entire flow is a "sequence"
activity. The BPEL code, each of whose eight steps derived from
BPMN is indicated by a comment (e.g., line 12 indicates step 1),
is provided in Figures 5, 6 and 7 [12].
Figure 5 – Retailer BPEL code
Figure 7 – Retailer BPEL code
In the BPEL code, "partner links" (marked by the partnerLink
XML attribute, such as partnerLink="consumer" in line 13) are
used to identify the parties with which the process converses. Four
partner links are used:
• consumer, representing the consumer process, is used in
steps 1 (line 12), 2 (line 21), and 6 (line 44).
• warehouse, representing the warehouse process, is used
in steps 4 (line 30) and 5 (line 34).
• retailerDB, a web service interface to the retailer's
internal database, is used in steps 3 (line 26) and 7 (line
49).
• taskMsg, a web service interface to human workflow, is
used in step 8 (line 53).
All three types of process interactions are represented: consumer
and warehouse are external system interactions, retailerDB an
internal system interaction, and taskMgr human interaction. All
interactions are web-service-based. Each partner has a WSDL that
describes its interface. Interestingly, the retailer process itself is a
web service; its "receive" activities are web service operations,
which are documented in a WSDL that the process published to
its partners.
The next figure represents the interaction between business
process, services (business and integration) and operational
resources.
Figure 8 – Relationship between BPM Layer, ESB Layer and
EAI Layer.
7. Benefits of using BPM and SOA
• The business process layer separation permits its
modification without impact in the existent services.
• Events and triggers can be used to start or automate any
business process.
• Process containers permit that large business processes
are broken in smaller and more manageable ones.
• Business process design tools allow that the process can
be viewed and maintained by any enterprise area, and
they can speed up the BPEL code generation for
installing the business process in a computer
environment.
• The OMG (Object Management Group) [5], in conjunct
with the WfMC (Workflow Management Coalition) [6]
has worked a lot toward the BPM documentation and
standardization, what makes the BPM trustable, secure
and in tune with the process of market expansion.
8. Case TCS and Brasil Telecom
Brasil Telecom [7] is a Brazilian company specialized in
telecommunication solutions that attend in an integrated way all
the market demands, with a convergent solution, its mobile and
fixed operations, traffic of data and voice, data center, free,
broadband and dial internet.
Brasil Telecom has more than 10.8 million of installed fixed lines
and the second broadband internet access base in Latin America.
It also has more than 2 million mobile phone clients in less than 2
years operation.
TCS Brazil, with its EAI project, has worked in partnership with
Brasil Telecom to establish the use of BPMN in its IT areas, as
represented in figure 9 below.
Figure 9 – BPMN Implementation Process
These areas goals are to use BPMN to define and document its
business process and its relationships with each others services
and processes, such as Provisioning, Billing, CRM, etc. The
documentation of the processes and services, as well as its
implementation and architecture, is happening with the help of
TCS with its Component Management, Architectural and
Development teams.
Before the deployment of BPMN every business areas defined its
processes through workflows and textual documents. As of the
deployment of BPMN as the way to document and organize the
business process, all the IT business areas is being trained to
define its process and services using the new paradigm and
standardized tools.
With the BPMN and SOA deployment, we expect to shorten the
projects life cycle as well as reduce the number of defects found
in the projects, since the services will be strongly reused. This
way, the project cost and rework will reduce and the process
visibility and manageability will increase significantly, enabling
the change and adaptation of the business process in a time to
market.
9. Conclusions
BPM and SOA provide a perfect combination for enterprise
computing. BPM provides the higherlevel abstraction for defining
businesses processes, as well as other important capabilities of
monitoring and managing those processes. Services provide the
functions that support those processes. SOA provides the
capabilities for services to be combined and to support and create
an agile, flexible enterprise. BPM without SOA is useful for
building applications, but difficult to extend to the enterprise.
SOA without BPM is useful for creating reusable and consistent
services, but lacks the ability to turn those services into an agile,
competitive enterprise.
SOA provides the ideal level of abstraction for defining reusable
business functionality, completely encapsulating underlying
applications and technology platforms from the BPM system.
SOA generates modular business components that encapsulate
business logic and generally accepted interfaces. The modules can
easily execute the steps in a process flow.
SOA is the crucial foundation for BPM, supporting rapid
assembly and orchestration of process services into larger, end-to-
end processes.
10. REFERENCES
[1] CBDI Forum - http://www.cbdiforum.com
[2] W3C - http://www.w3.org
[3] Taylor, Frederick Winslow. The Principles of Scientific
Management. Dover Publications, 1911.
[4] IBM – Websphere Business Integration -
www.ibm.com/software/integration/wbisf/
[5] OMG – Object Management Group – http://www.omg.org
[6] WfMC – Workflow Management Coalition –
http://www.wfmc.org
[7] Brasil Telecom -
http://www.brasiltelecom.com.br/home/sobreabrasiltelecom.
html
[8] Microsoft BizTalk Server - http://www.microsoft.com/biztalk
[9] TIBCO Software – http://www.tibco.com
[10] Vitria Technologies – http://www.vitria.com
[11] Havey, Michael. Essential Business Process Modeling.
O’Reilly, Aug-2005.
[12] Havey, Michael. What is Business Process Modeling.
O’Reilly OnJava, July 2005.
[13] Behara, Gopala Krishna. BPM and SOA: A Strategic
Alliance. BPM Trends, May 2006.
[14] Erl, Thomas. Service-Oriented Architecture: A Field Guide
to Integrating XML and Web Services. Prentice Hall, 2004.