Simple Object Access Protocol for Web Applications (Archived Report)


Simple Object Access Protocol for Web Applications (Archived Report)










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.

ARCHIVED REPORT:
Simple Object Access Protocol for Web Applications

by Candice
Block Lombardi

Copyright 2014, Faulkner Information Services. All Rights Reserved.

Docid: 00017821

Publication Date: 1404

Report Type: TUTORIAL

Preview

Simple Object Access Protocol (SOAP) is a platform-neutral, networked
application communication standard, designed to facilitate interoperability across the Internet.
Finalized in 2009 by the XML Working Group of the World Wide Web
Consortium, SOAP continues to support a programmer’s ability to quickly and inexpensively
integrate disparate processes and programs, such as e-commerce and cloud
applications, irrespective of platform or programming
language. While some vendors have replaced SOAP with CORBA or REST
architectures, as of 2014 IBM continues to promote SOAP as part of its Endpoint
Manager API.

Report Contents:

Executive Summary

[return to top of this report]

Simple Object Access Protocol (SOAP) is a web services specification based on popular, broadly adopted Web
technology standards such as XML and HTTP. The SOAP message format enables applications to
interoperate across the public Internet, without extensive integration work or
even much detailed mutual knowledge about the respective applications in
communication.

Related
Faulkner Reports
Service Oriented
Architecture Tutorial

In this
respect, SOAP differs markedly from the frameworks it is designed to
replace for example, Microsoft’s Distributed Component Object Model (DCOM),
IBM’s Component Object Request Broker Architecture (CORBA), and Sun
Microsystems’ Java Remote Method Invocation (RMI).

SOAP allows disparate application platforms to dynamically interact, integrating their
operations more tightly and more easily than would otherwise be possible. This
is SOAP’s chief appeal in e-commerce and business-to-business
applications. SOAP is often a foundation of service oriented
architecture (SOA) platforms that are on the market today. In particular, it
is the basis for many of the Microsoft products’ Web services protocol
stack, which have a broad audience. As
of 2014, IBM continues to tout SOAP as a useful part of its Endpoint Manager API for quickly and
easily extracting data about computers, inventory, security, and recent events
into other systems.1

There are SOAP competitors in common use. IBM’s CORBA has long been
popular, has a large legacy code base, and has a deep pool of qualified
developers. Technologies like Roy Fielding’s Representational
State Transfer (REST) seem to offer particular advantages to enterprise application developers as cloud
computing expands. In addition to battling competing
standards like CORBA or REST based applications, SOAP has yet to completely
deal with performance issues related to its reliance on XML. Parsing
extensive XML documents can make applications considerably slower than DCOM-, CORBA-, or REST-based solutions that do similar jobs.

Description

[return to top of this report]

Designed for Platform Independence. Microsoft, DevelopMentor,
and Userland Software began developing SOAP in 1998 to enable applications to share data and
interoperate across the Internet with true platform independence. Development
of the SOAP specification continued under the oversight of the XML Protocol Working Group
(which completed its work on SOAP and closed in 2009) of the
World Wide Web Consortium (W3C); W3C groups continue work on integrating the
standard more deeply into other W3C projects including Java Message Service. SOAP uses HTTP and XML to avoid the proprietary nature
of other distributed application protocols, such as DCOM or RMI. HTTP headers
are used to hold information necessary to deliver and receive SOAP-based
messages, while XML is used to carry the actual content of messages.

Facilitates Interoperability. Both XML and HTTP are
standard Internet protocols that are supported by virtually all operating
systems. In theory, using them as a means to communicate eliminates
interoperability issues. None need
be aware of the exact characteristics of the other party to a conversation. The communicating systems simply exchange XML based documents, which
are encoded and decoded locally.

