TEAMFLY

Team-Fly

Developing Java Web ServicesArchitecting and Developing Secure

Web Services Using Java

Ramesh NagappanRobert Skoczylas

Rima Patel Sriganesh

Developing JavaWeb Services

Architecting and Developing SecureWeb Services Using Java

Publisher: Robert IpsenEditor: Theresa HudsonDevelopmental Editors: Scott Amerman and James RussellEditorial Manager: Kathryn A. MalmManaging Editor: Angela SmithText Design & Composition: Wiley Composition Services

This book is printed on acid-free paper.

Copyright 2003 by Wiley Publishing Inc., Indianapolis, Indiana. All rights reserved.

Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmittedin any form or by any means, electronic, mechanical, photocopying, recording, scanning, orotherwise, except as permitted under Section 107 or 108 of the 1976 United States CopyrightAct, without either the prior written permission of the Publisher, or authorization throughpayment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rose-wood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470. Requests to the Pub-lisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc.,10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, E-mail:PERMCOORDINATOR@WILEY.COM.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used theirbest efforts in preparing this book, they make no representations or warranties with respectto the accuracy or completeness of the contents of this book and specifically disclaim anyimplied warranties of merchantability or fitness for a particular purpose. No warranty maybe created or extended by sales representatives or written sales materials. The advice andstrategies contained herein may not be suitable for your situation. You should consult witha professional where appropriate. Neither the publisher nor author shall be liable for anyloss of profit or any other commercial damages, including but not limited to special, inci-dental, consequential, or other damages.

For general information on our other products and services please contact our CustomerCare Department within the United States at (800) 762-2974, outside the United States at(317) 572-3993 or fax (317) 572-4002.

Wiley also publishes its books in a variety of electronic formats. Some content that appearsin print may not be available in electronic versions.

For more information about Wiley products, visit our Web site at www.wiley.com.

Trademarks: Wiley, the Wiley Pubishing logo and related trade dress are trademarks or reg-istered trademarks of Wiley Publishing, Inc., in the United States and other countries, andmay not be used without written permission. All other trademarks are the property of theirrespective owners. Wiley Publishing, Inc., is not associated with any product or vendormentioned in this book.

Library of Congress Cataloging-in-Publication Data:

ISBN 0-471-23640-3

Printed in the United States of America

10 9 8 7 6 5 4 3 2 1

Foreword xiii

Introduction xv

Part One Evolution and Emergence of Web Services 1

Chapter 1 Evolution of Distributed Computing 3What Is Distributed Computing? 4The Importance of Distributed Computing 5Client-Server Applications 6CORBA 8Java RMI 10Microsoft DCOM 13Message-Oriented Middleware 14Common Challenges in Distributed Computing 16The Role of J2EE and XML in Distributed Computing 17The Emergence of Web Services 20Summary 20

Chapter 2 Introduction to Web Services 21What Are Web Services? 22Motivation and Characteristics 24Why Use Web Services? 26Basic Operational Model of Web Services 26Core Web Services Standards 27

Extensible Markup Language (XML) 28Simple Object Access Protocol (SOAP) 28Web Services Definition Language (WSDL) 29Universal Description, Discovery, and Integration (UDDI) 29ebXML 30

Contents

v

Other Industry Standards Supporting Web Services 31Web Services Choreography Interface (WSCI) 31Web Services Flow Language (WSFL) 31Directory Services Markup Language (DSML) 31XLANG 32Business Transaction Protocol (BTP) 32XML Encryption (XML ENC) 32XML Key Management System (XKMS) 32XML Signature (XML DSIG) 33Extensible Access Control Markup Language (XACML) 33Security Assertions Markup Language (SAML) 33

Known Challenges in Web Services 34Web Services Software and Tools 34

BEA Systems Products 34Cape Clear Products 35IBM Products 35IOPSIS Products 35Oracle Products 35Sun Products 36Systinet Products 36

Web Services Strategies from Industry Leaders: An Overview 36Sun ONE (Sun Open Net Environment) 37IBM e-Business 37Microsoft .NET 37

Key Benefits of Web Services 38Summary 38

Part Two Web Services Architecture and Technologies 39

Chapter 3 Building the Web Services Architecture 41Web Services Architecture and Its Core Building Blocks 42Tools of the Trade 46

Simple Object Access Protocol (SOAP) 46Web Services Description Language (WSDL) 47Universal Description, Discovery, and Integration (UDDI) 49ebXML 49

Web Services Communication Models 50RPC-Based Communication Model 50Messaging-Based Communication Model 51

Implementing Web Services 52Developing Web Services-Enabled Applications 54

How to Develop Java-Based Web Services 55Developing Web Services Using J2EE: An Example 60

Summary 101

Chapter 4 Developing Web Services Using SOAP 103XML-Based Protocols and SOAP 104

The Emergence of SOAP 105Understanding SOAP Specifications 106

vi Contents

Anatomy of a SOAP Message 107SOAP Envelope 110SOAP Header 111SOAP Body 112SOAP Fault 112SOAP mustUnderstand 115SOAP Attachments 116

SOAP Encoding 118Simple Type Values 118Polymorphic Accessor 119Compound Type Values 120Serialization and Deserialization 124

SOAP Message Exchange Model 124SOAP Intermediaries 126SOAP Actor 127

SOAP Communication 128SOAP RPC 128

SOAP Messaging 130SOAP Bindings for Transport Protocols 131

SOAP over HTTP 131SOAP over SMTP 134Other SOAP Bindings 136SOAP Message Exchange Patterns 138

SOAP Security 140SOAP Encryption 140SOAP Digital Signature 142SOAP Authorization 143

Building SOAP Web Services 144Developing SOAP Web Services Using Java 145

Developing Web Services Using Apache Axis 146Installing Axis for Web Services 147Running Axis without Tomcat/Servlet Engine 149Axis Infrastructure and Components 149Axis Web Services Programming Model 154

Creating Web Services Using Axis: An Example 160Building Axis-Based Infrastructure 161Setting Up the ACME Web Services Environment 165Implementing the ACME Web Services 173

Known Limitations of SOAP 199Summary 199

Chapter 5 Description and Discovery of Web Services 201Web Services Description Language (WSDL) 202

WSDL in the World of Web Services 202Anatomy of a WSDL Definition Document 204WSDL Bindings 211WSDL Tools 214

Contents vii

Future of WSDL 221Limitations of WSDL 222

Universal Description, Discovery, and Integration (UDDI) 222UDDI Registries 223Programming with UDDI 226Inquiry API 235Publishing API 249Implementations of UDDI 254Registering as a Systinet UDDI Registry User 255Publishing Information to a UDDI Registry 257Searching Information in a UDDI Registry 260Deleting Information from a UDDI Registry 264Limitations of UDDI 269

Summary 269

Chapter 6 Creating .NET Interoperability 271Means of Ensuring Interoperability 272

Declaring W3C XML Schemas 273Exposing WSDL 273Creating SOAP Proxies 273Testing Interoperability 274

Microsoft .NET Framework: An Overview 274Common Language Runtime (CLR) 275.NET Framework Class Library 275

Developing Microsoft .NET Client for Web Services 276Key Steps in Creating a Web Service Requestor

Using the .NET Framework 276Case Study: Building a .NET Client for Axis Web Services 278

Challenges in Creating Web Services Interoperability 289Common SOAP/HTTP Transport Issues 290XML Schema- and XML-Related Issues 290SOAP/XML Message Discontinuities 290Version and Compatibility 291

The WS-I Initiative and Its Goals 291Public Interoperability testing efforts 292Summary 292

Part Three Exploring Java Web Services Developer Pack 293

Chapter 7 Introduction to the Java Web Services Developer Pack (JWSDP) 295Java Web Services Developer Pack 296

Java XML Pack 297Java APIs for XML 297JavaServer Pages Standard Tag Library 309Apache Tomcat Container 309Java WSDP Registry Server 310ANT Build Tool 310

viii Contents

Downloading the Web Services Pack 310Summary 311

Chapter 8 XML Processing and Data Binding with Java APIs 313Extensible Markup Language (XML) Basics 314

XML Syntax 316Namespaces 322Validation of XML Documents 324

Java API for XML Processing (JAXP) 337JAXP 337Uses for JAXP 338JAXP API Model 339JAXP Implementations 342Processing XML with SAX 342Processing XML with DOM 353XSL Stylesheets: An Overview 364Transforming with XSLT 372Threading 383

Java Architecture for XML Binding (JAXB) 383Data Binding Generation 386Marshalling XML 393Unmarshalling Java 395Other Callback Methods 396Sample Code for XML Binding 396

Summary 399

Chapter 9 XML Messaging Using JAXM and SAAJ 401The Role of JAXM in Web Services 402

JAXM Application Architecture 403JAXM Messaging: Interaction Patterns 406

JAXM API Programming Model 407javax.xml.messaging 407javax.xml.soap (SAAJ 1.1 APIs) 409

