Service Oriented Architecture










PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The
reader is available for free
download
.

Service Oriented Architecture

by Kirk Woodward

Docid: 00018001

Publication Date: 1808

Report Type: TUTORIAL

Preview

Service oriented architecture (SOA) is a widely-endorsed conceptual
approach to infrastructure design that offers efficiencies in
the deployment of applications, both internal and inter-company,
based on the concept of designing app functions as reusable
services. Implementing SOA requires considerable analysis since it is
intended to leverage currently-owned as well as new third-party
technologies. The latter are being increasingly marketed by both major and
niche vendors. Cloud technologies, smartphones, and other mobile devices
are currently powerful drivers of SOA implementation.

Report Contents:

Executive Summary

[return to top of this
report]

One of the most significant trends in the technology space is the rise in
the use of service oriented architectures (SOAs).

Service Oriented Architecture Platforms Tutorial

XML Development Tools Tutorial

SOAs are an approach to systems integration that aim to make it possible
for users of network technology to integrate applications both within an
organization and across its various locations. Effectually, an SOA acts as
an IT strategy that organizes the discrete functions contained in
enterprise applications into interoperable, standards-based services that
can be combined and reused to meet business needs.

SOAs make it possible to reuse the services that comprise an application
extensively across an organization. SOAs can also help companies maximize
computing power by strategically balancing the locations of services on
different servers, even on servers outside of the corporate LAN, if
desired.

SOAs can offer the opportunity of enabling an organization to
quickly assemble and dissolve trading partnerships to suit a shifting
business environment, and of making it possible for applications to be
either internally integrated or developed from scratch using a
minimum of resources.

While the concepts behind SOAs have been around for more than a decade,
the underlying technology of Web services and microservices have greatly
supported its ascendance. Additional impetus is being supplied by cloud
technologies and by the dramatic increase in the use of smartphones and
other personally owned devices for business purposes. Cloud based SOA is
frequently referred to as Service-Oriented Cloud Computing Infrastructure
(SOCCI).

The key challenges to businesses interested in implementing SOA today are
(1) understanding how it can help an organization achieve its goals and
(2) reengineering business processes to exploit its capabilities. Major IT
vendors are investing heavily in the SOA market, which is predicted by one
study to reach a worldwide volume of over $16.4 billion by 2020.

Description

[return to top of this
report]

SOA is an architectural framework that breaks down software elements and
business processes into standardized components that can be combined and
reused with minimal effort. It does this by providing a layer of
middleware that enforces policies and rules for services, such as
security, routing, and workflow. In an SOA, all functions are defined as
services; however, an SOA only defines a service’s required parameters and
results, not the technology used to implement those results.

Thus, the technology that delivers a service is independent of the SOA.
Applications based on Web services can plug into middleware to be
reused or recombined into composite applications. As a result, the terms
“SOA,” “Web services,” and “microservices” are frequently used together.
SOAs may use technologies other than Web services and microservices;
however, most businesses are considering these in conjunction with each
other, and that is the focus of this report. Nevertheless it must be
stressed that the conceptual element of SOA is at least as important as
the technical aspects.

To implement an SOA, a company first analyzes its existing infrastructure
and intercompany relationships to determine how it can treat the
components of its infrastructure as reusable services. It creates a plan
to implement this approach, using its own existing technology where it
can, and when needed importing other technologies designed with SOA in mind,
typically including Web services microservices, and, with increasing
frequency, cloud services.

SOA, then, is not a product or an item to be purchased and installed, but
an analytical and conceptual framework to be followed and expanded on as a
company achieves efficiencies through the reuse of services throughout its
infrastructure.

The concept of the SOA is not new, having been originally used in
relation to DCOM and Object Request Brokers based on the CORBA (Common
Object Request Broker Architecture) specification. Since the emergence of
the CORBA specification made it possible to integrate applications on
disparate heterogeneous platforms more than a decade ago, businesses have
pursued the promise of technology-based solutions to business needs such
as cross-enterprise integration, B2B/B2C integration, and other flexible
business models.

