SOAP: Cross Platform Web Service Development Using XML

SOAP: Cross Platform Web Service Development Using XML



Product Details

ISBN-13: 9780130907639
Publisher: Pearson Education
Publication date: 08/17/2001
Series: Pearson Temp Net Series
Edition description: BK&CD-ROM
Pages: 391
Product dimensions: 7.00(w) x 9.27(h) x 1.12(d)

About the Author

Scott Seely has written extensively on Windows and UNIX/Linux programming, as well as on C, C++, and Visual C++, and he has recently joined Microsoft. He is author of Windows Shell Programming (Prentice Hall PTR).

Read an Excerpt

Chapter 1: How We Got To SOAP

To understand why we need a technology such as the Simple Object Access Protocol (SOAP) we need to spend a bit of time looking at how computing technology has evolved. SOAP itself started out as a way to make distributed computing platform agnostic. We have always had the concept of distributed computing. The idea of having people perform calculations that they are good at and then handing the work off to other mathematicians is nothing new. For example, logarithms take a long time to compute. Because of this, people wrote out and reproduced logarithmic tables for other mathematicians to use.

To review the history, I would like to take a look at the things we have done in moving from the abacus to mechanical calculators and then to distributed computing. Understanding (or simply reviewing) this history gives some perspective of where we have come from and highlights why so many people are excited about SOAP. The idea of ubiquitous computing is moving from being just a neat idea to a reality. SOAP provides a way for all those computers to talk to each other and request services of each other. Indulge me as I present a little history lesson showing where our pursuit of automated number crunching has taken us.

The Abacus

The abacus has been used as a calculator for thousands of years, and you can still find it in use in China, Japan, and the Middle East. The most common form of the abacus can register numbers from 1 to 9,999,999,999,999.1 The abacus does this using 13 rows of beads as shown in Figure 1-1. The user of an abacus reads the numbers from the beads touching the center bar. Each bead touching the center bar on the bottom half of the abacus equals one times the units column. Each bead touching the center bar from the top half of the abacus equals five times the units column. Figure 1-2 shows how you would represent the number 23.

The abacus shines when adding and subtracting numbers. Practiced users can usually outpace a person using a modern adding machine. As users add the second number in, they slide the beads up and down. Every time all five bottom beads touch the center bar, one bead from the same column on the top bar must come down. Then, all five beads must be returned to the bottom again. Likewise, if both top beads touch the center bar these beads must moved away from the center bar and one bottom bead from the next highest rank gets moved up. Figure 1-3 shows how one would execute 7 + 23 and reconcile that to 30. To subtract 7 from 30 and get 23 you would reverse the process.

Does that all make sense to you? Here is another way to look at the abacus. For this example, we use people and their fingers instead of beads to build a human abacus. After all, the abacus is based on this same idea. The bottom five beads represent the five fingers on a hand. The top two beads represent two hands. Each "hand" equals five "fingers." We use our human abacus like this: When all the fingers on one hand fill up, we start counting on the other hand. When the person in the ones column gets to 10, that person sets their fingers to zero and the person in the tens column remembers one on their hands (by raising one finger). This counting continues through the ranks until the capabilities of the fingers in the abacus are used up.

Because of the abacus's ability to aid in addition and subtraction, the tool has endured for a long time. Due to its construction it does not handle multiplication and division very well. Multiplication essentially involves adding the numbers over and over again (25 * 4 = 25 + 25 + 25 + 25). Division is also possible but time consuming. Not surprisingly, the abacus does not help us do any serious number crunching. It does allow for distribution of computing tasks. You may ask two or more people to manipulate the same series of numbers just to verify that the results are correct. Alternatively, you can also split up large computations among many people who have an abacus. As we know now, there are faster ways to perform computations. Let's take a look at one of the first attempts to speed things up.

Early Calculators

As we learned more and more about the world around us, we learned more about the mathematical relationships in nature. All of this math created a need for tools that could assist in performing calculations. Around 1600, Galileo began to incorporate mathematics with his observations of the physical world. For example, he noticed that objects fell to the earth at the same rate regardless of their weight. A marble will hit the ground in the same time it takes a cannon ball to travel the same distance. Figuring out the mathematics describing the various phenomena he observed created a need for new tools. For his own work, Galileo invented a number of different compasses.

Galileo was not the only person figuring out the mathematics of nature. History credits John Napier with the invention of logarithms. He published his initial work on them in 1614. Logarithms are useful for quick multiplication and division, but it takes a long time to compute logarithms manually. To save time, Napier invented a device called Napier's Bones, the predecessor of the slide rule. This tool proved to be very difficult to use and as a result, people looked for new, better ways to do the same thing. Seven years after Napier published his first paper on logarithms, William Oughtred gave us the slide rule in 1621. This tool remained a standby for students of mathematics until the calculator became affordable during the 1970s....

