SOA concepts
This topic contains the following sections:
Overview
The primary goal of Service-Oriented Architecture (SOA) is to align the business
world with the world of information technology (IT) in a way that makes both more
effective. SOA is about the business results that can be achieved from having
better alignment between the business and IT.
SOA starts from the premise that all businesses have a business design. A
business design describes how that business works - the processes that it
performs; the organizational structure of the people and finances within that
business; the business' near-term and long-term goals and objectives; the
economic and market influences that affect how that business achieves its goals;
the rules and policies that condition how the business operates.
Most businesses have a written form of their high level business plan - the high
level definition that states the business' purpose. Few businesses, however,
have a written form of their business design. Many of those who have
documented their business design have trouble keeping their design up to date
with what they actually practice. Business processes evolve as businesses
respond to shifts in the marketplace, regulations, or product innovations; this
evolution usually happens without reflecting those changes in the formal design
of the business.
However, even if the business design has not been documented, or even if what
is documented is now obsolete, there is nonetheless a business design in effect.
A fundamental premise of SOA is that if the business design can be transcribed
and maintained there is a potential for leveraging that captured design
information.
Even if the business design is not used to communicate between the business
and IT organizations, it can nonetheless be a valuable tool to help businesses
understand what they are doing and how. Beyond that, however, the business
design becomes an essential tool in communicating requirements between the
business and the IT organization. The business can identify those elements of
the design that should be automated and what within that design should be
performed by people, creating a blueprint of the information systems that are
created to support that automation.
By deriving the information system design from the business design you can
more easily drive changes into the information system at the rate and pace of
change in the business design. Furthermore, the information system can be used
as a catalyst for change in the business design. It is from this correspondence
that SOA delivers on the promise of more flexible businesses through more
flexible IT.
What is a "service" in service-oriented architecture?
We refer to the practice of deriving an information system design from a business
design as service-oriented architecture. The business process and the tasks
from which it is composed can be collectively thought of roughly as services.
Thus, the business design is essentially a composition of services and the
policies and conditions that must be applied to their use which form the
information system design.
However, there remains the question of "what is a service?" Is it a function within
an application? Are all application functions services? Does SOA include system
services? Coming up with a single, mathematically precise definition that applies
universally to all situations can be hugely complicated. In practice, such precision
is not necessary to achieving value and success from SOA.
An underlying premise in the application of SOA to information technology is the
principle of loose coupling - that is, avoiding or at least encapsulating temporal,
technological and organizational constraints in the information system design.
This same principle applies also to the definition of service - the rules used to
define services in one context may not be applicable in another. What is
important is that whatever definition we arrive at, it should originate from the
primary concerns and constraints of that context. As a generalization, a service is
a repeatable task within a business process. So, if you can identify your
business processes, and within that, the set of tasks that you perform within the
process, then you can claim that the tasks are services and the business process
is a composition of services.
However, note that certain tasks can be decomposed into business processes in
their own right. The order-entry process includes, amongst other things, a task to
confirm availability of the items being ordered. The confirm-availability task is
itself a business process that includes, for example, the tasks of checking the
on-hand inventory, verifying the supply pipeline, and possibly creating a
background request and determining its availability. Thus, business processes
are themselves services; there is a principle of recursive decomposition implied
in the term service. If taken far enough we could easily claim that everything is a
service. This, obviously, is not useful - at some point treating everything as a
service would yield an incredibly inefficient over-generalization of the problem
space. You should exercise this principle of recursive decomposition only to the
extent that you legitimately need flexibility within your business design.
From this definition of service, service-orientation is a way of integrating your
business as a set of linked services. If you can define the services in each of your
vertical and horizontal lines-of-business, you can begin to link those LOBs by
composing their services into larger business processes. Likewise, you can
decompose the main services of your LOBs into a set of more basic services that
can then be easily recomposed either to change LOB processes, or to interlink
your LOBs at a lower level of their capabilities. Similarly, you can use the same
principles of composition to create links with your business partners to both
automate those relationships and to gain more efficiency from them. One
consequence of service orientation is flexibility: you gain the ability to iteratively
optimize your business design, unhampered by inflexible IT structures.
A service-oriented architecture, then, is an architectural style for creating an
Enterprise IT Architecture that exploits the principles of service-orientation
to achieve a tighter relationship between the business and the information
systems that support the business.
Composite applications and service-oriented architecture
There are many challenges associated with application development and
delivery in today's On Demand world. Companies face requirements to grow
their businesses and increase revenue; however, they must also balance these
requirements against the costs of ever increasing needs to develop the
company's information technology infrastructure. Flexibility is critical for business
agility and for offering new business and customer services in response to
competitive pressures. Along with these challenges comes an increasing focus
on employee productivity and operational efficiency. So how does an
organization confront the daunting technology activities involved in integration or
development of new products, markets, business services, among other areas,
while maintaining existing services and leveraging existing technology
resources? Service Oriented Architecture (SOA) provides a methodical
approach to addressing these challenges by providing an extensible framework
that allows growth, development, and agility in the information technology
infrastructure.
In SOA, a service is defined as a "repeatable business task". For
example, tasks that are performed repeatedly throughout any given timeframe
(e.g. checking customer credit, pulling down new work orders, etc) can be
componentized and automated to the extent possible and feasible. Service
Oriented refers to the concept of integrating business by linking these "services"
together to deliver a complete solution. Considering these definitions, Service
Oriented Architecture is the architectural approach for implementing the linked
business services concept. In the context of SOA, Composite Applications are
groups of business services programmatically linked together to deliver a
comprehensive business solution.
With this understanding, it's clear that SOA provides a foundation that is
specifically targeted at building business applications. The definition of SOA from
Service Oriented Architecture for Dummies by Judith Hurwitz, Robin Bloor and
Carol Baroudi is "an architecture for building business applications as a set of
loosely coupled black-box components orchestrated to deliver a well-defined
level of service by linking together business processes."
Considering the definition of SOA, it's important to note that composite
applications themselves are not extensions to SOA, but instead, the extensions
are the components that make up the composite applications. For xample, In the Lotus Expeditor
client environment, a composite application is an aggregation of components
that, when wired together, provide the ability for the components to communicate
and interact with each other. These client components are the true extension of
the SOA architecture.
There are several characteristics that are essential for true SOA
implementations. First, SOA implementations should embrace open standards
such as SOAP, WSDL, XML, HTTP/HTTPS/JMS, J2EE, Eclipse, OSGi, etc, for
new application development. These standards provide maximum flexibility in
terms of application portability and protect software assets from obsolescence
associated with changes in proprietary implementations. From an application
integration perspective, SOA simplifies the integration process. An added benefit
is savings realized by creating an application once and reusing across multiple
lines of businesses (LoBs). For example, an account creation service may be the
same across multiple LoBs so the asset could be used in each LoB application.
Secondly, the architected implementation should provide the flexibility that
simplifies integration with legacy applications as solution components where
these components may include embedded browsers, ActiveX®, web services,
Eclipse based RCP, intelligent forms, host access, native Windows®
applications, portlets, web containers, etc. Effectively, integration is dependent
on the ability for applications to call other applications using existing standards
as defined in the previous paragraph. There should be virtually no limit to the
possible composite application permutations.
Thirdly, the initial driving force behind SOA has primarily been web services;
composite applications have primarily been portal based. However, with the
introduction of Lotus Expeditor, a new dimension has been added to SOA, the
concept of extending SOA to the client. Accordingly, the principles of SOA should
also apply to the client. As a matter of fact, to be thorough the client SOA focus
should also take into account that today's On Demand business requires a
solution architecture which incorporates the needs of mobile employees. The key
here is to develop a consistent architectural strategy for the entire enterprise
from the client to the back-end, delivering an end-to-end SOA solution.
Fourth, a well-designed SOA solution should include end user considerations.
The user interface should aggregate the solution components in a manner that
reduces end user retraining by preserving the application look and feel. Where it
is practical and conducive, some functions can be moved from back-end servers
to the clients, thereby decreasing application response times, decreasing the
network load and reducing latency while offloading back-end servers. The "plug
and play" fashion of new runtimes should allow applications to be loaded and
unloaded on the fly. For example, an application could start another application
for any given need, and then stop that application when it is no longer required
as part of runtime. Composite applications embracing the OSGi standard can
establish parameters to automatically unload the stopped program thereby
minimizing the footprint and freeing up system resources. Additionally, there
should be provisions to manage dependencies with minimal user intervention
(e.g. App A requires App B so if it's unavailable on the client it will go search for it
on the server). Together, these considerations translate to an improved user
experience. For mobile users, additional provisions should be built in for offline
operations.
Finally, to deliver on the SOA promise to "orchestrate" components and services,
the ability to centrally manage and control clients should be a part of any SOA
architected solution. Centralized management ensures compliance with
corporate standards, enables automated installation and configuration of
applications, and automates the delivery of pertinent information.
So then, how do composite application components tie into and extend SOA? In
the previously stated definition, SOA specifies building loosely coupled
applications and treating them as "black-boxes". Well-designed Composite
applications implement this architectural approach by providing for building
business applications as described; however, they should take it a step further,
providing integration of existing applications with other existing, as well as new,
applications. Reusable modules of code, written with standards compliance in
mind, allow the black-box approach by providing components with well-defined
and documented access criteria which perform specific business processes. For
example, an Order Entry class may be developed with methods to perform the
following functions:
Enable selection of various related items to be ordered
Query suppliers for the available inventories and prices
Consolidate the items and prices from multiple vendors into a single order
Enforce a policy to limit orders to a set amount
Present a screen for final review and submission to approver
The SOA concept of linking together business processes is the centerpiece of
composite applications. For example, once the Order Entry class is developed,
the module (or black-box) could be utilized as a component of other composite
applications. The developer of the composite application would only need to
utilize the methods surfaced by the Order Entry class. Then as part of the
composite application scenario, a Sametime® plug-in could be developed, and
linked to the Order Entry module, to enable the Order Entry application to
generate an automated Sametime message to the order approver.
We can extend this scenario to account for a mobile sales force by building-in
offline capabilities. For example, at the beginning of the business day, the
business application could send queries to the suppliers and store the item and
price information in a local database on the client device. The sales person
would then process orders throughout the day without concern as to the status of
the connectivity. When offline, transactions could be queued for delivery once
connectivity is reestablished. Furthermore, device management could be
employed to install and configure the sales applications, and to sync price
changes to the local client databases as necessary.
SOA summary
Service-oriented architecture and Web services enable new opportunities for
more flexible, rapid, and widespread integration in a model that is consistent with
the exposure of business function as services. SOA and Web services offer the
choreography of those services into processes that can be modeled, executed,
and monitored with features such as:
SOA defines concepts and general techniques for designing, encapsulating,
and invoking reusable business functions through loosely bound service
interactions. Most of the techniques have been proven individually in previous
technologies or design styles. SOA unites them in an approach that is
intended to bring encapsulation and reuse to the enterprise level.
Web services provide an emerging set of open-standard technologies that
can be combined with proven existing technologies to implement the
concepts and techniques of service-oriented architecture.
Industry support for Web services standards, interoperability among different
implementations of Web services, and the infrastructure technology that is
required to support a service-oriented architecture give technology customers
increasingly mature and sophisticated technologies that are suitable for
service-oriented architecture implementation.
These techniques and technologies give you the tools that are required to
implement flexible service-oriented architectures and to evolve toward an on
demand business model. However, SOA is an architectural approach, not a
technology or a product. In order to implement an SOA, you must have the
infrastructure to support the architecture, such as an Enterprise Service Bus and
a service registry and repository.
For more information, go to the following:
http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-soa-whitepaper.pdf
https://www.ibm.com/software/solutions/soa/gov/
http://www.ibm.com/developerworks/ibm/library/ar-servgov/
http://www.ibm.com/developerworks/rational/downloads/06/plugins/rmc_soa_gov/overview.html
http://www.ibm.com/developerworks/wikis/display/woolf/SOA+Governance?showChildren=false&decorator=printable
This wiki has moved to a