Takes Advantage of HTTP. A clever aspect of the
design of SOAP is the way in which it takes advantage of HTTP, the standard
protocol for exchanging messages on the Web. Most corporate firewalls permit
HTTP messages to pass through (using port 80) so that their employees can
access Web content. Consequently, remote procedure calls that use SOAP and
HTTP can pass through as well, since the XML documents they exchange look
like ordinary Web traffic. This may sound a bit insidious in terms of
its security implications, but SOAP’s security typically piggybacks on
established and accepted HTTP methods, such as the secure sockets layer (SSL)
protocol. In addition, XML messages can contain digital signatures,
which decisively authenticate parties to a SOAP conversation. The thing
to keep in mind is that SOAP is essentially a message passing format. It isn’t specifically tied to the standard Web protocol, HTTP. Developers might choose another protocol if it posed advantages in terms of
security, message routing, or network latency. There are no SOAP-specific
security features articulated in its specification. Security methods built
into SOAP-compliant applications can and should be employed.

Distributed Computing Architecture. Historically, the Web has
been based on a client/server model. Web servers maintain data and
applications that are accessed by client computers across the Internet. There
has been movement to supplant or complement this architecture with a utility-like
computing model in which resources are distributed and systems act as both
clients and servers. 

  • In one scenario, this takes the form of peer-to-peer
    file-sharing. There is no master database in this situation. A
    large number of computers are linked by the Internet, and a small set of
    files are stored on each computer. Users have access to the shared files on
    every other computer, and thus can download from an enormous "virtual
    database" of content.
  • Another scenario, distributed computing takes
    the form of communication among applications stored on different computers.
    Applications can request data or a service from an application on another
    computer. As a result, the collective storage and processing resources of all
    of the connected computers can be fully harnessed. The performance of
    applications can benefit from having processing loads spread across multiple
    CPUs; this enables computers to be gainfully used when they might otherwise
    be idle, such as at night.

SOAP is designed to be a distributed computing standard that enables easy, platform-independent application
interoperability across the Internet, using any OSI compliant network
protocol. It overcomes shortcomings of other interoperability standards by flexibly
using the Internet as its communications medium and delegating XML document
handling tasks. These characteristics are crucial, because they allow
organizations to rapidly and autonomously network their systems, launch new
relationships, and swiftly respond to changing market conditions.

In addition to SOAP, there
are several other distributed computing protocols that enable an application
to make procedure calls to another application across a network, but these all
have at least one of the following two limitations: either they are unable to
facilitate communication across the Internet or they function only with
specific platforms. 

Web Services Are the Big
Picture

On its own, SOAP is an
interesting, but perhaps limited specification. Its true significance emerges when viewed as
a key part of the Web Services framework. Web services
are a collection of protocols and techniques that enable a heterogeneous
population of servers to interoperate in a loosely coupled, coarse-grained
way, linked only by stateless Internet connections. Web services are the
underlying pieces of an SOA.

Web services are
typically based on four underlying, complimentary standards: XML, SOAP, WSDL,
and UDDI. Here’s how this works:

  • Web
    services package content or functionality in XML messages, which may be
    sent to any client capable of ordinary Internet connection, making them
    the lingua franca of the Internet. Typically, XML messages are
    transferred using the popular and ubiquitous HTTP protocol, but this is
    mostly for reasons of convenience and not an inherent requirement of Web
    Services or its associated protocols. SOAP is the protocol by which Web
    services expose XML content to clients. SOAP’s semantics are both
    vendor- and platform-neutral, so that, at least in theory, anyone can
    build a client application that makes use of the XML content.
  • In
    order to enable Web Services clients to make sophisticated uses of
    material exposed by SOAP, the Web services description language (WSDL)
    protocol defines the interfaces of the exposed object. The client
    examines the list of interfaces and uses these to intelligently interact
    with the Web service’s content. The WSDL interface descriptions are
    themselves packaged in XML documents.
  • To make
    themselves known and freely available, Web services are registered in a
    public directory. The format of the directory entries is specified by
    the Universal Discovery, Description, and Integration (UDDI) protocol.
    Potential client applications can search the directory for desired
    services in much the same way a user searches for Web sites.

Clearly SOAP is a
critical underpinning of Web services, and support for it is being built into
a variety of products and services. In the larger picture, SOAP and Web
services promise enterprises a powerful new means of quickly and
inexpensively integrating business processes and systems, irrespective of
platforms or programming languages.

Competing Standards and Protocols

[return to top
of this report]

