Article type: Focus article

Service Oriented Architecture

Kathryn B Laskey, klaskey@gmu.edu George Mason University
Kenneth Laskey, klaskey@mitre.org The MITRE Corporation

Keywords
service oriented architecture, web services, distributed computing, publish-find-bind triangle,
metadata

Abstract
Service oriented architecture (SOA) is a paradigm for organizing a set of capabilities, often
distributed across the network and possibly under control of different ownership domains. The
organized capabilities can be used to provide solutions to business problems. A business
problem is broadly defined as any problem, in any domain of interest, encountered by an
individual or organization as it goes about its business. SOA is applied to business problems that
are amenable to information technology solutions. Services are made visible to potential users,
interact with users through a series of information exchanges, and produce real world effects.
Invocation and information exchange rely on standard languages and protocols that facilitate
interoperability. From a user’s perspective, invoking a service to produce an intended effect is
experienced as a single, atomic operation. The detailed sequence of actions carried out by the
service may involve any number of operations such as database queries, data transformations,
execution of models, and formatting of displays. These operations may themselves be composed
of lower level operations. The data and/or software modules required to perform the operations
may reside at different physical locations and be controlled by different organizations. The details
of composing the sequence of actions that produces the real-world effect are transparent to the
user interacting with the service. Service oriented architecture frees users to concentrate on their
business problem, leaving the details of the solution to the service.

The World Wide Web has created unprecedented opportunities to share information without
regard to geographic location of information resources and users. For example, a scientist can
collaborate with scientists on another continent to analyze data drawn from archives located on
two other continents, producing results that will be consumed by users all over the world. Data
access and communication can be accomplished instantaneously from the researchers’ and end
users’ workstations, eliminating the requirement for time-consuming and expensive travel and
shipping.

1
Achieving this kind of interoperation requires a means to bring together a set of capabilities,
which may reside at different physical locations and be under control of different ownership
domains, and combine them to address a user’s need. Service oriented architecture (SOA) is a
paradigm for organizing and packaging units of functionality as distinct services, making them
available across a network to be invoked via defined interfaces, and combining them into
solutions to business problems. SOA provides standardized mechanisms for matching needs with
capabilities, accessing and invoking the capabilities, and combining the capabilities to meet the
needs.

Example: SOA for Climate Analysis

The following example is inspired by SciFlo [1-2], a system developed by the NASA Jet
Propulsion Laboratory that allows scientists to assemble reusable web services, software
modules, and command-line scripts to perform multi-step analyses that make use of data sets
and apply operators residing at widely dispersed physical locations.

Consider a researcher studying climate change who wishes to obtain satellite imagery data for a
given space-time region. The data will be used to run a model developed at her lab to estimate
the concentration of certain atmospheric pollutants. The concentration results serve as input to a
chemical transport model developed by another lab to predict changes in concentration over time,
and those results will be used to produce final graphical displays. The traditional way to perform
such an analysis would be to gather and integrate all the necessary resources at the researcher’s
physical location. The researcher might send a request to the agency that maintains the satellite
imagery data, which would respond by sending a CD containing the requested data to the
researcher via the postal service. The researcher might write to the lab that developed the
chemical transport model to request a copy of the software, which would be sent via email or
another CD. While some of the requests could be processed via email and some of the data
could be transferred via remote file transfer, the programmer in the researcher’s lab would still
need to re-host the requested software on local computers and build additional software to
integrate the pieces. Furthermore, the data would not include subsequent updates. The process
of obtaining the data and the chemical transport model, and writing the software to combine them,
could take weeks to months and would represent a static snapshot at the time of the request. If
the researcher wanted to repeat the analysis on a new space-time region, she could reuse most
of the software, but would need to make another time-consuming request for a new data
snapshot. If the chemical transport model had been updated, that update would also be needed,
and effort would be required to incorporate the changes.

Increasingly, analyses such as this are performed with the support of services for accessing data
and invoking models. The process may include a combination of human actions through a user-
facing interface or machine-to-machine message exchange. A possible scenario for our
researcher would begin by accessing the data via a data access service. She could do this by
pointing her web browser to a page containing a form on which to enter information such as the
dataset she wishes to access and the space-time region of concern. From the consumer’s
perspective, the service is a black box: she enters her request, pushes the “retrieve data” button,
and is taken to a page of links from which she can download the data. The data access service
allows her to treat data access as a single, seamless operation: submit a form to request data,
and be provided with a site from which to download the requested data. Furthermore, researchers
from a variety of disciplines could make use of the service to access the data for their purposes.

