John wiley sons developing java web services 2003

When a policy change in the accounting department dictates a soft-ware rewrite in the sales department, that’s brittleness.In seeking to eliminate brittleness, there have been three sign

TE AM

Team-Fly®

Architecting and Developing Secure

Web Services Using Java

Ramesh Nagappan Robert Skoczylas Rima Patel Sriganesh

Developing Java

Web Services

Architecting and Developing Secure

Web Services Using Java

Publisher: Robert Ipsen

Editor: Theresa Hudson

Developmental Editors: Scott Amerman and James Russell

Editorial Manager: Kathryn A Malm

Managing Editor: Angela Smith

Text 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 transmitted

in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment 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 their best efforts in preparing this book, they make no representations or warranties with respect

to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose No warranty may

be created or extended by sales representatives or written sales materials The advice and strategies contained herein may not be suitable for your situation You should consult with

a professional where appropriate Neither the publisher nor author shall be liable for any loss 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 Customer Care 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 appears

in 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 istered trademarks of Wiley Publishing, Inc., in the United States and other countries, and may not be used without written permission All other trademarks are the property of their respective owners Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.

reg-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

Part One Evolution and Emergence of Web Services 1

Summary 20

v

Other Industry Standards Supporting Web Services 31

Web Services Strategies from Industry Leaders: An Overview 36

Summary 38

Part Two Web Services Architecture and Technologies 39

Web Services Architecture and Its Core Building Blocks 42

Summary 101

Anatomy of a SOAP Message 107

SOAP Envelope 110 SOAP Header 111 SOAP Body 112 SOAP Fault 112 SOAP mustUnderstand 115 SOAP Attachments 116

SOAP Encoding 118

SOAP Intermediaries 126 SOAP Actor 127

SOAP Security 140

SOAP Encryption 140

SOAP Authorization 143

Summary 199

WSDL Bindings 211 WSDL Tools 214

Summary 269

Developing Microsoft NET Client for Web Services 276

Key Steps in Creating a Web Service Requestor

Challenges in Creating Web Services Interoperability 289

Summary 292

Part Three Exploring Java Web Services Developer Pack 293

Chapter 7 Introduction to the Java Web Services

Downloading the Web Services Pack 310Summary 311

XML Syntax 316 Namespaces 322

JAXP Implementations 342

Threading 383

Summary 399

javax.xml.messaging 407

Summary 450

Chapter 10 Building RPC Web Services with JAX-RPC 451

Summary 561

Designing the Service Requestor Environment (computerBuy.com) 575

Team-Fly®

Implementation 582

Summary 615

SAML Implementations 687 SAML Architecture 689

Conclusion 710Summary 711

Part Five Web Services Strategies and Solutions 713

Summary 731

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,” that’s brittleness When you can’t open your wordprocessor documents because the software version is wrong, that’s brittle-ness When a policy change in the accounting department dictates a soft-ware rewrite in the sales department, that’s brittleness.

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

■■ The first was the introduction of Java technology, which separated

software from the platform and allowed the creation of business logicthat wasn’t 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 enabled

different software systems to share data without being affected by

changes to the data structures unless they needed to respond to them

■■ The most recent is the introduction of Web services Web services

separate collaborating computer systems connected by networks,

enabling them to delegate processing without becoming coupled in

a brittle way

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 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 developer

ser-a comprehensive toolchest In the pser-ages thser-at 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 tant Web services vendors, including a variety of tools

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

■■ A discussion of the essentials of Web services security that

considers 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.

“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 infrastructures

to 24 × 7 online businesses running on different systems and locations As

a next evolutionary step, Web services are a new breed of Web-based 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

appli-This book is a developer’s guide for designing and developing Web 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 coverage

ser-of the Java Web Services Developer Pack (JWSDP) In addition, this bookalso addresses the fundamentals of Web services from the ground up

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 ture, Security Assertion Markup Language (SAML), XML Key Man-agement Services (XKMS), and XML Access Control Markup

Signa-Language (XACML)

■■ Interoperability with Microsoft NET

■■ The real-world implementation of Web services on JWSDP, using acase 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 ming knowledge of implementing Web applications using Java and XML

program-Organization of the Book

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

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 it

devotes 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 background

of distributed computing and the evolution of Internet-enabled

technologies is explored in the first chapter Here, we will examine

the definition and reasons for using distributed computing and thecore distributed computing technologies

Chapter 2, “Introduction to Web Services.”This chapter presents an

introduction to Web services, especially focusing on the definition

of Web services, the standards and technologies that the services

use, and the benefits of using these services

Part Two, “Web Services Architecture and Technologies.”This sectionwalks through the different Web services standards and technologies

such 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 to

expose enterprise applications to Web services It also demonstrates

an interoperability scenario with non-Java based Web services

Chapter 3, “Building the Web Services Architecture.”This chapter

focuses on the Web services architecture, its core building blocks,

implementation models, and deployment processes for building

Web services-based application solutions In addition, this chapter

illustrates, using an example, the development of a complete Web

services solution, exposing J2EE applications as services over the

Internet

Chapter 4, “Developing Web services using SOAP.”This chapter

provides an in-depth discussion on SOAP and its role in

develop-ing Web services It covers the W3C definition of SOAP’s

stan-dards, conventions, messages, communication models, and

implementation of SOAP-based applications for Web services In

addition, the chapter also includes example illustrations of

adopt-ing different SOAP communication models in Web services

Chapter 5, “Description and Discovery of Web Services.”This