The primary competitors to SOAP are the Internet Inter-Orb Protocol (IIOP),
the Distributed Component Object Model (DCOM), and the Remote Method
Invocation (RMI) standard.

Internet Inter-ORB Protocol (IIOP).
IIOP is part of the Common Object Request Broker Architecture (CORBA), a set
of specifications describing how distributed program objects can communicate
across a network. IIOP is designed specifically to facilitate communication
across the Internet by taking advantage of the Transmission Control Protocol
(TCP). The shortcoming of CORBA-based protocols is that they do not use
application port 80, and therefore cannot typically travel through a
firewall.

Distributed Component Object Model (DCOM). Within a client/server
environment, the Microsoft-created DCOM enables client-based programs to
make requests of server-based programs. DCOM uses TCP/IP and HTTP, making it
capable of working across the Internet. The protocol is limited to Microsoft
platforms, however, thus diminishing its ability to serve as the foundation
of a worldwide distributed computing network.

Remote Method Invocation (RMI).
Sun Microsystems’ RMI is a Java-based RPC that can pass along multiple objects
with a single message. RMI is limited to facilitating communication among
Java-enabled programs.

Representational State Transfer (REST).
The REST architecture was first proposed by Roy Fielding in his 2000 PhD
thesis. Fielding was one of the original authors of the HTTP protocol. The key features of RESTful applications are:

  • Statelessness
    –     This
    feature is designed into RESTful apps,
    meaning that they have no reliance on knowledge of prior transactions
    between client and server. They don’t use state preservation mechanisms like
    cookies or SOAP. Each message between a browser and Web server contains all
    of the information necessary to execute a transaction, find resources, and
    provide a result.
  • Client Server
    – REST treats the browser and the
    server as separately encapsulated entities, which means that they can both
    act and evolve independently and won’t break their conversation mechanism by
    doing so.
  • Use of Resources – Resources are the preferred
    means of exchanging information about application state and behavior, and
    can be anything from HTML, media or executable code. Resources share a
    consistent interface and are addressable using an ordinary URI.

Some advantages of REST are that it closes security gaps opened by the use
of cookies, optimizes page download times because representations of
application state may be cached and reused, is vendor neutral, and reduces
the client side coding burden for application developers.

Current View

[return to top of this report]

As organizations put Web services to use in SOAs, they are finding that the path is not
completely free of obstacles. Even with the adoption and deployment of the
Web Services Security (WSS) specification, Web services’ complexities make
adoption a slow process. With the advent of SOA platforms from IBM, Oracle,
SAP, and others, many industry analysts believed that Web services were on
the verge of universal adoption. This turned out to be too optimistic an
assessment of the ability of organizations to deploy SOA infrastructures.

Enterprises Must Define SOAP Strategy. Some enterprise CIOs have seen SOAP as overly complex, which in turn makes
it both a risky and costly strategy. Today’s reality is, indeed, that an
organization cannot buy an SOA, turn it on, and go to lunch. SOAP demands an
organization have the expertise on hand both to deploy services and to
integrate them with existing applications, databases, and processes. This translates to a significant investment and staffing commitment. In order
to effectively "service orient" existing applications and networks,
expect to do the following:

  • Define
    and execute an overall SOAP strategy
  • Train
    developers to retrofit existing applications and to implement standards
  • Build
    new layers of middleware
  • Devise
    new security defenses

Continued Market Adoption and Integration. Despite these challenges, SOAP
maintains a strong presence in the web services and applications design realm.
Areas where its adoption has been welcomed include e-commerce and cloud
computing, with continued work on its application in mobile and gaming
platforms. 

While the work on the basic
SOAP standard has been completed, work continues on the specifications and
protocols that make up the body of Web Services. The latest version of the
specification is SOAP version 1.2.

[return to top of this report]

References

[return to top of this report]

1 "IBM Endpoint Manager: TEM SOAP API."
IBM. February 5, 2014.

About the Author

[return to top of this report]

Candice Block Lombardi tracks and writes about enterprise
software and security, the IT services sector, telecommunications, and data
networking. She is a frequent contributor to Faulkner’s information
services.

[return to top of this report]