![They were fond of dividing the thickness, and increasing the
apparent intricacy, by giving to each half a different ramification;
making for instance two sets of mullions and tracery in one opening,
one before the other, and totally without correspondence.[8]
They
divided the mouldings into separate parts, and placed those of their
bases at different heights, one set of vertical mouldings passing
between the bases of other vertical mouldings, and the bases of
these again, are interrupted by the high plinths of the former bases,
as if each penetrated the solid stone, and reappeared again where
that did not cover it; many of these fancies are evidently taken from
basket work.
The remaining fragment of the church of St. John the Baptist at
Soissons, belongs to this style, and the new tower and spire at
Chartres form a most beautiful specimen. The shrine work that
surrounds the choir at Chartres is also an exquisite miniature
example, which I shall mention more particularly hereafter. At about
two leagues from Chalons, at a small village called L’Épine, is a little
church of the fourteenth century. One tower only has been
completed, and crowned with an elegant spire; but had the front
been finished, it would offer perhaps the most beautiful specimen of
Gothic external composition in the world. The arch of the doorway is
large; even more so than the usual proportion in French churches,](https://image.slidesharecdn.com/12734-250311151027-c6b2c230/85/Special-Edition-Using-SOAP-Special-Edition-Using-John-Paul-Mueller-51-320.jpg)
![The church of St. Germain des Prés claims to be the oldest in
Paris.[9]
The first edifice was begun by Childebert in 557, and finished
in 558, a degree of expedition which does not announce much
magnificence; yet we are told that it was in the shape of a cross,
and that the fabric was sustained by large marble columns, the
ceiling was gilt, the walls painted on a gold ground, the pavement
composed of rich mosaic, and the roof externally covered with gold.
This description is by Gislemer, a monk of the abbey, who lived at
the end of the ninth century, after the church had been twice burnt
by the Normans; and perhaps it rather gives us the author’s opinion
of what a church ought to be, than what this once was. The building
however does not appear to have been totally destroyed, since
Morard, who became abbot in 990, perceiving that the repairs since
its ruin by the Normans, had been hastily and slightly executed,
determined to pull it down entirely and rebuild it; and he is said to
have had the satisfaction of completing it, nearly as it exists at
present, before his death, which happened in 1014. We learn from
the inscription which was formerly legible on his tomb, that he
added to the church a tower, containing a bell (signum): this
addition may seem to throw some doubt on the extent of the works
executed by him. A dedication took place in 1163, but we cannot
suppose the building stood complete and useless for all that period.
The old cloister was taken down in 1227, and another begun and
finished in the course of the same year by Eudes, the abbot. A new
refectory was commenced in 1236, and in 1244 the great chapel of
the Virgin was undertaken. These were executed from the designs of
Pierre de Montereau, and are cited as proofs of his exquisite taste
and skill. The Chapter House, and a beautiful chamber which
adjoined it, were constructed about the same time, and the
dormitory over them in 1273; but all these parts have been
destroyed during the revolution. A new cloister was erected in 1555,
but in 1579 the church is described as being much out of repair, and
though some restorations and alterations were made in 1592, yet in
1644 it was in a most dilapidated and dangerous condition. The nave
was covered with the fragments of the ceiling, and in parts with the
tiles of the roof; the pavement was so sunk, that it was necessary to](https://image.slidesharecdn.com/12734-250311151027-c6b2c230/85/Special-Edition-Using-SOAP-Special-Edition-Using-John-Paul-Mueller-53-320.jpg)
![descend to it by steps; and the vaulting of the transept threatened
to fall in. The whole of these deficiencies were repaired in the course
of two years, the vaulting of the transept was renewed, and the
nave for the first time vaulted with stone. The pillars were
ornamented with composite capitals, some of the windows enlarged,
a new doorway opened to the south, and an alteration made in the
disposition of the choir, which seems to have been the only part of
the fabric which had been kept in sufficient repair. As it now stands
the church is not a very large one. The inside is low and gloomy;[10]
in the nave and part of the choir, the piers consist of four half
columns attached to a square pillar, the vaulting of the nave is
slightly pointed, but the known recent date of this part renders its
form of little consequence, nor is that of the choir of much more
historical value. The piers of the chevet are cylindrical. All the
arching is round, except that of the chevet, where the French and
Whittington say it was pointed from necessity; but this is not very
evident: the openings are smaller, but this is not the only way of
carrying the arches to the same height. This may be done in the first
place by making a Gothic arch formed from two centres, with a
larger radius than the semicircular arches, (a pointed arch with the
same radius would not rise so high) or with an arch from two
centres, and the same radius on a base somewhat more elevated, or
lastly, by a semicircular arch on a much more elevated base. The
following diagram will explain this better than words.
To judge by the eye, the arches of St. Germain des Prés lie nearly in
the middle between the second and third, i. e. between b and c. The
base is considerably elevated by a perpendicular line continued
above the capital, and the radius of the curve is smaller than that of](https://image.slidesharecdn.com/12734-250311151027-c6b2c230/85/Special-Edition-Using-SOAP-Special-Edition-Using-John-Paul-Mueller-54-320.jpg)
![whole edifice, but only under the chapels and side aisles. The people
in this neighbourhood are more unfavourably disposed towards the
Bourbons than those who live to the east of Paris. A woman
observed that I was one of those who had brought back Louis XVIII.
She had nothing to say against them or him, but the tones of her
voice did not promise that she would say any thing for either. The
conducteur of the diligence perhaps was not a Napoleonite.
“Whether God or the devil, Napoleon or Louis XVIII. be on the
throne,” he observed, “the laws should be obeyed. There were
revolutions in France before this, of which they talk so much; for
instance, in the times of Charles V., who drove the English out of
France; and if the French were now as devoted to their country as
they were then, these things could never have happened.” I could
not be displeased with any Frenchman for a feeling of soreness at
the interference of foreigners in the affairs of his country, however
political circumstances may have required it.
The two churches last described, and that of Nôtre Dame at Paris,
may be considered as belonging to a style of Gothic, intermediate
between the first and second of those I have enumerated; and as I
wish to give you a sort of historical series elucidating the progress of
architecture, I shall here introduce some account of the French
metropolitan edifice. This is said to have been originally founded by
Childebert, in 522. It had 30 marble columns, and very large
windows, according to the account left us of it by Fortunatus, a
cotemporary poet.[11]
This description, however, has nothing to do
with the present building, which was commenced in 1010 by Robert
the Pious. After his death it was neglected, and little was done till
1165, when Maurice de Sully, a liberal and munificent prelate, filled
the see of Paris, and to him we seem to have been indebted for the
greater part of the edifice. He destroyed the old church of
Childebert, which had existed till this period; and in the year 1181
the eastern part was so far advanced, that it was consecrated by
Henry, the Pope’s legate, and by the bishop himself, who died the
next year. Odo de Sully succeeded, and prosecuted the work with
great zeal till his death in 1208, so that for forty-three years from](https://image.slidesharecdn.com/12734-250311151027-c6b2c230/85/Special-Edition-Using-SOAP-Special-Edition-Using-John-Paul-Mueller-74-320.jpg)
Special Edition Using SOAP Special Edition Using John Paul Mueller
- 1. Instant Ebook Access, One Click Away – Begin at ebookgate.com Special Edition Using SOAP Special Edition Using John Paul Mueller https://ebookgate.com/product/special-edition-using-soap- special-edition-using-john-paul-mueller/ OR CLICK BUTTON DOWLOAD EBOOK Get Instant Ebook Downloads – Browse at https://ebookgate.com Click here to visit ebookgate.com and download ebook now
- 2. Instant digital products (PDF, ePub, MOBI) available Download now and explore formats that suit you... Special edition using Microsoft Windows Vista Robert Cowart https://ebookgate.com/product/special-edition-using-microsoft-windows- vista-robert-cowart/ ebookgate.com Special Edition Using TCP IP Niit (Usa) Inc. https://ebookgate.com/product/special-edition-using-tcp-ip-niit-usa- inc/ ebookgate.com Special Edition Using Microsoft Office PowerPoint 2007 Patrice-Anne Rutledge https://ebookgate.com/product/special-edition-using-microsoft-office- powerpoint-2007-patrice-anne-rutledge/ ebookgate.com Special Edition Using the Internet Fourth Edition Table of Contents Unknown https://ebookgate.com/product/special-edition-using-the-internet- fourth-edition-table-of-contents-unknown/ ebookgate.com
- 3. RibbonX For Dummies John Paul Mueller https://ebookgate.com/product/ribbonx-for-dummies-john-paul-mueller/ ebookgate.com Mapping Hazardous Terrain using Remote Sensing Geological Society Special Publication No 283 1st Edition R. M. Teeuw https://ebookgate.com/product/mapping-hazardous-terrain-using-remote- sensing-geological-society-special-publication-no-283-1st-edition-r-m- teeuw/ ebookgate.com CSS3 for dummies 1st Edition John Paul Mueller https://ebookgate.com/product/css3-for-dummies-1st-edition-john-paul- mueller/ ebookgate.com Artificial Intelligence For Dummies 2nd Edition John Paul Mueller https://ebookgate.com/product/artificial-intelligence-for-dummies-2nd- edition-john-paul-mueller/ ebookgate.com Special Teaching For Special Children Pedagogies For Inclusion Lewis https://ebookgate.com/product/special-teaching-for-special-children- pedagogies-for-inclusion-lewis/ ebookgate.com
- 5. Contents at a Glance Introduction 1 An Overview of SOAP 11 2 SOAP in Theory 33 3 An Overview of Security Issues for SOAP 61 4 Using SOAP to Create a Simple Application 81 5 Migrating an Application from DCOM to SOAP 121 6 Creating Remote Access Utilities 161 7 Creating Data Entry Forms and Surveys 195 8 Providing Remote Database Access 237 9 Moving to Web-based Applications 283 10 Working with PDAs 321 Appendixes A SOAP Data Types and Data Type Conversions 345 B Microsoft Biztalk and SOAP 355 C Third-Party Tool Reference 371 D SOAP for Visual C++ Developers 389 Glossary 407 Index 427 Using SOAP John Paul Mueller 201 W. 103rd Street Indianapolis, Indiana 46290
- 6. Special Edition Using SOAP Copyright 2002 by Que All rights reserved. No part of this book shall be repro- duced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the pub- lisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for dam- ages resulting from the use of the information contained herein. International Standard Book Number: 0-7897-2566-5 Library of Congress Catalog Card Number: 2001090465 Printed in the United States of America First Printing: September, 2001 04 03 02 01 4 3 2 1 Trademarks All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capi- talized. Que cannot attest to the accuracy of this informa- tion. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. Warning and Disclaimer Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an “as is” basis. The author and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information con- tained in this book. Associate Publisher Dean Miller Executive Editor Candace Hall Acquisitions Editor Michelle Newcomb Development Editors Sarah Robbins Maureen McDaniel Managing Editor Thomas F. Hayes Project Editor Karen S. Shields Copy Editors Karen Gill Kay Hoskin Indexer Johnna Dinse Proofreader Marcia Deboy Technical Editor Russ Mullen Team Coordinator Cindy Teeters Media Developer Michael Hunter Interior Designer Ruth Harvey Cover Designers Dan Armstrong Ruth Harvey Page Layout Tricia Bronkella Rebecca Harmon Cheryl Lynch
- 7. Contents Introduction 1 1 An Overview of SOAP 11 What Is SOAP? 13 How SOAP Differs from DCOM and CORBA 15 DCOM Wire Protocol 15 CORBA IIOP 19 Java RMI 20 SOAP, HTTP, and XML 22 Problems Solved by Using SOAP 24 Performance Issues 26 Tradeoffs of Using SOAP 26 When SOAP Is Faster 27 SOAP and the Web Server 28 Why Make the Move to SOAP? 28 Case Study 29 Definition of a Problem 29 Light at the End of the Tunnel 30 Perfection, an Ongoing Process 30 2 SOAP in Theory 33 Dissecting the SOAP Message 35 Viewing the HTTP Portion of SOAP 37 Viewing the XML Portion of SOAP 38 Working with the SOAP Message 39 Using SOAP with Your Current Code 45 Discovering SOAP Services 47 Understanding Discovery of Web Services (DISCO) 48 Working with the Web Service Description Language (WSDL) 48 Understanding Universal Discovery, Description, and Integration (UDDI) 49 Putting Everything Together 50 Using SOAP to Move Data 52 Current SOAP Implementation Problems 53 SOAP and XML-RPC 56 SOAP and XML Protocol (XMLP) 56 Understanding SOAP Attachments 57 Case Study 58 3 An Overview of Security Issues for SOAP 61 Introduction 62 Understanding SOAP Privacy and Security Issues 63 What Are the Issues? 64 User Privacy Issues 65 Data Security Issues 66 Security Standards You Should Know About 67 HTTP Authentication Framework 71 Secure/Multipurpose Internet Mail Extensions (S/MIME) 73 Secure Socket Layer (SSL) 74 User Identification Issues 75 Using Smart Cards 75 Using Biometrics 76 Where Do You Go from Here? 77 Case Study 78
- 8. 4 Using SOAP to Create a Simple Application 81 Introduction 82 An Overview of Microsoft’s SOAP Toolkit 83 Toolkit Features 84 Three Types of Microsoft SOAP Toolkit Application 86 Problems You’ll Experience 87 Using the Microsoft SOAP Toolkit 90 An Overview of the Application 98 How SOAP Applications Differ 98 Basic Application Design and Data Flow 99 Understanding the Simple Application in This Chapter 100 Shortcuts for Creating SOAP Applications Quickly 100 Understanding Namespaces, the Short Version 102 Creating the Server Side Code 104 Designing the Component 104 Designing a Listener 105 Creating the Client Code 106 Testing the SOAP Application 109 Checking the Example Application for Errors 110 SOAP Testing Tips 112 Testing Your Server 113 Handling SOAP Errors 116 Performance Concerns for all Applications 117 Attributes Versus Elements 118 Code Optimization 119 Project 120 Special Edition Using SOAP iv 5 Migrating an Application from DCOM to SOAP 121 Introduction 122 SOAP Application Conversion Prerequisites 123 An Overview of the Conversion Process 123 Deciding Which Application Modules to Change 126 Avoiding Protocol-Related Problems in Modified Applications 129 Integrating New Modules with Existing Application Elements 134 Implementing SOAP with COM Language Binding 136 Productivity Tips 137 Updating a Simple Utility Program 140 Updating the Server-Side Component 141 Creating the Local Component 142 Updating the Standard Client 144 Updating a Data Viewer 145 Understanding the Importance of Three-Tier Programming 146 Updating the Common Business Logic Component 147 Separating the Data Viewing Logic from the Main Database Component 148 Creating the Data Viewer Client 151 Updating a Complete Database Application 153 Modified Application Concerns 155 Reliability 156 Security 157 Performance 158 Troubleshooting 159
- 9. 6 Creating Remote Access Utilities 161 Introduction 162 An Overview of Remote Access Utilities 162 Uses for Remote Access Utility Applications 163 Understanding the Web Services Difference 165 When Is SOAP Overkill? 166 Making Utility Programs Flexible 167 Shortcuts for Using Existing Components with Utilities 168 Utility Program Security Issues 169 Non-Issues for Utility Programs 170 Writing a Server Status Viewer 172 Creating the Server-Side Component 173 Tips for Working with Server Status Information 177 Working with the ISAPI Listener 179 Creating the Client 181 Creating a Simple Employee Check-In Application 182 Creating the Component 183 Some Caveats About WSDL Files 188 Creating the Client 190 Testing the Application 191 Project 193 Creating Your Own Utility 193 Upgrading the Server State and User Check-In Utilities 194 7 Creating Data Entry Forms and Surveys 195 Determining Which Data Entry Vehicle to Use 197 Shortcuts for Data Entry and Survey Applications 199 Reducing the Number of Round Trips 199 Choosing Document or RPC Style WSDL Files 200 Empty and NULL Value Processing 202 Unregistering Your Control 203 Understanding CDATA Sections 204 Understanding XML Document Transmission Restrictions 204 Using a Third-Party Product to Document Your Components 206 Creating a Simple Survey Form 208 Creating the Database 210 Creating the Server-Side Component 210 Designing a Survey Form 212 Testing the Input Application 214 Writing an Analysis Component 216 Designing an Output Application 218 Survey Application Data Processing Concerns 221 Testing the Output 221 Creating a Simple Data Entry Form Application 221 Creating the Database 223 Designing the Server-Side Component 223 Creating a Data Entry Client 225 Testing the Data Entry Application 227 Security, Privacy, Performance, and Reliability Issues 227 Security 228 Privacy 229 Performance 230 Reliability 231 Handling Data Entry and Survey Form Errors 232 Using Templates for Quick Forms 233 Using MIME for SOAP Applications 234 Special Considerations for MIME Messages 234 Where MIME Support Is Going 235 Project 236 v Contents
- 10. 8 Providing Remote Database Access 237 Remote Database Application Uses and Concerns 239 Concerns 240 Common Uses Based on SOAP Limitations 242 Developer Shortcuts for Remote Database Applications 243 Using Complex Data Types 245 Understanding the Problem 245 Understanding WSDL Generator Differences 247 Describing the Interface 249 Creating the Server-Side Component 251 Creating the Remote Client 252 Testing the Complete Data Type Application 254 Defining the SQL Server Database 255 Creating the Server-Side Component 255 Tips for Working with Database Components 256 Working with SQLXML 257 Using Multiple Server-Side Components 258 Generating the Code 259 Creating a Middle-Tier Component 263 Creating the Client-Side Application 267 Testing the Application 272 Quick Fixes for Remote Database Applications 274 Loss of Connection 275 Odd Data Entry Errors 275 Performance Issues 276 Server Is Busy or Missing Objects 277 Addressing Transaction Issues 278 Special Edition Using SOAP vi Troubleshooting 279 How Do I Detect SOAP-Related Database Errors? 279 Are the Database Shortcomings of SOAP Permanent? 280 What Are the Top Ten Issues for SOAP Database Developers? 280 9 Moving to Web-Based Applications 283 Uses for Web-Based Applications 285 Overcoming Problems with Web-Based Applications 287 Updating a Thick Client Application for Thin Client Use 289 Generating Proxy Classes the Easy Way 290 Using Thick and Thin Clients Simultaneously 291 Creating the Server-Side Component 292 Creating the Processing Component 295 Designing the Thick Client Application 297 Designing a Thin Client Form View 298 Designing the Thin Client Web Page 299 Creating a Live Data Application 302 Handling Web-Based Application Errors 303 Handling Connection Loss 304 Scripting Errors 304 Component Security Problems 305 Service Is in Use 305 ActiveX Component Can’t Create Object 306 Nothing Happens or Strange Error Message 307
- 11. vii Contents Security Issues for Web-Based Applications 307 An Overview of the Potential Security Solutions 309 Using SSL 311 Using IBM Web Services Toolkit 311 Quick Fixes for Memory and Other Resource Problems 312 Component Interactions 313 Benefits of the Script Debugger 314 Human Language Support 316 ASP and Component Communication 316 Component Doesn’t Support Locale Error 317 Case Study 317 An Overview of the Problem 317 The Solution 318 The SOAP Connection 319 A Negative to Consider 319 10 Working with PDAs 321 Special Needs for PDAs 323 The Case for PDAs 323 Special Add-ons 324 Networking 325 Operating System 325 Getting SOAP for Your PDA 326 pocketSOAP 327 IdooXoap 328 kSOAP 328 Updating the Complex Type Example 329 Creating the Client Code 329 Differences in Implementation 331 Testing the Application 331 Updating the Computer Name Example 332 Creating the Code 333 A Look at the Message Traffic 335 Server Differences Revisited 337 Testing the Application 338 Addressing PDA Display Issues 338 Screen Size 339 Using Color 340 Pointer Pointers 340 Beyond PDAs to Telephones 341 Understanding PDA Security Issues 341 Troubleshooting 343 Why Does the Example Seem to Run, and Then Display Nothing Onscreen? 343 Why Doesn’t My Code Run Properly on All of My PDAs? 344 How Do I Fix Messaging Problems with the Client? 344 A SOAP Data Types and Data Type Conversions 345 Data Types Overview 346 Complex Data Types 349 Differences in Implementation 351 Data Type Conversions 353 B Microsoft BizTalk and SOAP 355 What Is BizTalk? 357 How BizTalk and SOAP Work Together 358 An Overview of Useful BizTalk Utilities for SOAP 359 BizTalk Editor 359 BizTalk Mapper 363 BizTalk Orchestration Designer 365 BizTalk Fixes a Few SOAP Problems 368 Is BizTalk the SOAP Add-On for Your Company? 369
- 12. An Overview of the Application 394 Creating the Server-Side Component 395 Generating a Static WSDL File 395 Developing the Server-Side Component Code 396 Making the CONFIG.XML Entry 399 Creating the Client 400 Initial Setup 400 Adding the Code 401 Handling SOAP Errors 404 Glossary 407 Index 427 Special Edition Using SOAP viii C Third-Party Tool Reference 371 Finding the Right Tools 372 Tools That Make You Productive 372 Tools That Fix Problems 373 Masker 2.0 374 MZTools Add-In for Visual Basic 376 psWSDL Wizard 381 tcpTrace 383 XML Spy 384 Typical File Views 385 Viewing Data in More Than One Way 386 Special Features 388 D SOAP for Visual C++ Developers 389 Introduction 390 An Overview of the 4S4C SOAP Toolkit 391 Features 391 Installation 393
- 13. About the Author John Mueller is a freelance author and technical editor. He has writing in his blood, hav- ing produced more than 50 books and more than 200 articles to date. The topics range from networking to artificial intelligence and from database management to heads-down programming. Some of his current books include several COM+ developer guides, a small business and home office networking guide, and a Windows 2000 Performance, Tuning, and Optimization book. His technical writing skills have helped more than 25 authors refine the content of their manuscripts. John has provided technical editing services to both Data Based Advisor and Coast Compute magazines. He has also contributed articles to maga- zines like SQL Server Professional, Visual C++ Developer, and Visual Basic Developer. When John isn’t working at the computer, you can find him in his workshop. He’s an avid woodworker and candle maker. On any given afternoon, you can find him working at a lathe or putting the finishing touches on a bookcase. One of his newest craft projects is glycerin soap making, which comes in pretty handy for gift baskets. You can reach John on the Internet at JMueller@mwt.net. John is also setting up a Web site at http://www.mwt.net/ ~jmueller/. Feel free to take a look and make suggestions on how he can improve it. One of his current projects is creating book FAQ sheets that should help you find the book informa- tion you need much faster.
- 14. Dedication This is my 50th book, so I spent time considering everything that has gone on during the past 13 years. So many people have helped me that listing them here would consume many pages. Authors require help from those around them. They not only require technical help, but also help with other issues such as the daily needs that we all have. I dedicate this book to all of those tireless helpers who have meant so much to me over the years. I wish that I could list all of you on this page. Acknowledgments Thanks to my wife, Rebecca, for working with me to get this book completed. I really don't know what I would have done without her help in proofreading my rough draft. She also helped research, compile, and edit some of the information that appears in this book. Russ Mullen deserves thanks for his technical edit of this book. Russ greatly added to the accuracy and depth of the material you see here. In addition, he spent many hours working with me through e-mail to find solutions to some of the problems that SOAP presented, and he's responsible for providing many of the Web-site addresses sprinkled throughout the book. Russ went even further in this book; he spent hours finding just the right equipment to use when performing his technical edit. I can never sufficiently express my thanks to him. As you read this book, you'll see mentions of many third-party products and in-depth looks at products from major vendors. The SOAP community provided much of this information through conversation and by checking the technical accuracy of both code and theory. I'd like to thank everyone, but space won't allow me to mention them all. However, I would like to mention that the people on the Developmentor list server and the Microsoft SOAP newsgroups were exceptionally helpful. Some special people stand above the rest. Simon Fell helped me in many areas, including the complex type and PDA examples. He also helped with the products he develops and supports, including 4S4C and pocketSOAP. Roger Wolter helped in many of the Microsoft SOAP Toolkit examples. He read and commented on many of the theory sections of the book. Paul Kulchenko discussed MIME and SOAP attachments with me, among other top- ics. Karen Watterson provided several tips for the book and pointed me toward some of the third-party products. Rosimildo DaSilva taught me about SOAP and embedded systems. Yasser Shohoud helped me understand the problems with user-defined type support in SOAP toolkits. Birgit Reidinger helped me with XML Spy and discussed some compatibil- ity issues with me. Ahmad Baitalmal provided me with a glimpse of a completely functional SOAP application that appears as one of the case studies in this book. He reviewed and helped me refine the case study so that you could read about a real-world application in action. Jacek Kopecky provided me with information about IdooXoap and discussed PDA issues with me.
- 15. Every book begins with a good outline and proposal. I would like to thank the following reviewers for their help in getting this book off to a good start: Clemens Vasters, Jeremiah Talkar, Ken Rabold, Madhu Govinda, Rob Caron, and Alek Aslom. All of these reviewers provided solid comments that affected the final content of the book and my approach in discussing certain topics. Matt Wagner, my agent, deserves credit for helping me get the contract in the first place and taking care of all the details that most authors don't really think about. I always appreci- ate his help. It's good to know that someone wants to help. Finally, I would like to thank Candace Hall, Michelle Newcomb, Sarah Robbins, Karen Shields, Maureen McDaniel, and other members of the Que staff for their assistance in bringing this book to print. Writing a book about SOAP presented many logistical chal- lenges, and I appreciate their willingness to give me the time required to put a good book together. Que was also kind enough to provide me with a Palm to use in the PDA section of this chapter.
- 16. Tell Us What You Think! As the reader of this book, you are our most important critic and commentator. We value your opinion and want to know what we're doing right, what we could do better, what areas you'd like to see us publish in, and any other words of wisdom you're willing to pass our way. As an associate publisher for Que, I welcome your comments. You can fax, email, or write me directly to let me know what you did or didn't like about this book—as well as what we can do to make our books stronger. Please note that I cannot help you with technical problems related to the topic of this book, and that due to the high volume of mail I receive, I might not be able to reply to every message. When you write, please be sure to include this book’s title and author as well as your name and phone or fax number. I will carefully review your comments and share them with the author and editors who worked on the book. Fax: 317-581-4666 Email: feedback@quepublishing.com Mail: Associate Publisher Que 201 West 103rd Street Indianapolis, IN 46290 USA
- 17. INTRODUCTION In this chapter What's in This Book 3 On the Web 6 Intended Audience 7 Equipment Used for This Book 7 Conventions Used in This Book 8
- 18. 2 Introduction It is difficult to get some types of applications to work on the Internet because of the lack of technologies that can move data from one point to another safely and with few technical problems. In addition, developers need a single standard for transferring data that will work on all operating system platforms. The need for a single solution for data transfer is becom- ing apparent as financial institutions begin moving their operations to the Internet. Recently, credit card companies began actively promoting their Web site as a better alterna- tive for customer support than calling on the telephone. Many trade journals have also had stories of major financial institutions making the move to the Internet. DCOM and CORBA, the two most popular technologies currently in use, have a myriad of technical problems, including lack of operating system platform independence. The fact that many Web servers with firewalls won’t work with either technology only complicates matters. In addition, the use of two technologies means that developers end up working twice as hard to get their distributed applications to work. Clearly, developers require a new data transfer technology, and I believe that technology will be the Simple Object Access Protocol (SOAP). SOAP is based on XML and allows data transfer through firewalls with a minimum of problems. Because SOAP is XML-based, developers find that it suffers few platform-related problems. (Of course, compatibility is always an issue with a new technology.) In short, SOAP is the technology that you need to solve your distributed application programming problems. It will allow you to transfer data between disparate machines more efficiently and with fewer problems. SOAP is such a new technology that most developers have to rely on the white papers pro- duced by developers of the technology for reference purposes. Special Edition Using SOAP provides the kind of information that you’ll need to get your applications working quickly after you understand the basic theory behind SOAP. This book will help you gain proficiency in SOAP in the following ways: ■ A technology overview that cuts out superfluous information and provides just the information needed to write applications ■ Detailed examples that show how to create new applications as well as convert existing ones ■ Tips that show how to become proficient with SOAP quickly ■ Solutions for problems with using SOAP in certain environments ■ Performance and other tips that will make applications perform faster and more reliably ■ A data type and data conversion reference ■ An overview of Microsoft’s Biztalk technology ■ A third-party tool reference that will allow you to start working with SOAP immediately, rather than build tools first.
- 19. 3 What’s in This Book As you can see, this book provides complete coverage for the developer who needs to com- plete projects quickly. Special Edition Using SOAP focuses on getting work done, rather than on the theoretical aspects of the technology. Of course, the book covers all of the details, such as ensuring that security is in place and that the application will perform reliably. Although the focus is on speed, the book will also provide tips that ensure development speed gains aren’t overshadowed by hours of debugging later. Special Edition Using SOAP is the book you need on your shelf because it provides the real-world tools that you require to make Web-based applications a reality. What’s in This Book I’ve designed this book to get you up and running with SOAP as quickly as possible. In fact, this book contains only three theory chapters—the remaining seven chapters focus on example code and how to accomplish work quickly. You’ll find a wealth of productivity aids and tips on how to avoid pitfalls. The following sections provide an overview of the book. Chapter 1: An Overview of SOAP This chapter tells you what SOAP is and how it differs from older technologies, such as DCOM and CORBA. It also talks about how SOAP uses HTTP and XML with some addi- tional elements to create a message. Finally, we’ll talk about the advantages and disadvan- tages of using SOAP to develop applications. This includes problems you might experience, such as getting the same performance from your application as before you converted it to use SOAP. Chapter 2: SOAP in Theory SOAP is a protocol (set of rules), rather than an application programming interface (API) or programming methodology. This chapter will help you understand how SOAP works and why it can avoid certain problems that DCOM and CORBA can’t in a distributed environ- ment. The coverage in this section will be complete, but extremely focused. The chapter provides many references to Microsoft and other vendor material on the Internet. Even if you need a detailed view of the inner workings of SOAP, the combination theory overview in this chapter and references to white papers on the Internet should provide everything you need. Chapter 3: An Overview of Security Issues for SOAP Security issues are a concern for any application. Protecting data is a problem that has plagued computers since the very beginning. The distributed application environment provided by the Internet only makes matters worse.
- 20. 4 Introduction This chapter discusses the major security concerns for any SOAP application. Later chap- ters will discuss specific concerns for particular application types. You’ll also find a discus- sion of privacy issues in this chapter. Securing the user’s identity is becoming more important as countries pass laws requiring secure and hassle-free communication. Finally, this chapter discusses some alternative technologies, such as biometrics, for securing your system. It’s important to look at these alternatives as a way to reduce coding require- ments and application usage complexity. Chapter 4: Using SOAP to Create a Simple Application This chapter contains the first complete SOAP example in the book. The example isn’t that complicated, but we do examine it thoroughly. The chapter will discuss issues such as error handling and testing techniques. We’ll also talk about methods for creating WSDL files and discuss how those WSDL files reflect the underlying component technology. This chapter concentrates on the Microsoft SOAP Toolkit. Chapter 5: Migrating an Application from DCOM to SOAP Many developers will spend more time converting existing applications to SOAP than cre- ating new ones. This chapter shows how to move an application from the DCOM environ- ment to the SOAP environment. It also shows how to maximize your current coding investment by continuing to use as many of the DCOM modules as possible. We’ll also discuss some practical issues. For example, SOAP isn’t always the correct solution to your application problem; you might find that DCOM is still the right tool for the job. Chapter 6: Creating Remote Access Utilities More employees are on the road than ever before. They want access to their applications back at the office and it’s your responsibility to provide that access. In addition, a remote user might have new application needs, such as a utility for quickly checking in at the home office without calling. This chapter looks at these issues and more. You’ll find two program- ming examples that show how to use SOAP for the remote user’s needs. Chapter 7: Creating Data Entry Forms and Surveys Web-based applications are useful because you can share information with others outside your company. You can also gather information from others and use it for analysis. For example, companies are always looking for new ways to request information from customers and use it to improve sales or service. SOAP is a useful technology because it extends the data entry form and survey application to perform tasks that you can’t generally perform now. For example, such an application can completely automate the process of entering new data into the database. For that matter, you can automate the analysis as well and send the results to concerned parties.
- 21. 5 What’s in This Book This chapter also discusses some practical issues you need to consider, such as using tem- plates to reduce the amount of coding required to create an application. Templates are espe- cially important for survey applications where the presentation changes regularly. We’ll also discuss some special issues, such as the enhanced error-handling requirements for a survey application. Chapter 8: Providing Remote Database Access The database is the center of every business. In fact, the organized storage of data is the center of every business, even those that don’t have a computer (admittedly rare today). SOAP provides new opportunities to handle data in the distributed application environ- ment. Not only can you create new data connections internally, but also partners can now access your data directly as needed. This chapter addresses some special database applications needs. For one thing, most devel- opers want to use transactions to ensure reliable data transfer from one point to another. We’ll discuss this issue along with methods for fixing database application problems. Although this chapter won’t provide you with a complete tutorial on database design and implementation, it does provide you with the SOAP piece of the puzzle. Chapter 9: Moving to Web-Based Applications Several of the previous chapters have led up to this one. The application of the future will always provide a distributed connection. The user won’t care where he uses the application because it won’t matter. Web-based applications represent the future of programming tech- nology. This chapter shows you how to create some simple Web-based applications. Of course, the important issue is preserving all of that code you have right now. This chap- ter also tells you how to preserve your investment by leveraging your current code base. You’ll avoid creating applications from scratch by carefully designing your Web-based application to hook into the existing application infrastructure. Chapter 10: Working with PDAs Many users are completely hooked on the personal digital assistant (PDA). This little device holds a significant piece of their lives. It stores all of their contact information, tasks they need to perform, and schedule for upcoming weeks. Unlike a desktop computer, a PDA is small and you can take it with you anywhere to record new information. In short, PDAs are becoming an essential asset for most employees. It won’t be long before you’ll find yourself moving existing applications to the PDA—at least the applications that are small enough to move. This chapter examines methods for moving common applications to the PDA. We’ll look at two examples so that you can see some of the pitfalls in developing a PDA solution.
- 22. 6 Introduction This chapter also discusses some of the issues surrounding PDA development. We’ll cover SOAP-specific issues, such as the selection of a SOAP toolkit for PDA development. This chapter also discusses a few general PDA issues. For example, the small screen that a PDA provides will affect the way that you develop the application interface. Appendix A: SOAP Data Types and Data Type Conversions This short appendix tells what data types SOAP supports and how to convert data from existing languages to a format that SOAP will understand. It’s a quick reference with code snippets that show how to perform the required work. There aren’t any complete program- ming examples. Appendix B: Microsoft Biztalk and SOAP Although Microsoft isn’t the only company working with SOAP, for readers of this book, Microsoft will probably be a major supplier of SOAP technology. Biztalk provides access to Microsoft’s XML and SOAP technology implementations, so a discussion of this important server product is essential. This appendix provides an overview of Biztalk as a whole, plus specifics on how this server will provide XML and SOAP services. Appendix C: Third-Party Tool Reference Because SOAP is so new, you’ll want to know what types of tools are available from third parties. This appendix provides a list of the tools that are available at the time of writing. This list isn’t complete, but it does represent some of the better tools available for SOAP development today. Appendix D: SOAP for Visual C++ Developers Most of the examples in this book concentrate on Visual Basic or some form of scripting. This appendix discusses SOAP for the Visual C++ developer. You’ll find example code and a complete discussion of Visual C++ development issues. Like the example in Chapter 4, “Using SOAP to Create a Simple Application,” the appendix example is somewhat simple, but the discussion is in depth. We’ll talk about issues such as testing and SOAP error han- dling, as well as the creation of client-side code. On the Web We’ve provided all the source code for the examples in the book at an easy to find website. Just go to www.quepublishing.com and check out the site. There you will find easy to down- load executables that contain all the source code separated by chapter. Everything you need to complete the exercises is right there.
- 23. 7 Equipment Used for This Book Intended Audience I wrote this book for the developer who has a good understanding of programming princi- ples and has worked with distributed applications sometime in the past. In other words, a complete novice will have a difficult time understanding the material, but someone with a little experience will get some information from it almost immediately. All of the examples assume that you know something about Visual Basic or Visual C++ programming and have worked with DCOM or CORBA in the past. You need to understand terms like interface because the theory sections in this book are short and concentrate only on SOAP principles. As the book progresses, the topics become more difficult and the anticipated understanding level of the reader increases. By the time you reach the remote database programming example (Chapter 8, “Providing Remote Database Access”), I’m assuming that you’re at least an intermediate to advanced reader who has spent some time developing remote data- base applications. You must understand how to work with databases. Although the chapters do provide details on constructing the applications, you won’t find any information about working with the database managers or procedural steps for constructing the tables. All that I provide is the schema you need to build the application. This doesn’t mean that I’m going to bury you with arcane information; this book covers the various topics in simple terms that you’ll find easy to understand. The purpose of this book is to discuss as many SOAP issues as possible in terms that everyone will understand. However, a beginner will still very likely get lost as the book progresses because there’s little in the way of introductory information. Equipment Used for This Book I made some assumptions while writing the application programming examples in this book. First, you need at least two machines: a workstation and a server. This two-machine setup is the only way that you’ll see SOAP in action and truly know it works as anticipated. During the writing of this book, I used a Windows 2000 and Windows 98 workstation. The servers included Windows 2000 Server and Red Hat Linux. I also experimented with two Web servers running on a NetWare file server, and two PDAs (Windows CE-based Pocket PC and a Palm). I tested all of the examples in this book with Visual Studio 6.0 Enterprise Edition. Most of the examples use Visual Basic, but you’ll also find examples written in Visual C++ and in various scripting languages. None of these examples is guaranteed to work with any other programming language products and none of them will work with the educational versions of Visual Studio.
- 24. 8 Introduction You must install the latest service packs for all products before the examples will work prop- erly. SOAP is a new technology that relies on the latest versions of many DLLs, especially the XML parsers used in the examples. This book doesn’t support the beta versions of the SOAP toolkits unless I specifically note that I’ve used a beta version. Make sure you use release versions of the SOAP toolkits, especially the Microsoft SOAP Toolkit Version 2.0. Some of the example programs rely on a database manager. I used SQL Server 7.0 for all of the examples in this book. The source code provides scripts that I tested on SQL Server, but may work with other database managers as well. The sample data is in delimited text format and you should be able to import it into any database manager. In short, you can use any database manager you want, but the examples might require modification to do so. Conventions Used in This Book There are several conventions used within this book will help you get more out of it. Look for special fonts or text styles and icons that emphasize special information. ■ Sometimes I’ll ask you to type something. This information always appears in bold type like this: Type Hello World. ■ Code normally appears on separate lines from the rest of the text. However, there are special situations where small amounts of code appear directly in the paragraph for expla- nation purposes. This code will appear in a special font like this: Some Special Code. ■ Definitions are always handy to have. I’ll use italic text to differentiate definitions from the rest of the text, like this: A CPU is a required part of your machine. ■ In some cases, I won’t have an exact value to provide, so I’ll give you an idea of what you should type by enclosing it in angle brackets like this: Provide a <Machine Name> value for the Name field. ■ You’ll always be able to recognize menu selections and command sequences because they’re implemented like this: Use the File | Open command. ■ URLs for Web sites are presented like this: http://www.microsoft.com. Notes help you understand principle or provide amplifying information. In many cases, a note is used to emphasize some piece of critical information that you need. All of us like to know special bits of information that will make our job easier, more fun, or faster to perform. Tips help you get the job done faster and more safely. In many cases, the information found in a Tip is drawn from experience, rather than through experimentation or the documentation.
- 25. 9 Conventions Used in This Book Any time you see a caution, make sure that you take special care to read it. This infor- mation is vital. I’ll always uses the Caution to designate information that will help you avoid damage to your application, data, machine, or self. Never skip the Cautions in a chapter, and always follow their advice. Finding what you need quickly is more important than ever before. Many people work at a pace that they call Internet time. They no longer have the luxury of performing hours of research to find that magic piece of information needed to complete an appli- cation. With this in mind, I’ve spent the time you don’t have to find unique information sources on the Internet. This icon will always provide that information so that you can get what you need quickly.
- 27. An Overview of SOAP In this chapter What Is SOAP? 13 How SOAP Differs from DCOM and CORBA 15 SOAP, HTTP, and XML 22 Problems Solved by Using SOAP 24 Performance Issues 26 SOAP and the Web Server 28 Why Make the Move to SOAP? 28 Case Study 29 1 CHAPTER
- 28. 12 Chapter 1 An Overview of Soap At one time in the history of the PC, computing consisted of a single computer using simple applications that relied only on local resources. Eventually, networking changed the way people shared expensive peripherals and data, but the data was still, to an extent, stored locally. As companies grew and became more dependent on the PC, the concept of the Local Area Network (LAN) gave way to the Metro Area Network (MAN) and Wide Area Network (WAN). The client/server architecture of days gone by allowed a limited form of distributed computing. However, there was still a direct connection and all of the data appeared within the confines of one company, so sharing data was still relatively easy. Today, computing is all about distributed applications running on machines that may not know anything about each other. Data is no longer restricted to one company; business-to- business communication is now the norm. Consequently, these machines may not even have a direct connection or access the network at the same time. Data sharing occurs between individuals who may not ever meet. In short, there isn’t a direct connection between the provider and the user of data anymore, which means the rules used in the past don’t work well for modern communication needs. Early computers relied on protocols (predefined rules) that ensured safe data transfer between machines that knew what to expect from each other. These protocols work fine on a LAN, MAN, or WAN because there’s a direct connection between machines. A protocol designed for the LAN environment, however, may run into problems when dealing with something like the Internet. For example, the protocol may expect to find another Windows machine when the client really needs to communicate with a Unix server. That’s precisely what’s happened and why we need a new protocol named Simple Object Access Protocol (SOAP). The fact that you’re reading this book means that you already have some idea of why you need SOAP and may even know something about it from a technical perspective. The first section of this chapter is going to tell you more about SOAP—what it does and how it works. This section isn’t going to provide many details, but it will prepare you for the detailed discussion in Chapter 2. I want to present a basic overview of the technology before jumping into the details. SOAP is different from older protocols. It provides some features these older protocols don’t have. For example, unlike Distributed Component Object Model (DCOM) and other binary protocols, SOAP won’t interfere with the operation of the firewall on your Web server. It uses a plain text transfer method that firewalls readily accept. This means that you can maintain the integrity of your company’s Web site, and still get the data you need. Some of these neat new features come at a cost. You lose some of the features provided by the older protocols. For example, security is an issue that many SOAP developers are trying to address as of this writing. The second section of the chapter provides a brief comparison of SOAP to older protocols, such as DCOM and Common Object Request Broker Architecture (CORBA). You’ll learn how SOAP excels and where it provides less than stellar results. SOAP actually interacts with other Web technologies that you may have used in the past. Although SOAP can theoretically rely on any transport protocol, the current toolkit from Microsoft uses the same Hypertext Transfer Protocol (HTTP) used to move Web pages across the Internet. (Note that you can use any reliable protocol to transfer SOAP
- 29. 13 What Is SOAP? messages—HTTP is simply the most straightforward and easily accessible method right now, so developers are using it.) In addition, SOAP relies on the eXtensible Markup Language (XML) to format data before moving it from one point to another. The third section of the chapter discusses the interaction between these three technologies. As previously mentioned, Microsoft designed SOAP to address specific problems. Technologies such as DCOM just can’t make the grade in the distributed computing environment of the Internet. The fourth section of the chapter discusses these problems in detail and explains how SOAP addresses them. SOAP changes the performance picture—it uses a new technique to transfer data, so differ- ences in performance are expected. In many cases, SOAP is slower than older technologies like DCOM. You can’t beat a direct binary connection between client and server that relies on optimized data transfers. However, given the distributed nature of applications today, there are also situations when SOAP is faster than binary technologies. In the fifth section of the chapter, we’ll talk about SOAP performance issues. This section also talks about ways of mitigating some of those performance losses by using better coding techniques. Microsoft designed SOAP to work with the Internet—which means you’ll eventually run into a Web server. The sixth section of the chapter discusses how SOAP works with a Web server to handle client requests. We’ll talk about some of the mechanics you’ll need to know later, like common storage locations for files and some of the implementation details. The final section of the chapter discusses a topic that many of you will ask about once you see everything required to move to SOAP. It’s important to know why this move is so important and how you’ll benefit from it. SOAP is a great technology with a very important purpose for your company. This section discusses why you need to include SOAP in your programming toolbox. What Is SOAP? SOAP is a lightweight communication protocol based on the eXtensible Markup Language (XML). It allows applications and components to exchange data. As mentioned in the intro- duction, SOAP currently relies on HTTP as a transport protocol, but could use any reliable transport protocol to transfer data. In addition, SOAP is useful for many data transfer needs, including LANs, WANs, and MANs—it’s not just for the Internet. 1 Ch Learning XML is an essential part of learning SOAP. You don’t have to become an XML guru, but knowing the basics is a requirement. Many XML Web sites offer tutorials and other information about this technology. For example, DevelopMentor (http://www. develop.com/dm/dev_resources.asp) provides good tutorials on this and other distributed application topics from a Microsoft perspective. W3Schools (http://www. w3schools.com/ xml/) provides detailed tutorials in small segments. Another good place to look for XML training is Courses in XML by QTrain (http://www.qtrain. net/). Once you finish the basic XML tutorials, you’ll want to visit XSLT.com (http:// xslt.com/resources_tutorials.htm) and learn more about data transformation
- 30. 14 Chapter 1 An Overview of Soap Despite what you may have heard, SOAP isn’t another conspiracy by Microsoft to take over the world—it’s a protocol supported by many vendors. Some of the most notable contribu- tors to SOAP are Ariba, Commerce One, Compaq, DevelopMentor, HP, IBM, IONA, Lotus, SAP, and UserLand. Vendors who support SOAP hope it will eventually gain stan- dards status. The World Wide Web Consortium (W3C) is currently discussing SOAP. You can read the W3C comments at http://www.w3.org/Submission/2000/05/Comment and see the initial specification at http://www.w3.org/TR/SOAP/. Since SOAP is a new protocol that isn’t tied to a particular operating system, the vendors working on it are free to add features that make SOAP especially suited to distributed application use. Three of the features that make SOAP attractive are: ■ No ties to existing component technologies—SOAP will theoretically work with any platform. ■ No ties to a particular programming language; you can use SOAP with any language capable of outputting text. (You can also use a special toolkit to output the formatted text as well, seen in Chapter 4.) ■ Easy to learn and simple to extend. You’ll see as the book progresses that these three points are important because they’ll affect your perception of SOAP as an application solution. For example, the fact that vendors haven’t tied SOAP to a particular programming language means that you’ll very likely see a wealth of toolkits on the market. These toolkits may not all produce compatible code. In addition, they may rely on server or client-side components that aren’t compatible with other SOAP imple- mentations. Problems like these will become less noticeable as SOAP nears standardization. The last point is important as well. SOAP really is easy to learn. It’s verbose, which means that some of the code listings you see become quite long and look complicated, but the underlying technology is simple. The complexity that you’ll see as we work with SOAP throughout the book comes from the various extensions that Microsoft and other vendors add. These extensions provide additional flexibility and allow you to tailor a SOAP imple- mentation to specific needs. techniques. ZVON.org (http://www.zvon.org/index.php?nav_id=2) includes tutorials on both XML namespaces and the eXtensible Stylesheet Language Transformations (XSLT). SOAP is a very hot topic right now because it offers so much. However, getting the latest news can prove difficult because the specifications change so quickly. You can usually rely on news Web sites and newsgroups to provide updated information on a regular basis. For example, the SOAP News Web site at http://soap.weblogs.com/ provides up to the minute information about this new standard. DevelopMentor and other organizations provide list servers that discuss SOAP. The main public SOAP newsgroups appear on the
- 31. 15 How SOAP Differs from DCOM and CORBA SOAP is intertwined with other technologies as well. We’ve already discussed its connection with XML (and by extension, XSLT ). Creating a SOAP implementation is only the first step. If you want others to use your implementation, you need to advertise it in some way. As the book progresses, we’ll talk about the significance of Universal Description, Discovery, and Integration (UDDI). You can find out more about this technology at http://www.uddi.org/. The main purpose of UDDI is to allow vendors to advertise services publicly, including those that rely on SOAP. Another technology that figures prominently in the SOAP picture is Web Services Description Language (WSDL). We’ll discuss this technology in detail in Chapter 2. WSDL provides a description of objects and documents on a Web server in the form of a schema. It also allows advanced features of some programming IDEs to display a list of functions applicable to a particular object. Look at http://www-106.ibm.com/developerworks/ library/w-wsdl.html to find out more about WSDL. How SOAP Differs from DCOM and CORBA SOAP, like DCOM and CORBA, is a wire protocol. The term wire protocol indicates that appli- cations use SOAP to move data from one place to another. Many people assume that because COM and DCOM have similar names that they’re the same kind of protocol. COM is actually a specification that tells how to create components—DCOM enables those components to interact across a network. It’s an important difference to understand because Microsoft designed SOAP to overcome some of the limitations of DCOM, not to replace it or replace COM itself. The first two sections below provide a comparison of SOAP with DCOM and CORBA. We’ll look at how the protocols compare from a result and method perspective. The essential difference between SOAP and the other two protocols is that SOAP uses plain text, while DCOM and CORBA use a binary format. A third section discusses the Java Remote Method Invocation (RMI). This is a relatively simple wire protocol that’s designed to support Java. It differs from DCOM and CORBA because Java RMI is only designed to support Java—these other protocols support any language. The Java RMI is still a binary protocol, so it differs from SOAP in that regard. DCOM Wire Protocol The DCOM Wire Protocol, also known as the DCOM Network Protocol or DCOM for short, is a high-level protocol based on the Distributed Computing Environment (DCE) Remote Procedure Call (RPC) Network Protocol and implemented by Microsoft. DCOM relies on several lower-level protocols to accomplish its work. Like SOAP, DCOM oversees the data transfer; it doesn’t perform the mechanics of moving the data. As an enabling 1 Ch Microsoft server (news.microsoft.com). You’ll find a wide range of topics in news- groups like microsoft.public.msdn.soaptoolbox, microsoft.public.xml. soap, and microsoft.public.xml.soapsdk.
- 32. 16 Chapter 1 An Overview of Soap protocol, DCOM ensures that the client and server can talk to each other, but doesn’t participate in the conversation or manipulate the data. Ethernet Driver Internet Protocol (IP) DCOM Network Protocol (DCE RPC Network Protocol) COM Runtime Proxy Client Service Control Manager (SCM) OLE32 User Datagram Protocol (UDP) Winsock Driver Security Provider Protocol Stack Ethernet Driver Internet Protocol (IP) DCOM Network Protocol (DCE RPC Network Protocol) COM Runtime Stub Server- Side Component Service Control Manager (SCM) User Datagram Protocol (UDP) Winsock Driver Security Provider Protocol Stack Figure 1.1 Internet Explorer versions 5.5 and above can display SOAP messages in a simple format. Microsoft didn’t create the DCE RPC Network Protocol specification. The Open Software Foundation (OSF), which is now part of the Open Group, created it. You can find out more about the DCE RPC Network Protocol specification at http://www.osf.org/. Find a good RPC overview at http://www.ja.net/documents/ NetworkNews/ Issue44/RPC.html. There’s an article about the inner workings of DCOM at http:// www.microsoft.com/msj/0398/dcom.htm. The main Microsoft DCOM Web site is at http://www.microsoft.com/com/tech/DCOM.asp. Figure 1.1 shows a generic DCOM component setup. We aren’t doing anything fancy here since the idea is to learn how the connection between the client and server works. Table 1.1 tells you about the various components shown in Figure 1.1. Notice that the message goes through quite a few transition layers. These layers figure prominently in the performance discussion later in the chapter.
- 33. 17 How SOAP Differs from DCOM and CORBA Table 1.1 Components of a Typical DCOM Data Transfer Component Description Client Originates requests to the server for resources and support. DCOM assumes this is a standard desktop application operating on a LAN. OLE32 DLL containing the methods used to create an instance of an object (along with a wealth of other functionality). Service Control Manager (SCM) Creates the initial connection between the client and server. DCOM only uses the SCM during object creation. After the client and server establish a connection, the SCM steps out of the picture. The SCM represents one of the handshaking elements that we’ll talk about later in the performance section of the chapter. Proxy The server’s presence within the client’s address space. The proxy is actually a table of interfaces. Windows creates and manages it at the request of the COM run time. The proxy allows the client to think that the server is local, even though the server is located on another machine. COM Runtime Operating system elements that host objects and provide client/server communication. The COM runtime is part of any COM related scenario—both in-process and out- of-process—local and remote. Security Provider The security provider logs the client machine into the server machine. The operating system determines the type of security providers available. Some security providers will also protect all data transferred between the client and server in some way—usually using encryption. DCOM Network Protocol Defines a protocol for creating a connection with a (DCE RPC Network Protocol) remote server. In addition to implementing a component protocol, this block contains all the elements to implement the Object Remote Procedure Call (ORPC) specification at an application level. This is the wire protocol that’s the target of this section of the chapter. Protocol Stack Actual network communication requires more than just one protocol—there are network-related protocols to consider as well. The protocol stack consists of all the protocols required to create a connection between the client and server, including network specific protocols like transmission control protocol/Internet protocol (TCP/IP). Figure 1.1 shows a typical protocol stack consisting of a Winsock (Windows sockets) driver, user datagram protocol (UDP), IP, and an Ethernet driver. Not shown is the Ethernet network interface card (NIC) actually used to create the physical connection between the client and server. 1 Ch
- 34. 18 Chapter 1 An Overview of Soap Table 1.1 Continued Component Description Stub The client’s presence within the server’s address space. Windows creates and manages the stub at the request of the COM runtime. As far as the server is concerned, it’s working with a local client. Server The COM object that the client has requested services and resources from. Figure 1.1 is typical of a binary wire protocol like DCOM and even CORBA. As you can see, the design is somewhat complex, but works well in a LAN, WAN, or MAN environment. The point is that DCOM is an enabling technology, not a data manipulation technology. You can view it as a sort of traffic cop and trail guide rolled into one. DCOM uses a specific procedure to ensure reliable communications between machines. This procedure relies on a lot of handshaking to ensure that each phase of the data move- ment process occurs as anticipated. Contrast this with SOAP, which sends the data and sim- ply assumes that it will arrive at the remote location. Here are the steps that DCOM follows to ensure a safe data transfer between machines: 1. Client issues an object creation call. The call must include both a class ID (CLSID) and a server name (along with any information required to log onto the server). As an alter- native, the client can issue a standard call that OLE32.DLL will resolve to a remote location based on a registry entry, or the client can use monikers. 2. OLE32.DLL calls upon the client side SCM to create a connection to the server machine because it can’t service the call locally. 3. DCOM creates the required packets to send information from the client to the server. 4. The server-side SCM creates an instance of the desired server-side component and returns a pointer of the object instance to the client. 5. The server-side SCM calls upon the COM runtime to create a stub for the component to interact with. 6. The client-side SCM calls upon the COM runtime to create a proxy for the client to interact with. 7. The SCM returns a pointer to the proxy to the client. 8. Normal client and server-side component communications begin. As you can see, DCOM provides a robust data communication environment that relies on a client and server that exist at the same time and have a direct connection. It’s important to understand that DCOM is still an optimal technology when reliability is more important than flexibility. DCOM provides a secure and reliable environment that SOAP can provide. On the other hand, the complexities of DCOM make it difficult to use over the Internet. There are simply too many requirements that DCOM has to satisfy before communication can occur.
- 35. 19 How SOAP Differs from DCOM and CORBA CORBA IIOP CORBA and DCOM have existed side by side for an eternity in computer time. Each tech- nology has proponents and detractors who protect their point of view with the vigor of religious zealots. However, many developers view CORBA as simply an alternative to DCOM and therefore feel that CORBA has the same limitations. The truth is slightly different. CORBA is more like SOAP than DCOM when it comes to design goals, even though CORBA is a binary protocol. There are two main pieces to this architecture, just like COM and DCOM in the world of Windows. CORBA, like COM, provides a specification for component services. There are several CORBA implementations on the market. IBM provides the System Object Model (SOM) and Distributed SOM (DSOM) architectures. Likewise, Netscape offers the Open Network Environment (ONE) platform. Each CORBA implementation differs a little in low-level details, which we won’t discuss in this chapter since they aren’t important in the overall comparison of CORBA to SOAP. Unlike COM, the Object Management Group (OMG) designed CORBA to run on more than one operating system. In addition, OMG looked at Internet communication as an important CORBA feature from the outset. CORBA tends to perform better than DCOM on the Internet, but still provides less than acceptable performance in most cases. These design differences make CORBA more like SOAP than DCOM when it comes to design goals. 1 Ch You can find out more about OMG at http://www.omg.org/. One of the best Web sites to visit for CORBA details is Distributed Object Computing with CORBA Mid- dleware (http://www.cs.wustl.edu/ ~schmidt/corba.html). This site includes a copy of the CORBA specification, a tutorial, and some great overviews of the technology. There’s an interesting CORBA frequently asked questions (FAQ) site at http://www.aurora-tech.com/corba-faq/. There are FAQs for all the CORBA and IIOP components on this site, including answers on IIOP elements like the Interoperable Object Reference (IOR). The OMG sponsored ORB Interoperability Showcase appears at http://corbanet.dstc.edu.au/. CORBA, like COM, is a local component implementation. It requires a wire protocol to cross machine barriers. That’s where the Internet Inter-ORB Protocol (IIOP) comes into play. Unlike DCOM, a protocol designed for LAN use alone, OMG developed IIOP for Internet use. IIOP, like DCOM, is the wire protocol that enables component communica- tion between remote applications. In fact, you could almost replace the block names in Figure 1.1 with CORBA and IIOP equivalents and see the technology in operation—the ideas are the same, the names and precise implementation details are changed. If you want to know how the DCOM and CORBA technologies differ from a block dia- gram perspective, compare the CORBA block diagram (Figure 1.2) at http://www. cs.wustl.edu/~schmidt/corba-overview.html with Figure 1.1 in this chapter.
- 36. 20 Chapter 1 An Overview of Soap IIOP provides most of the same functionality of DCOM. Unlike SOAP, both IIOP and DCOM can transfer a variety of non-ASCII data types, such as integers and objects. The same binary features that restrict IIOP and DCOM from getting through firewalls allow them to transfer native data types. This makes binary data transfers more efficient—they require fewer data packets. CORBA and DCOM are both stateful protocols. A user establishes a connection with the server and that connection remains in place during the entire session. This ensures the user’s state information remains intact and enhances the developer’s ability to write applications that interact with the user. HTTP is a stateless protocol. Consequently, SOAP can’t main- tain state information, which causes problems. For example, SOAP can’t support properties because the use of properties infers maintained session state information; something that HTTP can’t support. Another way that CORBA and DCOM are similar (although definitely not equal) is in the area of security. If you want to secure a SOAP data transfer, you need to rely on a third party product,such as Secure Sockets Layer (SSL). CORBA and DCOM both include built-in security. Unfortunately, security settings often cause problems for both CORBA and DCOM developers. Getting security set high enough so that no one can see your data, yet low enough to get past firewalls is difficult. In addition, DCOM is especially susceptible to security-setting errors that result in a loss of communication. If the server and the client don’t agree about the level of security to support, then communication doesn’t take place. Obviously, CORBA and DCOM are quite different internally. The packets they produce are not compatible, some data representations differ, and they use different methods to accom- plish the same tasks. It’s important to understand that these differences cause problems for distributed application developers because a company that uses CORBA can’t communicate with a company that relies on DCOM, and vice versa. Java RMI I included Java Remote Method Invocation (RMI) in the chapter because it’s an important adjunct to CORBA. It isn’t a separate or unique wire protocol because it’s built on CORBA, but Java RMI does include some features you need to know about. The most important feature is simplicity. The creators of Java RMI recognized that many developers viewed CORBA as difficult to use and error prone, so they created an easier to use wire protocol in the form of Java RMI. You’ll see definite similarities in the two architectures. For example, you can view the COM proxy and stub performing a function similar to the CORBA Interface Definition Language (IDL) stub, Dynamic Invocation Interface (DII), IDL skeleton, and Dynamic Skeleton Interface (DSI). Note that CORBA uses more layers to accomplish the same goals as DCOM—some developers say this makes CORBA slower than DCOM even on a LAN (your mileage may vary).
- 37. 21 How SOAP Differs from DCOM and CORBA All you need to do is spend a little time with Java RMI to realize the simplicity it brings to the development environment. The protocol automatically takes care of many of the low- level details you normally need to consider. For example, you can gain access to a remote object by looking it up in a name facility provided by Java RMI, or by receiving the reference as a return value or method invocation argument. In addition, the protocol doesn’t need to consider language or platform differences because communication occurs directly between two Java Virtual Machines (JVMs). You can see that Java RMI is a simplified form of CORBA by looking at the block diagram and architectural discussion at http://www.java.sun.com/ products/jdk/1.1/docs/guide/rmi/spec/rmi-arch.doc.html#200. One thing that might escape your notice at first is that Java RMI also inherits all of the good features of Java. This means you gain access to niceties like garbage collection. When you develop an application using CORBA or DCOM, you have to allocate objects and remember to destroy them manually. Java RMI still requires that you allocate the objects, but the run- time automatically destroys objects that go out of scope (they’re no longer referenced by other objects). The first feature that I noticed beyond simplicity is that the Java RMI doesn’t require a large support library. You don’t have to install anything extra—everything comes with the JVM. Many developers I know have had horrifying experiences getting DCOM to work because of DLL hell. DLL hell is an evil giant of a problem in which older applications either won’t run with new versions of DLLs or they overwrite those DLLs and cause new applications to fail. The fact that Java RMI appears as part of the whole Java package and there’s little chance for incompatibilities to creep in can save more development time than you’d ever imagine. Java RMI also includes a unique feature—the ability to move behaviors between machines using inheritance. (Normally, Java RMI extends a default class; but, using special program- ming techniques allows you to extend other classes as well.) This feature allows a developer to add a new behavior to an existing class. For example, an existing class may perform finan- cial analysis, but you might want it to include sales tax or other added calculations. A new behavior would allow an existing class to perform this task. Contrast this with CORBA and DCOM, which allow a developer to call methods in existing object or move objects around, but not augment existing object behavior. Simplicity comes with a high price in this case. For one thing, you’re still dealing with a binary protocol. It’s still impossible to get messages past firewalls in some cases. In addition, you have less control over the environment when problems occur (simplicity gets in the way). 1 Ch One of the better overviews of Java RMI appears at http://www.java.sun.com/ marketing/collateral/ rmi_ds.html. I found the diagrams a little difficult to see, but, otherwise, the information is easy to understand. You’ll also want to view the more detailed Java RMI white paper at http://www.java.sun.com/marketing/ collateral/javarmi.html and the specification at http://www.java.sun.com/ products/jdk/1.1/ docs/guide/rmi/spec/rmiTOC.doc.html.
- 38. 22 Chapter 1 An Overview of Soap Another problem is that Java RMI is understandably a Java only solution. As long as you’re willing to make your programming language Java, you’ll be fine. However, Java isn’t noted for its high execution speed and is, therefore, less suitable than other languages for some types of desktop and automation applications. Java RMI passes all parameters by copy rather than by reference. This means a remote method can’t change the value of an argument you pass; it must provide a return value in other ways. Passing parameters by copy is the Java RMI method of handling some of the intricacies of marshalling. Java RMI always passes objects, on the other hand, by reference. The client gains access to an interface, not an object implementation. SOAP, HTTP, and XML I can already hear some of the SOAP savvy among you sighing that I chose to lump SOAP, HTTP, and XML together. It’s true that these protocols are useful as separate entities and don’t necessarily depend on each other. However, the real world situation today is that developers do use them together, so for the sake of simplicity, I’m lumping them together for now. So, what does a SOAP message look like? It depends on the technologies that you use with SOAP, which is why I specified the three technologies I’m using up front. Here’s a simple example—so simple, in fact, that you probably wouldn’t use this form in a real message. <SOAP-ENV:Envelope> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <GetPerson> <LastName>Mueller</LastName> <FirstName>John</FirstName> </GetPerson> </SOAP-ENV:Body> </SOAP-ENV:Envelope> This example points out several similarities between Web technology that you’re already familiar with and SOAP. Notice that everything has an opening and closing tag—that’s the XML influence on SOAP, but also has it’s roots in the HyperText Markup Language (HTML) we’re all familiar with. A SOAP message always appears within an envelope. The envelope can have a header, just like an HTML document would, but this isn’t required. The message must have a body. The message content appears within the body as shown here. We’re making a request of the GetPerson function for a person whose last name is Mueller and first name is John. You can extend all of these tags. In fact, you’ll likely extend most of them when creating standard SOAP messages. For example, the envelope tag will probably look something like this in a real message. <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”> The second parameter, in this case xmlns, is the namespace used for the envelope. A namespace reference tells where to find definitions for classes that contain functions used
- 39. 23 SOAP, HTTP, and XML within the message. So, let’s expand this principle to the GetPerson function mentioned previously. Here’s what the body of the example message might actually look like. <SOAP-ENV:Body xmlns:MyObj=”http://www.mycompany.com/myobjects/”> <MyObj:GetPerson> <LastName>Mueller</LastName> <FirstName>John</FirstName> </MyObj:GetPerson> </SOAP-ENV:Body> The xmlns tag contains the location of the MyObj object on your company server. This object contains the GetPerson function used in this example. As you can see, a SOAP message could quickly begin to look complex, but it’s simple in design. 1 Ch Remember that you must always pair all XML and SOAP tags; there’s always an opening and closing tag. In cases in which you don’t need to include any data between tags, you can signify the closing tag by adding a slash at the end of the tag like this example of a paragraph tag: “<P />”. We’ll discuss namespaces in more detail as the book progresses. For now, all you need to know is that SOAP messages have a specific format that looks familiar if you’ve worked with XML or even HTML in the past. OK, I’ve shown you the XML and SOAP part of the picture; so where does HTTP come into play? SOAP uses HTTP as a transport protocol—the method for getting a message from one place to another. A SOAP message transaction normally occurs in two phases. The first appears within an HTTP request message. The client requests data from the server, just as it would for a Web page. The server places the requested data within the SOAP message that Web server packs into an HTTP response message. The Web server uses the same tech- nique as it would normally use—only the content of the HTTP message differs from normal. A standard browser can view the SOAP message you create. For example, Figure 1.2 shows the output from the sample code we looked at earlier. Since we didn’t create an XSL file for this example, the browser uses the default template. This template shows you the content of the SOAP message with keywords and content highlighted in a variety of colors. Normally, you’d pass the SOAP response message to a client side application for interpretation and display. Now that you have a taste of what SOAP is like, you might want to view the SOAP specification. The current specification, as of this writing, is version 1.1. You’ll find it at http://static.userland.com/xmlRpcCom/ soap/SOAPv11.htm (among other places). Not only will the specification fill you in on additional details, but you’ll also see some example messages that contain the HTTP header, as well as the SOAP message. I chose to concentrate on just the SOAP portion of the message in my example listings.
- 40. 24 Chapter 1 An Overview of Soap Problems Solved by Using SOAP Some developers are dubious about the benefits of using SOAP because they see it as a com- plex way to transfer data from one location to another using unsafe methods. For example, SOAP doesn’t have any form of internal security and you can’t use it when you need trans- actions. One developer even stated that SOAP was a poor choice for any kind of database work, unless you include safeguards at both ends of the transaction. (This is where all of those classes on three-tier design come into play—SOAP should access only the business logic on your server, not the database itself.) No matter what the developer community comes up with for a data transfer protocol, there are always going to be negative points to consider. SOAP is a “fire and forget” solution to transferring data on the Internet that works well in some cases and not at all in others. I’m not going to convince you in this section that SOAP is the perfect solution for every prob- lem. You shouldn’t consider it the solution for all problems either—SOAP has limitations. All arguments aside, SOAP does solve two very important problems and a host of smaller problems. The first problem is the matter of network security versus data transfer. DCOM and CORBA are both binary data transfer protocols. This means they both rely on non- ASCII characters that a Web server firewall could interpret as executable code and packet formats that the firewall will interpret as invalid HTTP packets. In both cases, the firewall throws the packets out because it’s designed to work that way. Since the Web server requires the firewall to keep crackers out, there’s an obvious problem with using binary data transfers. SOAP solves the problem by using ASCII in an HTTP package—something the firewall will instantly recognize as data and pass along to the Web server for processing. Figure 1.2 Internet Explorer versions 5.5 and above can display SOAP messages in a simple format.
- 41. 25 Problems Solved by Using SOAP The second major problem is one of compatibility. If you use a binary protocol, the client and server must both use the same method for retrieving the data from the packet. Binary compatibility is easy to achieve when programmers in one company maintain both the client and server. However, distributed applications aren’t one-company solutions. You now have other companies in the form of partners and clients to consider. Transferring ASCII data within an HTTP packet between companies is easier and less error prone than binary methods. SOAP combined with UDDI makes it easy for customers to find you and use the resources you provide. Services such as online ordering are easier to implement when everyone has common grounds for participation. It’s ironic that one of the features that makes binary protocols so useful on a LAN actually gets in the way when working in a distributed environment. DCOM provides a wealth of security setting features that enable you to fine-tune your approach to keeping your data secure. For example, you can choose to check a user’s identity only once at the outset of a communication. On the other hand, you can ask the user for identification information before each transaction. While this does aid in security, it also means that DCOM is doing a lot of handshaking with the application; a feature low bandwidth connection like the Internet won’t support. SOAP doesn’t implement any security internally, so there isn’t any security-related handshaking to worry about when using this protocol. SOAP relies on security like SSL that’s designed for Internet use, so again, the effect of security on system performance is minimal. Proxy servers can also present problems for the developer. The target for a remote call might not have a publicly routable IP address. This means that a proxy server will have to route the packets to the correct internal address—adding yet another failure point where incorrect configuration information can keep an application from working. SOAP is interpreted by a listener component that has a direct public IP address. You still gain security benefits because the listener doesn’t do anything with the data—an internal (nonaccessible) component works with the data after the listener interprets it. There’s plenty of opportunity to check the data for security and corruption problems as part of the translation process. Older wire protocols often rely on nonstandard TCP/IP ports for communication so they don’t interfere with standard network traffic. One of the more common ports is 135, but these protocols can use other ports as well. What happens if a network administrator recon- figures the firewall to close the port the application needs? It may take a long time to find the problem because this is an unexpected error. DCOM and CORBA will simply report they can’t contact the server—leaving you in the dark as to the cause of the problem. SOAP solves this problem by using standard communication ports that a network administrator is unlikely to close. This is the tip of the iceberg. Microsoft and other vendors designed SOAP primarily to solve the problems of Internet communication. It isn’t too surprising that it excels in the kinds of communication that you’d expect to perform on the Internet. You’ll run into problems, however, if you assume that SOAP is the only answer. DCOM, CORBA, and Java RMI still provide many useful features not found in SOAP that address distributed applica- tion programming within a company or tightly knit group of companies. 1 Ch
- 42. 26 Chapter 1 An Overview of Soap Performance Issues It’s important to realize that SOAP represents a new method of transferring data from one point to another. Unlike binary technologies used with LANs, SOAP travels between dis- tributed applications on a public network using ordinary text. The differences between SOAP and other transport methods like DCOM Wire Protocol mean that you can’t rely on old technique to ensure swift transmission of data. The following sections will look at the two sides of the SOAP performance coin. On the one hand, there’s good reason to suspect that SOAP won’t perform well as binary data trans- fer methods. For one thing, it’s a verbose data transfer method. On the other hand, SOAP doesn’t require complex translation methods on both ends of the wire. Plain text can get through firewalls with relative ease and is understandable by all platforms. Tradeoffs of Using SOAP There are many performance tradeoffs to consider when working with SOAP. One of the most obvious performance tradeoffs is the compactness of binary data when compared to the ASCII text used by SOAP. Although ASCII text is generally compatible with any system on the market, it’s also bulky. (Look at the simple coding examples in the “SOAP, HTTP, and XML” section of this chapter for details.) Unfortunately, there isn’t any direct way to alleviate this problem. You can’t compress the data without losing some of the compatibility that SOAP is supposed to provide. The size of your messages is a concern because SOAP works on low bandwidth networks for the most part. The Internet isn’t as fast as a LAN or other local dedicated connection. In fact, large message sizes will also affect local server resources (more storage space and longer handling times). Overall, message size is the one performance problem that you’ll have a hard time solving. You can secure a SOAP transaction if you want to. For example, since SOAP relies on HTTP as a transport protocol, you have access to all of the same security measures that you can use with HTTP like Secure Sockets Layer (SSL). However, as anyone who has ever used SSL will tell you, connection speed suffers greatly. It doesn’t take long to realize that you can either have a slow secure SOAP connection or a fast connection that gives everyone access to your data. SOAP lacks the alternatives of other protocols such as DCOM provide. Another potential problem is a two-edged sword. SOAP messages consist of plain ASCII data in XML format. This means that an application on the client has to translate binary data into an ASCII format for transport. Another application on the server end has to translate the data from ASCII format back into a binary format. The translation of data takes time. Just how much time depends on the amount of data you need to transfer and the original data format. Transferring graphics or other strictly binary data is an expensive proposition, while database fields are less problematic if they contain a lot of string data to begin with. (You’ll notice that many SOAP examples are queries for data from a database, but few show record updates or transfers of data that’s normally interpreted from a binary format.) We’ll see in the next section of the chapter that there’s an up side to the use of ASCII text to transfer your data that could become a performance boost.
- 43. 27 Performance Issues SOAP can also create smaller messages in some cases. A binary protocol uses large object refer- ence tags in some situations. The resulting message is actually larger than the SOAP message. A DCOM packet contains information other than the data that you're asking the protocol to transfer, which is the reason for the increase in message size. Admittedly, this is only the case when the object is relatively small. However, if you're making a lot of small requests, rather than a few large requests, the difference in request header size can make a difference. 1 Ch Sometimes performance tuning an application means getting creative, rather than accept- ing you can’t do much to improve performance. For example, reducing the length of string fields can mean the difference between transferring one or two packets. Reducing the number of packets will increase performance. If you can’t reduce the size of the strings, then try to use keywords in place of some of the fields. For example, if a field can only contain a limited number of selections, try passing a number instead of a string. The component on the receiving end can translate the number back into a string as part of the process of reading the SOAP message. Don’t get the idea that there’s any free lunch when it comes to SOAP. Yes, DCOM uses a large object reference tag that could adversely affect performance, but DCOM also supports features like properties. SOAP and DCOM aren’t equivalent; DCOM provides more functionality than SOAP for the near future, so you may still find that you need DCOM functionality even if using it does hurt performance. When SOAP Is Faster The SOAP performance picture isn’t entirely grim. In fact, it can be a faster transport mecha- nism than those binary alternatives. Consider for a moment that we’re talking about a distrib- uted application environment with firewalls and other obstacles to overcome when transferring data from one point to another. A SOAP message requires no translation to get past the firewalls—binary data may very well require translation, if it gets past the firewall at all. Here’s the second part of the two-edged sword mentioned in the previous section. There’s no simple answer to the question of whether it takes more time to transfer binary or ASCII data over the Internet because there are too many variables to consider. Binary data transfers could take more time if a firewall configuration issue forces the server to resend the data multiple times. On the other hand, you have the size of the SOAP message to consider. The only way you’ll know how well SOAP is going to perform is to test it in actual use and make a comparison to similar tests using technologies such as DCOM. If performance is a major criterion, then you need to perform such tests. Another, more subtle, performance difference is that SOAP requires no handshaking. When you’re working with a low bandwidth, high latency media like the Internet, handshaking can become a real performance problem. DCOM requires keep-alive messages and other house- keeping messages that don’t significantly affect the performance of a LAN, but eat precious bandwidth on most Internet connections.
- 44. 28 Chapter 1 An Overview of Soap SOAP and the Web Server When you’re working with SOAP, you’ll eventually need to deal with a Web server. Since Web servers differ in capability and features, it’s almost certain that you’ll run into problem getting SOAP to work with some of them properly. For example, most developers worry about interoperability between Internet Information Server (IIS) and the Apache server used by many UNIX servers right now. You’ll find two common problems working with Web servers from different vendors. First, there’s the problem of data reception. A Web server commonly uses a listener component to pick up SOAP messages and act upon them. If every listener acted the same way, there wouldn’t be a problem. However, there are nuances of difference between SOAP listener ver- sions, so developers often run into compatibility problems. The amount of trouble you run into will depend on the SOAP toolkit you use to create a solution. There are some listener components written in Java that purport to fix these problems, but little idiosyncrasies remain. Another problem is one of translation. Getting the data to the server doesn’t help much if the server can’t interpret it. As we saw earlier, SOAP relies on an XML format to get data from one place to another. What happens if the server is expecting tags in one order and the client provides them in another? Obviously, a smart developer creates components that will interact with the data no matter what order it comes in, but unforeseen problems can occur during the initial design process. Why Make the Move to SOAP? SOAP isn’t a magic bullet designed to kill the problems that plague most of us in a world of ever-increasing complexity. A distributed application requires time and patience to build— a new technology is unlikely to reduce that complexity to any extent. However, SOAP can reduce the difficulty of implementing a distributed application solution by reducing the number of potential problem areas. The mere fact that SOAP makes it easier to move your data through firewalls is enough to use this technology when creating distributed applications. Debugging is another reason to use SOAP. When working with DCOM and other binary technologies, you can’t really see the data flow between machines. You can see the data before the sender transmits it and you can see it once it arrives at the destination, but you can’t see the part in-between (unless you’re very good at reading the binary data in packets). Since SOAP relies on plain text transmission, debugging is easier because you can see flaws in the data transmission itself. Developers who create many distributed applications often cite compatibility as the reason to use SOAP. Using a binary protocol implies that every machine will understand that protocol equally. In other words, if you choose CORBA IIOP to transfer your data, every machine involved needs to speak that protocol. (One kludge that developers use is to write code that bridges translation differences between different protocols such as DCOM and CORBA, but this is an error-prone method of handling the problem.) SOAP promises to provide a platform independent transfer media since every computer speaks plain text. The only requirement is
- 45. 29 Case Study that the computers use the same standard to translate the XML text into data formatted for the application—a much easier requirement to fulfill. A few developers are finding that a hidden reason to use SOAP is development speed. SOAP is a simple protocol when compared to DCOM or CORBA. Not only do you have an opportunity to debug your application with relative ease, but the coding requirements are easier to understand and less error prone. Developers run into fewer configuration related bugs in their applications and spend more time locating real problems. Once SOAP is stan- dardized, you may find that the biggest developer specific reason for moving to SOAP is to get more coding done faster and with fewer errors. Making the developer more efficient always pays big dividends in productivity and developer happiness. Case Study The main reason to use SOAP today is to create distributed applications that run over the Internet. Yes, you can use SOAP for other types of development and it’ll work fine, but SOAP isn’t a cure all for every programming problem on your network. It’s one solution out of many. DCOM and other wire protocols still have a place in your enterprise and you need to keep that in mind as you develop new applications. So, how are some companies using SOAP today? Many of the pioneers are still in the testing stage as I write this. SOAP is an exciting technology, but the standard is still changing on a daily basis, so many companies have relegated SOAP to research for future products. The bottom line is that you shouldn’t rush into a SOAP project because it looks interesting. One company that I talked with recently has begun using SOAP for a mainstream application and for good reason—SOAP really is the only answer in this case. This company has requested anonymity, so we’ll refer to them as ABC Corporation for the purposes of this case study. The fact of the matter is that this company could just as easily be the one that you’re working in now. Definition of a Problem The management at ABC Corporation began looking at the company’s bottom line as profits began to drop in a slowing economy. While ABC Corporation had a great sales staff, a good product line, and relatively competitive prices, in some cases they couldn’t get their product out in time to beat competitors. Taking orders by telephone, filling out paper orders, and the like simply cost the company too much time. Management decided that direct business-to-business sales over a computer connection would speed things up consid- erably and reduce labor costs as well. A faster processing cycle could mean the difference between staying afloat or truly excelling at business. It’s a nice thought and it’ll probably work. The only problem is that the programming staff at ABC Corporation had no idea on how to implement the solution. Their company relied heavily on UNIX servers, while the majority of their customers had Windows NT or Windows 2000 servers. Direct data communication was impossible—at least direct commu- nication in the form expected by management. Automation might prove impossible if the development staff didn’t find a common form of communication. 1 Ch
- 46. 30 Chapter 1 An Overview of Soap At first, ABC Corporation tried the old standby of using forms on their Web site and Common Gateway Interface (CGI) scripts to process the orders. Unfortunately, the installa- tion proved less robust than management wanted. It was also slow, error prone, and didn’t consider individual company needs. Although the system might have worked, no one used it regularly because it was cumbersome and time-consuming—typing out a paper form was still easier. Light at the End of the Tunnel ABC Corporation tried a number of other solutions. All of these solutions failed for one reason or another. The final straw was when they discovered that the Java RMI solution they implemented was too slow and cumbersome. Management decided to call in a consultant. A number of consultants suggested ways to get around the company’s problems, but ABC Corporation finally decided to try SOAP. They decided that SOAP would circumvent the majority of the problems they knew about and the other problems were easy enough to solve using other methods. Development went slow—a concession to being the first on the block with a new solution. However, the company eventually had a workable solution to test. Profitability had to be right around the corner. Perfection, an Ongoing Process Life is often a twisted path, rather than a straight road. ABC Corporation found that their new solution was less than perfect. Compatibility problems between the Windows imple- mentation of the SOAP listener and the Apache version caused a few hours of nail biting as the consultant and development staff rushed to fix the problems. The new code worked around the compatibility problems, performed a few additional checks, and included some more error trapping. While the application was now stable, it did execute slightly slower than before. Sometimes there isn’t a perfect solution, just one that works. The lesson that ABC Corporation learned in this case is that they should have spent more time looking for a SOAP toolkit that works equally well on Windows and Apache. Some of the problems were outside the control of ABC Corporation or their partners. One of the things that SOAP assumes is a perfect network and we all know that the Internet is far from perfect. Although ABC Corporation has improved system up time and provided their partners with alternative means for submitting orders when needed, glitches still occur. They don’t occur on a regular basis, but even one lost order might result in the loss of a customer. The lesson learned here is that you need to build plenty of redundancy into your SOAP implementation and provide alternative communication methods in the case of failure. ABC Corporation also added an email response to their setup. The customer receives an email when ABC Corporation receives the order and another message when they send the order out. This additional communication is completely automated, so it costs ABC Corporation little and greatly enhances customer satisfaction.
- 47. 31 Case Study ABC Corporation plans to roll out their SOAP solution to all partners in about three months as I write this. The testing phase is still ongoing. They currently have a pilot program for several partners and the results look promising. It would be difficult to place a precise date on return on investment at this point. However, ABC Corporation can process orders faster, with less human intervention, and greater customer satisfaction. Just these changes make the bottom line look a lot better. 1 Ch
- 49. SOAP in Theory In this chapter Dissecting the SOAP Message 35 Using SOAP with Your Current Code 45 Discovering SOAP Services 47 Putting Everything Together 50 Using SOAP to Move Data 52 Understanding SOAP Attachments 57 Case Study 58 2 CHAPTER
- 50. Exploring the Variety of Random Documents with Different Content
- 51. They were fond of dividing the thickness, and increasing the apparent intricacy, by giving to each half a different ramification; making for instance two sets of mullions and tracery in one opening, one before the other, and totally without correspondence.[8] They divided the mouldings into separate parts, and placed those of their bases at different heights, one set of vertical mouldings passing between the bases of other vertical mouldings, and the bases of these again, are interrupted by the high plinths of the former bases, as if each penetrated the solid stone, and reappeared again where that did not cover it; many of these fancies are evidently taken from basket work. The remaining fragment of the church of St. John the Baptist at Soissons, belongs to this style, and the new tower and spire at Chartres form a most beautiful specimen. The shrine work that surrounds the choir at Chartres is also an exquisite miniature example, which I shall mention more particularly hereafter. At about two leagues from Chalons, at a small village called L’Épine, is a little church of the fourteenth century. One tower only has been completed, and crowned with an elegant spire; but had the front been finished, it would offer perhaps the most beautiful specimen of Gothic external composition in the world. The arch of the doorway is large; even more so than the usual proportion in French churches,
- 52. and its ornaments reach to the top of the rose window over it. The spire is short, with little flying buttresses at its base. It rises from an octagonal turret placed on the tower. Many of the parts themselves may be thought clumsy, but they are beautifully disposed, and every little defect vanishes in the perfection of the whole. Inside also it is an elegant building, if you except the white wash and yellow wash with which it is at present variegated. The front, including the two first arches of the nave, appears to be somewhat posterior to the rest of the church. If we compare these examples with the buildings in our own country, we shall find the first nearly to correspond with the earliest specimens of what has been called the early English. The eastern parts of the cathedral at Canterbury form the best example I can cite to you; Salisbury Cathedral, and the transept at York, both agree with it in some particulars, while in others they approach to the second French style. Of this, after making some allowance for national differences, Westminster Abbey will furnish you a pretty good idea, or the eastern end of the cathedral at Lincoln. The nave at York would also belong to this style, excepting the vaulting and the west window. Of the third style good examples are rather deficient in England as well as in France; and perhaps it might be considered only as a variety of the second, yet it has a distinct and peculiar character. In our own buildings it is marked by a more complicated arrangement of the ribs on the vaulting; and in general it may be observed, that the English architects paid more attention to the enrichment of this part than the French. After this the two nations held a different course, and I can produce you no parallel to my fourth French style; nor have I met in France with any building like the choir at York, King’s College Chapel at Cambridge, or that of Henry the Seventh at Westminster. I hope this general view of the subject will enable you to comprehend more easily my accounts of particular buildings, but in order to explain myself more fully, I shall request your attention to a very curious building of early date, which has been the subject of much controversy in France.
- 53. The church of St. Germain des Prés claims to be the oldest in Paris.[9] The first edifice was begun by Childebert in 557, and finished in 558, a degree of expedition which does not announce much magnificence; yet we are told that it was in the shape of a cross, and that the fabric was sustained by large marble columns, the ceiling was gilt, the walls painted on a gold ground, the pavement composed of rich mosaic, and the roof externally covered with gold. This description is by Gislemer, a monk of the abbey, who lived at the end of the ninth century, after the church had been twice burnt by the Normans; and perhaps it rather gives us the author’s opinion of what a church ought to be, than what this once was. The building however does not appear to have been totally destroyed, since Morard, who became abbot in 990, perceiving that the repairs since its ruin by the Normans, had been hastily and slightly executed, determined to pull it down entirely and rebuild it; and he is said to have had the satisfaction of completing it, nearly as it exists at present, before his death, which happened in 1014. We learn from the inscription which was formerly legible on his tomb, that he added to the church a tower, containing a bell (signum): this addition may seem to throw some doubt on the extent of the works executed by him. A dedication took place in 1163, but we cannot suppose the building stood complete and useless for all that period. The old cloister was taken down in 1227, and another begun and finished in the course of the same year by Eudes, the abbot. A new refectory was commenced in 1236, and in 1244 the great chapel of the Virgin was undertaken. These were executed from the designs of Pierre de Montereau, and are cited as proofs of his exquisite taste and skill. The Chapter House, and a beautiful chamber which adjoined it, were constructed about the same time, and the dormitory over them in 1273; but all these parts have been destroyed during the revolution. A new cloister was erected in 1555, but in 1579 the church is described as being much out of repair, and though some restorations and alterations were made in 1592, yet in 1644 it was in a most dilapidated and dangerous condition. The nave was covered with the fragments of the ceiling, and in parts with the tiles of the roof; the pavement was so sunk, that it was necessary to
- 54. descend to it by steps; and the vaulting of the transept threatened to fall in. The whole of these deficiencies were repaired in the course of two years, the vaulting of the transept was renewed, and the nave for the first time vaulted with stone. The pillars were ornamented with composite capitals, some of the windows enlarged, a new doorway opened to the south, and an alteration made in the disposition of the choir, which seems to have been the only part of the fabric which had been kept in sufficient repair. As it now stands the church is not a very large one. The inside is low and gloomy;[10] in the nave and part of the choir, the piers consist of four half columns attached to a square pillar, the vaulting of the nave is slightly pointed, but the known recent date of this part renders its form of little consequence, nor is that of the choir of much more historical value. The piers of the chevet are cylindrical. All the arching is round, except that of the chevet, where the French and Whittington say it was pointed from necessity; but this is not very evident: the openings are smaller, but this is not the only way of carrying the arches to the same height. This may be done in the first place by making a Gothic arch formed from two centres, with a larger radius than the semicircular arches, (a pointed arch with the same radius would not rise so high) or with an arch from two centres, and the same radius on a base somewhat more elevated, or lastly, by a semicircular arch on a much more elevated base. The following diagram will explain this better than words. To judge by the eye, the arches of St. Germain des Prés lie nearly in the middle between the second and third, i. e. between b and c. The base is considerably elevated by a perpendicular line continued above the capital, and the radius of the curve is smaller than that of
- 55. the semicircle of the arches in the square part. As the architects have in some degree availed themselves of this elevated base, it is evident that they might, by doing it a little more, have preserved the semicircular form, and they must have been conscious that they had it in their power to do so. There is no gallery along the nave, but we find one round the choir, with square-headed openings. It has been much disputed whether this was, or was not the original form. M. Du Fourny contends, that as the first ceiling was of wood, and probably flat, it was highly natural that they should make these openings square-headed; but I think he is wrong. On the two towers at the entrance of the choir, we see openings, the lower parts of which are exactly similar to those abovementioned, and they are divided in the same manner by a little pillar; but these are arched above. It is probable that the arches have been removed in order to make room for the windows of the clerestory above, which in fact come down to them, but of which the lower part is filled up. All the windows are round-headed, (except those of the little chapels) without tracery or division of any sort, ornamented with a billetted moulding externally, and entirely plain within. Those of the chapels are pointed, but with the same ornament, and equally without tracery. There are some Saxon (or Norman) arcades below these windows; but there can be no doubt that these chapels in their present form (exclusively of the vaulting) are somewhat posterior to the church. The vaulting of the aisles is circular, and remarkably arched on the ridge, so as to present nearly a succession of portions of domes. The capitals, as usual in the Norman architecture, are very various, some resemble baskets, others are formed of a collection of figures of animals: some bear a resemblance to the Corinthian, but the masses are smaller in proportion to the size of the capital, and the relief less strongly marked. In this I think the artist judged rightly, and that the looseness of the Corinthian foliage would have been inconsistent with the massiveness of such a pillar. Here are also some decidedly composite capitals under the vaulting, but these were probably introduced in the repairs of 1644. Whittington says, that the proportions of the columns of the choir approach nearly to those of
- 56. the Corinthian order. The shafts of the latter have full eight diameters in height: those of the former about four and a half. The western tower is entirely incrusted in a wall of modern masonry except at the top, where we may observe a story of what we call Saxon architecture, with circular headed windows divided by little columns. In the other two towers, which flank the clerestory of the choir, the arches are also semicircular; but the openings are separated by piers, not by columns, and the workmanship of both, though somewhat differing, is more rude than that of the western tower. Judging by the little portion still exhibited, I should conclude this the latest of the three. Yet, as the masonry of these two ruder towers forms an essential part of the edifice, and the aisles are continued through their lower story, without exhibiting any difference of style in that part, we can hardly suppose them prior to the rest, more especially as the arches of the recesses, corresponding with the gallery of the choir, are surmounted with pointed arches. I cannot attribute this form to any alteration, because these arches do not correspond in style with any other restoration of the building. I must therefore be content to attribute the body of the church to Morard, excluding the vaulting, and to doubt about all the rest. The western portal of this church exhibits the pointed arch. It is at present ornamented with shafts set in reveals, but some of them are restorations, and occupy the place either of statues, or of columns with statues attached to them: above is a series of ten small figures, whose faces have been broken by the Iconoclasts of the eighteenth century. The lower figures have been adduced as proofs of the antiquity of the tower, because they are supposed (two of them at least) to represent the family of Childebert, but the conclusion certainly does not follow from the premises, and I have no doubt that this portal, ancient as it is, was posterior to the body of the church. To make a theory for the chronology of this edifice from the dates we find in books, compared with the evidence of the architecture, we may suppose the bulk of the western tower to have been built in the eighth century, but nothing of this work remains
- 57. exposed to view: the body of the church, northern tower, and lower part of the southern tower by Morard, between 990 and 1014: the upper part of the southern tower very shortly after. The upper part of the western tower followed. The western portal was certainly posterior to 1028: the reasons for fixing on this date are derived from the cathedral at Chartres. Bulliart does not give any representation of the arch of this doorway, and Whittington’s whole theory seems to indicate that he supposed it semicircular. I shall resume this subject in my observations on Chartres. I have kept you so long vacillating about St. Germain, that you are tired of it, and so am I. After all, one derives but little satisfactory evidence from a building so rude, and so frequently altered, but it has been strongly pressed into the history of French architecture, and I could not pass it over; and now, after this terrible digression, I will return to the church at Nôtre Dame, at Chalons, an edifice in many respects similar, but of a much more finished construction, exhibiting more of its original form, and to judge from a comparison of the internal evidence, of a date very little later. It is an excellent specimen of what I have called the first style of French Gothic, but it is not entirely free from alterations. This church is said to have had formerly eight towers, and as many spires. I cannot make out the places of more than four; two at the end of the nave, and two at the entrance of the choir, immediately beyond the transept. Such an arrangement seems not to have been unfrequent; but here, both in this building, and in the cathedral, these towers flank the aisles of the choir: at St. Germain’s at Paris they abut upon the clerestory, and the aisles pass through them. On one of the towers in front, there is a wooden spire, the general form of which is an acute octangular pyramid, with a small square pyramid on the spaces left at each angle of the tower. This is the arrangement of the pinnacles over the buttresses of the cathedral of Rheims, but it has nothing to do with the Saxon towers of this building. The style of these towers much resembles the summit of the western tower of St. Germain, but is more ornamental, the semicircular headed windows being divided by groups of little columns, and the parts subdivided by a
- 58. detached column. The projections are remarkably bold. There is no pointed arch in any of these towers inside or out, except in the upper story of two of them, and here they are without doubt of a later date; and the architecture of the church, which is mostly pointed, is not so united to the towers as to bring in the parts with perfect regularity. There are two stories of aisles to the nave as well as to the choir, and in some points of view the effect of this is so pleasing, that I feel quite reluctant to condemn it. The upper story cuts in places some ancient mouldings. In this vaulting a is the lowest point of the ridge, b is somewhat higher, and c still higher. The piers of the chevet are circular, with capitals in some degree resembling those of the Corinthian order, and the slender detached columns behind the choir have, still more nearly, Corinthian capitals and proportions. They present something peculiarly graceful and pleasing in their appearance. As they certainly do not appear calculated to sustain the thrust of an arch, it is difficult to shew a reasonable ground for the admiration one cannot help feeling. The union of circular chapels with the circular end of the choir and its aisles, each part having its ornaments exceedingly well disposed, is also a beautiful circumstance in the external view; but it is rather conceived than seen in this instance, as the outside is much encumbered by small houses, and there are some enormous plain buttresses, on the date of which I will not pretend to decide: if they are posterior to the church, the original ceiling must have been of wood. The pavement is almost entirely composed of old monuments engraved in stone, exactly in the manner of the brass plates in England. Many of them represent the architecture of the thirteenth
- 59. and fourteenth centuries: one or two, from their extreme simplicity, may be taken from the architecture of the twelfth. There are none in which the arch is not pointed, and the trefoil ornament is always exhibited. Amongst, I dare say, two hundred monuments of this sort, I observed only one figure in mail, and that I could not find again on searching for it; and a fragment of one in plate armour: the earliest date is 1201, but the figures are not perfectly clear. There are also tombs of a blue stone, inlaid with white. I longed for Mr. L.; here were materials for an excellent lecture on the progress and changes of dress among our forefathers. I do not know that there is any thing amongst them which might not be found in England, but at the same time I know no place in England where there is such a collection of costumes. The cathedral at Chalons has a tower at each end of the west side of the transept, a disposition not at all pleasing. Parts of these towers seem to be of the same date with those of Nôtre Dame, but they have been altered and added to in the seventeenth century, at which time the present vaulting, the two spires, and the whole of the west front, were erected by the Cardinal de Noailles. The body of the edifice appears to belong to the thirteenth century. Its nave has four ranges of windows: those of the clerestory; those of the galleries or triforia, great part of which are opened into windows; of the aisles; and of the side chapels. The last form no part of the original design; they are very low, and it would be an improvement to take them away. The slender spires which surmount the old towers, are perforated in all directions; and though they cannot be much praised, have something of a light and elegant effect. There is a considerable quantity of good stained glass in Nôtre Dame, and some likewise in the cathedral, but not so much; and the great rose window at the west end of the latter is entirely without it. I was in the church in the evening when the setting sun shone full into the building, and produced a painful glare, instead of the rich mellow splendor of painted glass in similar circumstances. Chalons was the first place where I observed in common use the semicircular tiles, which are usually shown to us in Italian
- 60. landscapes, but they were small and ill laid, and had a crowded effect. We left Chalons early on the morning of the 30th of April, and for the first six leagues saw nothing but a boundless common field. The diligence does not change horses, but stops to rest them for an hour or two in the middle of the journey. The harness was partly rope, and partly leather, and some of the traces were chains. The rope traces are rather apt to break, because no one thinks of putting new ones, as long as there is any chance that the old ones will hold out the stage, but the chain traces are worse. They are originally slight, but when a link gives way its place is supplied by a bit of leather; this seldom lasts long, and it is not uncommon for it to give way a second time in the same stage, but with the most heroic perseverance the postillions apply another piece of leather. I have not yet met with the phenomenon of an iron chain entirely of leather, but I hope to see some considerable approach to it. The latter half of the ride presented to our view a range of hills, about two miles distant on the left, not very high, but steep and broken, the upper part mostly covered with wood, and the lower with vineyards. These hills form the edge of the materials occupying the Paris basin, which every where exhibit a strong contrast to the rounded swells of the chalk country. There were also some little hills on the right, but these were naked, except a few groups of trees at the base. This, though not a beautiful landscape, was a considerable improvement on the shelterless plain of the morning. There was something at least to amuse the imagination, but it did not last long, and we returned long before reaching Rheims to the usual expanse of common field.
- 61. H LETTER IV. GOTHIC ARCHITECTURE. Paris, May, 1816. aving conducted you to Rheims, I now proceed to give you an account of what I saw there, and if it should contain a few digressions as long as those in my last, I hope you will forgive me, for this Gothic Architecture offers continual temptations to lead me out of the direct road. I shall begin, not with the cathedral, but with a much more ancient building, which is supposed to have served as a cathedral before the present edifice was erected. The church of St. Remi is said by Whittington to have been dedicated in 1049. I know not whether he mean the nave or the choir, but they are certainly of different periods. The Recueil des Abbayes, &c. says it was built in the time of Charlemagne, and consecrated by Leo IX., who was pope from 1048 to 1054; the nave, except the vaulting, is much in the style of St. Germain des Prés, at Paris, but the pillars are of various shapes, and do not seem the result of one design. There are two stories of aisles to the nave, and to the straight part of the choir, and above these are the principal windows of the clerestory, with semicircular heads, and over them a range of circular openings, which I do not recollect to have seen elsewhere. The buttresses, externally, are alternately semicylindrical with a small projection, and rectangular with a very considerable one; the first are parts of the original structure, and evidently denote the roof to have been of timber, and not vaulted; indeed all the vaulting appears to be posterior to the walls and piers; the latter were probably added at
- 62. the same time with the vaulting which rendered them necessary. The middle of the western front is a restoration, in which many old parts have been re-used, and the fragments of marble and granite render it probable that the spoils of some Roman building were employed in the ancient edifice. The two old towers remain, the southern doorway, and the window over it are beautiful specimens of what I have denominated in a former letter, the third style of Gothic; and are probably of the fourteenth century. The choir is of the first style, very much resembling that of Nôtre Dame at Chalons, and though this church is certainly inferior in general effect to the one just mentioned, yet some of the partial views it presents are, I think, superior to any thing there. The flying buttresses of the choir are supported, on their first separation from the building, by a little column; and a narrow gallery, which surrounds the clerestory, passes between these columns and the body of the church. The same disposition prevails at Nôtre Dame at Chalons, at Amiens, and at the cathedral at Rheims. There are some granite shafts of columns in the church, which have perhaps belonged to an ancient temple. Under this church is a crypt, where we are shewn the tombs of Clothaire the First, and of Sigismond, king of Burgundy. The former died in 561, probably at Soissons; the latter was thrown with his wife and family into a well at Orleans, and we should not certainly expect to find him in the same chapel with one of his principal enemies at Rheims. A simple vault, or succession of vaults of small dimensions, can give us no internal evidence of the time of its construction. And now, in order to preserve something of a chronological order, let me transport you from Rheims to Mantes, where I have since seen a church which is a puzzle for the antiquaries. Whittington says that it was built by Eudes de Montreuil, and I understand him to quote Millin for the assertion; but I cannot find the passage in that writer. On the contrary, Millin tells us that it was built by the same architect who built Royaumont. Now, Royaumont was finished in 1228, sixty-one years before the death of E. de Montreuil, which took place in 1289. The first church which was erected at Mantes is
- 63. said to have been built in 865, but it was destroyed by William the Conqueror; and we certainly see at present no remains of any edifice of that date, yet Millin seems inclined to consider the northern doorway of the western portal as part of the original construction. Altogether this church has the appearance of a building that has undergone considerable alterations at different periods. In what I take to be the original work, the nave has two stories of aisles, the end of the choir is round, and the windows are without tracery. In the clerestory and in the lower aisles the windows are pointed; in the upper aisles they are entire circles; all have Saxon ornaments externally, and are quite plain within. All these circumstances indicate a style prior to that existing at the beginning of the thirteenth century, which is the date generally assigned to the edifice, under the auspices of Blanche of Castille, mother to Louis the Ninth. Two towers have been added at the west end. The southern, which is said to be the most ancient, is a very strange composition of slender Gothic. The upper story but one is surrounded by a colonnade, if the expression be admissible, of two ranges of columns, one above another, without either arch or architrave between them, but merely connected with the wall by a stone slab on each capital of the lower range. The upper range supports arches, on which rest several unconnected slabs, steeply sloping, wrought into scales, and conducing neither to the beauty, the strength, nor the shelter of the edifice. The north-west tower, built, according to the tradition of the place, three hundred years after the other, is much less light in its construction, and not much more handsome. It would rather appear more ancient than posterior to the first, if there were any difference, but the summit is comparatively modern, and this has probably given birth to the opinion that its date is so much posterior. Many of the chapels appear to have been built in the thirteenth century, at which time the vaulting of the nave and choirs was perhaps added, and some of the windows of the upper aisle were altered from their original circular form, into that which they now bear. Later still (in 1405) the porch of the southern door of the
- 64. western entrance was erected. It is very beautiful, and is the only part of the edifice which is so. Besides these, are a great many other incongruities which are probably assignable to different periods. The vaulting is with oblique groins, as at Beauvais. You know, that in oblique groining, the piers are usually alternately larger and smaller. In this church, the direct arch between the greater piers seems to be formed on an equilateral triangle, or nearly so, rising on the capitals of the shafts; but on the smaller piers the perpendicular line is continued considerably above the capital, and the direct arch between them is consequently very obtuse. Perhaps it was this whim which attracted the admiration of Sufflot, who is said to have been lost in astonishment at the hardiesse of the vaulting, although the nave is only 34 feet wide. The boldness of the architect is however sufficiently conspicuous in other respects, for the piers of the chevet are only 1 foot 11 inches in diameter, to support a vaulting which rises 102 feet 6 inches (English measure) from the ground. One of them is consequently crippled, and has been banded and supported on every side with iron. M. Gabriel, one of the companions of Soufflot, in his examination of this church, contends that the six columns of the chevet might all be cut away, and that nevertheless, by the scientific disposition of the stones, the upper part and the vaulting would remain secure: this indeed would be something wonderful. All the arches of the nave and choir are pointed. So much for Mantes, but I have still to trespass upon your patience before I bring you back to Rheims, with an account of a building, which from its early date, its peculiar architecture, and its great magnificence, I consider the most interesting specimen of the Gothic style in France, or probably in the world. I had conceived, from what Whittington says of it, pp. 54, 55, 57, that I should find a building of the Norman taste, but this is not the case; Chartres is decidedly Gothic, of a peculiar manner indeed, but such as one would suppose posterior to all the three edifices above described. There are some additions to the original building, but these are extremely well marked, and the mass of the edifice is so clearly the result of one design, and the production of one period, and the time
- 65. of its erection is so well authenticated, that it takes place of all other cathedrals in antiquarian interest, and yields to few in beauty. Let me relate to you what information I have been able to pick up on the spot, it may help you to form some idea of what one has to wade through to arrive at any satisfactory results in the history of French Gothic. I first bought a little book of the history of Chartres, in order to obtain the dates of the different parts, but I learnt from it little of what I wanted to know. The author begins by telling us, that the ancient nations of Gaul were the most religious people in the world, and that the innocence of their lives, and the holiness of their priesthood, made them worthy to participate in the most important revelations, and to have the future incarnation of the Word shewn to them, long before it was accomplished. There were, he says, three classes of people to whom this communication was made, the Magi, the Sybils, and the Druids. The first learnt it by their knowledge of astrology, the second received the gift of prophecy in recompense of their virginity, and the Druids knew by a prophetic spirit rather than by any fortuitous prediction, that a virgin would one day bear a son for the salvation of the world; and they consequently raised altars in several places, inscribed virgini parituræ, (did they write Latin?) and amongst others there was a very celebrated one at Chartres. When afterwards Christianity was preached in these parts, there were three circumstances of similarity in the Christian and Druidical rites, which greatly facilitated its progress. The worship of the virgin, who, according to their traditions, was to bring forth a son; the offering of bread and wine, usual in their sacrifices; and the adoration of the Tau, that is, of the cross. The Christian service was performed at the ancient altar of the virgin, and crowds thronged from all parts of the universe to present their offerings. The present cathedral is built over the grotto where this altar formerly stood. The most famous relic here was the shift of the virgin, which was stolen from a Jew widow by some pious patricians of Constantinople. It was taken from them by an emperor, whose piety was, I suppose, of the same sort, and presented to Charlemagne, who brought it to Aix. It was removed thence by Charles the Bald, and given to the
- 66. cathedral at Chartres. This relic has of course performed abundance of miracles, but most of these are what would be called by many people in England special providences. And, if amongst us, we had no division into sects, would not these special providences soon become to be considered as miracles, and alleged as proofs of the truth of particular doctrines? We have no reason then to pride ourselves on our freedom from such superstitions, as it depends on circumstances over which we have no control, but much cause to be thankful, not that we have this or that form of worship, but that we have the liberty of thinking for ourselves on religious subjects. This book is not an antiquated work: it was printed in 1808, and may serve to prove, that whatever injury the revolution may have done to religion in the minds of the French, it has by no means rooted out superstition. There is a public library at Chartres, containing between twenty and twenty-five thousand volumes, and I there found a history of the city deserving more attention; although even in this, the author employs 200 pages in telling us what happened before the arrival of the Romans. This folly seems as strong in France as it is said to be among the Welsh; and many of the local histories are prefaced by an account of Samothès, the son of Japhet, who first peopled Gaul, and a long series of princes, who gave successively their names to the Druids and Bards, to the Celts, the Gauls, and even to the Francs. These, instead of being a German nation, were the subjects of Francus, the son of Hector, called Astyanax and Scamander by Homer, who came to France and married the daughter of Rhemus, king of Rheims. It was only a return to the land of his forefathers, for Dardanus, the founder of the Trojan line, was a Frenchman. But to return to this History of Chartres, which was written by a M. V. Chevard, and printed at Chartres. It assures us that the old cathedral was burnt in 1020; that Fulbert, who was then bishop, began the present edifice almost immediately, but that it was not completed at the time of his death, in 1028, although it appears to have been considerably advanced. We are even told that it was finished before the middle of the eleventh century, but this word is
- 67. often used very loosely in the accounts of Gothic buildings. Matilda, wife of William the Conqueror, who died in 1083, covered the main body of the edifice with lead. The basnef, the towers, and the west front, were finished in 1145. The south porch was added in 1060, by Jean Cormier, or Jean Le Sourd, physician to Henry I. of France. The famous steeple is one of those of the western front. The place was formerly occupied by a wooden one, but this being burnt in 1507, gave rise to the present, which rose almost immediately from the ruins. I had heard so much of the height of this steeple, that the first view of it disappointed me in this respect, but the great elevation of the body of the building in the French churches, effectually prevents any such extreme impression of height as is produced by the spire of Salisbury Cathedral; or, at least, the elevation must be indeed enormous to occasion it. The vaulting of these edifices is more lofty, and the space between that and the timber roof is much greater than is usual in England; indeed, sometimes in our churches the direct tie-beam is omitted, in order to bring the vaulting absolutely into the roof. The roof itself is also higher. Altogether the ridge of the roof at Chartres must be full 50 feet higher than that at Salisbury, and 50 feet added to the mass of the building, and taken from the spire, will greatly diminish the apparent elevation of the latter. The height of the edifice is very much lost in its bulk. It even forms a base for the lighter part, and in some degree a standard by which to measure it. Afterwards, however, in walking round the town, and seeing the cathedral in different points of view, I gave to the height its full value. The impression was not that of a very high steeple, but of a very lofty church: an effect greatly enhanced by its fine situation, on the summit of a hill, with the town collected at its foot. The whole height of the new spire is 403 English feet. The upper part of the tower and the spire, are of the most light and beautiful work imaginable. The ornaments are executed with the greatest delicacy, and in entire relief, the stems of the vines, and the bunches of grapes which enrich the mouldings being entirely detached, and the work suspended merely by the extremities of the leaves; and all the veins and ribs are shown as if they were to be seen at hand, instead of at an elevation of 300 feet. Even parts, which cannot be
- 68. seen at all from below, are finished with the same care. The staircase, by which one ascends this spire, forms a little tower of itself, also of open work, quite independent of that which supports the spire. The opposite spire is much more solid and simple in its form, and seems to be part of the edifice of Fulbert; its height is 365 feet, and its appearance is more like that of Norwich than any other English spire I am acquainted with, but the resemblance is not at all continued in the tower which supports it. There are several pinnacles rising above the base of the spire, and the whole composition is more Gothic than at Norwich. As the cathedral was two or three times destroyed by fire, before it was erected in its present form, i. e. before the time of Fulbert, it is possible that some of the lower part of this tower belonged to an earlier edifice; the pointed arch is however exhibited in it. The whole western front is very beautiful. The porch is ornamented with statues and columns, as at Rheims and Amiens, but not in such profusion, nor is it so deep. The execution is also more stiff and rude, and the resemblance is probably much stronger to the western doorway of St. Germain, as it existed before the revolution, than to either of these buildings. Some of the statues are merely stuck to the little columns behind them, under others there is a projection to receive the feet, but very small, and apparently insufficient. Over them are small canopies, which are likewise attached to the shaft of the column. The capitals of these columns, instead of foliage, are formed of little figures, with canopies over them, surmounted by what have the appearance of little models of large buildings. It is remarkable that, although the arches of this doorway are somewhat pointed, yet the architecture represented in the models never is so. In the south portal, on the contrary, which I shall describe by and by, where these models are tenfold more abundant, a considerable number have pointed arches. This circumstance seems very extraordinary if this western doorway was built, as is asserted, eighty-five years after the southern porch. Over the great door is a triple window, the middle division being the largest and highest, the only instance of this disposition in the building. Above this is a magnificent rose window, but of simpler arrangement, and a larger portion of solids than we find in those of
- 69. a later date. The windows of the nave and choir are also terminated by a rose, but with this singular difference, that in the great roses the exterior is ornamented with mouldings, while the internal faces are plain; in the smaller ones, on the contrary, the internal faces are moulded and the outside is plain. The southern porch is very curious on many accounts. It was built, as I have already said, in 1060, by Jean Cormier, physician to Henry I. This date is important, because it seems exceedingly well authenticated, and the addition of the porch proves the church, if not finished, yet to have been in a state of great forwardness at that period. There are openings, not arched, but square-headed, combining all the parts of this porch into a sort of open portico. It abounds with detached shafts, of which there are none within the church, with large and small figures, and with models of architecture, in some of which, as I have already remarked, the pointed arch is exhibited. The arches of the porch itself are all pointed. The footstools of the figures are usually themselves grotesque human figures, and many of them with crowns. These statues, and the canopies over them, are much better managed than in the western front. They are rudely finished, but the labour bestowed on the lace of some of the garments shews that this rudeness was the effect, not of negligence, but of want of skill. The foliage of the capital of the columns spreads over the underside of the canopy. Above the porch is a range of five windows, of equal size and height, and over these a rose window. In the transept at Amiens, the angular spaces between a similar range of arches, and a circle above them, are opened, and form additions to the rose window; here they are closed, and no attempt is made to unite them. There is, as usual, a gallery in front of the gable, and at each end of this gallery is a small octangular tower, surmounted by a spire. This seems to have been a common mode of finishing in the early French Gothic; it occurs at a church in Soissons, which bears all the marks of antiquity; and in other places. The general opening of the windows, both in the clerestory and aisles, in this church, is round-headed, but they are divided by a large plain mullion (such as
- 70. I have never seen elsewhere) into two parts, each of which has a pointed arch, and over them is a rose. It was, perhaps, part of the original design to have a tower on each side of each end of the transept, and one on each side of the choir, but the parts which are now exhibited of these towers, above the roofing of the church, seem to be of later date; none of them are finished, and what has been performed of the two latter does not correspond with the work of the other four. These are ornamented with numerous little shafts, extremely long and slender, most of which are united to the solid masonry, but those at the angles are detached, in order to give an exaggerated appearance of lightness. I imagine them to be posterior to those of Nôtre Dame, at Paris, but earlier than those at Rheims; but among the various efforts which ultimately completed the first mentioned of these churches, we cannot determine during which the towers were built, and the priority of date is left in great uncertainty, for the style of building is not decisive, or rather, I have not sufficient knowledge to be able to determine it from that character. The northern front of the cathedral at Chartres presents a similar style of ornament, but without the projecting porch, which makes so important and interesting a feature on the south. Chartres is very rich in painted glass; in this respect it far exceeds any other cathedral I have seen; the colours are deep, without losing their brilliancy, and the light is stronger than at Rheims, although the windows of the aisles, with only one or two exceptions, are painted, as well as those of the clerestory. The glass is said to be half an inch thick; I believe this is not much thicker than some of the old glass in York cathedral. Many of the windows contain escutcheons. This church is 461 feet long internally, and the vaulting is 113 feet high, the piers of the nave are composed alternately of octagonal pillars, with four circular shafts attached to them, and of circular pillars, with as many octagonal shafts attached to them. All the arches and the vaulting are pointed, except perhaps (and of this I am not sure), that the cross vaulting of the nave may be of circular arches. The construction of the roof has been much praised, but it is not good;
- 71. the timbers are all small, and the trusses are very close together. At the point of the choir there is as usual a maître poutre of immense size, which you are told supports the whole roof, but which in fact supports nothing, being itself suspended by the converging rafters. There is a space of about six feet between the tie-beam and the top of the vaults. SHRINE- WORK AT CHARTRES. London. Published by J & A Arch. Cornhill.
- 72. March 1st . 1828. The single story of side aisles, the polygonal end of the choir, the piers which support the groins behind it, and the windows of the choir single, and not disposed by threes, all unite to refer this building to the second style of French Gothic; which the greater massiveness of the work, and the presence of some circular arches in the towers, might otherwise render doubtful. The single story of aisles and the greater height of the building seem to indicate a later period than Nôtre Dame at Paris, but on the other hand the smaller windows, surmounted in the nave by a single rose, the more solid divisions of the great rose windows, and the style of finishing externally, announce an earlier stage of the art. If I had to estimate the date from the architecture, I should be very much puzzled by many peculiarities, either very rare, or not met with elsewhere; but on the whole, excepting a portion of the towers, I could not have placed it before 1150. With good proportions, beautiful parts, and finely coloured windows, you will conclude that the whole impression produced is sublime; but I wish I had you here, where you would find some better proof of this, than the cold conviction of your reason. The people seemed very devout, and were all day long kissing the pedestals, and various parts of the decorative architecture, about a figure of the virgin, which is almost black. In this part of France the virgin is usually represented with a very dark complexion; and such is, I believe, the case with the most popular images of her in all Catholic countries. There is a labyrinth in the pavement which is said to be a league, measured along all its folds; a countryman applied to me to know if this was true. I told him it was impossible, and shewed him that the number of turns, multiplied by the length of the middle one, only gave 1320 feet, but he was determined to believe as his fathers had believed before him.
- 73. I must not quit the cathedral without mentioning the beautiful shrine-work which surrounds the choir, to see which is alone well worth a journey to Chartres. It consists of forty-five compartments, forming a sort of continued gallery, and contains in all about two hundred and fifty figures, each of three feet high. It is a very curious specimen, both for the extreme delicacy of the workmanship, and as a model of the last period of Gothic architecture in France. It is complete point lace in stone, and some of the threads are not thicker than the blade of a penknife. The style is rich and beautiful, or at least many parts are beautiful; but as a whole, it wants simplicity, and is inferior in design to the architecture of King’s College chapel at Cambridge, and perhaps even to Henry VII. chapel at Westminster; but the extreme intricacy of the multiplied ornaments in the last-mentioned building does not please me. In the work at Chartres the disposition of the masses is much more simple and intelligible, but the tracery and detail of the ornaments are even more confused. It is worthy of notice that the vaulting continues entirely simple, and without any trace of the palm-tree branching, exhibited in that of King’s College chapel, or of the still more complicated arrangement of that of Redcliff church at Bristol. This fine work is in two series, the first of which is said to have been executed with the surplus of the money raised for erecting the spire. It is precisely of the same style as that erection, if we make allowance for its greater delicacy, adapted to the different nature of the work; but no dates are marked on it: this forms the largest part. The second series exhibits some traces of the knowledge of Roman architecture, and has dates from 1523 to 1530. This is ornamented with arabesques in imitation of the Italian cinque cento. I observed two dates of a later period, T. Bovdin Mil vi c xi, and a similar inscription of 1612, but there is no difference of style to account for them. I was led by the accounts of Chartres to suppose I should find some vestiges of very high antiquity in the crypt under the cathedral, but I was disappointed; there seems to be nothing but what is coeval with the building, and the vaults do not extend under the
- 74. whole edifice, but only under the chapels and side aisles. The people in this neighbourhood are more unfavourably disposed towards the Bourbons than those who live to the east of Paris. A woman observed that I was one of those who had brought back Louis XVIII. She had nothing to say against them or him, but the tones of her voice did not promise that she would say any thing for either. The conducteur of the diligence perhaps was not a Napoleonite. “Whether God or the devil, Napoleon or Louis XVIII. be on the throne,” he observed, “the laws should be obeyed. There were revolutions in France before this, of which they talk so much; for instance, in the times of Charles V., who drove the English out of France; and if the French were now as devoted to their country as they were then, these things could never have happened.” I could not be displeased with any Frenchman for a feeling of soreness at the interference of foreigners in the affairs of his country, however political circumstances may have required it. The two churches last described, and that of Nôtre Dame at Paris, may be considered as belonging to a style of Gothic, intermediate between the first and second of those I have enumerated; and as I wish to give you a sort of historical series elucidating the progress of architecture, I shall here introduce some account of the French metropolitan edifice. This is said to have been originally founded by Childebert, in 522. It had 30 marble columns, and very large windows, according to the account left us of it by Fortunatus, a cotemporary poet.[11] This description, however, has nothing to do with the present building, which was commenced in 1010 by Robert the Pious. After his death it was neglected, and little was done till 1165, when Maurice de Sully, a liberal and munificent prelate, filled the see of Paris, and to him we seem to have been indebted for the greater part of the edifice. He destroyed the old church of Childebert, which had existed till this period; and in the year 1181 the eastern part was so far advanced, that it was consecrated by Henry, the Pope’s legate, and by the bishop himself, who died the next year. Odo de Sully succeeded, and prosecuted the work with great zeal till his death in 1208, so that for forty-three years from
- 75. the resumption of the work, it was carried on with spirit, and we must suppose a large portion of it was completed. Pierre de Nemours, who died in 1220, is thought to have finished the nave and western front. The last figure of a king exhibited in its galleries is that of Philip Augustus, who died in 1223, and this is one reason for supposing it finished in his reign, but it is not a very strong one. The south transept was not, however, begun till 1257, as we are informed by a Gothic inscription on the porch, and an ancient church of St. Stephen was then destroyed to make room for it. The present rose window was renewed on the model of the ancient one in 1726. The date of the north transept is unknown; it probably preceded the south; but its porch and chapels are assigned by Le Grand to the fourteenth century. The front is heavy, but not so heavy as usually represented in engravings; I think this appearance arises in part from the square solidity of the towers, and in part from the horizontal lines being marked too strongly, a circumstance which always produces a bad effect in Gothic architecture. I have not been able to determine whether it was intended to crown these towers with spires: I am inclined to answer in the affirmative, but rather from analogy than from direct proof. According to Landon there were twenty-five statues of kings in the arches over the western porch, viz. thirteen of the first race, nine of the second, and seven of the Capetian. They entirely filled one range of arches and no more. Now there are two ranges of arches above the doorways in this front, the lower of which, according to the elevation given by the same author, presents twenty-four niches, and the upper twenty-six. Query, how many statues were there, and where did they stand? Felibien, in his plate of the elevation, which is much better than Landon’s, figures twenty- eight niches in the lower arcade, viz. nine in the middle, seven on one side, and eight on the other, and four on the buttresses. The upper arcade is a gallery not intended for statues, the middle part of which is open on both sides. The arches of the lower range have trefoil heads, and appear from below to be entirely composed of models of architecture. The canopies of the portal abound also with
- 76. models of architecture, resembling in this, and in the style of sculpture, the south portal at Chartres. Perhaps the design of these, though not the execution, may be attributed to the time of Maurice de Sully, in 1165, but this brings the date a century later than that of Chartres. I wish very much to discover that the south porch in that cathedral was of 1160, instead of 1060, but I cannot persuade myself that the physician of Henry I. lived to build it a hundred years after his sovereign’s death. The Matilda mentioned as having contributed to the church, may be the widow of the emperor. Whittington says, “The eastern end, which is triagonal and very plain, was probably one of the first Gothic structures in France (1168). This plainness, from a proper regard to uniformity, was maintained in the subsequent part of the building, excepting in the chapels, which are of later date;” this I do not comprehend; the eastern end is semi-circular, and is richly ornamented externally with slender shafts, and spires of different heights, which may perhaps have been added at the same time with the chapels, if these are indeed posterior, but assuredly they do not make part of them. It seems to me that those parts which remain without ornament have never been completed, for they exhibit abrupt terminations, which were not in the taste of the Gothic architects at any period. All the flying buttresses are exceedingly slender, and altogether the construction of Nôtre Dame may be considered as among the boldest, and most successful, existing in Gothic architecture; although even here we find some traces of the too great operation of the thrust of the arches of the side aisles. On entering Nôtre Dame one is struck with the double range of side aisles and open chapels besides, making an entire width of seven divisions, instead of five, as at Amiens, or three, as in our churches. It is generally supposed, that if two dimensions of a building are great, they will appear of less magnitude if the third be great also. For instance, in a very large building, great height will diminish the apparent extent in the plan, great length will diminish the apparent width, and a narrow room will look higher than a wide one of the same height and length. Yet certainly the impression of
- 77. space is much less at Nôtre Dame, than in the narrower and loftier edifice at Amiens. One of our travellers has estimated the size of Nôtre Dame as about half that of Westminster Abbey; and some non architectural friends with whom I have talked on the subject, thought that he perhaps underrated it, but that certainly the French building was much smaller than the English. Nôtre Dame is 416 feet long internally, and 153 wide: the length of the transept hardly surpassing the width of the nave and side aisles. Westminster Abbey is 360 feet long and 72 wide. The transept, indeed, is 195 feet long, but the whole internal area of the French building must be at least twice as much as that of the English. Whence is this very false estimate of its size? Does it depend merely on the injudicious arrangement of the parts, or is it in some degree to be attributed to a patriotic determination to find every thing best in our own country? Here are two stories of side aisles, and this double range, and the very slender columns which divide the openings of the upper, are in some points of view very pleasing. There are three arches over each of the larger openings below, united into one common arch; but the space included between the three smaller arches and the larger one is a blank wall. This has a very bad effect, especially as it is a part in which we are accustomed to expect ornament; indeed the arrangement of this gallery is inferior to that before noticed in Nôtre Dame at Chalons. The vaulting of the nave and choir is with oblique groins, as at Beauvais and Mantes. The vaulting itself, according to Millin, is only 6 inches thick. With the cathedral of Nôtre Dame I conclude what I had in my mind to say to you of the progress of Gothic architecture, previous to its full development in the cathedrals of Amiens and Beauvais. Another proud specimen of architecture of that period is found in the cathedral of Rheims. It was founded, we are told, in 818, but I have some doubt whether the early structure thus spoken of was not the church of St. Remi, and not one occupying the site of the present cathedral. It was burnt in 1210, together with great part of the city of Rheims. A new cathedral was immediately begun, but the ancient crypt was left; now we are not shewn any ancient crypt at the
- 78. cathedral, but there is one at St. Remi. The work went on with great rapidity, for the altar was dedicated on the 18th October, 1215, and the body of the church was finished in 1241. It appears probable that this finishing does not include the famous western front, which however was completed before 1295. Thus you see the bulk of the building was erected in thirty-one years; while at Paris two active bishops could not bring theirs to so forward a state by forty-three years of persevering exertion, although the foundations were previously laid, and probably a considerable quantity of materials prepared, and although the transept was not included. The size was not much greater, and the expense must have been decidedly less, on account of the inferior richness of the latter building. This difference is rather surprising, especially when we take into consideration, that the Parisian bishops had the support of the monarch. Of the portal, or west front, the plate in Whittington is the best I have seen, though it retains many errors of a large but very bad engraving, published in 1625. It must have been partly copied from this, or from some other, which may be traced to a common origin, but not without a reference to the building, because several mistakes are rectified, and the details are better given, though the drawing is on a much smaller scale. One important error is not to be attributed to the old plate; the octagonal turrets placed at each angle of the western towers, are not closed, but entirely open, consisting merely of the slender shafts, which are kept in their upright position by numerous iron ties. The part above the arches supported by these shafts is the base of an unfinished spire, and the whole summit of the towers is evidently of a temporary nature; even as a temporary finish, however, there neither are, nor apparently ever were, any fleurs-de-lys. In the richness and magnificence of the external architecture, Rheims is superior to any other cathedral I have seen, and probably to any which has ever been erected. Whittington’s plate above cited will give a tolerably correct idea of the western front, but none of the effect produced by the same profusion, extended over the whole surface of a great building. I do not know whether the view of the
- 79. Welcome to Our Bookstore - The Ultimate Destination for Book Lovers Are you passionate about books and eager to explore new worlds of knowledge? At our website, we offer a vast collection of books that cater to every interest and age group. From classic literature to specialized publications, self-help books, and children’s stories, we have it all! Each book is a gateway to new adventures, helping you expand your knowledge and nourish your soul Experience Convenient and Enjoyable Book Shopping Our website is more than just an online bookstore—it’s a bridge connecting readers to the timeless values of culture and wisdom. With a sleek and user-friendly interface and a smart search system, you can find your favorite books quickly and easily. Enjoy special promotions, fast home delivery, and a seamless shopping experience that saves you time and enhances your love for reading. Let us accompany you on the journey of exploring knowledge and personal growth! ebookgate.com