Service Oriented Architectures

Published By: Prentice-Hall
Viewed: 10727

SOA Forward

This is a copy of the forward JT co-authored to a special edition of a book called Service Oriented Architectures published by Prentice-Hall. It was included in the box of a software package called Redberri Enterprise.

The old show-business bromide, “It took him 20 years to become an overnight success,”
can be applied to Service-Oriented Architecture (SOA). The foundations of SOA
are decades of best practices. And despite its numerous, unquestionable advantages,
many enterprises have been reluctant to invest in it. That tendency could well be
penny-wise and pound foolish. The idea of building services, minimizing redundancies,
and flexibly plugging them into an infrastructure grid is the way that everything
should be built. Although it hasn’t caught on to date, things are changing. Now, the
emergence of second-generation Web services standards are causing companies to
become increasingly interested in SOA. These emerging standards position SOA as the
foundation for building applications with unprecedented levels of flexibility, agility,
and sophistication.

Basic business needs such as lowering costs, reducing cycle times, integrating enterprise
applications, building successful B2B and B2C networks, achieving greater ROI,
creating adaptive and responsive business models keep us looking for more promising
solutions. Today, a growing number of organizations are coming to the realization that
without a consistent architectural framework within which applications can be rapidly
developed, integrated, and reused, “point solutions” won’t provide the return on
investment they seek.

The SOA Imperative
While SOA is not a new concept, the increasing adoption of Web services is a major catalyst
of change and increased interest in SOA today. The flexibility and reusability
inherent in SOA enables IT services organizations to transform their business models
from highly customized one-to-one services to one-to-many, or many-to-many reusable
services. SOA is now being promoted in the industry as the next evolutionary step in
software architecture to help IT organizations meet their ever more complex set of challenges.
SOA is now being viewed as the next step in the evolution of software architecture
needed to help IT organizations meet an ever more complex set of challenges. SOA
addresses real business issues through an architectural framework allowing the assembly
of components and services for the rapid and dynamic delivery of solutions. For the
numerous small to medium sized businesses, SOA enables them to efficiently share
information with other internal and external information systems. This system to system
information sharing capability is critical for a variety of supply chain management
scenarios. Web services, together with counterpart SOA and composite applications,
help such companies link their customers, employees, suppliers and partners into
seamless business processes in a cost-effective manner. Companies across the board
stand to gain from an understanding and adoption of SOA, especially when implemented
using XML based Web services.

SOA plays a key role in solutions that address the issue that every business faces: IT
complexity. Corporate management will always push IT for better systems and technology
utilization, greater ROI, integration of historically disparate systems, and faster
implementation of new systems. Legacy systems must be reused rather than replaced,
because budget constraints make replacement cost-prohibitive. Pervasive merger and
acquisition activity routinely requires entire IT organizations, applications, and infrastructures
to be integrated and absorbed. SOA allow the development of systems that
are ideal for heterogeneous and dynamic environments, where they must accommodate
an endless variety of hardware, operating systems, middleware, languages, and
data stores.

Corporate management must comply with the increasing number of on-going regulatory
and government required compliance mandates. In the U.S. alone, Graham-Leach-
Bliley and Sarbanes-Oxley are examples that apply to all public corporations while others,
such as the Health Insurance Portability and Accountability Act (HIPAA) and the
Basel II Accord, affect specific industries and companies that participate in them,
regardless of size. The adoption of SOA helps businesses to approach compliance as a
business process, managed over the long term. A best practice SOA-centric approach to
compliance draws, organizes and presents information from multiple application syserl_
fore.fm tems and other internal and external sources, enabling a broader and richer control of
business activities.

Capitalizing on the Opportunities of SOA
At the outset, it is necessary to understand that implementing an appropriate SOA
framework requires pragmatic and prescriptive guidance on how best to capitalize on
the opportunities SOA brings. Some of the more important aspects are:
• SOA allows a service provider and requester to be loosely coupled—meaning that
one need not know the implementation details of the other. The most common way
to do this is through SOAP (Simple Object Access Protocol) calls over HTTP.

• SOA are stateless—so that every conversation (or transaction) is separate and
distinct from every other conversation rather than building on or referencing
previous conversations. This allows services to remain simple because the service
provider need not keep track of the state of any given conversation. It simply deals
with the current request, and it’s done.

• SOA has well-defined interfaces—meaning that in addition to providing the
function of the service, the service provides all of the information needed to use
itself. The service will provide information such as the messages required to invoke
the service, the details of constructing those messages, and information about where
to send the messages. Today, these services are defined through the use of a WSDL
(Web Services Description Language) document.

• Since SOA is not limited to internal secure networks, but also includes the Internet, it
needs to provide several layers of security, including authentication, authorization,
and encryption. Authentication verifies the requester’s identity; authorization
verifies that the requester can use the service; and encryption keeps the data safe as
they pass between the provider and the requester.

Betting on Integration Middleware
A new generation of Integration Middleware solutions, standardized on Web Service
protocols, is strongly positioned to enable winning SOA solutions. In particular, openstandards
based Integration Middleware solutions provide the significant benefit of
being able to act as both a service provider and customer of Web Services, making them
ideal for solutions in a SOA environment. Integration Middleware might be thought of
as an after-market enhancement supplier for software. Just as someone might add a satellite
radio tuner, GPS navigation system, and theft prevention system after purchasing their car, Integration Middleware can be acquired and used to enhance a company’s
existing portfolio of software products. Integration Middleware provides the standard
open interfaces to build SOA, and obviates the need to repurchase, redesign, and redeploy
existing software infrastructure components. At the same time, it supports all of
the requirements and benefits of a true SOA environment.

