Building Web Services with Java M A K I N G S E N S E O F X M L , W S D L , A N D U D D I S O A P, Second Edition Steve Graham Doug Davis Simeon Simeonov Glen Daniels Peter Brittenham Yuichi Nakamura Paul Fremantle Dieter König Claudia Zentner DEVELOPER’S LIBRARY Sams Publishing, 800 East 96th Street, Indianapolis, Indiana 46240 Building Web Services with Java, Second Edition Associate Publisher Michael Stephens 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 omissions 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 Acquisitions Editor Todd Green 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 information provided is on an “as is” basis.The author and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information 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 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 I Web Services Basics Web Services Overview and Service-Oriented Architectures XML Primer 31 The SOAP Protocol 111 Describing Web Services 167 Implementing Web Services with Apache Axis 233 Discovering Web Services 307 II Enterprise Web Services Web Services and J2EE 347 Web Services and Stateful Resources 383 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 717 Appendix A Glossary 731 Index 755 Table of Contents Introduction I Web Services Basics Web Services Overview and ServiceOriented Architectures 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 Contents 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-Based checkInvoice() 85 DOM-Based checkInvoice() 91 JAXB-Based checkInvoice() 96 Testing the Code 105 Summary 107 Resources 109 v vi Contents 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 The mustUnderstand Flag 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 out and inout Parameters 149 XML, Straight Up: Document-Style SOAP 151 When to Use Which Style 151 Contents The Transport Binding Framework 152 Features and Properties 153 The HTTP Binding 157 The SOAPAction Feature 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 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 vii viii Contents 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 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 The MessageContext and 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 The Service Object 246 Using the Call Object for Dynamic Invocation 247 Using Stubs and WSDL2Java 253 Holders: Mapping inout/out Parameters to Java 256 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 TypeMapping 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 The AxisFault Class 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 ix 330 Chapter Discovering Web Services Listing 6.5 Continued “uuid:8609C81E-EE1F-4D5A-B202-3EB13AD01823”)); identifierBag.setKeyedReferenceVector(keyedReferenceList); businessEntity.setIdentifierBag(identifierBag); // Set categoryBag CategoryBag categoryBag = new CategoryBag(); keyedReferenceList = new Vector(); keyedReferenceList.add(new KeyedReference( “Sporting and Athletic Goods Manufacturing”, “33992”, “uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2”)); keyedReferenceList.add(new KeyedReference(“New York”, “US-NY”, “uuid:4E49A8D6-D5A2-4FC2-93A0-0411D8D19E88”)); categoryBag.setKeyedReferenceVector(keyedReferenceList); businessEntity.setCategoryBag(categoryBag); // Obtain authToken using get_authToken UDDI API AuthToken authToken = uddiProxy.get_authToken(userid, password); // Save businessEntity Vector businessEntityList = new Vector(); businessEntityList.add(businessEntity); BusinessDetail businessDetail = uddiProxy.save_business(authToken.getAuthInfoString(), businessEntityList); // Get businessKey for published businessEntity String businessKey = ((BusinessEntity) businessDetail.getBusinessEntityVector().elementAt(0)).getBusinessKey(); // Display businessKey System.out.println(“Published businessEntity key: “ + businessKey + “.”); } public static void main(String[] args) { try { PublishBusinessEntity publishBusinessEntity = new PublishBusinessEntity(); publishBusinessEntity.saveBusiness(args[0], args[1]); } catch (Exception e) { System.out.println(“EXCEPTION: “ + e.toString()); } System.exit(0); } } As previously mentioned, a publisher assertion is used to associate a pair of existing Business Entity entries An assertion isn’t complete until the publishers of both entries have made the same assertion Five APIs are used to process publisher assertions: add_publisherAssertions—Adds one or more publisherAssertions to the publisher’s assertion collection businessEntity businessEntity n n n n n delete_publisherAssertions—Deletes one or more publisherAssertions from the publisher’s assertion collection get_publisherAssertions—Gets the full list of publisherAssertions associated with a publisher’s assertion collection get_assertionStatusReport—Determines the status of current and outstanding assertions set_publisherAssertions—Adds new assertions or updates existing assertions The call operates on the entire set of assertions for a publisher The final publication API call is get_registeredInfo.This message is used to obtain a complete list of businessEntity and tModel entries that are owned by the publisher associated with the provided authentication token Finding Service Descriptions When you’re finding a service description, you can use two types of inquiry APIs: the find APIs and the get APIs Except for the find_binding API, the find APIs for the primary datatypes are used to retrieve a list of references (UDDI keys) to UDDI data entries using specified search criteria.The find_binding API returns the contents of a bindingTemplate.The get APIs are used to return the actual contents of a data entity Table 6.3 summarizes the inquiry APIs for the primary datatypes Table 6.3 UDDI Inquiry APIs Datatype Find API Get API bindingTemplate find_binding get_bindingDetail businessEntity find_business get_businessDetail serviceBusiness find_service get_serviceDetail tModel find_tModel get_tModelDetail Here’s an example of the message that would be sent to find the businessEntity for SkatesTown, using just identifier and categorization information: 331 332 Chapter Discovering Web Services The response to this message contains a list of businessInfo elements, each of which contains a reference to a businessEntity that matched the find criteria: SkatesTown Each businessEntity is referenced by its businessKey.The businessKey can be used to retrieve the actual contents of the businessEntity.The following message would be used to retrieve the full contents of the businessEntity (which appears in Listing 6.4): 54438690-573E-11D8-B936-000629DC0A53 Listing 6.6 provides an example of how to use UDDI4J to process the preceding find_business and get_businessDetail operations Listing 6.6 Find BusinessEntity Example import import import import import import org.uddi4j.client.*; org.uddi4j.datatype.*; org.uddi4j.datatype.business.*; org.uddi4j.datatype.tmodel.*; org.uddi4j.response.*; org.uddi4j.util.*; Business Entity Listing 6.6 Continued import java.util.*; /** * Chapter - Find BusinessEntity Example * * This example shows how to find the businessEntity * that represents SkatesTown */ public class FindBusinessEntity { // Location of UDDI registry String inquiryURL = “http://uddi.ibm.com/testregistry/inquiryapi”; /** * Find the businessEntity and then get its details */ protected void getBusinessDetail() throws Exception { UDDIProxy uddiProxy = null; // Create UDDI proxy uddiProxy = new UDDIProxy(); uddiProxy.setInquiryURL(inquiryURL); // Create identifierBag IdentifierBag identifierBag = new IdentifierBag(); Vector keyedReferenceList = new Vector(); keyedReferenceList.add(new KeyedReference(“DUNS”, “00-111-1111”, “uuid:8609C81E-EE1F-4D5A-B202-3EB13AD01823”)); identifierBag.setKeyedReferenceVector(keyedReferenceList); // Create categoryBag CategoryBag categoryBag = new CategoryBag(); keyedReferenceList = new Vector(); keyedReferenceList.add(new KeyedReference( “Sporting and Athletic Goods Manufacturing”, “33992”, “uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2”)); keyedReferenceList.add(new KeyedReference(“New York”, “US-NY”, “uuid:4E49A8D6-D5A2-4FC2-93A0-0411D8D19E88”)); categoryBag.setKeyedReferenceVector(keyedReferenceList); // Find the businessEntity using just the identifierBag // and categoryBag as a search criteria BusinessList businessList = uddiProxy.find_business((Vector) null, (DiscoveryURLs) null, identifierBag, categoryBag, (TModelBag) null, (FindQualifiers) null, 10); 333 334 Chapter Discovering Web Services Listing 6.6 Continued // Get businessKey for the first businessEntity found String businessKey = ((BusinessInfo) businessList.getBusinessInfos().get(0)).getBusinessKey(); // Display businessKey System.out.println(“Key for businessEntity found: “ + businessKey + “.”); // Get the businessEntity details BusinessDetail businessDetail = uddiProxy.get_businessDetail(businessKey); // Get first business name Name businessName = (Name) ((BusinessEntity) businessDetail.getBusinessEntityVector().elementAt(0)).getNameVector().get(0); // Display business name System.out.println(“Name of businessEntity found: “ + businessName.getText() + “.”); } public static void main(String[] args) { try { FindBusinessEntity findBusinessEntity = new FindBusinessEntity(); findBusinessEntity.getBusinessDetail(); } catch (Exception e) { System.out.println(“EXCEPTION: “ + e.toString()); } System.exit(0); } } In addition to the find and get APIs for the primary UDDI datatypes, the following APIs are also available: find_relatedBusinesses—Used to find all the businesses affiliated with a specified business type.The affiliation would have been defined previously using the save_publisherAssertion call get_businessDetailExt—Returns extended businessEntity information for one or more specified businessEntity entries.This message returns the same information as the get_businessDetail message, but it may contain additional information n n Business Entity What’s New in UDDI Version 3.0 UDDI version 3.0 provides a significant set of improvements over UDDI version 2.0 The major enhancements are described in this section Policy Polices are used to define the specific operational behavior for a UDDI registry.This feature was added to make it easier to use a UDDI registry in environments that have different operational characteristics (for example, a test registry versus a production registry) A registry can set the following types of policies: n n n n n n n n n Policy delegation—Defines the set of policies that can be delegated to nodes Keying—Defines the policies that affect key generation and format As an example, these policies could be set to allow publisher-assigned keys (described later) APIs—Describes policies for the data confidentiality of the different sets of APIs Time policies—Defines how nodes in a registry synchronize their clocks User policies—Defines the policies for publication limits and transferring ownership of UDDI data entities Data custody—Defines the policy for custody transfer between nodes Custody indicates the node where changes must be made to a data entity Replication—Defines whether replication is supported, and what protocol should be used Subscription—Defines whether subscription is supported, as well as aspects such as conditions for renewal and volume limits Value set policy— Describes policies related to the external validation of values and the associated caching behavior Security Starting with UDDI version 3.0, entities published to a UDDI registry can be digitally signed, providing a way to ensure the authenticity and integrity of data in the registry All five of the primary UDDI datatypes can be signed using XML digital signatures.You can learn more about digital signatures in Chapter 9, “Securing Web Services.” When publishing an entity in a UDDI registry, the publisher digitally signs the content of the entity and provides the digital signature as an element within the entity When a service requestor searches the registry, it may specify that its query should only return entities that have been signed When SkatesTown starts using UDDI version 3.0 registries, the company will sign all the entities it publishes By doing so, SkatesTown assures its customers and business partners that the data represented by those entities are valid 335 336 Chapter Discovering Web Services Support for Multi-Registry Environments UDDI version 3.0 introduces the concepts of root and affiliate registries Affiliate registries rely on the root registry to ensure that key values are unique across both types of registries An example of a root registry is the UDDI Business Registry Since the root registry ensures unique key values, data can be easily shared between root and affiliate registries.This support has helped enable two other new functions: subscription and publisher-assigned keys In SkatesTown’s environment, the UDDI registry hosted by e-Torus could be the root registry, and the affiliate registries could be hosted by the members for the e-Torus marketplace Subscription You can use the new subscription function to receive notification when changes occur in a registry.There are two types of subscriptions: entity-based and query-based An entity-based subscription notifies the subscriber when one or more entities have changed.When using a query-based subscription, the subscriber is notified when the result set for the query changes within a specified time period SkatesTown can use the subscription feature to track the services its competitors add, or to track the services that are added to the e-marketplace registry.This mechanism can also be used to keep the contents of two or more registries synchronized Publisher-Assigned Keys When an entity is added to a UDDI registry, it’s assigned a unique key that is a URI This key is used to identify the entity in much the same way that a primary key is used in a relational database In version 3.0, assigning keys to an entity is controlled by policy, and the policy can be defined to allow the publisher to specify the key for an entity when it’s published This feature provides two benefits First, it provides a method to move entities between UDDI registries without having to create new keys As an example, if you have a test registry and a production registry, you can move a businessEntity from one to the other without changing its business key Second, the keys may contain values that make them easier to use There are three types of keys: uuidKey, domainKey, and derivedKey All the keys use the format “scheme : value”, where the scheme is always “uddi”.The uuidKey is the same as the UDDI version 2.0 (and version 1.0) keys.These keys contain a UUID (Universally Unique Identifier) as a value.The domainKey has a valid hostname as a value, and the derivedKey is a UDDI key with a key-specific string appended to it Here are some examples of these keys and how SkatesTown could use the domainKey and derivedKey: uuidKey—uddi:4CD7E4BC-648B-426D-9936-443EAAC8AE23 domainKey—uddi:www.SkatesTown.com derivedKey—uddi:www.SkatesTown.com:PriceCheck, n n n uddi:www.SkatesTown.com:PurchaseOrderSubmission Business Entity Using WSDL with UDDI UDDI provides a method for publishing and finding service descriptions.The UDDI data entities provide support for defining both business and service information.The service description information defined in WSDL is complementary to the information found in a UDDI registry UDDI provides support for many different types of service descriptions A Web service, registered in UDDI as a businessService, can be described using WSDL, a plain ASCII text document, a RosettaNet pip, RDF, or any other type of description mechanism As a result, UDDI has no direct support for WSDL or any other service description mechanism In this section, we explore how to publish in a UDDI registry Web services that are described using WSDL How to Publish WSDL-Based Service Descriptions The UDDI organization has published two best-practices documents that describe how to publish WSDL-based service descriptions in a UDDI registry: n Using WSDL in a UDDI Registry 1.08—http://www.oasis-open.org/ committees/uddi-spec/doc/bp/uddi-spec-tc-bp-using-wsdl-v10820021110.htm n Using WSDL in a UDDI Registry,Version 2.0—http://www.oasis-open.org/ committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v200-20031104.htm The second document supplements the information in the first.The primary difference is that the second document provides a method to model and represents individual Web service artifacts Since the first document is referenced by the WS-I Basic Profile (see Chapter 13, “Web Services Interoperability,” for more details), Al Rosen has decided to use these conventions as the process for publishing the SkatesTown WSDL service descriptions in a UDDI registry Mapping from WSDL to UDDI A WSDL service description contains an abstract definition for a set of operations and messages, a concrete protocol binding for these operations and messages, and a network endpoint specification for the binding Figure 6.4 outlines how the major WSDL elements map into UDDI elements Since the service interface represents a reusable definition of a service, a reference to it is published in a UDDI registry as a tModel If the service interface definition contains more than one binding element, the reference to the service interface may include a pointer to a specific WSDL binding element.The service implementation describes an instance of a service, and each instance is defined using a WSDL service element Each service element in a service implementation document corresponds to a UDDI businessService element In particular, the Web service location (address) listed in a WSDL port element must be the same as the value in the UDDI accessPoint element 337 Business Entity For a n n n tModel, the mapping from WSDL to UDDI is the following: The overviewURL element must contain a reference to the WSDL binding element in the poSubmission Web service interface definition Since the poSubmission.wsdl document contains only one binding element in it, there is no need to directly reference the binding definition The keyedReference element in the categoryBag is used to indicate that this tModel is categorized as a WSDL specification.This means the document referenced by the overviewURL must be a WSDL document The value of the tModelKey attribute must be referenced by the bindingTemplate that’s created next After the tModel is published, Al poSubmission Web service: can publish the following businessService for the Purchase Order Submission SkatesTown purchase order submission service. SOAP based purchase order submission service. http://www.skatestown.com/services/poSubmission 339 340 Chapter Discovering Web Services Reference to tModel with Web service interface definition Reference to WSDL service implementation document http://www.skatestown.com/services/ ➥poSubmissionImplementation.wsdl The important content within the bindingTemplate element is as follows: The accessPoint element contains the URL at which the Web service can be invoked.This value must be the same as the address value from the port element in the WSDL service implementation document The tModel referenced by the tModelInstanceInfo element must be the tModel that contains the reference to the service interface definition for this service Al followed an extended convention that defined how to reference the service implementation document from the bindingTemplate element.The overviewURL element contains a reference to the WSDL service implementation document Although this isn’t defined in the best-practices document, it does provide a way for the service requestor to obtain additional WSDL-based information for this service n n n Publishing a Service Definition with Multiple Bindings Let’s look at another example that requires us to reference a single binding within a WSDL service interface definition that contains multiple bindings (see Listing 6.7).The e-Torus marketplace has decided to publish a standard version of both the PriceCheck and poSubmission Web service definitions It combined both service interface definitions into one physical file, which is located on the e-Torus Web site: http://www.etorus.com/services/OrderInterface.wsdl Business Entity Listing 6.7 e-Torus Order Service Definition 341 342 Chapter Discovering Web Services Listing 6.7 Continued When e-Torus publishes this service interface, it will create two tModel entries (one for each binding definition) Here is the tModel for the binding named poSubmissionSOAPBinding: e-Torus purchase order submission service This is the standard service interface definition for purchase order submission service Reference to the WSDL document that contains the e-Torus standard service interface definition for the purchase order submission service http://www.e-Torus.com/services/OrderInterface.wsdl# ➥xmlns(wsdl=http://schemas.xmlsoap.org/wsdl/) ➥xpointer(//wsdl:binding[@name=’poSubmissionSOAPBinding’]) The contents of this tModel are similar to the one that SkatesTown published.The primary difference is that the overviewURL contains an XPointer (http://www.w3.org/TR/WD-xptr) reference to the binding named poSubmissionSOAPBinding.To use this tModel, SkatesTown would have to update the bindingTemplate in its businessService element to reference tModelKey: uuid:6783FF9C-1277-7823-BA89-34A976B1E6D2 Other Service Discovery Methods Other Service Discovery Methods There have been other attempts to define specifications for Web service discovery.Two specifications that we review here are the Web Service Inspection Language (WSInspection) and WS-ServiceGroup WS-Inspection The Web Services Inspection Language (WS-Inspection) defines a method to discover service descriptions at the service provider’s point of offering (http://www106.ibm.com/developerworks/webservices/library/ws-wsilspec.html).The WSInspection specification defines two primary functions: n n The XML format used to list references to existing Web services—A WS-Inspection document can reference a WSDL service description directly, and it can also reference UDDI entries The set of conventions for locating WS-Inspection documents on a Web site—WSInspection documents can be placed at common entry points for a Web site, or references to WS-Inspection documents can appear within Web content documents, such as HTML pages WS-Inspection provides a basic method for service discovery, but it requires you to know the location of a service provider so that you can inspect its Web site Although WS-Inspection provides a service-discovery methodology that’s complementary to UDDI (distributed versus centralized service discovery), it isn’t being pursued as a Web service standard because it didn’t gain enough support WS-ServiceGroup The WS-ServiceGroup specification is one of the WS-Resource Framework specifications (http://www.globus.org/wsrf).These specifications provide the basis for convergence of the Grid and Web services worlds.The WS-ServiceGroup specification was derived from the ServiceGroup portType in the OGSI 1.0 specification (http://www globus.org/research/papers/Final_OGSI_Specification_V1.0.pdf).WSServiceGroup defines a method for grouping together Web services and WS-Resources (a Web service that is associated with a stateful resource) A Web service that belongs to a ServiceGroup is a Member, and each Member is associated with the ServiceGroup through a ServiceGroupEntry Members of a ServiceGroup must conform to the membership rules and constraints for the ServiceGroup, so that meaningful queries can be processed to locate entries in the ServiceGroup.The concept of a ServiceGroup could be used to define an aggregation of Web services that form a basic service registry The queries that are processed against a ServiceGroup could be used to discover Web services that are defined as Members of the ServiceGroup 343 344 Chapter Discovering Web Services Summary In this chapter, we’ve described the role of service registries such as UDDI within a service-oriented architecture.We examined UDDI datatypes and APIs in some depth, reviewed the use of UDDI for private service registries, and discussed the new features that will be available in UDDI version 3.0 Finally, we examined the convention for publishing WSDL-based Web services in a UDDI registry and how that convention can make UDDI effective for doing dynamic discovery of Web services at runtime Resources n UDDI specifications—http://www.oasis-open.org/committees/uddispec/doc/tcspecs.htm n UDDI best practices—http://www.oasis-open.org/committees/uddispec/doc/bps.htm n UDDI technical notes—http://www.oasis-open.org/committees/uddispec/doc/tns.htm n Web Service Inspection Language (WS-Inspection)—http://www-106.ibm.com/ developerworks/webservices/library/ws-wsilspec.html ... Discovering Web Services 307 II Enterprise Web Services Web Services and J2EE 347 Web Services and Stateful Resources 383 Securing Web Services 445 10 Web Services Reliable Messaging 507 11 Web Services. .. (SOAP) 11 2 What Is SOAP, Really? 11 3 Doing Business with SkatesTown 11 4 Inventory Check Web Service 11 7 Choosing a Web Service Engine 11 7 Service Provider View 11 7 Deploying the Service 11 8 The... Model 17 4 Parts of the WSDL Language 17 6 Structure of a WSDL Document: Definitions 17 8 PortType 17 9 Operation 18 0 Message 18 0 Part 18 1 Types 18 4 Binding 18 6 Port 19 0 Service 19 1 Documentation 19 2