Developing Enterprise Web Services An Architects

Guide Chatterjee download

https://ebookbell.com/product/developing-enterprise-web-services-
an-architects-guide-chatterjee-22062124

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Netbeans Ide Field Guide Developing Desktop Web Enterprise And Mobile
Applications 2nd Edition Patrick Keegan

https://ebookbell.com/product/netbeans-ide-field-guide-developing-
desktop-web-enterprise-and-mobile-applications-2nd-edition-patrick-
keegan-924580

Netbeans Ide Field Guide Developing Desktop Web Enterprise And Mobile
Applications Patrick Keegan

https://ebookbell.com/product/netbeans-ide-field-guide-developing-
desktop-web-enterprise-and-mobile-applications-patrick-keegan-978162

Enterprise Application Development With C 9 And Net 5 Enhance Your C

And Net Skills By Mastering The Process Of Developing
Professionalgrade Web Applications 1st Edition Ravindra Akella

https://ebookbell.com/product/enterprise-application-development-
with-c-9-and-net-5-enhance-your-c-and-net-skills-by-mastering-the-
process-of-developing-professionalgrade-web-applications-1st-edition-
ravindra-akella-50860754

Developing Enterprise Ios Applications Iphone And Ipad Apps For

Companies And Organizations James Turner

https://ebookbell.com/product/developing-enterprise-ios-applications-
iphone-and-ipad-apps-for-companies-and-organizations-james-
turner-2390338
Developing Enterprise Services For Sap Thomas Pohl

https://ebookbell.com/product/developing-enterprise-services-for-sap-
thomas-pohl-5411694

Developing Enterprise Java Applications With J2ee And Uml Khawar Zaman
Ahmed

https://ebookbell.com/product/developing-enterprise-java-applications-
with-j2ee-and-uml-khawar-zaman-ahmed-972532

Developing Enterprise Chatbots Learning Linguistic Structures 1st Ed

Boris Galitsky

https://ebookbell.com/product/developing-enterprise-chatbots-learning-
linguistic-structures-1st-ed-boris-galitsky-10484914

Developing Enterprise Ios Applications James Turner

https://ebookbell.com/product/developing-enterprise-ios-applications-
james-turner-31831784

Developing Enterprise Java Applications With J2ee And Uml 2004011

Khawar Zaman Ahmed Cary Eumrysh

https://ebookbell.com/product/developing-enterprise-java-applications-
with-j2ee-and-uml-2004011-khawar-zaman-ahmed-cary-eumrysh-60052056
“With the publication of this book, the Web Services vision is about to
take a giant leap forward. Chatterjee and Webber, drawing on their own
impressive experiences building Web Services, painstakingly provide their
readers with concise, but thorough understandings of the most important
issues and their solutions. They unabashedly recommend best practices in
application architectures, put key technologies together and show their
readers how to step-by-step build world-class, enterprise Web Services
and ebusiness applications. It’s about time we had a book like this!”
—David Bunnell, former CEO & Editor of Upside Magazine,
and founder of PC Magazine, PC World, Macworld,
Publish, NewMedia, and BioWorld

“Developing Enterprise Web Services is the first of the next generation of

Web services books, picking up where the introductory volumes leave off.
Jim and Sandeep review the essential foundation (SOAP, WSDL, and
UDDI) and then describe how to design and build real applications on top
of it. This book includes essential information and examples about
extended Web services specifications in the areas of security, transactions,
and reliability, and others, and is invaluable as a resource for developers
and managers who want to look past the standard stock quote service.”
—Eric Newcomer, CTO Iona
Hewlett-Packard® Professional Books
HP-UX
Fernandez Configuring CDE
Madell Disk and File Management Tasks on HP-UX
Olker Optimizing NFS Performance
Poniatowski HP-UX 11i Virtual Partitions
Poniatowski HP-UX 11i System Administration Handbook and Toolkit, Second Edition
Poniatowski The HP-UX 11.x System Administration Handbook and Toolkit
Poniatowski HP-UX 11.x System Administration “How To” Book
Poniatowski HP-UX 10.x System Administration “How To” Book
Poniatowski HP-UX System Administration Handbook and Toolkit
Poniatowski Learning the HP-UX Operating System
Rehman HP Certified: HP-UX System Administration
Sauers/Weygant HP-UX Tuning and Performance
Weygant Clusters for High Availability, Second Edition
Wong HP-UX 11i Security
UNIX, LINUX, WINDOWS, AND MPE I/X
Mosberger/Eranian IA-64 Linux Kernel
Poniatowski UNIX User’s Handbook, Second Edition
Stone/Symons UNIX Fault Management
COMPUTER ARCHITECTURE
Evans/Trimper Itanium Architecture for Programmers
Kane PA-RISC 2.0 Architecture
Markstein IA-64 and Elementary Functions
NETWORKING /COMMUNICATIONS
Blommers Architecting Enterprise Solutions with UNIX Networking
Blommers OpenView Network Node Manager
Blommers Practical Planning for Network Growth
Brans Mobilize Your Enterprise
Cook Building Enterprise Information Architecture
Lucke Designing and Implementing Computer Workgroups
Lund Integrating UNIX and PC Network Operating Systems
SECURITY
Bruce Security in Distributed Computing
Mao Modern Cryptography: Theory and Practice
Pearson et al. Trusted Computing Platforms
Pipkin Halting the Hacker, Second Edition
Pipkin Information Security
WEB/INTERNET CONCEPTS AND PROGRAMMING
Amor E-business (R)evolution, Second Edition
Apte/Mehta UDDI
Chatterjee/Webber Developing Enterprise Web Services: An Architect’s Guide
Kumar J2EE Security for Servlets, EJBs, and Web Services
Mowbrey/Werry Online Communities
Tapadiya .NET Programming
OTHER PROGRAMMING
Blinn Portable Shell Programming
Caruso Power Programming in HP OpenView
Chaudhri Object Databases in Practice
Chew The Java/C++ Cross Reference Handbook
Grady Practical Software Metrics for Project Management and Process
Improvement
Grady Software Metrics
Grady Successful Software Process Improvement
Lewis The Art and Science of Smalltalk
Lichtenbelt Introduction to Volume Rendering
Mellquist SNMP++
Mikkelsen Practical Software Configuration Management
Norton Thread Time
Tapadiya COM+ Programming
Yuan Windows 2000 GDI Programming
STORAGE
Thornburgh Fibre Channel for Mass Storage
Thornburgh/Schoenborn Storage Area Networks
Todman Designing Data Warehouses
IT/IS
Missbach/Hoffman SAP Hardware Solutions
IMAGE PROCESSING
Crane A Simplified Approach to Image Processing
Gann Desktop Scanners
This page intentionally left blank
Developing Enterprise
Web Services
An Architect’s Guide

Sandeep Chatterjee, Ph.D.

James Webber, Ph.D.

www.hp.com/hpbooks

PEARSON EDUCATION
PRENTICE HALL PROFESSIONAL TECHNICAL REFERENCE
UPPER SADDLE RIVER, NJ 07458
WWW.PHPTR.COM
Library of Congress Cataloging-in-Publication Data

A CIP catalog record for this book can be obtained from the Library of Congress.

Editorial/production supervision: Mary Sudul

Cover design director: Jerry Votta
Cover design: DesignSource
Manufacturing manager: Maura Zaldivar
Acquisitions editor: Jill Harry
Editorial assistant: Brenda Mulligan
Marketing manager: Dan DePasquale
Publisher, HP Books: Mark Stouse
Manager and Associate Publisher, HP Books: Victoria Brandow

© 2004 Hewlett-Packard Corp.

Published by Prentice Hall PTR
Pearson Education, Inc.
Upper Saddle River, New Jersey 07458