After retrieving the data, the researcher manipulates it into a form usable by her pollutant
concentration model, runs the concentration model to produce outputs, and transforms the output
into a format that can be ingested by a remote service that invokes the chemical transport model.
Finally, she retrieves the results of the transport model and inputs them into her plotting program.

2
Once the researcher has refined and perfected her analysis, she may wish to perform the
analysis across a large number of geographic regions, repeat it on a weekly or monthly basis,
and ultimately make it available to other researchers. She could compose the steps described
above into a service she would own, i.e. one she would create, maintain, and possibly provision
for others. This service would take a space-time region as input and provide as output a set of
plots of estimated pollutant concentrations over time. Although the analysis makes use of models
and data residing at different geographic locations and owned by different organizations, users
would perceive the service as a seamless, unified operation. A user would simply enter a request
on a web form, and be directed to a web page showing concentration graphs. Alternatively,
machine-to-machine remote access could be invoked through a computer program. The user can
focus on the science; the service takes care of the administrative details of data access, data
transformation, and model invocation.

There are several fundamental aspects of SOA demonstrated by this example. First, looking
inside the black box of the data access service would reveal a sequence of actions triggered by
our researcher's request, including discovery of data sets, transformation of the query, and
processing of results. Some of these actions are themselves complex operations. The actions
are performed by the underlying capability of data access, likely much the same underlying
capability that would be used by the owner of the data if our researcher made the request and
expected to result to be mailed as a CD. To the scientist, a detailed account of this sequence of
operations is unimportant. However, what is important is that someone had previously developed
an understanding of the business problem of data access, and developed an automated process
for solving it. Making that capability accessible through a SOA service provides the benefits
noted in the example, but was not possible without having a capability to access.

Second, our researcher did not have to request a copy of the software owned by others, but had
a mechanism to use the capability provided by the software at a remote location where the
software is maintained and provisioned. This relieved the burden of re-hosting and maintaining
the re-hosted software. The topic of software versioning is beyond the scope of this article, but it
is a critical consideration for predictable and consistent use of a remotely maintained resource.

Finally in our scenario, the researcher was still responsible for conversions between different data
formats and possibly different community vocabularies. While there is discussion of mediation
services to facilitate this process, the burden at present falls to the user in the SOA ecosystem.

Business Services and SOA Services

A business service is a functionality invoked to address a business problem. Examples of
business problems include predicting changes in concentration of a pollutant over time, reserving
a flight between two cities on a given date, or cleaning a house. The first of these business
problems can be solved by running a given chemical transport model on specific data; the second
by making a reservation on a given flight offered by a particular airline; the third by hiring a
particular maid service to come to the house at a specific time and date. Note that in general
there will be more than one way to solve a given business problem: there are multiple models for
estimating pollutant concentrations; multiple airlines and flights connecting a pair of cities; and
multiple maid services.

Making use of SOA to solve a business problem requires prior existence of at least one solution
to the business problem. The pre-existing solution is the underlying capability for the business
problem of interest. SOA provides a means of using standardized mechanisms for discovery,
invocation, and communication to access the underlying capabilities. If the business problem
cannot be solved without SOA, then SOA cannot in itself provide a solution. The only business
problem to which SOA itself provides a solution is the business problem of information technology
(IT) facilitation of efficient interaction between consumers and providers of pre-existing elements
of solutions to business problems.

3
A SOA service, as distinct from a business service, is an IT artifact that provides the business
service of efficient connectivity between consumer needs and provider capabilities. It provides a
mechanism to access the capability of a business service and to realize some subset of the real
world effects gained by interacting with the SOA service to access the business service.
Returning to our three examples, SOA can provide interfaces to provide scientists with access to
existing chemical transport models; to provide travelers with access to existing airline reservation
systems; and to provide households with access to existing maid services. These services must
exist before SOA can provide a means to access and interact with them.

How does SOA Work?

A system built on the SOA paradigm must provide visibility of needs and capabilities; must
include a means for consumers and providers to interact; and must produce real world effects that
address a consumer’s business problem [3].

Visibility refers to the ability of consumers with needs and providers of capabilities that address
the needs to find each other and prepare to interact. This includes establishing (1) an awareness
by at least one participant of the other, (2) a willingness on the part of the participants to interact,
and (3) the reachability necessary to exchange information. A common means of achieving
awareness is a service registry that lists descriptions of available services. For a consumer to
assess whether a service meets her needs and eventually to interact with the service, the
description must include the functions performed; input and output formats; constraints and
policies; and mechanisms of access and use. Syntax and semantics of service descriptions must
be widely accessible and understandable.