True application integration, however, has not been easily achieved. The
wide range of technologies that are in use today, particularly involving
the cloud, and, increasingly, smartphones and personally owned devices,
creates a business environment in which each application integration
project is a unique effort, requiring customized programming and project
management. As businesses increasingly adapt new technologies and software
products to serve tactical needs throughout their organizations, the
vision of agile, secure integration becomes both more imperative and more
difficult to achieve.

To meet this need, it is highly advantageous for an architecture that
allows components and services to be assembled and delivered
speedily, even dynamically, to be adopted. Computing architectures
that allow fully distributed processing, programming languages that run on
any platform, and connectivity tools that ease integration, all exist
today; however, none offers a complete coherent architectural framework.
SOA is an attempt to provide such a framework.

A basic example of an SOA technical solution is a collection of Web
services created in a service layer. Web services are software
components that control access to hardware, software, or data entities
that are essential to the function of other entities available over HTTP.
Thus, in the same way that the World Wide Web is a mesh of information,
Web services create a mesh of automated, machine-to-machine programming,
with handling of requests that can be accessed by any authorized member.
The services include published interfaces that enable them to communicate
with each other by passing data or by coordinating activity between two or
more services.

Increasingly, the location of services matters less as means of
communication increase. Web services take objects and code fragments
written in disparate languages and located on different servers, and make
them available for use in any program, on any platform, with no need to
rewrite code to integrate it into an enterprise. This is possible through
the adoption of standards that define how data will be requested and
passed. These standards mediate the differences in data types, and
operating platforms are removed from the equation.

Because of the value of sharing data among trading partners without the
heavy burden of integration that has existed in the past, many IT
departments find themselves fielding questions from management about the
benefits and drawbacks of Web services. The vision of mature Web services
is that the Internet itself becomes a platform-independent programming
environment that makes it possible to connect and disconnect applications
in a matter of hours, even if they sit on the cloud or behind firewalls
that belong to trading partners.

It is important to mention again, however, that SOA and Web services are
not identical. The difference between an SOA and a Web service may be
described as follows: an SOA is strategic and Web services are tactical.
The SOA defines what must be done, and Web services (and when
appropriate other elements, such as microservices) perform the functions.

For most organizations the path to achieve the SOA ideal is bound to be
complex. The enterprise must agree on standards in order to enable
platform-independent communication. Authentication and access technologies
and policies must be in place to allow a user’s requests to be
transparently processed across multiple firewalls. Quality of service must
be assured, so that a broken database behind one firewall does not impact
users who are accessing it from behind other firewalls.

Most of what was said above of Web services can be applied to microservices as well, and there can be overlap between the two.
Microservices are applications designed as a series of small independent
applications, including some simple means of communication with other
applications (an API, or Application Programming Interface). Since an SOA
is a conceptual framework, an SOA can be built of Web services, microservices, or both.

Standards

Standards define the data that is being passed back and forth so
that it can be understood by the requester and the server. There are
estimated to be over 120 standards that can currently be used in an SOA.
Numerous other standards are in development; some compete with each other,
some are designed to extend the power of other standards, and some serve
highly specialized business needs.

The technical standards that are the most influential in relation to SOA
are XML, SOAP, WSDL, and UDDI. Security standards exist, as well, and are
discussed separately in the section on authentication. Table 1 lists some
of the most common standards that make up the SOA concept. This table is
not all-inclusive, because an SOA will always take on at least some of the
characteristics of an already-installed environment.

It should be noted that business standards for SOAs exist as well, one of
the most significant being Domain Driven Design, or DDD, which is not a
technical but a business standard. The following table refers to technical
standards.

Table 1. SOA Standards

Standard

Description

Extensible Markup
Language (XML)

XML is generally
recognized as a core standard of SOA. XML tags data so that
other programs can parse the code and identify and reuse pieces
of information that are contained in it. XML is a flexible
way of building common frameworks for information that can then
be shared online and used for electronic display, as well as
for creation of print media and the populating of
databases. XML is similar to HTML, the language used to build
Web pages today. An XML file can be displayed on the Web.
Information within its tags can be stored in a database and can
trigger an action, for example dialing all numbers within the
<PHONENUM> tags. XML lets developers create their own
tags, but all developers must use the same tags if information
is to be shared. As long as developers use the same tags to
define data, information can be shared among any documents on
the Web or any database on any server.