SOA and XML Web Services
An appropriate approach begins with the understanding of SOA as a modular framework
that enables software components to interact seamlessly. While SOA is often confused
with Web services, they are not the same. SOA can be implemented without
using XML Web services. However, using XML Web services to construct SOA is ideal
because connections can then easily evolve as business requirements change. Since they
are loosely coupled, SOA architected with Web services specify information or service
requests, but not which systems must respond. For example, a customer service application
could respond to any request from any other system or service to interrogate or
manipulate customer information. Without specifying targets, a new application can
provide services without changing any of the underlying business systems that may
depend on it.

Equally relevant are composite applications that require Web services-based SOA.
Composite applications are built by aggregating the Web services provided by other
local or Internet-based applications. Application developers create an interface, after
which they add application services by binding the interface to as many Internet-connected
application services as required. A composite application links together the
right application parts to initiate a new business process without having to start from
scratch. For example, an employee service application that aggregates benefit and pension
information, as well as transactional capabilities from external providers, is woven
with internal HR processing capabilities. Architecting SOA using XML Web services is
particularly useful when:
• Redundant applications exist on two or more systems
• A new business application can leverage application services or functionality
established on a remote system, as needed
• Business processes are needed that target different constituents using the same basic
application services.
• Business processes are needed that require many points of integration with other
systems, such as customer relationship management

Weaving SOA into Operations
Sound preparation and architectural planning are more important than how SOA and
Web services are actually built. Simply jumping into Web services without a sufficient
understanding of the business requirements can result in missed strategic opportunities.
Defining XML terms and major business processes for internal use, and for connections
to partners, will make the transition to Web services easier. Organizations of every
size and scope should consider the following process when preparing to roll out bestpractice
SOA services:
• Learn about XML Web services technologies and standards, and evaluate the impact
of Web services on nascent and established IT environments. Look at existing
applications and consider how those applications can be decompressed into Web
services
• Educate peers, senior management and line-of-business managers on the business
capabilities of SOA based on XML Web services by emphasizing how data from
multiple-established sources and custom logic can be accessed to provide enterprisewide
integration
• Question application vendors and consultants about the role of SOA and XML Web
services strategies in their integration plans. Choose solutions based on their abilities
to drive, and not be driven by, standards development
• Develop a road map to control and drive the implementation of XML Web services
throughout your organization. Focus on line-of-business personnel and primary
business partners by involving them early in the process
• Pick a pilot SOA project and work with XML Web services. Application-servicebased
solutions (Web services) tend to be created in a series of small, lower-risk
steps. Once the initial pilot is successful, take on mid-sized deployments that begin
to cut across functional areas and business units
• Finally, develop other SOA applications by reusing established application
components. Also, consider using Web services as a basis for easily adding functions
to legacy systems or to help them connect to other systems.

Seeing the Future of SOA
Where we are going is just as important as where we are. Sometimes, when people talk
about the future of SOA, they talk about autonomous networks, self-writing services,
and artificial intelligence. While those are all interesting possibilities, they aren’t practical nor needed in an average business today. Instead the practical future of SOA is in
passive profiling, discovery, and trusts.

Passive profiling is an old concept that is being applied to the new area of SOA over
Web services. Passive profiling keeps track of how services are used and who’s using
them, and adjusts them according to those patterns. A simple application of this,
already in use, is to apply an automatic discount to a specific purchaser, either based
upon a pre-existing relationship, or perhaps by volume of orders.

Discovery can be likened to a search engine for services. In current terminology, this
implementation is called UDDI (Universal Description, Discovery, and Integration). It
allows a requester to ask a list of providers for a particular type of service. In this way,
the requester need not know who is providing the service, or even if it exists prior to
execution; hence, the name discovery. Discovery is already in use on a small scale
today, but it will become more pervasive and eventually become the “normal” way of
interacting with SOA.

Currently, when a requester asks a provider for service, the requesters often need to
authenticate themselves. This allows the provider to know who is using the service,
either for security’s sake alone, or for billing purposes. The problem today is that there
isn’t a really good way for the requester to know that he is talking to the right provider.
For instance, there could be a “man-in-the-middle” acting as the provider. The advent
of trusts will help to eliminate this problem. Both the requester and the provider will
know that they are conversing with the right entity. There are some standards being
developed to combat this issue, but it will likely be a while before a standard is agreed
upon and widespread adoption occurs.

Service-Oriented Architecture is not something to think about in the future. It is making
an impact today. It will continue to evolve and improve over time. There will always be
the visionaries who focus on the leading edge of what is possible without considering
whether or not it is practical. Happily, there will also always be the pragmatists who
get the work done with the tools at hand. Regardless of which of these best describes
you, gaining an understanding of SOA is important. SOA is useful, it’s practical, and
it’s here. This book provides an excellent introduction to this important area and will
help you see how to apply it within your organization.

Raj Rao and J.T. Smith
Brunswick New Technologies