Pinlac, May M.

November 17, 2010

BSIT -4A

System Integration

1. SOA Advantages

Businesses in today’s competitive environment are constantly faced with the challenge of having
to provide more with fewer resources. Businesses are constantly under pressure to deliver goods
and services to the market at a faster, cheaper rate – and at higher quality than in previous times.
It is predicted that investments in Information Technology are going to drive businesses forward
– not merely in terms of gaining responsiveness and efficiencies, but additionally in the creation
of top line opportunities.

It is an ironic fact that the vast majority of corporate Information Technology companies only
allocate about three quarters of their annual budget to “keeping the lights on.” At the same time,
it has been established that the average utilization of a normal server is around fifteen to twenty
percent. While these figures may not be reflective of every single business, they do highlight the
fact that there is a lot of inefficiency in the way that Information Technology is carried out in
today’s business world. This inefficiency winds up consuming large chunks of a budget that
could be put to better use towards strategic initiatives.

What is behind this high rate of inefficiency? While there might not be one single cause, a lot of
it can be attributed to mergers, acquisitions, and functional silos within a business. All of these
factors tend to contribute to bloated Information Technology infrastructures, which then become
rife with overlapping and duplicate systems and applications. When faced with tight deadlines
and a business’s ongoing demands, Information Technology tends to just accept these
redundancies, only integrating systems where necessary as a means of maintaining their
consistency. While this approach may very well result in quick time to delivery, it also very
much inflates the recurring costs.

While a lot of Information Technology businesses might very well be content with this status
quo, executive management tends to view the alignment of Information Technology with
business as the primary concern related to the Information Technology field. With as little as
fifteen percent of the budget available for service needs, however, Information Technology does
not have a lot of room to maneuver. These problems are vast and apply to a variety of different
industries. What is needed is a major change in the way these issues are managed.

2. Past and Present of SOA

-SOA implementations rely on a mesh of software services. Services comprise

unassociated, loosely coupled units of functionality that have no calls to each other embedded in
them. Each service implements one action, such as filling out an online application for an
account, or viewing an online bank statement, or placing an online booking or airline ticket
order. Rather than services embedding calls to each other in their source code, they use defined
protocols that describe how services pass and parse messages using description metadata.

SOA developers associate individual SOA objects by using orchestration. In the process of

orchestration the developer associates software functionality (the services) in a non-hierarchical
arrangement using a software tool that contains a complete list of all available services, their
characteristics, and the means to build an application utilizing these sources.

Underlying and enabling all of this requires metadata in sufficient detail to describe not only the
characteristics of these services, but also the data that drives them.Programmers have made
extensive use of XML in SOA to structure data that they wrap in a nearly exhaustive description-
container. Analogously, the Web Services Description Language (WSDL) typically describes the
services themselves, while the SOAP protocol describes the communications protocols. Whether
these description languages are the best possible for the job, and whether they will
become/remain the favorites in the future, remain open questions. As of 2008 SOA depends on
data and services that are described by metadata that should meet the following two criteria:

1. The metadata should come in a form that software systems can use to configure
dynamically by discovery and incorporation of defined services, and also to maintain
coherence and integrity. For example, metadata could be used by other applications, like
a catalogue, to perform autodiscovery of services without modifying the functional
contract of a service.
2. The metadata should come in a form that system designers can understand and manage
with a reasonable expenditure of cost and effort.
SOA aims to allow users to string together fairly large chunks of functionality to form ad
hoc applications that are built almost entirely from existing software services. The larger the
chunks, the fewer the interface points required to implement any given set of functionality;
however, very large chunks of functionality may not prove sufficiently granular for easy reuse.
Each interface brings with it some amount of processing overhead, so there is a performance
consideration in choosing the granularity of services. The great promise of SOA suggests that
the marginal cost of creating the n-th application is low, as all of the software required already
exists to satisfy the requirements of other applications. Ideally, one requires only orchestration to
produce a new application.
For this to operate, no interactions must exist between the chunks specified or within the chunks
themselves. Instead, humans specify the interaction of services (all of them unassociated peers)
in a relatively ad hoc way with the intent driven by newly emergent requirements. Thus the need
for services as much larger units of functionality than traditional functions or classes, lest the
sheer complexity of thousands of such granular objects overwhelm the application designer.
Programmers develop the services themselves using traditional languages like Java, C, C+
+, C#, Visual Basic, COBOL, or PHP.

SOA services feature loose coupling, in contrast to the functions that a linker binds together to
form an executable, to a dynamically linked library or to an assembly. SOA services also run in
"safe" wrappers (such as Java or .NET) and in other programming languages that manage
memory allocation and reclamation, allow ad hoc and late binding, and provide some degree of
indeterminate data typing.

As of 2008, increasing numbers of third-party software companies offer software services for a
fee. In the future, SOA systems may[original research?] consist of such third-party services combined
with others created in-house. This has the potential to spread costs over many customers and
customer uses, and promotes standardization both in and across industries. In particular, the
travel industry now has a well-defined and documented set of both services and data, sufficient
to allow any reasonably competent software engineer to create travel-agency software using
entirely off-the-shelf software services.[3] Other industries, such as the finance industry, have also
started making significant progress in this direction.

SOA as an architecture relies on service-orientation as its fundamental design principle.[4] If a

service presents a simple interface that abstracts away its underlying complexity, users can
access independent services without knowledge of the service's platform implementation.

3. Fundamental concept of SOA

Architectures can operate independently of specific technologies.[8] Designers can implement

SOA using a wide range of technologies, including:

 SOAP, RPC
 REST
 DCOM
 CORBA
 Web Services
 DDS
 WCF (Microsoft's implementation of Webservice forms a part of WCF)
Implementations can use one or more of these protocols and, for example, might use a file-
system mechanism to communicate data conforming to a defined interface-specification between
processes conforming to the SOA concept. The key is independent services with defined
interfaces that can be called to perform their tasks in a standard way, without a service having
foreknowledge of the calling application, and without the application having or needing
knowledge of how the service actually performs its tasks.

Many implementers of SOA have begun to adopt an evolution of SOA concepts into a more
advanced architecture called SOA 2.0.

SOA enables the development of applications that are built by combining loosely coupled and
interoperable services.

These services inter-operate based on a formal definition (or contract, e. g., WSDL) that is
independent of the underlying platform and programming language. The interface definition
hides the implementation of the language-specific service. SOA-based systems can therefore
function independently of development technologies and platforms (such as Java, .NET, etc.).
Services written in C# running on .NET platforms and services written in Java running on Java
EE platforms, for example, can both be consumed by a common composite application (or
client). Applications running on either platform can also consume services running on the other
as web services that facilitate reuse. Managed environments can also wrap COBOL legacy
systems and present them as software services. This has extended the useful life of many core
legacy systems indefinitely, no matter what language they originally used.

SOA can support integration and consolidation activities within complex enterprise systems, but
SOA does not specify or provide a methodology or framework for documenting capabilities or
services.
High-level languages such as BPEL and specifications such as WS-CDL and WS-Coordination
extend the service concept by providing a method of defining and supporting orchestration of
fine-grained services into more coarse-grained business services, which architects can in turn
incorporate into workflows and business processes implemented in composite applications or
portals.

As of 2008 researchers have started investigating the use of Service Component Architecture
(SCA) to implement SOA.

Service-oriented modeling [1] is an SOA framework that identifies the various disciplines that
guide SOA practitioners to conceptualize, analyze, design, and architect their service-oriented
assets. The Service-oriented modeling framework (SOMF) offers a modeling language and a
work structure or "map" depicting the various components that contribute to a successful service-
oriented modeling approach. It illustrates the major elements that identify the “what to do”
aspects of a service development scheme. The model enables practitioners to craft a project plan
and to identify the milestones of a service-oriented initiative. SOMF also provides a common
modeling notation to address alignment between business and IT organizations.

SOMF addresses the following principles:

 business traceability
 architectural best-practices traceability
 technological traceability
 SOA value proposition
 software assets reuse
 SOA integration strategies
 technological abstraction and generalization
 architectural components abstraction

4. Introduction of Business Process

To ensure that Business Process Management (BPM) does not only remain a keyword, the
implementation needs to be prepared professionally and the necessary basis for the further setup
and extension needs to be defined.
The company and organisation wide implementation of BPM is among our core competences.
We actively support you with the definition and coordination of your BPM goals providing the
expert assistance you need.
Define procedure models to which your employees need to comply, optimise your processes
along the value added chain, and benefit from the continuous enhancement and consistent
improvement of the processes in your company.

This course will provide each participant with an introductory understanding of the role
of Business Process ExecutionLanguage (BPEL) and its role for modeling corporate workflows
and SOA processing. This course will focus on the usage of business process models, the role of
BPEL and BPEL4WS, vendor product support, integration of WSDL and other XML standards,
BPELWS partner concepts, stateful interactions, BPEL extensions, use of the a Modeler,
mapping elements in BPEL4WS, and the role of the Integration Server. All aspects of this class
will illustrate the architecture and design of an efficient and effective SOA environment.

5. Modeling SOA Building Blocks

Building-blocks accessible over standard Internet protocols independent of platforms and

programming languages. These services can represent either new applications or just wrappers
around existing legacy systems to make them network-enabled.

Each SOA building block can play one or both of two roles:

1. Service Provider - The service provider creates a web service and possibly publishes its
interface and access information to the service registry. Each provider must decide which
services to expose, how to make trade-offs between security and easy availability, how to
price the services, or (if no charges apply) how/whether to exploit them for other value.
The provider also has to decide what category the service should be listed in for a given
broker service and what sort of trading partner agreements are required to use the service.
It registers what services are available within it, and lists all the potential service
recipients. The implementer of the broker then decides the scope of the broker. Public
brokers are available through the Internet, while private brokers are only accessible to a
limited audience, for example, users of a company intranet. Furthermore, the amount of
the offered information has to be decided. Some brokers specialize in many listings.
Others offer high levels of trust in the listed services. Some cover a broad landscape of
services and others focus within an industry. Some brokers catalog other brokers.
Depending on the business model, brokers can attempt to maximize look-up requests,
number of listings or accuracy of the listings. The Universal Description Discovery and
Integration (UDDI) specification defines a way to publish and discover information about
Web services. Other service broker technologies include (for example) ebXML
(Electronic Business using eXtensible Markup Language) and those based on the
ISO/IEC 11179 Metadata Registry (MDR) standard.
2. Service consumer - The service consumer or web service client locates entries in the
broker registry using various find operations and then binds to the service provider in
order to invoke one of its web services. Whichever service the service-consumers need,
they have to take it into the brokers, then bind it with respective service and then use it.
They can access multiple services if the service provides multiple services.

6. Enterprise Service Bus

 In computing, an enterprise service bus (ESB) is a software architecture construct which
provides fundamental services for complex architectures via an event-driven and standards-based
messaging engine (the bus). Developers typically implement an ESB using technologies found in
a category of middleware infrastructure products, usually based on recognized standards.

An ESB generally provides an abstraction layer on top of an implementation of an enterprise

messaging system, which allows integration architects to exploit the value of messaging without
writing code. Unlike the more classical enterprise application integration (EAI) approach of a
monolithic stack in a hub and spoke architecture, an enterprise service bus builds on base
functions broken up into their constituent parts, with distributed deployment where needed,
working in harmony as necessary[1].

An ESB does not itself implement a service-oriented architecture (SOA) but provides the
features with which one may implement such. An ESB should[citation needed] build on the basis of
standards and provide flexibility, supporting many transport media capable of implementing both
traditional SOA patterns as well as SOA 2.0-enriched business architecture. ESBs attempt to
isolate the coupling between the service called and the transport medium. Most ESB providers
incorporate SOA principles and allow for independent message formats.

7. Business Process Management and SOA

One of the major benefits of SOA is its ability to align IT with business processes. Business
processes are important because they define the way business activities are performed. Business
processes change as the company evolves and improves its operations. They also change in order
to make the company more competitive.
Today IT is an essential part of business operations. Companies are simply unable to do business
without IT support. But this places a high level responsibility on IT. An important part of this
responsibility is IT's ability to react on changes in a quick and efficient manner. Ideally, IT must
instantly respond to business process changes.

In most cases, however, IT is not flexible enough to quickly adapt application architecture to the
changes in business processes. Software developers require time to modify application behavior.
In the meantime the company is stuck with old processes. In a highly competitive marketplace
such delays are dangerous, and the threat is exacerbated by a reliance on traditional software
development to make quick changes within an increasingly complex IT architecture.

The major problem with traditional approaches to software development is the huge semantic
gap between IT and the process models. SOA reduces the semantic gap by introducing a
development model that aligns the IT development cycle with the business process lifecycle.

To understand this better, let's look at the four phases of the SOA lifecycle:

 Process modeling is the phase in which process analysts work with process owners to analyze
the business process and define the process model. They define the activity flow, information
flow, roles, and business documents. They also define business policies and constraints, business
rules, and performance measures. Performance measures are often called key performance
indicators (KPI). Examples of KPIs include activity turn-around time, activity cost, etc. Usually
BPMN (Business Process Modeling Notation) is used in this phase.

 Process implementation is the phase in which the developers work with process analysts to
implement the business process with the objective to provide end-to-end support for the
process. In the SOA approach the process implementation phase includes process
implementation with the BPEL (Business Process Execution Language) and process
decomposition to the services, implementation or reuse of services, and integration.

 Process execution and control is the actual execution phase, in which the process participants
execute various activities of the process. In the end-to-end support for business processes it is
very important that IT drives the process and directs process participants to execute activities -
and not vice-versa, where the actual process drivers are employees. In SOA, processes execute
on a process server. Process control is an important part of this phase, during which process
supervisors or process managers control whether the process is executing optimally. If delays
occur, exceptions arise, resources are unavailable, or other problems develop, process
supervisors or managers can take corrective actions.

 Process monitoring and optimization is the phase in which process owners monitor key
performance indicators (KPI) of the process using BAM (Business Activity Monitoring). Process
analysts, process owners, process supervisors, and key users examine the process and analyze
the KPIs while taking into account changing business conditions. They examine business issues
and make optimizations to the business process.
Figure 1 show how a process enters this cycle and goes through the various stages.

Once optimizations have been identified and selected, the process returns to the modeling phase
to apply the optimizations. Then the process is re-implemented and the whole lifecycle is
repeated. This is referred to as an iterative-incremental lifecycle, because the process is improved
in each stage.

8. Layer Achitecture

An abstract view of SOA depicts it as a partially layered architecture of composite services that
align with business processes. depicts a representation of this type of architecture.

The relationship between services and components is that enterprise-scale components (large-
grained enterprise or business line components) realize the services and are responsible for
providing their functionality and maintaining their quality of service. Business process flows can
be supported by a choreography of these exposed services into composite applications. An
integration architecture supports the routing, mediation, and translation of these services,
components, and flows using an Enterprise Service Bus (ESB). The deployed services must be
monitored and managed for quality of service and adherence to non-functional requirements.
Figure 3: The layers of a SOA

For each of these layers, you must make design and architectural decisions. Therefore, to help
document your SOA, you might want to create a document consisting of sections that correspond
to each of the layers.

1. Scope <what area of the enterprise is this architecture for?>

2. Operational systems layer
1. Packaged applications
2. Custom applications
3. Architectural decisions
3. Enterprise components layer
1. Functional areas supported by this enterprise components
2. <What business domains, goals and processes are supported by this enterprise
components>
3. Decisions regarding governance
1. <Criteria by which something is elected as an enterprise components
within this client organization>
4. Architectural decisions
4. Services layer
1. Categorized portfolio of services
2. Architectural decisions
5. Business process and composition layer
1. Business processes to be represented as choreographies
2. Architectural decisions
1. <Which processes need to be soft-wired into choreographies and which
will be built into applications?>
6. Access or presentation layer
1. <Document implications of Web services and SOA on this layer; if any. For
example, use of portlets that invoke Web services at the user interface level and
the implications on the functioning of that layer>
7. Integration layer
 1. <Include considerations of an ESB>
2. <How are we going to ensure the service-level agreements (SLAs) and quality of
service (QoS) required by clients of the services provided?>
3. Security issues and decisions
4. Performance issues and decisions
5. Technology and standards limitations and decisions
6. Monitoring and management of services
1. Description and decisions

Now, let's describe each layer in greater detail and discuss the composition of each of these
layers.

Layer 1: Operational systems layer. This consists of existing custom built applications,
otherwise called legacy systems, including existing CRM and ERP packaged applications, and
older object-oriented system implementations, as well as business intelligence applications. The
composite layered architecture of an SOA can leverage existing systems and integrate them
using service-oriented integration techniques.

Layer 2: Enterprise components layer. This is the layer of enterprise components that are
responsible for realizing functionality and maintaining the QoS of the exposed services. These
special components are a managed, governed set of enterprise assets that are funded at the
enterprise or the business unit level. As enterprise-scale assets, they are responsible for ensuring
conformance to SLAs through the application of architectural best practices. This layer typically
uses container-based technologies such as application servers to implement the components,
workload management, high-availability, and load balancing.

Layer 3: Services layer. The services the business chooses to fund and expose reside in this
layer. They can be discovered or be statically bound and then invoked, or possibly,
choreographed into a composite service. This service exposure layer also provides for the
mechanism to take enterprise scale components, business unit specific components, and in some
cases, project-specific components, and externalizes a subset of their interfaces in the form of
service descriptions. Thus, the enterprise components provide service realization at runtime
using the functionality provided by their interfaces. The interfaces get exported out as service
descriptions in this layer, where they are exposed for use. They can exist in isolation or as a
composite service.

Lever 4: Business process composition or choreography layer. Compositions and

choreographies of services exposed in Layer 3 are defined in this layer. Services are bundled into
a flow through orchestration or choreography, and thus act together as a single application. These
applications support specific use cases and business processes. Here, visual flow composition
tools, such as IBM® WebSphere® Business Integration Modeler or Websphere Application
Developer Integration Edition, can be used for the design of application flow.

Layer 5: Access or presentation layer. Although this layer is usually out of scope for
discussions around a SOA, it is gradually becoming more relevant. I depict it here because there
is an increasing convergence of standards, such as Web Services for Remote Portlets Version 2.0
and other technologies, that seek to leverage Web services at the application interface or
presentation level. You can think of it as a future layer that you need to take into account for
future solutions. It is also important to note that SOA decouples the user interface from the
components, and that you ultimately need to provide an end-to-end solution from an access
channel to a service or composition of services.

Lever 6: Integration (ESB). This layer enables the integration of services through the
introduction of a reliable set of capabilities, such as intelligent routing, protocol mediation, and
other transformation mechanisms, often described as the ESB (see Resources). Web Services
Description Language (WSDL) specifies a binding, which implies a location where the service is
provided. On the other hand, an ESB provides a location independent mechanism for integration.

Lever 7: QoS. This layer provides the capabilities required to monitor, manage, and maintain
QoS such as security, performance, and availability. This is a background process through sense-
and-respond mechanisms and tools that monitor the health of SOA applications, including the all
important standards implementations of WS-Management and other relevant protocols and
standards that implement quality of service for a SOA.