In relation to Web services, XML describes calls and results.
It does not have anything to do with the actual passing of data,
the identification of compatible potential partners, or the
security of the data as it is passed. Those activities are
performed by standards like WSDL, SOAP, UDDI, and SAML. 

Other standards also exist, many serving niche markets. Two
that impact every business using Web services are ebXML and
BPEL4WS.

Simple Object Access
Protocol (SOAP)

SOAP is the basis of
Microsoft’s .NET strategy, and has achieved a strong level
of acceptance among other major industry players. SOAP is a way
for a program running in one kind of operating system to
communicate with a program in the same or another kind of
operating system by using HTTP and XML as the mechanisms for
information exchange. SOAP uses existing XML parsers and HTTP
libraries to do most of the work, which means that SOAP
implementations can often be completed in a few months. Related
standards include WS-Addressing (message headers),
WS-Reliable-Messaging (delivery guarantees),
WS-Security, WS-Policy, WS-MetadataExchange, and UDDI.

Web Services
Description Language (WSDL)

WSDL describes
available services. Based on XML and SOAP, it is used to
describe the services a business offers and to provide a way for
clients and partners to access those services electronically. In
practical terms, it enables a programmer to connect disparate
applications without having to find and study two sets of
application development manuals; instead, the programmer can
simply read the WSDL to identify a function call, its location,
the method to call it, and the parameters it requires. This
reduces integration time from months to hours, providing that a
valid WSDL and SOAP interface exists. WSDL is also the
cornerstone of the UDDI initiative, which is described next.

Universal Description,
Discovery, and Integration (UDDI)

The UDDI project is
not a technical standard; rather, it is intended to advance the
acceptance of Web service standards by enterprises. It provides
a searchable index with pointers to WSDL service descriptions.
It is also the basis of an operational registry. Before the UDDI
project, there was no industry-wide, accepted way for businesses
to reach their customers and partners with information about
their products and Web services. Nor was there a way to discover
information necessary for businesses to integrate into each
other’s systems and processes. UDDI is like a Yellow Pages that
offers not only contact information, but programmatic
descriptions of the Web services offered by each business, so
that other businesses can see if the technology is compatible
with their own.

Continuing the example of Web services as an illustration of SOA
implementation, there are three major functions inherent in the Web
services model:

  • Service Discovery – The process of locating service
    providers and documentation describing services (as through the UDDI
    directory).
  • Service Invocation – A method of calling a service
    based upon analysis of the metadata about the service.
  • Data Passing – The transfer of information between a
    Web service and its requester.

Authentication is the process of determining whether a user or a program
is what it appears to be. Authentication is usually done through the use
of passwords of varying complexity. Once the password is verified,
authorization is granted for the user or program to receive the requested
data.

Web services, however, require that users and programs access data behind
multiple firewalls, whereas microservices do not, necessarily. In a single
user Web services session, a user logged into a reseller’s site might
gather data that is actually being passed from a manufacturer’s site, a
shipping company’s site, and a third-party support site. Users cannot be
expected to enter another password each time they access a different
system, and trading partners cannot be expected to maintain password
information on indirect requestors.

The trading partners themselves must be comfortable allowing Web services
access behind their firewalls, where sensitive corporate data is
contained. Web services are based on XML and SOAP, which are simple and
portable, with no built-in security mechanisms; data transferred via Web
services consequently can face exposure to threats. Files that are passed
via Web service transactions must be secured en route because they are
inspected and altered at many points during a transaction; consequently,
each file must carry its own access permissions, and some parts of each
file, such as personal data, must be encrypted and signed.

The same considerations must be taken into account when locating
functions on the cloud.

Current View

[return to top of this
report]

The increasing acceptance and implementation of Web services, the
emergence of microservices, the corporate embrace of cloud technologies,
and the rapidly expanding use of smartphones and other personal devices,
have increased the already substantial interest in SOA. A further driver
of interest in SOA is a business environment in which decision-makers seek
tighter alignment of IT assets with business goals in order to reduce
costs and increase revenue. Decision-makers wish to extract additional
value from the IT systems in which they have invested over the past decade
or more. SOA accomplishes that goal by allowing existing assets to be
reused and recombined in new ways with a minimum of new investment.

SOAs are deployed in the enterprise software environment of large and
small businesses and have been released as enterprise software products by
the major software vendors, such as IBM, CA Technologies, Software AG, SAP
SE, Oracle Corporation, and Fujitsu LTD. SOA adopters are viewing SOA as a
long-term, strategic tool that streamlines development, reduces
integration time, and increases IT responsiveness to business needs.

The fact that SOA has been adopted by major application software vendors
and incorporated into cloud products eases the technical challenges of
integrating internal systems with hosted applications. At the same time,
SOA does not require a single-source solution, and in fact encourages an
architecture that can unite disparate technologies by treating them as
reusable services. The enterprise must evaluate the benefits of
application integration versus reliance on a single vendor.

An enterprise-centric view of systems management is increasingly affected
by Software as a Service (SaaS), meaning the outsourcing of software
functions onto the web, and by XaaS, cloud computing approaches that are
leading to a model based on and further developing the principles of SOA
by emphasizing shared cloud web services and service combinations such as
mashups.

A notable example of an approach to SOA on a technical level is The Open
Group Architectural Framework (TOGAF), a high-level design approach that,
in common with many SOA practices, emphasizes the use of currently
installed technologies where possible while moving the infrastructure
toward adopting an SOA.

Despite advantages, SOAs have not met with universal enthusiasm.
Implementing an SOA requires intensive analysis and focused execution. It
is almost never a quick or easy process. Experience suggests that
beginning with small steps at lower levels is a best practice for
implementation, even if the plan is to rely significantly on cloud
technology. Results may not be immediately apparent; patience and
determination are important assets in the process.

Outlook

[return to top of this
report]

SOA as an architectural approach is being widely evaluated, and
frequently recommended, because of market imperatives. Businesses
today operate under the requirements to create revenue, reduce costs,
and engage and disengage easily in partnerships, in addition to the
pressures of dealing with a recovering economy. In relation to these
goals, the future of SOA technology is strong, since SOA encourages these
goals by proposing broad functionality and integration that is streamlined
and agile. Estimates of future market value for SOA are increasing yearly.

Now that SOA is being adopted by enterprise software providers, it can be
used to solve the longtime problem of integrating hosted applications with
internal systems. Also, SOA fits well with other technology initiatives
such as grid computing, on-demand computing, utility computing, and cloud
computing, since as noted SOA is not in itself a technology. A business
that already employs one or more of the technologies referred to is more
likely to implement SOA and deploy it successfully. Major application
vendors are delivering SOA-enabled packages that increase the ease with
which Web services can be integrated with business processes.

Companies that successfully deploy SOA may find that other types of
enterprise software and developer tools are no longer necessary. If all
distributed computing efforts become service-oriented, as some analysts
are predicting, then tools for integration and development such as EAI,
ETL, application server, MOM, IDE, and RAD tools, may possibly be subsumed
within the SOA deployment, depending on how it is architected. The caution
remains that SOA is not an “easy fix” for anything.

Recommendations

[return to top of this
report]

An SOA can increase ROI because services can be isolated into modules
that exist separately from the applications that call them. For example, a
service might be written to provide credit card authorization. The service
can be used in conjunction with a specific application. If that
application is replaced in the future, the credit card authorization
service will still be viable for use with the replacement application.

Because the service code is independent of applications and is found by
client applications through lookup services and dynamic binding, it can be
moved without repercussions between servers or between external
providers and/or cloud services. Another benefit of isolating services is
that they can be tested independently, which makes it easier to test more
frequently, and therefore to produce services with a higher level of
quality than would otherwise be possible. Likewise, defects can be found
and corrected relatively quickly.

