Dr. Dobb's Journal July 2001
In the continuing saga of the life of a software developer in the insurance industry, our hero (that's me) has to solve problems, push the technological envelope, keep a watchful eye on maintainability, and get cooperative behaviors from all the resources and employees at his disposal.
To make all that happen, the problem I face this month is to bring together a sequence of operations on three different web servers geographically located in three different parts of the country. Each of these web servers belongs to a different business and requires a B2B2B model. In each instance, each business subscribes to Microsoft's DNA model and has a middle tier full of COM objects. In this example, I need to tie all three servers together and process a request for a forecast for a mutual fund. The forecasting component is a web service on Box B. The data for the participant is on Box A and the data for other variables needed for the economic forecast is on Box C. All three businesses constantly update your services. Thus, if a participant desires an updated forecast for his portfolio, then all he needs is for his client (a laptop) to process request data from all three web servers. Thus, the questions become: How am I going to send data from one server to another and return the forecast to the client — the participant laptop? Do I use EDI, DCOM? What if we are talking about NT and Solaris boxes? I did not wish to use port 1452 for COM objects because of security issues with the firewall and I don't want to maintain a constant data link between all three servers. Like most developers, I believe the Web is not for weekly batch updating. In addition to the aforementioned, it must be able to be seamless, invisible, and quick.
Since the servers speak HTTP, XML seemed like a logical choice to begin with. But while I've read some books on XML and have coded small applications, I've yet to use it in any real-world situation. I needed something that would let my server talk to any other server regardless of language, operating system, or middle-tier technology. How do I do this?
Enter SOAP, the "Simple Object Access Protocol," an XML grammar for making method requests over HTTP. One of XML's main strengths is in the elimination of DCOM and the utilization of the MSXML library.
To effectively use SOAP, I had to have a plan. In his article "Distributed Computing with SOAP" in Visual C++ Developers Journal, April 2000, David Marcato lists five items to consider:
Following Ken's advice, I obtained some background information from numerous web sites (including http://www.microsoft.com/ and its SOAP toolkit), then turned to the following books:
To develop anything, a blueprint of what needs to be done is necessary. Consequently, I first examined each book to get an idea of what is involved in creating a SOAP architecture and to solve my problem of communication between and among these three different servers.
In trying to design my SOAP architecture, I found Brian Travis's XML and SOAP Programming for BizTalk Servers to be problematic. While it did provide useful implementation on duck bar jokes (that I thought were a little nerdy) and how to deliver them as a web service with BizTalk 2000, the book offered me little value. Why? Because I was using Visual Basic 6, Interdev, IIS, MTS, and SQL Server as my four-tier architecture and did not wish to add OmniMark and BizTalk to the mix. Instead, I wanted to rely on Active Server Pages (ASP) for my server communication architecture. On the other hand, if I were moving from OmniMark and BizTalk, then this book would have fit my needs exactly, so I won't be overly critical with respect to this issue. Second, I could have used some more development in the SOAP chapter. Much of this book, specifically Chapters 9-12, is devoted to the topics of BizTalk and OmniMark. The reason I purchased the book was for SOAP. I was disappointed that SOAP was in the title because it was mentioned only in Chapter 7, along with BizTalk.
In Understanding SOAP: The Authoritative Solution, Kenn Scribner and Mark Stiver's main goal was to provide an introduction to SOAP and explain a representative SOAP implementation. The book was thorough in explaining the syntax and the use of SOAP (514 pages worth), but most of the code was in C++ and the examples weren't well integrated. The introduction was good and the review of distributed object technologies was very good. The chapter on implementing SOAP and the COM language binding helped me understand several nuances with respect to using and reusing C++ objects in SOAP. However, I had to piece together several chapters to get a big picture of what I was trying to accomplish in my application. Clearly, this book is written for a C++ audience and is quite extensive for a reference.
In Applied XML Solutions, Benoit Marchal provided an excellent treatment of the client/server architecture of SOAP with a useful implementation of a stock price server and client application. Although the entire book is based on Java applications and the use of servlets, it is concise, useful, and illuminating. This was probably due to my exposure and experience with Java. The organization of the book was logical and I learned more about topics such as WML, portals, and the cards concept for the presentation of data on smaller screens (like mobile phones).
In Developing XML Solutions, Jake Sturm guides you through numerous demonstrations of XML, DTD, using XML in IE 5, Microsoft BizTalk Server 2000, and how to build scalable Windows DNA-compatible systems. This book provided examples of various XML routines that were difficult to follow. I got the least amount of information on SOAP from this book.
Still, from the information contained in these books, I was able to install IE 5 on my servers so I could use the XMLDOM and the XMLHTTP methods on all three machines. I used these for the SOAP client/server relationships among the servers. Server A was set up as a SOAP server and client that called my COM objects from .asp. I then loaded the client's XML, the data from Server B that also acted as a SOAP server and client with Server C, which again acted as both server and client. So the process is such that when a URL returns an XML-encoded message to Server B, it had to be able to read it. It did by acting as a SOAP client and then responded by sending an XML-encoded message to Sever C, which then read the XML-encoded message and responded with an XML-encoded message to Server A, which sent it to the client's browser. For developing the XML and using the XMLDOM methods, I found Applied XML Solutions, Developing XML Solutions, and XML and SOAP Programming for BizTalk Servers to be useful in developing the XML application of the data transfer. Understanding SOAP: The Authoritative Solution helped with encoding the data types in XML, passing the data structures, and exception handling. Also, I liked this book's treatment of the SOAP toolkit for Visual Studio 6. Although much of the COM chapter dealt with C++, I was able to translate some of the concepts with respect to issues related to binding and reusability. In short, I recommend adding Understanding SOAP: The Authoritative Solution to the programmer's bookshelf.
I tend to be more critical these days of programming books that merely state what has already been stated elsewhere on the Web for free. Given that the audience for these books are programmers, developers, engineers, and project managers, we should expect that the reading of this subject matter does not occur in a vacuum. Thus, my first attempt at learning anything new is to visit various sites, then read articles and try to find what I need for free.
In this case, each book has something to offer apart from web sites and magazines, and can be an important enhancement to a programmer's bookshelf. In XML and SOAP Programming for BizTalk Servers, the author provides a detailed treatment of BizTalk and XML and shows how they work together for e-commerce. This is a must-read if you want to use OminMark and BizTalk. Applied XML Solutions is by far the best book of the lot, not only in terms of Java and real-world coded examples, but with respect to its discussion on the practical issues associated with SOAP architecture and implementations. Understanding SOAP: The Authoritative Solution is designed as a reference book and that is exactly where I place it. Serious SOAP implementers need to have a background in all the details, problems, and possibilities to use SOAP in their environment. Understanding SOAP: The Authoritative Solution is excellent in that regard.
All in all, I was satisfied with these books because I was able to create my SOAP prototype, which solved the problem of server communication. And so, this finishes another story of our hero from the chronicles of Days of Our Data.
DDJ