Where's the SOA Beef?
Mahesh H. Dodani, IBM Software, U.S.A.
|
 |
COLUMN
PDF Version |
1 SERVICE ORIENTED ARCHITECTURE RECAP
"SOA is hot now because it reflects a concerted effort to
have a full end-to-end architecture that works within and between
enterprises." – Bob
Sutor, Blog on SOA and web services
http://www-106.ibm.com/developerworks/blogs/dw_blog.jspa?blog=384.
Service Oriented Architecture (SOA) seems to be on everyone "lips" and "minds." There
is a lot of ongoing work in the area, and the field continues to mature
at a very fast pace. Most of the industry is focused on showing the
rapid adoption of SOA within enterprises as is evidenced by the following
sampling:
•
Technology analysts are reporting on the state-of-the-practice, highlighting
emerging practices, principles, adoption maturity and product support.
For example, Zapthink provides many levels of reports covering SOA
practice ranging from patterns ensuring adoption of SOA principles
to antipatterns showing common practitioner mistakes (http://www.zapthink.com/cluster.html?id=practice.)
•
Comprehensive roadmaps for enterprises to adopt SOA are being developed,
for example, the one defined by CBDI at http://roadmap.cbdiforum.com/.
This roadmap provides an organization a step-by-step guide to transition
into SOA and web services. An important aspect of the roadmap is the
definition of a maturity model (for the underlying web services technologies)
that allows the organization to gauge the effectiveness of their adoption
of SOA and the underlying technologies.
•
Many books have been written on SOA and the practices of adopting it
within a solution or enterprise. One such book list, http://www.amazon.com/exec/obidos/tg/listmania/list-browse/-/1MZETAUOOCQS0/ref=cm_lm_lists/002-5289932-2690458,
includes a wide range of books on the topic including underlying components
and technologies (e.g. Enterprise Service Bus), patterns and approaches
for realizing SOA within enterprises, and tackling Qualities of Service
(QoS.)
So, "where’s the beef" in SOA practices? In
order to have a comprehensive practice established, we need to have
methods
to guide the practitioner, reference architectures (and associated
implementations) to provide a blueprint for the practitioner to follow,
patterns and frameworks that provide detailed guidelines to ensure
known (and best) practices are followed, and products/tools that provide
the capabilities that are needed.
In the following section, we walk through the methods, reference architectures,
patterns and supporting products/tools from IBM to showcase the state-of-the-practice.
2 STATE OF THE PRACTICE
We start by articulating the overall approach in adopting a SOA approach
within an enterprise. We showcase the approach from the perspective
of the lifecycle of an on demand service as shown in Figure 1.
Figure
1: Lifecyle of an on demand service
As shown in the figure, the first step for the enterprise is to develop
their business model to identify the core and differentiating business
services that support particular business goals the enterprise cares
about. These independent business services typically implement a meaningful
business process or task that is provided to users or other businesses
the enterprise interacts with. The business service itself is assembled
from a set of integration services and the resulting assembly is deployed
and managed in the on demand infrastructure. The integration services
must provide all the capabilities to ensure that the business process
or task is fully realized in terms of new and existing legacy-based
components, and can be effectively used by the user and business communities.
The deployment and management of the on demand service require support
for service-level automation and orchestration services to ensure that
the service can be configured, secured, optimized and managed in an
automated manner (e.g. using autonomic computing capabilities.) To
facilitate flexibility and simplification of the underlying infrastructure,
the use of resources (hardware, storage, etc.) is handled through virtualization
services. These services are capable of “sensing and responding” to
workloads to assign resources on demand.
You can follow the “day
in the life” of an on demand busines
service in order to better understand the capabilities, services, and
their interactions at http://www-128.ibm.com/developerworks/library/i-odoe1/.
This article shows the life cycle of an on demand application from
modeling of the underlying business functions and performance indicators
to construction and assembly of a business service component implementing
the model objectives, to the deployment of that component as a business
service into the on demand infrastructure.
Figure 2 depicts a reference
SOA to support the development and deployment of on demand services.
Business services provide users and external
businesses access to the exposed business processes and functions.
Application services are used to implement the exposed business processes
and functions, which are in turn deployed and managed using the infrastructure
services. These services communicate, interact and integrate with
each other through the enterprise service bus.
Figure 2: on demand operating environment reference architecture
Exposed business services are implemented using application services,
which in turn comprise the following services. User access services
provide support for handling various device types, interaction modes,
and connection mechanisms that users can use to access the business
services. The user interaction services complement these access services
to facilitate a collaborative environment for the users to participate
in the business process. Business function services provide “atomic” functions
(e.g. packaged applications) that are needed to implement the business
service. Common services provide “helper” functions to
augment the implementation. Information management services support
all the information needs of the business service, including access
to integrated information on disparate data sources, analysis of the
data to provide business intelligence, and manipulation of the service
metadata. The choreography of all the needed services to implement
the business services is supported by the business process choreography
services.
The implemented business service is deployed and managed
using infrastructure services. Deployed services are managed using
the service level automation
and orchestration services. These services ensure quality of service
policies for the business service, and also support specialized management
services dealing with availability, configuration, workloads, problems
and end-to-end security. Autonomic managers monitor service execution
based on policy declarations, analyze the service behavior, and based
on the analysis may plan an action to resolve a problem and execute
the plan. This autonomic approach is called the Monitor-Analyze-Plan-Execute
(MAPE) feedback loop, and is an integral component for attaining infrastructure
simplicity. The actual resources (server, storage, network, etc.) are
virtualized and made available to the business services through resource
managers. These resource managers can map available resources to the
requirements posed by business services and their QoS declarations,
and dynamically change these based on utilization. To support services
or their components being hosted, outtasked, or outsourced, utility
business services provides functions for billing, metering, rating,
peering and settlement.
All interactions between services flow through
the Enterprise Service Bus (ESB). The ESB supports both event-based
as well as message-based
interactions. The ESB facilitate these interactions by providing services
to find services, handling interface mismatches, transforming inputs
and outputs, and connections to legacy applications and business functions.
Note the patterns used to build infrastructure and application services – adapters
enable integration of existing infrastructure components into autonomic
management and resource virtualization, process choreography is used
for scripting MAPE execution plans, and the ESB provides the infrastructure
for exchange of events between managed elements and autonomic managers.
SOAs
require standards for the definition of services and their capabilities
and interactions. The growing acceptance of XML as a standard representation
of structured information and of Web services standards (often called
WS-* standards) have greatly facilitated the adoption of this architectural
approach. To allow the ESB to provide all the needed services, it
is important that it has a normalized representation of services, which
is accomplished by making all application components look like WS-*-defined
services. Note that the ESB facilitates SOA principles to apply to
the virtualization of both business functions and physical infrastructure.
The on demand operating environment spans the construction of applications
as well as their deployment and management. Clients (users or businesses)
only see a collection of business services and are interested in
their
quality of service, but the on demand operating environment shields
them from the details of application assembly and service delivery.
To explore the architecture for the On Demand operating environment
and its guiding principles in more detail, please visit http://www-128.ibm.com/developerworks/library/i-odoe1/.
To
guide the development of robust, industrial-strength SOA based implementations
we require supporting patterns and frameworks. In
previous columns
I have introduced IBM Patterns for e-business (http://www-106.ibm.com/developerworks/patterns/)
which define a set of proven, reusable architectures that can drive
the design, development, implementation and extension of complex
applications. These patterns have been culled from the documentation
and analysis
of successful IBM projects. They match business challenges with
Business and Integration patterns, use proven Application and Runtime
patterns,
populate the Runtime patterns with pre-tested Runtime Product Mappings,
and establish best practice guidelines for application design,
development and management. Figure 3 shows the extension of the IBM
Patterns
for e-business to address SOA. In particular, the SOA pattern can
be viewed
as a composite encompassing access to the exposed services using
self service and collaboration patterns and interaction with other
external
businesses and partners using the extended enterprise patterns.
The self service business pattern allows users to interact with business
services, while the collaboration pattern enables business partners
and users to be part of the business process workflow. These business
patterns are combined on the front-end using access integration
patterns
and on the back-end using application integration patterns.
Figure 3: SOA and Patterns for e-business
To explore these SOA patterns and related best practices, access the
available redbooks that address these topics at http://www.redbooks.ibm.com/cgi-bin/searchsite.cgi?query=Service-Oriented+Architecture.
Finally, we need
to address the capabilities needed to support a successful implementation
and deployment of an SOA. There are many ways to define
the needed capabilities and the support of these in products and
tools. For example, http://www-106.ibm.com/developerworks/library/i-odoe2/ defines the capabilities required to support integration and infrastructure
management that are needed to build an on demand service. Figure
4
shows the capabilities that are needed for integration and the products
and tools that support these capabilities. For more detailed coverage
of these capabilities and products, visit http://www-306.ibm.com/software/info/openenvironment/soa/.
Figure 4: SOA Capabilities and Product/Tool Support
This column has provided a comprehensive view of the growing maturity
of the state-of-the-practice for SOA, and presented all aspects of
the needed support including methods, reference architectures, patterns,
and products/tools. Underlying this maturity are the many projects
that have successfully implemented SOA. These projects continue to
prove that SOA is “beefy” and will become the de-facto
guiding principle in the development of complex applications.
About the author
|
 |
Mahesh Dodani is a
software architect at IBM. His primary interests are in enabling
communities of practitioners to design and build complex on demand
business solutions. He can be reached at dodani@us.ibm.com. |
Cite this column as follows: Mahesh Dodani: "Where's the
SOA Beef?", in Journal of Object Technology, vol. 3,
no. 10, November-December 2004, pp. 41-46. http://www.jot.fm/issues/issue_2004_11/column4
|