In SOA, services exist as a catalog of reusable assets that can be
combined in ways not conceived by the original developers. This makes it
possible to create new applications more quickly and at lower cost.

Decision makers will have to review and modify business practices and
processes to successfully exploit the concept of the SOA. This can present
a challenge, especially for companies that already have difficulty
coordinating business processes internally and managing multi-tiered
service level agreements (SLAs). Weak manual processes, poor data
coordination, and inability to automate straightforward tasks plague many
organizations. Companies that struggle with these fundamental operations
will have difficulty implementing SOAs.

Leverage Existing Technologies. The IT department
must prepare the corporate infrastructure for the deployment of SOA. It
must ensure that hardware, software, and applications are able to handle
the type of activity generated by Web services and are highly scalable in
order to handle dynamic traffic. Increased bandwidth use must be
anticipated and accommodated. Application servers must be tuned for
increased network traffic, and the demand for memory is expected to
increase as well. Some new technology may have to be implemented, such as
a dedicated XML infrastructure, or an increased use of cloud technology.

Problems can arise. For example,
an enterprise with an IT department skilled in Microsoft’s .NET
development platform might have difficulty implementing a Java
infrastructure, and it would not be practical to move the entire network
to an alternate platform merely for the sake of implementing a particular
Web service. In this instance, the importance of careful analysis is
clear.

Create a Dedicated XML Infrastructure. Application and
networking infrastructures by themselves do not meet the requirements of
an SOA. Application infrastructures are not usually tightly coupled,
while networking infrastructure does not handle the granularity required
by a SOA. An XML infrastructure must be loosely coupled, highly
distributed, and able to support the heterogeneous requirements of Web
services. An application based on Web services or microservices may be
executed on different operating systems, developed in different
environments, and operated through different networks and different
software systems. To maximize the investment in a SOA, a proper
infrastructure must be in place to support such requirements.

Train IT Staffs. Staff must be able to support
distributed applications, and to respond to scalability and security
issues. As SOA becomes available in suites of products that
provide security, management, business process automation,
integration, and development and testing tools, developers will benefit
from becoming fluent in all these categories, rather than from
specializing in one or two. With lower-level skills potentially being
recruited offshore, developers in the US need to understand the business
as well as the process perspective of enterprise architecture in order to
remain employable.

For a successful initial foray into an SOA implementation, as with many
software implementations, the first phase should be designed to solve a
real problem with measurable results. This phase of development should be
limited in scope but should be designed with future phases in mind,
particularly in relation to how Web services components can be reused. The
most versatile and fundamental components should be identified, and
developed first.

When evaluating the potential benefits of SOA, it is wise to discuss the
subject with partners and, for B2B enterprises, with customers as well.
Some Web services can be outsourced to partners, relieving the primary
enterprise of the burden of development and increasing SOA efficiency.
This approach may not always be practical. The goals of some
implementations, on the other hand, may present channel conflict issues
that must be hammered out in order for the implementation to succeed. From
a technical point of view, there must be agreement between trading
partners concerning which standards will be put to use.

Security issues must be continually evaluated while an SOA is
implemented, since a traditional inside-outside security model may not
protect exposed Web services. Various security protocols for SOAs are
being developed; for example, Microsoft, IBM, and VeriSign have combined
their efforts to create WS-Security, first released in 2006. IBM and
Microsoft also collaborated with other companies on the WS-Trust standard
for security between message exchanges. Security issues are not resolved
when processes are located in the cloud, as numerous security breaches
indicate. Cloud security must not be taken for granted.

SOAs provide a powerful and flexible programming model that reduces the
costs of development and ownership, and if properly executed, make it
easier to introduce new applications and systems. The advent of cloud
systems will certainly increase the probability of wider adoption of the
SOA approach.

[return to top of this
report]

About the Author

[return to top of this
report]

Kirk Woodward is a technical writer. In addition to
project management, his areas of expertise include enterprise software,
hardware systems, and the use of Internet resources.

[return to top of this
report]