This material may be distributed only subject to the terms and conditions set forth in the Open
Publication License, v1.0 or later (the latest version is presently available at
<http://www.opencontent.org/openpub/>).

Prentice Hall books are widely used by corporations and government agencies for training, marketing,
and resale.
The publisher offers discounts on this book when ordered in bulk quantities. For more information,
contact Corporate Sales Department, Phone: 800-382-3419; FAX: 201-236-7141;
E-mail: [email protected]
Or write: Prentice Hall PTR, Corporate Sales Dept., One Lake Street, Upper Saddle River, NJ 07458.

Other product or company names mentioned herein are the trademarks or registered trademarks of their
respective owners.

Printed in the United States of America

2nd Printing

ISBN 0-13-140160-2

Pearson Education LTD.

Pearson Education Australia PTY, Limited
Pearson Education Singapore, Pte. Ltd.
Pearson Education North Asia Ltd.
Pearson Education Canada, Ltd.
Pearson Educación de Mexico, S.A. de C.V.
Pearson Education — Japan
Pearson Education Malaysia, Pte. Ltd.
CONTENTS

Foreword by David Bunnell xvii

Acknowledgments xxi
Chapter 1
Introduction 1
What Are Web Services? 2
SOAP 6
WSDL 7
UDDI 7
Why Web Services Are Important 8
The Evolution of Web Applications 8
Not Just Another Distributed Computing Platform 10
Web Services and Enterprises 11
Moving Forward 12
Summary 13
Architect’s Note 14

Part 1 Basic Web Services Standards, Technologies, and

Concepts 15

Chapter 2
XML Fundamentals 17
XML: The Lingua Franca of Web Services 17
XML Documents 19
XML Namespaces 21
Explicit and Default Namespaces 23
Inheriting Namespaces 24
And Not Inheriting Namespaces 24
Attributes and Namespaces 25
XML Schema 26
XML Schema and Namespaces 27

vii
viii Contents

A First Schema 28
Implementing XML Schema Types 30
The any Element 44
Inheritance 48
Substitution Groups 50
Global and Local Type Declarations 52
Managing Schemas 54
Schemas and Instance Documents 58
XML Schema Best Practices 59
Processing XML 60
SAX: Simple API for XML 61
DOM: Document Object Model 64
Extensible Stylesheet Transformation (XSLT) and XML Path Language (XPATH) 66
Summary 68
Architect’s Note 68
Chapter 3
SOAP and WSDL 69
The SOAP Model 69
SOAP 73
SOAP Messages 74
SOAP Envelope 75
SOAP Header 75
SOAP Body 79
SOAP Faults 79
SOAP Encoding 83
SOAP RPC 85
Using Alternative SOAP Encodings 89
Document, RPC, Literal, Encoded 92
Document 92
RPC 92
Literal 93
Encoded 93
SOAP RPC and SOAP Document-Literal 93
SOAP, Web Services, and the REST Architecture 93
Looking Back to SOAP 1.1 95
Syntactic Differences between SOAP 1.2 and SOAP 1.1 96
Changes to SOAP-RPC 97
SOAP Encoding 97
Contents ix

WSDL 98
WSDL Structure 98
The Stock Quote WSDL Interface 100
Definitions 100
The Types Element 101
Bindings 104
Services 107
Managing WSDL Descriptions 108
Extending WSDL 110
Using SOAP and WSDL 111
Service Implementation and Deployment 112
Binding to and Invoking Web Services 113
Where’s the Hard Work? 117
Summary 118
Architect’s Note 118
Chapter 4
UDDI—Universal Description, Discovery, and
Integration 119
UDDI at a Glance 119
Analogies with Telephone Directories 120
The UDDI Business Registry 124
UDDI Under the Covers 127
The UDDI Specification 127
UDDI Core Data Structures 127
Accessing UDDI 130
How UDDI Is Playing Out 134
UDDI and Lifecycle Management 135
UDDI and Dynamic Access Point Management 137
Summary 139
Architect’s Note 140
x Contents

Part 2 Advanced Web Services Technologies and

Standards 143

Chapter 5
Conversations 145
Conversations Overview 145
Conversational Requirements for B2B Interactions 147
Web Services Conversation Language 148
Consuming WSCL Interfaces 149
WSCL Interface Components 151
Interactions 151
Transitions 158
Conversations 162
The Bar Scenario Conversation 164
Relationship Between WSCL and WSDL 169
What WSCL Doesn’t Do 173
Summary 173
Architect’s Note 174
Chapter 6
Workflow 175
Business Process Management 175
Workflows and Workflow Management Systems 178
Workflows 178
Workflow Management Systems Drawbacks 180
Web Services and Workflow 181
Business Process Execution Language for Web Services (BPEL) 181
The BPEL Stack 182
Activities 183
Service Linking, Partners, and Service References 205
Message Properties and Property Aliases 209
Correlating Messages 210
Containers and Data Handling 218
Workflow Example: Online Shop 222
BPEL 1.1 and OASIS WSBPEL 246
BPEL and Its Relation to BPML, WSCI, WSFL, Xlang, and Others 246
Summary 247
Architect’s Note 248
Contents xi

Chapter 7
Transactions 249
ACID Transactions 249
Distributed Transactions and Two-Phase Commit 254
The Two-Phase Commit Approach 255
Dealing with Heuristic Outcomes 263
Advanced Topics: Nesting and Interposition 266
Scaling Transactions to Web Services 269
OASIS Business Transaction Protocol 271
The BTP Model 271
Implementing with BTP 276
Consuming Transactional Web Services 277
Client API 278
Under the Covers: BTP’s Two-Pipe Model 280
Transactionalizing Web Services 284
Supporting Infrastructure 286
Participants 287
Compensating Actions: A Strategy for Participant Implementation 290
Integrating Participants and Services 291
The Transaction Manager 293
Bringing It All Together: A Cohesive Example 294
BTP: In a Nutshell 297
Other Web Services Transaction Protocols 297
Microsoft .Net 297
J2EE and Enterprise Java Beans 299
WS-Coordination and WS-Transaction 300
Summary 303
Architect’s Note 303
Chapter 8
Security 305
Everyday Security Basics 306
Security Is An End-to-End Process 308
Data Handling and Forwarding 309
Data Storage 309
Errors in Identity 310
Web Service Security Issues 310
Data Protection and Encryption 311
xii Contents

Authentication and Authorization 315

Non-Repudiation and Signatures 317
Types of Security Attacks and Threats 323
Malicious Attacks 323
Denial of Service Attacks 324
Dictionary Attacks 325
Internal Threats 325
Web Services Security Roadmap 326
WS-Security 328
The Security Header Element 329
The UsernameToken Element 330
The BinarySecurityToken Element 331
The SecurityTokenReference Element 331
The KeyInfo Element 332
The Signature Element 332
The ReferenceList Element 333
The EncryptedKey Element 334
The EncryptedData Element 335
Putting It All Together 336
Preventing Replay Attacks 338
Summary 341
Architect’s Notes 341
Chapter 9
Quality of Service 343
What Is QoS? 343
Why Is QoS Important for Web Services? 346
Full Control versus Predictable Worst-Case Performance 346
QoS Metrics for Web Services 347
Where Are the Holes? 349
XML 349
HTTP 349
Communication Networks 349
Server-Side Infrastructure 350
Design Patterns and Best Practices 351
Use Coarse-Grained Web Services 352
Build the Right Client Application 355
Cache Web Service Results 356
Contents xiii

Use Resources Efficiently 357

Building QoS into Web Services and Applications 361
QoS-Enabled Web Services 362
Communicating QoS to Client Applications 362
Lifecycle Management 366
QoS-Enabled Applications 367
Monitoring QoS Performance 367
Discovering the Right Service 370
Recovering from Service Failures 371
Summary 372
Architect’s Note 372
Chapter 10
Mobile and Wireless 375
Mobile Web Services 377
Challenges with Mobile 379
The Wireless Network 379
Limited Computing Resources 382
User Interfaces 383
Proxy-Based Mobile Systems 385
Mobile Messaging Platform 386
Flash ActionScript Mobile Application User Interface 399
Invoking Web Services Directly Through a Proxy Server 402
Direct Mobile Web Service Access 406
J2ME Web Services 411
Supported APIs 412
Programming Model 413
Summary 413
Architect’s Notes 414
Chapter 11
Portals and Services Management 415
Portals 415
Programmatic and Interactive Web Service Interfaces 417
The WSRP and WSIA Specifications 421
Building Portlets and Portals with WSRP 422
Restrictions 425
Deploying and Locating Services 426
Putting It All Together 426
xiv Contents

Summary 429
Web Services Management 429
The Objectives of Web Services Management 430
Web Services Management Modules 431
Web Services Distributed Management 434
Summary 434
Architect’s Notes 435

Part 3 Putting It All Together—Building Real World

Enterprise Web Services and Applications 437

Chapter 12
Real World Web Service Application Development—
Foundations 439
Enterprise Procurement 439
System Functionality and Architecture 441
Running the EPS Application 443
System Implementation 445
VendorAOrdering.java 446
VendorAProcurement.wsdl 449
EPS.html 452
EPSCatalog.html 453
ServiceServlet.java 453
Client-Side Binding Stubs 460
OutputServlet.java 461
Deploying the Application 462
Running the Application 465
Direct Web Service Invocations (without Binding Stubs) 469
Where Are the Holes? 471
Summary 471
Architect’s Notes 472
Chapter 13
Real World Web Service Application Development—
Advanced Technologies 473
Introduction 473
Building Evolvable and Composable Workflows 475
Automating the Procurement Process 476
Contents xv

Augmenting Remote WSDL Interfaces 478

Implementing the BPEL Workflow Script 479
Deploying and Executing BPEL Workflows 495
Adding Transaction Support 499
Changes to the Back End Systems 501
Transaction-Aware Service Implementation 504
Implementing Participants 511
Consuming Transactional Web Services 518
Programming for Mobility 522
Securing the Application 531
HTTP Security 531
Summary 536
Architect’s Notes 537
Chapter 14
Epilogue 539
Current Standards and Future Trends 539
XML 539
SOAP and WSDL 540
UDDI 541
Transactions 541
Security 541
Conversations 542
Workflow 542
Quality of Service 543
Mobile and Wireless 543
Standards Organizations 544
W3C 544
OASIS 545
WS-I 545
Vendor Specifications 546
Platforms 547
Microsoft .Net 547
J2EE 547
A Single Web Services Platform? 548
Summary 548

Index 551
This page intentionally left blank
FOREWORD

The singing workmen shape and set and join

Their frail new mansion’s stuccoed cove and quoin
With no apparent sense that years abrade…
—Thomas Hardy, Rome: Building a New Street in the Ancient Quarter, 1887

K, Rome wasn’t built in a day, but once they got the sucker up and running, it was mag-
O nificent and, hey, it’s still there and functioning quite nicely. Having first heard about
Web services toward the end of the last century, I would have thought by now they would be
ubiquitous. At this point in time, I should be able to replace My Yahoo with a personalized Web
services portal uniquely suited to my quixotic needs and desires. Years ago, I started planning
this portal when I heard Bill Gates waxing poetically about Hurricane—a.k.a. “My Services”—
which was Microsoft’s vision of creating a suite of personalized Web services for early adopters
like me. Unfortunately, Microsoft abandoned this effort when critics complained it was really an
insidious plot to own people’s personal information.
Mostly by pure dumb luck, I’ve been at the forefront of technology for most of my life. As
a young man just out of college, I was working in Albuquerque, New Mexico, at a small com-
pany called MITS which, with a little help from a then 19-year old Bill Gates and his buddy Paul
Allen, started the personal computing revolution. Taking advantage of this happy situation, I
leveraged my background in media to launch a magazine called Personal Computing. These
experiences led me to found a number of other magazines including PC Magazine, PC World,
Macworld, Publish, NewMedia, and BioWorld. Most recently I was CEO and Editor of Upside
Media, Inc.
Throughout the years, I have been fortunate to have had a first-hand involvement in the
evolution of many revolutionary new innovations, including the first personal computer (Altair),

xvii
xviii Foreword

the first portal computer (Osborne), the first spreadsheet (VisiCalc), the Macintosh Computer,
Multi-Media, the Internet, and even Biotechnology.
To say that I have seen my share of “paradigm shifts” is an understatement. Technology
innovation has been all around me. Who would have thought that a couple of guys in a small
company in Albuquerque would start what would later become the PC revolution? Shouldn’t it
have come out of IBM or Xerox or some other big technology company? That’s exactly the rub.
Innovative ideas don’t always come from the big companies, sometimes they spring out from the
big guys and at other times they spring out from the little guys.
Based on all the above, I am completely convinced that Web services will level the playing
field between the little guy and the big guy as no technology has ever done before. Thanks to this
new revolution, the mom-and-pop company down the street can market their innovative software
and services to the neighborhood, to the global masses, as well as to the largest companies in the
world. But, we’re not only talking about the new and interesting. Even the most mundane and
boring is supported. The procurement system of the mom-and-pop company can seamlessly
interface with the billing system of a global multinational company and here’s where things get
really interesting. The systems of the multinational can also interface with the systems of the
mom-and-pop company. The most innovative new systems to the most boring, existing tasks are
all available on an anybody-to-anybody basis. This will ultimately happen but like many great
technologies, it will require a lot of work and patience before the dream is truly realized.
As Sandeep Chatterjee and James Webber so eloquently and clearly explain in this book,
real world Web services and Web services-based applications can’t simply be put together in a
haphazard manner by merely reading through one of the Web services technology specifications.
You need to be familiar with these standards and they are extremely important, but they only
represent the basic building blocks. To “architect” and construct world-class enterprise services,
developers need a much deeper knowledge of a number of different standards and tools plus
their “inter-relationships” and best practices for use.
Web services are small segments of larger applications and as such, quality-of-service
issues loom large if they are to be truly useful and scalable. When building them, you have to
factor in such considerations as: Availability (how often is the service available for consump-
tion); Accessibility (can it serve a client’s request now); Performance (how long does it take to
respond); Compliance (is it really “standard”); Security (is it safe to interact with this service);
Energy (suitable for mobile apps); and Reliability (how often does it fail). Like building Rome,
building Web services gets complicated fast.
So how do you architect an application to be reliable if some of the Web services you are
depending on become unavailable? Can an application be written to seamlessly scale to support
new Web services from an expanding group of strategic partners? What about transactional
guarantees or atomic coordination between multiple, independent services? And can you accom-
plish your design goal and still provide adequate safeguards for corporate and individual infor-
mation and intellectual property?
I imagine that the software world would have given up in disgust by now, moved on to some
new paradigm, except for two factors. The first is that all the major software companies are com-
 xix

mitted to Web services to the tune of several billion dollars, and the second is that Web services
are, gosh darn-it, actually revolutionary. They are so revolutionary they represent a whole new
amazing way of doing business, which will transform the software industry forever and change
the very nature of the corporate IT department, thrusting it into the heart of strategic thinking.
Web services build on and extend the Web application model by allowing any client appli-
cation to access and use its capabilities. By implementing capabilities that are available to other
applications (or even other Web services) via industry standard network and application inter-
faces and protocols, Web services represent reusable software building blocks that are URL
addressable. We’re talking here about a concept called “anybody-to-anybody” communica-
tions—quoting from this book, “a person who implements a Web service can be almost one hun-
dred percent certain that anybody else can communicate with and use the service.”
Chatterjee and Webber aren’t so concerned, however, about Web services for the masses.
They tackle a much more difficult topic, which is Web services for enterprises. These are ser-
vices that have to be totally reliable, absolutely secure and extremely functional. Referring back
to the “building Rome” analogy, these guys aren’t really talking about building foot paths or
neighborhood streets, rather they are more interested in the avenues, aqueducts, and other major
arteries that seamlessly and safely interconnect the Porticus of Gaius to the Forum of Caesar—
the House of the Vestal Virgins to the Temple of Saturn, and back again. They are talking about
the communication and transportation systems that made Rome the most magnificent function-
ing city of the Ancient World.
In today’s global marketplace, world class enterprises need to interconnect with their cus-
tomers and partners internationally using legacy systems that are mostly incompatible with each
other, and they need to do this relatively fast and as inexpensive as possible. Web services pro-
vide the solution but not without overcoming some fairly difficult obstacles.
In the Web services world, nothing is as simple as it may seem. Take transactions, for
example. Transactions are the bedrock on which B2B interactions rise or fall, they are a funda-
mental abstraction or requirement for what we sometimes refer to as “fault-tolerant computing.”
In a lucid and detailed style, the authors point out that the choices for transactions are scarce
and, in fact, the OASIS Business Transaction Protocol (or simply BTP) is the “only Web ser-
vices transaction protocol with implementation we can use today.” They explain BTP and how to
implement it, but just in case you get in over your head, they also suggest that unless you have
specialist knowledge in this area, you should give “serious consideration” to buying or outsourc-
ing it.
As with transactions, this book goes into great detail to describe the Web services technol-
ogies and standards that can be used in the real world today. These address the most challenging
enterprise requirements including conversations, workflow, security, the challenges inherent in
the development of mobile systems, how to build user-facing portals by aggregating back-end
Web services, and how to manage an ever growing number and type of Web services within the
enterprise. But more than this, the authors tell you in a concluding section filled with source
code and a step-by-step guide how to put this together. You’ll learn how to actually develop a
xx Foreword

Web service application and deploy it onto the Tomcat application server and the Axis SOAP
server (both freely available).
The ambitious goal of Developing Enterprise Web Services: An Architect’s Guide is to
give readers a “thorough understanding” of the steps necessary to build and deploy Web services
and client applications that meet enterprise requirements. This is a lofty goal indeed, and you’ll
want to spend some serious time going through all the clear and concise content that the authors
have spent well over a year developing. I found it really amazing.
Fortunately, with the publication of this book, the Web services vision is about to take a
giant leap forward. We are building our “Rome” and the end is finally in sight. Chatterjee and
Webber, drawing on their own impressive experiences building Web services, painstakingly pro-
vide their readers with concise, yet thorough understanding of the most important issues and
their solutions. They unabashedly recommend best practices in application architectures, put key
technologies together and show their readers step-by-step how to build world-class, enterprise
Web services-based e-business applications. And darn it, it’s about time we had a book like this!

David Bunnell
Berkeley, California
September 2003
ACKNOWLEDGMENTS

The authors would like to thank the many people who have helped and contributed to this
book. First, we would like to thank Bob Bickel for supporting and sanctioning our writing of this
book. We would also like to thank the following people who reviewed early drafts of the manu-
script and provided insightful feedback: Tony Wasserman, Lionel Lavallee, Sriram Somanchi,
Ravi Trivedi, Mark Little, Stuart Wheater, Andy Taylor, Savas Parastatidis, Lindsay Marshall,
Scott Williams, Satish Thatte, and Farhat Kaleem.

We would also like to thank the people at Pearson Education and, in particular, our execu-
tive editor, Jill Harry, who supported, encouraged, and guided us throughout the process. And, of
course, our most profound thanks go to our families for their constant love and encouragement.
Jim would especially like to thank Katherine Neasham for her continued support.

To all of these and many others too numerous to mention, we give our heartfelt thanks and
appreciation.

xxi
This page intentionally left blank
 C H A P T E R 1

Introduction

eb services technologies are fundamentally changing the software industry, making the
W role of enterprise IT organizations more strategic, and recasting the software vendor-
consumer relationship. Web services are also being hailed by CEOs, CIOs, and CTOs as the
next-generation vehicle for driving topline growth and controlling bottom lines. But, simply
jumping on the Web services bandwagon won’t lead to corporate success. Web services are sim-
ply a platform; how companies implement a solution using this new technology determines their
success and ultimately their return on investment (ROI). In this book, we take a no-nonsense,
strategic view of developing enterprise Web services and applications: looking at where the
technologies are, where they are going and how companies need to architect their own Web ser-
vices solutions to not get left behind.
Web services platforms provide the functionality to build and interact with distributed
applications by sending eXtensible Markup Language (XML) messages. Additional technology
layers are constantly emerging, others are being refined, and still others are being discarded. The
platform is essentially a moving target.
To stay on the leading edge, companies are building and deploying their applications
while work on the underlying platform continues. And, as with any industry standard initia-
tives which require building consensus, the Web services platform will remain a work in
progress for some time.
How can you build any meaningful application, let alone mission-critical enterprise applica-
tions, on such a platform? If you are a developer or an architect charged with building Web ser-
vices or applications that consume Web services, you have to know where the platform is today,
and where it is going. Otherwise, the endless pit of application rewrite and maintenance overhead
will far outweigh any benefits that can be garnered from this promising new technology.

1
2 Chapter 1 • Introduction

Real world, enterprise Web services and applications cannot be developed by simply reading
through the Simple Object Access Protocol (SOAP) or the Web Services Description Language
(WSDL) specifications. Developers must understand a number of different standards and technolo-
gies, and more importantly, their inter-relationships as well as best practices for their use.
Consider an e-business application that requires interaction between multiple partner Web
services. Understanding SOAP and WSDL gives developers the ability to write Web services
and consume them within their application. But, how must the application be architected to be
reliable in case some Web services become unavailable? How can an application be written to
seamlessly scale and support new Web services from a growing list of strategic partner compa-
nies? What are the best practices for developing mobile Web service applications, and how can
individual Web services be created to support quality-of-service (QoS)? How can transactional
guarantees or atomic coordination between multiple, independent Web services be supported by
applications? And, how can all of this be done securely so that corporate and individual informa-
tion and intellectual property are safeguarded?
In this book, we focus on how to develop Web services and applications within real world
enterprise environments. We describe not only the vanilla Web services platform consisting of
SOAP, WSDL, and UDDI (Universal Description, Discovery and Integration), but also build on
this to include the other technologies, standards, and emerging standards that provide support for
transactions, security and authentication, mobile and wireless, quality-of-service, conversations,
workflow, interactive applications and portals, as well as systems management.
We discuss the opportunities represented by Web services and, more importantly, describe
best practices and architectural patterns for building enterprise systems that position you and
your organization to most fully leverage those opportunities. We do not summarize any one Web
services standard, but instead provide a sufficiently thorough discussion of all of the critical
technologies and standards, as well as their inter-relationships, that are necessary for building
enterprise Web services and applications. Our focus is on developing enterprise Web services
and applications based on industry standard Web services technologies, not on summarizing
standards.
Let’s get started by reviewing what Web services are and why they are important.

What Are Web Services?

Web services represent a new architectural paradigm for applications. Web services implement
capabilities that are available to other applications (or even other Web services) via industry
standard network and application interfaces and protocols. An application can use the capabili-
ties of a Web service by simply invoking it across a network without having to integrate it. As
such, Web services represent reusable software building blocks that are URL addressable. The
architectural differences between monolithic, integrated applications and Web services-based
applications are depicted in Figure 1-1.
What Are Web Services? 3

Figure 1-1 The architectural differences between (a) a monolithic application with integrated
capabilities, and (b) a distributed application using Web services-based capabilities.

The capabilities provided by a Web service can fall into a variety of categories, including:

• Functions, such as a routine for calculating the integral square root of a number.
• Data, such as fetching the quantity of a particular widget a vendor has on hand.
• Business processes, such as accepting an order for a widget, shipping the desired
quantity of widgets and sending an invoice.

Some of these capabilities are difficult or impractical to integrate within third-party applications.
When these capabilities are exposed as Web services, they can be loosely coupled together,
thereby achieving the benefits of integration without incurring the difficulties thereof.
Web services expose their capabilities to client applications, not their implementations.
This allows Web services to be implemented in any language and on any platform and still be
compatible with all client applications.
4 Chapter 1 • Introduction

Each building block (Web service) is self-contained. It describes its own capabilities, pub-
lishes its own programmatic interface and implements its own functionality that is available as a
hosted service. The business logic of the Web service runs on a remote machine that is accessi-
ble by other applications through a network. The client application simply invokes the function-
ality of a Web service by sending it messages, receives return messages from the Web service
and then uses the results within the application. Since there is no need to integrate the Web ser-
vice within the client application into a single monolithic block, development and testing times,
maintenance costs, and overall errors are thereby reduced.
Assume you want to build a simple calculator application that determines the appreciation
in stock price for any company given its corporate name and the date the stock was originally
purchased. The application must do the following:

• Determine the stock ticker symbol for the company based on the company name.
• Determine the latest price of the stock based on the ticker symbol.
• Determine the historical price of the stock for the given date based on the ticker
symbol.
• Calculate the difference between the two stock prices and present it to the user.

This seemingly trivial application is in fact enormously complex. Right from the get go
there are problems. We have to build a database with the names of all the companies in the coun-
try and their associated stock ticker symbol. More importantly, we must maintain this database
as companies are newly listed, become delisted, change their names or their ticker symbol, or
merge. To access the real-time price of a stock, we must have a relationship with a financial or
brokerage firm. The legal complexities and hassles in architecting such a relationship is bad
enough, not to mention the IT infrastructure that must also be put into place.
Unless you work for a brokerage firm or are in the business of maintaining stock informa-
tion, the time and costs necessary to build the infrastructure necessary to support the stock
appreciation calculator are enormous and, in most cases, prohibitively so. Until a brokerage firm
itself decided to provide such a calculator, customers would have to make do without it.
Web services simplify and in many ways eliminate the need to build for yourself the sup-
port infrastructure—both legal and technical. The calculator can be developed by simply passing
messages between the calculator application and the appropriate set of Web services. Figure 1-2
graphically depicts the flow of messages, and the fundamental architecture of a Web services-
based stock price appreciation calculator.
Messages are sent between the calculator application and the following three Web services:

• StockTickerNameToSymbolConverter, which accepts a company’s name and

provides the ticker tape symbol.
• RealTimeStockQuoteLookup, which provides the latest price of a stock based on
its ticker tape symbol.
What Are Web Services? 5

Figure 1-2 Sending and receiving Web service messages to build a stock price appreciation
calculator.

• HistoricalStockQuoteLookup, which provides the historical price of a stock

based on its ticker tape symbol and the desired date.

Since each of these three Web services is provided, hosted, and managed by another com-
pany, the developer of the calculator application has only to focus on his key insight or contribu-
tion alone. Complex, domain-specific issues such as the fact that Hewlett-Packard’s ticker tape
symbol was HWP and only recently became HPQ are (or should be) handled by the Web ser-
vices directly. Using these three Web services, the application can easily determine the stock
price appreciation for Hewlett-Packard from August 15, 2002, to be $17.51 - $15.00 = $2.51.
Based on the data from the Web services, the calculator application can provide further analysis,
such as the percentage appreciation, and present all of the information in an easy-to-understand,
graphical manner.
Assuming the required capabilities exist and are available as Web services, developers can
focus on their unique value-added piece and utilize third-party Web services for the remainder of
the functionality. The benefits of using Web services are clear:

• Dramatically cut application development costs by focusing on your own value-added

contribution and using third-party Web services for everything else.
6 Chapter 1 • Introduction

• Integrate both data and business processes with market constituents and business
partners that have desired domain expertise or capabilities.
• Reduce or eliminate many errors born out of complex and large monolithic
applications.
• Simplify application maintenance and customization by segmenting an application into
the client application and each of its consumed Web services.
• Significantly reduce time-to-market.

As we take this idea further, and more and more companies expose some of their internal
capabilities as Web services, the real value of Web services lies in the composition of a set of
Web services. Consider the following two companies. One is a traffic service company that mon-
itors automobile traffic on major roads and highways and predicts expected travel times. The
second is a taxi reservation service company that allows customers to reserve taxis for pickup at
a specified location and time. Each of these companies and their products are compelling in and
of themselves. However, if these companies exposed their capabilities as Web services, these
services can be composed together into a single, more compelling and useful service—either by
one of these two companies themselves or by a third company.
As an example, consider taking a taxi to the airport before catching a flight for a meeting.
By leveraging the capabilities of both companies through their respective Web services, a trav-
eler can reserve a taxi and rest assured that if an accident or other traffic conditions cause an
unexpected increase in her travel time, the taxi reservation can be held and an alert sent to the
traveler advising her of the updated taxi schedule as well as the traffic situation that caused the
change. By simply and intelligently combining the individual services of the two companies, we
are able to create a more compelling and useful service for travelers. The composition of Web
services from different enterprises is depicted in Figure 1-3. The technologies that form the
foundations of Web services are SOAP, WSDL, and UDDI.

SOAP
Simple Object Access Protocol (SOAP) is an XML-based mechanism for exchanging informa-
tion between applications within a distributed environment. This information exchange mecha-
nism can be used to send messages between applications and, more specifically, can be used to
implement remote procedure calls (RPCs). RPCs allow one application to invoke and use a pro-
cedure (or capability) of another, possibly remote, application.
SOAP does not specify any application implementation or programming model. Instead, it
provides a mechanism for expressing application semantics that can be understood by applica-
tions no matter how they are implemented. Accordingly, SOAP is application language- and
platform-independent. SOAP is typically used in conjunction with HTTP, which supports easy
traversal of firewalls and is sufficiently lightweight to be used within mobile and wireless envi-
ronments.
What Are Web Services? 7

Figure 1-3 Composing together services exposed by multiple corporations to create a separate
service offering.

WSDL
Web Services Description Language (WSDL) is an XML-based language for describing Web
services. Through a WSDL description, a client application can determine the location of the
remote Web service, the functions it implements, as well as how to access and use each function.
After parsing a WSDL description, a client application can appropriately format a SOAP request
and dispatch it to the location of the Web service.
WSDL descriptions go hand-in-hand with the development of a new Web service and are
created by the producer of the service. WSDL files (or pointers thereto) are typically stored in
registries that can be searched by potential users to locate Web service implementations of
desired capabilities.

UDDI
Universal Description, Discovery, and Integration (UDDI) is a specification for a registry of
information for Web services. UDDI defines a means to publish and, more importantly, discover
(or search for) information about Web services, including WSDL files.
8 Chapter 1 • Introduction

Figure 1-4 The relationships between SOAP, WSDL, and UDDI.

After browsing through an UDDI registry for information about available Web services,
the WSDL for the selected service can be parsed, and an appropriate SOAP message can be sent
to the service. Figure 1-4 graphically illustrates the relationships between SOAP, WSDL, and
UDDI.
Now that we have a glimpse into what Web services are and how they can be used to build
interesting applications and systems, we next discuss why this new technology is important.

Why Web Services Are Important

Web services represent a new paradigm in application architecture and development. The impor-
tance of Web services is not that they are new, but that this new technology addresses the needs
of application development. To understand this new paradigm, let us first look at the application
paradigm that preceded Web services—Web applications.

The Evolution of Web Applications

Web applications are applications that are available via the World Wide Web (Web) and allow
any user anywhere in the world access to its capabilities. This is in contrast to older client-server
applications in which only dedicated clients could access the applications residing on the server.
Web applications grew the user base from just a few hundred client machines accessing a client-
server application, to millions of users across the Web accessing a Web application.
The Web opened up the floodgates to Web applications by allowing users to simply spec-
ify a URL within a Web browser. Web applications also increased the difficulty of developing
applications because a Web application client (a PC browser) has no knowledge of the applica-
tion’s communication requirements or underlying systems. Industry standard technologies such
Why Web Services Are Important 9

as HTTP and HTML were used to bridge this gap between Web application clients and the Web
applications themselves. Application servers and other middleware emerged to reduce the com-
plexities of building Web apps while still allowing pervasive access to each Web application.
Web services build on and extend the Web application model. Web applications allow any
Web browser to access its functionality, with the application user interface presented through the
browser. Web services take this a step further and allow any client application to access and use
its capabilities.
A Web application allows universal user access to its capabilities by supporting industry
standard interfaces to its user interface. They do not allow extending or adding to their capabili-
ties through programmatic access. To leverage the functionality of a Web application and build
on it, complex and often unreliable techniques, such as screen scraping, must be used. Web ser-
vices address this issue by allowing programmatic access to the Web services’ capabilities using
industry standard interfaces and protocols. The evolution of Web applications to Web services is
shown in Figure 1-5.

Figure 1-5 Evolution of Web applications to Web services and key architectural differences.
10 Chapter 1 • Introduction

Web services advocate a services-oriented architecture for applications in which a soft-

ware component provides its functionality as a service that can be leveraged by other software
components. Such a service model abstracts away many complex issues that arise from software
component integration, including platform compatibility, testing, and maintenance.
Since Web service clients do not have information necessary to communicate with a Web
service, a set of standards is necessary to allow any-to-any communications. Web service stan-
dards build on previous standards for communications and data representation, such as HTTP
and HTML.
The key enabler for Web services is XML. Although HTML and XML are similar in that
both are human-readable markup languages, HTML is for presentation markup while XML is
for semantic markup. This critical attribute of XML supports expressing application and func-
tional semantics in a platform-independent manner that enables any-to-any information
exchange.
Some argue that Web services are nothing new; they are simply the latest incarnation of
distributed computing. In some sense that may be true, but what is it about Web services that is
driving the incredible buzz? Why are entrepreneurs, CEOs of established companies, and indus-
try analysts excited about this technology? In the next section, we see that Web services are not
just another distributed computing platform.

Not Just Another Distributed Computing Platform

Web services are indeed a technology for distributed computing and there is one critical distinc-
tion between Web services and distributed computing technologies that have come before. A
person who implements a Web service can be almost one hundred percent certain that anybody
else can communicate with and use the service. The breakthrough of Web services is precisely
the anybody-to-anybody communications that it enables. The confidence level Web services
engender in its developers is similar to that of HTML Web pages. The developer of an HTML
page is certain that anybody with a browser can view the Web page.
Web services grew out of a need for a distributed computing application environment that
was not as difficult to deploy to as the Common Object Request Broker Architecture (CORBA)
or Microsoft’s Distributed Component Object Model (DCOM), and also offered greater interop-
erability. Both CORBA and DCOM aimed to provide a distributed computing environment
across heterogeneous environments. Unfortunately, neither supported environments or technolo-
gies that were sufficiently far-reaching to enable heterogeneous communications at the anybody-
to-anybody scale.
In a sense, Web services sacrifice the richness of capabilities that are provided by previous
distributed computing environments, which are necessary to a small group of all applications,
for a much simpler and more ubiquitous solution that is applicable for the vast majority of appli-
cations. This is not to say that Web services place restrictions on their use. Additional capabili-
ties can be layered on top of the Web services platform to address varying needs.
Web Services and Enterprises 11

Applications that are exposed as Web services have a large base of other applications (that
are also exposed as Web services) with which to communicate. Since they are based on simple
and open industry standards (or de facto standards), Web services make significant inroads
toward ubiquitous interoperability. Interoperability here is on the scale of the Web or the Inter-
net, not just a group or organization.
Based on industry standards and supporting anybody-to-anybody interoperability, Web
services are poised to be the platform that delivers on the needs of e-businesses. All companies
interact with other companies in the course of conducting their businesses. Manufacturing com-
panies interact with component suppliers, distributors interact with manufacturing companies,
retailers interact with distributors, and so on. Initially, these interactions were manual, conducted
by mail, phone, and fax.
Web applications allowed companies to interact with one another by exposing some of
their capabilities and business processes to others on the Web. But, most of the time, this still
required a human being interacting with the Web application on the other side. Web services
remove the need for constant human intervention while companies interact by enabling pro-
grammatic conversations between applications.
By removing this barrier to e-business interactions, Web services enable new business
relationships as well as more fluid relationships that can be configured and reconfigured on-the-
fly. Although Web services offer numerous benefits, they also present many challenges and risks
within traditional enterprise environments. We discuss Web services and how they fit within
enterprises next.

Web Services and Enterprises

On the surface, Web services appear to be a risky proposition for enterprises. Why will IT orga-
nizations that have demanded full control over all aspects of enterprise applications adopt a dis-
tributed and shared software architecture that moves administrative control over various parts of
applications outside of the enterprise firewall? The runtime characteristics of Web services-
based applications will have critical dependencies on remotely hosted and remotely managed
external businesses. This is a severe departure from the centrally controlled as well as the guar-
anteed predictability and reliability that have become the hallmarks of enterprise software and
the IT organizations that manage them.
The reasons for this break are clear. Web services enable the flow of data and business pro-
cesses between business partners—between enterprises as well as between multiple organiza-
tions or groups within an enterprise—to a degree that have not been possible before. Businesses
that could not previously communicate and applications that could not previously interoperate
can now do so.
Web services enable companies to drive topline growth by integrating together different
services and introduce new revenue-generating services. At the same time, Web services sim-
12 Chapter 1 • Introduction

plify integration, reducing time-to-market and costs, as well as support operational efficiencies
that streamline the bottom line.
The potential benefits of Web services are enormous. The risks are equally great, if not
greater. Enterprise IT organizations will find themselves in the middle, responsible for reconcil-
ing the benefits with the risks of adopting Web services within the enterprise.
IT organizations, in an effort to gain a controlling foothold over risky and potentially
harmful Web services traffic, will insist on controlling which Web services applications interact
with one another. A misbehaving Web service will simply be cut off from interacting with any
enterprise applications; such cut offs may even be preemptive if there is a history of problems or
a perception of a threat.
To accomplish this, IT will take on a more strategic role within organizations and align
itself more closely with individual business units. Critical decisions by business units, such as
the partners from which to source components, will have to be cleared by IT if those partners’
Web services will interact with the applications or Web services of the company.
This will have major ramifications for enterprise application architectures. Enterprise
applications will support dynamic and swappable Web services—hardwired Web service invoca-
tions will no longer suffice. Moreover, IT will use management environments to deploy enter-
prise-wide policies for Web services that will monitor and strictly enforce the Web services that
applications can use.
There is no doubt that the uptake of Web services within the enterprise will require
changes. Many of these changes will be to established procedures and existing policies that have
been supported by years of experience and billions of dollars. Nonetheless, the potential bene-
fits—both financial and strategic—to adopting Web services are sufficiently large to justify such
changes.

Moving Forward
As organizations transition from researching Web services technologies and building internal
prototypes to early-adopter deployments, and then eventually to mainstream adoption of Web
services, the key differentiator and requirement is that these applications and systems are appro-
priate for “real world” deployment and usage. Some of the early prototypes built using Web ser-
vices were in many ways toys. All of the Web services and client applications run on a single
machine, hosted by the same application server, in a fully controlled environment. Many of these
services and applications that once worked as prototype systems will no doubt break—some
immediately, while others may take more time to break (which is much worse).
The next few years will see Web services and applications become hardened and ready for
“real world” deployment. The real world is indeed a cold and hard place. Web services run
remotely, sometimes go down and become unavailable, evolve into multiple versions, as well as
encounter variances in network bandwidth and quality. Moreover, politics and competitive
Summary 13

issues between organizations will result in unexpected outages and behaviors along critical
dependencies within applications.
Already we see many standards bodies that have been convened to address these and other
issues. Some of the technologies that are being developed to address these needs will eventually
be automatic, transparent to developers as existing infrastructure and tools, such as middleware
and IDEs, and incorporate the technologies. Nonetheless, architects and developers will need to
have a keen understanding of these issues and technologies to develop enterprise-class Web ser-
vices and applications.
In this book, we look at the Web services platform—where it is now and where it is
going—with an eye toward developing robust enterprise Web services and applications. In the
first of the three sections of this book, we begin by describing the core technologies that make up
the Web services platform. These are XML, SOAP, WSDL, and UDDI. This platform provides a
distributed computing environment based on standard interfaces and protocols, but it does not
implement all of the capabilities necessary for implementing enterprise systems.
In the second part of this book, we look at some of the standards and emerging technolo-
gies that, once layered on top of the vanilla Web services platform, address some of the critical
requirements of enterprise systems. These technologies include support for transactions, security
and authentication, conversations, workflow, quality of service, mobile and wireless, services
and systems management, as well as interactive applications and Web portals.
In the third part of the book, with both the vanilla Web services platform as well as some
of the critical advanced technologies and standards under our belt, we take an in-depth look and
provide step-by-step instructions for building an enterprise application using Web services.
Addressing one of the biggest pain points in business processes today, we develop an enterprise
procurement application that ties together the inventory and ordering Web services of multiple
suppliers and facilitates the procurement process. We first develop the entire application using
only the vanilla Web services platform (as described in the first part of the book). After identify-
ing the shortcomings of this implementation based only on the vanilla platform, we add to and
expand on the application using the advanced standards and technologies described in the sec-
ond part of the book.
We conclude this book by summarizing and highlighting some of the key points to remem-
ber when developing enterprise Web services and applications.

Summary
Web services represent enormous opportunities and challenges. How organizations negotiate
these hurdles will determine the benefits they incur. In this book, we describe the Web services
platform—where it is and where it is going—so that developers building applications are cogni-
zant of the fluid nature of the platform and can address enterprise system requirements within
the context of a changing platform.
14 Chapter 1 • Introduction

Architect’s Note
• Web services are remotely hosted and managed applications whose capabilities can be
accessed programmatically by client applications via an addressable URL.
• The core Web services platform, consisting of SOAP, WSDL, and UDDI, provides the
means for building distributed applications based on industry standard technologies,
interfaces, and protocols.
• The core Web services platform does not provide all of the necessary capabilities on
which to build enterprise systems. Additional technologies are being developed and are
being standardized that can be layered on top of the core platform and provide support
for security and authentication, transactions, mobile and wireless access, quality-of-
service, workflows, conversations, systems and service management, as well as
interactive applications and Web portals.
• Web services are important and different from other distributed computing
environments because they are based on industry standards that are nearly ubiquitous.
This allows unprecedented interoperability between applications as well as companies
and supports anybody-to-anybody applications.
• The adoption of Web services within enterprises will require fundamental changes to
IT organizations that are responsible for deploying and maintaining enterprise systems.
In an effort to maintain control over enterprise systems within a Web services
environment, IT will take on a more strategic role that is aligned with individual
business units and become part of the business decision process.
 P A R T
1

Basic Web Services

Standards, Technologies,
and Concepts

n this first section of the book, we briefly review the industry standards, technologies and
I concepts that underlie Web services. These critical technologies support the development of
Web services as well as applications that use (or consume) Web services. But, be forewarned
that these foundational technologies do not provide everything necessary to build Web services
and applications that meet enterprise requirements. We cover these advanced technologies in
Section Two of this book.
In this section, we describe the following technologies that together make up the basic
Web services platform:
Chapter 2: XML Fundamentals. In this first of three chapters in Part One, we start with
a discussion of the fundamentals of the eXtensible Markup Language (XML), the basic technol-
ogy on which Web services are based. From network protocols up the stack to back-end data-
bases, XML in all its forms has had a commoditizing effect on enterprise computing systems
and being both platform and language independent is a natural choice for the level of interopera-
bility required of Web services.
Chapter 3: SOAP and WSDL. Here we describe in detail the two technologies that
make up the foundations of Web services: SOAP and WSDL. SOAP (Simple Object Access
Protocol) is an XML-based mechanism for exchanging information between applications
within a distributed environment. This information exchange mechanism can be used to send
messages between applications and, more specifically, can be used to implement remote pro-
cedure calls (RPCs). WSDL (Web Services Description Language) is an XML-based language
for describing Web services. Through a WSDL description, a client application can determine

15
16 Part 1 • Basic Web Services Standards, Technologies, and Concepts

the location of the remote Web service, the functions it implements, as well as how to access
and use each function.
Chapter 4: UDDI. In this chapter, we describe UDDI (Universal Description, Discovery,
and Integration), which is a specification for a registry of information for Web services. UDDI
defines a means to publish and, more importantly, discover (or search for) information, includ-
ing WSDL files, about Web services. We also describe the UBR (UDDI Business Registry),
which is a global implementation of the UDDI specification.
After reading Section One, you will have a strong understanding of the technologies, stan-
dards and concepts underlying Web services. Refer to Section Three for a detailed, step-by-step
guide and lots of sample source code to actually develop Web services and client applications.
 C H A P T E R 2

XML Fundamentals

he suite of technologies grouped under the XML umbrella provides the fundamental
T building blocks of the Web services architecture. From network protocols through back
end databases, XML has had an advantageous effect on enterprise computing systems. Being
platform and language independent is a natural choice for building interoperable systems via
Web services. Given the importance of XML in enterprise computing, and specifically in Web
services, this chapter recaps the fundamentals of XML before embarking on a discussion of
more advanced topics such as namespaces and XML Schema.

XML: The Lingua Franca of Web Services

XML is a standard for data mark-up backed by the World Wide Web Consortium, which has
been branded “the universal format for structured documents and data on the Web.”1 The entire
XML suite of standards, models, and processing technologies have been under development
since 1998 with the initial XML specification, and has since been augmented by several addi-
tional supporting standards and notes that have brought XML to its current rich state. In fact,
though XML is undeniably a richly specified technology, it has retained its simplicity and the
entire XML platform can be profiled as follows:2

1. From the W3C Web Site at http://www.w3c.org/XML/

2. These (fewer than 10) points are based on the W3C’s “XML in 10 Points” available from http://
www.w3c.org/XML/1999/XML-in-10-points

17
18 Chapter 2 • XML Fundamentals

• XML is for Structuring Data

Structured data includes things like spreadsheets, address books, configuration
parameters, financial transactions, and technical drawings. XML is a set of rules for
designing text formats that support the developer in creating structured data. Though it
vaguely resembles source code, XML is not a programming language, but it does make
it easy for a computer to generate data, read data, and ensure that the data structure is
unambiguous. XML avoids common pitfalls in language design. It is extensible,
platform-independent, supports internationalization and localization, and is fully
Unicode-compliant.
• XML Resembles HTML
Like HTML, XML makes use of tags (words surrounded by angle brackets, “<” and
“>”) and attributes (of the form name=“value”). While HTML specifies what each tag
and attribute means and often how the text between them will render in a browser,
XML uses the tags only to delimit pieces of data and leaves the interpretation of the
data completely to the application that reads it.
• XML is Human Readable, but Humans Shouldn’t Read It
Programs that produce structured data often store that data on disk, using either a
binary or text format. An advantage of a textual format is that it allows people, if
necessary, to look at the data without the program that produced it, using tools like text
editors. XML files are text files that people shouldn’t have to read, but may read as and
when the need arises. Care must be taken when manually editing XML since its rules
are strict. A forgotten tag or an attribute without quotes makes an XML document
unusable. The official XML specification forbids applications from trying to second-
guess the creator of a broken XML file; if the file is broken, an application has to stop
and report an error.
• XML is Verbose
Since XML is a textual format and uses tags to delimit the data, XML files are nearly
always larger than comparable binary formats. That was a conscious decision by the
designers of XML. The advantages of a text format are evident, and the disadvantages
can usually be compensated at a different level by compression applications. In
addition, the transfer of XML across networks can be hastened by communication
protocols such as those used in modems protocols and HTTP/1.1, which can compress
data on-the-fly, saving bandwidth almost as effectively as a binary format.
• XML is a Suite of Technologies
XML 1.0 is the specification that defines what “tags” and “attributes” are. Beyond that
specification, the XML family is a growing set of modules that offer useful services to
accomplish important and frequently demanded tasks.
• XML is Modular
XML allows you to define a new document format by combining and reusing other
formats. Since two formats developed independently may have elements or attributes
XML Documents 19

with the same name, care must be taken when combining those formats. To eliminate
name confusion when combining formats, XML provides a namespace mechanism that
is supported in all XML-based technologies.
• XML is License-Free, Platform-Independent, and Well-Supported
By choosing XML as the basis for Web services, we gain access to a large and growing
community of tools and techniques on which to develop value. Basing Web services on
XML is similar to basing a database strategy on SQL—you still have to build your own
database, programs, and procedures that manipulate it, but there are many tools and
commodity components available to help. Furthermore, since XML is license-free,
Web services can be built without incurring royalty payments.

While a full discussion of the subject of XML is beyond the scope of this book, before delving
deeply into developing Web services it is imperative that at least the basics of XML and XML
processing are understood. Although some of the XML detail inherent in developing Web ser-
vices can be abstracted by toolkits, the increasing popularity of XML at the application level
means that any learning at this point will, in addition to accelerating the rate of understanding
Web services technology, be generally valuable in day-to-day development. That said, it’s time
to get acquainted with some fundamental XML concepts.

XML Documents
The purpose of an XML document is to capture structured data, just like an object in an object-
oriented programming language. Documents are structured into a number of elements, delimited
by tags which may or may not be nested within other elements.
Anyone familiar with the syntax of HTML will immediately be comfortable with the look
and feel of XML, although anyone thinking about coding XML like HTML must be wary—
XML is extremely strict in its syntax, where the interpretation of HTML (particularly by brows-
ers) is quite permissive. As we progress through the examples, it is worth remembering the fun-
damental document syntax:

1. All tags must have corresponding end tags unless they are devoid of subelements, in
which case they can be represented as
<element-name … attributes … />.
2. No element can overlap any other element, although nesting within elements is
allowed.
3. A document can only have a single root element (which excludes the XML declaration
<?xml … ?>).
4. Attributes of an element must have unique names within the scope of a single tag.
5. Only element names and attribute name-value pairs may be placed within a tag declara-
tion.
20 Chapter 2 • XML Fundamentals

The best way to understand XML is by example, and the XML document shown in Figure
2-1 is typical of the structure of most XML documents, though it is somewhat shorter than most
we’ll be seeing in the Web services world.

<?xml version="1.0" encoding="utf-8"?>

<dvd>
<title>The Phantom Menace</title>
<year>2001</year>
</dvd>

Figure 2-1 A simple XML document.

Figure 2-1 shows a simple XML document that contains data about a DVD. The document
(as all XML documents should) begins with the XML Declaration, delimited by <? and ?>.
This declaration provides information for any programs that are going to process the document.
In this case it informs any processors that the XML document is encoded according to version
1.0 (at the moment 1.0 is the first and only XML version and the 1.1 effort is underway) and the
underlying textual encoding is UTF-8 as opposed to ASCII.
The remainder of the document is where the actual structured data is held. In this case we
have a root element delimited by the dvd tag, which contains two subelements delimited by
the title and year tags. Those subelements contain textual data that we assume relates to the
name of the film on the disk and the year of its release (though this is a convention and we could
name elements badly, just as we can poorly name variables when programming).
We can take this document one stage further and make it a little more useful for those pro-
grams who might want to derive richer information from it. The document shown in Figure 2-2
embellishes that from Figure 2-1 adding in the DVD regional information as an attribute to the
root element region="2". We have also added a comment to aid human readability that is
delimited by <!-- and -->.

<?xml version="1.0" encoding="utf-8"?>

<!-- This is the European release of the DVD -->
<dvd region="2">
<title>The Phantom Menace</title>
<year>2001</year>
</dvd>

Figure 2-2 A simple XML document with attributes and comments.

The addition of the attribute in Figure 2-2 would, for instance, be of great help to a DVD
cataloging system that could use the region attribute to classify disks by their target geographical
region.
XML Namespaces 21

XML Namespaces
Namespaces in object-oriented programming languages allow developers to name classes unam-
biguously. Given that different organizations (should) use different namespaces for the software
components, even in the cases where two third-party software components contain a class with
exactly the same name, the fact that those classes are in different namespaces means that they
are easily distinguished from one another.
Unambiguous naming is a requirement that also permeates the XML world. For example,
it may be the case that several versions of a document with a root element dvd may exist, but the
structure of each is different. The way we distinguish the document that we want from a number
of available dvd documents is by its XML namespace.
Unlike popular programming languages where specific scope resolution operators are used
to build namespaces (e.g., MyPackage.MyClass in Java and MyNamespace::MyClass in
C++) the convention in XML is to use a URI (Universal Resource Identifier) as the namespace
identifier.

In fact, XML namespaces use URIs by convention only. Strictly

speaking, an XML namespace is just a string. The value in using
URIs is that they ensure uniqueness that strings cannot.

The URI is the union of the familiar URL and the not-so-familiar URN (Uniform
Resource Name) schemes as shown in Figure 2-3 and Figure 2-4.

ftp://src.doc.ic.ac.uk
gopher://gopher.dna.affrc.go.jp
http://www.arjuna.com
mailto:[email protected]
news:uk.jobs.offered
telnet://foo.bar.com/

Figure 2-3 Some familiar URI schemes.

The general scheme for the construction of a URI is <scheme>:<scheme-spe-

cific-part>. An absolute URI contains the name of the scheme in use followed by a colon
(e.g., news:), which is followed by a string which is interpreted according to the semantics of
that scheme (i.e., uk.jobs.offered identifies a particular Usenet newsgroup).
While the URI scheme doesn’t mandate the meaning of the <scheme-specific-part>,
many individual schemes share the same form which most Web users will have experienced with
URLs (Uniform Resource Locator) where the syntax consists of a sequence of four parts:
<scheme>://<authority><path>?<query> (for example, http://search.sun.com/
22 Chapter 2 • XML Fundamentals

search/suncom/?qt=java). Depending on the scheme in use, not all of these parts are neces-
sary but given those rules any valid URI can be constructed.