Once visibility is established, interaction can proceed. This is most often accomplished by the
exchange of messages through well-defined service interfaces. The interface must prescribe the
syntax and semantics of the information to be exchanged and the protocols that define the
message itself. It must also specify the actions that can be performed against a service, any
dependencies or preconditions, and the real world effects that performing those actions will
produce.

Interaction occurs within a given execution context: the particular set of infrastructure elements,
processes, conditions and policies governing the given interaction between consumer and
provider. The execution context includes aspects such as security level, legal requirements, and
organizational policies with regard to information release. The service description (and a
corresponding description associated with the service consumer and its needs) contains
information that can include preferred protocols, semantics, policies and other conditions and
assumptions that describe how a service can and may be used. The participants (providers,
consumers, and any third parties such as government regulators) must agree upon and
acknowledge a consistent set of agreements in order to have a successful service interaction, i.e.
realizing the described real world effects. The execution context is the collection of this
consistent set of agreements.

Currently, the most common implementation of SOA is Web Services.1 The array of standards
used to define the Web Services interface is sometimes referred to as WS-*. These standards
and those that provide the underpinnings are primarily being developed by the Internet
Engineering Task Force (IETF) [5], the World Wide Web Consortium (W3C) [6], and the
Organization for the Advancement of Structured Information Standards (OASIS) [7], but a number
of other organizations [e.g., 8, 9, 10] also contribute specialized specifications. Most of these
standards use the Extensible Markup Language (XML) [11] as the basic syntax and provide a
binding to the Hypertext Transfer Protocol (HTTP) [12] for the underlying message protocol. The
primary Web Services message specifications are SOAP2 [13] to define the Web Services
message envelope and the Web Services Description Language (WSDL) [14] to describe

4
elements of the Web Services interface. SOAP and WSDL do not adequately address the
semantics issues and additional work needed to enable true dynamic discovery.

History and Promise of SOA

The idea of IT services to provide access to IT business functionality dates back to the Network
Services Model from The Burton Group in 1991 [15]. In this approach, network services include
file, print, directory, messaging, and security, and were designed for use within the corporate
intranet.

The term "Service-Oriented" Architecture was coined by Roy Shulte and Yefim Natis [16,17] in
1996 to describe a style of multi-tier computing that helps organizations share logic and data
among multiple applications and usage modes. In this work, SOA refers to a software
architecture that builds a topology of interfaces, interface implementations, and interface calls.

Expanding the concept beyond services for IT and software development functionality to more
general business concerns, the Network Applications Consortium in 1998 advocated [18] that
"organizations should plan to move to a multi-tier, service-oriented architecture in which strategic
applications are partitioned between user services, business services, data services, and legacy
services." The dominant programming models at this time were distributed object models, notably
CORBA and DCOM.

The first use of XML as the basis for exchanging IT service information, known as XML-
RPC3employed XML as a syntax for exchanging objects, in an attempt to avoid the complications
seen with CORBA and DCOM [19]. Later, the use of WSDL with SOAP introduced the idea of the
document-literal style, in which the message payload is included as an XML document. This
replaces the approach of passing a programming object through a programming interface. The
document-literal style is now considered best practice for Web Services.

With the emergence of XML, the paradigm for data exchange and services has shifted from
software objects to XML documents and from using services for IT functions to using services to
package, invoke, and deliver general business functions. As the focus continues to shift from IT to
more general business functionality, the service oriented architecture concept will see application
to business services that include human interaction and execution of physical processes not
directly related to information technology (as in the above example of a maid service).

Potential benefits of service oriented architecture include facilitating manageable growth of large-
scale enterprise systems, organizing large-scale networks of systems to enable and facilitate
interoperation, and reducing costs of activities requiring inter-organizational cooperation. Growth
of the SOA paradigm is likely to lead to changes in organizational structure to align with the new
way of organizing and delivering business functionality. Advocates of the SOA paradigm argue
that these changes will lead to more agile, scalable, evolvable and manageable systems and
organizations.

SOA in itself does not address issues associated with ownership, legal and contract obligations,
security and trust, delegation, authority, and other aspects of the business environment within
which services are used. These issues must be addressed by organizations within the
institutional and legal context of the interaction between providers and consumers. Once
adequate solutions to these issues have evolved, they can be represented and referenced within
service descriptions and service interfaces [3].

Conclusion

