What is Service Oriented Architecture (SOA)?
There is no single unique and
easy way to define or explain SOA. Given a room full of C-level
executives, IT Managers, IT-Architects, and developers with each asked
to give a one sentence explanation of what SOA is, for sure, each answer
will be different. What is the fundamental message behind SOA? What is
it trying to achieve and what does it provides the adopter with? This
will help the reader to be able to define or explain it correctly. Let's
list some of most common facts he/she may have heard about SOA:
It's a style for building loosely coupled and distributed applications
It's all about service providers providing services to service consumers that conform to contracts
It provides a programming model based on standards defined by various standard bodies including OASIS, WS-*, and so on
Service Oriented Architecture (SOA) is a set of architectural styles, patterns, principles, procedures, and criteria for building solutions and applications.
Such applications exhibit the following characteristics:
Loosely coupled from operating systems, programming languages, and protocols
Expose coarse grained Business Services that can be mapped to business capabilities
Business Services are Modular, Encapsulated, and Reusable
Can be Composed, Orchestrated, or Choreographed
Services expose standardized interfaces
Services are described though contracts and hence discoverable
Leverages a standards-compliant middleware
The process of adopting an SOA is a journey and possibly an ever-evolving, ever-learning, never ending one. With SOA, you progress and mature over time to reach a state where you can truly achieve the benefits, as promised.
Process, Business Services, and Components-the core constructs
Business Processes
represent the flow of activities required to complete a business
process, which, in turn, help achieve a business objective. They are
orchestrations, choreography, or compositions of Business Services
targeted to achieve business goals.
Business Service, to
be more precise, represents a discrete business function that makes
meaningful sense to an organization. A Business Service can be composed
of one of the many fine-grained functions or atomic services, and by the
true definition of SOA, encapsulation, it can dynamically behave
depending on how it is invoked. Services form the building blocks of SOA
and should be reusable, decoupled, exposed in a standardized fashion,
and derived from disparate IT resources.
Components realize and
provide services from one or more applications and these components are
wrapped into the Business Services. Components help realize not only
the functionality of the services they expose, but also ensure that
their Quality of Service (QoS) is good, as guaranteed by the service
provider. The following figure depicts how all of the above are
interrelated and interconnected at a very high level.
Achieving success through BPM enabled by SOA
A fact of reality in many
organizations today is that they have many applications which are
disparate in terms of technology, programming languages based on which
they were written, capabilities exposed through interfaces, services, or
APIs, and so on. To create a purchase order in an order entry system,
we will need information about the customer from customer information
management systems, product information from product catalog, and so on
and so forth. Hence there is a constant struggle to make all the
applications integrated.
IT is under constant
pressure to address these requirements for managing layer upon layer of
legacy systems that may or may not interoperate with any degree of
simplicity. This is where integration comes in and helps connect
applications together with the right communications , data semantics and
server infrastructure as well as the right business process
capabilities to give IT and enterprise leaders the ability to create
composite applications that meet new flexible and dynamic business
needs.
Getting the integration right
is one of the key aspects of getting SOA right, and it enables the
integration of the disparate applications. Integration is only one half
of the struggle; there are several techniques and modes in which you can
integrate applications. They include but are not limited to:
Presentation-based integration that provides interaction and collaboration capabilities
Process-driven integration that helps streamline business processes
Information-centric integration for unified access to information from heterogeneous data sources
Bare bones connectivity-based integration
A Business Process Management
(BPM) approach enabled by SOA is key to achieving operating
efficiencies and gaining a competitive advantage for any organization.
Organizations need a BPM enabled by SOA framework, which will allow them
to constantly evolve their collaborative process automation and process
improvement approaches. So what is this BPM enabled by SOA framework
and what will it comprise?
Business Process Management (BPM)
You may have been reading a
lot about Business Process Management. What is it? BPM is a discipline
that focuses on process modeling, design, automation, management, and
continuous improvement. It is not a technology or a product. It covers
the full range of application-to-application, inter-application,
workflow, and person-to-person process management, including process
modeling, design, automation, monitoring, management, and continuous
improvement. The core and basic components of BPM include (but are not
limited to):
Modeling and simulation
Policies and Rules
Collaboration through human task processing
Content-centric processing
Process execution including choreography and orchestration
Business Activity Monitoring (BAM)
Support for common Business Objects (BOs)
Intuitive process definition tool
Customizable work portal
Historical process analysis
Wide range of integration capabilities and adapters
Process Tracking and Notification
Process Performance Analysis
System Scalability and Process Performance
Provision for parallel human task approvals
Capability to work with and modify in-flight processes
Building blocks of BPM enabled by SOA framework
Businesses very well
understand that their core (and differentiating) business processes
will have to be automated (post integration) and be able to externalize
these from end applications. Process-driven integration is about
bringing people, processes, information, and systems together using the
Business Process management (BPM) approach enabled by an SOA approach.
This approach requires a solid technology platform and of course an
over-arching methodology that will offer you prescriptive guidance on
how to deliver solutions. So what are these core building blocks? They
include:
Business Process Modeling
Business Process Execution
Business Policies and Rules
Enterprise Service Bus
Business Process Monitoring
Information Model (the semantic model)
Now let's look briefly at each
of these core building blocks/capabilities that are needed for achieving
success in a business process-driven integration provided, as shown in
the following figure:
Business Process Modeling
This is the starting
point where you discover and document the various other business
process(s) (using a modeling notation such as Business Process Modeling Notation BPMN)
that might exist on paper or even in the minds of some subject matter
experts and document it with business modeling. Also, once the processes
are modeled, you will have the ability to run model simulations and try
out various 'what-if' scenarios to forecast what would happen if you
altered the process. Based on these simulations, you arrive at an
optimal process design. The process modeling exercise also helps to
identify the SOA services that will have to be specified, realized,
and also in many cases, reused.
Business Process Execution (including Choreography)
Once the business processes have been modeled, they will have defined in an executable format (such as Business Process Execution Language
(BPEL)) and deployed on a standard-based process execution platform
that supports both the business process execution environment and the
packaging of business tasks as services. The assembly, sequencing,
orchestration, and choreography of existing services and new services
results in the realization of a deployable process model. This assembly
should be based on industry standards such as Service Component Architecture
(SCA). The execution platform must also support human interaction for
both participants in the business process and administrators of the
business process. The runtime should also provide a variety of
administrative capabilities required to configure the environment for
the applications that are installed.
Enterprise Service Bus
Enterprise Service Bus
(ESB) provides the underlying connectivity and backbone infrastructure
for SOA to connect applications. An ESB is essentially an architecture
pattern that provides capabilities including connectivity,
communications, message queuing, message routing, message
transformation, reliable messaging, protocol transformation and binding,
event handling, fault handling, message level security, and so on. It
enables loose coupling between service consumers and service providers,
and thus enhances the ability to rapidly change and introduce new
Business Services into the environment. An ESB typically would leverage a
service registry and repository to provide information about service
endpoints.
Business Policies and Rules
Policies and rules can make
the business processes highly flexible and responsive. A business policy
represents a key piece of domain knowledge, externalized from a
business process and is applied when a particular request context is
met. An example could be, all purchase orders that include order items
such as Oxygen Canisters $1000
has to be shipped overnight, and so on. Metadata elements such as
"order item" and "order amount" are deemed as the business domain
vocabulary and values of which can change (you can add "Defibrillator"
along to the critical items list), which will have to be externalized
from the business process. are deemed critical orders, order amount worth over
A business rule is a
statement that defines or constrains some aspect of the business. They
are typically atomic and cannot be broken down further. An example would
be, say, in a loan origination business process, at each step of the
process, business analysts identify rules that must be met by the loan
staff and underlying systems. In traditional banking systems, these
rules reside within the loan origination system itself, so changing the
rules means modifying the application. When the rules are abstracted
from the loan origination systems, they reside in a business rules
engine. As a result, bank management can identify those activities that
change rapidly, such as decisions relating to FICO® scores, and then,
instead of changing the process and its underlying application, they
change only the decision point within the business process, which in
turn resides in a business rules engine (external to the process
itself). This capability adds agility to the process by reducing the
time, costs, and resources necessary to respond to changing conditions.
Business Process Monitoring
While the business
processes are deployed and are executing, data must be captured that
provides information about the processes. This data can be analyzed to
determine if the business processes are performing as expected. Both
business-related information and IT-related information can be captured
for monitoring. You should also be able to visually define dashboards
based on Key Performance Indicators
(KPI), which are based on the monitor model deployed for the business
process, providing a visual display of the business process status.
Information Model
For a process-driven
integration approach coupled with SOA to succeed, a common and
enterprise level information model is required, which becomes the basis
for the messages exchanged between processes and services, and also
serves as the glossary for the business policies and rules. When dealing
with applications that have disparate data and information models, use
of this common information model shields the business processes away
from the gory details of each and every individual system. The ESB
provides capabilities to transform from this Canonical Data Model to the
target system's format. The Canonical data model minimizes dependencies
between integrated applications that use different data formats.
Typically, one could leverage industry standards such as Tele Management
Forum's Shared Information/Data Model (SID) and so on to define the
information models.
A mind map is a
diagram used to represent words, ideas, tasks, or other items linked to
and arranged around a central keyword or idea. Mind maps are used to
generate, visualize, structure, and classify ideas, and as an aid in
study, organization, problem solving, decision making, and writing.
A mind map, as shown in the following figure, sums up all the previous concepts.