Another good convention to adopt for namespaces is that the URI

chosen should have some meaning. For instance, if a document
has a namespace which is a HTTP URL, then dereferencing that
URL should retrieve the schema which constrains that document.

A URN is intended to be a persistent, location-independent, resource identifier. In typical

situations a URN is used where a name is intended to be persistent. The caveat is that once a URN
has been affiliated with a particular entity (protocol message, Web service, and so on), it must not
be reused to reference another resource. The URNs in Figure 2-4 are typical of the kinds of iden-
tifiers we find in Web services applications (taken from OASIS BTP, see Chapter 7):

urn:oasis:names:tc:BTP:1.0:core
urn:oasis:names:tc:BTP:1.0:qualifiers

Figure 2-4 An example of the URN scheme.

XML namespaces affiliate the elements and attributes of an XML document with
namespaces identified by URIs. This process is called qualification and the names of the ele-
ments and attributes given a namespace scope are called qualified names, or simply QNames.
Now that we understand we can qualify our documents with a namespace, we can extend
the example in Figure 2-2 to include namespace affiliation. Given that it is likely there will be
other DVD cataloging systems and those systems will also use elements with names like dvd
(which will likely have a different structure and content from our own version), the addition of a
namespace into our XML document confers the advantage that it cannot be mixed up with any
other similar-looking dvd documents from outside of our namespace. Our newly namespaced
document is shown in Figure 2-5.

