Understanding Soap: Simple Object Access Protocol

Understanding Soap: Simple Object Access Protocol

by Kenn Scribner, Mark C. Stiver, Kennard Scribner
     
 

Understanding SOAP begins with a discussion of distributed object computing, reviewing the current technologies. It then discusses the realities that make distributed object computing so difficult. Given these realities, the book provides a case study of a current technology to show why it is so difficult to distribute objects and why a protocol, such as SOAP,…  See more details below

Overview

Understanding SOAP begins with a discussion of distributed object computing, reviewing the current technologies. It then discusses the realities that make distributed object computing so difficult. Given these realities, the book provides a case study of a current technology to show why it is so difficult to distribute objects and why a protocol, such as SOAP, is such an important topic. An in-depth example gives you a working scenario of what is involved with distributed object computing and SOAP. Finally, the book discusses the future of SOAP, to include language binding and system integration. This book provides you with an accelerated approach to understanding how XML applies to distributed systems, specifically using the SOAP protocol.

Editorial Reviews

bn.com
The Barnes & Noble Review
SOAP looks like it's gonna clean up. If you're a developer who wants to make the most of it, Understanding SOAP is the jumpstart you've been looking for.

One thing that's especially welcome about this book: perspective. The authors begin by comparing SOAP to existing distributed object technologies such as CORBA, DCOM, and Java RMI, explaining how it stacks up in terms of scalability, performance, activation, state management, garbage collection, and other key criteria. You'll learn how developers have traditionally used XML to transport data between systems and how SOAP adds value through an interoperable, flexible, well-designed architecture.

The authors cover protocol transports, XML payloads, data types, remote methods, and more. They're reasonably platform-agnostic, but Understanding SOAP does contain a full chapter on the relationship of SOAP to Microsoft's BizTalk, as well as a real-world SOAP implementation (running nearly 200 pages) that intercepts Windows COM object calls and formulates SOAP resquest-response scenarios.

SOAP is thoroughly entwined with XML schemas, namespaces, and other not-quite-nailed-down XML standards. The book is candid about "why things are the way you find them today as well as how things might change in the foreseeable future" -- including potentially crucial issues, such as security and object discovery. (Bill Camarda)

Bill Camarda is a consultant and writer with nearly 20 years' experience in helping technology companies deploy and market advanced software, computing, and networking products and services. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks For Dummies®, Second Edition.

Product Details

ISBN-13:
9780672319228
Publisher:
Sams
Publication date:
07/10/2000
Series:
Sams Professional Series
Pages:
450
Product dimensions:
7.40(w) x 9.12(h) x 1.23(d)

Read an Excerpt


Chapter 1: Essential SOAP: A Comparison of SOAP to Existing Distributed Object Technologies

SOAP: (n): Hydrolysis or saponification of the sodium salt of a long chain of fatty acids.

Not anymore. There is a new SOAP on the block. The Introduction gave you an idea of what SOAP really is and why it's necessary. This chapter furthers that introductory discussion by more fully explaining SOAP's purpose, and then by comparing SOAP (as a wire protocol) to the commonly-used distributed object technologies and their wire protocols in use today.

It's important to remember that SOAP is itself a wire protocol rather than an entire distributed object architecture. On the other hand, entire distributed object architectures are designed around their wire protocols for efficiency. Some distributed object technologies concern themselves with security, for example, and carry security information within their data packets. They have mechanisms to efficiently encode the security information to speed the data's consumption on the receiving end.

Also, unlike contemporary distributed object architectures, SOAP makes use of openly available technologies that, when combined, specify a wire protocol. This protocol can be used to facilitate highly and ultra-distributed architectures. As you've seen from the introduction, SOAP commonly uses the HTTP protocol to transport XML-encoded serialized method argument data from system to system. This serialized argument data is used on the remote end to execute the client's method call on that system, rather than the client's local system.

This chapter begins by exploring the SOAP wire protocol and why such aprotocol makes sense. Then the chapter introduces the wire protocols of other contemporary distributed systems to see how they are incorporated into the overall distributed architecture. This should provide you with a good feel for where SOAP fits in relation to other systems as well as help you better understand the SOAP specification itself.