chapter explains two important Web services specifications: WSDLand UDDI It provides a detailed explanation on the important

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 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

Devel-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 provides

a 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 also

includes example illustrations using JAX-RPC and demonstrates

the different client invocations

Chapter 11, “Java API for XML Registries.”This chapter provides

detailed 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 port, association support, connection management, life cycle

sup-management, and querying capabilities Also provided with this

chapter is the discussion on the various JAXR examples about

working with UDDI registries

Chapter 12, “Using theJava Web Services Developer Pack: Case

Study.”This chapter focuses on implementing a complete Web vices solution using the Java Web Services Developer Pack

ser-(JWSDP) 1.0 It puts together all of the JWSDP-based APIs covered

in 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 great

details on the issues revolving around Web services security, which

is followed by a discussion on each of the five major Web services

security technologies: XML Encryption, XML Signature, XML Key

Management Services (XKMS) , Security Assertions Markup

Lan-guage (SAML), and XML Access Control Markup LanLan-guage

(XACML) It also provides good examples of using tools for

secur-ing Web services through XML Encryption and XML Signature

technologies In addition, the chapter provides a hypothetical use

case 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 also

provides some brief information on the Sun ONE product stack,

including its tools and platform servers In addition, it also

intro-duces ebXML technologies

Companion Web Site

All the source code from the example illustrations found within this book

is 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 reader’s feedback You are 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

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 pletion of the project, and it’s a great feeling to see the quality of work theway we wanted

com-It’s 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 Harvard’s 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, whodidn’t 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 It’s always been

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 fiancée, Urszula Masalska, who put upwith this project for the last couple of months Without your patience andencouragement, I wouldn’t 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

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, who’d 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; and

my 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

Ramesh Nagappanis 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 worked

as 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 Skoczylasis an Enterprise Java Architect with the Sun Java Center

in Boston, MA He has many years of experience in Object-Oriented 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)

tech-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 onSun’s 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

Evolution and Emergence

of Web Services

The 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 As

a 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 Internet

by going through a series of technological innovations The key non of enabling business applications over the Internet is based on a fun-damental technology called distributed computing

phenome-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 Distributed

Computing

1

■■ The definition of distributed computing

■■ The importance of distributed computing

■■ Core distributed computing technologies such as the following:

■■ 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 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

consid-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 aspect

of 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 located

on different computers connected to a network” (www.webopedia.com,May 2001) Figure 1.1 shows a distributed computing model that provides

an infrastructure enabling invocations of object functions located anywhere

on the network The objects are transparent to the application and provideprocessing power as if they were local to the application calling them

Team-Fly®

Figure 1.1 Internet-based distributed computing model.

Today, Sun Java RMI (Remote Method Invocation), OMG CORBA 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

(Com-The Importance of Distributed Computing

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

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

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

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

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

distrib-Extensibility. This can be achieved through dynamic tion of applications that are distributed across the network

(re)configura-Higher productivity and lower development cycle time. By breaking

up 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

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 system

in which multiple desktop-based business client applications access a tral database server

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

■■ Complex business processing at the client side demands robust

client systems

■■ Security is more difficult to implement because the algorithms and

logic reside on the client side making it more vulnerable to hacking

■■ Increased network bandwidth is needed to accommodate many calls

to the server, which can impose scalability restrictions

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

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

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 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 can

pro-be written in any language that has mappings to a neutral interface tion called the Interface Definition Language (IDL) An IDL is a specificinterface language designed to expose the services (methods/functions) of

defini-a CORBA remote object CORBA defini-also defines defini-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 client’s 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 component’s interfaces,inherited classes, events, attributes, and exceptions can be specified

in a standard definition language supported by the CORBA ORB

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 the

client and server It establishes the foundation for the distributed

application objects, achieving interoperability in a heterogeneous

environment

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

OS and programming-language independence. Interfaces between

clients and servers are defined in OMG IDL, thus providing the

fol-lowing advantages to Internet programming: Multi-language and

multi-platform application environments, which provide a logical

separation between interfaces and implementation

Legacy and custom application integration. Using CORBA IDL,

developers can encapsulate existing and custom applications as

callable client applications and use them as objects on the ORB

Rich distributed object infrastructure. CORBA offers developers a

rich set of distributed object services, such as the Lifecycle, Events,

Naming, Transactions, and Security services

Location transparency. CORBA provides location transparency: An

object reference is independent of the physical location and

applica-tion level locaapplica-tion This allows developers to create CORBA-based

systems where objects can be moved without modifying the ing applications

underly-CORBA - ORB (Object Bus)

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

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

asynchro-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 oriented CORBA architecture, very high scalability expected inenterprise applications may not be achieved

connection-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 mechanism

to 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 serialization—a 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,

they were not intended to support or solve the distributed computing 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 another’s meth-ods Because these VMs can be running on different computers anywhere

chal-on 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 tion solution

applica-Figure 1.4 A Java RMI architectural model.

Java

Client

RMI Stubs

Remote Ref Layer

Java RMI Server

RMI Skeleton

Remote Ref Layer

JRMP

The Java RMI architecture is composed of the following components:

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

stand-RMI stub. The RMI stub is the client proxy generated by the rmi

compiler (rmic provided along with Java developer kit—JDK) that

encapsulates 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 with

an 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

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 of

the connection-oriented nature Hence, achieving high scalability in

such an application model becomes a challenge

■■ RMI does not provide any specific session management support In

a typical client/server implementation, the server has to maintain

the session and state information of the multiple clients who access

it Maintaining such information within the server application out a standard support is a complex task

with-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 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