<?xml version="1.0" encoding="utf-8"?>

<!-- This is the European release of the DVD -->
<d:dvd xmlns:d="http://dvd.example.com" region="2">
<d:title>The Phantom Menace</d:title>
<d:year>2001</d:year>
</d:dvd>

Figure 2-5 A simple namespaced XML document with attributes and comments.

We have introduced into Figure 2-5 an association between a prefix and a URI (in this case
we’ve used a URL), using the xmlns attribute from the XML Namespace specification. We
XML Namespaces 23

then used that prefix throughout the document to associate our elements with that namespace.
Any XML processing infrastructure that reads our document does not see the elements as simply
their element names but de-references the URI to arrive at the form {URI}:<local name>
(e.g., {http://dvd.example.com}:dvd}) which is unambiguous, unlike the element
name alone (i.e., just dvd). It is important to remember that the syntax {prefix}:<local
name> is not understood by XML processing programs, it is a convention used when describing
qualified elements.

Although any element can contain a namespace declaration, the

style convention in XML is to declare all namespaces that a doc-
ument uses in its root element. Although this can make the open-
ing tag of the root element quite large, it does improve overall
document readability since we do not then pepper the document
with namespace declarations.

Explicit and Default Namespaces

XML permits two distinct kinds of namespace declarations. The first of these as we have
seen is the explicit form, whereby a prefix is given a namespace association (e.g.,
xmlns:d="http://dvd.example.com"), and then elements and attributes which belong
to that namespace are explicitly adorned with the chosen prefix. The second of these is the
default namespace declared as xmlns=<uri> that provides a default namespace affiliation
which applies to any elements without a prefix.

The default namespace can be used to improve the readability of

an XML document. In documents where a particular explicit
namespace is predominantly used (like the WSDL or SOAP doc-
uments in Chapter 3), declaring a default namespace alleviates
the need to pepper the document with the same prefix all over.
Using this strategy, only those elements outside of the default
namespace will need to be prefixed, which can make documents
significantly easier to understand.

We present a modified version of the XML from Figure 2-5 in Figure 2-6, where the
default namespace declaration implicitly scopes all following elements within the http://
dvd.example.com namespace, like this:

<?xml version="1.0" encoding="utf-8"?>

<!-- This is the European release of the DVD -->
<dvd xmlns="http://dvd.example.com" region="2">
<title>The Phantom Menace</title>
<year>2001</year>
</dvd>

Figure 2-6 Using default namespaces.

24 Chapter 2 • XML Fundamentals

Adding a namespace affiliation to an XML document is analogous to placing a Java class

into a specific package. Where the Java equivalent of in Figure 2-2 (which has no namespace
affiliation) might have been referenced by a declaration such as DVD myDVD, the equivalent
type of reference for the document in Figure 2-5 or Figure 2-6 would be com.exam-
ple.dvd.DVD myDVD, which when reduced to Java terms is clearly unambiguous since only
the owner of the dvd.example.com domain should be using that namespace (and by infer-
ence should be the only party using that namespace to name XML documents).

Inheriting Namespaces
Once a default or explicit namespace has been declared, it is “in scope” for all child elements of
the element where it was declared. The default namespace is therefore propagated to all child
elements implicitly unless they have their own explicit namespace.

This arrangement is common in WSDL files (Chapter 3) where

the WSDL namespace is the default namespace for an interface,
but where the binding elements use their own explicit
namespace.

The rule of thumb for choosing a default or explicit namespace is that if you can’t see at a
glance yourself which namespace an element belongs to, then no one else will be able to and,
therefore, explicit namespaces should be used. If, however, it is obvious which namespace an
element belongs to and there are lots of such elements in the same namespace, then readability
may be improved with the addition of a default namespace.

And Not Inheriting Namespaces

Of course, a child may not necessarily want to inherit the default namespace of its parent and
may wish to set it to something else or remove the default namespace entirely. This is not a prob-
lem with explicit namespaces because the child element can just be prefixed with a different
explicit namespace than its parent, as shown in Figure 2-7, where the genre element has a differ-
ent namespace affiliation than the rest of the document (which uses the default namespace).

<?xml version="1.0" encoding="utf-8"?>

<!-- This is the European release of the DVD -->
<dvd xmlns="http://dvd.example.com" region="2">
<title>The Phantom Menace</title>
<year>2001</year>
<g:genre xmlns:g="http://film-genre.example.com">
sci-fi
</g:genre>
</dvd>

Figure 2-7 Mixing explicit and default namespaces within a document.

XML Namespaces 25

It is important to realize that any children of the genre element in Figure 2-7 that use the
default namespace will be using the default namespace of the dvd element since the genre ele-
ment only declares an explicit namespace for its scope. Similarly, with default namespaces, any
element is at liberty to define a namespace for itself and any of its children irrespective of the
namespace affiliations of any of its parent elements. This is shown below in Figure 2-8:

<?xml version="1.0" encoding="utf-8"?>

<!-- This is the European release of the DVD -->
<dvd xmlns="http://dvd.example.com" region="2">
<title>The Phantom Menace</title>
<year>2001</year>
<genre xmlns ="http://film-genre.example.com">
sci-fi
</genre>
</dvd>

Figure 2-8 Mixing default namespaces within a document.

The genre element from Figure 2-8 declares that the default namespace for itself and its chil-
dren (if any) are, by default, in the namespace http://film-genre.example.com. This
differs from the example shown in Figure 2-7 since in the absence of any explicit namespace,
children of the genre element belong to the http://film-genre.example.com and not
to the http://dvd.example.com namespace as the outer elements do.
Of course it may be the case that an element does not require a default namespace and that
the parent default namespace is inappropriate. In such cases, we can remove any default
namespace completely, by setting it to the empty string xmlns="".

For default namespaces, remember that the scoping rules are

based on the familiar concept of “most local” where the declara-
tion nearest to the use has the highest precedence.

Attributes and Namespaces

So far all of our attention has been focused on the interplay between namespaces and ele-
ments. However, it is equally valid for attributes to be qualified with namespaces through the
same prefix syntax. When namespace-qualifying attributes have a default namespace, different
rules apply compared to elements. Attributes are not affiliated with any default namespace, so if
an attribute is to be namespace qualified, then it must be done so explicitly since any attribute
without a prefix will not be considered namespace qualified—even if declared in the scope of a
valid default namespace.
26 Chapter 2 • XML Fundamentals

The convention in XML is to associate elements with

namespaces, but to leave attributes unqualified since they reside
within elements with qualified names.

At this point we now understand both basic XML document structure and some more
advanced features like namespaces. These both set the scene for higher-level XML-based tech-
nologies (including Web services) which we shall continue by looking at XML Schema.

XML Schema
With the exception of the basic XML syntax, XML Schema is without a doubt the single most
important technology in the XML family. In the Web services world, XML Schema is the key
technology for enabling interoperation.
XML Schema is a W3C recommendation3 that provides a type system for XML-based
computing systems. XML Schema is an XML-based language that provides a platform-indepen-
dent system for describing types and interrelations between those types. Another aspect of XML
Schema is to provide structuring for XML documents.

Document Type Definitions (or DTDs) were the precursor to XML

Schema, and are a text- (not XML-) based format designed to
convey information about the structure of a document. Unlike
XML Schema, DTDs do not concern themselves with type sys-
tems, but simply constrain documents based on their structure.
Furthermore, since the DTD language is not XML-based, many
of the XML-friendly tools that we use are incapable of processing
DTDs. Because of these reasons, and the fact that no recent
Web services protocols have used DTDs, we can consider DTDs
as a deprecated technology in the Web services arena. Instead,
XML Schema has become the dominant metadata language for
Web services (and indeed for most other application areas by this
time).

In fact, the analogy between XML technologies and object-orientation is clear if we com-
pare XML documents to objects and XML Schema types to classes. XML documents that con-
form to a schema are known as instance documents, in the same way that objects of a particular
class are known as instances. Thus we can conceptually match XML Schema schemas with
classes and XML documents with objects, as shown in Figure 2-9.

3. See http://www.w3.org/XML/Schema#dev for links to the XML Schema specifications.

XML Schema 27

Figure 2-9 Comparing XML to object-oriented model.

The conceptual relationship between an object model and XML Schema is straightforward
to comprehend. Where object-based systems classes and their interrelationships provide the
blueprint for the creation and manipulation of objects, in the XML arena it is the type model
expressed in XML Schema schemas that constrain documents that confirm to those schemas.
Like object-oriented programming languages, XML Schema provides a number of built-in
types and allows these to be extended in a variety of ways to build abstractions appropriate for
particular problem domains. Each XML Schema type is represented as the set of (textual) values
that instances of that type can take. For instance the boolean type is allowed to take values of
only true and false, while the short type is allowed to take any value from -32768 to
32767 inclusively. In fact, XML Schema provides 44 different built-in types specified in the
http://www.w3.org/2001/XMLSchema namespace. Additionally, XML Schema allows users to
develop their own types, extending and manipulating types to create content models is the very
heart of XML Schema.

XML Schema and Namespaces

As we have seen, the built-in types from XML Schema are qualified with the namespace http://
www.w3.org/2001/XMLSchema. We must not use this namespace when we develop our own
types, in the same way that we would not develop types under the java.lang package in Java or
System namespace in .Net. However, like adding package or namespace affiliations in object-ori-
ented programming, affiliating a type with a namespace in XML Schema is straightforward. Add-
ing a targetNamespace declaration to an XML Schema to affiliate it with a namespace is
analogous to adding a package declaration to a Java class, as shown in Figure 2-10.
Exploring the Variety of Random
Documents with Different Content
one passion—the passion of a predestined tragical and unrequited
love.
END OF PART I.
[1] I have to thank Mr. Clement Shorter, who has purchased the
copyright of Charlotte Brontë's manuscripts, for his generous
permission to quote from these letters freely for the purposes of
my criticism.—(F.M.)
[2] Childe Harold, note 9 to canto iii.
[3] The author of Childe Harold adds on this note as a comment
upon what he has said of 'Love' as the inspiration of the greatest of
all Romantics, J.-J. Rousseau:—
'His love was passion's essence—as a tree
On fire by lightning; with ethereal flame
Kindled he was, and blasted; for to be
Thus, and enamour'd, were in him the same.
But his was not the love of living dame,
Nor of the dead who rise upon our dreams,
But of Ideal beauty, which became
In him existence and o'erflowing teems
Along his burning page, distemper'd tho' it seems.
This breathed itself to life in Julie, this
Invested her with all that's wild and sweet;
This hallow'd too the memorable kiss
Which every morn his fever'd lip would greet,
From hers, who but with friendship his would meet:
But to that gentle touch, thro' brain and breast
Flash'd the thrill'd spirit's love-devouring heat;
In that absorbing sigh perchance more blest
Than vulgar minds may be with all they seek possest.'
[4] Rudyard Kipling.
[5] See Letter, 18 Nov. I am giving my own translation from the
French of Charlotte's Letters in these extracts, not certainly on
account of any dissatisfaction with Mr. Spielmann's English versions
of them, but in order to avoid the risk of any infringement of Mr.
Spielmann's copyright in his Introduction.
[6] Mrs. Gaskell's Life, p. 290.
[7] Charlotte had been a year and ten months in England in
October 1845. This phrase, however, proves that the Letter belongs
to this year and not to 1844, and consequently that the Letter that
follows it, January 8, is 1846.
 PART II

SOME REMINISCENCES OF THE

REAL MONSIEUR AND MADAME HEGER

THIS SECOND PART IS

DEDICATED TO
MY BROTHER
THE LATE ABBÉ AUSTIN RICHARDSON
WHO DIED SUDDENLY, 20TH AUG. 1913

Dearest, before you went away

And left me here behind you,
How often would you talk to me,
And I, too, would remind you
Of stories in this book retold,
That for us two could ne'er grow old;
Of scenes that we could live through yet,
Just you and I,—and not forget:
And now I feel, since you are gone,
I wrote this book for you alone.

CHAPTER I

THE HISTORICAL DIFFICULTY: TO DISENTANGLE FACT

FROM FICTION

The purpose of the First Part of this study was to show that with the
knowledge of the Secret of Charlotte Brontë, brought to us by Dr. Paul
Heger's generous gift of these pathetic and beautiful Love-letters, the
'Problem of Charlotte Brontë,' as so many very clever but inattentive
psychological critics have stated it, has lost all claim to serious
attention.
The basis of the 'Problem' was the alleged 'dissonance' between
Charlotte's personality and her genius—between her dreary, desolate,
dull, well-tamed existence, uncoloured, untroubled by romance (as
Mrs. Gaskell painted it), and the passionate atmosphere of her novels,
where all events and personages are seen through the medium of one
sentiment—tragical romantic love.
We now know that the dissonance did not exist; that from her twenty-
sixth year downwards, Charlotte's life was, not only coloured, but
governed by a tragical romantic love: that, in its first stage, threw her
into a hopeless conflict against the force of things and broke her
heart: but that, because the battle was fought in the force, and in the
cause, of noble emotions, saved her soul alive; and called her genius
forth to life: so that it rose as an immortal spirit from the grave of
personal hopes.
Understanding this, we know that there is no 'Problem' of Charlotte
Brontë: but that her personality and her genius and her life and her
books were all those of a Romantic. But although there is no
psychological Problem, a difficulty that concerns the historical criticism
of Charlotte's life and her books does remain. And this difficulty has to
be faced and conquered, not by speculations nor arguments, but by
methods of enquiry.
When we study Charlotte Brontë's masterpiece Villette in comparison
with what we now know about the romance in her own life, we
recognise two facts: the first is that, in this work especially, she has
painted with such power the emotions she has undergone that her
words become feelings that lift and ennoble the reader's sensibility:
and thus serve him—in the way that it belongs to Romantics to serve
mankind.
But the second fact we discover is that,—again, in this book
particularly,—historical personages and real events are used as the
materials for an imaginary story, in a way that has produced critical
confusion: and what is graver still—has caused false and injurious
opinions to be formed about historical people. And the difficulty we
have to face is, not what amount of blame belongs to Charlotte for
misrepresenting historical facts, nor even need we ask ourselves what
reason she had for thus misrepresenting them. Because the reason
becomes plain when we take the trouble to realise that the motive the
writer of this work of genius had in view was one that concerned her
own personal liberation from haunting memories, rather than any
motive concerning the impressions she might produce.
There can be no doubt that Charlotte's motive in Villette, judged as a
method of personal salvation, was not only a permissible, but a noble
one. It is the one that Pater attributed to Michael Angelo: 'the effort
of a strong nature to attune itself to tranquillise vehement emotions
by withdrawing them into the region of ideal sentiments':—'an effort
to throw off the clutch of cruel and humiliating facts by translating
them into the imaginative realm, where the artist, the author, the
dreamer even, has things as he wills, because the hold of outward
things' (such a stern and merciless one in the case of Charlotte
Brontë!) 'is thrown off at pleasure.'
But, judged as a literary and historical method, was Charlotte Brontë's
manner of treating the real Director and Directress of the Pensionnat
in the Rue d'Isabelle a justifiable or fair one? Can she be held without
fault in this; that in Paul Emanuel and in Madame Beck she painted
Monsieur and Madame Heger in a way that rendered them visible to
every one who knew them; and then placed them in fictitious
circumstances that altered the character of their actions and feelings,
in such a way as to misrepresent their true behaviour? It seems to me
that we must admit that the authoress of the Professor and of Villette
adopted an unjust literary and historical method in so far as these real
people are concerned: and that in the case of Madame Heger
especially, passion and prejudice betrayed her: and rendered her
guilty of a fault that must be recognised as a very grave one. But
when this fault has been recognised and admitted, it seems to me a
conscientious critic's duty does not compel him to scold this woman of
genius for having the passions of her kind. A great Romantic is not an
angel: and in this case the main facts about Charlotte are not her
shortcomings as a celestial being, but her transcendent merits as an
interpreter of the human heart. For my own part, I confess that after
reading Charlotte's Love-letters, I am in no mood to look for faults in
her, nor even to lend much attention to some faults that, without
looking for them, one is bound to recognise. For what a thankless and
unseemly, as well as what an unprofitable, sort of criticism is that
represented in ancient days by the youngest amongst Job's Friends,
who had such a delightfully expressive name, Elihu, the son of
Barachel the Buzite, of the kindred of Ram! Elihu's criticism of Job
(the man of genius, plunged into dire misfortune, not by any fault or
folly of his own, but by the will of the Higher Powers, who desired to
prove his virtue and to call forth his genius), is exactly the same
method of criticising men and women of genius in the same case as
Job, practised by Elihu's intellectual descendents, Buzites of the
kindred of Ram, in all countries and in every age, down to England in
the twentieth century. The fundamental doctrine of this critical
method was, and is, that 'great men are not always wise,' and that it
is the vocation of smaller men to teach them wisdom, without
'respecting their persons or giving them flattering titles' (truly, as a
matter of fact, by calling them names—knaves, hypocrites,
sentimental cads, blackguards, etc.). In other words, the rule with
these Buzites is that the main purpose of criticising great people is to
find fault with them; to surprise them in their 'unwise' moments, to
concentrate attention upon the faults they may, or may not, have
committed in these moments; and to build upon these occasional real,
or imaginary, faults, psychological and pathological theories about the
madness, wickedness, or folly of people capable of them. And to
conclude that there is 'very much to reprobate and a great deal to
laugh at' in these men and women of genius—and that the fact that
they had genius, and that as witnesses to the 'instinct of immortality
in mortal creatures' they have served and honoured mankind, and
also have bequeathed to us treasures of ideal beauty, is a mere
accident, and may be left unnoticed.
But let not my portion ever be with these fault-finders, who 'darken
counsel by words without knowledge,' as the original Elihu was told,
'out of the Whirlwind,' by the Supreme Critic; 'in whose stead' the son
of Barachel had arrogated to himself the right to scold and scoff at
Job; and to tell him that his misfortunes were all the result of his bad
character and of his uncontrolled emotions. I refuse, then, to
recognise as a question of vital importance Charlotte's forgetfulness of
historical exactitude in Villette; and I do not myself understand how
any one (except a Buzite) who has read these Letters given to us by
Dr. Paul Heger, and especially the last one, that received no answer,
can help feeling that the suffering the writer of the Letters must have
undergone, in the unbroken silent solitude that followed her
unanswered appeal, must have made the hold upon her memory of
'outward things' so hard to bear, that to break that hold, to live in the
realm of imagination free from it, having things as she would, justified
almost any method of self-liberation.
Still the fact of the critical confusion of the personages in the novel
with the historical Director and Directress of the Pensionnat in the Rue
d'Isabelle does create difficulties in the way of forming right opinions.
And to remove them, we have to follow the plan already
recommended,—to make sure of our facts, before calling in the aid of
psychological arguments. And in this case, to see the position clearly,
we must disentangle from the imaginary story in Villette the real
personages and events woven into the fabric of a parable where, as I
have said, they appear amongst fictitious circumstances and produce
consequently false impressions. In other words, we have to recover a
clear knowledge of the true Monsieur Heger before we can determine
where 'Paul Emanuel' resembles, and where he differs from, the
Professor, whom Charlotte loved: but who never showed any particle
of love for Charlotte, such as Paul Emanuel bestowed on Lucy Snowe.
And then we have to re-establish in her true place, as Monsieur
Heger's wife and the mother of his five children, the true Directress of
the Pensionnat in the Rue d'Isabelle—who must be contrasted, rather
than compared, with the crafty, jealous and pitiless Madame Beck of
the novel, selfishly and cruelly interfering with the true course of an
entirely legitimate and romantic attachment between her English
teacher and her cousin, the Professor of literature. And the relative
positions of these two Directresses clearly seen, we have to ask
ourselves, Whether the real Madame Heger is proved to have had the
base and detestable character of the hateful Madame Beck? and
whether she really was, in any voluntary or even involuntary, way, the
direct cause of poor Charlotte's anguish, suspense and final heart-
break? And whether, given the positions and the different views of life
and sense of duty of the different people whose destinies become
entangled in this tragical romance, we can find fault with any person
concerned in these events,—unless, indeed, we follow Greek
methods, and drag in the Eumenides? Or, else, suppose it a parallel
case with Job's: and decide that it was the will of the Higher Powers
to prove Charlotte's virtue and to call forth her genius? But in so far
as mere mortals are concerned, we have to see whether anything else
could have happened, and whether poor Charlotte was not bound to
break her heart?
So that the purpose of the Second Part of this study of the 'Secret of
Charlotte Brontë' really lies outside of the 'Secret' itself, and becomes
an effort to know 'as in themselves they really were,' and
independently of their relationships with Charlotte, the Professor
whom she loved (probably much more than he deserved), and the
Directress of the Pensionnat in the Rue d'Isabelle—whom she
certainly hated, without any reasonable cause for this hatred,
although this hatred had a natural cause—that if only we will use
psychology for the purpose of penetrating facts, and not for playing
with such fictions as that it was 'no serious grief to Charlotte that
Monsieur Heger was married' we may easily discover. After all, one
must not ask for entire 'reasonableness' from Romantics, who see
personages and events through the medium of one great Passion.
And one must not demand from them absolute impartiality, when
judging the impediment that divides them from the object of this
passion.
We are not judges then in this case, but enquirers into the facts of the
personality and true characters of the Director and Directress of the
Bruxelles school and of their environment, as the influences that so
largely created the Romantic atmosphere where Charlotte's genius
lived and moved and had its being. And, by the special circumstances
of my own life, I am able to assist in a way that is not (so I am
tempted to believe) possible to any other living critic. The difficulty
that stands in the way of most modern investigators is that long ago
the historical people with their environment 'have become ghostly.'
Long ago, for most readers of Villette, the once famous Pensionnat de
Jeunes Filles in the Rue d'Isabelle, with its memory-haunted class-
rooms, with its high-walled garden in the heart of a city whose voices
reached one, as from a world far away, and 'down whose peaceful
alleys it was pleasant to stray and hear the bells of St Jean Baptiste
peal out with their sweet, soft, exalted sound,' have vanished out of
life. Yes—but out of my life they have not vanished! For me—the
historical Monsieur and Madame Heger exist quite independently of all
associations with the imaginary personages Paul Emanuel and
Madame Beck. For me—the old school, the class-rooms, the walled
garden, with its ancient pear-trees that still 'faithfully renewed their
perfumed snow in spring and honey-sweet pendants in autumn,'
remain—as they were planted vivid images and visions in my memory
half a century ago, when, as a schoolgirl, I knew nothing about
Charlotte Brontë nor Villette: but when I sat, twenty years after
Charlotte, in the class-rooms where she had waited for M. Heger, on
the eve of her departure from Bruxelles, myself an attentive pupil of
her Professor, and a witness, half terrified, and half exasperated, of
his varying moods. And when, too, I saw, rather than heard, Madame
Heger, moving noiselessly, where M. Heger's movements were always
attended with shock and excitement; only to me, Madame Heger
appeared always a friendly rather than an adverse presence—an
abiding influence of serenity that reassured one, after sudden
recurrent gusts of nerve-disturbing storms.
And I would point out that the value of my testimony about the
personal impressions I derived, quite independently of any knowledge
of Charlotte Brontë's residence in what was for me my school, and of
her enthusiasm for my Professor, or her dislike of my schoolmistress,
is enhanced both by the resemblances and by the differences of our
several points of view. Thus—like Charlotte—I was an English pupil
and a Protestant in this Belgian and Catholic school. Like her—my
vocation was to be that of a woman of letters. And although, when
she was brought under M. Heger's influence, she was a woman of
genius, already well acquainted with good literature, and not without
experience as a writer, whereas I was only an unformed girl, with very
little reading and no culture: and merely by force of an inborn desire
to follow a certain purpose in life that filled me with happiness, even
in anticipation, justified in supposing that I had a literary vocation at
all, and although no doubt I have not turned my advantages to
account as Charlotte did, yet I myself owe to M. Heger, not only
admirable rules for criticism and practice, that have always claimed
and still claim my absolute belief, but also I owe to him, as she did, a
full enjoyment of beautiful thoughts, beautifully expressed, and of
treasures of the mind and of the imagination, that, lying outside of
the recognised paths of English study, I might never have found, nor
even have recognised as treasures, had I not been cured of insularity
of taste by M. Heger.
So that upon this point I am able to say of M. Heger what Charlotte
said: he was the only master in literature I ever had; and up to the
present hour I esteem him, in this domain of literary composition, the
only master whose rules I trust.
But if my judgment of M. Heger, as a Professor, coincides with
Charlotte's, my judgment of him, outside of this capacity, does not
show him to me at all as the model of the man from whom she
painted Paul Emanuel. In other words, I never found nor saw in the
real Monsieur Heger the lovableness under the outward harshness,—
the depths of tenderness under the very apparent severity and
irritability,—the concealed consideration for the feelings of others,
under the outer indifference to the feelings of any one who ruffled his
temper; nor yet did I ever discover meekness and modesty in him,
under the dogmatic and imperious manner that swept aside all
opposition. In fact, I never found out that M. Heger wore a mask. But,
irritable, imperious, harsh, not unkind, but certainly the reverse of
tender, and without any consideration for any one's feelings, or any
respect for any one's opinions, thus, just as he seemed to be, so in
reality, in my opinion, M. Heger actually was. And what one must
remember is that Charlotte's point of view, from which she formed the
opinion that M. Heger was tender-hearted, and modest and meek,
was the point of view of a woman in love; and this standpoint is not
one that ensures impartiality.
My own point of view, between 1859 and 1861, was that of an English
schoolgirl, under sixteen, of a Belgian schoolmaster, over fifty, who in
his capacity of a literary Professor, was almost a deity to her; but who,
outside of this capacity, was not a lovable, but a formidable man: a
'Terror,' in the sense children and nursery-maids give the term; that is
to say, some one who is sure to appear upon the scene when one is
least prepared to face him, and who is constantly finding fault with
one. Now a 'Terror,' in this popular sense of the term, although he is
not a lovable, is not necessarily a hateful personage. There may
belong to him an interest of excitement, and even a secret admiration
for his cleverness in fulfilling his role of taking one unawares and
finding something in one to quarrel about. And most certainly this
interest of excitement, and even of a sense of amusement, entered
into my sentiment for M. Heger, whom I recognised as a double-
being, an admirable literary Professor, but an alarming and irritating
personality. But although I never hated him, I yet had some special
grievances against this 'Terror,' not only because he had a trick of
surprising me in weak moments, and of finding out my worst sides,
but also because he was really, in my own particular case, unjust; and
full of prejudice and impatience against my nationality, and personal
idiosyncrasies that were not faults; and that I couldn't help. Thus he
stirred up in me rebellious protests, that could not be uttered;
because how was an English schoolgirl of fifteen to protest against
the injustice of a Belgian 'Master,' in his own country, and his own
school: who was a man past fifty, too; and what was more, in his
capacity of literary Professor, if not quite a deity, at least, in my own
opinion, the keeper of the keys of palaces where dwelt the
Immortals?
And that my opinion of M. Heger's personality, as that of a 'Terror' (in
the childish and popular sense) did really show me the man apart
from the Professor very much as he really was, is confirmed by the
first impression he made upon Charlotte herself before the glamour of
romantic love had interfered with her critical perspicacity. Here is the
original description of M. Heger, in the early days of her residence in
Bruxelles:
'There is one individual of whom I have not yet spoken,' she wrote to
Ellen Nussey, 'M. Heger, the husband of Madame. He is Professor of
rhetoric: a man of power as to mind, but very choleric and irritable in
temperament, a little black being, with a face that varies in
expression. Sometimes he borrows the lineaments of a tom-cat:
sometimes those of a delirious hyena: occasionally, but very seldom,
he discards these perilous attractions and assumes an air not above
one hundred degrees removed from mild and gentleman-like. He is
very angry with me just now, because I have written a translation
which he stigmatises as peu correct. He did not tell me so, but wrote
the word on the margin of my book and asked me, in very stern
phrase, how it happened that my compositions were always better
than my translations, adding that the thing seemed to him
inexplicable. The fact is that three weeks ago in a high-flown humour
he forbade me to use either dictionary or grammar when translating
the most difficult English composition into French. This makes the
task rather arduous, and compels me every now and then to
introduce an English word, which nearly plucks the eyes out of his
head when he sees it. Emily and he don't draw well together at all.'
I am quoting this view of M. Heger's personality, taken by Charlotte
Brontë before she became a partial witness, because, by and by,
when I am giving my own reminiscences, it will be found that in 1842
M. Heger was very much the same Professor whom I knew in 1861.
And Madame Heger? Here too my impressions are obtained from a
point of view unquestionably more impartial than Charlotte Brontë's.
And it will be found that, when the alteration of clear power of vision
that personal prejudices make has been realised, my opposite
judgment of the Directress of the Pensionnat to the judgment of the
authoress of Villette, is not the result of any difference in the facts of
Madame Heger's characteristics and behaviour, but in the difference
between the standpoints from which we severally judge them.
Charlotte's standpoint was the one of the devotee, of the great spirit
who is neither a god nor a mortal, but the 'Child of plenty and
poverty, who is often houseless and homeless'—and who cannot well
see 'as in herself she really is,' the Mistress of the house; who
prudently, not necessarily with cruelty, closes the doors of her home
against intruders—that standpoint also is not one conducive to
impartial judgments.
My own point of view was that of a girl on the threshold of
womanhood, who saw in Madame Heger an embodiment of two
qualities especially, that, perhaps because I did not possess them and
could never possess them (passionate as I was by nature and with
strong personal likings and dislikings), inspired me with a sentiment of
reverence and wonder, as for a remote perfection, that, though
unattainable, it did one good to know existed somewhere; just as it
does one good, with feet planted on the earth, to see the stars. The
qualities I saw in Madame Heger were serene sweetness, a kindness
without preferences, covering her little world of pupils and teachers
with a watchful care. Tranquillité, Douceur, Bonté: the French words
express better than English ones the commingled qualities I felt
existed in Madame Heger as she moved noiselessly (as Charlotte
Brontë has described), whilst the more brilliant and gifted Professor's
movements were always stormy.
When relating these reminiscences of Monsieur and Madame Heger
and of the old school and garden, as I myself treasure them, and
quite independently of their associations with Charlotte Brontë, I shall
not be losing sight of the purpose that justifies this record (as an
endeavour to disentangle fact from fiction) if, in so far as the facts
that concern my own experiences are concerned, I ask now to be
allowed to relate them in a different tone—that is to say, not any
longer in the tone of a literary critic, nor as one supporting any thesis
or argument, but simply as a story-teller 'who has been young and
now is old.' And who, before the darkening day has turned to night,
calls to remembrance scenes and personages long since vanished out
of the world, but still alive for me, bathed in the light that shines upon
the undimmed visions of my youth—although to almost every one else
now alive these scenes have become 'as it were a tale that is told.'