The Argument for SOAP

After reading the introduction, you might wonder why the SOAP protocol is generating so much interest. After all, it is just another Microsoft XML-based initiative, isn't it?

In truth, SOAP does have roots in Microsoft, as one of the main specification authors works for Microsoft. That said, though, SOAP is a compelling technology in its own right and was honestly developed to be vendor independent. You can see this simply by examining the two fundamental SOAP technologies-HTTP and XML. These two technologies are international standards, and although Microsoft has played a significant role in the development of several of the key XML technologies, XML is nonetheless not under Microsoft's control.

A better way to view SOAP is based upon its technical merit. SOAP is fundamentally the combination of textual information shared via the Internet. The textual information is encoded in an XML format, which has specific rules for encoding and processing. The actual transmission of the XML data is managed by the transport protocol, which is (today) commonly HTTP served by a Web server. The combination of the open XML encoding style and the pervasive HTTP protocol makes SOAP possibly the most interoperable wire protocol yet invented.

If you are using HTTP as your SOAP transport protocol, then SOAP processing is very much aligned with the Internet, which specifies a stateless programming model. That is, object clients request services from a remote entity, which in turn responds with the pertinent information. After the remote entity responds, all state information regarding that invocation is destroyed unless measures are taken to persistently store the state information for later use. Regarding SOAP, rudimentary SOAP servers also follow this basic stateless, request/response scenario. SOAP itself doesn't preclude you from implementing more exotic servers that are capable of state management and decoupled request/response pairs (as with asynchronous callbacks). This makes it easy for scripts as well as more complex applications to implement SOAP.

Heavyweight Versus Lightweight Protocols

You will find a description of several contemporary distributed object technologies in this chapter. Although the purpose of the descriptions is to afford a comparison of SOAP to other wire protocols (and complete architectures, which SOAP does not provide), keep these questions in mind as you read the descriptions:

How complex is the wire protocol for the given system, and is it an open standard?
How complex is the given system?
If you design a distributed application using the given system, what are the development costs associated with the system? For example, is it easier to hire developers who know XML/HTTP or an architecture-specific protocol like HOP or RMI?
If you design a distributed application using the given system, what are the administrative costs associated with the system when you ship your application to an arbitrary user?
Does the selection of a given system bind you to specific vendor, and, if so, can you easily migrate your application to another vendor?

One argument in favor of the SOAP protocol is that it is a tremendously lightweight protocol. That is, the protocol itself requires two fundamental capabilities:

The capability to send and receive HTTP (or other) packets
The capability to process XML

At this time, HTTP is a pervasive technology. One can hardly imagine a business that doesn't handle HTTP data, at least if it interacts with the Internet in any meaningful fashion. At the very least, HTTP processing is well understood and widely implemented...

Meet the Author


Kennard Scribner started out managing a pizzeria, but when he found out he could make less money and work harder in the Air Force, he immediately signed up and was whisked away to foreign lands, starting with Omaha, Nebraska. (Don't let him fool you; he loved it there.) After earning a commission and several assignments later, Kenn left the Air Force to pursue his hobby of Windows programming as a full-time measure. Now Kenn finds himself teaching COM and implementing COM technology as he journeys around the town helping others get their projects off the ground. Along the way, he started The EnduraSoft Corporation to write and market ActiveX controls, although these days he's spending more time writing words than code! Kenn is the author and coauthor of several books, including Sams Teach Yourself ATL Programming in 21 Days and MFC Unleashed. You can reach Kenn at kenn@endurasoft.com.

Mark C. Stiver is a consulting software engineer with one of the world's largest supplier of information services for the legal and business industry. He has more than 11 years of experience working on a wide variety of commercial, industrial, and military software development projects. Recently he completed a two-year effort, developing an n-tier, distributed product using XML as the base protocol to integrate Windows desktop, Windows NT Server, and UNIX applications. Currently, he is involved in the design and development of XML-based interfaces for integrating with large-scale systems.

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >