Building Web
Services with Java
Sams Publishing, 800 East 96th Street, Indianapolis, Indiana 46240
DEVELOPER’S LIBRARY
M A K I N G S E N S E O F X M L , S O A P , W S D L , A N D U D D I
Steve Graham Doug Davis Simeon Simeonov
Glen Daniels Peter Brittenham Yuichi Nakamura Paul Fremantle
Dieter König Claudia Zentner
Second Edition
Second Edition
Copyright © 2005 by Sams Publishing
All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omis- sions. Nor is any liability assumed for damages resulting from the use of the information contained herein.
International Standard Book Number: 0-672-32641-8 Library of Congress Catalog Card Number: 2004091343 Printed in the United States of America
First Printing: July 2004
07 06 05 04 4 3 2 1
Trademarks
All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Sams
Publishing cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.
Warning and Disclaimer
Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied.The infor- mation provided is on an “as is” basis.The author and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the CD or programs accompanying it.
Bulk Sales
Sams Publishing offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information, please contact
U.S. Corporate and Government Sales 1-800-382-3419
corpsales@pearsontechgroup.com For sales outside of the U.S., please contact International Sales
1-317-428-3341
international@pearsontechgroup.com
Acquisitions Editor Todd Green
Development Editor Tiffany Taylor Managing Editor Charlotte Clapp Senior Project Editor Matthew Purcell Indexer Larry Sweazy Proofreader Eileen Dennie Technical Editors Alan Moffet Alan Wexelblat Marc Goldford Kunal Mittal
Publishing Coordinator Cindy Teeters
Designer Gary Adair
Contents at a Glance
Introduction 1
I Web Services Basics
1 Web Services Overview and Service-Oriented Architectures 9
2 XML Primer 31
3 The SOAP Protocol 111 4 Describing Web Services 167
5 Implementing Web Services with Apache Axis 233 6 Discovering Web Services 307
II Enterprise Web Services
7 Web Services and J2EE 3478 Web Services and Stateful Resources 383 9 Securing Web Services 445
10 Web Services Reliable Messaging 507 11 Web Services Transactions 525 12 Orchestrating Web Services 549
III Web Services in the Real World
13 Web Services Interoperability 609 14 Web Services Pragmatics 673 15 Epilogue:Web Services Futures 717Appendix
A Glossary 731Index 755
Introduction 1
I Web Services Basics
1 Web Services Overview and Service- Oriented Architectures 9
What Is a Web Service? 10 Business Perspective 11 Technical Perspective 12 Service-Oriented Architectures 13
Why Is SOA So Important? 15
SOA and Web Services: Related but Distinct 17 Trends in E-Business 17
Why Do We Need Web Services? 18 Scoping the Problem 18 Core Technologies 19 Industry Dynamics 20
What Makes a Good Web Service? 21 The Web Service Opportunity 22
Application Integration 22 B2B 24
Integration of Human Interaction with Systems:
B2C 24
Justifying Web Services 25
Web Services Interoperability Stack 26 Transport Layer 27
Messaging Layer 28 Description Layer 28
Quality of Experience Layer 29 Compositional Layer 29
Understanding the Web Services Interoperability Stack 29
Summary 30
v Contents
2 XML Primer 31
Document- Versus Data-Centric XML 32 Document-Centric XML 32 Data-Centric XML 33 Document Lifetime 34 XML Instances 35
Document Prolog 35 Elements 36
Attributes 38 Character Data 42
A Simpler Purchase Order 44 XML Namespaces 44
Namespace Mechanism 46 Namespace Syntax 47
Namespace-Prefixed Attributes 49 XML Schemas 51
Well-Formedness and Validity 51 XML Schema Basics 52
Associating Schemas with Documents 54 Simple Types 55
Complex types 59
The Purchase Order Schema 62
Global Versus Local Elements and Attributes 63 Basic Schema Reusability 64
Advanced Schema Reusability 70 There’s More 78
Processing XML 78 Basic Operations 78
Data-Oriented XML Processing 81 SAX-BasedcheckInvoice() 85 DOM-BasedcheckInvoice() 91 JAXB-BasedcheckInvoice() 96 Testing the Code 105
Summary 107 Resources 109
3 The SOAP Protocol 111
Simple Object Access Protocol (SOAP) 112 What Is SOAP, Really? 113
Doing Business with SkatesTown 114 Inventory Check Web Service 117
Choosing a Web Service Engine 117 Service Provider View 117
Deploying the Service 118 The Client View 118 A Closer Look at SOAP 120
The Structure of the Spec 120 The SOAP Messaging Framework 121
Vertical Extensibility 123 ThemustUnderstandFlag 125 SOAP Modules 126
SOAP Intermediaries 126
The Need for Intermediaries 127
Transparent and Explicit Intermediaries 128 Intermediaries in SOAP 129
Forwarding and Active Intermediaries 130 Rules for Intermediaries and Headers 130 The SOAP Body 132
The SOAP Processing Model 132 Versioning in SOAP 133
Processing Headers and Bodies 134 Faults: Error Handling in SOAP 134
Structure of a Fault 135 Using Headers in Faults 138
Objects in XML:The SOAP Data Model 141 Object Graphs 141
The SOAP Encoding 143 The SOAP RPC Conventions 148
outandinoutParameters 149
XML, Straight Up: Document-Style SOAP 151 When to Use Which Style 151
vii Contents
The Transport Binding Framework 152 Features and Properties 153 The HTTP Binding 157 TheSOAPActionFeature 158 The Web Method Feature 159 Using SOAP to Send Binary Data 160
SOAP with Attachments and DIME 160 PASWA, MTOM, and XOP 162 Small-Scale SOAP, Big-Time SOAP 163 Summary 165
Resources 165
4 Describing Web Services 167 Why Service Descriptions? 167
Role of Service Description in a Service-Oriented Architecture 168
Well-Defined Service 169 Functional Description 169 Nonfunctional Description 170 Description Summary 170
History of Interface Definition Languages (IDLs) 171 Web Services Description Language (WSDL) 173
WSDL Information Model 174 Parts of the WSDL Language 176 Structure of a WSDL Document:
Definitions 178 PortType 179 Operation 180 Message 180 Part 181 Types 184 Binding 186 Port 190 Service 191 Documentation 192 Import 192
Exploring More WSDL Features 195
Transmission Primitives 201
Rounding Out WSDL Bindings 205 WSDL Extension Mechanism 210 A Sketch of How WSDL Maps to Java 213 Nonfunctional Descriptions in WSDL 214
Policies 214 WS-Policy 216 Policy Assertions 220 Policy Attachments 220
Standardizing WSDL:W3C and WSDL 2.0 223 What’s New in WSDL 2.0 223
Overview of WSDL 2.0 224
A Complete WSDL 2.0 Description 229 Summary 230
Resources 231
5 Implementing Web Services with Apache Axis 233
A Brief History of Axis 234
JAX-RPC, JAXM/SAAJ, and JAXB 234 Current State of the Project 235 Axis Architecture 236
Handlers and Chains: Concepts 236 Server-Side Message Processing 238 Client-Side Message Processing 240
TheMessageContextand Its Many Uses 242 The Message APIs and SAAJ 243
A Message by Any Other Name 244 Accessing the SOAP Envelope, Bodies, and Headers 244
The Axis Client APIs 246 TheServiceObject 246
Using the CallObject for Dynamic Invocation 247
Using Stubs and WSDL2Java 253 Holders: Mapping inout/outParameters to Java 256
ix Contents
Web Service Deployment Descriptor (WSDD) 258 Handler Declarations 259
Chain Definitions 260 Transports 261 Type Mappings 262 Building Services 263
Instant Deployment: JWS 263 WSDD for Services 264
Deploying Services and the AdminClient 267 Getting at the MessageContext 268
Service Lifecycle and Scopes 270 Sessions on the Server Side 272
Using WSDL2Java to Generate Services 272 Generating WSDL for Your Services 273 A Guide to Web Service Styles 275
RPC Style 275 Wrapped Style 276 Document Style 277 Message Style 278
From XML to Java and Back Again:The Axis Type- Mapping System 279
Registering Mappings 279 Default Type Mappings 281
Default Type Mapping and XML/Java Naming 283
Custom Serializers and Deserializers 284 Using the MessageElement
XML/Object APIs 286
When Things Go Wrong: Faults and Exceptions 288 TheAxisFaultClass 288
Using Typed Exceptions 289 Axis as an Intermediary 291
Reasons for Roles 291 How to Write a Handler 292
The SkatesTown EmailHandler 292 The SkatesTown GlobalHandler 295
Built-in Security 297
Using the Authentication/Authorization Handlers 297
Understanding Axis Transports 298 ClientTransports 298 Server Transports 299
Transports Included with Axis 299 CustomTransports 300
No API Is an Island: Axis and Its Environment 300 Commons-Discovery and Obtaining
Resources 300
Logging Infrastructure 300 Security Providers 301 Compilers 301
Development/Debugging Tools 301 The happyAxis Page 301 Configuring Logging 301
UsingtcpmonandSOAPMonitor 303 Axis Futures: A Quick Tour 304
Participating in the Axis Community 305 Summary 305
Resources 306
6 Discovering Web Services 307 What Is Service Discovery? 307
Role of Service Discovery in a Service-Oriented Architecture 307
Service Discovery Mechanisms 308 Service Discovery at Design Time and Runtime 309
Scenario Updates 310
UDDI (Universal Description, Discovery, and Integration) 310
UDDI Datatypes 311 Using a UDDI Registry 325
What’s New in UDDI Version 3.0 335 Using WSDL with UDDI 337
xi Contents
Other Service Discovery Methods 343 WS-Inspection 343
WS-ServiceGroup 343 Summary 344
Resources 344
II Enterprise Web Services
7 Web Services and J2EE 347J2EE Overview 347 Containers 348
Enterprise JavaBeans 348
Roles: Development, Assembly, and Deployment 350
Benefits of Using Web Services with J2EE 351 J2EE Versions 353
Using EJBs from Axis 354 The Entity Bean 355 The Session Bean 358 The Deployment Unit 360 Exposing the EJBs via Axis 361 WebSphere Deployment Process 363 EJB Deployment 363
Configuring Axis to Invoke the SkatesService Session Bean 367 EJB Wrap-Up 375
Using JSR109: Implementing Enterprise Web Services 375
Step 1: Creating the WSDL File 376 Step 2: Creating the Deployment Descriptors 376
Step 3: Assembling the Application Files 378 Step 4: Enabling the EAR File for Web Services 379
Step 5: Deploying the Application 379 JSR109 Client Code 380
JSR109 Wrap-Up 381
Summary 381 Resources 381 8 Web Services and
Stateful Resources 383 Web Services and State 384 Aspects of State 384 SkatesTown Scenario 385 WS-Resources 385
Stateful Resources 387
Cardinality of Web Services and WS-Resources 387
Role of WS-Addressing 388 Implied Resource Pattern 391 Modeling Resource Properties 395
What Is a Resource Property? 395 WS-Resource Factory 399 Resource Property Operations 399 Rounding Out the POPortType 412 Using Notifications 412
Base Notification Concepts and Roles 413 Subscribing for Notification 415
The Subscription WS-Resource 419 Topics and Topic Spaces 420 Resource Properties of a Notification Producer 428
The Other Notification Producer Operation:
GetCurrentMessage 429
Notification of Value Changes on Resource Properties 430
Notification Consumers 432 Notification Brokers 433 Resource Lifetime 434
Immediate Termination 435 Scheduled Termination 436 Initializing Termination Time 439
Notification of WS-Resource Termination 440
xiii Contents
Other WS-Resource Framework Specifications 441 WS-RenewableReferences 442
WS-ServiceGroup 442 WS-BaseFaults 442 Summary 443
9 Securing Web Services 445 Example Scenario 445
Security Basics 446
Security Requirements 446 Cryptography 447
Authentication 450 Security Protocols 451 Security Infrastructures 452 Security Domains 455 Web Services Security 456
Security Model for Web Services 456 Web Services Security Specifications 458 Extended SkatesTown Security Scenario 459 WS-Security 461
Digital Signatures 462 Encryption 466 Security Tokens 471 WS-Trust 474
Public Key Infrastructure 474 Kerberos 476
XML Key Management Specification 479 WS-SecurityPolicy 481
WS-SecureConversation 482
WS-SecureConversation Overview 483 The SSL Protocol 486
Negotiation Protocol Example 487 WS-Federation 492
Enterprise Security 495 J2EE Security 495
Authorization in J2EE 496
J2EE and Web Services Security 498
Security Services 500 Summary 502 Resources 502
10 Web Services Reliable Messaging 507 Background of the Web Services Reliable Messaging Protocol (WS-RM) 507
The WS-RM Specification 509 WS-RM Processing Model 510
Client-Side Processing 511 Server-Side Processing 513 Sequence Faults 517
Policy Assertions 518
SpecVersion Assertion 519 DeliveryAssurancePolicy 519 SequenceExpirationPolicy 519 InactivityTimeoutAssertion 520 BaseRetransmissionInterval Assertion 520
AcknowledgementIntervalAssertion 520 SequenceRefElement 520
Flaws and Other Thoughts on the WS-RM Spec 521 Putting WS-RM into Use 521
Summary 523 Resources 523
11 Web Services Transactions 525 Web Services Coordination and Transaction (WS-C/Tx) 525
Transactions: A Brief Introduction 527 WS-Coordination 529
TheCoordinationContext 530 TheCreateCoordinationContext Operation 530
TheRegisterOperation 532 WS-Coordination Fault Codes 536 WS-Transaction: Atomic Transactions 536
WS-AT Operations 537 Commit and Rollback 537
xv Contents
AT Protocols 538
Two-Phase Commit Protocols 538 Committing the Transaction 539 Transaction Flow Overview 543 Business Activity Protocol 544 Reliable Delivery and Security 545 Summary 546
Resources 547
12 Orchestrating Web Services 549 Why Are We Composing Web Services? 549
Two-Level Programming Model 550 Stateless and Stateful Web Services 550 Evolution of Business Process Languages 550 SkatesTown Requirements 551
Business Process Execution Language for Web Services 552
Design Goals 553
External Interface of a Process 554 Overall Structure of a Process 558 Basic and Structured Activities 561
Process Lifecycle and Related Activities 562 Partner Links 563
Properties and Correlation Sets 565 Invoking Web Services and Providing Web Services 568
Data Handling and Related Activities 572 More Basic Activities:wait,empty 575 Flows 576
More Structured Activities:sequence,while, switch,scope 580
Fault Handling 582
Compensation Handling 585 Event Handling 587
SkatesTown: Putting It All Together 588
Advanced Considerations 601 Abstract Processes 601 Language Extensibility 604 Summary 604
Resources 605
III Web Services in the Real World
13 Web Services Interoperability 609Web Services Interoperability Organization 610 WS-I Basic Profile 1.0 611
Common Requirements for SOAP Envelope, WSDL Document, and XML Schema Document 619
Understanding the WSDL Document Structure 620
Importing XML Schema and WSDL Documents 622
Defining the Service Interface 623 Defining a SOAP Binding 626 Publishing a Service Description 637 HTTP and SOAP Message Content 638 Web Service Security 641
WS-I Conformance Claims 641 Service Provider, Requestor, and Registry Requirements 643
Summary of Basic Profile 1.0 Requirements 645
Future WS-I Profiles 648 Basic Profile 1.1 648
Simple SOAP Binding Profile 1.0 649 Attachments Profile 1.0 650
Basic Security Profile 1.0 660 WS-I Sample Applications 661 WS-I Test Tools 663
Monitor Overview 663
Monitor Configuration File 665
xvii Contents
Message Log File 665 Analyzer Overview 667
Analyzer Configuration File 667 Test Assertion Document 668 Profile Configuration Report 668 Summary 671
Resources 672
14 Web Services Pragmatics 673 Enterprise Adoption of Web Services 674
Time-Based Adoption Challenges 676 Inherent Limitations of SOA 677 Top-Down Versus Bottom-Up 679 Policies and Processes 682
Putting Web Services in Production 683 Web Services Technology Map 685 System Architectures for Web Services 691 Features, Capabilities, and Approaches 696
Tools and Platforms 696 SOA Testing 697
Deployment and Provisioning 699 Business Process Automation Using Web Services 700
Operations 708 Summary 715 Resources 715
15 Epilogue: Web Services Futures 717 A Roadmap for Web Services 717
Age of Invention (Base SOAP,WSDL, UDDI) 717
Age of Development (from Hype to Delivery) 718
Age of Mainstream Acceptance (Web Services Become Boring) 719
Future Trends in Web Services 720 Short-Term Trends and Issues 720 Medium-Term Trends 723 Longer-Term Trends 727 Summary 729
A Glossary 731 Index 755
About the Authors
Steve Graham is a Senior Technical Staff Member in IBM’s Systems Group and a member of the IBM Academy of Technology. Steve is an architect in the On Demand Architecture group. He has spent the last several years working on service-oriented architectures as part of IBM’s Web Services Initiative and IBM’s On Demand Initiative.
Most recently, Steve has applied service-oriented concepts to problems in Grid comput- ing as part of the Open Grid Services Architecture work in the Global Grid Forum.
Prior to this, Steve worked as a technologist and consultant with various emerging tech- nologies such as Java and XML, and before that he was an architect and consultant with the IBM Smalltalk consulting organization. Before joining IBM, Steve was a developer with Sybase, a consultant, and a faculty member in the Department of Computer Science at the University of Waterloo. Steve holds a BMath and MMath in computer science from the University of Waterloo and an MBA from the Kenan Flagler Business School at University of North Carolina, Chapel Hill.
Doug Davisworks as an architect in the Emerging Technology organization of IBM.
Previous activities include being the technical lead of IBM’s Emerging
Technologies/Web Services Toolkit, being one of IBM’s representatives in the W3C XML Protocol working group, and working on WebSphere’s Machine Translation proj- ect,TeamConnection, and IBM’s FORTRAN 90 compiler. Doug has a bachelor of sci- ence degree from the University of California at Davis and a master’s degree in comput- er science from Michigan State University.
Simeon Simeonovis a Principal at Polaris Venture Partners in Boston, where he helps early-stage IT companies accelerate their growth. Prior to joining Polaris, Sim was Vice President of Emerging Technologies and Chief Architect at Macromedia. Earlier, Sim was a founding member and Chief Architect at Allaire. Sim has played a key role in eight v1.0 product initiatives. His innovation and leadership have brought about category- defining products with significant market impact: the first Web application server (Allaire ColdFusion), the best open-source Web services engine (Apache Axis) and the first rich Internet application platform (Macromedia Flash/Flex). Sim has been working with XML and precursors to Web services since 1997 and has developed standards in this space at W3C, JCP, and OASIS. Sim has a master’s degree in computer science from Boston University and bachelor’s degrees in computer science, economics, and mathe- matics from Macalester College.
Glen Daniels is the Standards Strategist for Sonic Software, creator of the first
Enterprise Service Bus. Glen bridges the gap between Sonic’s development organization and the evolving world of standards. He is one of the primary designers and developers for the Apache Axis project, is a member of the Apache Software Foundation, and partic- ipates actively in organizations like the W3C, OASIS, and the JCP. Prior to Sonic, he was a principal software engineer at Macromedia and Allaire, where he architected new ini- tiatives and helped to bring the company into the Web services era.When not at stan- dards meetings or writing code, he enjoys playing music, cooking, and spending time with his friends, his family, and his two amazing cats.
concepts to IBM’s Autonomic Computing initiative. Prior to this, he was the lead archi- tect for the IBM Web Services Toolkit, which provided a preview of emerging Web serv- ice technologies. Peter also was one of the IBM representatives to the Web Services Interoperability (WS-I) organization. In this role, he was responsible for the architecture and overall development of the first release of the Java version of the WS-I Test Tools.
Peter has a BS in business administration from Boston University and an MS in comput- er science from Marist College.
Yuichi Nakamura leads the XML & Security group at the IBM Tokyo Research Laboratory. He joined IBM in 1990 and has worked in several areas such as object- oriented systems, multi-agent systems, B2B e-commerce, and knowledge engineering.
Since 1999 he has been working on Web services, addressing security, caching, and per- formance.Yuichi contributed to the Apache Axis project during its start-up phase, and he has been contributing to the development of security and cache components for IBM’s WebSphere Application Server. He received an MSc and a PhD in applied physics from Osaka University.
Paul Fremantleis a Senior Technical Staff Member in IBM’s Software division, based in the Hursley Park laboratory near Winchester in England. Paul works on IBM’s
Enterprise Service Bus initiative and other Web services activities in the WebSphere product. Paul has been working on Web services and XML at IBM since 1999, when he wrote early XML utilities for IBM’s alphaWorks website. Since then he has co-authored The XML Files, an IBM redbook, as well as a number of articles on J2EE and Web serv- ices both in print and on the Web. Paul’s involvement on the WebSphere Application Server includes architectural responsibility for the first SOAP support, the Web Services Invocation Framework, and the Web Services Gateway. Paul is the co-lead of the JWSDL standard in the Java Community Process and has initiated two open-source projects. Paul has an MSc in computation and an MA in mathematics and philosophy, both from Balliol College, Oxford.
Dieter Königis a software architect for workflow systems at the IBM Germany Development Laboratory. He joined the laboratory in 1988 and has worked on Resource Measurement Facility for z/OS, MQSeries Workflow, and WebSphere Process Choreographer. Dieter is a member of the OASIS WS-BPEL Technical Committee, which is working toward an industry standard based on the Business Process Execution Language for Web Services (BPEL4WS) specification. He holds a master’s degree (Dipl.inform.) in computer science from the University of Bonn, Germany.
Claudia Zentneris an architect working for IBM’s Software Group at the IBM Development Laboratory in Böblingen, Germany. Since joining IBM in 1989, she has worked on various middleware projects. For many years Claudia has been focusing on workflow, starting with FlowMark and MQSeries Workflow; currently she is an architect for the process choreography component of the WebSphere Business Integration offer- ing. Claudia graduated in computer science from the University of Cooperative Education in Stuttgart, Germany.
Acknowledgments
Steve Graham
Once again, to Karen, Erin, and Jessie, my family, my inspiration. For all the moments sacrificed to create this book, my most heartfelt thanks for your understanding. My thanks to my co-workers at IBM for providing an excellent environment for creative work.
My thanks also to the staff at Sams, particularly Tiffany Taylor and Michael Stephens, for the hard work that went into making this project a reality.
Romans 12:2.
Doug Davis
Thanks to my parents, family, and friends, without whose support and guidance none of the joys in my life would be possible. Lin—thanks to your never-ending patience and understanding, we managed to make it through another one! Sorry for forcing you to learn far more about Web services than you ever feared. :-)
Sim Simeonov
As always, my deepest thanks to Pyrra: my true love and a constant source of inspiration.
Second editions are not easy when the topic of writing is changing as fast as Web servic- es are evolving.Thanks go to all that helped me keep my finger on the pulse of the industry, notably, the good people working with Web services at Service Integrity, WebLayers, Orbitz, Amazon.com, eBay, CA, BMC, IBM, BEA, Microsoft, ZapThink, Burton Group, AT&T, GE, Ford, Bank of America,Wachovia, Fidelity, Morgan Stanley, Merck, and Web Services Journal.
Many thanks to Tiffany,Todd, and Mike at Sams for supporting us all the way!
Glen Daniels
I would like to thank my friends and family (not to mention the rest of the authoring team) for putting up with my overloaded schedule, and everyone at Sams for their great work pulling the book together. Also thanks to all the readers of the first edition who’ve made great comments and suggestions—we hope you like the new one!
Peter Brittenham
To my wife Abby, and my children Josh, Greg, and Jessica, thank you for your continued patience and support.
Yuichi Nakamura
To my wife Michiyo, my daughter Arisa, and my son Ryotaro.Thank you for your sup- port and patience. My thanks to my colleagues at IBM for providing this great environ- ment to work on Web services.
My thanks also to the staff at Sams,Tiffany,Todd, and Mike. Particularly, I thank Tiffany for her English editing on my chapter.
dren Anna and Dan for keeping me sane and driving me crazy.Thanks to my colleagues, especially Sanjiva Weerawarana,Tony Storey, Beth Hutchison, and Chris Sharp, for mak- ing my working environment challenging and fun, and to John Carter for being a great manager while I wrote this book. Finally, thanks to Tiffany,Todd, and Mike at Sams for all their hard work, and to Steve for all his encouragement to us all.
Dieter König
To my wife Rita and my sons Daniel, Sebastian, Maximilian, and Jonas.Thank you for your patience and support during this adventure.
Claudia Zentner
To Anneliese, Christian, Marion, and all my friends, thanks for your support and patience.
We Want to Hear from You!
As the reader of this book, you are our most important critic and commentator.We value your opinion and want to know what we’re doing right, what we could do better, what areas you’d like to see us publish in, and any other words of wisdom you’re willing to pass our way.
As an associate publisher for Sams Publishing, I welcome your comments.You can email or write me directly to let me know what you did or didn’t like about this book—as well as what we can do to make our books better.
Please note that I cannot help you with technical problems related to the topic of this book.We do have a User Services group, however, where I will forward specific technical questions related to the book.
When you write, please be sure to include this book’s title and author as well as your name, email address, and phone number. I will carefully review your comments and share them with the author and editors who worked on the book.
Email: feedback@samspublishing.com
Mail: Michael Stephens
Associate Publisher Sams Publishing 800 East 96th Street
Indianapolis, IN 46240 USA
For more information about this book or another Sams Publishing title, visit our Web site at www.samspublishing.com.Type the ISBN (excluding hyphens) or the title of a book in the Search field to find the page you’re looking for.
Introduction
W
ELCOME TO THE WORLD OFWEB SERVICES! Web services is an evolving collection of standards, specifications, and implementation technologies that are showing great value in the world of application integration and distributed computing.Web services continue to evolve to address more sophisticated computing scenarios, and the authors of this book are excited to bring you into what is widely believed to be the next generation of distributed computing.Before we get going, we need to clarify some things about the purpose and structure of the book. Let’s talk about them now.
Goals of This Book
The overall goal of this book is to familiarize you with the concept of Web services and what it will take to incorporate Web services as part of your business.We’ll introduce the concept of Web services and give you a framework that describes how you can under- stand the various standards associated with Web services, such as Simple Object Access Protocol (SOAP),Web Services Description Language (WSDL), and Universal
Description Discovery and Integration (UDDI).We’ll help position Web services from a business and technical perspective, explaining and demonstrating how Web services can be used to address various business problems.
Another goal of this book is to help developers understand the issues and details relat- ed to building Web services using the techniques covered by this book.What pieces are required when you’re planning a Web services strategy? What things do you need to take care of when you’re developing Web services? We provide lots of examples to demon- strate these approaches.We also review in detail the Apache Axis Web services infrastruc- ture with our examples.
Assumed Background
This book is meant for computing technical professionals with some experience building Web applications and distributed computing systems.You don’t need to be a seasoned veteran of the distributed object wars to appreciate this book, but some familiarity with Web-based architectures and techniques such as HTTP and HTML is assumed. If you don’t have any experience with these techniques, some of the material could be a little confusing—particularly some of the code examples—but you should still be able to get a lot out of the book.
We assume you’re familiar with Java, in particular the Java servlet technology.We also briefly discuss the relationship between Enterprise JavaBeans (EJBs) and Web services, so some familiarity with EJBs is helpful as well. If you need to supplement your under- standing of these techniques, many good books on programming with Java, JSP, servlets, and EJBs are available on the market.
You’ll also discover that the Extensible Markup Language (XML) is at the core of all things dealing with Web service. Although we devote an entire chapter to explaining the core pieces of XML needed to build Web services, the more understanding of XML you have, the more successful you’ll be in building Web services.
Philosophy
The concepts and standards involved in Web services are very much interdependent. It’s difficult to cover each topic in isolation, because it’s the combination of these concepts and standards that makes Web services important to distributed computing.
The philosophy of this book can be summarized by four points: pragmatics, progres- sive disclosure, a continuous example, and a service-oriented architecture framework.
Pragmatics
In this book, we try to get to programming examples and running code as quickly as possible. In particular, we focus on building and consuming SOAP-based Web services using the Java-based Apache Axis Web services infrastructure.Whereas we emphasize that Web services are fundamentally programming language neutral, ultimately, any given Web service is implemented in some programming language technology. In the case of this book, we’ve chosen Java—probably not a surprise to you, given our title.Where issues of interoperability with Web services written in other programming languages appear, we note them. Detailed coverage of other Web services implementation approaches, such as Microsoft’s .NET, is beyond the scope of this book.
Progressive Disclosure
After an overview of Web services, we start with the fundamentals of XML and then layer on new concepts, motivated by a business computing problem.These layers produce a series of Web services technology stacks. For each of the technologies and standards in the Web services arena, we focus on explaining the technology from the perspective of the problems it solves, balancing the explanation of the technology itself.
Business Example
The technologies and standards that make up the Web services concept are each exam- ined in the context of an example (which we discuss later in this introduction).The use of the example adds insight to the explanation of Web services in the text of the book and supports the progressive disclosure approach as we follow the example, adding the
3 Introduction
layers of Web services technology to the solution.This technique helps position various best-practices approaches to Web service development and deployment.You can down- load the source code for these running examples from www.samspublishing.com.When you reach that page, enter this book’s ISBN number (0672326418) in the search box to access information about the book and a Downloads link.
Service-Oriented Architecture
The examples and Web services concepts are discussed in the context of Service- Oriented Architecture (SOA), which we introduce in Chapter 1, “Web Services Overview and Service-Oriented Architectures.”We use the SOA framework to help position the various Web services concepts in the context of a bigger picture.
Overview of the Book’s Composition
This book is divided into three major parts: “Web Services Basics,” “Enterprise Web Services,” and “Web Services in the Real World.” Chapters 1 through 6 describe the core concepts of Web services; you need to have a thorough understanding of this subject matter to be successful with any Web services development project. Chapters 7 through 12 are organized around Web services topics that have an enterprise computing focus.
The topics discussed in this section address technical subjects that usually crop up when you’re building “real” information technology solutions.The last part of the book, Chapters 13 through 15, deals with development pragmatics that we’ve gleaned from real-world experience with Web services. Let’s take a closer look at the topics in each of the chapters.
Chapter 1 begins the book with an explanation of what the Web services approach is all about.We describe what a Web service is, what standards and technologies are associ- ated with Web services, and what problems can be solved using Web services.We use this chapter to introduce the Service-Oriented Architecture (SOA) conceptual framework and begin to explain how the various Web services standards such as SOAP,WSDL, and UDDI fit together.This chapter will give you a solid conceptual basis for the rest of the book.
Before we can get into the core Web services standards, we take a brief side trip to explain XML in Chapter 2, “XML Primer.” Because XML is at the heart of all the Web services standards and techniques, it’s important for you understand it well. XML is a huge topic, but we focus our examination of XML on what you’ll need to know in order to understand the rest of the Web services topics.
After the review of XML, Chapter 3, “The SOAP Protocol,” dives in to the core mechanism of invoking a Web service.We review the topic of XML messaging in a dis- tributed computing environment, focusing on the SOAP messaging standard from the W3C. SOAP forms the core basis of communication between a service requestor and a service provider in a Web services environment, and it’s the foundation on which you can build the kinds of business-level extensions we’ll discuss later in the book.
Chapter 4, “Describing Web Services,” introduces the important notion of service description, which is key to making Web services a great application integration technol- ogy for building loosely coupled systems.This chapter discusses how Web services use service description to address the problem of communicating the details the service requestor needs to know about the Web service in order to properly understand how (and why) to invoke it.
Chapter 5, “Implementing Web Services with Apache Axis,” refines your understand- ing of SOAP in the context of a particular SOAP infrastructure: the Apache Axis project.
This chapter dives into the details of how Axis works and how you can use it to both consume Web services and deploy your own.
Now, you need to understand how the service requestor got the service description in the first place. Chapter 6, “Discovering Web Services,” picks up where Chapter 4 left off, discussing the various techniques for Web service discovery, such as UDDI.This chapter examines the standards related to finding what Web services are provided by businesses with which a company might want to collaborate.
Chapter 7, “Web Services and J2EE,” adds detail to the core concepts introduced in Chapters 1 through 6.This chapter explains how the Web services concepts map to Java 2 Enterprise Edition (J2EE). Chapter 7 explains how to build Web services using Axis and using the JSR109 Java standard.
In Chapter 8, “Web Services and Stateful Resources,” we review how the notion of stateful resources can be combined with Web services, by introducing the concepts of WS-Addressing, a referencing or pointer mechanism in Web services;WS-Resource Framework, a specification for associating Web services with stateful resources; and WS- Notification, a mechanism for doing publish-subscribe style of asynchronous messaging.
This work is an emerging standard for use in Grid computing and systems management as well as e-business computing. (For more information on Grid computing, we recom- mend that you browse www.globalgridforum.org.)
The very important issue of Web services security is discussed in Chapter 9, “Securing Web Services.”This chapter reviews existing security technologies and takes a closer look at the mapping from Web services security to those technologies.This chapter also reviews how Web services security technologies are integrated into enterprise applica- tions using the J2EE model.
In many applications, it’s critical to verify whether a message is sent or received by another party. Chapter 10, “Web Services Reliable Messaging,” explores a Web services specification that was written to try to overcome certain problems with Web services by adding a reliability aspect to SOAP.
Chapter 11, “Web Services Transactions,” examines how Web services deal with trans- actions. In an enterprise setting, it’s likely that Web services will need to be invoked and coordinated under the scope of a single unit of work. In this chapter, we examine a group of specifications that describe how to do this with Web services.
Web services allow designers to build applications that more closely resemble the business processes they automate. Chapter 12, “Orchestrating Web Services,” describes how to build Web services by coordinating or orchestrating simpler Web services into a
5 Introduction
business process (which is also a Web service).This chapter introduces the Business Process Execution Language for Web Services (BPEL4WS) specification.
Chapter 13, “Web Services Interoperability,” explores the Do’s and Don’ts of building Web services that interoperate with other Web services.The Web Service Interoperability (WS-I) Organization has developed a series of guidelines that help developers use the Web services specifications in a consistent way across vendors.This chapter examines the work of this organization.
Chapter 14, “Web Services Pragmatics,” deals with a list of issues that you may encounter when you’re building and deploying Web services in the real world.
Chapter 15 provides a forward-looking epilogue, “Web Services Futures,” which spec- ulates on some possible future uses of Web services technologies.
Note
This book introduces quite a few terms with which you might not be familiar. We’ve included a glossary at the back of the book that acts as a great reference guide to the terminology we use. We’ll annotate the first use of each term appearing in the glossary using the
g
symbol.Introducing SkatesTown
Before we get started, let’s introduce the fictional company we’ll use for our examples throughout this book: SkatesTown.We’ll follow SkatesTown as the company exploits Web services to improve its business.
SkatesTown is a small but growing business in New York that was founded by three mechanically inclined friends with a passion for skateboards.They started by designing and selling custom prebuilt boards out of Dean Carroll’s garage, and word soon spread about the quality of their work.They came up with some innovative new construction techniques, and within months they had orders piling up. Now SkatesTown has a small manufacturing operation in Brooklyn, and the company is selling boards, clothing, and equipment to stores around the city. Dean, Frank Stemkowski, and Chad Washington couldn’t be happier about how their business has grown.
Of the three, Chad is the real gearhead, and he has been responsible for most of the daring construction and design choices that have helped SkatesTown get where it is today. He’s the president and head of the team. Frank, gregarious and a smooth talker ever since childhood, now handles marketing and sales. Dean has tightly tracked the computer revolution over the years, and he’s chief technical officer for the company.
A few years back, Dean realized that networking technology was going to be big, and he wanted to make sure that SkatesTown could catch the wave and utilize distributed computing to leverage its business.This focus turned out to be a great move.
Dean set up a Web presence so SkatesTown could help its customers stay up to date without requiring a large staff to answer phones and questions. He also built an online order-processing system to help streamline the flow of the business with
network-enabled clients. In recent months, more and more stores who carry SkatesTown products have been using the system to great effect.
Our Story Begins
At present, Dean is pretty happy with the way things are working with SkatesTown’s electronic commerce systems. But there have been a few problems, and Dean is sure that the systems could be even better. He realizes that as the business grows, the manual tasks associated with order gathering and inventory resupply will limit the company’s success.
Always one to watch the horizon, Dean has heard the buzz about Web services, and he wants to know more. At the urging of a friend, he got in touch with Al Rosen, a con- tractor for Silver Bullet Consulting (SBC). Silver Bullet specializes in Web services solu- tions, and after a couple of meetings with Al, Dean was convinced—he hired SBC to come in, evaluate SkatesTown’s systems, and help the company grow into a Web service–enabled business.
As we move through the rest of the book, we’ll keep an eye on how SkatesTown uses technologies like XML and, later, SOAP,WSDL, UDDI, and the rest of the Web services stack to increase efficiency and productivity, and establish new and valuable relationships with its customers and business partners. Silver Bullet, as you’ll see, usually lives up to its name.
I
Web Services Basics
1 Web Services Overview and Service-Oriented Archectures 2 XML Primer
3 The SOAP Protocol 4 Describing Web Services
5 Implementing Web Services with Apache Axis
6 Discovering Web Services
1
Web Services Overview and Service-Oriented Architectures
O
KAY,ENOUGH WITH THE HYPE. Some have said that Web services promised to be everything to everyone, but clearly that isn’t going to happen.Where is the business ben- efit behind the Web services technologies? That’s what this book will attempt to explain, in the context of exploring the technologies themselves. Several things do seem to be true:n According to many industry analyst reports,Web services are being used by the vast majority of Fortune 500 businesses.
n Web services technology promises to help small and medium businesses participate more effectively in supply chains of large organizations.
n Information technology (IT) vendors have adopted Web services (more or less) as a major part of their software strategy.
n The Web services industry is dominated by standards activities, minimizing the likelihood of the technology being dominated by a single vendor.
That being said, several concerns remain:
n Widespread adoption, particularly after several pilot projects are completed, has been slow to happen. Some people speculate that the business climate after 2000 was too conservative, and the dot-com bubble made businesses shy of shiny new technology.
n Standards are being developed, but this is happening at a majestic (slow) pace.
Tooling and runtime support will follow, but when? Security standards have just recently been finalized, and infrastructure products supporting those standards have yet to be ubiquitously deployed. Additional concerns are lack of finalized reliable messaging and transaction standards. Some analysts claim that the Web services hype wasn’t about the technology’s promise (it’s well positioned to deliver value),
but rather about the rate and pace of its maturity: It’s a lot harder to get industry standards adopted than it’s to drive proprietary technologies.
n Best practices are slow in coming.Without a good base of solid implementation experience, there will continue to be a lot of thrashing around as businesses figure out what to use this technology for.
n Business process design is just beginning to take a service-oriented approach. Until this happens, many powerful benefits of Web services won’t be realized.
So how can we move forward? We talk about adoption pragmatics toward the end of the book, in Chapter 14, “Web Services Pragmatics”; until then, it’s important for developers to understand the individual technologies and standards that make up the Web services landscape. Discussing these technologies in the context of a scenario, like the SkatesTown scenario we return to throughout the book, is one excellent way to get a basic under- standing of Web services. After you learn the basic concepts, technology, and terminolo- gy, the next step is for you to implement, practice, summarize, and discuss.
In this chapter, we’ll provide the basic terminology and set of concepts that put the remainder of the book into context.We’ll define what we mean by a Web service
g
and describe situations in which Web services play an important role.We’ll describe a simple framework, called service-oriented architectureg
, which helps structure the application of Web services technologies.We’ll also provide a framework, in the form of an “interoper- ability” stack that positions how the various Web services technologies including SOAPg
, Web Services Description Language (WSDL)g
, and Universal Description Discovery and Integration (UDDI)g
relate.The rest of the book, then, is an elaboration of the basic concepts presented here.What Is a Web Service?
This is a book about building Web services.We can’t describe how to build a Web serv- ice without first clarifying what we mean by Web service.
Web services have gained a lot of momentum since the term was introduced in the year 2000. Many software vendors (large and small) have Web services initiatives and products. In fact, some vendors are in the second or third version of their Web services product offerings! Many organizations are involved in the refinement of Web services standards. Early in the evolution of Web services there seemed to be a slow convergence toward a common understanding of what the term means—there was no single, univer- sally adopted definition of what is meant by the term Web service.This situation was rem- iniscent of the early days of object-oriented programming: Not until the concepts of inheritance, encapsulation, and polymorphism were well defined did object-oriented programming become accepted into the mainstream of development methodologies.
Several major Web services infrastructure providers published their definitions for a Web service. And through the process of open standards development, a commonly accepted term emerged.The Web services Architecture working group of the World Wide
11 What Is a Web Service?
Web Consortium
g
(W3C, which manages the evolution of the SOAP and WSDL spec- ifications) developed the following definition for a Web service:A Web service is a software system designed to support interoperable machine-to- machine interaction over a network. It has an interface described in a machine- processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related stan- dards.
One important point is that a Web service need not necessarily exist on the World Wide Web.This is an unfortunate historical naming issue. A Web service can live anywhere on the network, Inter- or intranet. In fact,Web services have little to do with the browser- centric, HTML-focused World Wide Web. (Sometimes the names we choose in the IT industry don’t make a lot of sense; they simply take on a life of their own.)
Another important point is that a Web service’s implementation and deployment plat- form details aren’t relevant to a program that’s invoking the service. A Web service is available through its declared API and invocation mechanism (network protocol, data encoding schemes, and so on).This is analogous to the relationship between a Web browser and a Web application server:Very little shared understanding exists between the two components.The Web browser doesn’t care if the Web application server is Apache Tomcat, Microsoft Internet Information Services Server, or IBM WebSphere.The shared understanding is that they both speak HTTP and converse in HTML or a limited set of MIME types. Similarly, the Web application server doesn’t care what kind of client is using it—various brands of Web browsers or even non-browser clients.This minimal shared understanding between components allows Web services to form a system of loosely coupled components.
Business Perspective
Web services have become an important concept for business people; they’re quickly becoming a significant part of a business IT strategy.The vast majority of the Fortune 500 has already adopted Web services in some fashion. Although Web services–based sys- tems are mainly deployed for internal application purposes, a growing minority (around 40–50% according to recent surveys) of companies are beginning to use Web services with their customers, suppliers, and business partners.
To a business person, the Web services approach is all about integration: integrating application functionality within an organization or integrating applications between busi- ness partners (in a supply chain, for example).The scenario in this book illustrates this approach. Application integration allows time and cost efficiencies for receiving purchase orders, answering status inquiries, processing shipment requests, and so on.The important point is that application integration is enabled without tight lock-in to any particular business partner. If another supplier has better prices, shipping terms, or quality assur- ance, then a company’s reorder systems can be easily repositioned to use that supplier;
doing so is as easy as pointing a Web browser at a different Web site.With a broader adoption of Web services and XML document format standards, this style of dynamic business partner integration will become more broadly used.The Web services technolo- gy has become so important in business that it’s even appearing in business school cur- riculums. One of the authors of this book recently completed an MBA degree; Web services were featured in several of the courses!
The systems integration thought isn’t new.The IT industry has offered numerous integration technologies; many were proprietary, some were based on open standards.
Web services reflect the application of a trend broadly accepted in the IT community:
adoption of open standards.With Web services acting as a ubiquitous integration infra- structure supported by most organizations, the task of building cross-organizational information systems (such as a supply chain) becomes much easier and less expensive.
When systems are easy and inexpensive to integrate, an organization’s reach to suppli- ers, customers, and other business partners is extended, yielding cost savings, flexible business models, better customer service, higher customer retention, and so on.This fact is driving change in the way organizations think about building IT systems, particularly those involving integration of existing software programs and those of suppliers, cus- tomers, and business partners. Just as IT is fundamental to the efficient operations of an organization,Web services–based systems integration will be fundamental to flexible, lightweight systems integration—for internal application integration within an organiza- tion over an intranet and external partner integration over the Internet or extended vir- tual private network.
So, from a business perspective, a Web service is a business process or step within a business process that is made available over a network to internal and/or external busi- ness partners to achieve a business goal.The key is ease of integration, particularly between organizations, allowing business systems to be built quickly by combining Web services built internally with those of business partners.
Technical Perspective
From a technical perspective, a Web service is nothing more than a collection of one or more related operations that are accessible over a network and are described by a service description. At this level, the Web services concept isn’t new.With Web services, the IT industry is trying to address the fundamental challenge of distributed computing that has been around for decades: locating and accessing remote components.The big difference is that now the industry is approaching this problem using open technology (XML and Internet protocols) and open standards managed by broad consortia such as OASIS
g
and the W3C.
The role of loose coupling can’t be overemphasized. Instead of building an application as a collection of tightly coupled components or subroutines, all of which are well known to the developer at coding time, the Web services approach is much more dynamic.The focus with Web services is on the interface: the contract between a Web service and the component invoking it. Of course, this approach isn’t new; what is new
13 Service-Oriented Architectures
is the way that Web services combine the loosely coupled component-based approach to software development with the lessons learned from the World Wide Web—particularly the important role of simple, open standards to achieve ubiquitously deployed infrastruc- ture capabilities.
Service-Oriented Architectures
Early in the Web services technology evolution, we noticed a pattern that we called service-oriented architecture (SOA). SOA is a simple concept, which makes it applicable to a wide variety of Web services situations.
In an SOA, all software components (or functional units that are visible for other entities to invoke or consume over the network) are modeled as services.That is, the architectural premise is that all business tasks or business processes that are built in soft- ware are designed as services to be consumed over a network.
In an SOA, the focus of design is the service’s interface.This is similar to component- based software engineering approaches we’ve seen. However, a major difference is that the focus of application design is shifted to composing services invoked over a network.
In the SOA approach, the designer isn’t building a program, a functional unit for one purpose/use only; rather, they’re building a service that has a well-defined interface and that can potentially be used in multiple business contexts.
Because SOA is focused on building applications using components with well-defined interfaces, it allows applications to be loosely coupled. Applications are integrated at the interface (contract) level, not at the implementation level.This allows greater flexibility, because applications are built to work with any implementation of a contract, not to take advantage of a feature or idiosyncrasy of a particular implementation. For example, dif- ferent service providers (of the same interface) can be dynamically chosen based on poli- cies (such as price, other QoS guarantees, current transaction volume, and so on).
Figure 1.1 depicts the main roles and operations in an SOA. Any service-oriented architecture contains three roles: a service requestor
g
, a service providerg
, and a serviceregistry
g
:n A service provider is responsible for creating a service description
g
, deploying that service in a runtime environment that makes it accessible by other entities over the network, publishing that service description to one or more service registries, and receiving Web service invocation messages from one or more service requestors. A service provider, then, can be any company that hosts a Web service made available on a network.You can think of a service provider as the “server side” of a client- server relationship between the service requestor and the service provider.n A service requestor is responsible for finding a service description published to one or more service registries and is responsible for using service descriptions to bind to or invoke Web services hosted by service providers. Any consumer of a Web service can be considered a service requestor.You can think of a service requestor as the “client side” of a client-server relationship between the service requestor and the service provider.
n The service registry is responsible for advertising Web service descriptions published to it by service providers and for allowing service requestors to search the collec- tion of service descriptions contained within the service registry.The service reg- istry role is simple: to be a matchmaker between service requestor and service provider. Once the service registry makes the match, it’s no longer needed in the picture; the rest of the interaction takes place directly between the service requestor and the service provider for the Web service invocation.
Service Registry
Service Requestor
Service Provider Bind
Find Publish
Figure 1.1 Service-oriented architecture
Each of these roles can be played by any program or network node. In some circum- stances, a single program might fulfill multiple roles; for example, a program can be a service provider, providing a Web service to downstream consumers, as well as a service requestor, itself consuming Web services provided by others.
An SOA also includes three operations: publish
g
, findg
, and bindg
.Theseoperations define the contracts between the SOA roles:
n The publish operation is an act of service registration or service advertisement. It acts as the contract between the service registry and the service provider.When a service provider publishes its Web service description to a service registry, it’s advertising the details of that Web service to a community of service requestors.
The details of the publish API depend on how the service registry is implement- ed. In certain simple or direct publish scenarios, the service registry role is played by the network itself, with publish being an act of moving the service description into a Web application server’s directory structure. Other services registry imple- mentations, such as UDDI, define a sophisticated implementation of the publish operation.
n The find operation is the logical dual of the publish operation. It’s the contract between a service requestor and a service registry.With the find operation, the service requestor states a search criteria, such as type of service, various other aspects of the service such as quality of service guarantees, and so on.The service
15 Service-Oriented Architectures
registry matches the find criteria against its collection of published Web service descriptions.The result of the find operation is a list of service descriptions that match the find criteria. Of course, the sophistication of the find operation varies with the implementation of the service registry role. Simple service registries can provide a find operation with nothing more sophisticated than an unparameterized HTTP GET.This means the find operation always returns all Web services pub- lished to the service registry, and it’s the service requestor’s job to figure out which Web service description matches its needs. UDDI, of course, provides extremely powerful find capabilities.
n The bind operation embodies the client-server relationship between the service requestor and the service provider. It can be quite sophisticated and dynamic, such as on-the-fly generation of a client-side proxy based on the service description used to invoke the Web service; or it can be a static model, where a developer hand-codes the way a client application invokes a Web service.
The key to SOA is the service description. It’s the service description that is published by the service provider to the service registry. It’s the service description that is retrieved by the service requestor as a result of the find operation. It’s a service description that tells the service requestor everything it needs to know in order to bind to or invoke the Web service provided by the service provider.The service description also indicates what information (if any) is returned to the service requestor as a result of the Web service invocation.
Each time an SOA is deployed, different technologies may fulfill each role. Chapter 6, “Discovering Web Services,” discusses various options for implementing a service reg- istry and goes into great detail on the UDDI service registry technology. Chapter 4,
“Describing Web Services,” discusses service description in detail. Chapters 3 and 5, “The SOAP Protocol” and “Implementing Web Services with Apache Axis,” focus on the use of SOAP to fulfill the bind operation. Chapter 9, “Securing Web Services,” discusses how to make Web services more secure. Chapters 10 and 11, “Web Services Reliable
Messaging” and “Web Services Transactions,” describe how to make invoking Web serv- ices reliable and transactable. In Chapter 12, “Orchestrating Web Services,” you’ll learn how to build applications by stitching services together using a workflow technique.
The choices of which techniques to use are driven by business needs. How secure does a Web service invocation need to be? There is a price to pay for security (in com- plexity and performance); sometimes it’s worth paying, and other times the risk doesn’t warrant the cost. Is reliable message delivery important? For some Web services invoca- tions, it clearly is; for others, it isn’t obvious that the complexity and the performance price are warranted.The same is true for transactions and the other Web services capabil- ities discussed in this book.
Why Is SOA So Important?
SOA is an important trend within the IT community.There is a lot of discussion among analysts and developers about the term.Why all the fuss?
With the SOA approach to application architecture, your view of the entire software portfolio is different. SOA augments and grows your application portfolio. Existing appli- cations can be easily converted to services, to be consumed by existing or new applica- tions.Your portfolio of applications gradually shifts to become a portfolio of components exposed as services and applications composed of services (service orchestrations).
Eventually, monolithic, tightly coupled, inflexible applications will be replaced by SOA-architected applications.This won’t happen overnight, but rather will take place in an evolutionary fashion, driven by business needs.
With an SOA, organizations will be better able to construct software to integrate business processes and respond rapidly to changes in the business environment: the arrival of a new supplier or competitor, a shift of business model, a postmerger combi- nation of IT assets, the opportunity to outsource a business process, and so on.When parts of the solution to the new business system were built by autonomous organiza- tions, an SOA approach is the best approach to stitch the solution together. More than any technical consideration, this concept of implicit, seamless software integration as a major business benefit is one of the main drivers for service orientation.
The SOA approach isn’t lost on vendors of prepackaged software applications. Many major application vendors are at the forefront of Web services standards and SOA prac- tices.The forward-thinking among the software vendors recognize this new SOA emphasis and are incrementally moving their product offerings away from tightly coupled, shrink-wrapped software suites toward more flexible, mix-and-match, loosely coupled SOA architectures of services.This approach will ease their customers’ task of integrating packaged software components with existing business systems and processes.
Another important benefit of SOA comes from the notion of bringing IT concepts and business concepts closer together. Previously, technical architectures reflected too much technical detail and hid the underlying business process.With SOA, it’s easier to focus on modeling business processes and tasks as services and building business systems as workflow combinations of these underlying services.With a closer modeling of the business system in technology, it becomes easier to isolate the parts of the system that need changing to reflect those tasks in the business process that need changing.With an SOA approach, technical details of the service are hidden behind the interface, and the designer’s attention is focused on jointly (or unilaterally) designing useful service inter- faces.
Thus the combination of a closer IT model of the business, together with loose cou- pling, provides the overall business benefit of SOA.The benefit boils down to good choice of service.What service interface design yields most benefit to the organization, and which is most useful to important service requestors? Which existing applications can be refactored or wrappered as services and let you quickly get to the point of build- ing SOAs from existing IT investments? Which business processes will provide the biggest benefit if they’re built or refactored as services? These are important questions to address when you’re considering adopting SOA.