5
Service oriented architecture is a paradigm for the design of software architecture. It is not a set
of commercial products but rather a way of structuring IT solutions that leverage resources
distributed across the network and possibly owned by different people or organizations. SOA
enables the interaction between providers with capabilities to address business problems and
consumers for whom the real world effects of using those capabilities deliver the needed
solutions. SOA does not provide solutions for unsolved domain problems but it may provide an
efficient means for bringing together the pre-existing elements of a solution.
While use of Web Services is thriving, there are numerous issues that must be addressed to
realize the promise of the SOA paradigm. Among these are better means to go beyond syntactic
interoperability to achieve semantic interoperability; methods to ensure trust and security;
managing cross-ownership interaction; and developing organizational infrastructure that is well-
aligned with the SOA paradigm. A mechanism such as SOA for enabling seamless accessibility to
units of functionality, without requiring users to attend to the details of how the functionality is
implemented, is a necessary enabler for a large-scale scientific enterprise that involves
collaboration and information access without regard to physical location or organizational
affiliation.

Notes
1
As with SOA, there are numerous definitions of Web Services in the literature. For example, work done
under the World Wide Web Consortium (W3C) can be found at [4].

2
For SOAP 1.1 and before, SOAP expanded as an acronym to Simple Object Access Protocol. To reflect
modifications made during the W3C Recommendation process, SOAP-related specifications beginning with
the development of SOAP 1.2 no longer expand the name SOAP.

3
RPC is an acronym for remote procedure call.

References
1. SciFlo homepage: http://sciflo.jpl.nasa.gov/SciFloWiki/FrontPage

2. Yunck, T., Wilson, B., Fetzer, E., Braverman, A., Eldering, A., Garay, M., Manipon, G.,
Dobinson, E. and Tang, B. Rolling Out GENESIS/SciFlo in the ESIP Federation’s Earth
Information Exchange, Proceedings of the Sixth Annual NASA Earth Science Technology
Conference, 2006.

3. MacKenzie, C. M.; Laskey, K. J.; McCabe, F.; Brown, P. F.; and Metz, R. (2006)
Reference Model for Service Oriented Architecture 1.0. OASIS Standard, 12 October
2006. Available at http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

4. W3C Web Services Architecture Working Group: http://www.w3.org/2002/ws/arch/

5. Internet Engineering Task Force (IETF): www.ietf.org

6. World Wide Web Consortium (W3C): www.w3.org

7. Organization for the Advancement of Structured Information Standards (OASIS):

www.oasis-open.org

8. Web Services Interoperability Organization (WS-I): www.ws-i.org

9. Distributed Management Task Force (DMTF): www.dmtf.org

6
 10. The Liberty Alliance: http://www.projectliberty.org/

11. Extensible Markup Language (XML) 1.0: http://www.w3.org/TR/xml/ (most recent edition)

12. Hypertext Transfer Protocol (HTTP): http://www.ietf.org/rfc/rfc2616.txt

13. SOAP 1.1, W3C Member Submission, 8 May 2000: http://www.w3.org/TR/2000/NOTE-

SOAP-20000508/;
SOAP 1.2, W3C Recommendation, 27 April 2007: http://www.w3.org/2000/xp/Group/

14. Web Service Description Language (WSDL)

WSDL 1.1, W3C Member Submission, 15 March 2001:
http://www.w3.org/TR/2001/NOTE-wsdl-20010315;
WSDL 2.0, W3C Recommendation, 26 June 2007: http://www.w3.org/2002/ws/desc/

15. “The Burton Group Releases Report on Intranets and the Future of the NOS; Report
Serves as Foundation for Annual Conference”, Business Wire, 15 July 1996, available at
http://findarticles.com/p/articles/mi_m0EIN/is_1996_July_15/ai_18489134.

16. Schulte, W. and Yefim V. Natis, “Service Oriented” Architecture, Part 1, Gartner report
SPA-401-068, 12 April 1996.

17. Schulte, W. and Yefim V. Natis, “Service Oriented” Architecture, Part 2, Gartner report
SPA-401-069, 12 April 1996.

18. Business Services Architecture: Integration of software components and common

services infrastructure: A NAC Position Paper, 7 April 1998, available at
http://www.opengroup.org/onlinepubs/9199929699/toc.pdf.

19. XML-RPC.Com: http://www.xmlrpc.com/.

Further Reading
1. Erl, T. SOA Principles of Service Design. Prentice Hall, 2007.

2. Erl, T. Service-Oriented Architecture (SOA): Concepts, Technology, and Design. Prentice

Hall, 2005.

3. Papazoglu, M. Web Services: Principles and Technology. Prentice Hall, 2007.