CHAPTER II

MY FIRST INTRODUCTION TO CHARLOTTE BRONTË'S

PROFESSOR

[1]

'Madame,—quelquefois, donner, c'est semer'—Speech made to

my Mother by M. Heger.

In 1859 this memorable thing happened:—I was introduced by my

mother to M. Heger as his future pupil. I was fourteen years of age:
but I remember everything in connection with this event as though it
had happened yesterday. We were staying at Ostend, where my
mother had taken my brother and myself for a long summer holiday,
because she believed we had been previously overworked at our
former schools, from which she had removed us. She was convinced
that we both of us stood in need of sea-air, exercise and healthy
recreation, before we could take up our studies again, after the strain
we had undergone. Upon this point my brother and I were entirely of
one mind with our mother.
But after a holiday of three months, we had also begun to feel, with
her, that this state of things could not go on for ever, and that—as she
expressed it—'something had to be done with us.' What was done
with us was the result of circumstances that I cannot but regard as
fortunate, in my own case at any rate. They brought into my life, at a
very impressionable age, influences and memories that have always
been, and that are still, after more than half a century, extraordinarily
serviceable and sweet to me.
The first of these fortunate circumstances was the renewal (due to an
accidental meeting at Ostend) of my mother's friendship with a
relative whom she had lost sight of for a great many years; who had
married a Dutch lady and settled in Holland. The eldest daughter of
these re-discovered cousins was an exceptionally charming girl of
nineteen; and upon enquiry my mother found out that she had been
educated at a school in Brussels, situated in the Rue d'Isabelle, and
kept by a certain Madame Heger. How it came to pass that, only four
years after the publication of Villette, and two years after Mrs.
Gaskell's Life of Charlotte Brontë, it did not occur to my mother to
identify this particular Brussels school with the one where the Director
was the fiery and perilously attractive 'Professor Paul Emanuel' and
where the Directress was painted as the crafty and treacherous
'Madame Beck,' I really cannot say; but, so it was. There can be no
doubt that it was solely because the account rendered by her
delightful young kinswoman of the school where she had spent three
years was thoroughly satisfactory to my mother, and because the
unaffected and accomplished girl herself was an excellent proof of the
happy results of the education she had received, that my mother
made up her mind that the best thing that could be 'done with me,'
was to send me to Madame Heger's school. She had entered into
correspondence with this lady, and the plan had developed into a
further arrangement, that my brother was to be placed with a French
tutor recommended by Madame Heger, and who was the Professor of
History at her establishment. All these conditions were very nearly
settled, when M. Heger came to visit my mother at Ostend; to talk
matters over and to make final arrangements.
Of course from the point of view of my own humble interest I
recognised that the visit of this Brussels Professor was an event of
great importance. I was fully conscious of this, because my cousin
had told me a great deal about M. Heger, explaining that he was the
ruling spirit in the Pensionnat; that he was rather a terrible
personage; and that if he took a dislike to one,—well, he could be
very disagreeable. I had received so much advice upon this particular
subject from my cousin that I had talked the matter over very
seriously with my brother afterwards, and asked him what he thought
I ought to do in order to avoid the misfortune of offending M. Heger.
My brother's advice was sound:—'Don't let the man see you are afraid
of him,' he said, 'and then, whatever you do, don't show off.'
Keeping these counsels in mind, after M. Heger's arrival, I sat upon
the extreme edge of the rickety sofa that filled the darkest corner in
the little salle-à-manger of our Ostend apartments over the Patissier's
shop in the Rue de la Chapelle—I remember the very name of the
Patissier; it was Dubois—watching and listening eagerly to the
conversation of the Professor with my mother, who, strange to say,
did not seem to be in the least afraid of him; nor to recognise that he
was in any way different to ordinary mortals! And I must say, looking
back to that September afternoon to-day, and realising our attitude of
mind, my mother's and mine, towards this interesting personage to
us, but interesting solely in his character of my future teacher, there
does seem to me something amazing—so amazing as to be almost
amusing—in our total unconsciousness of his already well-established
real, or rather ideal claims as a personage immortalised in English
literature, by an illustrious writer who, four years before my birth, had
been his pupil; and whose romantic love for him, whilst it had broken
her heart, had served as the inspiration of her genius; so that her
literary masterpiece was precisely a book where the very school I was
going to inhabit was painted, with extraordinary veracity, in so far as
outward and local points of resemblance were concerned.
As for my own ignorance of all these circumstances there is nothing
strange in that. Fifty-four years ago a schoolgirl of my age was not
very likely to have read Villette. But what one may pause to inquire is
whether if by any accident the book had come into my hands, and
thus revealed to me my true position, should I have gone down on
my bended knees to my mother, or to express the case more exactly,
should I have flung my arms round her dear neck, and prayed, 'Don't
send me to this school; I am afraid of Professor Paul Emanuel; I
loathe Madame Beck; I shall never make friends with these horrid
Lesbassecouriennes?' Well, really, I don't think I should have done
anything of the sort! At fourteen one adores an adventure. It seems
to me probable that the excitement of going to the same school, and
learning my lessons in the same class-rooms, and treading the paths
of the same garden, and being instructed by the same teachers as a
writer of genius, who had left these scenes haunted by romance,
would have made me hold under all apprehensions of the
Lesbassecouriennes as school-fellows, of the perfidious Directress
with her stealthy methods of espionage, of the explosive, nerve-
wrecking Professor, always breaking in upon one like a clap of
thunder. Yes; but though held under, the apprehension would have
troubled my inner soul a good deal all the same; and this would have
been a pity. Because, in so far as the real Directress and real Belgian
schoolgirls whom I was going to know in the Rue d'Isabelle went,
these apprehensions would have been superfluous and misleading.
But now if there were no danger of my finding in the real Pensionnat
any spiritual counterparts of either the fictitious Madame Beck, or of
the perverted Lesbassecouriennes pupils, was it equally certain that, if
I had read Villette, I should not have recognised and been justified in
recognising in Monsieur Heger the original model and living image of
that immortal figure in English fiction, 'the magnificent-minded,
grand-hearted, dear, faulty little man'—Professor Paul Emanuel?
We shall perhaps be able to decide this question better at the end of
these reminiscences than here. But what must be realised is, that the
very fact that lends some general interest to my mother's first
impressions and my own about M. Heger is chiefly this: that it
expresses observations made from a purely personal standpoint; out
of sight of any literary views about 'Paul Emanuel,' or historical
judgments upon his relations with Charlotte Brontë. The perfectly
simple purpose we had in view was to see clearly what sort of a
Professor M. Heger was going to prove, and whether I was going to
do well as his pupil, and get on satisfactorily, amongst these foreign
surroundings.
My mother formed a most favourable opinion of our visitor, and
decided that I was fortunate in obtaining such a Professor. What had
especially impressed her was a sentence delivered by M. Heger, with a
masterly little gesture, that, as she herself said, entirely won her over
to his opinions upon a question where elaborate arguments might
have left her unconvinced. And I may observe here, that this
belonged to M. Heger's methods, not so much of arguing, as of
dispensing with arguments. His mind was made up upon most
subjects, and as he had got into the habit of regarding the world as
his class-room, and his fellow-creatures as pupils, he did not argue;
he told people what they ought to think about things. And in order to
make this method of settling questions not only convincing, but
stimulating, to his most intelligent pupils, he held in reserve a store of
these really luminous phrases, that he would use as little Lanterns,
flashing them, now in this direction, now in that, but always with a
special and appropriate direction given to the illuminative phrase, so
that it lit up the point of view upon which he desired to fix attention.
The particular sentence that conquered my mother's admiration and
acquiescence in M. Heger's point of view was the one I have made
the heading of this chapter. Here was how he contrived to introduce
it. After discussing the plan of my studies, and the arrangements for
my being taken to the English church by my brother every Sunday,
and allowed to take walks with him upon half-holidays (to all of which
of course I listened with passionate attention), they passed on to
discuss the terms asked by the tutor whom the Hegers had
recommended. My mother had been told by her Dutch cousin that
they were exorbitant terms; and, as a matter of fact, I believe they
were exactly twice the amount charged by the Hegers themselves: 'I
am not a rich woman,' my mother had said, apologetically, 'and I have
put aside a fixed sum for my children's education; I doubt if I can give
this.' ... Then did the Professor see, and seize, his opportunity:
'Madame,' he said, with a gesture, 'quelquefois, donner, c'est semer.'
My mother, dazzled with this prophetic utterance, remained
speechless and vanquished. In the evening of the same day I heard
her quote to the Dutch cousin, who did not approve of her consent to
these charges, 'what that clever man, Professor Heger) said so well,'
as though it had been unanswerable. In the course of the next two
years I often heard the same luminous phrase used, with equal
appropriateness, to light up other propositions. (I have heard M.
Heger use it in a sense where it became a different formula for
expressing a fundamental doctrine of Rousseau, thus, 'Instruire, ce
n'est pas donner, c'est semer,' but I never heard the words without
going back to the first impression, and to the vision it called up. I
would see again the little salle-à-manger in the Rue de la Chapelle at
Ostend, I would watch the masterly gesture of the Professor's hand
when he delivered his triumphant sentence, that is not an argument,
but is worth more; I would see the look of admiration and sudden
conviction come into my dear mother's face; I would feel myself
sitting upon the little rickety sofa in the dark corner, and I would
shudder with the foreknowledge of what was coming, for, woebetide
me that I should have to tell it, this first interview did not leave with
me the same impression of confidence in M. Heger as my future
teacher and guardian that it did with my mother; it left with me, on
the contrary, the miserable conviction that the very worst thing that
could have happened had happened; that M. Heger had taken a
vehement dislike to me, and consequently that all hope of happiness
for me in the Pensionnat in the Rue d'Isabelle was over and done
with.
And the worst of it was, that it was all my own fault; or rather, to be
just, it was my misfortune.
For I had had a really very bad time of it, sitting on that rickety little
sofa. My mother, who had only too flattering an opinion of me in
every way, had meant to say the kindest things about me to M. Heger,
and I knew this perfectly. But unfortunately, although she spoke
French with the greatest fluency and self-confidence (because as she
was a very charming woman, and as Frenchmen are always polite in
their criticism of the French of charming English women, she had
been very often complimented upon her command of the language),
—unfortunately, I say, her French was really English, literally
translated; and every one who has experience of what false meanings
can be conveyed by this sort of French will realise what I had
suffered, because, though I only spoke French badly at this time, I
understood the language better than my mother. And this is how I
had heard myself described to my future Professor. My mother had
wished to say that I was more fond of study and of reading than was
good for the health of a girl of my age; but what she actually said was
that I was fond of reading things that were not healthy or suitable
(convenable) for a young girl. Again, she had meant to say that as I
had worked too hard, she had let me run wild a little; and that
consequently I might find it difficult to get into working habits again;
but that as I had a capital head of my own, and plenty of courage, I
should, no doubt, soon get into good ways again. But instead of all
these flattering things (that might have been rather irritating too, only
a Professor of experience knows how to forgive a parent's partiality), I
had heard this fond mother of mine say that her daughter had
recently contracted the habits of a little savage; and that it would
require courageous discipline, as she was very headstrong, to bring
her into the right way again. It will be understood that to sit and
listen to all this about oneself was anguish. But, carefully watching M.
Heger's face, I had a notion that he had found out there was some
mistake. Still I was depressed and bewildered; and in dread of what I
was going to say, when the time came, as I knew it must, when he
would say something to me, and I should have a chance of answering
for myself. And the misfortune was, that when the critical moment
came, I wasn't expecting it; because, here, at least, what the author
of Villette says of Professor Paul Emanuel was true of M. Heger—
everything he did was sudden; and he always contrived to take one
by surprise.
It was immediately after he had won his triumph over my mother, and
in the moment when I myself was under the spell of admiration for
his talent, that he turned upon me, in a sort of flash, smiling down
upon me (very red and startled to find him so near), and nodding his
head with an irritating look of amusement as his penetrating eyes
searched my doleful face. 'Aa-ah,' he said, in a half-playful, but as it
sounded to me, more mocking, than kindly tone, 'Aa-ah' (another nod
of the head), 'so this is the little Savage I have to discipline and
vanquish, is it? And she is headstrong (têtue). Tell me, Mees, am I to
be too indulgent? or too severe? (Dois-je être trop indulgent? ou trop
sévère?') Now, if only I had made the natural reply, the one obviously
expected from me—the one any girl in my position would have made,
and which I myself should have made if I hadn't been addressed as 'a
little savage,' and if I hadn't been smarting under the sense that he
must have the worst possible opinion of me, and that I ought to
vindicate my honour in some way,—if only, in short, I had
remembered my brother's wholesome advice, 'Don't show off,' that is
to say, if only I had said, amiably and nicely, with a timid little smile,
'Trop indulgent, s'il vous plait, Monsieur,' THEN all would have been
well with me; M. Heger would have continued to smile; we should
have exchanged amiable glances and parted the best of friends.... But
of what use are these speculations? What I did reply to his question
of whether he was to be too indulgent or too severe was—'Ni l'un ni
l'autre, Monsieur; soyez juste, celà suffit' ... and I listened to the
broadness of my own British accent, whilst I said it, in despairing
wonder! M. Heger's smiles vanished; there came what I took to be a
'look of undying hatred' into his face—it was not perhaps so bad as all
that, but ... well, I certainly hadn't conquered his favour. He said
something disagreeable about Les Anglaises being over wise, too
philosophical for him, which my mother thought was a compliment to
my cleverness. But I knew what I had done, and that it could never
be undone, henceforth ...
Well, but the case really was not quite so desperate perhaps?
[1] This chapter is reproduced from the Cornhill by the kind
permission of Messrs. Smith, Elder and Co.

CHAPTER III

MONSIEUR AND MADAME HEGER AS I SAW THEM;

AND BELGIAN SCHOOLGIRLS AS I KNEW THEM
Let me give here my mother's, and my own, account of the
impressions made upon us by M. Heger's personal appearance at this
time.
'He is very like one of those selected Roman Catholic Priests,' my
mother told her Dutch relatives, 'who go into society and look after
the eldest sons of Catholic noblemen. He has too good a nose for a
Belgian and, I should say, he has Italian blood in him.'
My own report, to my brother, who made anxious inquiries of me, was
less flattering perhaps, but it was not intended to be disrespectful. I
always see M. Heger as I saw him then: as too interesting to be
alarming; but too alarming to be lovable.
'He is rather like Punch,' I said, 'but better looking of course; and not
so good-tempered.'
Let me justify these two descriptions by showing that both of them
were based upon an accurate observation of the man himself.
M. Heger, as I remember him, was no longer what Charlotte called
him, angrily, in her letter to Ellen Nussey, a little Black Being, and,
affectionately, under the disguise of Paul Emanuel, 'a spare, alert
man, showing the velvet blackness of a close-shorn head, and the
sallow ivory of his brow beneath.' M. Heger in 1859 was still alert, but
he was not spare, he was inclining towards stoutness. His hair was
not velvet black, but grizzled, and he was bald on the crown of his
head, in a way that might have been mistaken for a tonsure; and this
no doubt added to the resemblance my mother saw in him to a Priest.
He did not look in the least old, however. His brow, not sallow but
bronzed, was unwrinkled; his eyes were still clear and penetrating
(Charlotte said they were violet blue; and certainly she ought to have
known. Still, do violet eyes penetrate one's soul like points of steel?)
The Roman nose, that my mother thought too good a nose to be
Belgian, and that reminded me of Punch (but a good-looking Punch)
was a commanding feature. And the curved chin (also suggesting a
good-looking Punch, to a young and irreverent observer), although it
indicated humour, meant sarcasm, rather than a sense of fun. But
Monsieur Heger had one really beautiful feature, that I remember
often watching with extreme pleasure when he recited fine poetry or
read noble prose:—his mouth, when uttering words that moved him,
had a delightful smile, not in the least tender towards ordinary
mortals, but almost tender in its homage to the excellence of writers
of genius.
In brief, what M. Heger's face revealed when studied as the index of
his natural qualities, was intellectual superiority, an imperious temper,
a good deal of impatience against stupidity, and very little patience
with his fellow-creatures generally; it revealed too a good deal of
humour; and a very little kind-heartedness, to be weighed against any
amount of irritability. It was a sort of face bound to interest one; but
not, so it seems to me, to conquer affection. For with all these
qualities of intellect, power, humour, and a little kind-heartedness, one
quality was totally lacking: there was no love in M. Heger's face, nor
in his character, as I recall it; and, oddly enough, looking back now to
him as one of the personages in my own past to whom I owe most,
and whose mind I most admire, I have to recognise that in my
sentiment towards M. Heger to-day even, made up as it is half of
admiration and half of amusement, there is not one particle of love.
I have said—in connection with my first impression, that 'undying
hate' was the sentiment that M. Heger had conceived for me—that
really 'it was not so bad as all that.' Still, what happened at this first
interview, if it did not determine any deep-rooted antipathy to me,
planted from this moment in M. Heger's breast, did indicate, to a
certain extent, what the character of our future relationships was to
be—out of lesson-hours. In these hours, our relationships of Professor
and pupil were ideal. Seldom did an occasional misunderstanding
trouble them. Certainly, in my own day, no other pupil entered with so
much sympathetic admiration into the spirit of M. Heger's teaching as
I did. He saw and felt this; and here I, too, was for him, and as a
pupil, sympathetic. But in our personal relationships, there were
certain things in me that were antipathetic to M. Heger, and that
rubbed him so much the wrong way, that he was constantly (so it still
seems to me) unjust to what were not faults, but idiosyncrasies, that
belonged to my nationality and my character. First of all, there was
my English accent: and here this singular remark has to be made: I
never spoke such purely British French to any one as to M. Heger;
and this was the result of my constant endeavour to be very careful to
avoid the accent he disliked, when speaking to him. The second cause
of offence in me was also due to my nationality, or rather to my
upbringing. Like all English children of my generation, I had been
brought up to esteem it undignified, and even a breach of good
manners, to cry in public: and although I was tender-hearted and
emotional, I was not in the least hysterical; and except under the
stress of extreme distress, it cost me very little self-control not to
weep, as my Belgian schoolfellows did, very often, at the smallest
scolding; or even without a scolding, and simply because they were
bored—'ennuyée.' I remember now my surprise, at first hearing the
reply to my question to a sobbing schoolfellow: 'Pourquoi pleures-tu?
'Parce que je m'ennuie.' 'Why?' 'Mais je te le dis parce que je
m'ennuie.' Well, but M. Heger liked his pupils to cry, when he said
disagreeable things: or, in any case, he became gentle, and melted,
when they wept, and was amiable at once. But when one did not
weep, but appeared either unmoved, or indignant, he became more
and more disagreeable: and, at length, exasperated. A third
idiosyncrasy in me that he disliked was not national, but personal. It
was due to a sort of incipient Rousseau-ism,—that must have been
inborn, because I was never taught it, even in England. And yet there
it was, implanted in me as a sentiment, long before I recognised it as
an opinion or conviction, that I could express in words! This natural
sentiment, or principle, was the belief that 'I was born free: that my
soul was my own: and that there was no virtue, wisdom, nor
happiness possible for me outside of the laws of my own constitution.'
Unformulated, but inherent in me, this fundamental belief in myself as
a law to myself, no doubt betrayed itself in a sort of independence of
mind and manner very aggravating to my elders and betters, and to
those put in authority over me. And especially aggravating to an
authoritative Professor, who was, in all domains, opposed to
individualism, and the doctrine of personal rights and liberty. Thus in
literature M. Heger was a classic; in religion he was a dogmatic
Catholic; in politics he was an anti-democrat, a lover of vigorous
kings; and by constitution he was a king in his own right: a masterful
man, not only a law to himself, but a lord, by virtue of his sense of
superiority, to everyone else.
For these reasons, M. Heger and myself—on ideal terms as Professor
and pupil—were on bad terms outside of lesson-hours. We could not
quite dislike each other; but our relationships were stormy. There
were, however, intervals of calm.
I have said that with a good deal of admiration, gratitude, and some
amusement, there is no love for M. Heger intermingled with my
remembrances of him.
There is, on the contrary, a good deal of love in the sentiment I retain
for Madame Heger,—although, as a matter of fact, in the days when I
was her pupil I never remember any strong or warm feeling of
personal affection for her; nor have I any distinct personal obligation
to her, as to one who, like M. Heger, rendered me direct services by
her instructions or counsels. Nor yet again had Madame Heger any
strong personal liking for me; nor did she show me any special
kindness. But her kindness was of an all-embracing character. And so
was her liking for, or rather love of, all the inhabitants of the little
world she governed: a world that extended beyond the boundaries of
the actual walls of the Pensionnat, in any stated year; a world, made
up of all the girls who, before that year, and afterwards, through
several generations, had been and ever would be, her 'dear pupils';
'mes chères élèves';—terms that, uttered by her, were no mere
formula, but expressed a true sentiment, and a serious and, so it
seems to me, a beautiful and sweet idealism. This idealism in Madame
Heger, this constant love and care and watchfulness for the
community of girls, who, passing out of her hands, were to go out
into the world by and by, to fulfil there what Madame Heger saw to be
the kind and sweet and tranquil, and sometimes self-sacrificing and
sorrowful, mission of womanhood, enveloped the ideal school-
mistress with a sort of unfailing benevolence, that became a
pervading influence in the Pensionnat, singling out no particular
pupils, and withdrawn from none of them.
Here, it seems to me, and not at all in the reasons imagined by
Charlotte in the case of Madame Beck, we have the secret of Madame
Heger's system of government. I really am not, at this distance of
time, able to say positively whether there was, or was not, a
surveillance that might be called a system of espionage carried on,
keeping the head-mistress informed of the conversation and
behaviour of this large number of girls, amongst whom one or two
black sheep might have sufficed to contaminate the flock. I was not a
faultless, nor a model girl by any means: but I was a simple sort of
young creature with nothing of the black sheep in me; and I never
remember in my own case having my desk explored, nor my pockets
turned inside out. But if even this had been done, it would not have
gravely affected me; because neither in my pockets nor in my desk,
would anything have been found of a mysterious or interesting
character. But I should think it very probable that, in this very large
school, a watchful surveillance was kept up; and that if any of these
schoolgirls, most of them under sixteen, had attempted, after their
return from the monthly holiday, to bring back to school illegal stores
of sweets, or a naughty story book, and had concealed such things in
their school desks, well, I admit, I think it possible, that the sweets or
naughty book might have been missing from the desk next day. And
also that, in the course of the afternoon, a not entirely welcome
invitation would have been received by the imprudent smuggler of
forbidden goods to pay Madame Heger a visit in the Salon? These
things took place occasionally I know: and naturally, amongst the girls
public sympathy was with the smuggler. But I am not sure, if one
takes the point of view of a Directress, if a large girls' school could be
carried on successfully, were it made a point of honour that there
should be no surveillance, and that pupils might use their lockers as
cupboards for sweets, or as hiding-places for light literature.
But, apart from the fact that Madame Heger was, no doubt, both
watchful and uncompromising in her surveillance, based upon a firm
resolution that nothing 'inconvenient' must be smuggled in, or hidden
out of sight, as a source of mischief in the school, there was in her no
resemblance to the odious Madame Beck; that is to say, no moral
resemblance. In physical appearance, the author of Villette did use
Madame Heger evidently as the model for the picture of an entirely
different moral person. 'Her complexion was fresh and sanguine, her
eye blue and serene. Her face offered contrasts—its features were by
no means such as are usually seen in conjunction with a complexion
of such blended freshness and repose; their outline was stern; her
forehead was high, but narrow; it expressed capacity and some
benevolence, but no expanse.... I know not what of harmony
pervaded her whole person.'[1]
Taking this portrait from Villette, as it is given of Madame Beck, and
comparing it with my own recollections, and also with the photograph
I am fortunate enough to possess of Madame Heger at the age of
sixty, it seems to me that this is a very accurate physical description of
the real Directress of the school in the Rue d'Isabelle; who morally
was as unlike the fictitious Madame Beck as truth is unlike falsehood.
About the physical resemblance, I may say that, if I had trusted to my
own impressions, I should have rejected the assertion that the 'outline
of her features was stern.' I never remember associating sternness
with Madame Heger; though her supreme quality of serenity imposed
a sort of respect that had a little touch of fear in it. Upon re-
examining the photograph attentively, however, I find that it is true
that the outline of the features is stern; but I do not think that this
impression was conveyed by the younger face, remembered with
softened colouring; and lit up, as a characteristic expression, by a
normal expression of serenity and of kindliness. 'I know not what of
harmony pervaded her whole person': that sentence of Charlotte's
(used by her of the unspeakable Madame Beck) exactly expresses the
impression I still retain of the very estimable and, by myself,
affectionately remembered, Madame Heger.
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com