Basic Programming Steps for Using JAXM 413Using a JAXM Provider 413Using JAXM without a Provider (Using SOAPConnection) 419

JAXM Deployment Model 425Deploying JAXM-Based Applications in JWSDP 1.0 425Configuring JAXM Applications Using a JAXM Provider 427Configuring a Client 428Configuring a Provider 428

Developing JAXM-Based Web Services 430Point-to-Point Messaging Using JAXM (SOAPConnection) 431Asynchronous Messaging Using the JAXM Provider 439

JAXM Interoperability 450JAXM in J2EE 1.4 450Summary 450

Contents ix

Chapter 10 Building RPC Web Services with JAX-RPC 451The Role of JAX-RPC in Web Services 452

Comparing JAX-RPC with JAXM 454JAX-RPC Application Architecture 454

JAX-RPC APIs and Implementation Model 456JAX-RPC-Based Service Implementation 456JAX-RPC-Based Client Implementation 464

JAX-RPC-Supported Java/XML Mappings 471Java/WSDL Definition Mappings 474

Developing JAX-RPC-Based Web Services 476Creating a JAX-RPC-Based Service (BookPriceService) 476Developing JAX-RPC Clients (BookPriceServiceClient) 484

JAX-RPC in J2EE 1.4 491JAX-RPC Interoperability 491Summary 492

Chapter 11 Java API for XML Registries 493Introduction to JAXR 494JAXR Architecture 494

JAXR Architectural Components 494JAXR Capabilities and Capability Profiles 496The JAXR Programming Model 498

JAXR Information Model 499Classes and Interfaces 499Classification of Registry Objects 502Association of Registry Objects 508

JAXR Registry Services API 510Connection Management API 510Life Cycle Management API 516Query Management API 522

JAXR Support in JWSDP 1.0 532Registry Server 532Registry Browser 534

Understanding JAXR by Examples 536Publishing Using JAXR 536Querying Using JAXR 549Deleting Information Using JAXR 556

Summary 561

Chapter 12 Using the Java Web Services Developer Pack: Case Study 563Case Study Overview 563

The Roles of Service Provider, Requestor, and Registry 564Important Components and Entities 564

Case Study Architecture 567Design of Components 568

Provider Environment 568Designing the Publishing and Discovery Classes 572Designing the Service Requestor Environment

(computerBuy.com) 575

x Contents

TEAMFLY

Team-Fly

Implementation 582Developing the Service Environment 582Developing the Service Requestor Environment 593

Setting Up the JWSDP Environment 602Service Provider Runtime Infrastructure (acmeprovider.com) 602Service Registry Infrastructure 609Service Requestor Runtime Infrastructure (computerBuy.com) 610

Executing a Scenario 612Summary 615

Part Four Security in Web Services 617

Chapter 13 Web Services Security 619Challenges of Securing Web Services 620

Technologies behind Securing Web Services 621Rapid-Fire Cryptography 621

XML Encryption 630What XML Encryption Is 631Implementations of XML Encryption 633XML Encryption 633Encrypting XML Element 641Decrypting the XML Element 643Programming Steps for Encryption and Decryption 644

XML Signatures 650Types of XML Signatures 650XML Signature Syntax 652Canonicalization 655Implementations of XML Signature 656XML Signature: An Example 657

XML Key Management Specification (XKMS) 668XKMS Components 670XKMS Implementations 671XML Key Information Service Specification (X-KISS) 671XML Key Registration Service Specification (X-KRSS) 677

Security Assertions Markup Language (SAML) 685SAML Implementations 687SAML Architecture 689Authentication Assertion 691Attribute Assertion 693Authorization (Decision) Assertion 694SAML Bindings and Protocols 696Model of Producers and Consumers of SAML Assertions 697Single Sign-On Using SAML 698

XML Access Control Markup Language (XACML) 706Architecture of an XML Access Control System 707

Conclusion 710Summary 711

Contents xi

Part Five Web Services Strategies and Solutions 713

Chapter 14 Introduction to Sun ONE 715The Vision behind Sun ONE 715Delivering Services on Demand (SoD) 718

Web Applications 718Web Services 718Web Clients 723

Sun ONE Architecture 724Sun ONE Service Layers 724Sun ONE Standards and Technologies 725Sun ONE Product Stack: Integrated versus Integrate-able 727

Summary 731

Further Reading 733

Index 741

xii Contents

In the last decade of computing, we have seen a growing realization thatmost of the cost of computing comes not from the initial purchase of thehardware, not even from the purchase of the software, but from the cost ofresponding to change throughout the life of the system. When one partchanges, the degree of tight coupling between the elements of the systemdictates the brittleness or probability that change will be forced else-where. When you have to retest the software because the operating systemwas upgraded, thats brittleness. When you cant open your wordprocessor documents because the software version is wrong, thats brittle-ness. When a policy change in the accounting department dictates a soft-ware rewrite in the sales department, thats brittleness.

In seeking to eliminate brittleness, there have been three significant stepstaken:

The first was the introduction of Java technology, which separatedsoftware from the platform and allowed the creation of business logicthat wasnt greatly affected by changes to the underlying server.

The second was the introduction of Extensible Markup Language(XML), which separated the data from the software and enableddifferent software systems to share data without being affected bychanges to the data structures unless they needed to respond to them.

The most recent is the introduction of Web services. Web servicesseparate collaborating computer systems connected by networks,enabling them to delegate processing without becoming coupled ina brittle way.

Foreword

xiii

All three of these steps need one another. The maximum protectionagainst brittleness occurs when software written for the Java platform usesagreed XML data formats to supply or consume services, which areconnected using Web services technologies such as SOAP and WSDL andperhaps UDDI, if the application calls for it. Systems built with Javatechnology, XML, and Web services are loosely coupled in all three dimen-sions and will be the most resilient and flexible in the uncertain future thatfaces us all.

The conjunction of Java for the software, XML for the data, and Web ser-vices for the collaborative processing makes this book especially timelyand welcome. The majority of Web services development today is beingconducted using products from the extraordinarily rich Java community,and the rapid integration of Web services into Java 2 Enterprise Edition(J2EE) by the Java Community Process (JCP) offers the software developera comprehensive toolchest. In the pages that follow, you will find thefollowing:

Discussion of the evolving standards landscape for Web services,including the important developments at ebXML, the XML succes-sor to EDI

The Java APIs for XML (JAX) standards so skillfully evolved by theJCP to address everything connected to XML and Web services in avendor-neutral way

Information about the approaches being taken by all of the impor-tant Web services vendors, including a variety of tools

Practical examples that will help you get started with your own JavaWeb services implementations

A discussion of the essentials of Web services security thatconsiders both the needs of identity management and of in-transitdata protection

A valuable case study of a real-world Web services deploymentusing Java

Web services are such a fundamental idea in the world of connectedcomputing that they will rapidly become part of the everyday fabric ofinformation systems, just as Java technology and XML have already. I com-mend this book to you as your springboard to the future of how to makethe Internet work.

Simon Phipps (www.webmink.net)Chief Technology Evangelist at Sun Microsystems, Inc.

xiv Foreword

The big Web Services story is the end-to-end, side-to-side integration of technology.

James Gosling,The father of Java Platform

In this age of Internet, the success of the Web-based applications played avital role in moving our businesses from brick-and-mortar infrastructuresto 24 7 online businesses running on different systems and locations. Asa next evolutionary step, Web services are a new breed of Web-based appli-cations that address the new phenomenon of building a general-purposeplatform for creating efficient integration among business processes, appli-cations, enterprises, partners, customers, and so on. Web services are thenext evolution phase of distributed computing, based on XML standardsand Internet protocols. Web services provide a promising mechanism forcommunication and collaboration among business applications, whichwere constructed using various resources, that enables them to worktogether regardless of their differences in their underlying implementa-tion.

This book is a developers guide for designing and developing Web ser-vices using a Java platform. It bundles together a wealth of knowledge anddetailed study materials, focusing on concepts, technologies, and practicaltechniques for implementing and deploying Web services. It combines theWeb services vision of the Java community by providing in-depth coverageof the Java Web Services Developer Pack (JWSDP). In addition, this bookalso addresses the fundamentals of Web services from the ground up.

Introduction

xv

Technologies Covered in This Book

The book covers the core Web services standards and technologies fordesigning and implementing Web services. In particular, it focuses indepth on the following subject areas:

Web services standards, protocols, and technologies, includingSOAP, WSDL, and UDDI

Web services architecture and exposing J2EE applications as Webservices.

The development of Web services using Java APIs (JAXP, JAXB,JAX-RPC, JAXM, and JAXR) on JWSDP

Web services security technologies: XML Encryption, XML Signa-ture, Security Assertion Markup Language (SAML), XML Key Man-agement Services (XKMS), and XML Access Control MarkupLanguage (XACML)

Interoperability with Microsoft .NET The real-world implementation of Web services on JWSDP, using a

case study Introduction to Sun ONE

In addition, the book also provides example illustrations using toolssuch as Sun Microsystems JWSDP 1.0, BEA WebLogic 7.0, Systinet WASP4.0, Apache Axis 1.0 Beta 3, IBM XML Security Suite, Exolab CASTOR, andMicrosoft .NET framework.

Target Audience

This book is for all Web services enthusiasts, architects, and developerswho perceive Java as their platform of choice for Web services develop-ment and deployment.

This book presumes that the reader has the basic conceptual and program-ming knowledge of implementing Web applications using Java and XML.

Organization of the Book

The content of this book is organized into following five parts, with exclu-sive chapters concentrating on the Web services technologies:

xvi Introduction

Part One, Evolution and Emergence of Web Services. Introduces thereader to Web services by taking a evolutionary journey of distrib-uted computing and the emergence of Web services, and then itdevotes an exclusive overview on Web services, addressing its moti-vation, characteristics, industry standards and technologies, strate-gies and solutions, and its benefits and limitations.

Chapter 1, Evolution of Distributed Computing. The backgroundof distributed computing and the evolution of Internet-enabledtechnologies is explored in the first chapter. Here, we will examinethe definition and reasons for using distributed computing and thecore distributed computing technologies.

Chapter 2, Introduction to Web Services. This chapter presents anintroduction to Web services, especially focusing on the definitionof Web services, the standards and technologies that the servicesuse, and the benefits of using these services.

Part Two, Web Services Architecture and Technologies. This sectionwalks through the different Web services standards and technologiessuch as SOAP, WSDL, and UDDI with real-world examples. It fea-tures an in-depth coverage of the Web services architecture on a J2EEimplementation model, with example illustrations showing how toexpose enterprise applications to Web services. It also demonstratesan interoperability scenario with non-Java based Web services.

Chapter 3, Building the Web Services Architecture. This chapterfocuses on the Web services architecture, its core building blocks,implementation models, and deployment processes for buildingWeb services-based application solutions. In addition, this chapterillustrates, using an example, the development of a complete Webservices solution, exposing J2EE applications as services over theInternet.

Chapter 4, Developing Web services using SOAP. This chapterprovides an in-depth discussion on SOAP and its role in develop-ing Web services. It covers the W3C definition of SOAPs stan-dards, conventions, messages, communication models, andimplementation of SOAP-based applications for Web services. Inaddition, the chapter also includes example illustrations of adopt-ing different SOAP communication models in Web services.

Chapter 5, Description and Discovery of Web Services. Thischapter explains two important Web services specifications: WSDLand UDDI. It provides a detailed explanation on the important

Introduction xvii

aspects of a WSDL specification and examples of using WSDL toolswithin Web services development. UDDI specification also is cov-ered in great detail, complete with practical examples on workingwith UDDI registries. This chapter also covers issues with the cur-rent WSDL and UDDI technologies.

Chapter 6, Creating .NET Interoperability. This chapter discussesthe Web services interoperability scenarios, challenges, and issues.It also illustrates a full-featured interoperability example thatinvolves Java and Microsoft .NET environments.

Part Three, Exploring Java Web Services Developer Pack (JWSDP).This section exclusively focuses on Java APIs for Web services: JAXP,JAXB, JAXM, JAX-RPC, and JAX-R, and their reference implementa-tion on JWSDP. This section provides complete example illustrationsand developer essentials for implementing and deploying Java-basedWeb services on JWSDP. It also includes a special chapter that illus-trates a case study demonstrating a real-world Web services imple-mentation using JWSDP.

Chapter 7, Introduction to the Java Web Services Developer Pack.This chapter introduces the reader to the Java Web Services Devel-oper Pack (JWSDP) 1.0. It covers the Java XML Pack APIs and pro-vides an overview of the runtime environment and tools used forbuilding, deploying, and testing Web services applications.

Chapter 8, XML Processing and Data Binding with Java APIs.This chapter discusses the Java API for XML Processing (JAXP)and Java Architecture for XML Binding (JAXB). It provides anoverview of XML, DTD, and W3C XML Schema and then providesa walkthrough of the various techniques used for processing XMLdata. The chapter also covers the Simple API for XML (SAX), Doc-ument Object Model (DOM), and eXtensible Stylesheet transforma-tions (XSLT). For completeness, it also dedicates a section on databinding using JAXB.

Chapter 9, XML Messaging Using JAXM and SAAJ. This chapterdiscusses the Java API for XML messaging (JAXM) and SOAP withAttachment API for Java (SAAJ). It covers the JAXM/SAAJ-basedapplication architecture, an API programming model, and deploy-ment. It also includes example illustrations of using JAXM andSAAJ APIs.

Chapter 10, Building RPC Web Services with JAX-RPC. Thischapter discusses the Java API for XML RPC (Remote proceduralcall) for developing RPC-based Web services. It also covers the

xviii Introduction

JAX-RPC application architecture, an API programming model,deployment, and its different client Invocation models. It alsoincludes example illustrations using JAX-RPC and demonstratesthe different client invocations.

Chapter 11, Java API for XML Registries. This chapter providesdetailed information on the Java API for XML Registry (JAXR)specification from the Java Community Process (JCP). It also dis-cusses the various aspects of JAXR in terms of its classification sup-port, association support, connection management, life cyclemanagement, and querying capabilities. Also provided with thischapter is the discussion on the various JAXR examples aboutworking with UDDI registries.

Chapter 12, Using theJava Web Services Developer Pack: CaseStudy. This chapter focuses on implementing a complete Web ser-vices solution using the Java Web Services Developer Pack(JWSDP) 1.0. It puts together all of the JWSDP-based APIs coveredin this book to demonstrate a working Web services example.

Part Four, Security in Web Services. This section covers Web servicessecurity concepts and various security standards and technologies. Inaddition, it illustrates real-world Web services security implementa-tion scenarios on XML Encryption, XML Signature, and SAML-basedSingle Sign-On.

Chapter 13, Web Services Security. This chapter provides greatdetails on the issues revolving around Web services security, whichis followed by a discussion on each of the five major Web servicessecurity technologies: XML Encryption, XML Signature, XML KeyManagement Services (XKMS) , Security Assertions Markup Lan-guage (SAML), and XML Access Control Markup Language(XACML). It also provides good examples of using tools for secur-ing Web services through XML Encryption and XML Signaturetechnologies. In addition, the chapter provides a hypothetical usecase study of applying SAML for achieving Single Sign-On.

Part Five, Web Services Strategies and Solutions. This section intro-duces the reader to the Sun ONE initiative and provides information onSun ONE tools and platform servers for implementing Web services.

Chapter 14, Introduction to Sun ONE. This chapter aims at intro-ducing the Sun ONE platform technologies and products. It alsoprovides some brief information on the Sun ONE product stack,including its tools and platform servers. In addition, it also intro-duces ebXML technologies.

Introduction xix

Companion Web Site

All the source code from the example illustrations found within this bookis available for download from the companion Web site, www.wiley.com/compbooks/nagappan.

In addition, this site also includes the following material:

Errata Further reading and references Changes and updates

Support and Feedback

The authors would like to receive the readers feedback. You are encour-aged to post questions and/or contact the authors at their prospectiveemail addresses. Contact information can be found at the companion Website to this book at www.wiley.com/compbooks/nagappan.

xx Introduction

TEAMFLY

Team-Fly

The authors would like to extend their big thanks to the Wiley publishingteam, including Terri Hudson, Kathryn Malm, Scott Amerman, James Rus-sell, and Angela Smith; and the reviewers for their constant help, frombeginning to end, in fulfilling this dream work.

Thanks to Simon Phipps for writing the Foreword and sharing his bestthoughts on Web services in this book.

Thanks, too, to Dave Martin and Chris Steel for having reviewed thiswork and sharing their views.

Heartfelt gratitude to our friends at Sun Microsystems for their help andsupport while accomplishing this work.

Ramesh Nagappan

After six months of hard work, it is an utter surprise for me to see the com-pletion of the project, and its a great feeling to see the quality of work theway we wanted.

Its quite fun to recall the genesis of this book: Two friends, SadaRajagopalan and Sameer Tyagi, started gathering ideas for this mammothproject on September 19, 2001, at the John Harvards Pub in Natick, Massa-chusetts. Around 10:45 P.M., after most of us had three pitchers of aseasonal flavor and all had shared rip-roaring hilarious talk, Sada, whodidnt drink, came up with this idea of writing a book on Java Web ser-vices. In the next few days, we created the proposal for this book. BothSameer and Sada helped us initiating this huge effort and in getting theproposal written; much thanks to them for all their efforts. Its always been

Acknowledgments

xxi

great fun calling Sameer in the middle of the night, especially to discussemerging technologies, as well as known bugs, changes, and issues.

My special thanks goes to Sunil Mathew and my fellow architects at theSun Java center for their constant encouragement for writing this book.Thanks to the Apache Axis team and my friends at Apache Software Foun-dation for being helpful, answering my questions, and updating me withchanges. Thanks also to the Exolab CASTOR, Systinet WASP, and W3CSOAP discussion groups for answering my questions with insightfulresponses and initiating valuable discussions.

Finally, the largest share of the credit goes to my loving wife, Joyce, mylittle buddy Roger, and my parents for all their love and support. Onlythrough their love and support, am I able to accomplish any goal.

Robert Skoczylas

After long, long hours of hard work we are finally done with the chaptersand ready to thank and recognize the help of many people who gave usguidance, direction, and support.

Special thanks to Sada Rajagopalan for his contributions to the firstchapter of the book. Your amazing motivation got this ball rolling. Thanks!

Big thanks to all the expert contributors of the Java, XML, and Web ser-vices mailing lists out there, your feedback adds a great value to this work.

I want to thank all my friends at the Sun Java Center for all their support,especially my manager, Sunil Mathew, for his constant encouragement.

Also, to the many people who have directly or indirectly influenced mycareer: Albert Rudnicki, Paul Dhanjal, Mario Landreville, Ray Sabourin,Jan Bratkowski, Sameer Tyagi, Tomasz Ratajczak, Carol McDonald, ChrisSteel, and Dan Hushon.

Thanks to my parents, Urszula and Jacek, and my brother Slawomir,who always show me the way things need to be done.

Finally, I would like to thank my fiance, Urszula Masalska, who put upwith this project for the last couple of months. Without your patience andencouragement, I wouldnt have had the strength to cross the finish line.Thank you!

Rima Patel Sriganesh

This book has been an exciting roller-coaster ride of my life. When I firststarted as a reviewer of this book, I never imagined that I would end upbeing a co-author. All of a sudden when that opportunity came up, I was

xxii Acknowledgements

overwhelmed with joy as well as work. It was during the course of thisproject that I realized how challenging this work was, not only for me, butalso for my husband, whod happily let go of all the fun moments for thesake of my venture.

In the memory of those fun times we lost, I would like to dedicate myshare of this hard work, success, and joy to my dearest and loving hus-band, Sriganesh, without whom life would not have been so beautiful; andmy most wonderful parents, who spent the best years of their lives inturning me into the person that I am today.

My special thanks goes to Max Goff, without whom I would have nevergot to know this beautiful world of Technology Evangelism.

Also, I would like to thank my fellow Evangelist Carol McDonald forintroducing me to my cohorts on this book as well as the rest of the Sun Tech-nology Evangelism group, including my manager, Reginald Hutcherson.

Acknowledgements xxiii

Ramesh Nagappan is an experienced software architect who specializes inJava-, XML-, and CORBA-based distributed computing architectures forInternet-based business applications and Web services. He is an active con-tributor to popular Java- and XML-based open source applications. Prior tothis work, he has co-authored two books on J2EE and EAI. He is also anavid Unix enthusiast. Before he hooked on to Java and CORBA, he workedas a research engineer for developing software solutions for CAD/CAM,fluid dynamics, system simulation, and aerodynamics applications.

Currently he is working for Sun Microsystems as an Enterprise JavaArchitect with the Sun Java Center in Boston. He lives in the Boston suburbwith his wife and son. In his spare time, he enjoys water sports and playingwith his son Roger. He graduated from Harvard University, specializing inapplied sciences. He can be reached at nramesh@post.harvard.edu.

Robert Skoczylas is an Enterprise Java Architect with the Sun Java Centerin Boston, MA. He has many years of experience in Object-Oriented tech-nologies. He has been focused on design and implementation of large-scaleenterprise applications using Java and XML technologies. He currentlyconsults and mentors large projects specializing in server side Java-baseddistributed systems. He is driven by new technologies and loves readingabout them. His past experiences include working on Java applications forperformance and analysis of cellular networks with Ericsson ResearchCanada (LMC).

About the Authors

xxv

Outside of Java World, Robert enjoys techno beats, playing golf, and anyextreme sport that involves a board, including snowboarding, wakeboard-ing, and windsurfing. Robert holds a Computer Science degree fromConcordia University in Montreal, Quebec. He can be reached atrobert.skoczylas@sun.com

Rima Patel Sriganesh is a Technology Evangelist presently working forSun Microsystems, Inc. She specializes in Java, XML, and Integration plat-forms. Her areas of technology passion include Distributed ComputingModels, Trust Computing, Semantic Web, and Grid Computing architec-tures. She speaks frequently at premiere industry conferences such asJavaOne, Web Services Edge, SIGS 101, and others. She also publishes onSuns Technology Evangelism portal: www.sun.com/developers/evang-central.

Rima and her husband live in the Greater Boston area. She most enjoyseating spicy Indian food and reading Gujarati novels. Also, she lovesdebating world politics and Vedic philosophy when energy permits her.Rima holds a graduate degree in Mathematics. She can be reached atrima.patel@sun.com.

xxvi About the Authors

PA R T

One

Evolution and Emergenceof Web Services

3The Internet has revolutionized our business by providing an informationhighway, which acts as a new form of communication backbone. This newinformation medium has shifted business from the traditional brick-and-mortar infrastructures to a virtual world where they can serve customersnot just the regular eight hours, but round-the-clock and around the world.Additionally, it enhances our organizations with significant benefits interms of business productivity, cost savings, and customer satisfaction. Asa result, modern organizations are compelled to re-evaluate their businessmodels and plan on a business vision to interact with their customers, sup-pliers, resellers, and partners using an Internet-based technology space. Toachieve this goal of obtaining an Internet business presence, organizationsare exposing and distributing their business applications over the Internetby going through a series of technological innovations. The key phenome-non of enabling business applications over the Internet is based on a fun-damental technology called distributed computing.

Distributed computing has been popular within local area networks formany years, and it took a major step forward by adopting the Internet as itsbase platform and by supporting its open standard-based technologies.This chapter discusses the background of distributed computing and theevolution of Internet-enabled technologies by focusing on the following:

Evolution of DistributedComputing

C H A P T E R

1

The definition of distributed computing The importance of distributed computing Core distributed computing technologies such as the following:

Client/server CORBA Java RMI Microsoft DCOM Message-Oriented Middleware

Common challenges in distributed computing The role of J2EE and XML in distributed computing Emergence of Web services and service-oriented architectures

What Is Distributed Computing?

In the early years of computing, mainframe-based applications were consid-ered to be the best-fit solution for executing large-scale data processing appli-cations. With the advent of personal computers (PCs), the concept of softwareprograms running on standalone machines became much more popular in terms of the cost of ownership and the ease of application use. With the number of PC-based application programs running on independentmachines growing, the communications between such application programsbecame extremely complex and added a growing challenge in the aspectof application-to-application interaction. Lately, network computing gainedimportance, and enabling remote procedure calls (RPCs) over a network pro-tocol called Transmission Control Protocol/Internet Protocol (TCP/IP) turnedout to be a widely accepted way for application software communication.Since then, software applications running on a variety of hardware platforms,operating systems, and different networks faced some challenges whenrequired to communicate with each other and share data. This demandingrequirement lead to the concept of distributed computing applications.

As a definition, Distributing Computing is a type of computing in whichdifferent components and objects comprising an application can be locatedon different computers connected to a network (www.webopedia.com,May 2001). Figure 1.1 shows a distributed computing model that providesan infrastructure enabling invocations of object functions located anywhereon the network. The objects are transparent to the application and provideprocessing power as if they were local to the application calling them.

4 Chapter 1

TEAMFLY

Team-Fly

Figure 1.1 Internet-based distributed computing model.

Today, Sun Java RMI (Remote Method Invocation), OMG CORBA (Com-mon Object Request Broker Architecture), Microsoft DCOM (DistributedComponent Object Model), and Message-Oriented Middleware (MOM)have emerged as the most common distributed computing technologies.These technologies, although different in their basic architectural designand implementation, address specific problems in their target environ-ments. The following sections discuss the use of distributed computingand also briefly describe the most popular technologies.

The Importance of Distributed Computing

The distributed computing environment provides many significant advan-tages compared to a traditional standalone application. The following aresome of those key advantages:

Higher performance. Applications can execute in parallel and distributethe load across multiple servers.

User

Application Internet

Object

Object

Object

TCP/IP

TCP/IP

TCP/IP

Evolution of Distributed Computing 5

Collaboration. Multiple applications can be connected through stan-dard distributed computing mechanisms.

Higher reliability and availability. Applications or servers can beclustered in multiple machines.

Scalability. This can be achieved by deploying these reusable distrib-uted components on powerful servers.

Extensibility. This can be achieved through dynamic (re)configura-tion of applications that are distributed across the network.

Higher productivity and lower development cycle time. By breakingup large problems into smaller ones, these individual componentscan be developed by smaller development teams in isolation.

Reuse. The distributed components may perform various servicesthat can potentially be used by multiple client applications. It savesrepetitive development effort and improves interoperability betweencomponents.