1 This particular form of abacus has 13 rows. As a rule, an abacus can handle smaller or larger numbers depending on its construction. Smaller numbers need fewer rows-you could handle numbers through 9,999 with 11 four-row abacus. For each power of 10 that you want to handle, just add another row.

Table of Contents



1. How We Got to SOAP.
The Abacus. Early Calculators. Programmable Machines. Electronic Computers. Distributed Computing. Summary. Bibliography.

2. XML Overview.
Uniform Resource Indentifiers. XML Basics. XML Schemas. XML Namespaces. XML Attributes. Summary.

3. The Soap Specification.
Things to Know. Rules for Encoding Types in XML. The SOAP Message Exchange Model. Structure of a SOAP Message. Using SOAP in HTTP. Using SOAP for RPC. Summary.

4. Building a Basic SOAP Client and Server.
SOAP Library Design. In Search of One Good Socket Library. SimpleSOAP Library. SOAPNetwork Library. A Simple SOAP Server. A Simple SOAP Client. Summary. Fun Things to Try.


5. Web Services Description Language.
WSDL Overview. Defining a Web Service. SOAP Binding. HTTP GET and POST Binding. MIME Binding. Summary.

6. Universal Description, Discovery, and Integration.
UDDI Basics. Where Does UDDI Fit In? UDDI Information Types. The Programmer's API. Summary.

7. Available SOAP Implementations.
Apache. IdooXoap. Iona. Microsoft. pocketSOAP. RogueWave. SOAP: : Lite. White Mesa. Zope. Summary.


8. Auction System and Requirements.
Background. Executive Summary. Bidder Enrollment and Management. Item Enrollment and Management. The Bidding System. Reporting. Summary.

9. Auction System Design.
Bidder Enrollment and Management. Item Enrollment and Management. The Bidding System. Summary.

10. Bidder Enrollment.
The Java Environment. Setting Up the Java Enviroment. Securing Accessto the Web Service. The VB Environment. Summary.

11. Category and Item Management.
General Implementation Rules. Category Management. Item Management. Summary.

12. The Bidding System.
Bidding Pages. Bidding Web Service. Summary.

13. Case Study Summary.
Client Management. Category Management. Item Management. Auction. Summary.




As long as there have been two computers, there has been difficulty getting them to communicate. Dozens, possibly hundreds, of strategies have arisen, each with their own strong and weak points. However, the end result is that still, it is difficult to get two computers to agree on a strategy for communication. Everyone wants everyone else to change to meet their strategy's needs. Thus, we end up with the "Communication Wars," CORBA vs. DCOM, DCOM vs. RMI, messaging vs. RPC, and so on.

Into this tangled mass of communication comes SOAP (Simple Object Access Protocol). SOAP does not try to solve all problems; it only defines a simple, XML-based communication format. However, with this simple goal, and a powerful extensibility mechanism, SOAP bears the promise of being a true cross-everything communication protocol-cross-programming language, cross-operating system, cross-platform. As long as a computer, operating

system, or programming language can generate and process XML (that is, text), it can make use of SOAP. Since the initial release, almost every major software vendor has either produced, or announced, an implementation of SOAP. We've seen standalone SOAP, SOAP built into Web servers, application servers, communication tools and even messaging middleware using SOAP. In the future, SOAP will become even more prevalent, as companies and organizations like Microsoft, IBM, Apache, and Sun add even more SOAP support to their applications, operating systems and programming languages.

As the SOAP specification winds its way through the W3 standardization process, I'm certain that we will see changes. However, please don't let this stop youfrom experimenting and using SOAP in your applications. Yes, there will be changes, but these should be relatively minor, and each implementation should hide many of these details.

I first "met" Scott because of a mailing list—DevelopMentor's excellent list devoted to SOAP discussions ( if you're interested in joining). There he tirelessly helped others understand what he obviously thought as an important technology. Therefore, I was glad to hear that he was also working on this book. He has packed a great deal of practical development advice into these pages. I also love the fact that he shows a variety of the implementations available, and that they are all communicating nicely.

I hope that as you read this book, you see why Scott and I think SOAP is so important. So, whether you are a Java developer using the Apache implementation of SOAP, a VB developer using the Microsoft SOAP Toolkit, or a C# developer using .NET Web Services, or one of the many other implementations available, I hope that you join us in using SOAP in your applications. Perhaps together we can all learn to communicate.

— Kent Sharkey
.NET Frameworks Technical Evangelist
Microsoft Corporation

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews