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
Copyright 2018, Faulkner Information Services. All Rights Reserved.
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).
|
Related Faulkner Reports |
|
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.
|
Standard |
Description |
|---|---|
|
Extensible Markup |
XML is generally In relation to Web services, XML describes calls and results. Other standards also exist, many serving niche markets. Two |
|
Simple Object Access |
SOAP is the basis of |
|
Web Services |
WSDL describes |
|
Universal Description, |
The UDDI project is |
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.
Web Links
[return to top of this
report]
- CA: http://www.ca.com/
- Hewlett-Packard: http://www.hp.com/
- IBM: http://www.ibm.com/
- Microsoft: http://www.microsoft.com/
- OASIS: http://www.oasis-open.org/
- Open Group (TOGAF): http://opengroup.org
- Oracle: http://www.oracle.com/
- SAP AG: http://www.sap.com/
- World Wide Web Consortium (W3C): http://www.w3.org/
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]