Reduced cost. Because this model provides a lot of reuse of oncedeveloped components that are accessible over the network, signifi-cant cost reductions can be achieved.

Distributed computing also has changed the way traditional networkprogramming is done by providing a shareable object like semantics acrossnetworks using programming languages like Java, C, and C++. The fol-lowing sections briefly discuss core distributed computing technologiessuch as Client/Server applications, OMG CORBA, Java RMI, MicrosoftCOM/DCOM, and MOM.

Client-Server Applications

The early years of distributed application architecture were dominated bytwo-tier business applications. In a two-tier architecture model, the first(upper) tier handles the presentation and business logic of the user applica-tion (client), and the second/lower tier handles the application organizationand its data storage (server). This approach is commonly called client-serverapplications architecture. Generally, the server in a client/server applicationmodel is a database server that is mainly responsible for the organizationand retrieval of data. The application client in this model handles most of thebusiness processing and provides the graphical user interface of the applica-tion. It is a very popular design in business applications where the user

6 Chapter 1

interface and business logic are tightly coupled with a database server forhandling data retrieval and processing. For example, the client-server modelhas been widely used in enterprise resource planning (ERP), billing, andInventory application systems where a number of client business applica-tions residing in multiple desktop systems interact with a central databaseserver.

Figure 1.2 shows an architectural model of a typical client server systemin which multiple desktop-based business client applications access a cen-tral database server.

Some of the common limitations of the client-server application modelare as follows:

Complex business processing at the client side demands robustclient systems.

Security is more difficult to implement because the algorithms andlogic reside on the client side making it more vulnerable to hacking.

Increased network bandwidth is needed to accommodate many callsto the server, which can impose scalability restrictions.

Maintenance and upgrades of client applications are extremely diffi-cult because each client has to be maintained separately.

Client-server architecture suits mostly database-oriented standaloneapplications and does not target robust reusable component-oriented applications.

Figure 1.2 An example of a client-server application.

Application

TCP/IP

Application

TCP/IP

Application

TCP/IP

DatabaseServer

Evolution of Distributed Computing 7

CORBA

The Common Object Request Broker Architecture (CORBA) is an industrywide, open standard initiative, developed by the Object ManagementGroup (OMG) for enabling distributed computing that supports a widerange of application environments. OMG is a nonprofit consortiumresponsible for the production and maintenance of framework specifica-tions for distributed and interoperable object-oriented systems.

CORBA differs from the traditional client/server model because it pro-vides an object-oriented solution that does not enforce any proprietary pro-tocols or any particular programming language, operating system, orhardware platform. By adopting CORBA, the applications can reside andrun on any hardware platform located anywhere on the network, and canbe written in any language that has mappings to a neutral interface defini-tion called the Interface Definition Language (IDL). An IDL is a specificinterface language designed to expose the services (methods/functions) ofa CORBA remote object. CORBA also defines a collection of system-levelservices for handling low-level application services like life-cycle, persis-tence, transaction, naming, security, and so forth. Initially, CORBA 1.1 wasfocused on creating component level, portable object applications withoutinteroperability. The introduction of CORBA 2.0 added interoperabilitybetween different ORB vendors by implementing an Internet Inter-ORBProtocol (IIOP). The IIOP defines the ORB backbone, through which otherORBs can bridge and provide interoperation with its associated services.

In a CORBA-based solution, the Object Request Broker (ORB) is anobject bus that provides a transparent mechanism for sending requests andreceiving responses to and from objects, regardless of the environment andits location. The ORB intercepts the clients call and is responsible for find-ing its server object that implements the request, passes its parameters,invokes its method, and returns its results to the client. The ORB, as part ofits implementation, provides interfaces to the CORBA services, whichallows it to build custom-distributed application environments.

Figure 1.3 illustrates the architectural model of CORBA with an examplerepresentation of applications written in C, C++, and Java providing IDLbindings.

The CORBA architecture is composed of the following components:

IDL. CORBA uses IDL contracts to specify the application boundariesand to establish interfaces with its clients. The IDL provides a mecha-nism by which the distributed application components interfaces,inherited classes, events, attributes, and exceptions can be specifiedin a standard definition language supported by the CORBA ORB.

8 Chapter 1

Figure 1.3 An example of the CORBA architectural model.

ORB. It acts as the object bus or the bridge, providing the communi-cation infrastructure to send and receive request/responses from theclient and server. It establishes the foundation for the distributedapplication objects, achieving interoperability in a heterogeneousenvironment.

Some of the distinct advantages of CORBA over a traditionalclient/server application model are as follows:

OS and programming-language independence. Interfaces betweenclients and servers are defined in OMG IDL, thus providing the fol-lowing advantages to Internet programming: Multi-language andmulti-platform application environments, which provide a logicalseparation between interfaces and implementation.

Legacy and custom application integration. Using CORBA IDL,developers can encapsulate existing and custom applications ascallable client applications and use them as objects on the ORB.

Rich distributed object infrastructure. CORBA offers developers arich set of distributed object services, such as the Lifecycle, Events,Naming, Transactions, and Security services.

Location transparency. CORBA provides location transparency: Anobject reference is independent of the physical location and applica-tion level location. This allows developers to create CORBA-basedsystems where objects can be moved without modifying the underly-ing applications.

CORBA - ORB (Object Bus)

Client Stubs Server Skeletons

C C++ Java C C++ Java

IDL IDL IDL

Evolution of Distributed Computing 9

Network transparency. By using the IIOP protocol, an ORB can inter-connect with any ORB located elsewhere on the network.

Remote callback support. CORBA allows objects to receive asynchro-nous event notification from other objects.

Dynamic invocation interface. CORBA clients can both use staticand dynamic methods invocations. They either statically define theirmethod invocations through stubs at compile time, or have theopportunity to discover objects methods at runtime. With thoseadvantages, some key factors, which affected the success of CORBAevident while implementing CORBA-based distributed applications,are as follows:

High initial investment. CORBA-based applications require hugeinvestments in regard to new training and the deployment ofarchitecture, even for small-scale applications.

Availability of CORBA services. The Object services specified bythe OMG are still lacking as implementation products.

Scalability. Due to the tightly coupled nature of the connection-oriented CORBA architecture, very high scalability expected inenterprise applications may not be achieved.

However, most of those disadvantages may be out of date today. TheInternet community for the development of Intranet and Extranet applica-tions has acknowledged using CORBA with IIOP and Java as their tools ofchoice. Sun has already released its JDK 1.4 (Java development kit), whichincludes a full-featured CORBA implementation and also a limited set ofservices.

Java RMI

Java RMI was developed by Sun Microsystems as the standard mechanismto enable distributed Java objects-based application development using theJava environment. RMI provides a distributed Java application environ-ment by calling remote Java objects and passing them as arguments orreturn values. It uses Java object serializationa lightweight object persis-tence technique that allows the conversion of objects into streams.

Before RMI, the only way to do inter-process communications in the Javaplatform was to use the standard Java network libraries. Though thejava.net APIs provided sophisticated support for network functionalities,

10 Chapter 1

they were not intended to support or solve the distributed computing chal-lenges. Java RMI uses Java Remote Method Protocol (JRMP) as the inter-process communication protocol, enabling Java objects living in differentJava Virtual Machines (VMs) to transparently invoke one anothers meth-ods. Because these VMs can be running on different computers anywhereon the network, RMI enables object-oriented distributed computing. RMIalso uses a reference-counting garbage collection mechanism that keepstrack of external live object references to remote objects (live connections)using the virtual machine. When an object is found unreferenced, it is con-sidered to be a weak reference and it will be garbage collected.

In RMI-based application architectures, a registry (rmiregistry)-orientedmechanism provides a simple non-persistent naming lookup service that isused to store the remote object references and to enable lookups fromclient applications. The RMI infrastructure based on the JRMP acts asthe medium between the RMI clients and remote objects. It interceptsclient requests, passes invocation arguments, delegates invocationrequests to the RMI skeleton, and finally passes the return values of themethod execution to the client stub. It also enables callbacks from serverobjects to client applications so that the asynchronous notifications can beachieved.

Figure 1.4 depicts the architectural model of a Java RMI-based applica-tion solution.

Figure 1.4 A Java RMI architectural model.

JavaClient

RMIStubs

Remote Ref. Layer

Java RMIServer

RMISkeleton

Remote Ref. Layer

JRMP

Evolution of Distributed Computing 11

The Java RMI architecture is composed of the following components:

RMI client. The RMI client, which can be a Java applet or a stand-alone application, performs the remote method invocations on aserver object. It can pass arguments that are primitive data types orserializable objects.

RMI stub. The RMI stub is the client proxy generated by the rmicompiler (rmic provided along with Java developer kitJDK) thatencapsulates the network information of the server and performsthe delegation of the method invocation to the server. The stub alsomarshals the method arguments and unmarshals the return valuesfrom the method execution.

RMI infrastructure. The RMI infrastructure consists of two layers: theremote reference layer and the transport layer. The remote referencelayer separates out the specific remote reference behavior from theclient stub. It handles certain reference semantics like connectionretries, which are unicast/multicast of the invocation requests. Thetransport layer actually provides the networking infrastructure, whichfacilitates the actual data transfer during method invocations, thepassing of formal arguments, and the return of back execution results.

RMI skeleton. The RMI skeleton, which also is generated using the RMIcompiler (rmic) receives the invocation requests from the stub andprocesses the arguments (unmarshalling) and delegates them to the RMIserver. Upon successful method execution, it marshals the return valuesand then passes them back to the RMI stub via the RMI infrastructure.

RMI server. The server is the Java remote object that implements theexposed interfaces and executes the client requests. It receives incom-ing remote method invocations from the respective skeleton, whichpasses the parameters after unmarshalling. Upon successful methodexecution, return values are sent back to the skeleton, which passesthem back to the client via the RMI infrastructure.

Developing distributed applications in RMI is simpler than developingwith Java sockets because there is no need to design a protocol, which is avery complex task by itself. RMI is built over TCP/IP sockets, but theadded advantage is that it provides an object-oriented approach for inter-process communications. Java RMI provides the Java programmers withan efficient, transparent communication mechanism that frees them of allthe application-level protocols necessary to encode and decode messagesfor data exchange. RMI enables distributed resource management, bestprocessing power usage, and load balancing in a Java application model.RMI-IIOP (RMI over IIOP) is a protocol that has been developed for

12 Chapter 1

enabling RMI applications to interoperate with CORBA components.Although RMI had inherent advantages provided by the distributed objectmodel of the Java platform, it also had some limitations:

RMI is limited only to the Java platform. It does not provide lan-guage independence in its distributed model as targeted by CORBA.

RMI-based application architectures are tightly coupled because ofthe connection-oriented nature. Hence, achieving high scalability insuch an application model becomes a challenge.

RMI does not provide any specific session management support. Ina typical client/server implementation, the server has to maintainthe session and state information of the multiple clients who accessit. Maintaining such information within the server application with-out a standard support is a complex task.

In spite of some of its limitations, RMI and RMI-IIOP has become thecore of the J2EE architectural model due to its widespread acceptance inthe Java distributed computing paradigm and rich features.

Microsoft DCOM

The Microsoft Component Object Model (COM) provides a way for Windows-based software components to communicate with each other bydefining a binary and network standard in a Windows operating environ-ment. COM evolved from OLE (Object Linking and Embedding), whichemployed a Windows registry-based object organization mechanism.COM provides a distributed application model for ActiveX components.

As a next step, Microsoft developed the Distributed Common ObjectModel (DCOM) as its answer to the distributed computing problem in theMicrosoft Windows platform. DCOM enables COM applications to com-municate with each other using an RPC mechanism, which employs aDCOM protocol on the wire.

Figure 1.5 shows an architectural model of DCOM.DCOM applies a skeleton and stub approach whereby a defined inter-

face that exposes the methods of a COM object can be invoked remotelyover a network. The client application will invoke methods on such aremote COM object in the same fashion that it would with a local COMobject. The stub encapsulates the network location information of the COMserver object and acts as a proxy on the client side. The servers can poten-tially host multiple COM objects, and when they register themselvesagainst a registry, they become available for all the clients, who then dis-cover them using a lookup mechanism.

Evolution of Distributed Computing 13

Figure 1.5 Basic architectural model of Microsoft DCOM.

DCOM is quite successful in providing distributed computing supporton the Windows platform. But, it is limited to Microsoft application envi-ronments. The following are some of the common limitations of DCOM:

Platform lock-in State management Scalability Complex session management issues

Message-Oriented Middleware

Although CORBA, RMI, and DCOM differ in their basic architecture andapproach, they adopted a tightly coupled mechanism of a synchronouscommunication model (request/response). All these technologies arebased upon binary communication protocols and adopt tight integrationacross their logical tiers, which is susceptible to scalability issues.

Message-Oriented Middleware (MOM) is based upon a loosely coupledasynchronous communication model where the application client does notneed to know its application recipients or its method arguments. MOMenables applications to communicate indirectly using a messagingprovider queue. The application client sends messages to the messagequeue (a message holding area), and the receiving application picks up the

Client COMrun timeServer

ComponentCOM

run time

RPC

DCOMProtocol

RPC

COMrun time

ServerComponent

14 Chapter 1

TEAMFLY

Team-Fly

message from the queue. In this operation model, the application sendingmessages to another application continues to operate without waiting forthe response from that application.

Figure 1.6 illustrates a high-level MOM architecture showing application-to-application connectivity.

In MOM-based architecture, applications interacting with its messaginginfrastructure use custom adapters. Client applications communicate withthe underlying messaging infrastructure using these adapters for sendingand receiving messages. For reliable message delivery, messages can bepersisted in a database/file system as well.

Some of the widely known MOM-based technologies are SunONE Mes-sage Queue, IBM MQSeries, TIBCO, SonicMQ, and Microsoft MessagingQueue (MSMQ). The Java Platform provides a Java-based messaging API(JMS-Java Message Service), which is developed as part of the Sun JavaCommunity Process (JCP) and also is currently part of the J2EE 1.3 specifi-cations. All the leading MOM vendors like SunONE, TIBCO, IBM, BEA,Talarian, Sonic, Fiorano, and Spiritwave support the JMS specifications.

JMS provides Point-to-Point and Publish/Subscribe messaging modelswith the following features:

Complete transactional capabilities Reliable message delivery Security

Figure 1.6 A typical MOM-based architectural model.

ApplicationA

ApplicationB

Persistence

Adapter APIAdapter API

MOMInfrastructure

Evolution of Distributed Computing 15

Some of the common challenges while implementing a MOM-basedapplication environment have been the following:

Most of the standard MOM implementations have provided nativeAPIs for communication with their core infrastructure. This hasaffected the portability of applications across such implementationsand has led to a specific vendor lock-in.

The MOM messages used for integrating applications are usuallybased upon a proprietary message format without any standardcompliance.

Adopting a JMS-based communication model enables a standardizedway to communicate with a MOM provider without having to lock in toany specific vendor API. It leverages the use of open standards l, thusenhancing the flexibility in connecting together diverse applications.

Common Challenges in Distributed Computing

Distributed computing technologies like CORBA, RMI, and DCOM havebeen quite successful in integrating applications within a homogenousenvironment inside a local area network. As the Internet becomes a logicalsolution that spans and connects the boundaries of businesses, it alsodemands the interoperability of applications across networks. This sectiondiscusses some of the common challenges noticed in the CORBA-, RMI-,and DCOM-based distributed computing solutions:

Maintenance of various versions of stubs/skeletons in the client andserver environments is extremely complex in a heterogeneous net-work environment.

Quality of Service (QoS) goals like Scalability, Performance, andAvailability in a distributed environment consume a major portionof the applications development time.

Interoperability of applications implementing different protocols onheterogeneous platforms almost becomes impossible. For example, aDCOM client communicating to an RMI server or an RMI clientcommunicating to a DCOM server.

Most of these protocols are designed to work well within local net-works. They are not very firewall friendly or able to be accessedover the Internet.

The biggest problem with application integration with this tightlycoupled approach spearheaded by CORBA, RMI, and DCOM was that it

16 Chapter 1

influenced separate sections of the developer community who werealready tied to specific platforms. Microsoft Windows platform developersused DCOM, while UNIX developers used CORBA or RMI. There was nobig effort in the community to come up with common standards thatfocused on the interoperability between these diverse protocols, thusignoring the importance, and hence, the real power of distributed comput-ing. Enough said about the weaknesses, we now are going to discuss whatis becoming an alternative technology, which still has all the existingstrengths and targets to solve the complexities of current systems.

The Role of J2EE and XML in Distributed Computing

The emergence of the Internet has helped enterprise applications to be eas-ily accessible over the Web without having specific client-side softwareinstallations. In the Internet-based enterprise application model, the focuswas to move the complex business processing toward centralized serversin the back end.

The first generation of Internet servers was based upon Web servers thathosted static Web pages and provided content to the clients via HTTP(HyperText Transfer Protocol). HTTP is a stateless protocol that connectsWeb browsers to Web servers, enabling the transportation of HTML con-tent to the user.

With the high popularity and potential of this infrastructure, the pushfor a more dynamic technology was inevitable. This was the beginning ofserver-side scripting using technologies like CGI, NSAPI, and ISAPI.

With many organizations moving their businesses to the Internet, awhole new category of business models like business-to-business (B2B)and business-to-consumer (B2C) came into existence.

This evolution lead to the specification of J2EE architecture, which pro-moted a much more efficient platform for hosting Web-based applications.J2EE provides a programming model based upon Web and businesscomponents that are managed by the J2EE application server. The applica-tion server consists of many APIs and low-level services available to thecomponents. These low-level services provide security, transactions, con-nections and instance pooling, and concurrency services, which enable aJ2EE developer to focus primarily on business logic rather than plumbing.

The power of Java and its rich collection of APIs provided the perfectsolution for developing highly transactional, highly available and scalableenterprise applications. Based on many standardized industry specifica-tions, it provides the interfaces to connect with various back-end legacy and

Evolution of Distributed Computing 17

information systems. J2EE also provides excellent client connectivity capa-bilities, ranging from PDA to Web browsers to Rich Clients (Applets,CORBA applications, and Standard Java Applications).

Figure 1.7 shows various components of the J2EE architecture.A typical J2EE architecture is physically divided in to three logical tiers,

which enables clear separation of the various application components withdefined roles and responsibilities. The following is a breakdown of func-tionalities of those logical tiers:

Presentation tier. The Presentation tier is composed of Web compo-nents, which handle HTTP requests/responses, Session management,Device independent content delivery, and the invocation of businesstier components.

Figure 1.7 J2EE application architecture.

IIOP

Applets/Applications

J2EE Server

WEB CONTAINER

EJB CONTAINER

LEGACYAPPLICATIONS

HTTP

Web Browser PDA

HTTP

i iCLIENTS

PRESENTATIONTIER

APPLICATIONTIER

INTEGRATIONTIER

DATABASE

SQL/JDBC

18 Chapter 1

Application tier. The Application tier (also known as the Businesstier) deals with the core business logic processing, which may typi-cally deal with workflow and automation. The business componentsretrieve data from the information systems with well-defined APIsprovided by the application server.

Integration tier. The Integration tier deals with connecting and com-municating to back-end Enterprise Information Systems (EIS), data-base applications and legacy applications, or mainframe applications.

With its key functionalities and provisions for partitioning applicationsinto logical tiers, J2EE has been highly adopted as the standard solution fordeveloping and deploying mission critical Web-based applications. Thepower of J2EE-based applications would be tremendous, if it is enabledto interoperate with other potential J2EE-deployed applications. Thisenables business components across networks to negotiate among themand interact without human interaction. It also enables the realization ofsyndication and collaboration of business processes across the Internet byenabling them to share data and component-level processes in real time.This phenomenon is commonly referred to as business-to-business (B2B)communication.

The emergence of the Extensible Markup Language (XML) for definingportable data in a structured and self-describing format is embraced by theindustry as a communication medium for electronic data exchange. UsingXML as a data exchange mechanism between applications promotes inter-operability between applications and also enhances the scalability of theunderlying applications. Combining the potential of a J2EE platform andXML offers a standard framework for B2B and inter-application communi-cation across networks.

With J2EE enabling enterprise applications to the Internet and XMLacting as a glue bridges these discrete J2EE-based applications by facili-tating them to interoperate with each other. XML, with its incredibleflexibility, also has been widely adopted and accepted as a standard bymajor vendors in the IT industry, including Sun, IBM, Microsoft, Oracle,and HP. The combination of these technologies offers more promising pos-sibilities in the technology sector for providing a new way of application-to-application communication on the Internet. It also promotes a newform of the distributed computing technology solution referred to as Webservices.

Evolution of Distributed Computing 19

The Emergence of Web Services

Today, the adoption of the Internet and enabling Internet-based applica-tions has created a world of discrete business applications, which co-existin the same technology space but without interacting with each other. Theincreasing demands of the industry for enabling B2B, application-to-application (A2A), and inter-process application communication has led toa growing requirement for service-oriented architectures. Enabling ser-vice-oriented applications facilitates the exposure of business applicationsas service components enable business applications from other organiza-tions to link with these services for application interaction and datasharing without human intervention. By leveraging this architecture, italso enables interoperability between business applications and processes.

By adopting Web technologies, the service-oriented architecture modelfacilitates the delivery of services over the Internet by leveraging standardtechnologies such as XML. It uses platform-neutral standards by exposingthe underlying application components and making them available to anyapplication, any platform, or any device, and at any location. Today, thisphenomenon is well adopted for implementation and is commonly referredto as Web services. Although this technique enables communicationbetween applications with the addition of service activation technologiesand open technology standards, it can be leveraged to publish the servicesin a register of yellow pages available on the Internet. This will further rede-fine and transform the way businesses communicate over the Internet. Thispromising new technology sets the strategic vision of the next generation ofvirtual business models and the unlimited potential for organizations doingbusiness collaboration and business process management over the Internet.

Summary

In this chapter, we discussed the evolution and the basics of distributedcomputing technologies and the emergence of Web services that define thenext generation of business services models and business process commu-nication over the Internet.

In particular, we looked at the background of distributed computing; thefundamentals of distributed computing techniques; the basics of industry-accepted technologies like CORBA, RMI, DCOM, and MOM; the role of J2EEand XML for enabling distributed computing over the Internet; and the con-cept of service-oriented architectures and the emergence of Web services.

In the following chapters, we will go into a more detailed introduction toWeb services concepts and focus on the various aspects of designing anddeveloping Web services.

20 Chapter 1

21

Today, people use the Internet as an everyday service provider for readingheadline news, obtaining stock quotes, getting weather reports, shoppingonline, and paying bills, and also for obtaining a variety of informationfrom different sources. These Web-enabled applications are built usingdifferent software applications to generate HTML, and their access is lim-ited only through an Internet browser or by using an application-specificclient. This is partially due to the limitations of HTML and the Web server-based technologies, which are primarily focused on presentation and theirinability to interact with another application.

The emergence of Web services introduces a new paradigm for enablingthe exchange of information across the Internet based on open Internetstandards and technologies. Using industry standards, Web servicesencapsulate applications and publish them as services. These servicesdeliver XML-based data on the wire and expose it for use on the Internet,which can be dynamically located, subscribed, and accessed using a widerange of computing platforms, handheld devices, appliances, and so on.Due to the flexibility of using open standards and protocols, it also facili-tates Enterprise Application Integration (EAI), business-to-business (B2B)integration, and application-to-application (A2A) communication acrossthe Internet and corporate intranet. In organizations with heterogeneousapplications and distributed application architectures, the introduction of

Introduction to Web Services

C H A P T E R

2

Web services standardizes the communication mechanism and enablesinteroperability of applications based on different programming languagesresiding on different platforms.

This chapter presents an introduction on Web services, especially focus-ing on the following:

The definition of Web services Motivation and characteristics of Web services Web services industry standards and technologies Web services strategies and solutions Benefits of Web services

Todays leading technology vendors have set their strategies aroundproviding infrastructure solutions for delivering Web services. With theincreasing adoption, acceptance, and availability of platforms, languages,application tools, and supporting technology solutions, it is expected thatWeb services will become a new service industry providing businesses services over the Internet.

What Are Web Services?

Web services are based on the concept of service-oriented architecture(SOA). SOA is the latest evolution of distributed computing, which enablessoftware components, including application functions, objects, andprocesses from different systems, to be exposed as services.

According to Gartner research (June 15, 2001), Web services areloosely coupled software components delivered over Internet standardtechnologies.

In short, Web services are self-describing and modular business applica-tions that expose the business logic as services over the Internet throughprogrammable interfaces and using Internet protocols for the purpose ofproviding ways to find, subscribe, and invoke those services.

Based on XML standards, Web services can be developed as loosely cou-pled application components using any programming language, any pro-tocol, or any platform. This facilitates delivering business applications as aservice accessible to anyone, anytime, at any location, and using any platform.

Consider the simple example shown in Figure 2.1 where a travel reser-vation services provider exposes its business applications as Web servicessupporting a variety of customers and application clients. These businessapplications are provided by different travel organizations residing atdifferent networks and geographical locations.

22 Chapter 2

Figure 2.1 An example scenario of Web services.

The following is a typical scenario:

1. The Travel service provider deploys its Web services by exposing thebusiness applications obtained from different travel businesses likeairlines, car-rental, hotel accommodation, credit card payment, andso forth.

WirelessDevice

Find Services

RegisterServices

InvokeServices

TravelServicesRegistry

ServiceRequestor

TravelReservation

ServicesProvider

Desktop

PDA

Automobile

Organization

AirlineReservation

System

Rental Car Reservation

System

HotelReservation

System

Map and WeatherInformation

System

Credit CardPayment System

Introduction to Web Services 23

2. The service provider registers its business services with descriptionsusing a public or private registry. The registry stores the informationabout the services exposed by the service provider.

3. The customer discovers the Web services using a search engine or bylocating it directly from the registry and then invokes the Web ser-vices for performing travel reservations and other functions over theInternet using any platform or device.

4. In the case of large-scale organizations, the business applicationsconsume these Web services for providing travel services to theirown employees through the corporate intranet.

The previous example provides a simple scenario of how an organiza-tions business functionalities can be exposed as Web services and invokedby its customers using a wide range of application clients.

As we discussed earlier, Web services are typically implemented basedon open standards and technologies specifically leveraging XML. TheXML-based standards and technologies, such as Simple Object Access Pro-tocol (SOAP); Universal Description, Discovery, and Integration (UDDI);Web Services Definition Language (WSDL); and Electronic Business XML(ebXML), are commonly used as building blocks for Web services. Thesetechnologies are discussed briefly in the section Core Web Services Stan-dards, which follows later.

Motivation and Characteristics

Web-based B2B communication has been around for quite some time.These Web-based B2B solutions are usually based on custom and propri-etary technologies and are meant for exchanging data and doing transac-tions over the Web. However, B2B has its own challenges. For example, inB2B communication, connecting new or existing applications and addingnew business partners have always been a challenge. Due to this fact, insome cases the scalability of the underlying business applications isaffected. Ideally, the business applications and information from a partnerorganization should be able to interact with the application of the potentialpartners seamlessly without redefining the system or its resources. Tomeet these challenges, it is clearly evident that there is a need for standardprotocols and data formatting for enabling seamless and scalable B2Bapplications and services. Web services provide the solution to resolvethese issues by adopting open standards. Figure 2.2 shows a typical B2Binfrastructure (e-marketplace) using XML for encoding data betweenapplications across the Internet.

24 Chapter 2

TEAMFLY

Team-Fly

Figure 2.2 Using XML for encoding data in a B2B communication.

Web services enable businesses to communicate, collaborate, and con-duct business transactions using a lightweight infrastructure by adoptingan XML-based data exchange format and industry standard deliveryprotocols.

The basic characteristics of a Web services application model are asfollows:

Web services are based on XML messaging, which means that thedata exchanged between the Web service provider and the user aredefined in XML.

Web services provide a cross-platform integration of business appli-cations over the Internet.

To build Web services, developers can use any common program-ming language, such as Java, C, C++, Perl, Python, C#, and/orVisual Basic, and its existing application components.

Web services are not meant for handling presentations like HTMLcontextit is developed to generate XML for uniform accessibilitythrough any software application, any platform, or device.

Buyer

Partner Seller

Internet

XML XML

XML

Introduction to Web Services 25

Because Web services are based on loosely coupled application com-ponents, each component is exposed as a service with its uniquefunctionality.

Web services use industry-standard protocols like HTTP, and theycan be easily accessible through corporate firewalls.

Web services can be used by many types of clients. Web services vary in functionality from a simple request to a complex

business transaction involving multiple resources. All platforms including J2EE, CORBA, and Microsoft .NET provide

extensive support for creating and deploying Web services. Web services are dynamically located and invoked from public and

private registries based on industry standards such as UDDI andebXML.

Why Use Web Services?

Traditionally, Web applications enable interaction between an end user anda Web site, while Web services are service-oriented and enable application-to-application communication over the Internet and easy accessibility toheterogeneous applications and devices. The following are the major tech-nical reasons for choosing Web services over Web applications:

Web services can be invoked through XML-based RPC mechanismsacross firewalls.

Web services provide a cross-platform, cross-language solutionbased on XML messaging.

Web services facilitate ease of application integration using a light-weight infrastructure without affecting scalability.

Web services enable interoperability among heterogeneousapplications.

Basic Operational Model of Web Services

Web services operations can be conceptualized as a simple operationalmodel that has a lot in common with a standard communication model(see Figure 2.3). Operations are conceived as involving three distinct rolesand relationships that define the Web services providers and users.

26 Chapter 2

Figure 2.3 Web services operational model, showing roles and relationships.

These roles and relationships are defined as follows:

Service provider. The service provider is responsible for developingand deploying the Web services. The provider also defines the ser-vices and publishes them with the service broker.

Service broker. The service broker (also commonly referred to as aservice registry) is responsible for service registration and discoveryof the Web services. The broker lists the various service types,descriptions, and locations of the services that help the servicerequesters find and subscribe to the required services.

Service requestor. The service requestor is responsible for the serviceinvocation. The requestor locates the Web service using the servicebroker, invokes the required services, and executes it from the serviceprovider.

Lets examine more closely some of the open standard technologies suchas SOAP, WSDL, UDDI, and ebXML that enable Web services.

Core Web Services Standards

The five core Web services standards and technologies for building andenabling Web services are XML, SOAP, WSDL, UDDI, and ebXML. Anoverview of each is presented in the following sections.

ServiceBroker

Invoke Service

Register ServiceDi

scov

er Se

rvice

ServiceRequestor

ServiceProvider

Introduction to Web Services 27

Extensible Markup Language (XML)In February 1998, the Worldwide Web Consortium (W3C) officiallyendorsed the Extensible Markup Language (XML) as a standard data for-mat. XML uses Unicode, and it is structured self-describing neutral datathat can be stored as a simple text document for representing complex dataand to make it readable. Today, XML is the de facto standard for structuringdata, content, and data format for electronic documents. It has already beenwidely accepted as the universal language lingua franca for exchanginginformation between applications, systems, and devices across the Internet.

In the core of the Web services model, XML plays a vital role as the com-mon wire format in all forms of communication. XML also is the basis forother Web services standards. By learning XML, you will be well preparedto understand and explore Web services. For more information on XML, goto Chapter 8, XML Processing and Data Binding with Java APIs, or to theofficial W3C Web site for XML at www.w3c.org/XML/.

Simple Object Access Protocol (SOAP)Simple Object Access Protocol, or SOAP, is a standard for a lightweightXML-based messaging protocol. It enables an exchange of informationbetween two or more peers and enables them to communicate with eachother in a decentralized, distributed application environment. Like XML,SOAP also is independent of the application object model, language, andrunning platforms or devices. SOAP is endorsed by W3C and key industryvendors like Sun Microsystems, IBM, HP, SAP, Oracle, and Microsoft.These vendors have already announced their support by participating inthe W3C XML protocol-working group. The ebXML initiative fromUN/CEFACT also has announced its support for SOAP.

In the core of the Web services model, SOAP is used as the messagingprotocol for transport with binding on top of various Internet protocolssuch as HTTP, SMTP, FTP, and so on. SOAP uses XML as the message for-mat, and it uses a set of encoding rules for representing data as messages.Although SOAP is used as a messaging protocol in Web services, it also canoperate on a request/response model by exposing the functionality usingSOAP/RPC based on remote procedural calls. SOAP also can be used withJ2EE-based application frameworks. For more information about SOAP, goto Chapter 4, Developing Web Services Using SOAP, or to the officialW3C Web site for SOAP at www.w3c.org/TR/SOAP/.

28 Chapter 2

Web Services Definition Language (WSDL)The Web Services Definition Language (WSDL) standard is an XML formatfor describing the network services and its access information. It defines abinding mechanism used to attach a protocol, data format, an abstractmessage, or set of endpoints defining the location of services.

In the core of the Web services model, WSDL is used as the metadatalanguage for defining Web services and describes how service providersand requesters communicate with one another. WSDL describes the Webservices functionalities offered by the service provider, where the service islocated, and how to access the service. Usually the service provider createsWeb services by generating WSDL from its exposed business applications.A public/private registry is utilized for storing and publishing the WSDL-based information. For more information about WSDL, go to Chapter 5,Description and Discovery of Web Services, or the official W3C Web sitefor WSDL at www.w3c.org/TR/wsdl/.

Universal Description, Discovery, and Integration (UDDI)Universal Description, Discovery, and Integration, or UDDI, defines thestandard interfaces and mechanisms for registries intended for publishingand storing descriptions of network services in terms of XML messages. Itis similar to the yellow pages or a telephone directory where businesseslist their products and services. Web services brokers use UDDI as a stan-dard for registering the Web service providers. By communicating withthe UDDI registries, the service requestors locate services and theninvoke them.

In the core Web services model, UDDI provides the registry for Webservices to function as a service broker enabling the service providers topopulate the registry with service descriptions and service types and theservice requestors to query the registry to find and locate the services. Itenables Web applications to interact with a UDDI-based registry usingSOAP messages. These registries can be either private services within anenterprise or a specific community, or they can be public registries to ser-vice the whole global business community of the Internet. The UDDIworking group includes leading technology vendors like Sun Microsys-tems, IBM, HP, SAP, Oracle, and Microsoft. For more information aboutUDDI, go to Chapter 5, Description and Discovery of Web Services, or tothe official Web site of UDDI at www.uddi.org/.

Introduction to Web Services 29

ebXMLebXML defines a global electronic marketplace where enterprises find oneanother and conduct business process collaborations and transactions. Italso defines a set of specifications for enterprises to conduct electronicbusiness over the Internet by establishing a common standard for businessprocess specifications, business information modeling, business processcollaborations, collaborative partnership profiles, and agreements andmessaging. ebXML is an initiative sponsored by the United Nations Centerfor Trade Facilitation and Electronic Business (UN/CEFACT) and theOrganization for the Advancement of Structured Information Standards(OASIS). Popular standards orga