• | Table of Contents
UDDI: Building Registry-Based Web Services Solutions
By Naresh Apte, Toral Mehta
Publisher | : Prentice Hall PTR
Pub Date | : December 23, 2002
ISBN | : 0-13-046457-0
Pages | : 448

UDDI: Building Web-based Web Services Solutions is a start-to-finish guide to using UDDI in real-world Web services. Naresh Apte and Toral Mehta begin with the fundamentals of business registries and Web services ecosystems. Then, using realistic case studies and example code, they illuminate every facet of UDDI-based Web services construction, including modeling, development, publishing, and inquiry. The authors range from UDDI data structures to Java and .NET APIs, and basic interactions through sophisticated cross-enterprise integration.


• | Table of Contents
UDDI: Building Registry-Based Web Services Solutions
By Naresh Apte, Toral Mehta
Publisher | : Prentice Hall PTR
Pub Date | : December 23, 2002
ISBN | : 0-13-046457-0
Pages | : 448

Copyright
Hewlett-Packard® Professional Books
About Prentice Hall Professional Technical Reference
About the FTP Site
List of Figures
List of Tables
Preface
Acknowledgments
Chapter 1. Introduction
 | Welcome to the Evolution
 | UDDI — A Powerful and Critical Element of Service-Based Ecosystems
 | Using this Book
 | Conventions
 | For More Information
Part I: Business Registries
 | Chapter 2. Business Registries
 |  | Section 2.1. Dynamics of the Vendor–Customer Relationship
 |  | Section 2.2. Improvements in Vendor Selection and Interaction
 |  | Section 2.3. Business Registries
 |  | Section 2.4. A Business Registry Explained
 |  | Section 2.5. Challenges of Registry-Powered Business
 | Chapter 3. Web Services Overview
 |  | Section 3.1. A Service
 |  | Section 3.2. Web Service Technology Stack
 |  | Section 3.3. Web Service Platforms
 |  | Section 3.4. A Simple Web Service
 |  | Section 3.5. Document Exchange Model-Based Web Services
 |  | Section 3.6. Advanced Topics
 |  | Section 3.7. UDDI and the Web Services Paradigm
 | Chapter 4. Registries and Web Services Lifecycle
 |  | Section 4.1. A Web Services Ecosystem
 |  | Section 4.2. Web Services Lifecycle
 |  | Section 4.3. Registry-Powered Business-to-Business Interaction
Part II: Applied UDDI
 | Chapter 5. UDDI Overview
 |  | Section 5.1. UDDI Formation
 |  | Section 5.2. Public UDDI Sites
 |  | Section 5.3. UDDI Operators
 |  | Section 5.4. UDDI API Specification
 |  | Section 5.5. UDDI Best Practices
 |  | Section 5.6. Complete UDDI Ecosystem
 |  | Section 5.7. Language-Specific UDDI APIs
 | Chapter 6. Modeling for Registries
 |  | Section 6.1. Modeling in UDDI
 |  | Section 6.2. Modeling Service Providers
 |  | Section 6.3. Modeling Services
 |  | Section 6.4. Role of tModels
 |  | Section 6.5. Service Bindings
 |  | Section 6.6. Modeling Needs Beyond the Design Phase
 |  | Section 6.7. Modeling Service Consumers
 | Chapter 7. Establishing Connection
 |  | Section 7.1. Communication Points of a UDDI Registry
 |  | Section 7.2. Establishing Connection
 | Chapter 8. UDDI Publishing
 |  | Section 8.1. A Case in Point
 |  | Section 8.2. Publishing a Business Entity
 |  | Section 8.3. Publishing a Service Interaction Specification
 |  | Section 8.4. Publishing a Service
 |  | Section 8.5. Deleting from the Registry
 |  | Section 8.6. Putting It All Together
 |  | Section 8.7. UDDI Data Structures
 | Chapter 9. UDDI Inquiry
 |  | Section 9.1. Inquiry Process
 |  | Section 9.2. FITSO Revisited
 |  | Section 9.3. Discovering a Service Interaction Specification
 |  | Section 9.4. Discovering a Service
 |  | Section 9.5. Discovering a Business Entity
 |  | Section 9.6. Search Qualifiers
 |  | Section 9.7. Using Discovered Services
 | Chapter 10. Building UDDI Solutions
 |  | Section 10.1. Private Registry
 |  | Section 10.2. Referencing Caching
 |  | Section 10.3. Taxonomies and Identifier Systems
 |  | Section 10.4. Versioning and Migration Policies
 |  | Section 10.5. Registry Usage Models
Part III: Case Studies
 | Chapter 11. Employee Portal Unfolded
 |  | Section 11.1. Corporate Employee Ecosystem
 |  | Section 11.2. Technology Quilt
 |  | Section 11.3. Modeling Business Entities
 |  | Section 11.4. Defining Categories and Interactions
 |  | Section 11.5. Final Analysis
 | Chapter 12. UDDI in B2B and B2C Scenarios
 |  | Section 12.1. Extended Supply Chains
 |  | Section 12.2. RFQ Basics
 |  | Section 12.3. RFQ Business Process Flow
 |  | Section 12.4. RFQ Processing for AmCAR, Inc.
 |  | Section 12.5. The AmCAR Procurement Ecosystem
 |  | Section 12.6. Extending the Solution
 |  | Section 12.7. Location-Based Mobile Services
Part IV: Expanding UDDI
 | Chapter 13. Competitive Landscape
 |  | Section 13.1. Recognized Leaders
 |  | Section 13.2. Strong Industry Participants
 |  | Section 13.3. Registry Technologies
 | Chapter 14. Version 3 and Beyond
 |  | Section 14.1. Registry Interaction
 |  | Section 14.2. API Enhancements
 |  | Section 14.3. Enhancements to Discovery
 |  | Section 14.4. Enhancements to Description
 |  | Section 14.5. Internationalization
 |  | Section 14.6. Security
 |  | Section 14.7. Policy
 |  | Section 14.8. OASIS
Part V: Appendixes
 | Appendix A. Client UDDI APIs
 |  | Section A.1. Publishing APIs
 |  | Section A.2. Inquiry APIs
 |  | Section A.3. Security APIs
 | Appendix B. Installing UDDI4J
 |  | Section B.1. Apache SOAP
 |  | Section B.2. Java Components
 |  | Section B.3. Configuring UDDI4J
 | Appendix C. UDDI Errors
 | Appendix D. UDDI .NET SDK
 | Appendix E. Setting Up DSN
 |  | Section E.1. Datasources
 | Appendix F. Database Wrapper Utility
 |  | Section F.1. Employee Contribution Database
 | Appendix G. Simple Object Access Protocol
 |  | Section G.1. SOAP Message Components
 |  | Section G.2. Attachments to SOAP Messages
 | Appendix H. WSDL
 |  | Section H.1. <definitions>
 |  | Section H.2. <service>
 |  | Section H.3. <types>
 |  | Section H.4. <message>
 |  | Section H.5. <operation>
 |  | Section H.6. <portType>
 |  | Section H.7. <binding>
 |  | Section H.8. <port>
Glossary
 | A
 | B
 | C
 | D
 | E
 | F
 | G
 | H
 | I
 | J
 | K
 | L
 | M
 | N
 | O
 | P
 | Q
 | R
 | S
 | T
 | U
 | V
 | W
 | X


Copyright

Library of Congress Cataloging-in-Publication Data

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

Credits

Editorial/production supervision: Wil Mara

Composition: Naresh Apte/Toral Mehta

Cover design director: Jerry Votta

Cover design: Nina Scuderi

Manufacturing buyer: Maura Zaldivar

Executive editors: Jill Harry/Mark Taub

Editorial assistant: Noreen Regina

Marketing manager: Kate Hargett

Publisher, Hewlett-Packard Books: Patricia Pekary

Acquisitions Editor, Hewlett-Packard Books: Walt Bruce

© 2003 by Hewlett-Packard Company

Published by Pearson Education

Publishing as Prentice Hall Professional Technical Reference

Upper Saddle River, New Jersey 07458

Prentice Hall books are widely used by corporations and government agencies for training, marketing, and resale.

For information regarding corporate and government bulk discounts, please contact: Corporate and Government Sales (800) 382-3419 or corpsales@pearsontechgroup.com.

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

All rights reserved. No part of this book may be reproduced, in any form or by any means, without permission in writing from the publisher.

Printed in the United States of America

10 9 8 7 6 5 4 3 2 1

Pearson Education LTD.

Pearson Education Australia PTY, Limited

Pearson Education Singapore, Pte. Ltd.

Pearson Education North Asia Ltd.

Pearson Education Canada, Ltd.

Pearson Educación de Mexico, S.A. de C.V.

Pearson Education — Japan

Pearson Education Malaysia, Pte. Ltd.

Dedication

To our parents, Anant & Nalini Apte and Deepak & Pratima Mehta.


Hewlett-Packard® Professional Books

Strategic Solution

Brans | Mobilize Your Enterprise: Achieving Competitive Advantage Through Wireless Technology
Caldwell | The Fast Track to Profit: An Insider's Guide to Exploiting the World's Best Internet Technologies
Carlson/Huck | Itanium Rising: Breaking Through Moore's Second Law of Computing Power
Fink | The Business and Economics of Linux and Open Source
Hayes-Roth/Amor | Radical Simplicity: Transforming Computers into Me-centric Appliances
Kincaid | Customer Relationship Management: Getting It Right!

HP-UX

Fernandez | Configuring CDE: The Common Desktop Environment
Madell | Disk and File Management Tasks on HP-UX
Olker | Optimizing NFS Performance: Tuning and Troubleshooting NFS on HP-UX Systems
Poniatowski | HP-UX 11i Virtual Partitions
Poniatowski | HP-UX 11i System Administration Handbook and Toolkit, Second Edition
Poniatowski | The HP-UX 11.x System Administration Handbook and Toolkit
Poniatowski | HP-UX 11.x System Administration "How To" Book
Poniatowski | HP-UX 10.x System Administration "How To" Book
Poniatowski | HP-UX System Administration Handbook and Toolkit
Poniatowski | Learning the HP-UX Operating System
Rehman | HP Certified: HP-UX System Administration
Sauers/Weygant | HP-UX Tuning and Performance: Concepts, Tools, and Methods
Weygant | Clusters for High Availability: A Primer of HP-UX Solutions, Second Edition
Wong | HP-UX 11i Security

UNIX, Linux, Windows, and MPE I/X

Diercks | MPE i/X System Administration Handbook
Mosberger | IA-64 Linux Kernel
Poniatowski | UNIX User's Handbook, Second Edition
Roberts | UNIX and Windows 2000 Interoperability Guide
Stone/Symons | UNIX Fault Management

Computer Architecture

Kane | PA-RISC 2.0 Architecture
Markstein | IA-64 and Elementary Functions

Networking/Communications

Blommers | Architecting Enterprise Solutions with UNIX Networking
Blommers | OpenView Network Node Manager
Blommers | Practical Planning for Network Growth
Brans | Mobilize Your Enterprise: Achieving Competitive Advantage Through Wireless Technology
Cook | Building Enterprise Information Architecture: Reengineering Information Systems
Lucke | Designing and Implementing Computer Workgroups
Lund | Integrating UNIX and PC Network Operating Systems

Security

Bruce | Security in Distributed Computing: Did You Lock the Door?
Pearson et al. | Trusted Computing Platforms: TCPA Technology in Context
Pipkin | Halting the Hacker, Second Edition
Pipkin | Information Security

Web/Internet Concepts and Programming

Amor | E-business (R)evolution, Second Edition
Apte/Mehta | UDDI: Building Registry-based Web Services Solutions
Apte/Mehta | Web Services: A Java Developer's Guide Using e-Speak
Greenberg | A Methodology for Developing and Deploying Internet and Intranet Solutions
Mowbrey/Werry | Online Communities: Commerce, Community Action, and the Virtual University
Tapadiya | .NET Programming

Other Programming

Blinn | Portable Shell Programming: An Extensive Collection of Bourne Shell Examples
Caruso | Power Programming in HP OpenView: Developing CMIS Applications
Chaudhri | Object Databases in Practice
Chew | The Java/C++ Cross Reference Handbook
Grady | Practical Software Metrics for Project Management and Process Improvement
Grady | Software Metrics: Establishing a Company-wide Program
Grady | Successful Software Process Improvement
Lewis | The Art and Science of Smalltalk
Lichtenbelt | Introduction to Volume Rendering
Mellquist | SNMP++: An Object-Oriented Approach to Developing Network Management Applications
Mikkelsen | Practical Software Configuration Management: The Latenight Developer's Handbook
Norton | Thread Time: The Multi-Threaded Programming Guide
Tapadiya | COM+ Programming
Yuan | Windows 2000 GDI Programming

Storage

Thornburgh | Fibre Channel for Mass Storage
Thornburgh/Schoenborn | Storage Area Networks
Todman | Designing Data Warehouses: Supporting Customer Relationship Management

IT/IS

Missbach/Hoffman

SAP Hardware Solutions: Servers, Storage, and Networks for mySAP.com

Image Processing

Crane | A Simplified Approach to Image Processing: Classical and Modern Techniques in C
Day | The Color Scanning Handbook: Your Guide to Hewlett-Packard Scanjet Color Scanners
Gann | Desktop Scanners: Image Quality Evaluation


About Prentice Hall Professional Technical Reference

With origins reaching back to the industry's first computer science publishing program in the 1960s, Prentice Hall Professional Technical Reference (PH PTR) has developed into the leading provider of technical books in the world today. Formally launched as its own imprint in 1986, our editors now publish over 200 books annually, authored by leaders in the fields of computing, engineering, and business.

Our roots are firmly planted in the soil that gave rise to the technological revolution. Our bookshelf contains many of the industry's computing and engineering classics: Kernighan and Ritchie's C Programming Language, Nemeth's UNIX System Administration Handbook, Horstmann's Core Java, and Johnson's High-Speed Digital Design.

PH PTR acknowledges its auspicious beginnings while it looks to the future for inspiration. We continue to evolve and break new ground in publishing by providing today's professionals with tomorrow's solutions.


About the FTP Site

The discussion in the book is supported by code for working examples that explains and demonstrates each concept. An Online Extras FTP site has been set up at Prentice Hall for this book. This FTP site includes all the code, databases, and tools for running the examples described. The address for this FTP site is http://www.phptr.com/apte/.

The working directory on the FTP site for each example is located on each chapter title page under the section headings. This will help you navigate through the FTP site. The shared and datasources directories provide additional tools and databases used in the examples.

Please contact the authors at http://www.insidewebservices.com if you run into any problems accessing the FTP site.


List of Figures

2.1 Vendor discovery process.

2.2 Finding cement vendors.

2.3 Summit of customers and their vendors.

3.1 A service.

3.2 A Web service.

3.3 Web services technology stack.

3.4 .NET technology stack.

3.5 Emp401k Architecture.

3.6 Emp401kService WSDL.

3.7 Starting Emp401kClient.

3.8 Result of invoking getFundList() from Emp401kClient.

3.9 Start a new Web service project in Visual Studio .NET.

3.10 Creating the new Web service in Visual Studio .NET.

3.11 Setting Web sharing properties on your Web service directory.

3.12 Browser-based client for a .NET Web service.

3.13 WSDL for Emp401kDOTNET.

3.14 A method page for Emp401kDOTNET.

3.15 Invoking getFundList() method of Emp401kDOTNET.

3.16 XML document embedded in a SOAP message.

3.17 XML documents as attachments to a SOAP message.

4.1 Web services ecosystem.

4.2 Introducing the ecosystem players.

4.3 Relationships of ecosystem players.

4.4 The complete ecosystem.

4.5 Service lifecycle.

4.6 Steps in service deployment.

4.7 Registry as an intermediary.

4.8 Relationship between higher- and lower-level services.

5.1 User registration with Microsoft UBR.

5.2 Adding a business with Microsoft UBR.

5.3 Successful addition of a business with Microsoft UBR.

5.4 Finding a business with Microsoft UBR.

5.5 Successful search of a business with Microsoft UBR.

5.6 Details for a registered business.

5.7 Adding service to a business entity.

5.8 Successful search of a service with Microsoft UBR.

5.9 Adding binding to a service.

5.10 Successful addition of service binding.

5.11 The Microsoft Corporation business entity.

5.12 UDDI ecosystem.

5.13 Language-specific API and UDDI API relationship.

6.1 Modeling in a registry paradigm.

6.2 Responsibilities of a service provider.

6.3 Relationship between a legal and UDDI-registered business entity.

6.4 Decision points for service registration.

6.5 Connecting business entities through publisher assertions.

6.6 High-level service provider model.

6.7 Responsibilities of a service consumer.

6.8 Reference importing by a service consumer.

7.1 Interaction patterns demonstrated through examples.

7.2 UDDI interactions supported on publish URL.

7.3 UDDI interactions supported on inquiry URL.

7.4 Test publisher URL results.

7.5 Test inquiry URL results.

7.6 Successful completion of GettingStarted.

8.1 Business entity registration for Prudentially 401(k), Inc.

8.2 Successful registration of Prudentially 401(k), Inc. business entity.

8.3 Registration of FITSO tModel for 401(k) information services.

8.4 Binding information for service.

8.5 Successful service publication.

8.6 Deleting a service.

8.7 Summary of published resources.

9.1 Inquiry structure in the UDDI registry.

9.2 Ecosystem-based inquiry.

9.3 Business entity-based inquiry.

9.4 Broad-based search results for searching for FITSO tModel.

9.5 Results for searching for FITSO tModel.

9.6 Results of service search.

9.7 Inquiry structure in the UDDI registry.

10.1 Reference importing.

10.2 Reference exporting.

10.3 UDDI Registry as UBR.

10.4 UDDI as a market exchange.

10.5 Reference caching.

10.6 UDDI as a portal facilitator.

10.7 UDDI as EAI and B2B facilitator.

11.1 Corporate employee ecosystem.

11.2 Business-entity level modeling for the Employee Ecosystem UDDI Registry.

12.1 General RFQ process flow.

12.2 AmCAR Parts Procurement ecosystem.

12.3 Architecture of the AmCAR Procurement ecosystem.

12.4 Dimensions of mobile device features.

12.5 The Mobile Printing ecosystem.

14.1 Monolithic registry cloud.

14.2 Network of UDDI registries.

14.3 Entity promotion.

14.4 Creating derived categories.

14.5 Access type values.

14.6 UDDI Policies.

E.1 ODBC Start panel.

E.2 Choosing the ODBC driver.

E.3 Attributing a DSN to a database.


List of Tables

2.1 Bringing Together Buyers and Sellers

5.1 Comparison Between NOM and DEM Programming Models

5.2 White, Yellow, and Green Pages in Perspective

6.1 Data Elements Associated with a UDDI-Registered Business Entity

6.2 Data Elements Associated with a Service

6.3 Data Elements Associated with a tModel

6.4 Data Elements Associated with a Service Binding

8.1 FITSO Compliance-Based Prudentially 401(k), Inc. Modeling

8.2 UDDI-Supported URL Types

9.1 FITSO Compliance-Based Prudentially 401(k) Modeling

9.2 Search Qualifiers for Find and Get APIs

10.1 tModel Types Defined in UDDI Types Taxonomy.

12.1 RFQ Terminology tModel

14.1 Recommended Security Mechanisms for UDDI APIs

F.1 Schema for Table EmpTable

F.2 Sample Entry for Table EmpTable

F.3 Schema for Table FundTable

F.4 Sample Entry for Table FundTable

F.5 Schema for Table EmpContrib

F.6 Sample Entry for Table EmpContrib


Preface

In the next generation of the Web, services rather than the computers themselves, form the foundational blocks of the Internet. At the center of this "web of services" or more simply, Web services, are business registries. Business registries are the meeting point between Web service users, Web service providers, and Web service deployers.

To us, it is a unique experience to be part of this burgeoning technology paradigm. Having been involved from the beginning with our work on HP's E-speak initiative, we have had the honor of participating in the Web services play, right from Act One, if you will. We have had the fortune to not only help develop and bring Web service technologies to market but also to help deploy Web service solutions with customers.

Business registries are a cornerstone of the Web services phenomenon. Both the deployment of business registries and the development of Web services need to be explained and fostered to achieve the "web of services" vision. To ensure the easy registration and discovery of Web services, consortiums are being formed to standardize the processes of describing and registering services. The Universal Definition Description Integration (UDDI) group and ebXML Business Registries are just two examples of major XML-based business registry initiatives.

Believing in the paradigm's promise to make businesses work more smoothly together despite corporate and technology boundaries, it makes sense to us to help share the vision and value with those just beginning their Web services journey. Writing our second Web services-focused book on UDDI was a natural choice for us as it is an aspect of the Web Services paradigm that has not been explained as comprehensively ever before. In this book, we examine business registries in detail by discussing the value proposition and explain the technology for registering and discovering Web services through a series of examples and case studies.

We hope this book provides you the knowledge to fit business registries, and more specifically UDDI, in your Web services solutions because business registries are expected to play a pivotal role in the next Chapter of the Internet.

Naresh Apte | Toral Mehta
Sunnyvale, CA | Sunnyvale, CA
October 2002 | October 2002


Acknowledgments

Producing a book is truly a team effort. We want to take a moment to acknowledge our team members because without their time, effort, and support, this book would not have become a reality.

We would like to thank former HP employee and colleague, Andrew Nielsen (who loves his wife Deb). Andrew provided a thorough technical review of our content. He was a natural choice for us since he spent over two years working in the Hewlett-Packard UDDI initiative representing the company on the UDDI.org project team.

Special thanks go to our publishing team. As with the first book, they guided us through the process with patience and understanding. We want to thank Jill Harry (Prentice Hall Acquisitions Editor), Mark Taub (Prentice Hall), William Mara (Production Editor), Walt Bruce (HP Press), and Pat Pekary (HP Press) for their support and guidance throughout the development and publication of our second book.

We also want to thank Bob Bickel (Executive Sponsor) and Jacek Walicki (Champion) for their encouragement and sponsorship. We also hold a deep gratitude to our families and friends for helping sustain the fire and passion that is needed to complete a project of this size.

Finally, creativity in any form, whether it be music, painting, poetry, or writing, to name a few, needs an audience. We want to thank our readers for taking the Web services journey with us.


Chapter 1. Introduction

It is not surprising that one of the most quoted business writers today is Charles Darwin. In the field of business-to-business e-commerce and, most recently, mobile commerce, evolution is not simply a metaphor; it is a reality. Many businesses have failed to meet expectations or simply failed because they could not adapt their existing products and services to a new, more dynamic Internet environment. As IT departments are viewed more and more favorably as business differentiators, compared with cost-of-sales, it behooves business application developers to turn current IT assets into collections of Web services that take full advantage of the speed, flexibility, and instant global reach of the Internet.

A number of obstacles exist, however, in achieving a services-based business model. Currently, a typical business-to-business transaction involves:

  • Multiple standards: One of the reasons this transaction is so time-consuming is that there is no common standard for presenting and negotiating information. Each company uses a different method for pricing its products, establishing delivery times, and negotiating contracts. The lack of standards makes it difficult to automate such processes.

  • Entrenched processes and services: Business transactions that require a great deal of human intervention are difficult to maintain and evolve. Changes in prices, products, and deadlines can mean starting negotiations from square one. Simply trying to fine-tune human processes to meet changing needs is a short-term and costly solution.

  • Lack of an online directory: There are number of Web site search engines and listings; however, there is no global and well-populated depot to search for Web services that fit a company's business needs. Universal Description Discovery and Integration (UDDI) technology has the promise to address this issue, as we will see in this book.

  • Static, point-to-point negotiating: The business processes around partner, vendor, and customer interactions today are ad hoc and need to be adjusted for each entity. For example, suppose that a printing company wants to buy a large quantity of paper. The procurement department uses personal contacts, industry directories, and so on, to develop a list of potential suppliers. They contact each supplier separately, describe their needs, and solicit proposals. Typically, after some negotiation, the printing company finds a supplier and buys its paper. Once developed, this process is not guaranteed to work subsequently for purchasing of same or different product.

In summary, if we look at these characteristics of a typical business transaction, none of them even remotely take advantage of the speed, flexibility, and openness of the Internet. The problem is even more acute in the mobile space in which the operating environment is not yet mature. In the mobile environment, even the basic communication technology is also not standardized across the world. The problem becomes finding a relatively quick and economical way to adapt current business processes to a new paradigm. In the world of services, the ability of different resources to interact with each other is at the core of the new world order. This interaction is based on standards and is driven by dynamism made possible by the network that connects these services together.


Welcome to the Evolution

Service-based interaction provides a different way of transacting business "over the Web." In this case, the resources providing a service need not have prior knowledge of each other's existence and can adapt to the ever-changing landscape of services. In many ways, the services behave like human beings or the companies they represent except that the services operate in a digital world. Some of the benefits that the service-based solutions bring are:

  • Open and standards-based solutions: This level of speed and automation is possible because the businesses can easily wrap their current services through standardized interactions. Businesses in this environment communicate with each other using a standard grammar.

  • Flexible, constantly evolving "services": The end result is that businesses can locate and use services much more easily. These services become genuine Web services, as flexible and adaptable as the Internet itself. This can even be used to create complex services — a collection of simple individual services brought together just in time to meet a particular need. We look at the Web services paradigm more closely in Chapter 3.

  • Dynamic, automated partnering and negotiating: By eliminating or reducing human intervention, a business can locate partners and negotiate with them much more quickly.

As always, the problem does not end at the idea but at the implementation or solution. At the heart of service-based computing is a Web services directory that facilitates and mediates between service publishers and service consumers. This book introduces UDDI and provides insight on how to incorporate UDDI into your Web service solutions.


UDDI — A Powerful and Critical Element of Service-Based Ecosystems

The Universal Description, Discovery, and Integration (UDDI) project is an industrywide project and initiative that provides open and standard specifications for key Web service ecosystem activities:

  • Describing services

  • Discovering businesses and services

  • Incorporating services into Web service solutions

  • Creating and deploying an XML-based registry

At the heart of a Web services ecosystem, UDDI registries are platform agnostic and can interact with businesses and services deployed on a variety of platforms. UDDI is a critical part of the Web services technology stack and is based on tried and tested industry standards such as

  • World Wide Web Consortium (W3C)

  • Internet Engineering Task Force (IETF) standards such as Extensible Markup Language (XML), and HTTP and Domain Name System (DNS) protocols.

Additionally, platform- and language-agnostic qualities are enhanced by using the Simple Object Access Protocol (SOAP). Not only is UDDI platform- and language-agnostic, but its generic nature positions it well within any industry and corporate ecosystem, thus making it industry-agnostic as well.

UDDI acts as the meeting place of industry/ecosystem stewards, service consumers, and service publishers. The forum allows electronic business models of each party to exist within the registry architecture and act on their behalf — thus facilitating electronic decision-making. Through the implementation and interaction with UDDI, it is easy for businesses to collaborate with each other.

UDDI enables businesses to establish many-to-many business relationships, provides the flexibility to add new members quickly and easily, provides a single interface, and enables applications to be treated as services. It enables companies to extend their business-to-business (B2B) or business-to-consumer (B2C) offerings to create ecosystems of services quickly and easily. Organizations such as ecosystem creators, IT departments involved in supply chain initiatives, and software developers and system integrators creating solutions for businesses can use this software to fulfill their needs better, compared with conventional methods.

This book discusses both the services-based ecosystem vision and the UDDI software that helps in implementing that vision. The UDDI specifications are available via the http://www.uddi.org/ project web site.

Several companies, including heavy weights such as Microsoft, IBM, and Oracle, as well as smaller Web service pioneers such as Systinet provide UDDI-compatible software. As is common with emerging technologies, much of the work on these initiatives will eventually converge into a common standard that is adopted industry-wide. To that end, UDDI has been submitted recently to Organization for the Ad-vancement of Structured Information Standards (OASIS) for further work and enhancement.


Using this Book

This book is designed to get you using UDDI quickly and easily. By the end of this book, we hope to have provided a thoughtful understanding of the UDDI initiative, its place in Web service architecture, and the ability to develop your own UDDI-based solutions. In general, each chapter has two parts — one that provides a conceptual framework for some service feature and another that provides a code-level example of implementation within the UDDI paradigm. While the second part is aimed at the developers, the first part would be useful for developers as well as business and technical managers. The managers can use this discussion as a gauge to test the readiness of the existing systems, as well as new ones under development, for participating in service-based architectures and economies. Although the service-based environment is not prevalent yet, it will soon be a reality with industry giants such as Microsoft, IBM, and BEA rallying behind it. Thus, it is essential to assess the readiness of the current and future application landscape for an organization. An extensive background in the Web services paradigm is not necessary in using this book. However, for the code-level discussion, basic understanding of C#, Java, and distributed computing is recommended.

The discussion in the book is supported by code for working examples that explains and demonstrates the concept well. Each chapter builds on the one before, so that, by the end of the book, you have gone through the entire process of interacting with a registry, from modeling your business to participate in an UDDI-based registry to exporting UDDI entries to a private registry. We have chosen the employee portal solution as our primary example; however, you will find the concepts in the book easily applicable to your own projects. The FTP site includes all the source code in the book. This FTP site can be reached directly or from http://www.insidewebservices.com. The book also includes case studies that provide step-by-step design for the solutions. A chapter each is also devoted to competitive analysis and to discussion of the future direction of the registry technology.

The book has the following chapters.

Chapter 2, "Business Registries," introduces and explains the concept of registries. The discussion includes the role of registries in improving business interactions.

Chapter 3, "Web Services Overview," explains the foundational technologies of the Web services stack as well as introduces some advanced topics including Web services scalability and security. It teaches you basic programming techniques to develop Web services.

Chapter 4, "Registries and Web Services Lifecycle," expands on the role of registries within the Web services ecosystem and Web services lifecycle. Includes a discussion on the registry as an intermediary in business-to-business interactions.

Chapter 5, "UDDI Overview," provides a detailed description of the UDDI initiative including the UDDI Operators, Application Programming Interfaces (APIs), and the language-specific APIs for interacting with a UDDI registry. It also provides best practices developed as part of the initiative.

Chapter 6, "Modeling For Registries," shows how service publisher and consumer entities should be modeled for participation in a registry-based paradigm. It introduces the UDDI concepts of service bindings and tModels for representing service interaction specifications and classification schemes.

Chapter 7, "Establishing Connection," explains how to establish connection with the communication points of a UDDI registry. It introduces the UDDI Publish and Inquiry APIs and usage of both UDDI .NET SDK APIs as well as the UDDI4J APIs.

Chapter 8, "UDDI Publishing," explains how to design applications to use both the UDDI .NET SDK APIs as well as the UDDI4J APIs for publishing to a UDDI registry. It includes a detailed discussion on the process of publishing for a service publisher.

Chapter 9, "UDDI Inquiry," explains how to design applications to use both the UDDI .NET SDK APIs as well as the UDDI4J APIs for inquiring a UDDI registry. It includes detailed discussion on the process of inquiring for a service consumer.

Chapter 10, "Building UDDI Solutions," discusses several advanced topics including security, private registries, versioning, internationalization, validation of business modeling, and others. It prepares the reader for including UDDI in an advanced solution.

Chapter 11, "Employee Portal Unfolded," illustrates the role of a UDDI registry in an employee portal especially highlighting the role of the ecosystem governor and the modeling of business entities.

Chapter 12, "UDDI in B2B and B2C Scenarios," explains the role of a UDDI registry in a Car Manufacturer's Ecosystem and a Location-based Mobile Ecosystem especially highlighting the interactions among various entities within the ecosystems.

Chapter 13, "Competitive Landscape," looks at the competitive landscape in the business registry space. It also includes discussion on ebXML Business Registries.

Chapter 14, "Version 3 and Beyond," discusses the direction the UDDI Specification is taking with its release of Version 3.

In addition, we have also included several appendices that help in running the examples or expand on certain concepts. A glossary at the end also provides a quick reference for many of the terms used in the book. The index provides an easy reference to relevant terms.


Conventions

Throughout the book, we have used different types of fonts to indicate different types of information:

  • Code segments, classes, methods, and variables use this font. The code segments are also indented so that they stand out from rest of the text. Each code segment is also associated with a file name to indicate the file to which the code belongs. This should help in locating the relevant code snippet at the FTP site.

  • New terms or UDDI-specific words are in this form. This denotes a new term or an emphasis on some word.

  • File names are in this font. Different types of files used in this book include class files, data files, and configuration files. The file names are used throughout the text and in particular in a code segment.

Examples are included and discussed in many of the chapters. The FTP site includes the code associated with these examples. The working directory on the FTP site for each example is located on the chapter title page for each chapter under the section headings. Each of the examples provides a complete business situation and design and solution for that situation.

We have also used "Note" sections in the book to emphasize a related point in a discussion. These notes provide information that is useful to the discussion in which they appear but are not directly related to it. The notes include information such as industry anecdotes, history, a specific UDDI feature, or "gotchas." An example of a note is below:

Note

This is an example of a note. Notes highlight a point that is related to the text around them.


For More Information

After reading this book, you may want to get some more information about the book in particular or about the UDDI technology and its evolution. We would also like your comments and suggestions. Your feedback will be valuable for us to improve future editions of this book, as well as other works. Suggestions specific to the UDDI platform are also welcome. We will communicate those to the UDDI team in the OASIS standards committee. Visit http://www.insidewebservices.com to get more information about the book or to reach the authors. This Web site can also be used to connect to the FTP site where code for the examples used in the book is located. In addition, we have set up a community at Yahoo! Groups called uddibook. Feel free to join this group to participate in an open discussion about UDDI and this book.

You can visit the UDDI information pages at the following web sites to download software, the specifications, or get more information:

  • http://www.uddi.org

  • http://uddi.ibm.com

  • http://uddi.microsoft.com

Note

The examples demonstrated in this book may not be visible or accessible in the test Microsoft universal business registry at the time of publication.

We enjoyed working on this book and hope that you find it useful in a journey toward a service-based business environment of the future. To know more about it, let's enter the world of UDDI-powered Web services.


Part I: Business Registries

In this Part

Chapter 2: Business Registries

Chapter 3: Web Services Overview

Chapter 4: Registries and Web Services Lifecycle


Chapter 2. Business Registries

  • Dynamics of the Vendor–Customer Relationship

  • Improvements in Vendor Selection and Interaction

  • Business Registries

  • A Business Registry Explained

  • Challenges of Registry-Powered Business

Explaining business registries and their place within a company's ecosystem requires a discussion on how a company engages with another company to fulfill its needs. [1] These engagements, collectively called business-to-business (B2B) relationships, are fundamental to a company's existence. Improvements made to business practices associated with B2B relationships invariably result in higher productivity and increased competitiveness.

[1] An ecosystem of a company consists of its partners, vendors, customers, and the regulatory environment.

Several technologies have emerged to facilitate these B2B relationships in an effective manner. These technologies bring business partners together electronically. For example, it is very common for companies to place electronic orders with their vendors. However, despite these advancements, there continue to be sources of inefficiencies within business relationships. The latest evolution in technology, Web services, addresses these inefficiencies and promises to provide seamless and efficient interaction within an ecosystem.


2.1 Dynamics of the Vendor–Customer Relationship

Finding businesses or service providers that meet a company's needs is at the heart of its efficiency and success. Interacting with that network of vendors is an even more important process. Efficient and effective interactions within the company's vendor network are again another critical success factor for any enterprise.

What follows is a fairly comprehensive explanation of vendor-customer scenario— including the role of technology in making this process more efficient. This scenario is the core example for a large part of the book and also is detailed further with respect to UDDI in one of the case studies and hence it is important to have this context as a background.

2.1.1 Discovering Vendors

Finding the ideal or close-to-ideal vendor is a less-than-perfect process that can result in entering into an adequate transaction rather than an ideal or desired transaction. A company will determine its requirements and then seek a business or service provider that matches those requirements within a certain acceptance range. However, the resources available to find an ideal or desirable entity are limited. There are various B2B methods, processes, and procedures that assist a company in procuring the resources required. Forging the vendor–customer relationship can be highly people-intensive at one extreme or can be fully automated at the other. The steps involved in building a B2B relationship include:

  1. Determining detailed requirements

  2. Seeking out a list of potential vendors or service providers

  3. Interacting with potential vendors or service providers to determine if there is an initial requirements match

  4. Negotiating contracts with qualified vendors and service providers

  5. Notifying other vendors and service providers of selection

This process can be very effort-intensive, especially when sourcing a new requirement. Each time a new requirement for raw material, services, or supplies arises, the process described earlier to establish B2B relationships ensues. As a result, many companies create specially skilled and dedicated teams, positions, or roles to develop and manage vendor relationships. Often, these roles are called business planners.

Figure 2.1 depicts the iterative nature of this process. The business planner is generally responsible for managing this process. Of course, the business planner must take into account not only the requirements to be filled but also the interest, influence, and constraints of the enterprise. These are the guidelines that help the business planner through this process. Influence could be factors such as special discounts available from certain vendors. Interest could be factors such as a long running history with a vendor. Finally, constraints are factors such as a requirement that a vendor must not have a relationship with a competitor. Within this decision space, the business planner must find a vendor to meet the basic requirements. Each iteration of this process results in a list of potential vendors that must be investigated and perhaps negotiated with. Steps 4 and 5 will always remain people-intensive, because technology cannot replace trust-built relationships. In this chapter, we demonstrate how automating earlier steps can result in a more efficient way to search for the right vendor or service provider.

Figure 2.1. Vendor discovery process.

Consider a business planner, Jeff, at ConstructNow. ConstructNow is a global construction giant based in San Francisco. Jeff is responsible for sourcing cement, among other construction materials, for ConstructNow. He has the contacts and processes quite streamlined for efficiency. However, ConstructNow has won a major government contract to build a military installation. This military installation needs a different grade of cement — military-grade. Military-grade cement has greater heat resistance versus the regular industry-grade version. An expert at sourcing industry-grade cement, Jeff realizes he will have to spend a significant amount of time and effort to find the most synergistic source.

Hit and Miss

In this example, ConstructNow is faced with increased demand. Having negotiated cement contracts at the start of the quarter, ConstructNow needs to make arrangements for additional cement to proceed with the nonplanned construction contracts. However, Jeff wants to ensure the extra cement is available at a reasonable price and quality prior to accepting the contracts. Of course, the time available to Jeff is limited and he needs to secure the extra cement within a week. ConstructNow's first tier vendors are unable to satisfy the extra demand.

Like most companies, ConstructNow has categorized its vendors into three tiers. The first tier vendors usually are the preferred vendors because of previously negotiated prices and quality. First tier vendors are vendors that a company prefers to interact with because the right understanding of each other's business processes and electronic connectivity already exists. Second and third vendors are vendors that can fulfill demand; however, this usually is accompanied by compromise on several parameters, such as time of delivery, price, and quality. They are generally not as electronically connected with the company as first tier vendors. Naturally, there will be several "unaffiliated" vendors that a company rarely does business with.

Second and third tier vendors may not always provide exactly what ConstructNow needs, but can be alternatives to fulfill impromptu and important demands. After several phone calls to second and third tier vendors looking for the additional cement supply, Jeff finally negotiates the desired quantity. However, the eventual supplier, CementEtc, has not always delivered cement on time and also charges an extra service fee for rush orders. The less-than-perfect process, as explained earlier, results in a transaction for ConstructNow that was adequate but not ideal. These tiers are depicted in Figure 2.2.

Figure 2.2. Finding cement vendors.

The less-than-perfect process for matching requirements with business or service providers may result in paying an "unwarranted" higher price or perhaps settling on the quality obtained. In our example, additional effort by Jeff may have resulted in finding the ideal vendor but, for all practical purposes, Jeff needs to make a decision in a time-bound fashion forcing him to accept adequate terms.

An analysis of the situation shows that seeking out vendors manually is an inefficient procedure. It is:

  • Time consuming

  • Hit-and-miss

  • Potentially cost ineffective

  • Forcing compromise

  • Based on a limited vendor network

Once a vendor is found and selected, the next challenge is to determine the best way to interact with it.

2.1.2 Interacting with the Vendor Network

As a company transacts with its vendor network, there are still more obstacles to smoothen. If we examine the established vendor network closely, we see that there are vendors with whom enterprises interact electronically, semi-electronically, and manually. A spectrum of processes, procedures, and technologies support these varying levels of interaction mechanisms. Each vendor has an access point that the enterprise uses to interact with it. This could be as simple as a phone number to a single point of contact or as complex as an electronic access point that a packet of specially formatted data is sent to. Organizing, cataloging, and sharing these access points becomes a process in itself. In addition, knowing how to interact with all the vendors of an enterprise can be a monumental task as well. Cataloging such access points is generally a company-specific, and potentially fragile, process.

The absence of a strong cataloging process results in several problems. First, business planners could have a difficult time in determining the point of contact within a vendor's organization. This would require an extra amount of effort to navigate the organization of the vendor to find the appropriate person. Secondly, this problem is exacerbated when a company is trying to escalate within the vendor network. It is critical to know and capture the escalation path to invoke when a problem arises. During the course of history developed with the vendor network, a strong cataloging process could capture the efficient interaction mechanisms. For example, a company could catalog whether it is best to send a Purchase Order via email or use the online order Web site. This organizational learning could help increase the efficiency in interacting with vendors.

Interacting with vendors also involves incorporating them into the process flow of a company. For effective interactions between a company and a vendor (from its vendor network), the process flows need to "blend" together within both organizations. For example, if a company's purchasing business process dictates that payment be made in 45 days, then a vendor's collections process should not trigger "past-due" notices after 30 days. In a well-blended process, the payment terms would be the same — at least between the two concerned parties.


2.2 Improvements in Vendor Selection and Interaction

Several processes, procedures, and supporting technologies have emerged over time to assist business planners in discovering vendors that meet or exceed their selection criteria and in interacting with the discovered vendors.

2.2.1 Request for Proposal

One common procedure in the business world is to outline the requirements in an "invitation" and make it available to potential suppliers, vendors, and service providers. Such an invitation is called a Request for Proposal (RFP). Amidst the vast amount of information available on the RFPs, noteworthy is the level of complexity or simplicity possible in structuring RFPs. RFPs generally provide detailed and specific terms that assist vendors in preparing their responses.

RFPs provide companies a reprieve from scanning the entire market for a suitable vendor. RFPs put the onus on potential vendors to respond to a need. If "published" in a very visible and accessible manner, RFPs can actually bring attention to potential vendors — especially those that may not have been on the radar of the business planner. It also provides an efficient mechanism to share the detailed requirements; the efficiency results from the idea that vendors can review requirements and determine whether responding is beneficial or not. However, this is still a very manual process that limits the vendor reach to those that "see" the RFP. It is important to note that RFPs are free-formatted.

The simplest version of an RFP could be a Web page form with an email address. This is cost-effective and can significantly increase the reach to potential vendors. Looking at RFPs from the point of view of a potential vendor, we see a significant drawback. Several RFPs may describe requirements in a variety of ways. Because of limited resources, vendors need to not only evaluate each RFP on its own merits, but also in comparison to others and determine response. This laxity requires potential vendors to thoroughly analyze each RFP very closely to determine whether to respond or not. Finally, RFPs are effective in bringing together customers and potential vendors but do not provide support for subsequent intercompany transactions.

2.2.2 Request for Quote

Another process that has evolved is the ability of a customer to request a potential vendor to submit a quote (the amount of resources required to complete a task). This is known as a Request for Quote (RFQ). While an RFP is an invitation to vendors to respond, an RFQ is an entry point provided by vendors to allow potential customers to "request" a quote for products or services.

RFQs, like RFPs, can be a very cost-effective way to reach a "cognizant" audience. However, the onus is still on the customer to compile a list of potential vendors. We learned in Section 2.1 that this is an iterative process fraught with inefficiencies and is very time-consuming. Again, a well-placed RFQ can assist a vendor in drawing attention to itself, helping those business planners in their search for an ideal vendor.

2.2.3 Electronic Data Interchange

Electronic Data Interchange (EDI) is a standard format for exchanging business information over an electronic network. Specially formatted electronic messages are used to represent business information, such as price, product number, and so forth. A company and its vendors may deploy an EDI network to exchange business information that reduces the need for manual intervention once the initial relationship and contract are in place. Parties who exchange EDI transmissions are referred to as trading partners.

Unlike RFPs and RFQs, EDI networks do not relieve business planners from the pain of discovering ideal vendors. In fact, EDI networks are only deployed among trading partners limiting the customer's vendor reach. The efficiency gained from EDI networks is really in the interaction and transactionality. Because transactions are broken down into information exchanges, preformatted information can be shared to transact business with minimal human intervention. However, these EDI networks are very expensive to deploy, maintain, and support and thus are limited in their potential because many smaller vendors may not participate.

2.2.4 E-Marketplaces

E-marketplaces are a phenomenon of the Internet and of the desire to make finding the right partner more efficient. An e-marketplace is a generic term that represents the installation of various Internet technologies between vendors and customers. E-marketplaces are found in two major flavors: consortium-run and privately-run.

Consortium-Run E-Marketplaces

A consortium is a group of interested parties that work together to develop a specification for a certain task. Consortiums typically are a group of partners, competitors, common-interest parties, or legislative bodies. This group determines certain guidelines, rules of engagement, maybe even interaction patterns and quality-of-service levels for a certain industry or sector. The specification developed by a consortium is not necessarily binding to the members of the consortium, nor is a membership necessarily required to accept a specification. If the rules of engagement provided by a consortium are widely accepted, it becomes a standard. Consortiums can deal with any topic you might imagine. Some examples of consortiums are:

  • Consortiums of similar functions coming together to actualize economies of scale or to streamline their business process (for example, RosettaNet)

  • Consortiums trying to solve a certain societal problem

  • Consortiums of technology pioneers (for example, W3C or Universal Description, Discovery, and Integration [UDDI])

Participation in a consortium is generally open to any interested party and has limited entry criteria. You will notice that there are more restrictive marketplaces as well, such as private e-marketplaces.

Private E-Marketplaces

Private e-marketplaces are run by an entity or a group of entities and restrict participation. An example of this could be a car manufacturer that deploys an e-marketplace with many of its vendors to facilitate better interaction. In this case, the main entity or entities generally enforce policies and procedures that may or not be mutually agreed upon and participation would require adherence to the described rules of engagement.

Generally, e-marketplaces (especially privately-run ones) focus on a particular vertical market. For example, the transportation and logistics industry has over one hundred e-marketplaces. Of course, the focus of these marketplaces is essentially to help buyers and sellers come together. Hence, the engines of these marketplaces usually provide auctioning capability, online catalogs, or to a smaller extent, collaboration facilities. However, e-marketplaces tend to be hard-wired together with proprietary or nonstandard technology and require high level consulting services. A functioning marketplace can be a very efficient means of procuring resources. However, the "entrance fee" might pose a cost-barrier for some vendors and make it impossible to form spot relationships. Lightweight e-marketplaces could be deployed as well. These e-marketplaces are more of an information repository and less of a transaction environment; for example, they may store a catalog of product information.

RosettaNet is an organization that works toward developing standards to assist companies in transacting business. Like EDI, RosettaNet attempts to remove some of the inefficiencies in B2B transactions. Dictionaries of these standards provide information on the process as well as an electronic representation of it. These standards can be thought of as a recipe for business transactions. E-marketplaces that implement and support RosettaNet standards are known to be RosettaNet-compliant and are one step closer to open B2B interactions. Again, like EDI and privately-run e-marketplaces, RosettaNet infrastructures generally do not expand a customer's vendor reach. Noteworthy is the fact that incorporating RosettaNet-compliant vendors into a RosettaNet-compliant company could be fairly straightforward because of the standards-based approach.

2.2.5 The Analysis

A disadvantage of all the present technologies and processes described earlier, is that there is no central location to go to and identify potential vendors or service providers to fulfill a company's needs. Relying on a Web site that holds an RFP or RFQ process, is still very hit-and-miss, as it assumes that a potential vendor or service provider is actively monitoring that location. This also raises the issue of dependency on a manual search process. The importance of human interaction cannot be fully replaced by any technology construct; however, these technologies can help to concentrate human involvement to a later stage in the process — a stage when negotiations or commitment is required. The business planner can interact with a smaller subset of vendors, thereby saving time.

Another disadvantage is that many of these technologies require a heavy investment in time, resources, and training to set up. Thus, they cannot be employed for immediate or infrequent needs. For example, in most cases a company's EDI network will not reach out to the second and third tier vendors. In such cases, companies resort to manual processes for transacting business with these vendors. For example, Jeff would need to manually process purchase orders to send to CementEtc.

These processes, procedures, and technologies do not assist in consistently describing a vendor's offerings. For example, when looking through the telephone directory, Jeff could search for several cement providers before finding one that provides exactly the kind of cement that ConstructNow requires. Some cement providers may not have the required quality level. Predictable description frameworks help vendors describe themselves consistently. These frameworks offer businesses the ability to make an educated assessment and avoid an "apples to oranges" comparison. Without consistent descriptions, Jeff may find that cement can be procured at a very low price but only upon further discussion discovers that the heat resistance property is only industry-grade. You will recall that Jeff needs military-grade heat resistance for the government construction project. A structure to help companies describe their offerings in a consistent fashion could have avoided this confusion.

Table 2.1 summarizes the advancements in bringing together buyers and sellers. We compare these advancements on characteristics such as the degree of manual effort, implementation cost, and degree of vendor reach. Note that no one solution is the silver bullet for enterprises and business planners. Each advancement has its own strengths and weaknesses as each technology or process would. Despite the challenges described, it is important to note that various industries have adopted one or more of these processes and developed sophisticated technologies to support them. For example, for enterprises with information technology (IT) needs, the RFP framework has become an accepted way to invite system integrators and consulting services companies. These adopted processes are continuously evolving. Note that a combination of the aforementioned processes, procedures, and technologies can be used in conjunction with each other to deploy a framework that does increase the efficiency of customer-vendor interactions. Business registries are not meant to displace any of these adopted practices, but to provide an ability to collect services together intelligently, capturing some information around access points, interaction procedures, and escalations points to name a few.

Table 2.1. Bringing Together Buyers and Sellers

Attribute

RFP

RFQ

EDI

E-Marketplaces

Process owner

Customer

Vendor

Customer

Market owner

Degree of manual effort

High

High

Medium

Medium

Implementation cost

Varies based on complexity

Low

High

High

Degree of vendor reach

High

—

Low to medium

Medium

Vendor description consistency

Very low

Very low medium

Low to

Medium

Process change flexibility

High

High

Low to medium

Medium

Business registries are not only a phenomenon of these improvements, but also an effect of the latest technological innovation — Web services. A simple "Google" search on Web services results in a plethora of information about what they are, how they are used, and the technologies they are comprised of and so forth. Chapter 3 provides a brief overview on Web services. However, the working definition that we use throughout the book is:

Web Services: Web services are services or business assets (either electronic or human) that are made available via a company's infrastructure. Customers can access some Web services via peer-to-peer communication or via a central hub.

Web services are most notably known for their ability to be deployed using a variety of Internet standards.


2.3 Business Registries

Section 2.1 describes the structures that have emerged in response to the need to continuously improve an enterprises' ability to discover and engage vendors. While on one hand, Web services expose a company's offering and e-marketplaces and EDI networks improve intercompany interaction, on the other, the gap of knowing with whom to interact still exists. We still cannot necessarily find the optimal vendor. Business registries address this gap.

Business registries represent the summit of vendors and their customers as well as other interested parties, such as regulators. This summit or meeting place allows vendors a way to display their offerings and customers, to not only browse through the offerings but perhaps transact with the vendors as well. If we take a step back from the e-business world, this is analogous to telephone directories. Telephone directories provide customers a way to search for businesses and, conversely, provide businesses a way to present their availability to customers. Figure 2.3 depicts this relationship.

Figure 2.3. Summit of customers and their vendors.
    [ Team LiB ]


2.4 A Business Registry Explained

Business registries are repositories of information that facilitate discovery and interaction between customers and vendors. They can carry information about vendors' offerings as described previously. Vendors may represent their offerings as regular text descriptions or as electronic representations (for example, Web services).

2.4.1 An Employee Portal

Large enterprises provide employees with easy access to the employee service network. Many business to employee (B2E) technologies use standard Internet technologies to assist enterprises in presenting employees with all the information they need. One can probably think of many services that employees use during their employment history with a company. However, we present a partial list in this example to show the breadth of transactions that employees enter into.

  • Payroll

  • Insurance

  • 401(k) participation

  • Performance evaluations and development plans

  • Discount programs

  • Company news

  • Training programs

Enterprises continue to simplify access to such services for employees. Human Resource (HR) departments started off with an employee file that was essentially a manila folder with notes. Over time, employees could access HR experts' help via phone. The HR representatives would be able answer questions and interact with the employee files to resolve any issues. Eventually, the manila folders and hard copy forms were replaced with electronic documents (and scanned copies).

Employee portals based on Internet technologies are the latest advancement in this area. These portals are a set of Web pages and scripts that give employees access to information that resides on scanned files or in employee databases. They also provide services that allow employees to perform frequent transactions, such as recording vacation time. This collection of information and services could be considered a business registry. Today, most employee portals are browser-based. However, programmatic access to these services could remove the requirement of direct employee interaction in cases where it is not absolutely required. For example, employees may check the performance of their 401(k) portfolio either through browser-based or service-based programmatic interaction. Service-based programmatic interactions can bring the necessary information automatically to an employee, without manual effort. Moreover, other services can use this information for subsequent processing. For example, an employee's personal accounting software can obtain 401(k) data automatically and prepare a monthly financial performance report.

2.4.2 The Nuts and Bolts of a Registry

A business registry, regardless of whether it contains Web service entries or brick-and-mortar entries, is a platform where potential customers and vendors meet. It provides capabilities that assist a customer in finding the elusive ideal vendor. It also provides capabilities to assist a vendor in presenting and describing their offerings to potential customers. In essence, business registries can be any number of the following:

  • Discovery and browsing platform

  • Publishing platform

  • Registry or repository platform

  • Transaction platform

Business registries can be constructed to serve a select group of entities. Often, these are restricted and only entities that have met certain criteria can obtain access. The employee portal described previously is an example of a restricted registry. The notion of restricted registries leads us to different variations of registries that are characterized by access control levels.

Private Registries

Business registries that are highly restricted are known to be private. In general, private registries restrict the vendors that can describe their offerings as well as the potential customers that can discover or transact within the registry.

An employee portal is a private business registry that allows a company's employees to interact with select services. The services that are offered to the employees are brought into the registry after an out-of-band qualification, negotiation, and selection process. Out-of-band, in this case, refers to the fact that this process is likely to occur outside the private business registry platform.

Public Registries

Public registries are registries that are typically open for a general audience. Public registries usually require a simple registration process to allow vendors and customers to access it. They are, typically, situated in a widely accessible environment. Examples of public registries can be found in the consumer space; an online dentist registry that allows patients to discover the appropriate dentist would generally be public.

2.4.3 Conceptual Features of Registries

The features of a business registry primarily depend on its type. We mentioned that business registries can be discovery, publishing, and transactional platforms, but the degree to which a registry supports each of those broad categories of activities varies. Generally, there are some basic features that a rich registry technology must provide:

  • Register as a user (vendors and customers)

  • Register vendor descriptions

  • Register vendor services and offerings

  • Register vendor interaction guidelines

  • Browse vendors, services, offerings

  • Search for vendors, services, offerings

  • Authenticate and authorize users

  • Manage user information and registration data

Some registry technologies also provide a hub for interaction and act as a transaction platform; however, this is not absolutely required because many transactions happen at the application-to-application level and not via a central hub.

As business registries mature, value-added services will become key differentiators for registry platform vendors. These value-added services will fall under a few major categories: ease-of-use tools, community building, quality of service, and revenue-models.


2.5 Challenges of Registry-Powered Business

Despite some of the benefits of registry-powered business and transactionality, there is no denying the fact that registries are slow to gain popularity. Business is still more of an art and less of a science. With that in mind, there are limits to how much efficiency technology can infuse into the system. There are also certain intangible challenges that require a change in people's perspectives.

2.5.1 Technological Challenges

The technological challenges around the business registries revolve around security and information integrity.

Electronic Trust

As is the case in the Web services arena, security continues to be an important consideration for deployers of business registries — public or private. Access to a private registry is more controlled (e.g. behind a firewall) and hence registry-level security may be more relaxed than with a publicly-accessible registry. However, business registry software vendors need to provide the ability to secure the registry. Securing business registries involves providing:

  • Authentication to use the registry

  • Authorization and delegation to perform various activities

  • Mechanisms to prevent fraud or impersonation

  • Encryption

  • Delegation of authority

  • Privacy

  • Trust assumptions

Authentication could be as simple as username and passwords or as complex as a digital certificate infrastructure. Authorization is access control, including role-based access control. Fraud or impersonation prevention deals with the ability of a registry to ensure that a company/entity is what it claims to be. For example, in a generic public registry, it would be dangerous to allow a company to claim it is Hewlett-Packard when in reality it is not. Third-party validated certificates can be used to prove the identity; however, it is important for the business registry to fold in these security technologies to help foster electronic trust among participants.

An authenticated party can be part of a transaction, but it may not have access or privilege to all information available. In fact, there are usually several levels among the users — each level with different usage rights. Thus, after a service user is authenticated, it must be authorized to perform a certain operation or to request that a certain task be performed by the service.

Delegation of authority is the ability to delegate authorization to a transaction to another user. Delegation creates a powerful mechanism to transfer certain responsibilities to request or perform a task in the Web services world.

Authorization controls the access to the data, even among authenticated parties. Legislated privacy requirements can restrict the usage of data even further. Even though an authorized entity has access to the privileged information, that party might be forbidden to use it without prior knowledge or consent of the primary subject of the data. An example of this is credit-issuing companies. Even though they are authenticated and authorized to have access to the credit cardholder's address, annual income, and preferences, this information cannot be shared with anybody without written permission from the cardholder. Moreover, the cardholder can revoke this permission at any time. Privacy of services means that the service can prohibit the end-user from divulging certain data about it (or the data it mediates access to) to other users in the ecosystem.

In many cases, there is already a built-in trust between two or more parties engaged in a transaction. In such a scenario, the trusting party may be willing to relax the rules of security for a trusted entity. An example of this could be the approval for a travel expense report. If an approving manager trusts the spending judgment of an employee, a travel expense report undergoes a relaxed level of scrutiny. Trust assumptions are usually a good way to make an exception to the standard service security policy.

Information Sanity

Information sanity refers to the ability to rely on the timeliness, accuracy, and "freshness" of the information contained within the registry. Like any repository of information, a business registry is only as good as the information contained within it. While this issue is two-pronged (it has a counterpart on the goodwill challenges list as well), it is very important for business registry deployers or administrators to employ the appropriate procedures and processes to ensure the information is essentially up-to-date and accurate. The technical facet of this problem deals with the maturity and sophistication of the tools provided with the registry infrastructure to perform activities that would promote and enforce information sanity. Some of the types of activities that could support information sanity are:

  • Forcing registrants to review their information on some frequency or risk registry entry expiration

  • Simulate registry interactions to uncover stale information

  • Enforce contractual obligations regarding providing fresh information

2.5.2 Intangible Challenges

Intangible challenges are those challenges that are not necessarily related to the technological infrastructure that registries are deployed using. These challenges pertain to the realities of how business is conducted and how relationships are formed.

The Place to Be and Look

As we mentioned previously, any registry is only as good as the information it contains. With that in mind, both public and private registries need to develop a reputation as the place to be and the place to look. Private registries, like the employee portal, can enforce processes and procedures around usage of the private registry; however, public registries need to develop, encourage, and nourish this reputation. To be successful, these registries need to be known as the place to look or the place to be registered so that a wealth of information can be created. As business registries move through their life cycle, we observe that they are likely to be deployed in a private environment initially and perhaps linked into a larger public ring in the future. This reduces the need for becoming the place to be and look for now; however, it is important to follow the acceptance of any registry technology. If it does not get accepted in the private space, it is unlikely that a public instantiation of it will be able to develop the appropriate reputation.

Acceptance of registries, whether de jure or de facto, is incomplete without the necessary confidence.

Fostering Confidence

We started the discussion about business registries by describing the very people-intensive process of finding vendors to fulfill a need — whether that be a physical resource like cement or software consultants. The people involved in bringing in new vendors are essentially accountable for the relationships they foster. They will make decisions based on confidence that has been developed over time. In the absence of direct confidence, brand awareness is a good substitute, especially if the brand awareness can be coupled with customer references or testimonials. Fostering the same ability to have confidence in potential partners discovered on a discovery platform, such as a business registry, is most likely going to be one of the most significant challenges.

Despite these challenges, business registries (the next generation of e-marketplaces), are going to be an important part of supply chain, logistics, and vendor networks in the coming years. Internally, enterprises are cleaning up their infrastructures and integrating their set of disparate systems. These integrated environments are likely to have a Web services network that will supplement the EDI and e-marketplaces that exist. As this expanded virtual network of several different companies becomes more complex, the role of business registries as the mechanism to navigate this maze will be critical.

In the next chapter, we examine in detail the role of business registries within Web services-based ecosystems.


Chapter 3. Web Services Overview

  • A Service

  • Web Service Technology Stack

  • Web Service Platforms

  • A Simple Web Service

    example working directory: \Examples\Ex01Emp401kService

  • Document Exchange Model-Based Web Services

  • Advanced Topics

  • UDDI and the Web Services Paradigm

Web services are a new phenomenon in the computer industry. The concept of a Web service is based on service-based computing which we discuss in Chapter 2.


3.1 A Service

Section 2.2.5 provides a business-level discussion about Web services and a corresponding definition. A technical-level definition for Web service requires us to first define a service. The definition of a service as given below is not necessarily precise or all encompassing, but rather a working description of the notion of a service. Figure 3.1 depicts a service.

Figure 3.1. A service.

Service: A service is an active program or a software component in a given environment that provides and manages access to a resource that is essential for the function of other entities in the environment.

It is important to note that the notion of resource is rather broad in this definition. A resource could be a piece of hardware, such as a hard disk, or software, such as a math library. It could also be some data in a database or some information, such as a news item. This definition is somewhat simplistic yet very powerful. It is simplistic because it tries to be as broad as possible and specifies very few characteristics or restrictions on qualifying entities. A service need only be a program or a library function to qualify. The key, however, is in the provision and management of a resource. Provision means that it has to make the resource available to other entities, and management denotes controlling and granting the access rights. You can see that this automatically mandates interaction with other entities in its environment. Thus, a program or a software component that does not interact with other entities will not qualify as a service. An equally important aspect is controlling a resource that is desirable by other entities in the service environment. Any resource that is useful only internally to the program does not make it a service.

3.1.1 A Web Service

Web services constitute a special class of services. The services from this class are highly interoperable.

Web Service: A Web service is a service over a computer network that abides by a specific framework to offer its services. The framework provides the means to describe and discover the service, interact with the service, and potentially integrate the Web service with other Web services to offer higher-level Web services.

Figure 3.2 shows a conceptual view of a Web service. The high level of interoperability in this case is achieved through uniform discovery and description standards provided by the framework. Note that the interoperability here is limited among the services that abide by the same set of standards. Web services inherit several characteristics of component-based architectures. Chief among them are:

Figure 3.2. A Web service.

  • They have a well-defined build-time and runtime interface for interaction.

  • They can be thought of as an independent entity, compared with other components of the architecture. They can be built, deployed, and undeployed without affecting other Web services in the architecture (however, this might affect the functioning of the system).

  • They are individually addressable in the system. This means that a Web service can be approached and communicated with by other entities in its ecosystem. The addressability of a Web service or a component separates them from other software modules that are merely results of functional decomposition.

However, a Web service is not the same as a component. Several characteristics differentiate the two.

  • Service description — A Web service is described using a specific standard taxonomy (nomenclature). The taxonomy attaches specific meaning to the terms used in the service description. Taxonomies are discussed in detail in Chapter 6. The description also consists of a means to describe operations facilitated by the service and the mechanics of those operations.

  • Service discovery — The standardized description of a class of Web services can be used to discover a specific service within that class. Taxonomy-based classification helps in filtering out services that do not attach the same meaning to the terms used in the interaction.

  • Service interoperability — Standardized description and discovery mechanisms make it easy for clients of a service to reconstruct a service interface in a way it finds most suitable at its end. This interface can then be used during service interaction. Thus, clients written virtually in any language can interact with a Web service.

  • Service composition — Web services can be combined together to create higher-level Web services — on the fly. The preciseness of service description within a certain taxonomy can make the task of such modularization easy and any service fitting a specific description can become part of a higher-level Web service.


3.2 Web Service Technology Stack

The Web services paradigm consists of components that are aimed at facilitating all the stages in service creation and use. It primarily consists of three components:

  1. Service creation and deployment platform

  2. Service registry

  3. Service description and classification framework

As discussed earlier, Web services are characterized by the underlying framework that defines the process of description, discovery, and interaction. The current widely-popular framework provides a language-independent technology stack between communicating software entities. Figure 3.3 depicts this stack.

Figure 3.3. Web services technology stack.

In this section, we focus on the XML-messaging and the Service Description layers of the stack as these layers have the most sophisticated standards. Web services security and Web services management, discussed later, are still being debated and discussed within the Web services community. The topic of this book is the Registration and Discovery functionality provided by UDDI.

3.2.1 XML-Messaging

The underlying communication mechanism in the Web services paradigm is Simple Object Access Protocol (SOAP). SOAP is an Extensible Markup Language (XML) over Hypertext Transfer Protocol (HTTP)-based protocol for accessing components (for example, services and objects) in a platform-independent manner. Appendix G provides more details about SOAP technology.

The major advantage of this lightweight protocol is that it allows services running in one kind of platform (Java 2 Enterprise Edition [J2EE]) to communicate with services in the same or another kind of platform (.NET). Since HTTP is available on all popular platforms, it provides an already at-hand solution to the problem of how services running on different platforms in a network can communicate with each other. The SOAP specification specifies exactly how to encode an HTTP header and an XML file so that a service on one platform can interact with a service in another. Another major advantage of SOAP is that because it is XML/HTTP-based, it can go through the firewall in the same manner that HTTP requests do. Therefore, SOAP solves two obstacles in the service paradigm — interoperability and firewall traversal.

3.2.2 Service Description

The Service Description layer of the stack refers to the ability of a service to communicate what a Web service can do, where it resides, and how to invoke it. The Web Services Description Language (WSDL) supports service description capabilities in the Web services paradigm. WSDL is an XML-based grammar used to describe services a business offers; it also provides a way for individuals and other businesses to access those services electronically. A WSDL describes four critical pieces of data:

  • Interface information that describes all publicly available methods

  • Data type information for all message requests and message responses

  • Binding information about the transport protocol to be used (e.g., HTTP, HTTPS, or SMTP)

  • Address information for locating in the form of a service endpoint URL

Appendix H explains WSDL in further detail. WSDL, like SOAP, is also platformand language-independent and is used primarily to describe SOAP-based Web services. WSDL is derived from SOAP and IBM's Network Accessible Service Specification Language (NASSL). WSDL replaces both NASSL and SOAP as the means of expressing business services in the UDDI registry.


3.3 Web Service Platforms

There are two main types of Web service platforms: Java 2 Enterprise Edition (J2EE) and Microsoft's .NET. BEA, IBM, and Sun Microsystems are just a few of the large software houses that provide J2EE-based Web service platforms. In addition, there are open source platforms, such as Apache Axis, are available for Java-based Web services. Microsoft has its own platform based on the .NET architecture. These platforms implement and supplement various layers and components of the Web service architecture stack depicted in Figure 3.3.

3.3.1 Apache Axis Web Services Platform

Axis is an open-source product from Apache Software Foundation — an open-source community responsible for developing several notable products such as Tomcat and Cocoon. Axis can be considered as the SOAP engine that can facilitate both Web service deployment and consumption.

Axis can act as a stand-alone server. Axis is also pluggable with Tomcat — a feature that can be used for more complex architectures. In addition to the server capabilities, Axis provides a few tools that can be used to ease the development effort for server-side and client-side developers. The Java2WSDL tool can used to create Web service specific components for a Java class representing certain functionality. On the other hand, the WSDL2Java utility can be used to generate client-side proxies for the Web service.

3.3.2 .NET

Microsoft .NET is a development and deployment platform geared towards Web services. It contains several software technologies that individually address a specific feature necessary for Web service development. As such, several of these software components are upgrades of existing products such as SQL server and BizTalk server. However, under the .NET aegis, these components have a common framework to support Web services. This framework, understandably called .NET Framework, provides the backbone for the Microsoft technologies and products that support Web services. Figure 3.4 depicts that .NET technology stack.

Figure 3.4. .NET technology stack.

.NET Framework

The .NET Framework is essentially an implementation of the Web services technology stack as well as a common set of resources that are used by applications written in any .NET-supported programming language. .NET Framework consists of two parts — the Common Language Infrastructure (CLI) and a set of class libraries. CLI is equivalent to a virtual machine that runs bytecode in an intermediate language called Internal Language (IL). Any language that can be compiled eventually into IL can be supported through the .NET platform.

As part of the .NET platform, Microsoft also introduced a new high-level programing language C# (pronounced See-Sharp). C# integrates programming language concepts in C, C++, and Java; it also has some additional features related to component development.

Visual Studio .NET

Visual Studio .NET is the visual programming environment for .NET. From a product perspective, it is the next revision of the Visual Studio Integrated Development Environment (IDE). Visual Studio.NET provides an easy drag-and-drop environment to create Web services from built-in templates. It also automates the process of deploying Web services on Microsoft Web servers.

UDDI .NET SDK

.NET also includes a Software Development Kit (SDK) for UDDI. The UDDI .NET SDK provides Visual Basic and C#-based APIs for interacting with a UDDI registry. This SDK is currently in Beta stage. At the time of writing this text, Microsoft had introduced Beta 2.0.


3.4 A Simple Web Service

In Chapters 2 and 4, we introduce the employee portal that enterprises are developing for employees. The portal provides several types of services; one group of services allows employees to manage their company-offered benefits. It is a common practice in many countries to offer employed people a means to save money for their retirement. Typically, these savings are specifically earmarked for the future and are either tax-deferred or tax-free. In the United States, one such company-offered retirement option is the 401(k) plan. Employees can invest up to an Internal Revenue Service (IRS)-defined maximum of pre-tax earnings. This money can be invested either in the offering company's stock, in more than one mutual fund, or in some other financial instruments (such as a government bond).

Large investment houses provide the participating employers and employees services that can give up-to-date information such as the available mutual funds for investment, the performance of those, and an individual's real-time account bal-ance. To illustrate a simple Web service, we look at the example of a retirement plan contribution service — Emp401kService(). This service allows its users to review fund lists and their associated contribution percentages. The service exposes two methods to accomplish this:

  • getFundList

  • getEmployeeContribution

In the next section, we demonstrate how to develop and deploy this service using both the J2EE and .NET Web services platforms.

3.4.1 Retirement Plan Contribution Web Service

Web services allow a decoupling of the business logic from the deployment. Hence, the first step in developing a Web service is to identify (or create) the business logic which will be exposed via the Web service interface. In our Emp401kService example, the business logic is very straightforward as can be seen from the business logic files Emp401kService.java and Emp401kServiceDOTNET.asmx.cs. Figure 3.5 depicts the service architecture.

Figure 3.5. Emp401k Architecture.

3.4.2 Business Logic

The getFundList method retrieves the list of the selected mutual funds available in this 401(k) plan from a backend database. The getEmployeeContribution method takes an employee number and returns the mutual funds and associated contribution percentages. Appendix F provides the schema for the 401(k) contribution database. Notice that there is nothing Web service-specific in the business logic code for the most part.

The way our service is architected, it takes character strings as input and returns a string in each case as output, but it could very well have used XML for information sharing. Later, in Section 3.5, we discuss the document exchange paradigm in greater detail.

Once the business logic or service logic is completed, the next step is to deploy it as a Web service. Before we discuss the deployment of the Emp401kService, let's recap what the Web services interaction paradigm will look like after deployment.

Notice that in both the .NET and J2EE worlds, the service takes programmatic SOAP-based requests and returns SOAP-based responses. Also, notice that the J2EE service is deployed with the Apache Axis server or J2EE container whereas the .NET service is deployed on Microsoft's Internet Information Server (IIS). The .NET paradigm is very integrated with Visual Studio .NET. The point and click nature of Microsoft tools masks many of the steps that occur between business logic creation and service deployment. We focus on the J2EE environment and return to .NET towards the end of this section.

3.4.3 Axis-based Emp401k Service Deployment

Deploying Web services in Axis is supported by a set of utilities that are bundled along with the Apache Axis Web service tools. After developing the business logic, the following steps are required for deploying the business logic as a Web service.

  • Create the WSDL representation

  • Create client-side bindings for the Web service

  • Deploy the business logic as a Web service

  • Create client logic

WSDL Representation

After the service is developed, a WSDL representation of it must be created. Many Web service platform vendors have tools that make this step very straightforward and remove the hassle of creating the associated XML.

Axis includes a utility called Java2WSDL.class in package org.apache.axis.wsdl to create the WSDL. The Java2WSDL utility takes several parameters including class representing the Web service, name of the WSDL file, and default namespace. The reader is referred to the Axis User's Guide for complete list of parameters. In this example, we use following parameters:

  1. Java class name for the business logic

  2. WSDL file name

  3. Service access point URL

  4. Target namespace

  5. Service name

The Java class name is straightforward. In the example, this is Emp401kService(). The WSDL file name is Emp401kService.wsdl. The service access point URL is the address of the deployed Web service. This is the address at which the service is reachable manually or programmatically. In this example, the endpoint is http://localhost:8080/axis/services/Emp401kService. The localhost:8080 should be changed to denote the server and port where the Axis server is started. The target namespace is the namespace used in the WSDL file. In this case, it is urn:Emp401kService. The service name is simply the name of the service; in this case, it is Emp401kService().

To run the utility, execute the following with the aforementioned parameters:

C:\> java org.apache.axis.wsdl.Java2WSDL -o Emp401kService.wsdl
      -l"http://localhost:8080/axis/services/Emp401kService"
      -n "urn:Emp401kService" Emp401kService

When this executes successfully, a file called Emp401kService.wsdl is generated in the local directory. So, what does the WSDL file actually do? Let's take a look at it more closely. The following portion of the WSDL file describes the messages that the service recognizes and processes. In this example, each method requires parameters and returns some data. Hence, there is a pair of messages exchanged when these methods are invoked. It possible that a pair of messages is not exchanged and only a request OR a response is delivered to the service or client, respectively. WSDL supports even these types of methods.

Emp401kService.wsdl
<wsdl:message name="getFundListRequest">
</wsdl:message>
<wsdl:message name="getFundListResponse">
      <wsdl:part name="return" type="SOAP-ENC:string"/>
 </wsdl:message>
<wsdl:message name="getEmployeeContributionRequest">
      <wsdl:part name="in0" type="SOAP-ENC:string"/>
</wsdl:message>
<wsdl:message name="getEmployeeContributionResponse">
    <wsdl:part name="return" type="SOAP-ENC:string"/>
</wsdl:message>
...

The following portion of the WSDL file describes the methods (operations) of the service. Notice the pairing together of request-response messages and their relationship to a specific operation.

Emp401kService.wsdl
<wsdl:portType name="Emp401kService">
  <wsdl:operation name="getEmployeeContribution"
     parameterOrder="in0">
    <wsdl:input message="intf:getEmployeeContributionRequest" />
    <wsdl:output message=
       "intf:getEmployeeContributionResponse" />
  </wsdl:operation>
  <wsdl:operation name="getFundList">
    <wsdl:input message="intf:getFundListRequest" />
    <wsdl:output message="intf:getFundListResponse" />
    <wsdl:fault message="intf:Exception" name="Exception" />
    <wsdl:fault message="intf:ClassNotFoundException"
       name="ClassNotFoundException" />
  </wsdl:operation>
</wsdl:portType>
...

The last portion of the WSDL file includes the parameters we provided in creating the WSDL representation, namely, the service access point URL and the service name.

Emp401kService.wsdl
...
<wsdl:service name="Emp401kServiceService">
  <wsdl:port binding="intf:Emp401kServiceSoapBinding"
     name="Emp401kService">
  <wsdlsoap:address location=
     "http://localhost:8080/axis/services/Emp401kService" />
  </wsdl:port>
</wsdl:service>
...
Creating Client-side bindings

To interact with a Web service, the client environment needs to have a client-side proxy for the service. The client-side proxy classes are responsible for exchanging messages with the service instance.

Axis provides a tool to generate the client-side stubs (the Web service proxy). Find the Web service business logic class file (in our example, Emp401kService.class) and run the following command:

C:\> java org.apache.axis.wsdl.WSDL2Java -s
 -Nhttp://localhost:8080/axis/services/Emp401kService
   =Emp401kService
 -Nhttp://DefaultNamespace=Emp401kService Emp401kService.wsdl

The WSDL URL is used by this tool to generate the appropriate messaging syntax. The -N option specifies the mapping between a namespace and a package. In this example, both the namespaces are mapped to the same package, viz. Emp401kService(). The directory, Emp401kService, has the following client proxy files:

  • Emp401kService.java

  • Emp401kServiceService.java

  • Emp401kServiceServiceLocator.java

  • Emp401kServiceSoapBindingStub.java

  • deploy.wsdd

In addition to these files, Java code representing exceptions and certain server-side bindings are also generated. The file deploy.wsdd is used during Web service deployment.

Deploying Emp401kService

Before the service is ready to be deployed, all necessary business logic classes need to be made available to the Axis SOAP server. To accomplish this, make all the Web service classes available in the class path.

At this point, the environment is set to deploy and run the service, Emp401kService(). Start the Axis server with following command:

C:\> java org.apache.axis.transport.http.SimpleAxisServer
-p 8080

To deploy the Web service, the Axis Admin client tool is used. This tool uses the file deploy.wsdd. Sample contents of this file is shown below:

deploy.wsdd
<deployment>
  <!-- Services from Emp401kServiceService WSDL service -->
  <service name="Emp401kService" provider="java:RPC">
      <parameter name="className"
   value="Emp401kService.Emp401KServiceSoapBindingSkeleton"/>
      <parameter name="allowedMethods" value="*"/>
      <parameter name="scope" value="Session"/>
  </service>
</deployment>

C:\> java org.apache.axis.client.AdminClient deploy.wsdd

The simplest way to ensure that the service is deployed appropriately (from a client perspective) is to enter the URL for the WSDL in the browser — http://localhost:8080/axis/services/Emp401kService?wsdl. The WSDL file for the Emp401kService() is depicted in Figure 3.6.

Figure 3.6. Emp401kService WSDL.

3.4.4 Interacting with Web Service

The client logic should be part of the same service proxy package as follows:

Emp401kClient.java
package Emp401kService;

Invoking the exposed Web service methods involves exchanging the SOAP messages described in the WSDL file. The method, Emp401kServiceServiceLocator(), provides the instance to the class that facilitates this communication. Individual methods from this class, Emp401Service(), correspond to methods of the original service. Therefore, the following code segment invokes the getFundList() method of the Emp401kService().

Emp401kClient.java
binding = new Emp401kService.
            Emp401KServiceServiceLocator().getEmp401KService();
...
String fundList = binding.getFundList();

3.4.5 In Action

To observe the example code in action, start the Axis SOAP server. We assume that the service has been deployed and the installation is verified. Open a command window and, from the appropriate directory, start the client program as follows:

C:\> java Emp401kService.Emp401kClient

The menu will appear as shown in Figure 3.7. To view the list of funds available, choose option 1. Contributions for a specific employee can be found through option 2. The list will appear as shown in Figure 3.8.

Figure 3.7. Starting Emp401kClient.

Figure 3.8. Result of invoking getFundList() from Emp401kClient.

3.4.6 .NET

Web services development in .NET can be completely contained within the Visual Studio .NET development tool. While developers on the Microsoft platform can manually create their .NET Web services without the help of the integrated development environment (IDE), our discussion is based on creating the Emp401k service with the help of the IDE.

First off, either the Internet Information Server (IIS) or the Personal Web Manager (PWM) is needed to run the Web services. The J2EE platform is application server-based and Web services run in the application server. However, in the .NET paradigm, Web services run in the Web server as an extension to the Active Server Pages (ASP) technology. Start the Web server as it is required when developing and building .NET Web services.

Once installed, start Visual Studio .NET from the Start menu. Start a new project from the File menu. On the right-hand side, choose the programming language; for this example we use C#. However, ensure that the ASP .NET Web service template is selected and that the name of the Web service is provided in the Location box at the bottom of the dialog box. We have named this one: Emp401kDOTNET(). Figure 3.9 depicts this step.

Figure 3.9. Start a new Web service project in Visual Studio .NET.

As the IDE processes this new Web service, a familiar graphic as seen in Figure 3.10.

Figure 3.10. Creating the new Web service in Visual Studio .NET.

The result of this process is that (assuming that PWM or IIS is installed with its default configuration) a new directory with the name of the Web service is created in C:\Inetpub\wwwroot. In this case, recall that it is Emp401kDOTNET. Check to make sure that this directory is created and also change the Web sharing properties on this directory. Right click on the directory name and go to the Web Sharing tab. Select Share this Folder check box. A property dialog box will immediately pop up and the following should be selected:

  • Read

  • Write

  • Execute

Figure 3.11 depicts this step.

Figure 3.11. Setting Web sharing properties on your Web service directory.

At this point, we are ready to modify the .NET Web service template to create the Emp401kDOTNET() Web service. Select the Service1.asmx in the Solution Explorer and rename it to the service name — in this case, Emp401kDOTNET.asmx. Also right click this file and set it as the start page for the service. Modify the template to add the required business logic. Emp401kDOTNET.asmx is the main Web service business logic file of the Web service.

Recall from the J2EE example that we use a database backend for this Web service. In the .NET paradigm, this requires having ODBC .NET Manager installed in the environment. Download and install this from Microsoft Developer Network (MSDN) Web site. We provide a shortcut to this URL on the accompanying CD. Once this is installed, include the database access libraries: Microsoft.Data.Odbc and System.Text in the asmx file. In addition, add reference to the ODBC library from the Project [image] Add Reference [image] Microsoft.Data.ODBC.dll.

Develop the business logic, similar to that in the J2EE paradigm, for getFundList() and getEmployeeContribution() methods.

Note

Exposed Web service methods in .NET Web services need to be public and should be denoted as a WebMethod.

Take a look at the code for the getFundList() method:

Emp401kDOTNET.asmx.cs
[WebMethod]
public string getFundList()
{
DataSet dataset= new DataSet();
OdbcDataAdapter adapter = new OdbcDataAdapter();
adapter.SelectCommand = new
         OdbcCommand("SELECT FundName FROM FundTable", myconn);
adapter.Fill(dataset);
StringBuilder resultString = new StringBuilder();
//iterate through the resultant dataset and build result string
for(int i=0; i<dataset.Tables["Table"].Rows.Count; i++)
{
 resultString.Append(dataset.Tables["Table"].
                                        Rows[i]["FundName"]);
       resultString.Append("|");
}
//Return the result in String format
return resultString.ToString();
}

The code looks fairly straightforward. There is generated code and template code that takes care of the Web services aspects of the development. For example, the InitializeComponent is included in the Web service constructor. Business logic is added to this template to provide the desired functionality via the Web service. A Build of the solution creates the relevant Web service specifics. Recall that we ran the ClassToWSDL tool in the WSP to create the WSDL file; in this case, this step is included in the build process.

3.4.7 In Action

To deploy the .NET based service from Visual Studio .NET IDE, load the project in the IDE environment. To deploy the Web service and launch the default browser-based client, click on Debug [image] Start Without Debugging. Successful operation will launch the browser as shown in Figure 3.12.

Figure 3.12. Browser-based client for a .NET Web service.

Notice http://localhost/Emp401kDOTNET/Emp401kDOTNET.asmx, the Web service URL, which is based on the Web service name. To view the WSDL of the Web service, enter the following URL in the browser or click on the Service Description link on the default page:

http://localhost/Emp401kDOTNET/Emp401kDOTNET.asmx?WSDL

The WSDL document is displayed in the browser window as shown in Figure 3.13.

Figure 3.13. WSDL for Emp401kDOTNET.

To invoke any service method, click on its name on the default page. A page detailing the SOAP messages and HTTP request examples will appear along with the Invoke button. The page for the getFundList() method is shown in Figure 3.14.

Figure 3.14. A method page for Emp401kDOTNET.

Clicking on the Invoke button invokes the particular method for the service and displays the results. The resultant page after invoking the getFundList() method is shown in Figure 3.15.

Figure 3.15. Invoking getFundList() method of Emp401kDOTNET.
    [ Team LiB ]


3.5 Document Exchange Model-Based Web Services

Until now, we treated the information to and from the Web service in the form of objects. In such a case, the information is stored in the form of Java or C# objects at both ends.

In Chapter 5, we discuss how language-specific data representation limits interoperability. Generally, it would be desirable to represent and process the data in XML format to improve it. Services developed using the Document Exchange Model (DEM) are designed to maximize usage of XML.

DEM-based services are most suitable for interactions that are request-response in nature where both the request and response are potentially complex in nature. Examples of such interactions are the exchange of order information between a company and its customers or an intracompany communication of product configuration data for complex products such as a car or an airplane. Figure 3.5 depicts simplified versions of such interactions.

In these types of interactions, language-specific objects are more difficult to work with compared to structured XML documents. XML documents provide a very flexible way to share information. SOAP and WSDL, based on XML technology themselves, provide a means to communicate information using XML documents.

Consider a DEM-based retirement plan contribution service that accepts XML-formatted requests and provides XML-formatted responses in contrast to the services explained previously that took string inputs. The request document to get contributions of an employee with ID 1001 could be formatted as follows:

<getEmployeeContribution xmlns="insidewebservices.com">
   <EmployeeID> 1001 </EmployeeID>
</getEmployeeContribution>

In response to such a request, the service returns an XML document that provides the fund names the employee has contributed to and the associated contribution percentage for each fund. For example:

<ContributionInfo xmlns="insidewebservices.com">
   <EmployeeName> Carl Cooper </EmployeeName>
   <FundList>
      <Fund>
         <FundName> Growth and Income Fund </FundName>
         <contribPercent> 50.0 </contribPercent>
      </Fund>
      <Fund>
         <FundName> Tax-Free Investment Fund </FundName>
         <contribPercent> 50.0 </contribPercent>
      </Fund>
   </FundList>
</ContributionInfo>

Note that in both the XML documents, the structure of the document is defined in a rather ad-hoc manner. In reality, there would more standard formats defined for such documents. In addition, elements do not have any attributes since they are discouraged in the WSDL specification in order to increase interoperability.

3.5.1 SOAP and DEM-Based Services

In the request and response messages sent using SOAP, a service developer has two options to package relevant XML documents. The XML documents can be embedded in the SOAP body or it could be attached to the SOAP message as an attachment.

Embedding XML Documents in SOAP Messages

Embedding an XML document in a SOAP message is a simpler option in which the relevant XML document is packaged within the SOAP body element and eventually in a SOAP envelope before the message is sent to/from the service. Due to this, the entire XML document becomes a "node" within the SOAP message (which is in XML format itself). Figure 3.16 depicts this.

Figure 3.16. XML document embedded in a SOAP message.

Thus, a SOAP-based request for employee contribution could look like this:

<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <getEmployeeContribution xmlns="insidewebservices.com">
         <EmployeeID> 1001 </EmployeeID>
      </getEmployeeContribution>
   </soap:Body>
</soap:Envelope>
XML Document as a SOAP Attachment

The SOAP specification allows for attachments to SOAP messages as explained in Appendix G. In such a case, SOAP messages could be sent in multipart Multi-Purpose Internet Mail Extensions (MIME) format. The main SOAP envelope forms one part of the MIME-structured message. The XML document(s) associated with the main SOAP message are packaged as remaining parts of the message with a reference to each such attachment in the main SOAP message. Figure 3.17 depicts this message structure.

Figure 3.17. XML documents as attachments to a SOAP message.

The <Attachment> tag in a SOAP body (or header) is used to specify references any attachments associated with the specific part of the SOAP message. This reference is in the form of a Universal Resource Identifier (URI) and is specified using the attribute href. A response to the getEmployeeContribution request can thus be formatted as follows:

--MIME encapsulation boundary
Content-Type: text/xml
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <Attachment
          href="http://insidewebservices.com/ctrbRes.xml"/>
      </soap:Body>
</soap:Envelope>

-- MIME encapsulation boundary
Content-Type: text/xml
Content-Location: http://insidewebservices.com/ctrbRes.xml
<?xml version="1.0"?>
<ContributionInfo xmlns="insidewebservices.com">
   <EmployeeName> Carl Cooper </EmployeeName>
   <FundList>
      <Fund>
     <FundName> Growth and Income Fund </FundName>
 <contribPercent> 50.0 </contribPercent>
  </Fund>
  <Fund>
     <FundName> Tax-Free Investment Fund </FundName>
 <contribPercent> 50.0 </contribPercent>
  </Fund>
   </FundList>
</ContributionInfo>
-- MIME encapsulation boundary--

Although more esoteric from a development perspective, SOAP messages with XML attachments provide a clear partition between information and its packaging. In addition, this technique can be used to package several related XML response documents into one MIME package as attachments to the SOAP response message.

To develop and use a DEM-based service, the service or its clients may have to generate SOAP messages themselves as the level of automation in the existing tools lacks the necessary sophistication. The Java APIs for XML Messaging (JAXM) objects can alleviate the developer from creating the necessary element structure to convert an existing XML document into a SOAP message. Refer to JAXM literature for more details.

3.5.2 WSDL and DEM-Based Services

The description of a DEM-based service differs slightly from an RPC-based service. In a WSDL document that describes a DEM-based service, several elements denote the fact that the service interacts through structured XML documents rather than built-in data types such as int and string.

XML Documents as complexTypes in WSDL

The XML documents used by a service, to receive requests or provide responses, are described in its WSDL document as complexType elements. A complexType element looks very close to an XML Schema Document (XSD) for an XML file. The ContributionInfo response document can be represented in the WSDL document as follows:

...
<definitions xmlns:s="http://www.w3.org/2001/XMLSchema"
  xmlns:s0="http://insidewebservices.com">

   ...

   <s:complexType name="ContributionInfo">
      <s:sequence>
         <s:element minOccurs="1" maxOccurs="1"
            name="EmployeeName" type="s:string" />
         <s:element minOccurs="1" maxOccurs="1"
            name="FundList" type="s0:FundList" />
      </s:sequence>
   </s:complexType>

   <s:complexType name="FundList">
      <s:sequence>
         <s:element minOccurs="1" maxOccurs="unbounded"
            name="Fund" type="s0:Fund" />
      </s:sequence>
   </s:complexType>

   <s:complexType name="Fund">
      <s:sequence>
         <s:element minOccurs="1" maxOccurs="1"
            name="FundName" type="s:string" />
         <s:element minOccurs="1" maxOccurs="1"
            name="contribPercent" type="s:string" />
      </s:sequence>
   </s:complexType>

   ...
</definitions>
Classifying DEM-Based Services in WSDL

The document-oriented nature of a service in WSDL is denoted in two places — binding and operation. In both these elements, the attribute style denotes the type of service. For DEM-based services, this attribute should be set to the value document. Thus, to denote the retirement plan contribution service as DEM-based, the corresponding elements are:

...
<soap:binding style="document"
    transport="http://schemas.xmlsoap.org/soap/http" />
...

<soap:operation soapAction="http://soapinterop.org/"
   style="document" />
...

Many Web service development tools available provide capabilities to create DEM-based services.


3.6 Advanced Topics

A Web service developer must be well versed in several aspects of Web service architecture. The discussion in this chapter is limited to providing an overview of the Web services technology. Using this discussion, it is possible to create simple Web services that can be used to understand the applicability of UDDI in the service lifecycle. As Web services evolve to solve real business issues and become mission critical and production-ready in nature, there are several other issues that need to be considered.

3.6.1 Scalability

The scalability of a Web service is determined by how well it can satisfy an increasing number of concurrent client requests. The higher the number of concurrent requests that a service can handle, the better the scalability. Of course, a single instance of a service has severely limited scalability. The deployment platform significantly affects the scalability of a service. Some deployment platforms use an application server in their infrastructure that have built-in load balancing capabilities. If a Web service platform deploys the service as a servlet or an Enterprise Java Bean (EJB), the scalability is limited by the load-managing capabilities of the underlying servlet or EJB container.

3.6.2 Web Services and Long-Lived Interactions

One of the promises of Web services is their ability to simplify intercompany interaction. These interactions are typically long-lived — the interactions take several hours or days to complete and generally include several round trip sub-interactions. An object-oriented (or RPC-based) approach to develop the service logic, for such a scenario, is not suitable since, generally, objects are not expected to exist that long.

A DEM-based service can provide a suitable alternative to facilitate long-lived interactions. The architecture for incorporating DEM-based services in long-lived interaction is currently undergoing evolution. After the architecture and related technologies mature, Web services can be very effective in managing long-lived interaction in both intra- and intercompany situations.

3.6.3 Security

Security is a vast area that has not been fully addressed by many of the Web service platforms at this point. For business-critical applications, Web service security needs to address several issues including, but not limited to:

  • Access to the service: who has authority to use the service

  • Access to different methods of the service: who has what levels of authority on the service methods

  • Access to the user data to and from the service: who has access to view and comprehend the data and information flowing to and from the service

  • Access to the user: who has authorization to communicate with the service user and access user information and data

  • Access to the architecture or internal process flows: who has authorization to introspect and extract the business processes that are used by the service

Several standards are being proposed to address one or more of the aforementioned issues. Notable among these standards are W3C XML Encryption, W3C XML Signature (also known as the "digital signature"), Java Security Assertion Markup Language (JSAML), Web Services Security (WS-Security), XML Key Management Services (XKMS), and XML Access Control Markup Language (XACML). The HP-WSP implements the digital signature specification. Most recently, IBM, Microsoft, and Verisign announced a supporting initiative in Web services security. Web Services-Security (WS-S) describes enhancements to the SOAP technology to provide quality of protection through message integrity, message confidentiality, and single message authentication. WS-Security also provides a general-purpose mechanism for combining security tokens with SOAP messages. It is designed to be extensible (e.g., support multiple security token formats). While many initiatives support the security requirements of Web services, as yet, no specific standard has been widely adopted.


3.7 UDDI and the Web Services Paradigm

UDDI plays an important role in the Web services paradigm. UDDI is the business registry that facilitates the discovery and interaction of Web services. It has become a de facto standard, like SOAP and WSDL. The key to begin participating in the UDDI infrastructure is to model your business. This model includes not only compiling the business entity information but also determining the services, tModels, and bindingTemplates to be registered as well. In the next chapter, we discuss business modeling in detail.


Chapter 4. Registries and Web Services Lifecycle

  • A Web Services Ecosystem

  • Web Services Lifecycle

  • Registry-Powered Business-to-Business Interaction

In Chapter 3, we describe the Web services phenomenon. The paradigm defined by Web services, in which several Internet services interact together to accomplish a task or process, highlights the need for business registries. Business registries, as we learned in Chapter 2, act as a collection point and a discovery platform. Business registries in the Web services paradigm house Web services and make them available for browsing and searching by other applications or processes. Figure 4.1 depicts the Web services world with business registries at its core.

Figure 4.1. Web services ecosystem.

Understanding business registries in the Web services context involves describing their place in the Web services ecosystem and lifecycle. In this chapter, we discuss these topics in further detail.


4.1 A Web Services Ecosystem

A Web services ecosystem is a set of related services. This set, as a whole, provides a set of services in a specific domain. In Chapter 2, we describe the employee portal. A portal Web site is an example of a Web service ecosystem that caters to a specific audience. An employee portal would cater to the needs of a certain set of employees or a medical portal would provide services related to medicine — including services such as medical advice, sale of prescription and nonprescription drugs, and archiving of medical history. But an ecosystem is not merely a collection of services. As the name implies, it is an orderly group. Just like a biological ecosystem, an ecosystem of services can have a hierarchy among its citizens, and it provides a set of rules and regulations that every member must abide by. However, in this case, the hierarchy is not in the sense of food chain or power, but one with the notion of higher- and lower-level services. A hierarchical view of the ecosystem helps in defining service composition — bringing together lower-level services to create higher-level services. In the employee portal ecosystem, for example, the Retirement Plan Financial Institutions, 401(k) services, and others can be thought of as lower-level member services in that ecosystem.

Higher-level services aggregate these lower-level services to create solutions that may be tailored for specific needs. For example, a higher-level service to induct a new employee in the company will make use of the appropriate lower-level services mentioned above and enroll the employee in the 401(k) plan and the stock purchase plan using relevant service interactions. In a similar fashion, a higher-level service can interact with relevant lower-level services to terminate an employee.

The regulatory aspect of the ecosystem is essential for smoother interoperability between the members of the ecosystem. In that respect, an ecosystem can be thought of as having two separate classes of services.

  • Regulatory class services — These are services that ensure interoperability among the members of the ecosystem and enforce standards and regulations required for that purpose. Some examples of this are standards-setting services, service-rating services, and monitoring and dispute-settlement services.

  • Member class services — These are the services that use the standards and rules set by the regulatory class services to offer a certain service that is within the domain of the ecosystem.

Together, these two layers of services provide a complete ecosystem that can sustain itself and provide useful services to its users. Among these classes, there are several roles that different entities will play to make an ecosystem successful.

4.1.1 Roles of Ecosystem Citizens

The complexity of an ecosystem can vary significantly as can the necessity for various roles. The discussion below provides a general view of an ecosystem and corresponding roles. The exact nature and types of the roles are dependent on a specific ecosystem. Figure 4.1 shows the relationship between various roles in an ecosystem.

Ecosystem Host

This entity is responsible for providing the necessary infrastructure for an ecosystem to function. The host's role is mainly to facilitate the general functioning of the ecosystem. An example of an ecosystem host would be the New York Stock Exchange (NYSE). It provides the means for the stock traders to buy or sell stocks and to provide data about those transactions, such as bid/ask prices and the Dow Jones Industrial Average (DJIA) — an index expressing the market's general sentiments about the top 30 companies listed at NYSE. The host also has policies for granting or revoking membership to interested parties. The NYSE, for example, has certain policies in place to let a firm trade any shares using its facilities.

Governing Body

A governing body, as the name suggests, provides policies in an ecosystem that form the framework for transactions in the ecosystem. It is important to distinguish between the roles of the ecosystem host and the ecosystem governing body. The governing body is a more passive entity — one that sets the policies but does not look into operational or day-to-day functioning of the ecosystem. It also does not facilitate interactions in the ecosystem. That responsibility is on the ecosystem host. For trading of company shares and other financial securities, the Securities and Exchange Commission (SEC) acts as the governing body.

Because the governing body is not associated with a specific ecosystem host, it is possible for multiple hosts to host an ecosystem that follows the guidelines provided by the governing body. For example, the NASDAQ provides an alternative stock trading facility to the NYSE. The two rival infrastructures are separate from each other; however, they both follow SEC guidelines. The companies listed on either of these two exchanges are expected to abide by SEC guidelines and to follow the day-to-day operational policies set by the respective ecosystem hosts.

In the service world, a governing body will most likely be a consortium. A consortium is a group of interested parties that work together to develop a specification for a certain task. Consortiums typically are a group of partners, competitors, common-interest parties, or legislature people; they determine certain guidelines, rules, maybe even interaction patterns and quality-of-service levels. The specification developed by a consortium is not necessarily binding to the members of the consortium, nor is a membership necessarily required to accept a specification. If a specification provided by a consortium is widely accepted, it becomes a standard for performing that task. Consortiums can deal with any topic you might imagine. We discuss some examples of consortiums in Chapter 2.

Business registries, like UDDI, support taxonomies to allow groups such as consortiums (discussed in Chapter 6), standards-setting bodies, or other governing third parties to apply these concepts to the network of services and clients that have decided to participate together in a service-based ecosystem. We introduce the ecosystem players in Figure 4.2.

Figure 4.2. Introducing the ecosystem players.

Ecosystem Monitor

An ecosystem monitor entity monitors the interactions between ecosystem members and ensures that the members of the ecosystem are following the interaction guidelines set by the ecosystem host and the governing body. Based on this, the ecosystem monitor can recommend changes in the functioning of a specific member entity or the ecosystem as a whole. There can be several monitoring entities in a given ecosystem. Also a specific monitoring entity may concentrate on only certain aspects in an ecosystem. For example, in the financial securities world, various independent auditing firms act as monitoring entities that audit the accounting and other financial business practices of companies to ensure compliance. The monitors can also provide metadata about an ecosystem and its members, based on their observations. One example of such metadata is service rating. A service rating can provide a relative or absolute standing of a service's offering, based on a variety of parameters, such as price of the service and usage satisfaction. The users of the service can then judge whether to use the service or not, based on this rating.

Ecosystem Arbitrator

It is possible in an ecosystem that the members get involved in a dispute for several reasons, including noncompliance with guidelines, unsatisfactory quality of service, breach of contract, or fraud. An ecosystem arbitrator acts as the mediator between the parties involved to resolve the issue. The governing body may provide guidelines for such arbitration, as well. In some cases, the ecosystem host or the governing body itself may act as the arbitrator. An example of this is the Internal Revenue Service (IRS) in the tax ecosystem. However, the arbitrator must be noted as a separate role in an ecosystem.

The role of ecosystem arbitrator is important even though it plays no part in the transactional aspect of the ecosystem functioning. Without it, effectiveness of the ecosystem could be compromised due to lack of recourse for any issues a member faces while interacting with other members in the ecosystem.

Service Registries

A registry in an ecosystem is a useful tool to locate a certain participating entity or a member of the ecosystem. Because it is possible that the number of the ecosystem members could be huge, the registries are an important means to get information about them. For the stock markets, several such registries, such as ValueLine, are available that provide a variety of data about listed companies and their financials. In service-based ecosystems, such registries provide specifics about the registered services. Earlier in this chapter, we described how services could be discovered and used on the fly. The service registries have a crucial role in the effective discovery of services mechanism.

Note

The role of a service registry and its importance in an ecosystem are widely accepted in the industry. As a result, standards are emerging to formalize creation of service registries. An example of this is UDDI. An overview of UDDI is provided in Chapter 5.

Ecosystem Members/Services

The ecosystem member entities are the very reason why an ecosystem exists. These form the second tier of the ecosystem — the member class services. The entities in this category use the ecosystem infrastructure provided by the ecosystem host and interact with each other to fulfill their needs. The ecosystem members must abide by the rules provided by the governing body, and they are subject to audits from the monitoring entities. Figure 4.3 diagrams the relationships of these additional ecosystem citizens.

Figure 4.3. Relationships of ecosystem players.

In the service-based ecosystem, a further characterization of the member services is necessary. There are three main roles that can be identified for launch and use of a service:

  1. Service Provider

  2. Service Deployer

  3. Service User
Service Provider

A service provider's role is to provide the core functionality for offering the service. For example, a service provider for the Order Status service will provide the means to query the order database using several fields from the database and related conditions and will extract the order status information from the database in some format. Usually, a service provider will need to cater to needs of several interested entities and may not have the expertise or reason to pay close attention to needs of a specific entity or its operational environment. That is the responsibility of the service deployer (see the following).

We use the term business logic in this book to refer to the core functionality provided by the service provider. For example, the business logic provided by a stock broker service is the functionality to buy or sell stock with potential buyers or sellers, based on user-specified criteria (such as limit price) at the stock exchange.

Service Deployer

As mentioned previously, a service provider is generally agnostic to the operational environment of the user of the service. A service deployer, on the other hand, is very sensitive to the operational environment and can do the best job of creating a user-friendly service experience. A service deployer works with the service provider to bring the service's business logic to a certain ecosystem and corresponding operational environment. For example, Enterprise Resource Planning (ERP) system vendors, such as SAP, provide an operational environment to streamline the business processes for a company. The core for the business processes is in the form of the business process analyst team in the company, and the vendor's professional services team helps in bringing those processes to the ERP platform.

A clear separation between the service provider and service deployer ensures optimal use of competencies. A service provider with the core competency in providing business logic can cater to several interested parties and platforms. On the other hand, the service deployer can help several service providers to provide their service to a specific ecosystem and its operational environment.

The Web services paradigm is based on this clear separation. We use this archi-tecture is subsequent examples throughout the book.

Service User

A service user uses the service offered by the service provider to fulfill its needs. There are several resources available in a service-based ecosystem at the disposal of the service user to ensure ease of use and quality of service. The service provider and the service deployer are mainly responsible for the ease of use and the regulatory class services ensure that a certain quality of service is maintained. The service user uses the appropriate service registries and the monitor ratings to choose a service that is most suitable for its needs. Any disputes regarding the service delivery between a user and provider can be resolved by the arbitrator.

Note

A user is not necessarily just a user in the Web service architecture. Because it is possible to compose several lower-level services to create a higher-level service, a user of a service can be another service itself! Thus, for all practical purposes, the distinction between a service and a service user is notional. An entity can be a service provider in one interaction and a service user in the other.

Figure 4.4 depicts the complete ecosystem with all its citizens.

Figure 4.4. The complete ecosystem.

4.1.2 Fostering Ecosystem Loyalty

For an ecosystem to be successful, it is necessary to have the right mix of all of the aforementioned roles — only that would ensure that the ecosystem is scalable, sustainable, and can cater to a growing user base. There are also two other factors that influence the subscription to an ecosystem.

Confidence: An ecosystem will be widely adopted if potential service providers and service users feel confident about the ecosystem environment. The ecosystem environment includes not only the existing members and the composition and credibility of the host and the governing body, but also the operating processes that the ecosystem employs. The existing and potential members should feel confident that the ecosystem provides a trusted environment for their business process and for dispute resolution. This trust or the confidence in the ecosystem comes from adoption of appropriate business standards and effective functioning of ecosystem-monitoring entities.

Note

Having trust in an ecosystem does not necessarily imply the same trust assumptions for individual members of the ecosystem. In a dynamic business environment, it is likely that you may not even be aware of the existence of the entity you discover, much less its trustworthiness. The importance of trust in the overall ecosystem environment is more underscored due to that.

Security: The wide variety of roles in an ecosystem also raises an important question — What are some of the security measures required in an ecosystem to make it a safe environment for the business transactions to take place? This concern comes from the fact that an ecosystem can be an open environment that facilitates intercompany transactions and, thus, carries sensitive data about business dealings. Before you send a quote for a certain product to a potential customer or a product specification to a potential vendor, you want to be assured that it will not fall into the wrong hands; moreover even if it did, you want to make sure that they will not be able to read it.

There are several security aspects that the ecosystem host and/or the governing body need to address — first, independently, to address each of them thoroughly, then, collectively, to maintain consistency. These security aspects range from encryption of data on the wire and authenticity of an individual entity to security enforcement infrastructure of the ecosystem as a whole. Chapter 10 discusses the mechanisms that the Web service paradigm uses to address the security and the trust assumptions.


4.2 Web Services Lifecycle

Bringing services to life is an interesting task for business IT managers of the ecosystem participants. It requires not only the operational resources, such as time, talent, and funding, but also the strategic (both horizontal and vertical) partnerships of other ecosystem members. It is an all-encompassing activity that is akin to the efforts required in building a product or software. From a business manager's perspective, it is useful to recognize the similarity. Following a lifecycle approach to launching a service can greatly assist in planning; however, recognizing the nuances is also important. The standard lifecycle is depicted in Figure 4.5.

Figure 4.5. Service lifecycle.

Strategic planning: Appropriate business relationships are formed in this phase. Should a consortium wish to foster co-opetition be desired, the discussions and negotiations with competitors and partners must happen here. Having a clear vision of what the consortium should provide will help guide the discussions. The consortium then needs to work to develop the framework for services.

Requirements: The requirements for the service will be gleaned from the consortium decisions, as well as the target market. It is important to notice that some of what the service does (or the minimum that the service does) will be strongly influenced and governed by an ecosystem and its monitor, so taking these into consideration will be very important during the service planning.

Architecture and design: Catering to an "unfamiliar" audience is important in this step. Because of the dynamic discovery capabilities of a service-centric architecture, you will find a whole host of users (hopefully!) who may or may not be familiar with your name. Accounting for unfamiliarity will promote use of your service and perhaps allow for repeat business and a superior service rating.

The usual distributing computing design issues still exist. Internet latency and instability must be designed for the service so that reliability and speed can be forced and handled in the complex web of computers.

Development and quality assurance loop: The standard software development processes follow in this phase for the service. However, the quality assurance must also take into account any requirements placed on the service by the ecosystem in terms of system engineering metrics. Ensuring that it is "fast enough," as defined by the ecosystem, stays "alive" long enough, as defined by the ecosystem, and so on, is essential in this phase.

Deployment: The deployment of a service or the "opening" of the service doors really activates it in the ecosystem environment. The ecosystem dependencies need to be thought out; thus, deployment needs to be orchestrated such that all prior ecosystem dependencies are fulfilled.

Support and service documentation: The complexities of distributed computing, such as separation of the requestor and the doer, are enhanced in a service-centric environment. The service support model must not only be one with effective documentation and help desks but should also provide reactive and after-the-fact resolution. The kinds of questions that need to be addressed by a comprehensive support model are:

  • How do I use this service?

  • What do I do if the service does not perform its task?

  • How do I report data discrepancy?

  • What is my liability protection for bad service implementations?

Obsolescence: A service's offering becomes outdated over its life. It is very important to recognize this and to plan for improved offerings via future enhanced services.

4.2.1 Web Service Deployment Process

Figure 4.6 describes the service lifecycle. This lifecycle considered the stages a service goes through in its lifetime. Let's consider a different time span and a narrower scope of simply deploying and using a service. The steps involved in that are shown in Figure 4.6.

Figure 4.6. Steps in service deployment.

As shown in the figure, the first step is to create and deploy the service in an ecosystem. Both the service provider and service deployer are involved in creating and deploying a service. The service provider manages the implementation of the business-level decisions such as the service's business logic, market, and pricing. The service deployer manages the implementation of the transactional frame-work of the service, based on the operational requirements set by the ecosystem's governing body.

A deployed service is functionally ready to be discovered and used by service users; however, it must be registered and advertised first with the ecosystem. This is done during the Service Registration and Service Advertisement steps. More complex services (made up of other simpler services) may need to be composed prior to being invoked by the service users. After the composition, the complex service is fully formed and usable. Users can interact with discovered services to accomplish the specific task for which they were chosen. This interaction with the services can be direct or brokered through a mediator.

A mediator is desired for transactions between a service and its clients. It plays the role of a trusted third party in a dynamic interaction environment. The mediator can log and monitor the interaction. It can also create a persistent interaction experience for the service or the client by shielding them from failures on either side. In a fully trusted environment, direct interaction between a service and client is possible.

Note

There is a cost associated with the mediator's benefits. The added step in the interaction sequence may result in lower throughput. A service user may experience slower response during a mediated transaction versus a direct transaction.

Once a service is deployed, its potential customers can use the service. For best user experience, service delivery is just as important. In case of business users, the service delivery may also be associated with the integration with existing infrastructure. The more seamless the integration is, the more appealing the service is to its users. While a service developer or deployer can design a default service delivery and experience, typically a more customized approach would be needed.


4.3 Registry-Powered Business-to-Business Interaction

Registry-powered business implies that a business registry is not only at the center of the ecosystem; it also plays a substantial role in the transactions that occur in the ecosystem. In Chapter 2, we discuss the role of the registry in an employee portal. In that example, not only does it serve as the central storing house for services in a particular ecosystem, but it also serves as the intermediary among various ecosystems.

4.3.1 Registry as an Intermediary

The employee portal from Chapter 2 is a private registry that caters to employees of a company. The business registry is not limited to providing discovery of services only within its established ecosystem. Business registries can be the intermediaries for an ecosystem with external entities whether those are other services, another collection of services (a business registry), or even a full ecosystem. As the intermediary, the business registry can play several roles. It can:

  • Assist members of the ecosystem to discover, browse, or interact with services of another ecosystem (assuming the appropriate relationships have been formed; for example, contracts and security arrangements have been made)

  • Provide members of another ecosystem access to its service portfolio (again assuming the aforementioned arrangements)

  • Interact with a larger open-access or restricted registry (import or export service meta deta)

In essence, the intermediary nature of business registries can be considered the virtual link between an ecosystem and other external entities. In the example of the employee portal, the registry can provide access to services that are external to the Employee ecosystem but are the result of relationships formed between the company and external service providers. For example, if the company has a relationship with a top-tier Cinema Theater, the portal could route employees to the Cinema Theater's online ticket purchasing service. Employees receive a discount on movie tickets using the referral mechanism. This requires collaboration between the employee portal and Cinema Theater's online services. Figure 4.7 depicts this relationship.

Figure 4.7. Registry as an intermediary.

4.3.2 Registry-Facilitated Web Services Lifecycle

The Web Services lifecycle (described in Section 4.2) facilitates the process of developing and deploying Web services. However, as we also see, Web services are found in two categories — lower-level and higher-level services. Lower-level services can be combined together to form higher-level or complex services. Figure 4.8 depicts this relationship.

Figure 4.8. Relationship between higher- and lower-level services.

Notice that a lower-level service can be a part of several higher-level services. In that respect, it is a many—many relationship.

The process of creating these higher-level services can be thought of as service composition. Service composition creates a unified user experience — one that is inclusive of and different from any constituent service experiences.

One advantage of service composition is that it makes the creation of complex services simpler. A complex service can be thought of as a service that consists of several lower level services. For example, a virtual storefront could be created by assembling together cataloging, order management, payment, and shipping ser-vices (each from entities whose core business happens to be providing that particular business service). Each lower level service provides a specialized offering. The lower level order management service would provide only ordering functionality for the virtual storefront (a complex composite service). As you can see, a virtual storefront provider is shielded from the intricacies of supply chain management if a set of reliable supply chain services has been composed into a higher level complex service, thereby allowing the storefront to focus on finding, selling, and advertising high-quality goods.

Using this model of service design, it is possible to create services of any complexity with a good degree of manageability. Conceptually, service composition is analogous to functional decomposition or top-down design approaches used in software engineering.

Continuing with the top-down design analogy, Web service developers identify the functional components that are needed to build a higher-level service. In the employee portal example, to develop a higher level IT Helpdesk Service, a Corporate IT developer may need:

  1. Employee Authentication Service

  2. Problem Ticket Service

  3. Employee Survey Service

The developer must collect these services together to provide the necessary functionality. Business registries can facilitate this collection. They act as the depot of available services that can be composed together. There is another advantage to this design. Besides the obvious reusability, due to the fact that the employee authentication service is already deployed within the environment; there is no need to redeploy it for this purpose. A scalable Employee Authentication Service that is only used very briefly for verification purposes should be shared among various components of the employee portal. Business registries not only help discover functional units, but also provide access to deployed services that can be shared.

Business registries, as we see, play a vital role in distributed solution architectures. There are several types of business registries. In Chapter 13, we discuss these in detail. However, the Web services paradigm is standardizing around the Universal Description Discovery Integration (UDDI) business registry. In the next part, we discuss UDDI in detail.


Part II: Applied UDDI

In this Part

Chapter 5: UDDI Overview

Chapter 6: Modeling for Registries

Chapter 7: Establishing Connection

Chapter 8: UDDI Publishing

Chapter 9: UDDI Inquiry

Chapter 10: Building UDDI Solutions


Chapter 5. UDDI Overview

  • UDDI Formation

  • Public UDDI Sites

  • UDDI Operators

  • UDDI API Specification

  • UDDI Best Practices

  • Complete UDDI Ecosystem

  • Language-Specific UDDI APIs

The Universal Description, Discovery, and Integration (UDDI) initiative started as a project that brought several companies under one umbrella to discuss the issues related to business integration. Today, the UDDI forum has taken the form of a specification body as well as an entity that plays a vital role in the operational aspect of a UDDI site. The UDDI specification provides the Application Programming Interfaces (APIs) that businesses can use to interact with any UDDI site. On the other hand, the UDDI project deals with operational issues regarding deploying a UDDI business registry. As a result, the UDDI forum operates differently from a typical Internet "standards body," such as the World Wide Web Consortium (W3C) or the Internet Engineering Task Force (IETF).


5.1 UDDI Formation

The UDDI initiative was announced on September 6, 2000 as a project that aimed at supporting a solution for service-centric business-to-business (B2B) integration issues. These issues are faced by any enterprise today when it integrates internally as well as with its partners and customers. UDDI provides the following direction for the project:

The UDDI Project is an open industry initiative in which any organization can participate and implement the specifications. The specifications build on core Internet standards — including TCP/IP, HTML, and XML — and are independent of any underlying platform, language, object model, business application, or marketplace.

The project also announced formation of an entity to oversee the functional aspects. This entity, UDDI.org, has three founding members — Ariba, IBM, and Microsoft. Today, there are over 300 participating members in this organization representing a broad set of industries including several companies such as ABN Amro, Accenture, BASF, Dow Chemical, Hewlett-Packard Company (HP), NTT Communications Corporation, Sabre Holdings Corporation, SAP AG, and Thomas Publishing. This broad-based participation will ensure that the specification is rich enough to satisfy the needs of a wide range of industries.

UDDI.org participants fall in two categories — Working Group members and Advisor Group members. The Working Group members are responsible for developing and publishing specifications and best practices. The Advisor Group, which is where most of the members participate, provides any appropriate comments and amendments. Today, the Working Group includes 15 companies.

5.1.1 Goals of UDDI.org

The UDDI project revolves around making the promise of service-centric computing real and achievable so that more and more companies can take advantage of it. Many businesses today use the Internet as a means to reach their customers and suppliers in an effective way. Reaching new customers and integrating supply chains in real-time has been made possible by the reach and simplicity of the Internet-based communication medium. An Internet-based business model is a vital part of business strategy of these businesses.

The use of Internet (and World Wide Web [WWW]) today, however, is limited in several ways:

  • The number of companies (vendors and customers) a business would deal with is limited to prior knowledge about them within that business. Information about a new customer or vendor is obtained primarily through non-Internet means, such as advertising and marketing agencies, advertising campaigns in media such as television, radio, and other product promotion means.

  • For most of the existing customers and vendors, the information is typically limited to the contact information of key persons (email, phone, and fax numbers, etc.) within those organizations. This makes person-to-person communication easy, but does not help system-to-system interaction.

  • For a smaller list of existing customers and vendors, there is a system-to-system integration in operation using established B2B technologies. However, these implementations are one-to-one, custom, and largely nonrepetitive. This makes current B2B architecture cost-prohibitive for wide-scale use.

The potential of Internet-based business models is not fully exploited as a result of these issues. UDDI.org and the UDDI project aim at addressing these issues and provide specifications to various solution components that resolve them.

UDDI proposes to create a "directory of business services" that provides listings of services, applications, and other software components developed to facilitate intercompany communication at the system level. This directory, conceptually built on but smarter than the real-life Yellow Pages, can provide a standardized way to discover new business entities. It facilitates companies to describe their services at an API-level and at the business-process level so that they can be discovered by potential trading partners with compatible business models and processes. Once discovered, the trading partners can quickly form a system-level communication channel (along with human-level engagement) to affect the new partnerships rapidly. Eventually, this can lead to lowered barriers for a company to participate in the global economy.

The UDDI project members had planned to hand over the UDDI specifications to a standards body after the third revision. As per that plan, the ownership for the specification has been transferred to Organization for the Advancement of Structured Information Standards (OASIS) in 2002.


5.2 Public UDDI Sites

Several participants in the UDDI project have created a public UDDI infrastructure that will serve as the backbone for many of the UDDI-based efforts. These sites implement the most current UDDI specification and are available free-of-charge to UDDI developers. The companies owning these public sites are called UDDI operators. At the time of writing this text, there were three public UDDI operators. The operators and the Uniform Resource Locator (URL) for their respective UDDI public (live and test) sites are as follows:

  • IBM Corporation

    http://uddi.ibm.com

    Test site: https://uddi.ibm.com/testregistry/registry.html

  • Microsoft Corporation

    http://uddi.microsoft.com

    Test site: http://uddi.rte.microsoft.com

  • SAP AG

    http://uddi.sap.com/

    Test site: http://udditest.sap.com/

Beside these operators, Systinet Inc. also provides a UDDI site, although it is not part of the overall public UDDI infrastructure.

  • Systinet Inc.

    http://www.systinet.com:80/web/uddi

Note that the above URLs simply provide information about the UDDI site itself and cannot be used directly to programmatically register or find a business. The URLs used for programmatic access are provided at these sites. All test programs and applications should use the test sites.

5.2.1 Universal Business Registry

The "public UDDI infrastructure" that is supported by the above three operators is the public instantiation of the UDDI specification. Together, these sites create a uniform view of all the businesses that are registered within UDDI infrastructure. This infrastructure is called the Universal Business Registry (UBR). The registries that are part of the UBR operate in unison, and are a replica of each other for basic registry information. It is possible to create UDDI sites that are not part of the UBR. As noted earlier, the Systinet UDDI instance is not part of the UBR.

Note

UDDI.org treats the UDDI API specification as an open standard. As such, the organization does not preclude the existence of non-UBR public instances of a business registry based on the UDDI specification. Of course, such registry instances will have some drawbacks such as not carrying the listings from the UBR. However, these instances can still play a role in providing value-added services that the UBR does not. There are also certain advantages for such registries, since they do not need to rollout functionality in a lock-step fashion—a requirement for UBR operators.

Any UBR site primarily provides basic functionality for a business to participate in the registry:

  • Register a UBR user

  • Register a business entity within the UBR

  • Register a service or a set of services that belong to a specific business entity

  • Register a service interaction model

  • Register a service binding

  • Discover or browse a business or a service using certain search criteria

While the UBR sites are meant to be used, primarily, in a programmatic way, all UBRs provide browser-based interactivity. This can be used to explore UDDI functionality. In Section 5.2.2, we discuss general UBR functionality using Microsoft's UBR instance. Other UBRs provide similar functionality as well. Typically, the browser-based functionality is a subset of overall programmatic functionality.

5.2.2 Microsoft UBR Walkthrough

The Microsoft UBR instance can be used for registering, discovering, and browsing a business or a service. Anyone can browse (look up information in) the UBR, but in order to add information to the registry the user must first register as a publisher. The registration is based on Microsoft Passport service. The URL https://uddi.microsoft.com/register.aspx provides user registration which is based on an email address. Figure 5.1 shows the registration of the email address: uddi@insidewebservices.com. Note that the email address provided must be a valid email address. Registration cannot be completed until the email-based step is completed.

Figure 5.1. User registration with Microsoft UBR.

After successful registration, an email is sent to the email address and the user can provide additional information such as username. Clicking on the link provided in the email completes the registration process. To verify successful registration, login at the Microsoft UDDI site.

Registering a Business

A registered user can add a business entity within the UBR. Business entity registration consists of providing details about the company it represents. To register a business entity, click on the add business link after user login. Figure 5.2 depicts the registration for a business — Inside Webservices.

Figure 5.2. Adding a business with Microsoft UBR.

Business registration typically includes the name of the business as well as a free-formatted string description. The description for Inside Webservices is "Get up-to-date information on Web services technologies."

Upon successful registration of a business, several new options to register services and other business attributes appear as shown in Figure 5.3. The user must click on the Publish button to publish the business to the site. This process includes validation and usually takes less than a day.

Figure 5.3. Successful addition of a business with Microsoft UBR.

Any user can discover any business registered with the UBR. This includes the businesses registered by other users as well. Figure 5.4 depicts the discovery of the business entity Inside Webservices. Figure 5.5 shows the successful discovery of the business. Note that this search is case-insensitive and that wildcard searches are supported. The underlying UDDI APIs provide both case-sensitive as well as case-insensitive search mechanisms.

Figure 5.4. Finding a business with Microsoft UBR.

Figure 5.5. Successful search of a business with Microsoft UBR.

Discovering a Business

A successful business discovery is presented with a URL for the found business entity. Clicking on the link takes us to the information about the business entity as shown in Figure 5.6.

Figure 5.6. Details for a registered business.

The information provides several key data items about the discovered business.

Examples of this key data are the name of the business, any contact information, if added, and the field Business Key.

Every registered element, such as a business entity, a service, or a service interaction model, in a UDDI registry is assigned a universally unique identifier (also called a UUID). The Business Key shows the UUID for a business. The UUID for the business Inside Webservices is: 735F7664-930F-4D8C-80A6-0A9B154162A3. A UUID uniquely identifies any element in the UBR infrastructure. The UUID key for a service is called Service Key. This mechanism ensures that UBR-registered elements can be uniquely addressed during discovery and interaction.

Regardless of which element is being assigned a UUID key, the underlying concept for all of them is the same. A UUID is a 128-bit value that is either guaranteed to be unique or extremely likely to be unique until 3400 A.D., based on the choice of algorithm. One advantage of the UUID scheme is that it does not require a central authority to generate the keys. Hence, it is a very attractive scheme to allocate unique identifiers in a distributed environment such as the UDDI UBR. UDDI has adopted the 8-4-4-4-12 Hex representation of the UUIDs.

Note

The UDDI Operator Council does not mandate any specific algorithm for generating UUIDs. However, if required, it may review the algorithm used by a UBR participant. Several UUID generation algorithms are described at:

http://www.ics.uci.edu/pub/ietf/webdav/uuid-guid/draft-leach-uuids-guids-01.txt

The successful search of a business entity also provides a discovery URL that can be cached for future reference. Clicking on that link returns the full UDDI XML representation of the business entity it represents. Some of the information fields shown are private to the entity that registered it (registration owner). This information is not publicly visible.

Registering a Service

Once a business entity is registered, services can be added to its portfolio. One business entity can register several services. Figure 5.7 shows the registration of the service Learn UDDI under the business Inside Webservices, while Figure 5.8 depicts successful service registration. Note the additional information such as the service classification and binding that is maintained within the UDDI registry.

Figure 5.7. Adding service to a business entity.

Figure 5.8. Successful search of a service with Microsoft UBR.

Binding a Service

The service registration so far concentrates only on certain informational elements such as name and description. However, for the registration to be useful, the information to access the service is also necessary. Such service bindings can be used to interact with the service using the appropriate communication protocol.

In UDDI terms, such a binding is called a bindingTemplate. BindingTemplates denote access points for registered services. For a service, there could be several access points possible. For example, a service might be accessible via email, through a Web page, or via the File Transfer Protocol (FTP). Figure 5.9 shows how to add a binding for a service. In this case, a mailto binding is added to the service Learn UDDI.

Figure 5.9. Adding binding to a service.

These are the minimum steps required to list a service in a UBR. Advanced features provided by the UBR are discussed throughout the book.

5.2.3 UDDI Registrars

A company interested in joining the UDDI community can register itself and its services in the UDDI registry. In Section 5.2.2, we discuss a simple example to do that. Usually, a fair amount of technical and business expertise is needed to register a complex business and its service portfolio. While it is possible for some companies to have the necessary expertise in-house, several companies may not have it. This could potentially slow down the adoption of UDDI.

To address this issue, a class of companies, called UDDI Registrars, has emerged. A UDDI registrar is a company that can perform the registrations on behalf of other companies. A registrar acts as a "consultant" to a company or business that wishes to list itself and its services in the UDDI registry. Such consulting would typically include:

  • Compiling business information

  • Defining the list of services to register

  • Determining the models that describe those services

UDDI registrars are functionally analogous to companies such as Register.com, Inc. (http://www.register.com). Register.com provides the basic services required to register a new Internet domain with the Internet Corporation for Assigned Names and Numbers (ICANN) — the corporation that oversees the management of the Internet domain name system. Besides the domain name registration, Register.com also provides other value-added services, such as domain hosting and Web page designing, through its partners.

There are several companies that are currently acting as UDDI registrars. Promi-nent among them are Peregrine Systems and Riskebiz Internet Services Inc. In the future, more companies are likely to play the role of registrars as UDDI becomes more popular among businesses worldwide.

Figure 5.10. Successful addition of service binding.
    [ Team LiB ]


5.3 UDDI Operators

The entire UBR functionality is based on the infrastructure created and maintained by the UDDI operators. For smoother operation of business registrations and discoveries, uniform operating procedures are essential. Becoming a UDDI operator thus requires adherence to several operational standards — those that are generally applicable to any Web site with high availability demands, as well as those that are specific to UDDI. As a result, there are only a few operators that form the UBR cloud.

5.3.1 Operator Specification

To bring uniformity among various UDDI operators, and to ensure high availability of the UBR, the UDDI project has defined a specification for potential UDDI operators. The UDDI Operator's Specification provides the details on several operational aspects of the UDDI registry instance. Some important aspects of this specification are:

  • Directory information management (storage, updates, and deletions)

  • Security (data replication and management, approved Certificate Authorities)

  • Inter-operator data replication requirements

  • Custody transfer (protocol for transfer of a business account from one operator to the other under various scenarios)

5.3.2 Operator Council

The operator council is comprised of the UBR operators. This group deals with the operational aspects of the UBR — such as uptime, compatibility, and interoperability. The council owns the UDDI Operator Agreement that defines the stipulations that all UBR operators must abide by. It also administers the UBR testing plan. This plan ensures that all UBR sites operate cohesively as part of the UBR cloud. A secondary purpose for the UDDI Operator Council is to be the first implementer of the specification and provide feedback to the UDDI Working Group. This feed-back not only adds to the over all quality of the current specification, but also guides future versions.


5.4 UDDI API Specification

As described in Section 5.2.2, it is possible to interact with a UDDI registry through a set of Web pages. Indeed, these Web pages simplify interacting with UDDI and in some cases are sufficient for some businesses. For example, it is possible for a small bakery owner (who does not have any dedicated computing infrastructure on site) to search for a paper company that can provide a certain type of paper carton suitable for packaging products. Once the shop owner discovers an appropriate paper company, through browser-based interaction, business interaction can continue through traditional means such as phone, fax, or simply on paper.

For some businesses, however, this may limit the interaction with the registry. Admittedly, browser-based interaction constricts the user to conduct a search or a service registration to the features provided on the Web page. Consider, for example, performing spell-check on the service description. This feature will most likely be absent from the Web pages at an operator site. UDDI provides Programmer's API Specification to develop custom-built tools based on customer needs.

The UDDI API specification is slightly different from other API specifications. One of the chief design principles used in UDDI is to keep it accessible to any business system — regardless of the underlying platform. Because of this, registry is available to any applications written in virtually any language — from COBOL to C#. This goal can be achieved through a different programming model called Document Exchange Model (DEM).

5.4.1 Document Exchange Model

A programming language provides the means to communicate data among various components of an application. The most commonly used mechanisms are passing parameters through function calls and object serialization. Technologies such as Common Object Request Broker Architecture (CORBA) also facilitate data communication between objects that are deployed across different computers — a technique called Remote Procedure Call (RPC). This type of programming model is called Network Object Model (NOM).

The DEM programming technique is different from NOM. It models the interaction between two "objects" as an exchange of a series of structured text documents, rather than chunks of data laid out in some language-specific format.

The DEM-based application design has several advantages over their NOM-based counterparts. Since a structured document can be parsed and understood by virtually any language, it is possible to facilitate interaction between any two objects (or applications) written in potentially incompatible languages. Table 5.1 provides comparison between the two techniques.

Table 5.1. Comparison Between NOM and DEM Programming Models

Network Object Model

Document Exchange Model

Supports tightly coupled architecture

Supports loosely coupled architecture

Suitable for programmatic interaction

Suitable for document-based interaction

Objects have state and behavior

Documents are stateless

Mostly suitable for short-lived interaction

Mostly suitable for long-lived interactions

Interface definition language (IDL) defines interaction interface

Document schemas and metadata define interaction interface

Code level method binding

Agreement on document semantics rather than interfaces

Uses language-specific protocols

Uses language-independent protocols

Works best in intranet environment

Can work in both intranet and Internet environment

As can be seen from this comparison, the DEM programming model is more suitable for intercompany interactions that are normally long-lived (completed over a long period of time) and happen across multiple firewalls on various platforms. At the root of the DEM model is a structured document. The extensible Markup Lan-guage (XML) has become a de facto standard for creating such documents.

The UDDI programming APIs are essentially the XML schemas for interacting with the UBR. Unlike typical programming APIs, the UDDI APIs provide the schemas for XML-based request and response documents. These APIs dictate how the XML document should be formatted to interact with the UDDI registry. For example, here is the syntax of the find_business API that is used to discover a business that matches certain criteria.

<find_business [maxRows="nn"] generic="2.0"
               xmlns="urn:uddi-org:api_v2" >
     [<findQualifiers/>]
     [<name/> [<name/>]... ]
     [<discoveryURLs/>]
     [<identifierBag/>]
     [<categoryBag/>]
     [<tModelBag/>]
</find_business>

We discuss individual tags such as categoryBag in greater detail in Chapter 7–9. However, at this point, it is important to note the nature of the UDDI APIs. These APIs also require that the XML document is, in fact, sent as a Simple Object Access Protocol (SOAP) message. The SOAP technology, which facilitates the RPC mechanism in the DEM world, is conceptually much the same as the traditional RPC mechanism in the NOM paradigm. Appendix G provides a summary of SOAP technology. The UDDI API specification further stipulates that the SOAP message be sent over the Hypertext Transfer Protocol (HTTP). Thus, the SOAP message over HTTP forms the fundamental transport protocol for any UDDI related interaction. A UBR instance, hosted by any operator, can understand and will respond in only a SOAP encoded message over HTTP.

5.4.2 Progression of the API Specification

The UDDI API specification has undergone changes as more and more functionality is added and changes are made to existing APIs. The first specification Version 1.0 was released in September 2000. The Version 2.0 specification was released in June 2001. The UDDI Working Group released the Version 3.0 specification in July of 2002.

This book deals primarily with the Version 2.0 specification, since that is the specification implemented by all existing UBR instances. Discussion of Version 3.0 has been included in Chapter 14.

5.4.3 API Categories

The UDDI APIs are classified in two main categories:

  • Inquiry APIs

  • Publish APIs

The Inquiry APIs, as the name suggests, are APIs used for querying a UDDI registry. The query can be used to discover either a business or more specifics about services offered by a specific business. The Publish APIs, on the other hand, are used to publish information about a business or its services.

5.4.4 Business Registration Information

The information published about a company (and its services) is at the center of effective participation of that company. The Inquiry APIs search the published information in order to return the appropriate businesses or services. Thus, registration owners must ensure sufficiency and accuracy of registration information. Registration information can be categorized in three ways:

  • White Pages

  • Yellow Pages

  • Green Pages

This type of categorization can be likened to their namesake in a phone directory.

White Pages

Information that is largely contact information about a company forms the White Pages category. This includes information such as the name of the company, its phone number and address, and any known company identifiers such as the DUNS number. The White Pages are analogous to a CORBA interface repository.

Yellow Pages

The Yellow Pages section delves into the services offered by a company. Because a company can offer several services, multiple Yellow Page entries may be found within a business — one set per service. Yellow Pages are equivalent to a CORBA trading service.

Green Pages

The Green Pages are a different category in the sense that they do not have a namesake in the phone directory system. The Green Pages section provides technical information about the services exposed by the companies. This technical information can be used by any user to interact with the exposed service. Green Pages can provide information about which standardized protocols or specifications a specific service abides by, so that its users can adjust their interaction sequence accordingly. Green Pages are analogous to a CORBA implementation repository.

UDDI defines a special metadata construct called tModel to describe the specifications that a service abides by. Each tModel corresponds to a certain specification (or version thereof) and thus is related to specific interaction interface (or interfaces) as mandated by that specification. Using the tModel associations of a service — called tModel bindings — a user of a service can readily determine the sequence of actions it must take to be able to communicate with the service. Conversely, it is also possible for a service user to narrow the search for a suitable service to only those services that support the tModels that the user understands. For example, a company may choose only those vendors that abide by the Roset-taNet [1] standard during the order fulfillment processes.

[1] RosettaNet is a consortium of more than 400 worldwide companies dedicated to creating, implementing, and promoting open e-business standards. These standards form a common e-business language, aligning processes between trading partners on a global basis.

The concept of a tModel is a very radical way of reducing the time required to ensure compatibility between a service and its users. tModels provide a common reference point for development teams across companies. They also can ease discussions regarding information flow between ecosystem entities. We discuss tModels in more details in Chapter 6.

Table 5.2 provides a summary of the three different levels of information. It is also important to note the relationship between the three information sets and how they are related.

Table 5.2. White, Yellow, and Green Pages in Perspective

White Pages

Yellow Pages

Green Pages

Business name

Contact information

Text Descriptions

Identifiers

Services

Product indexes

Geographic indexes

Industry codes

Service descriptions

Business processes

tModel Bindings

The Microsoft UBR provides an excellent example to bring out the relationship among these three information sets. It has published information in all these areas for the business entity "Microsoft Corporation."

5.4.5 The Microsoft Business Entity

The business entity Microsoft Corporation, is already registered at the Microsoft UBR site and is discoverable by any user. Figure 5.11 depicts the organization of this business entity.

Figure 5.11. The Microsoft Corporation business entity.

The business entity is the overarching element that has several elements, such as services, registered underneath. The business entity and the contact information form the White Pages section. The services themselves are part of the Yellow Pages category. Information pertinent to the Green Pages section, such as bindingTemplates and tModels, can also be found wherever applicable. For example, look at the Home Page service. The registered information is as follows:

Service Name: Home Page

Service Key: 17b29861-2f33-402c-98f0-fd16cf5b8e9c

Service Binding: http://www.microsoft.com

tModel Info: uddi-org:http


5.5 UDDI Best Practices

Participation in a UDDI registry raises many design considerations such as:

  • The type of information a business should expose about itself

  • The structure of services and subservices

  • The tModel or tModels to comply by

It is easy to see that there are several ways to register a business and its services on a UDDI registry, both from an architectural and a design point of view. The UDDI project addresses such issues by releasing Best Practices papers. For example, it addresses the question "What is the best way to model a suite of services that a business wants to expose to the outside world?" These guidelines, compiled together, provide a set of design templates that can be used during design phases. These guidelines are called Best Practices.

The UDDI project Web site provides an easy reference to the best practices documentation. The current set of guidelines is somewhat rudimentary in nature, but as UDDI matures, several additions to this compilation can be expected. These best practices are used throughout this book.


5.6 Complete UDDI Ecosystem

The complete UDDI ecosystem consists of several entities that are necessary for UDDI-based interactions to work seamlessly. Figure 5.12 depicts the ecosystem of UDDI registry players and the relationships among them.

Figure 5.12. UDDI ecosystem.

UDDI.org provides the foundation of this ecosystem with the API and operator specifications as well guidelines for designing services that use the registry. The UBR operators, such as Microsoft, create the public instantiation of the UDDI registry, while individual companies can create their own private registry instances. Standards bodies are responsible for defining tModels necessary for uniform interactivity across services in the same domain or functionality. Registrars provide the service registration expertise. Vendors and service providers can register their services by using such registrars. Together, these ecosystem members create an environment that can be used to discover the best services to meet their needs.


5.7 Language-Specific UDDI APIs

As described in Section 5.4.1, the UDDI API specification describes how to interact with a UDDI registry using XML documents. While this helps in bringing the language-independence necessary for widespread adoption, it does pose one limitation.

While structured documents, such as XML documents, are easy for computers to understand, human beings cannot process them well. Constructing or editing an XML document is a tedious and error-prone job for a person. Thus, it would be difficult to author an XML document that represents a find_business query and then decipher the XML response from the registry. For that, a user interface, such as a Web page or form, is necessary.

The need for a suitable user interface automatically implies the need for a programming language. To facilitate interaction between the user interface with a registry, a set of APIs are needed. For easy interoperability, these APIs should preferably be in the same programming language in which the user interface or any business logic is written. This need has given rise to several language-specific UDDI APIs. We describe some of the most common APIs. Figure 5.13 shows the relationship between language-specific APIs and the UDDI APIs. The language-specific APIs manage the XML communication for the application layer.

Figure 5.13. Language-specific API and UDDI API relationship.

5.7.1 UDDI4J

UDDI4J provides a set of Java APIs to interact with a UDDI registry. It is not the only Java API available today, but it is likely to be a dominant API due to endorsement from IBM and HP. The UDDI4J is an ongoing open source project. The programming examples provided in this book primarily use the UDDI4J APIs. We discuss these APIs in more detail in Chapters 7–9.

5.7.2 JAXR

The Java community also provides an answer to the need for Java APIs for a UDDI registry. The Java APIs for XML Registries (JAXR) effort, however, is an overar-ching initiative that aims at providing a uniform set of APIs for all XML registries including UDDI and ebXML. The JAXR APIs are currently available as an early access release.

5.7.3 .NET UDDI SDK

The .NET framework, announced and championed by Microsoft, provides support for the UDDI initiative. The .NET platform provides the Microsoft UDDI .NET SDK that helps in building UDDI client-side components using the .NET technology. The SDK provides APIs for languages that run in the .NET runtime.

While the UDDI registry can be used to register any services, it has been developed primarily with Web services in mind. Thus, to effectively use all the features available in UDDI, a good understanding of Web services technology is helpful. A complete in-depth discussion on Web services is beyond the scope of this book. In the next chapter, we provide a brief overview of the Web services concepts and the technologies used to develop them.


Chapter 6. Modeling for Registries

  • Modeling in UDDI

  • Modeling Service Providers

  • Modeling Services

  • Role of tModels

  • Service Bindings

  • Modeling Needs Beyond the Design Phase

  • Modeling Service Consumers

Modeling is an integral part of any software solution. In the software engineering world, a model provides an architectural representation of a real-world entity or process. In the context of business registries, such as Universal Description, Discovery and Integration (UDDI), such models could include organizational entities, businesses, and service interactions (in other words, service specifications).

Modeling in the business registry world does not include simply the services provided. Entities that participate as well as the services that are published or used are modeled. These models identify the relationships between the services and the business entities that manage them. They can also be used to define relationships among the business entities themselves. The service consumer, service provider, and parent entities or businesses need to be modeled themselves as well. Figure 6.1 depicts the entities and interactions that are typically modeled in a registry paradigm.

Figure 6.1. Modeling in a registry paradigm.
    [ Team LiB ]


6.1 Modeling in UDDI

The UDDI information model includes the following roles:

  • Provider: information about the entity that offers a service or set of services

  • Service: descriptive information about a service

  • Binding: technical information on how to interact with the service

  • tModel (technology model): service interaction specifications

The subsequent discussions in this chapter are focused on these roles. Notice that the service consumers themselves are not necessarily described. Although useful, the current UDDI specification does not mandate that a service consumer be registered as a business entity. Note that there are times when a service provider and a service consumer fall under the same logical business entity, but they are simply different functions within that single entity.


6.2 Modeling Service Providers

Service providers create the business logic of a service that is required to perform a specific function. While the responsibilities of a service provider in the real world vary from industry to industry, a high-level summary is as follows:

  • Design and develop services

  • Deploy the services

  • Register services with appropriate service registries

  • Form business-level engagements with potential consumers of services

  • Set up billing as appropriate

  • Monitor the performance of deployed services

  • Plan newer versions of the services

  • Create a strategy to support multiple service versions and facilitate migration for service consumers

  • Service obsolescence

Figure 6.2 depicts the process service providers go through in developing their services. Business modeling is very prominent primarily in the initial phases.

Figure 6.2. Responsibilities of a service provider.

UDDI provides a data structure that can model a service provider. It is the Business Entity data structure. Theoretically, it is possible for a legal business entity to create and register several business entities in a UDDI registry. However, from an architectural perspective, a one-to-one correspondence between a legal business entity and UDDI-registered business entity is a more sound design. In fact, Microsoft's UDDI production registry enforces this rule, by allowing only one business entity per user account, although the test site allows several business entities to be registered by a single legal business entity (or a single user).

The one-to-one relationship between a legal business entity and a UDDI-registered entity can make it easy for UDDI operators to manage business listings in a suitable manner. For service providers as well, such modeling theme streamlines the processes such as designing and managing portfolio of services. Several company-wide policies can be enforced uniformly across all the services, contacts, and other information maintained by the UDDI registry. Due to these advantages, we strongly recommend modeling the entire company under one Business Entity data structure. An exception to this design principle should only be made for very large companies. This is discussed in Section 6.6.1. Figure 6.3 depicts this relationship between legal and UDDI-registered business entities and the business entity metadata.

Figure 6.3. Relationship between a legal and UDDI-registered business entity.

There are several data elements associated with a UDDI business entity. These elements, together or alone, constitute the Yellow and White Page sections of the listing. Information such as contact name or phone number is part of the White Pages, while the taxonomy, under which the entity is categorized, constitutes the Yellow Pages. The complete list of data elements that are part of a UDDI-registered business entity can be found in the UDDI specification. Table 6.1 summarizes some of the key data elements.

Table 6.1. Data Elements Associated with a UDDI-Registered Business Entity

Element Name

Description

businessKey

A unique identifier of the business entity

operator

Operator site that manages the business entity

discoveryURLs

URLs associated with the business entity

name

Repeatable. Human-readable name associated with a business entity

description

Repeatable. Short business description

contacts

Repeatable. Set of contact names, phones, email addresses, and addresses

identifierBag

Set of identifiers such as taxID number, associated with the business entity

categoryBag

Taxonomy information used to categorize the business entity

The specifics of which elements are required and which elements are used in conjunction with others are also available in the UDDI specification.


6.3 Modeling Services

Designing services that can be registered in UDDI requires a different kind of planning than traditional application design practices. In addition to ubiquitous object-oriented design and functional decomposition, several new aspects must be tack-led. These design principles are a by-product of the service-based computing paradigm.

The UDDI registry aims at providing information regarding a business entity and a service that makes it easy for a service consumer to review metadata and technical information about both. While the metadata information is useful in forming a business relationship with the service provider, the technical information helps in understanding how the service interacts, the data format it uses, and the service bindings it supports. These two sets of information are essential for service discovery. From a service consumer perspective, searching for a suitable service can be narrowed down by several attributes. Chief among these attributes are taxonomies, service interaction interfaces, and service bindings. These elements are at the heart of service modeling.

6.3.1 Taxonomies

The first step of designing a service is to consider a set of taxonomies that the proposed service should belong to. The word taxonomy means a system of categorization. It denotes a formal approach used for categorization of any set of entities. Some of the examples of taxonomies are:

  • North American Industry Classification System (NAICS)

  • Universal Standard Products and Services Classification (UNSPSC)

  • Geographical (Geo)

  • Standard Industrial Classifications (SIC)

As a service provider, the choice of taxonomies to register the service under is important and is driven by the profile of the customer base and the business model of the service provider. For example, a service used by the banking industry should be classified within a taxonomy related to banking, whereas a service for consumers should be registered within a retail-related taxonomy.

We see how using taxonomies help service discovery when we discuss service consumers in Section 6.7. The UDDI project envisions three different types of taxonomies — industry, product or service type, and geographic.

Note

Services can be categorized within multiple applicable taxonomies. For example, a sales tax calculator service might be applicable in various industry or product type taxonomies as well as within a specific geography. UDDI allows a service to be categorized in an unlimited number of taxonomies at the same time.

Although UDDI has several popular taxonomies built-in and several others may be registered within the UBR by other standards bodies, it is possible that a service provider may find them inadequate or inapplicable for the specific service. In such a case, it is possible to register a new taxonomy that is tailored to the needs of the proposed service. UDDI provides the necessary Application Programming Interfaces (APIs) for this purpose. However, a decision to create a new taxonomy should be taken with utmost consideration to standards-compliance and the ability of potential service users to find the service. A service registered in a taxonomy that is not widely adopted or known will be rarely discovered and used. Once the decision to create a new taxonomy is made, taking it to standards bodies should also be considered to gain broader acceptance for it. At the very least, the taxonomy should be widely known and accepted within the relevant community, if not made into an industry standard. Two types of taxonomies can be registered with a UDDI registry — checked and unchecked. Unchecked taxonomies can be published by anybody at any time, while a checked taxonomy undergoes a thorough validation process. Checked taxonomies are explained in Chapter 10. UDDI APIs also provide the ability to register a service in several taxonomies at the same time. These APIs are discussed Chapters 7–9.

6.3.2 Service Interaction Interfaces

After the taxonomies for the service registration are determined, the next task a service provider must tackle is to determine the service interaction interfaces to adhere to. A service interaction interface is analogous to the API for an application. Like an API, it provides details such as various methods or function calls supported and the parameters used while invoking those methods. There may be possible invocation sequences associated with an interface described explicitly or implicitly. For well-known services within established industries, the interfaces may be already defined by standards bodies or consortiums. In such cases, the service designer may decide to abide by one or more of the published interfaces. For wider interoperability with several potential service consumers, it is desirable to adopt as many relevant published interfaces as possible. That way, a service consumer can choose the best suitable interface to interact with the service. This must be weighed against the investment required to implement the methods defined by different interfaces as well as the architectural constraints associated with them.

Like the taxonomies, service interfaces also require the "make vs. adopt" consideration. If there is no published or widely adopted interface for the specific service or if the service provider wishes to create a new service interface, it is possible to do so in UDDI. However, this puts the onus of popularizing the interface on the service provider itself. Usually, a service provider should adopt an existing interface, defined by relevant standards body or consortium. In the absence of a suitable interface definition, registering a new interface should be supplemented by initiatives for broader market adoption and taking the interface to a standards body. In Chapter 8, we discuss how to register the interface for a service and the related APIs.

Note

Services may comply with one or more than one interfaces and categorize within one or more than one taxonomy. The decision depends on the service consumer being targeted.

In the Web services realm, service interaction interfaces are described using Web Service Description Language (WSDL). WSDL provides all the necessary information about the messages a service should accept and the corresponding response. For the discussion in this book, we concentrate on the WSDL-based service interface definition. However, in the UDDI registry, it is possible to use other definitions as well. Table 6.2 shows some of the key data elements associated with the business service data structure.

Figure 6.4 depicts decision points that are required by a service provider while registering a service in the UDDI registry.

Figure 6.4. Decision points for service registration.

Table 6.2. Data Elements Associated with a Service

Element Name

Description

Required

businessKey

Unique identifier of the parent business entity of the service

Yes

serviceKey

A unique identifier of the service

Yes

name

Repeatable. Human-readable name associated with the service

Yes

description

Repeatable. Short service description

No

bindingTemplates

Structure that holds service binding information

Yes

categoryBag

Taxonomy information used to categorize the service

No


6.4 Role of tModels

From a design perspective, tModel is the UDDI structure to capture taxonomies as well as service interaction interfaces. The service provider would find or create and abide by various tModels. Recall from Chapter 5 that a tModel is a UDDI representation of certain specification (or version thereof). The specification, in this case, can denote either a taxonomy or a service interface definition. tModels can be thought of as technical fingerprints. Like fingerprints for human beings, they uniquely identify a certain entity. The UUID associated with a tModel can provide an accurate reference to a certain classification scheme or interaction interface. When teams from two or more companies work together on a business-to-business (B2B) integration project, tModels provide precise information about each company's compliance preference. When the tModels match exactly for two companies, the integration among their systems will be comparatively easy.

The implementation details of using tModel for taxonomy or service interface declaration are discussed in Chapter 8. Table 6.3 shows some of the key data elements associated with the business service data structure.


6.5 Service Bindings

Service bindings contain technical details of a service. Typically, they include the communication protocols supported, the service interaction interfaces abided by, and the service entry points. A service provider would normally aim at maximizing the usage of the service deployed. One of the attributes that can lead to a wider adoption of a service is support for various communication protocols. A service that is versatile and supports multiple protocols will be more accepted by potential service consumers. Service consumers may choose the communication protocol they find most suitable to interact with the service. UDDI provides a data structure bindingTemplate to express service bindings. Table 6.4 shows some of the key data elements associated with the service binding structure.

Table 6.3. Data Elements Associated with a tModel

Element Name

Description

Required

tModelKey

A unique identifier of the tModel

Yes

operator

Operator site that manages the tModel registration

Yes

name

Human-readable name associated with the tModel

Yes

description

Repeatable. One short tModel description per language

No

overviewDoc

A reference to information about the tModel and specification associated with it

No

identifierBag

Set of identifiers associated with the tModel

No

categoryBag

Taxonomy information used to categorize the tModel

No


6.6 Modeling Needs Beyond the Design Phase

While the initial modeling of a business entity and its services is done during the first few phases of the service lifecycle, modeling needs exist in other phases as well. Modeling in these cases ensures continuity of service and offers a smoother migration path when the service is phased out.

An access point for a service, as registered with a UDDI registry, is the same across all service consumers that discover it. Naturally, one instance of a service is unlikely to be able to cater to many clients. Thus, from an architectural point of view, the access point should be treated as an entry point for the service. The software component at this entry point would be responsible for creating an (dedicated) instance of the service logic as appropriate to serve a client.

Service billing can be very complicated and thus may significantly influence service modeling needs. The functionality that a service is intended to provide can have several options available — such as availability, maximum usage, and the number of options allowed. The revenue model can be based on these options. For example, a service might be available on a flat-fee, unlimited access option, while it may also be available on a per-transaction fee option. Based on the complexity and mutual exclusivity of the billing options, a service may be modeled in a registry as one or more services.

Table 6.4. Data Elements Associated with a Service Binding

Element Name

Description

Required

bindingKey

A unique identifier for the binding

Yes

description

Repeatable. Short binding description

No

accessPoint

Data about the service entry point. Could be URL, email, phone number

Yes

hostingRedirector

Reference to a different binding that contains service access information

Yes, if accessPoint is absent

tModelInstanceDetails

Reference to tModels that the service complies with under this binding

No

During the service lifecycle, there may be several versions that a service will go through as its functionality is enhanced. In some cases, it is desirable to keep the older version for business continuity; in other cases, it may be discontinued because it is no longer valid. Based on these needs, a new version of a service can be registered as a new service, or it can replace the old service registration. Versioning of services and tModels is discussed in detailed in Chapter 10.

6.6.1 Publisher Assertions

As discussed earlier, in a typical scenario, one-to-one correspondence between a legal business entity and a UDDI-registered business entity is recommended. In some cases, however, this design principle must be relaxed. In a large company, it is conceivable that there would be several business units with different goals, business models, or even markets. One such example is General Electric (GE). GE, as a business entity, is a holding company with several companies under its umbrella — for example, NBC (an entertainment company) and GE Finance (a financial services company). In this scenario, one business entity represents all the businesses the company is in.

It would be desirable that the UDDI-registered model in this case would provide the flexibility for different business units to register their business entity, while still maintaining relationship with a "parent" business entity. UDDI provides a construct called publisher assertions for this purpose. Figure 6.5 depicts a UDDI business entity model using publisher assertions.

Figure 6.5. Connecting business entities through publisher assertions.

Publisher assertions are used to make the relationship between various entities registered at a UDDI site visible. Using a set of publisher assertions, a holding company can relate it to all its constituent companies and vice versa. Publisher assertions is a two-way protocol that requires an approval (assertion) of the rela-tionship from either side. Thus, in this scenario, the business entity representing the holding company will signal its relationship with one of the constituent companies, which in turn will assert that the relationship exists. A service consumer, after discovering either of these companies, can get all the companies related to each other through the assertions.

The two-way nature of the assertion protocol avoids the scenario where a rogue business entity tries to assert itself as part some well-known and well-respected business entity. The confirming publisher assertion is only necessary when the businesses on each side of the relationship are published (owned) by different publishers. In the case where both the businesses are owned by the same publisher the confirming assertion is not necessary.

Note

Unless and until both the parties assert the relationship, it is not visible to anybody else. Only the controlling publisher of a business entity can initiate a publisher assertion for that entity.

Based on the discussion hitherto, we see that a legal entity can publish several services. In turn, each service can be classified in multiple taxonomies. Each service can also define multiple service bindings; each service binding specifies a different interaction mechanism. In addition, each business entity can be engaged in multiple publisher assertions. Figure 6.6 highlights these relationships.

Figure 6.6. High-level service provider model.
    [ Team LiB ]


6.7 Modeling Service Consumers

Like the service providers, service consumers also must follow a certain process to use registry-based services. The process begins with the identified need for a certain type of service or services and concludes with maintenance activity. The full process is as follows:

  • Identify the business needs for services

  • Search for appropriate service providers and form business relationships

  • Use appropriate services

  • Monitor the performance of services

  • Manage portfolio of services

  • Migrate a new service as appropriate

Figure 6.7 depicts the process service consumers go through in using services.

Figure 6.7. Responsibilities of a service consumer.

As mentioned earlier, the UDDI specification does not require a service consumer to be a registered entity. Thus, a potential service consumer need not go through the modeling exercise as far as business entity is concerned. However, it still needs models for its own processes and information requirements to be able to incorporate vendor services.

6.7.1 Fine-Tuning Business Processes

Incorporating the service-based interaction paradigm will undoubtedly require business process changes for a service consumer. The changes in the process can come in the form of adopting processes or formating standards related to the interaction, in identifying vendors and/or service functionality or service migration. Before a service consumer is ready to use a service, it must first address such process changes. Detailed process modeling is essential in this case. The effort typically varies based on the complexity of the processes. The need for services and related interactions emerges from this exercise.

6.7.2 Identifying tModels

Before a service consumer can use services from any service providers, it must first decide the categories of companies that will provide the required functionality. The choice of categories may be obvious in some industries while in others, a more thorough research may be required. When choosing a certain category, it should be broad enough to discover a good number of service providers, but narrow enough to pare down the number of qualifying companies. For example, when searching for a 401(k) provider, the "Financial Services" category may be too broad. A category such as "Third-party financial services for pension funds" would be a better choice.

Once an industry category (taxonomy) is chosen, the interaction standards must be selected as well. These standards will typically define the interaction sequence, specific operations, or workflow steps as well as data formats. Based on the business processes, and infrastructure, certain standards may lend themselves as a better choice than others. For example, if a company already has XML-savvy systems, XML-based standards are useful, while for others, EDI-based standards may be good to exchange information.

In UDDI, both these capabilities are expressed in the form of tModels. Thus, a choice of taxonomy and interaction model will boil down to choosing corresponding tModels. In Chapter 9, we discuss how service consumers discover tModels and services using the UDDI APIs.

6.7.3 Integrating Services

Once a set of service providers and services are determined, the next step required is the service integration model. A service consumer will typically have an existing infrastructure and applications into which these services are incorporated. Foraseamless experience, the discovered services must be integrated well with existing infrastructure. An advanced approach for this can call for building a service experience that is unique to the organization and its environment. Building such an experience may be easier with a set of standardized tools that can introspect the specifications associated with the concerned tModels. A good integration model should take into account the service delivery platforms, formats, and usage model.

Importing and Exporting Service References

Naturally, it is conceivable that once a search on suitable services is performed and they are discovered, there may not be a need to change the service provider forasignificant amount of time. It would be desirable in such a case to cache a service reference. A cached service reference will avoid the need to rediscover a service for every interaction with that service; it will also ensure that there is no error in choosing the right service.

The UBR does not provide a direct solution to this problem, as it is geared toward service publishers saving references to corresponding services. From a service consumer perspective, one solution for this is using a private UDDI registry as depicted in Figure 6.8.

Figure 6.8. Reference importing by a service consumer.

A private registry, such as one provided in Microsoft .NET Server, is an implementation of the UDDI specification that can be used as a private instance of a registry. The registry owner, in this case, would be free to keep any useful data for business entities and services. In case of reference caching, a service reference can be imported from a UBR node and kept locally. Every time there is a need to look up the service, the imported reference can be used.

The service consumer can in essence create a synonym for the found service or services. The synonym, in this case, could also carry some contextual information about service usage. Typically, this would include authentication and authorization policies.

A less likely but possible usage model could also be thought of when a service reference is exported to UBR. This usage is more likely with a service provider that chooses to publish its available services globally from its local portfolio.

Business modeling is an important task when adopting the service-based computing paradigm. It ensures that services and applications can discover and interact efficiently while also providing the brick-and-mortar entities behind the service interactions a means to exist in this paradigm. In Chapter 12, we present a case study that delves into the tactical specifics of business modeling for a supply chain environment.

In the next few chapters, we discuss the interaction with a UDDI registry using the UDDI APIs.


Chapter 7. Establishing Connection

  • Communication Points of a UDDI Registry

  • Establishing Connection

    example working directory: \Examples\Ex02GettingStarted

Interacting with a Universal Description Discovery Integration (UDDI) registry is accomplished using the UDDI eXtended Markup Language (XML)-based Application Programming Interfaces (APIs), as we discuss in Chapter 5. Once the business entity, its services, and the publisher relationships are modeled, as we describe in Chapter 6, applications can be developed to interact with the UDDI registry programmatically. Previously, we saw how manual interaction is possible using the Web-based interface provided by most UDDI implementations.

The UDDI applications in the next few chapters reflect the modeling decisions made during the design phase. The applications may be written in either .NET or Java programming paradigms. Recall that there are three language- or platform-specific APIs that relieve the developer from creating the appropriate UDDI XML messages to perform various UDDI functions:

  • UDDI .NET Software Development Kit (SDK)

  • UDDI4J

  • Java XML API for XML Registries (JAXR)

These APIs allow applications, based on a specific platform or language, to communicate with a UDDI registry. The UDDI registry could be either private or public. In the next few chapters, we explain how to use the UDDI4J and UDDI .NET SDK to perform the tasks of a service publisher and a service consumer. JAXR is a broader API that not only interacts with UDDI registries but other XML registries, for example, the ebXML Registry. JAXR is an evolving API specification and is not covered in this book. More information on JAXR can be obtained from Sun Microsystems and the Java Community Process (JCP) Web site.

In the following discussion on the UDDI .NET SDK APIs and UDDI4J, general familiarity of programming is assumed. The reader is also assumed to be well versed with Java and C# programming languages. Several resources are available for more information on these programming languages. To run the examples provided in this book, the software packages for the two APIs are required. Appendices B and D provide more information on how to obtain and install both of these packages.


7.1 Communication Points of a UDDI Registry

To demonstrate the use of the C# and Java APIs, we walk through the business case of a service provider that wishes to publish its service within the Universal Business Registry (UBR) and a service consumer that needs to find a specific service within the UBR and then caches it locally for frequent use. Figure 7.1 depicts the interaction patterns we demonstrate in the next few chapters.

Figure 7.1. Interaction patterns demonstrated through examples.

Before the business case can be demonstrated, however, a certain familiarity with the underlying APIs is essential. In this chapter, we focus on the foundational functionality such as submitting credentials and getting information from a UDDI registry through its communication points. The APIs associated with these functionalities are used throughout the rest of the book.

Noticeably, interaction with a UDDI registry via its communication points falls in two categories — publishing and inquiry. All the UDDI APIs can be classified into these categories. The communication points of the UDDI registry are also associated with these two categories: Publish URL and Inquiry URL. These URLs receive the corresponding UDDI API calls.

7.1.1 Publish APIs

The publish APIs receive publish information about a business entity and the services and interaction specifications it offers. The publish APIs use a dedicated Uniform Resource Locator (URL) called publish URL. The publish URL accepts XML messages that perform tasks, including:

  • Business entity registration (including deletion)

  • Service registration (including deletion)

  • Service binding definitions (including deletion)

  • Taxonomy registration (including deletion)

  • Interaction specification registration (including deletion)

  • Business relationships assertion (including deletion)

For a complete list, refer to the latest UDDI API Specification document. Figure 7.2 depicts the role of the Publish URL in a UDDI registry. The publish URLs for the UBR operators would normally take the following form:

Figure 7.2. UDDI interactions supported on publish URL.

uddi.mycompany.com/publish

Notice that these URLs provide secure communication because these URLs accept sensitive data such as username and password. This type of information must be encrypted when it travels over an open network such as the Internet.

7.1.2 Inquiry APIs

Like the publish APIs, the inquiry APIs also use a dedicated URL at a registry. This URL can be used to retrieve information about registered entities, such as businesses, services, and tModels, at the registry. The inquiry URL accepts XML messages to perform tasks, including:

  • Business entity discovery (and getting registration details)

  • Service discovery (and getting registration details)

  • Service binding discovery (and getting registration details)

  • Taxonomy discovery (and getting registration details)

  • Interaction specification discovery (and getting registration details)

  • Business relationships discovery

For a complete list, refer to the latest UDDI API Specification document. Figure 7.3 depicts the role of the inquiry URL in a UDDI registry.

Figure 7.3. UDDI interactions supported on inquiry URL.

The inquiry URLs for the UBR operators would normally take the following form:

uddi.mycompany.com/inquiry

Unlike the publish URL, the inquiry URL does not use a secure mode of communication. This is because the inquiry APIs do not require any sensitive data such as usernames and passwords. The information being retrieved is also considered public domain. The publisher should be careful about the kind of data that is published at a UDDI registry. Any user that has access to the registry, whether registered with the registry or not, can access the information published by the publisher. However, a private UDDI registry with greater access control may implement more restrictive policies. An invitation-only or elaborate registration process may precede access to the registry. We discuss private registries in greater detail in Chapter 10.


7.2 Establishing Connection

The GettingStarted applications test connectivity with both publish and inquiry URLs through the UDDI .NET SDK and UDDI4J software packages and thus provide a foundation for how to programmatically interact with a UDDI registry. The publish URL test consists of getting an authentication token from the UDDI registry and the inquiry URL test comprises of testing information retrieval from the UDDI registry.

7.2.1 UDDI .NET SDK

The C# test application GettingStarted.exe is the application that uses the UDDI .NET APIs to connect to the Microsoft UBR and test the UBR Publish and Inquiry URLs. Before we describe applications, we need to first explain the basics of programming with the UDDI .NET SDK APIs.

Incorporating UDDI .NET APIs

UDDI .NET SDK is used by adding a reference to the Microsoft.UDDI.SDK package in your Visual Studio .NET solution. This can be done via Project [image] Add Reference from the Visual Studio .NET menus. Adding references provides necessary information while compiling a program that uses certain functionality from a specific library.

Let's take a look at the GettingStarted.cs to review how to use the UDDI .NET SDK APIs in the test application. After adding the reference to the SDK, you also need to include the following declarations:

GettingStarted.cs
using Microsoft.Uddi;
using Microsoft.Uddi.Business;
using Microsoft.Uddi.Service;
using Microsoft.Uddi.Binding;
using Microsoft.Uddi.ServiceType;
using Microsoft.Uddi.Api;
using Microsoft.Uddi.Authentication;

These declarations ensure that the appropriate UDDI functionality is available to the application via the APIs. There is also a configuration file, app.config, that needs to be populated to run the .NET test application. Microsoft has migrated away from a text-based property file to an XML-formatted property file in the .NET environment. The properties take the following form:

<add key="settingName" value="settingValue"/>

In the publish URL test example, the configuration values required are the UDDI UBR username and password. These are required because only registered and authorized users are allowed to publish to the UBR.

App.config
<?xml version="1.0" encoding="Windows-1252"?>
<configuration>
  <appSettings>
    <add key="uddiUserName"
        value="uddi@insidewebservices.com" />
    <add key="uddiPassword" value="****" />
  </appSettings>
</configuration>

The UBR URLs are not set in this configuration file. Those are explicitly stated in the application, but may also be in a configuration file.

GettingStarted.cs
publishURL.Items.Add("https://uddi.rte.microsoft.com/publish");
inquiryURL.Items.Add("http://uddi.rte.microsoft.com/inquire");

We are now ready to dive into the actual code and see how to test the communication point URLs for the UBR using the UDDI .NET APIs.

Checking Publish Configuration

The APIs provided by the .NET SDK perform the same basic function as the UDDI4J APIs while being based on a different paradigm. The Publish methods are used to publish information to the registry. Publish.AuthenticationMode is required to force the authentication to happen at the UBR and not a third-party verification point. UDDI does allow integration with a stronger security mechanism as discussed in Chapter 10.

The API GetAuthToken processes and receives an authentication token from the UBR. Authentication tokens are evidence that an application has presented a valid username and password pair for use of the UBR. Subsequent interactions with the publish URL will require presentation of this token and, as such, it is important to obtain the authentication token prior to any other publish URL activity. The following code demonstrates the usage of these APIs:

GettingStarted.cs
Publish.AuthenticationMode =
   AuthenticationMode.UddiAuthentication;
Publish.Url = publishURL.Text;
Publish.User =
   ConfigurationSettings.AppSettings["uddiUserName"];
Publish.Password =
   ConfigurationSettings.AppSettings["uddiPassword"];
GetAuthToken gat = new GetAuthToken();
gat.UserID = Publish.User;
gat.Credentials = Publish.Password;
AuthToken at = gat.Send();
appendToMessageWindow("UDDI Operator:"+at.Operator);
appendToMessageWindow("\r\nAuthentication Token: \r\n\r\n" +
   at.AuthInfo);

Using the above code, we retrieve the authentication token as well as the UDDI operator name that we are interacting with. There are other Publish-type APIs that support the other publishing possible with the UDDI registry. These are discussed in Chapter 8.

Checking Inquiry Configuration

The UDDI .NET SDK provides APIs for discovering resources (services, businesses, tModels) that satisfy a certain criteria. In the example to test the inquiry URL, we discover the uddi-org:inquiry v2 tModel using the FindTModel method. There are several UDDI XML messages for different types of discovery. These other Find-type APIs are discussed in Chapter 9. In this example, we focus on establishing connection with the inquiry URL.

The array of tModels returned can be displayed reading the TmodelInfos values. The relevant code is shown below:

GettingStarted.cs
Inquire.Url = inquiryURL.Text;
FindTModel ftm = new FindTModel();
appendToMessageWindow("Searching for tModel
   \"uddi-org:inquiry_v2\"");
ftm.Name = "uddi-org:inquiry_v2";
TModelList tml = ftm.Send();

appendToMessageWindow("\r\nThe TModel Name: " +
   tml.TModelInfos[0].Name);
appendToMessageWindow("\r\nThe TModel Key: " +
   tml.TModelInfos[0].TModelKey);

Recall from Chapter 5 that the APIs essentially prevent the developer from having to manually format the relevant UDDI XML-messages. The XML messages created by the UDDI .NET APIs are very similar to those shown in the UDDI4J discussion.

7.2.2 In Action

After loading GettingStarted.cs in Visual Studio .NET, simply compile and execute. Successful execution of both the Test Publisher URL and Test Inquiry URL are shown in Figures 7.4 and 7.5.

Figure 7.4. Test publisher URL results.

Figure 7.5. Test inquiry URL results.

7.2.3 UDDI4J

The Java test application GettingStarted.class is the application that uses the UDDI4J APIs to connect to the Microsoft UBR and test the UBR URLs. UDDI4J needs to be configured as per the setup of your environment. For example, the firewall proxy needs to be identified, logging needs to be turned on or off, and so on. Appendix B explains properties that are used in setting up UDDI4J for all the example applications. The attributes configured are found in env.prop. Both these files are in the Shared subdirectory.

Checking Publish Configuration

There are two main UDDI4J APIs that we use to test the connectivity with the publish URL: UDDIProxy.get_authToken and UDDIProxy.get_registeredInfo.

GettingStarted.java
AuthToken token = proxy.get_authToken(p.getProperty("userid"),
   p.getProperty("password"));
...
RegisteredInfo ri =
    proxy.get_registeredInfo(token.getAuthInfoString());
System.out.println("\n\nUDDI Operator:"+ri.getOperator());

These calls get the authentication token that verifies the username and password and returns the UBR operator name you connected to. The get_authToken API forms the appropriate XML message to obtain an authentication token as discussed in the .NET example.

This API is used for UBRs or private registries that do not have some other method of obtaining an authentication token or certificate, or that choose to use username and password-based authentication. This method returns an authToken object that contains a valid authInfo object that is used in subsequent calls to publisher API calls that require an authInfo value.

Checking Inquiry Configuration

GettingStarted.class also contains the UDDI4J APIs to test the inquiry URL. To test the inquiry URL, we discover the UDDI V2 Inquiry tModel: uddi-org:inquiry v2. To discover this tModel, we use the UDDIProxy.find tModel and other APIs specifically geared for processing tModel information.

GettingStarted.java
TModelList tModelList =
  proxy.find_tModel("uddi-org:inquiry_v2", null, null, null, 5);
Vector tModelInfoVector =
  tModelList.getTModelInfos().getTModelInfoVector();
for (inti=0;i<tModelInfoVector.size(); i++)
{
...
}

The UDDIProxy.find_tModel API formats the XML message for locating a list of tModel entries that match a set of specific criteria. This method returns the list of tModels that fit your criteria. We discuss the find APIs in more detail in Chapter 9. This test application then displays the tModel name and key associated with it. A good test would be to match the returned tModel key with the uddi-org:inquiry_v2 key published in the UDDI specification. These two keys should match exactly.

As was the case in the .NET discussion, we explain the other important publish and inquiry UDDI4J APIs in the subsequent chapters.

7.2.4 In Action

Now that we are familiar with GettingStarted.java, let's run it and see it in action. To run the test application, execute the following command:

c:\> java GettingStarted

If the UBR URLs are fine and connectivity is established, you will see the authentication token, as well as the tModel described earlier. Figure 7.6 depicts successful completion of the GettingStarted application.

Figure 7.6. Successful completion of GettingStarted.

Now that we have seen the result of the test, we should peek behind the scenes to see what the UDDI4J APIs actually do. Recall that they create the UDDI-specified XML messages to interact with the registry. In this case, we need XML messages for the following:

  • Getting the authentication token

  • Discovering the tModels

The following XML messages were created by the get_AuthToken API to retrieve the authentication token from the UBR.

Request body:
<get_authToken cred="****" generic="2.0"
   userID=uddi@insidewebservices.com
   xmlns="urn:uddi-org:api_v2"/>

Response body:
<authToken generic="2.0" operator="Microsoft Corporation"
   xmlns="urn:uddi-org:api_v2">
   <authInfo> ... </authInfo>
</authToken>

The following XML messages were created by the get_registeredInfo API to retrieve information of all registered resources by the authenticated user from the UBR.

Request body:
<get_registeredInfo generic="2.0" xmlns="urn:uddi-org:api_v2">
   <authInfo>...</authInfo>
</get_registeredInfo>
Response body:
<registeredInfo generic="2.0" operator="Microsoft Corporation"
    xmlns="urn:uddi-rg:api_v2">
  <businessInfos>
    <businessInfo businessKey="...">
      ...
      <serviceInfos>
        <serviceInfo businessKey="..." serviceKey="...">
        ...
        </serviceInfo>
      </serviceInfos>
      ...
    </businessInfo>
    ...
  </businessInfos>

  <tModelInfos>
    <tModelInfo tModelKey="...">
    ...
    </tModelInfo>
  ...
  </tModelInfos>
</registeredInfo>

The following XML messages were created by the find_tModel API to discover the UDDI V2 tModel from the UBR.

Request body:
<find_tModel generic="2.0" maxRows="5"
   xmlns="urn:uddi-org:api_v2">
  <name>uddi-org:inquiry_v2</name>
</find_tModel>
Response body:
<tModelList generic="2.0" operator="Microsoft Corporation"
   truncated="false" xmlns="urn:uddi-org:api_v2">
  <tModelInfos>
     <tModelInfo tModelKey="uuid:ac104dcc-d623-
452f-88a7-f8acd94d9b2b">
      <name>uddi-org:inquiry_v2</name>
    </tModelInfo>
  </tModelInfos>
</tModelList>

In the next chapter, we explain how to interact with a UDDI registry as a publisher in more detail.


Chapter 8. UDDI Publishing

  • A Case in Point

  • Publishing a Business Entity

    example working directory: \Examples\Ex03RegisterBusiness

  • Publishing a Service Interaction Specification

    example working directory: \Examples\Ex04RegisterTModel

  • Publishing a Service

    example working directory: \Examples\Ex05RegisterService

  • Deleting from the Registry

    example working directory: \Examples\Ex06DeleteService

  • Putting It All Together

  • UDDI Data Structures

Publishing to the UDDI registry is the programmatic and electronic representation of the decisions made during the modeling phase. During the modeling phase, choices are made around categories to associate with and service interface specifications to comply with. It is in the publishing phase that these choices are translated into electronic representations for the UDDI registry.

To understand the UDDI publishing functionality, we build on the employee 401(k) example discussed previously. This scenario, with the help of several entities playing various roles, helps in demonstrating a typical process flow involved with the publishing in a UDDI registry.


8.1 A Case in Point

Financial Interactions and Transactions Standardization Organization (FITSO) is an established not-for-profit consortium of large financial institutions in North America, including pension fund providers. FITSO has embarked on a standardization effort to make interacting with financial service organizations simpler and more predictable. FITSO is currently focusing on pension fund providers and hopes to roll out the experience to other financial service areas thereafter. After investigating Web service standards and interaction patterns, FITSO decides that it needs to adopt and encourage two types of standards:

  • Classification scheme for business entities

  • Set of basic interaction patterns

8.1.1 Classification Scheme

The classification scheme allows like business entities to group together such that a service consumer can easily find all similar companies that provide services in the same area.

Given the familiarity of North American Industry Classification System (NAICS) in the financial industry, FITSO decides to recommend the NAICS classification scheme to classify the business entities behind the pension services. This taxonomy choice translates to using the NAICS tModel pre-loaded in the UDDI registry.

However, simply relating business entities to the NAICS classification scheme is not enough — that relation simply denotes the type of classification scheme to be used. Each business entity that uses the NAICS classification scheme should also register with the specific classification code as described by the NAICS specification. Accordingly, FITSO recommends companies handling pension funds be classified under the category "Pension fund, third party administrative services." Grouping business entities and their services under this classification gives service consumers a predictable mechanism to discover all pension fund entities and their services.

8.1.2 Pension Service Interaction Specification

Standardization at the business classification level is just one aspect to consider. FITSO has also decided to standardize on basic interactions as well. Service consumers would be able to develop applications that interact with the services; the vision is that applications designed to work with one service would easily interchange with another. Based on the types of interactions that are simple enough to standardize, FITSO designed a set of service interfaces for the pension fund services. For this example, we focus on the 401(k) information services specification. The functions that should be supported by a FITSO pension fund are as follows:

  • Get list of funds

  • Get fund performance

  • Add employee to a plan

  • Get employee contribution data

Recall that the service interaction specification translates into a tModel in the UDDI paradigm with a pointer to the appropriate Web Services Description Language (WSDL) document. In Section 8.3, we explain how FITSO registers the resultant tModel — TM401(k) — within the UDDI registry. This tModel represents the aforementioned interactions.

8.1.3 Prudentially 401(k) Provider

Prudentially 401(k), Inc. is a subsidiary of a global financial services conglomerate that specializes in providing pension fund management services to its clients. The company has established a large clientele through the years and it is one of the founding members of the FITSO organization.

Being one of FITSO's most influential members, Prudentially 401(k), Inc. was naturally one of the first pension fund providers to apply for the new compliance. To be a FITSO-compliant pension fund service provider, FITSO mandates that all pension fund services embark on providing Pension Fund Web services that are registered in the stated categories and abide by the FITSO service interaction specification. In order to achieve compliance, the business planner within Prudentially 401(k), Inc. determined that the business entity and the services needed to be modeled as described in Table 8.1.

Table 8.1. FITSO Compliance-Based Prudentially 401(k), Inc. Modeling

Model

UDDI representation

Business

Entity: Prudentially 401(k), Inc.

Classification

NAICS

Subclassification

524292

Service

Prudentially401kInformationService()

Interface Specification

TM401k

In the next three sections, we explain the mechanics behind making these modeling decisions a reality within the UDDI registry.


8.2 Publishing a Business Entity

Before its services can be published, Prudentially 401(k), Inc. needs to register its business entity with the UDDI registry. This registered entity assumes ownership of the services registered thereafter. Service consumers who discover services applicable to their needs can then search for the responsible entity to get more information about the service provider. This is discussed in greater detail in Chapter 9. The UDDI .NET SDK and UDDI4J software packages provide APIs to register business entities with the registry.

Note

In our examples, we register our information with Microsoft's UDDI Version 2 test site; however, the APIs (and examples) can be used almost as is with another UBR or a privately-deployed UDDI registry.

8.2.1 UDDI .NET SDK

Refer to Chapter 7 and Appendix D for how to set up the UDDI .NET SDK packages and configure them for use. As in Chapter 7, it is important to specify the entry point URL of the registry in question.

RegisterBusinessForm.cs
publishURL.Items.Add("https://uddi.rte.microsoft.com/publish");

Recall that publish activities require user name and password for authentication and the resulting authentication token. The user name and password information is used from the file app.config as explained in Chapter 7.

RegisterBusinessForm.cs
Publish.AuthenticationMode =
   AuthenticationMode.UddiAuthentication;
Publish.Url = publishURL.Text;
Publish.User =
   ConfigurationSettings.AppSettings["uddiUserName"];
Publish.Password =
   ConfigurationSettings.AppSettings["uddiPassword"];

The UDDI .NET API for registering a business entity is the SaveBusiness. Using this object and its methods, a business entity structure is populated. As seen in the following code, attributes including Names, Descriptions, DiscoveryUrls, and Contact are populated to build the business entity object. For the purpose of this example, all these attributes are populated through user input in the corresponding text boxes.

RegisterBusinessForm.cs
 SaveBusiness sb = new SaveBusiness();

// Add business information
sb.BusinessEntities.Add();
sb.BusinessEntities[0].Names.Add("en", businessNameBox.Text);
sb.BusinessEntities[0].Descriptions.Add
   ("en", descriptionTextBox.Text);
sb.BusinessEntities[0].DiscoveryUrls.Add
   (URLTextBox.Text, "http");

//Add contact
Contact c = new Contact(contactNameBox.Text, "Contact");
c.Phones.Add(contactPhoneBox.Text, "");
sb.BusinessEntities[0].Contacts.Add(c);

For the human-readable description associated with any attribute, the UDDI specification allows one description per language code. The applicable language codes are defined by the Internet Engineering Task Force (IETF) standard known as Request For Comment (RFC) 1766. This code can consist of one or more parts — a primary language code and a (possibly empty) series of sub-tags for country or dialect identification. The specification for the language codes can be found at http://www.ietf.org/rfc/rfc1766.txt. This example uses the code en that denotes the English language. Chapter 10 discusses the internationalization issues where language codes can play an important role. The language tag is optional in a description and the UDDI registry operator can decide a default language code to attach in such a case.

The discovery Uniform Resource Locator (URL) associated with an entity must conform to the URL format. Each URL must be associated with its type. Table 8.2 provides a quick summary of the types supported by the UDDI specification. In this example, the URL type is assumed to be http.

Prudentially 401(k), Inc. needs to classify itself under the NAICS taxonomy and the Pension Fund classification code, 524292, because of the FITSO specification. For each classification, three data elements are required — the tModel key that is associated with the classification scheme, the key name under which the entity is classified, and the value or code associated with the key. A data structure keyedReference holds these three elements together. The UDDI specification provides another data structure categoryBag, where multiple such classifications for a given entity can be specified. For registration of the Prudentially 401(k), Inc. business entity the following values must be used:

Reference tModel key: uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2

Key Name : Pension fund, third party administrative services

KeyValue: 524292

The reference key, in this case, refers to the NAICS tModel, pre-loaded on a UDDI registry. The code for pension funds and the precise description string is provided in the NAICS specification. The Web site http://www.naics.com provides Web-based tools for searching the codes for other industries.

RegisterBusinessForm.cs
//Add taxonomy tModel
KeyedReference kr = new KeyedReference();
kr.TModelKey = tModelUUIDBox.Text;
kr.KeyName = classificationNameBox.Text;
kr.KeyValue = classificationNumberBox.Text;
sb.BusinessEntities[0].CategoryBag.Add(kr);

Table 8.2. UDDI-Supported URL Types

URL Type

Description

mailto

Designates an electronic mail address reference, for example, mailto:uddi@insidewebservices.com.

http

Designates a URL compatible with Hypertext Transfer Protocol (HTTP), for example, http://www.insidewebservices.com.

https

Designates a URL compatible with secure HTTP, for example, https://www.insidewebservices.com.

ftp

Designates a File Transfer Protocol (FTP) directory address, for example, ftp://ftp.insidewebservices.com.

fax

Designates a telephone number that connects to a facsimile machine, for example, 1 408 555 5555.

phone

Designates a telephone number that connects to a telephone or other voice- or tone-based system, for example 1 408 555 5555.

other

A catch-all format. For this format, one or more of the associated tModel IDs must specify a particular format or transport type.

Although, not used in this example, a business entity should also specify the set of identifiers, such as DUNS identifiers, that can uniquely identify the entity. Even though providing these identifiers is optional, they help in precision of a discovered entity. Like the classification scheme, the UDDI specification does not mandate any identification scheme. However, the DUNS identification system as well as the Thomas Register Supplier Code System are pre-loaded in a UDDI registry. The UDDI Programmer's Reference Guide provides more detail on these as well as the associated tModels. The process for specifying an identifier is similar to the one for categories. The data structure identifierBag is used to hold the keyedReference elements with specific identifiers.

Finally, the business entity is published using the Send method. As discussed previously, the interaction with a UDDI registry happens through XML messages over the HTTP protocol. The Send method is responsible for this interaction. The exact XML message can be viewed through the ToString method of the SaveBusiness class.

RegisterBusinessForm.cs
appendToMessageWindow(sb.ToString());
BusinessDetail bd = sb.Send();

After the UDDI registry receives and processes the XML messages created by the UDDI .NET APIs, a UUID key is returned. This key is a unique identifier associated with the business entity that was registered. The response from the registry is also in XML format. Upon successful business entity registration, the response message can be parsed to display information pertaining to the registration such as the assigned key and the UDDI operator that manages the registration.

RegisterBusinessForm.cs
AppendToMessageWindow
   ("\r\n\r\nOperator:"+bd.BusinessEntities[0].Operator);
appendToMessageWindow("\r\nAssigned Business key:"+
   bd.BusinessEntities[0].BusinessKey);

8.2.2 In Action

The .NET example, RegisterBusinessForm.exe, uses a windows-based information entry design. However, all the business entity registration information pertaining to Prudentially 401(k), Inc.'s registration could have just as easily been placed in a property file. The application could then have been designed to be a console application that used a property file rather than manual data entry. The Java examples are written in the console-style with property file information.

Run the RegisterBusiness.exe application and then proceed to enter the information required to register the business. Recall that the business entity model (and taxonomy model) is populated with this information. Figure 8.1 depicts the information mandated by FITSO-compliant pension service providers regarding classification of the business entity.

Figure 8.1. Business entity registration for Prudentially 401(k), Inc.

After you have entered information in all three tabs, click on Register Business. Figure 8.2 depicts the successful results of registering the Prudentially 401(k), Inc. business entity.

Figure 8.2. Successful registration of Prudentially 401(k), Inc. business entity.

We discuss the associated XML messages that were sent to the UDDI registry to carry out the business entity registration during the UDDI4J discussion.

8.2.3 UDDI4J

The RegisterBusiness.java contains the application logic to register the Prudentially 401(k), Inc. business entity using the UDDI4J APIs. All the registration information is located in the property file, Prudentially401kInc.prop.

Prudentially401k.prop
BusinessName=Prudentially401(k), Inc.
DiscoveryURL=http://www.insidewebservices.com/Prudentially401k
Description=Prudentially401k, Inc. is known for outstanding
   service to its customers for their 401(k) needs.
ContactName=John Doe
ContactPhone=212-555-1212
# Contact email could be added in a way similar to contact
# phone.
# ContactEmail=

# Taxonomy to classify. A business entity can be classified
#in several taxonomies at the same time.

# NAICS (1997)
TModelKey=uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2
ClassificationName=Pension fund, third party administrative
   services
ClassificationNumber=524292

The first steps to publishing business entity information with the UDDI registry remain similar to the .NET discussion. We need to specify the publish URL as well as obtain an authentication token via the user name and password.

RegisterBusiness.java
proxy.setInquiryURL(p.getProperty("inquiryURL"));
proxy.setPublishURL(p.getProperty("publishURL"));

AuthToken token = proxy.get_authToken(p.getProperty("userid"),
   p.getProperty("password"));

Now we need to construct the business entity object using the properties in the property file and the UDDI4J APIs. As before, we populate the object with business entity details such as name, contact, and discovery URL, but we also need to classify the business entity. Note that the BusinessEntity object is instantiated with null key. This is a trigger for the UDDI registry to treat this as a new registration and assign a key. If a key is provided, the transaction is treated as an update of an existing entity associated with the specified key.

RegisterBusiness.java
BusinessEntity be = new BusinessEntity("", businessName);
be.setDiscoveryURLs(new DiscoveryURLs
   (createBusinessURLVector(bep, "DiscoveryURL")));
be.setDescriptionVector(createDescriptionVector
   (bep, "Description"));
Contacts cs = new Contacts();
cs.setContactVector(createContactVector(bep));
be.setContacts(cs);

The classification information is located in the property file and is based on the FITSO classification scheme. A CategoryBag object is used to store the classification information. Notice that this object, similar to the .NET objects, holds a collection of keyedReference objects.

RegisterBusiness.java
CategoryBag cb = new CategoryBag();
cb.setKeyedReferenceVector(createCategoryVector(bep));
be.setCategoryBag(cb);

Finally, the proxy.save_business API registers the business entity object in the UDDI registry. Successful registration results in a business key being assigned by the registry to the business entity. This information as well as the responsible operator name can be extracted from the response message.

RegisterBusiness.java
entities.add(be);

BusinessDetail bd =
   proxy.save_business(token.getAuthInfoString(),entities);
Vector businessEntities = bd.getBusinessEntityVector();
BusinessEntity returnedBusinessEntity =
   (BusinessEntity)(businessEntities.elementAt(0));
System.out.println("\n\nRegistry-assigned Business Key : " +
   returnedBusinessEntity.getBusinessKey());

8.2.4 In Action

To run the Java example for registering the business entity, use the command following:

c:\>java RegisterBusiness Prudentially401k.prop

When the application is successful, the business key is returned.

Registry-assigned Business Key:
   954eb479-cdbd-445b-b7a2-de33625ac015

The request and response XML messages that are exchanged by the UDDI .NET SDK and UDDI4J for publishing a business entity to the UDDI registry are as follows.

Request body:
<save_business generic="2.0" xmlns="urn:uddi-org:api_v2">
  <authInfo>...</authInfo>
  <businessEntity businessKey="">
    <discoveryURLs>
      <discoveryURL useType="">
         http://www.insidewebservices.com/Prudentially401k
      </discoveryURL>
    </discoveryURLs>
    <name>Prudentially401k, Inc.</name>
    <description>Prudentially401(k), Inc. is known for outstanding
       service to its customers for their 401(k) needs.
    </description>
    <contacts>
      <contact>
        <personName>John Doe</personName>
        <phone>212-555-1212</phone>
      </contact>
    </contacts>
    <categoryBag>
      <keyedReference keyName="Pension fund, third party
         administrative services" keyValue="524292"
         tModelKey="uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"/>
    </categoryBag>
  </businessEntity>
</save_business>
Response body:
<businessDetail generic="2.0" operator="Microsoft Corporation"
   truncated="false" xmlns="urn:uddi-org:api_v2">
  <businessEntity authorizedName="Inside Webservices"
     businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
     operator="Microsoft Corporation">
    ...
    ...
  </businessEntity>
</businessDetail>

Notice that the businessKey tag in the request message is empty, signifying a new registration. The response message contains the assigned key. This message also has an attribute authorizedName that signifies the owning account that sent the registration message.


8.3 Publishing a Service Interaction Specification

Recall that FITSO developed a service interaction specification, TM401k, for the pension fund 401(k) information services. This interaction specification needs to be registered in UDDI as a tModel. The UDDI .NET SDK as well as the UDDI4J APIs both provide APIs for register tModel decisions with the UDDI registry.

8.3.1 UDDI .NET SDK

The file RegisterTModelForm.cs contains the application logic to register the FITSO tModel with the UDDI registry. A look at the code shows that the main API is the SaveTModel class. This class is used for registering (and modifying) a tModel. As with the business entity class, described in Section 8.2, the tModel object model needs to be populated before being saved in the UDDI registry.

RegisterTModelForm.cs
SaveTModel stm = new SaveTModel();

stm.TModels.Add();
stm.TModels[0].Name = tModelNameBox.Text;
stm.TModels[0].Descriptions.Add
   ("en", descriptionTextBox.Text);
stm.TModels[0].OverviewDoc.OverviewURL =
   overviewDocTextBox.Text;

//Add category bag conditionally
if (tModelUUIDBox.Text != "")
{
stm.TModels[0].CategoryBag.Add();
stm.TModels[0].CategoryBag[0].TModelKey =
   tModelUUIDBox.Text;
stm.TModels[0].CategoryBag[0].KeyName =
   classificationNameBox.Text;
stm.TModels[0].CategoryBag[0].KeyValue =
   classificationValueBox.Text;
}
appendToMessageWindow(stm.ToString());
TModelDetail tmd = stm.Send();

The data elements associated with tModel registration are similar to that with a business entity registration — such as name, description, and category. The data structures are also similar to those associated with business entity registration. We can access the returned tModel key as follows:

RegisterTModelForm.cs
appendToMessageWindow("\r\nRegistry-assigned tModel Key: " +
   tmd.TModels[0].TModelKey);

The tModelKey is a unique identification key that is generated by the UDDI registry when a tModel object is registered successfully. As before, the generated UDDI XML messages are depicted in the UDDI4J discussion.

8.3.2 In Action

Run the RegisterTModelForm.exe and enter the values pertaining to the tModel you are registering. In our example, we continue with FITSO's tModel registration and register the tModel for FITSO compliant services to use. Figure 8.3 depicts the process, as well as the resulting tModelkey.

Figure 8.3. Registration of FITSO tModel for 401(k) information services.

The fact that we saw the tModelKey is evidence of successful registration; however, you may also visit the UDDI Web site and ensure visually that the tModel is successfully registered.

8.3.3 UDDI4J

The file RegisterTModel.java contains the application logic to register the FITSO tModel with the UDDI registry using the UDDI4J APIs. Notice again that the main API for registering the tModel with the UDDI registry is the save_tModel method of the UDDIProxy class. This method is used for registering (and modifying) a tModel with the registry.

As described in Section 8.2, the related tModel object needs to be populated before being saved in the UDDI registry. The TM401k.prop file contains the properties for the tModel to be registered. These properties are used to populate the tModel object.

RegisterTModel.java
Vector tModels = new Vector();
TModel tModel = new TModel("", TMp.getProperty("TMName"));

tModel.setDefaultDescriptionString
   (TMp.getProperty("TMDescription"));
OverviewDoc od = new OverviewDoc();
od.setOverviewURL(TMp.getProperty("TMOverviewDoc"));
tModel.setOverviewDoc(od);

CategoryBag cb = new CategoryBag();
cb.setKeyedReferenceVector(createCategoryVector(TMp));
tModel.setCategoryBag(cb);
TModelDetail tModelDetail =
   proxy.save_tModel(token.getAuthInfoString(), tModels);

Vector tModelVector = tModelDetail.getTModelVector();
TModel tModelReturned = (TModel)(tModelVector.elementAt(0));
System.out.println("\n\nRegistry-assigned tModel Key : " +
   tModelReturned.getTModelKey());

8.3.4 In Action

To run the Java example for registering a tModel, use the following command:

c:\>java RegisterTModel TM401k.prop

The registry-assigned tModel key will be displayed upon successful execution of the program.

Request body:
<save_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
  <authInfo>...</authInfo>
  <tModel tModelKey="">
    <name>TM401k</name>
    <description>
       tModel defined by FITSO for 401(k) interactions
    </description>
    <overviewDoc>
      <overviewURL>
         http://www.insideWebServices/FITSO/TM401k.wsdl
      </overviewURL>
    </overviewDoc>
    <categoryBag>
      <keyedReference keyName="KEYWORD" keyValue="401(k)"
        tModelKey="uuid:A035A07C-F362-44dd-8F95-E2B134BF43B4"/>
      </categoryBag>
  </tModel>
</save_tModel>
Response body:
<tModelDetail generic="2.0" operator="Microsoft Corporation"
   truncated="false" xmlns="urn:uddi-org:api_v2">
  <tModel authorizedName="Inside Webservices"
     operator="Microsoft Corporation"
     tModelKey="uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549">
  ...
  </tModel>
</tModelDetail>
Registry-assigned tModel Key:
   uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549


8.4 Publishing a Service

At this point, Prudentially401(k), Inc. is ready to publish its 401(k) information service P401kService with the UDDI registry. The business logic for the P401kService is similar to what is described in Chapter 3 and is compliant with FITSO's service interaction specification. In this section, we explain the usage of the UDDI .NET APIs and UDDI4J APIs to publish the service to the UDDI registry.

8.4.1 UDDI .NET SDK

An authenticated application (i.e., possessing an authentication token) needs to publish service information through the publish URL. Following a similar pattern, the main API for publishing a service to the UDDI registry is SaveService using the UDDI .NET SDK. Using the SaveService class methods, the service object needs to be populated with the service details. One additional service detail to note is the field BusinessKey. The BusinessKey links the service to the responsible or publishing business entity. In this case, we link the P401Kservice to the Prundentially401(k), Inc. business entity. Hence, the BusinessKey returned when the business entity was registered should be stored. This key will also be required in establishing relationships with other business entities as we discuss in the Publisher Assertions section of Chapter 6.

RegisterServiceForm.cs
SaveService ss = new SaveService();
ss.BusinessServices.Add();
ss.BusinessServices[0].Names.Add("en", serviceNameBox.Text);
ss.BusinessServices[0].Descriptions.Add
   ("en", descriptionTextBox.Text);
ss.BusinessServices[0].BusinessKey =
   parentBusinessKeyBox.Text;

As part of registering a service, it is also important to register the service entry point and the service interface specification that the service complies with. Publishing the service entry point allows service consumers to directly access the service after discovery. Prudentially401(k)'s service complies with FITSO's tModel (registered in the previous section). Populating the service object with this information is accomplished by providing information to another class, bindingTemplate, as part of the service object.

The bindingTemplate stores the technical fingerprint of the tModel that the service complies with. Recall that FITSO received a tModel key when it registered the service interaction specification. This key needs to be shared between the interaction specification publisher and all complying services. The following code exemplifies how to populate the binding template. The class TmodelInstanceInfo holds information about a tModel that the service complies with. Just like the taxonomies, several tModels can be complied with, by a service.

RegisterServiceForm.cs
BindingTemplate bt = new BindingTemplate();
bt.AccessPoint = new
   AccessPoint(Microsoft.Uddi.Api.URLType.Http,
      accessPointBox.Text);
TModelInstanceInfo tmii = new TModelInstanceInfo();
tmii.TModelKey = complianceTModelBox.Text;
bt.TModelInstanceDetail.TModelInstanceInfos.Add(tmii);
ss.BusinessServices[0].BindingTemplates.Add(bt);

Similar to registering a business entity, it is also important to classify the service in the same fashion that we further classified the business entity, i.e.,for ease of use. This service is further classified under general_keywords taxonomy. This is a preloaded tModel that is available in the UDDI registry. It allows you to associate a keyword with your service. Upon publishing, we link this service to the keyword 401k. The process is very similar to what we did when we registered the business entity. The classification name used in the example is KEYWORD and the value associated with it is 401k.

RegisterServiceForm.cs
KeyedReference kr = new KeyedReference();
kr.TModelKey = tModelUUIDBox.Text;
kr.KeyName = classificationNameBox.Text;
kr.KeyValue = classificationValueBox.Text;
ss.BusinessServices[0].CategoryBag.Add(kr);

Finally, the returned ServiceKey is displayed. As is the case with other unique identifiers, it is good practice to store this information. It could be used in the future, for example, in Chapter 10, we see how it is used for reference caching.

RegisterServiceForm.cs
appendToMessageWindow("\r\nRegisry-assigned Service key:"+
   sd.BusinessServices[0].ServiceKey);

8.4.2 In Action

In the final example in this chapter, RegisterBusiness.exe, we enter the details that are required to register the service. The notable difference in publishing a service as compared to the other resources is the binding information. In Figure 8.4 we show the information required to publish the P401kService in the UDDI registry. Note the compliance tModel Key. This is the tModel key for the FITSO service interaction specification registered previously. The access point is also denoted in this example.

Figure 8.4. Binding information for service.

The Taxonomy tab contains the general_keyword taxonomy information that will allow the service to be discovered using the 401k keyword. Finally, the Service Details tab contains basic service information and the business key information, which links the service, its responsible business entity. Thus, when a service consumer discovers the service, it can also review the responsible business entity to learn more about the entity providing the discovered service. Figure 8.5 depicts the successful execution of this application.

Figure 8.5. Successful service publication.

Notice that a service key is returned in this case as well. The UDDI registry returns any errors in the execution; these are displayed in the text box. Appendix C contains information about errors and some basic troubleshooting techniques for the UDDI registry.

8.4.3 UDDI4J

The UDDI4J APIs for publishing a service to the UDDI registry are very similar to the UDDI .NET SDK APIs. The procedure to publish a service using the UDDI4J APIs requires a similar service object to be populated with the service details, binding information, and taxonomy details. As is the case with other UDDI4J examples, a property file contains the specifics on the service to be published. In this case, Prudentially401(k), Inc. publishes a service with the property file P401kService.prop.

As is the case with the UDDI .NET SDK example, the BindingTemplate needs to be populated with the service access point as well as the appropriate tModel. The code below builds the BindingTemplate object.

RegisterService.java
public static Vector createBindingTemplateVector(Properties p)
{
Vector resultVector = new Vector();
BindingTemplate bt = new BindingTemplate();
bt.setAccessPoint(new
   AccessPoint(p.getProperty("AccessPoint"), "http"));
bt.setBindingKey("");
TModelInstanceDetails tmid = new TModelInstanceDetails();
tmid.setTModelInstanceInfoVector
   (createTModelInstanceInfoVector(p));
bt.setTModelInstanceDetails(tmid);
resultVector.add(bt);
return resultVector;
}

The CategoryBag needs to be populated with the classification scheme as well. From the property file, you will notice that this service is being further classified in the general_keyword taxonomy; this will allow it to be classified by keyword 401k as well.

RegisterService.java
public static Vector createCategoryVector(Properties p)
{
Vector resultVector = new Vector();
KeyedReference kr = new
   KeyedReference(p.getProperty
   ("ClassificationName"), p.getProperty("ClassificationValue"));
kr.setTModelKey(p.getProperty("CategoryTModelKey"));
resultVector.add(kr);
return resultVector;
}

Finally, the objects are put together to build the services object, which contains all the information required to publish the service. The UDDIProxy.save_service method publishes the service to the UDDI registry. Recall again that the authentication token is required for any publishing to the registry.

RegisterService.java
ServiceDetail sd =
   proxy.save_service(token.getAuthInfoString(),services);

A service key is returned to the application upon successful registration. However, it is also important to store the key as it may be used for subsequent transactions. In this case, we display the key for verification that the publish attempt was successful.

RegisterService.java
BusinessService bsReturned =
   (BusinessService)(businessServices.elementAt(0));
String serviceKey = bsReturned.getServiceKey();
System.out.println("\n\nRegistry-assigned Service Key : " +
   bsReturned.getServiceKey());

8.4.4 In Action

To run the Java example for publishing the P401kService, use the following command:

c:\>java RegisterService P401kService.prop

The XML request and response messages exchanged during the service registration process are as follows:

Request body:
<save_service generic="2.0" xmlns="urn:uddi-org:api_v2">
  <authInfo>...</authInfo>
  <businessService
     businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
        serviceKey="">
    <name>P401kServiceJava</name>
    <description>
     401(k) management service by Prudentially401(k), Inc. abiding
      by the FITSO TM401k tModel
    </description>
    <bindingTemplates>
      <bindingTemplate bindingKey="">
        <accessPoint URLType="http">
          http://www.insidewebservices.com/Prudentially401k/
             P401kService
        </accessPoint>
        <tModelInstanceDetails>
          <tModelInstanceInfo
            tModelKey="uuid:587a1d4f-d94e-4aa0-949c-
                cf527ed45328"/>
        </tModelInstanceDetails>
      </bindingTemplate>
    </bindingTemplates>
    <categoryBag>
      <keyedReference keyName="KEYWORD"
         keyValue="401(k)"
          tModelKey="uuid:A035A07C-F362-44dd-8F95-E2B134BF43B4"/>
    </categoryBag>
  </businessService>
</save_service>
Response body:
<serviceDetail generic="2.0" operator="Microsoft Corporation"
   truncated="false" xmlns="urn:uddi-org:api_v2">
  <businessService
      businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
      serviceKey="c33b39e7-7054-45f2-986e-413db139fb38">
    ...
  </businessService>
</serviceDetail>

The Service Key that is returned should be stored locally. More importantly, the unique key is proof that the service was published successfully and that it is now ready for service consumers to discover it.

Registry-assigned Service Key:
   c33b39e7-7054-45f2-986e-413db139fb38


8.5 Deleting from the Registry

The UDDI specification also provides delete functionality which can be used to retire any resources that no longer need to be advertised. The corresponding APIs in .NET and UDDI4J require appropriate authentication to delete a resource and the unique identifier key. Ideally, the publisher would have a list of all the resource identifier keys. If not, the publisher could find the resource, obtain its identifier key, and then delete it from the registry. It must be noted that simply obtaining the identifier key of a resource does not provide any ownership over the resource. The identifier key is merely a unique reference to the resource. The UDDI registry establishes ownership relationships within the registry itself. Therefore, only the UDDI user that published a resource to the registry can delete it.

Note

Because a UDDI entity is linked to the particular publisher that saved it; another publisher, whether registered at the same or different nodes in the registry, will not be able to delete the entity.

In the example below we demonstrate how to delete a service. Other UDDI-registered resources such as binding template, tModel, and business entity can be deleted in a similar manner using corresponding APIs and classes. Because tModels are extensively referenced in the UDDI data model, they cannot simply be deleted from the registry. When a delete_tModel API is invoked, the specified tModel is "hidden." This means that the deleted tModel cannot be discovered using find_tModel, but the details can still be obtained using get_tModel. By removing the discoverability of the tModel, its further use is hindered, yet at the same time, existing users can continue to use it. The only way to completely remove a tModel is to petition the operator where the tModel was saved. Business relationships also have peculiar deletion behavior. See Section 6.6.1 for more details on the behavior of business relationships and publisher assertion.

8.5.1 UDDI .NET SDK

The class DeleteService handles deletion of a service. The chief piece of information required to delete a resource, such as the service, is its unique identifier key.

DeleteServiceForm.cs
//Prepare the DeleteService object
DeleteService ds = new DeleteService();
ds.ServiceKeys.Add(serviceKeyBox.Text);

Once the DeleteService class is initialized, the delete request can be sent through the Send method. Unlike other APIs discussed so far, the deletion APIs return an XML message that generally provides information on any errors during the transaction. The class dispositionReport holds any such messages. Upon successful deletion, however, this class object returns a single message signaling successful execution. The success code as defined in the UDDI specification is E_success.

DeleteServiceForm.cs
DispositionReport dr = ds.Send();

//Check if the service was successfully deleted
if(dr.Results[0].ErrInfo.ErrCode.Equals("E_success"))
{
   appendToMessageWindow("Service deleted successfully");
}
else
{
   appendToMessageWindow("Error in service deletion.
      Error text follows ...");
   appendToMessageWindow(dr.Results[0].ToString());
}

8.5.2 In Action

Run the program DeleteServiceForm.exe and enter the service key for the service that needs to be deleted after choosing the publish URL. Once the Delete Service button is clicked, the status of the request is shown in the text box at the bottom of the window. Figure 8.6 shows the successful deletion of a service.

Figure 8.6. Deleting a service.

8.5.3 UDDI4J

UDDI4J also provides similar APIs for deleting a resource. Providing the authentication token and the identifier key is required to delete a resource from the UDDI registry. Typically, the UDDI4J APIs for deleting a resource take the form of delete_resource. The property file DeleteService.prop stores the identification key of the resource to be deleted. The code from the example below demonstrates the use of the delete_service API.

DeleteService.java
DispositionReport dr =
   proxy.delete_service(token.getAuthInfoString(),
   dsp.getProperty("ServiceKey"));

Successful deletion of the resource returned by the registry.

8.5.4 In Action

Use the following command to run the Java example to delete a service:

c:\>java DeleteService DeleteService.prop

The UDDI XML messages that are generated by the UDDI4J APIs are very similar to the XML messages generated by the UDDI .NET SDK APIs. The following XML messages are generated for deleting a service from the UDDI registry.

Request body:
<delete_service generic="2.0" xmlns="urn:uddi-org:api_v2">
  <authInfo>...</authInfo>
  <serviceKey>
     c33b39e7-7054-45f2-986e-413db139fb38
  </serviceKey>
</delete_service>
Response body:
<dispositionReport generic="2.0" operator="Microsoft Corporation"
xmlns="urn:uddi-org:api_v2">
  <result errno="0">
    <errInfo errCode="E_success"/>
  </result>
</dispositionReport>

If this deletes successfully, a confirmation note is displayed:

Service deleted successfully


8.6 Putting It All Together

The process of publishing business and service modeling decisions within the UDDI registry boils down to registering a resource (business entity, service, interaction specification, or classification scheme) in the registry with desired details. The links that need to be made electronically from one resource to another is accomplished through the exchange of unique identifiers or resource keys that are generated upon successful registration of a resource. For example, it is important for the business entity key to be provided during the service registration process; this links the service with its responsible entity.

Also, the process revolves around populating the resource objects (business entity, service, or tModel) so that the XML messages can be generated with details of the resource to be published. The unique identifiers returned from the UDDI registry are evidence that the publishing task was successful; however, for a visual check, it is also possible to use the Web browser-based interface to the registry and visibly check that all your resources were published satisfactorily. Figure 8.7 shows the Web browser-based view of all the published resources in Microsoft's beta UDDI site.

Figure 8.7. Summary of published resources.
    [ Team LiB ]


8.7 UDDI Data Structures

In the examples discussed in this chapter, several UDDI-based resources such as a business entity and a tModel are used. During the registration of these resources, several data elements associated with these resources can be used. The XML-based data structure is the best format that can describe the organization of data elements associated with these resources. These structures also define inter-resource relationships as well.

8.7.1 Containment

The containment principle, used for UDDI data structure design, defines how different resources are related to each other. For example, a business entity structure can have several service structures contained within it. In essence, containment defines the parent–child relationships between the resources and corresponding data structures.

As a design principle, no single instance of a core data structure is contained by more than one parent data structure. Thus, only a business entity structure will ever contain information about a specific service instance.

Note

References within a data structure are pointers to a specific instance of a resource such as a tModel. Typically, references are expressed using the identifier key of the concerned resource (e.g., tModel key). The references are not limited by the containment principle. They can be referenced within any number of structures. Thus, an interaction specification tModel can be referenced within several service structures.

8.7.2 Data Sufficiency

Although data structures for the UDDI resources can contain several data elements, not all of them are necessary to instantiate (register) a resource within the UDDI registry. In the examples in this chapter, we have used only a subset of the data elements to describe the resources such as business entities and services. Of course, some of the data elements are mandatory. The XML schema associated with the data structure provides information on which fields are optional and which are mandatory. For example, the business entity structure schema is as follows:

<element name = "businessEntity">
  <complexType>
    <sequence>
      <element ref = "discoveryURLs" minOccurs = "0"/>
      <element ref = "name" maxOccurs = "unbounded"/>
      <element ref = "description" minOccurs = "0"
         maxOccurs = "unbounded"/>
      <element ref = "contacts" minOccurs = "0"/>
      <element ref = "businessServices" minOccurs = "0"/>
      <element ref = "identifierBag" minOccurs = "0"/>
      <element ref = "categoryBag" minOccurs = "0"/>
    </sequence>
    <attribute ref = "businessKey" use = "required"/>
    <attribute ref = "operator"/>
    <attribute ref = "authorizedName">
  </complexType>
</element>

As can be seen from the schema, the element Name is required to register a business entity, while description is optional. The UDDI Version 2.0 Data Structure Reference specifies the XML schemas for all the resources used in this chapter. During registration, the UDDI registry checks for the data sufficiency for a resource being registered.

In the next chapter, we discuss inquiry APIs in detail.


Chapter 9. UDDI Inquiry

  • Inquiry Process

  • FITSO Revisited

  • Discovering a Service Interaction Specification

    example working directory: \Examples\Ex07FindServiceInterface

  • Discovering a Service

    example working directory: \Examples\Ex08FindService

  • Discovering a Business Entity

    example working directory: \Examples\Ex09FindBusiness

  • Search Qualifiers

  • Using Discovered Services

Inquiries to the UDDI registry may be Web browser-based; however, the UDDI registry is designed to support programmatic inquiries as well. Much of the focus on modeling is a result of needing to be able to ensure that resources are easily locatable within the registry. Classifying the business entity and its services appropriately aids service consumers in the discovery process. Had browser-based inquiry been the only supported mechanism, modeling would not be so critical because manual review of the registry would allow the service consumer to locate the service. However, in order for an application to discover a particular service with minimal manual intervention, it is important for a structure to be in place that supports the path to the service(s) desired. The classification and service interaction specifications provide just that structure. Business entities and services are classified within this framework and the inquiry process navigates this structure during the modeling phase described in Chapter 6. Figure 9.1 depicts this framework.

Figure 9.1. Inquiry structure in the UDDI registry.
    [ Team LiB ]


9.1 Inquiry Process

The process of finding a service depends on the information available regarding the type or class of services to be discovered. The UDDI specification provides several APIs to discover various resources registered within the registry. We discuss the following types of queries in this chapter:

  • Find service interface (tModel)

  • Find service

  • Find business entity

Recall from Chapter 8 that many details are published along with the main resource (whether that resource be a service, business entity, or a tModel). Many of these details are searchable, including:

  • Name

  • Category key

  • Unique identifier key

  • tModel complied with

  • Parent resource

A service consumer application can be designed to search on any number or combination of these types of details. However, the UDDI registry is designed ideally for use in an ecosystem paradigm. As discussed in Chapter 3, an ecosystem is usually powered by a governing body. This governing body helps to set up the structure that business entities participate in. The most typical scenario that a service consumer application would design for is as follows:

  • Find all the relevant service interaction specifications

  • Choose one which seems to suit your needs

  • Find all the services that comply with that particular service interaction specification

  • Choose a service that is most suitable

  • Find the responsible business entities for the discovered services

Figure 9.2 depicts this typical sequence.

Figure 9.2. Ecosystem-based inquiry.

It is possible that a service consumer has an existing relationship with a service provider and wants to search for all of its services. In this case, the inquiry process may simply include searching for all services provided by business entity. This sequence is depicted in Figure 9.3.

Figure 9.3. Business entity-based inquiry.
    [ Team LiB ]


9.2 FITSO Revisited

Financial Interactions and Transactions Standardization Organization (FITSO) is the consortium that mandates use of a service interaction specification for 401(k) services as described in Chapter 8. FITSO is recognized not only for its diligent financial policies but also its use of leading-edge software technologies.

FITSO is a strong consortium with the top tier 401(k) providers in the industry. Because of its adoption of the Web services paradigm, FITSO service consumer applications can query the UDDI registry for pension service providers that are FITSO-compliant. FITSO ensures that its mandates are well-known so that enterprise customers understand how to engage FITSO-compliant pension service providers.

9.2.1 AmericanCorporation, Inc. Service Consumer

American Corporation, Inc. (ACI) is a company with a sizeable workforce. Having recently decided to offer its employees 401(k) plans, ACI researches the pension fund industry and comes to the conclusion that FITSO compliancy is an important criteria in selection. ACI has determined it will work with only FITSO-compliant 401(k) service providers.

In the next three sections, we explain the electronic inquiry process supported by the UDDI registry and the UDDI-compliant APIs (UDDI .NET SDK and UDDI4J).


9.3 Discovering a Service Interaction Specification

In Figure 9.2, we depict a typical inquiry sequence a service consumer would go through. Usually that starts with only knowing that you are looking for services that abide by a certain interaction specification. In this example, ACI is looking for services that comply with the specification TM401k that FITSO published to the UDDI registry. Recall that this specification provides guidance on what features FITSO-compliant 401(k) service providers should include. Both UDDI .NET and UDDI4J provide APIs for constructing a query with a UDDI registry.

9.3.1 UDDI .NET SDK

The logic for finding a service interaction specification is found in FindSvcIntfForm.cs. Calls made to the inquiry URL are not secured because no authentication is required to interact with it — especially in the case of the UBR we use in the examples. The main configuration that is required is to denote the inquiry URL to communicate with. As in Chapter 8, we use Microsoft's UBR for the inquiry examples.

FindSvcIntfForm.cs
inquireURL.Items.Add("http://uddi.rte.microsoft.com/inquire");

The class FindTModel is the starting point to find a tModel. It provides several methods to construct queries on the registry to search tModels. Queries can be designed to handle a broad-based search of interaction specifications and classification schemes as well as a more refined search where more information about the interaction specification is known. In our example, the broader case simply uses a wildcard search and searches for characters in the name of the specification tModels published in the registry; whereas the refined search is category-based.

Broad-Based Search

A broad-based search is not always sufficient. One of the goals of XML-based registries is to assist in the electronic decision-making process. Simply doing a wildcard search of this nature would require a manual decision process as to which of the found interaction specifications to continue with. Given no other guidance, a manual decision process would be the only option. Entities such as consortiums and governing bodies should provide more details as to how to reach the exact interaction specification. Ideally, they would provide the following:

  • Interaction specification name

  • Classification scheme and details

Refined Search

FITSO provides this information in their specification. Using these guidelines, ACI can refine its search to locate interaction specifications with a specific name and classification type. Recall that in Chapter 8, the TM401k specification was published within the general_keyword taxonomy. The keyword provided was 401k. Using this additional information, the inquiry can be refined. Behind the scenes, a CategoryBag structure is constructed to store the additional information and prepare the appropriate inquiry XML to run on the UDDI registry. The Send method communicates the query to the UDDI registry.

FindSvcIntfForm.cs
//Add category bag conditionally
if (tModelUUIDBox.Text != "")
{
   ftm.CategoryBag.Add();
   ftm.CategoryBag[0].TModelKey = tModelUUIDBox.Text;
   ftm.CategoryBag[0].KeyName = classificationNameBox.Text;
   ftm.CategoryBag[0].KeyValue = classificationValueBox.Text;
}
TModelList tml = ftm.Send();
foreach( TModelInfo tmi in tml.TModelInfos )
{
searchResults.Nodes.Add(tmi.Name);
searchResults.Nodes[tml.TModelInfos.IndexOf( tmi )].Tag =
         tmi.TModelKey;
}

Notice the last portion of code in the preceding code segment. While rendering the Graphical User Interface (GUI) on the screen with the discovered tModel information, it also stores each tModel's unique identifier key in the Tag attribute. This is a direct link to each of the discovered tModels. Observe that we use the Tag attribute when requesting more details on each tModel. The following code segment uses the unique identifier and the class GetTModelDetail to display the description and overview documents associated with each tModel.

FindSvcIntfForm.cs
private void get_tmodelDetail()
{
// Get tModel details
GetTModelDetail gtmd = new GetTModelDetail();
gtmd.TModelKeys.Add( searchResults.SelectedNode.Tag.ToString());
TModelDetail tmd = gtmd.Send();
...

The results can be rendered in a hierarchical Graphical User Interface (GUI) view. The following code makes that possible.

FindSvcIntfForm.cs
foreach( TModelInfo tmi in tml.TModelInfos )
{
   searchResults.Nodes.Add(tmi.Name);
   ...
}

9.3.2 In Action

Run the file FindSvcIntf.exe and enter the values pertaining to the tModel you are looking for. In our example, we continue with FITSO's tModel and search for tModels that satisfy the criteria in Table 9.1.

Table 9.1. FITSO Compliance-Based Prudentially 401(k) Modeling

Model

UDDI representation

tModel Name

Name includes characters "401k"

Category tModel Key

Key for general_tModel

Classification Name

KEYWORD

Classification Value

401k

Figure 9.4 displays the results of the broad-based wildcard-based search. Figure 9.5 displays the results of the refined search. Notice that the results are much more in line with what ACI was looking for — i.e., the FITSO tModel.

Figure 9.4. Broad-based search results for searching for FITSO tModel.

Figure 9.5. Results for searching for FITSO tModel.

9.3.3 UDDI4J

The file FindSvcIntf.java contains the application logic to find the FITSO tModel using the UDDI4J APIs. All the information pertinent to what is being searched for is located in the property file findTModel.prop.

findTModel.prop
#A partial name string to be used during search.
#Note that % is used as a wildcard
TMSearchName=%401%k%
# Taxonomy to classify.
# uddi-org:general_keywords
CategoryTModelKey=uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549
ClassificationName=KEYWORD
ClassificationValue=401(k)

In the UDDI .NET SDK example, we demonstrated how a simple wildcard search could lead to a chaotic set of results. In this UDDI4J-based example, we simply execute a refined search from the start. The first step to searching the UDDI registry remains similar to the .NET discussion. We need to specify the inquiry URL.

FindSvcIntf.java
proxy.setInquiryURL(p.getProperty("inquiryURL"));

Now we need to construct the query object using the properties in the property file and the UDDI4J APIs. After obtaining the tModel name and category information to search with, the UDDIProxy.find_tModel API generates the appropriate UDDI XML messages and executes the query on the registry via the inquiry URL. Notice that there is an artificial upper limit of 5 placed on the maximum number of returned tModels. The choice of number 5 is completely arbitrary. When developing a real-world solution, other appropriate upper limits, commensurate with expected results, should be specified.

FindSvcIntf.java
String searchName = TMp.getProperty("TMSearchName");
//Add category bag conditionally. Other parameters can be added
// conditionally in a similar manner.
CategoryBag cb = null;
if(TMp.getProperty("CategoryTModelKey") != null);
{
cb = new CategoryBag();
cb.setKeyedReferenceVector(createCategoryVector(TMp));
}
TModelList tl = proxy.find_tModel(searchName, cb, null,null,5);

The find_tModel method returns information on all the tModels that match the search criteria. It is important to note that the default behavior for the find APIs is that the search criteria are logically ANDed; thus, any resource found satisfies all the search criteria. Later in the Section 9.6, we discuss how this behavior can be modified using search qualifiers.

To display the details associated with each tModel, methods like getNameString, getTModelKey, and other such get* methods are used as in the following code section. The method UDDIProxy.get_tModelDetail is used to get more details about the found tModels. Using the vector of these tModel objects, more details such as the description and overview document for each tModel can be found.

FindSvcIntf.java
System.out.println("tModel Name:"+tmi.getNameString());
System.out.println("tModel Key:"+tmi.getTModelKey());
TModelDetail tmd = proxy.get_tModelDetail(tmi.getTModelKey());
Vector tmv = tmd.getTModelVector();
//Get Description and overviewDoc for the tModel
if(tmv.size()>0)
{
TModel tm = (TModel) tmv.elementAt(0);
System.out.println("Default Description: " +
   tm.getDefaultDescriptionString());
System.out.println("Overview URL: " +
   tm.getOverviewDoc().getOverviewURLString());
}

Finding the right tModel and traversing through the details (description, name, overview document) can ensure that the appropriate tModel key is obtained. This tModel key will propagate through the find process to locate a service or set of services that ultimately solves the business problem at hand. In our example, the ultimate goal is to locate the set of FITSO-compliant 401(k) services.

9.3.4 In Action

To run the Java example for finding a service interaction specification, use the following command:

C:\>java FindSvcIntf FindTModel.prop

When the application is successful, a set of tModels is returned. We show a sample of the results in the following segment:

-----------------------------------------------
tModel Name: TM401k
tModel Key: uuid:81fc0c86-f61c-4f9c-b926-af478640b2c4
Default Description: tModel defined by FITSO for 401(k)
   interactions
Overview URL: http://www.insideWebServices/FITSO/TM401k.wsdl
-----------------------------------------------
tModel Name: TM401k_dotnet
tModel Key: uuid:3b7ad07a-ef53-48c0-a1c0-a93ea7a48125
Default Description: tModel defined by FITSO for 401(k)
   interactions
Overview URL: http://www.insideWebServices/FITSO/TM401k.wsdl
-----------------------------------------------

The request and response XML messages that are exchanged by the UDDI .NET SDK and UDDI4J for finding a tModel in the UDDI registry are as follows:

Request body:
<find_tModel generic="2.0" maxRows="5"
  xmlns="urn:uddi-org:api_v2">
  <name>%401%k%</name>
  <categoryBag>
    <keyedReference keyName="KEYWORD" keyValue="401(k)"
       tModelKey="uuid:A035A07C-F362-44dd-8F95-E2B134BF43B4"/>
  </categoryBag>
</find_tModel>
Response body:
<tModelList generic="2.0" operator="Microsoft Corporation"
   truncated="false" xmlns="urn:uddi-org:api_v2">
  <tModelInfos>
    <tModelInfo
       tModelKey="uuid:81fc0c86-f61c-4f9c-b926-af478640b2c4">
      <name>TM401k</name>
    </tModelInfo>
    ...
  </tModelInfos>
</tModelList>
Request body:
<get_tModelDetail generic="2.0" xmlns="urn:uddi-org:api_v2">
  <tModelKey>
     uuid:81fc0c86-f61c-4f9c-b926-af478640b2c4
  </tModelKey>
</get_tModelDetail>
Response body:
<tModelDetail generic="2.0" operator="Microsoft Corporation"
   truncated="false" xmlns="urn:uddi-org:api_v2">
  <tModel authorizedName="Inside Webservices"
   operator="Microsoft Corporation"
   tModelKey="uuid:81fc0c86-f61c-4f9c-b926-af478640b2c4">
    <name>TM401k</name>
    <description xml:lang="en">
       tModel defined by FITSO for 401(k) interactions
    </description>
    <overviewDoc>
      <overviewURL>
         http://www.insideWebServices/FITSO/TM401k.wsdl
      </overviewURL>
    </overviewDoc>
    <categoryBag>
      <keyedReference keyName="KEYWORD" keyValue="401(k)"
       tModelKey="uuid:a035a07c-f362-44dd-8f95-e2b134bf43b4"/>
    </categoryBag>
  </tModel>
</tModelDetail>

After reviewing the results, the FITSO TM401k tmodel key is obtained. In our case, that tModel key is uuid:81fc0c86-f61c-4f9c-b926-af478640b2c4. This key will be different when the reader runs the example.


9.4 Discovering a Service

After obtaining the appropriate tModel key for the service interface specification, we can find the services that comply with that specific tModel. For the sake of explanation, we call this the compliance tModel. In this example, the FITSO TM401(k) tmodel is the compliance tModel. Discovering a service is very similar to the process for discovering a tModel (or even a business). It requires constructing a query with the help of the UDDI .NET SDK and UDDI4J APIs.

9.4.1 UDDI .NET SDK

FindServiceForm.cs contains the logic for finding a service. Constructing the search query is fairly similar to that of the query for finding a tModel. Note that we now have the compliance tModel key from tModel discovery as discussed previously in this chapter. Using the service name and the compliance tModel key, we can locate one or more of the services that comply with the FITSO tModel.

FindService.cs
FindService fs = new FindService();
fs.Names.Add(serviceNameBox.Text);
if(tModelUUIDBox.Text != "")
{
fs.TModelKeys.Add(tModelUUIDBox.Text);
}
appendToMessageWindow(fs.ToString());
ServiceList sl = fs.Send();

While we have not constructed a query based on the CategoryBag structure as we did for tModels, a similar approach can be used. Queries based on categories would be useful if we were searching for a genre of services rather than a set of services that complied with a specific service interaction specification. Such a capability is very useful in situations where there is no consortium or governing body standards. In such cases, searching for a class of services might help to refine the search to some extent. For example, if FITSO had not defined a service interaction specification, a search could have been constructed to search for services classified under the NAICS classification with the pension fund classification code.

The results of the query return the service name as well as the service identification keys. These keys are useful because they provide direct access to the service for future use. In Chapter 10, we discuss the concept of service reference import and export.

FindService.cs
GetServiceDetail gsd = new GetServiceDetail();
gsd.ServiceKeys.Add(searchResults.SelectedNode.Tag.ToString());
ServiceDetail sd = gsd.Send();
...
TreeNode tn1 = new TreeNode( "Responsible Business" );
GetBusinessDetail gbd = new GetBusinessDetail();
gbd.BusinessKeys.Add(bs.BusinessKey);
BusinessDetail bd = gbd.Send();

foreach( BusinessEntity be in bd.BusinessEntities )
tn1.Nodes.Add(be.Names[0].Text);

Additional service details may be obtained for the services that result from the posed query, with the registry using the GetServiceDetail class. Most notable in these details is the business key and the business entity name of the responsible business entity that is returned. Using this business key, it is possible to obtain further information on the business entity that is responsible for the service.

9.4.2 In Action

The find service example is the FindService.exe application. Run it to see the we provide two options: name and compliance tModel identification key. Using GUI provided for constructing a query with the UDDI registry. In this example, a blank or very broad range of wildcards for the service name will broaden the search within the compliance category. In this example, we search for any services with 401(k) in the name complying with the compliance tModel key for the FITSO tModel. Figure 9.6 depicts the results of running this search.

Figure 9.6. Results of service search.

Providing a specific name and the compliance tModel key will result in only one service returned. This would be useful if an exact pointer to a specific service is desired as described earlier.

9.4.3 UDDI4J

UDDI4J provides APIs similar to the UDDI .NET SDK APIs for discovering a service. The service search parameters are located in the property file, FindSer-vice.prop, as is the case in other examples as well. We search for all services with 401(k) in the name that comply with the FITSO tModel, as can be seen by the property file.

The method UDDIProxy.find_service takes the search parameters and returns the list of matching services. Recall that the default AND behavior can be overridden using search qualifiers, as discussed in Section 9.6.

FindService.java
TModelBag tmb = new TModelBag();
tmb.setTModelKeyVector(createTModelVector(Svcp));
Vector names = new Vector();
names.add(new Name(Svcp.getProperty("ServiceSearchName")));

ServiceList sl = proxy.find_service(null,names,null,tmb,null,5);

As was the case in the UDDI .NET example, it is possible to get more details about the services returned using the get* methods. Important among the returned details is the business entity information.

FindService.java
Vector sinfv = sl.getServiceInfos().getServiceInfoVector();
System.out.println("Service Name:"+si.getNameString());
System.out.println("Service Key:"+si.getServiceKey());
BusinessDetail bd =
   proxy.get_businessDetail(si.getBusinessKey());
BusinessEntity be =
   (BusinessEntity) bd.getBusinessEntityVector().elementAt(0);
System.out.println("Business Name: "+
   be.getDefaultNameString());

It is possible to go one step further and also get a binding template associated with the discovered service. This binding template can provide information about the service access point, which can be used to communicate with the service.

9.4.4 In Action

To run the Java example for finding a service, use the following command:

C:\>java FindService FindService.prop

When the application is successful, a set of services that match the search criteria is returned. We show a sample of the results in the following segment:

-----------------------------------------------
Service Name: P401kService_DOTNET
Service Key: fcc48a77-8f8c-4bd3-a1d1-17a599648705
Business Name: Prudentially401k, Inc.
-----------------------------------------------

The request and response XML messages that are exchanged by the UDDI .NET SDK and UDDI4J for finding a service in the UDDI registry are as follows.

Request body:
<find_service generic="2.0" maxRows="5"
   xmlns="urn:uddi-org:api_v2">
  <name>%401%k%</name>
  <tModelBag>
    <tModelKey>
      uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549
    </tModelKey>
  </tModelBag>
</find_service>
Response body:
<serviceList generic="2.0" operator="Microsoft Corporation"
   truncated="false" xmlns="urn:uddi-org:api_v2">
  <serviceInfos>
    <serviceInfo
       businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
       serviceKey="fcc48a77-8f8c-4bd3-a1d1-17a599648705">
      <name xml:lang="en">
          P401kService_DOTNET
      </name>
    </serviceInfo>
  </serviceInfos>
</serviceList>
Request body:
<get_businessDetail generic="2.0" xmlns="urn:uddi-org:api_v2">
  <businessKey>
     954eb479-cdbd-445b-b7a2-de33625ac015
  </businessKey>
</get_businessDetail>
Response body:
<businessDetail generic="2.0" operator="Microsoft Corporation"
   truncated="false" xmlns="urn:uddi-org:api_v2">
  <businessEntity authorizedName="Inside Webservices"
     businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
     operator="Microsoft Corporation">
    <discoveryURLs>
      <discoveryURLuseType="">
       http://www.insidewebservices.com/Prudentially401k
      </discoveryURL>
      ...
    </discoveryURLs>
    <name xml:lang="en">
       Prudentially401k, Inc.
    </name>
    ...
    <businessServices>
      <businessService
          businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
          serviceKey="fcc48a77-8f8c-4bd3-a1d1-17a599648705">
        <name xml:lang="en">
           P401kService
        </name>
        <description xml:lang="en">
           401(k) management service by Prudentially401(k), Inc.
           abiding by the FITSO TM401k tModel
        </description>
        <bindingTemplates>
          <bindingTemplate
             bindingKey="bfacc9f8-c636-4f41-9596-e4e0f8db98ec"
             serviceKey="fcc48a77-8f8c-4bd3-a1d1-17a599648705">
            <accessPoint URLType="http">
  http://www.insidewebservices.com/Prudentially401k/P401kService
            </accessPoint>
            <tModelInstanceDetails>
              <tModelInstanceInfo
  tModelKey="uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549"/>
            </tModelInstanceDetails>
         </bindingTemplate>
      </bindingTemplates>
      <categoryBag>
        <keyedReference keyName="KEYWORD" keyValue="401(k)"
           tModelKey=
           "uuid:a035a07c-f362-44dd-8f95-e2b134bf43b4"/>
      </categoryBag>
    </businessService>
   </businessServices>
   ...
  </businessEntity>
</businessDetail>

The discovered services can either be used as discussed in Section 9.7 or the responsible business entities can be reviewed to help make the decision on which service to use.


9.5 Discovering a Business Entity

At this point, we have traversed through a complete discovery pattern, where we discovered a tModel based on certain keywords, discovered a set of services that complied with the specific tModel, and obtained more information about the business entity that owned the service.

Another discovery pattern is also possible when a potential service user has an idea about which business entities to work with, e.g., existing partners. In such a situation, the discovery that would happen is in reverse order — i.e., the business entity would be discovered first, followed by the services it offers. In this section, we discuss this discovery pattern. While it is possible to search a business using a variety of criteria, we demonstrate discovery based on a category tModel.

9.5.1 UDDI .NET SDK

The file FindBusinessForm.cs contains the code for discovering a business entity. The class FindBusiness acts as the central point, where the search criteria are provided. In this example, it includes a taxonomy under which the business entity is classified.

FindBusinessForm.cs
FindBusiness fb = new FindBusiness();

//Add taxonomy
KeyedReference kr = new KeyedReference();
kr.TModelKey = tModelUUIDBox.Text;
kr.KeyName = classificationNameBox.Text;
kr.KeyValue = classificationNumberBox.Text;
fb.CategoryBag.Add(kr);
...
BusinessList bl = fb.Send();

Once a search is successful, the results are rendered in tree format used in earlier examples in this chapter. Upon clicking on a specific business name, the object GetBusinessDetail gets detailed information about the chosen business entity.

FindBusinessForm.cs
// Get business details
GetBusinessDetail gbd = new GetBusinessDetail();
gbd.BusinessKeys.Add(searchResults.SelectedNode.Tag.ToString());
BusinessDetail bd = gbd.Send();

foreach(BusinessEntity be in bd.BusinessEntities)
{
   ...
}

9.5.2 In Action

Run the application FindBusinessFile.exe. Recall from Chapter 8 that the business entities were categorized under the NAICS taxonomy with code 524292. Enter the data such as the classification name and code. The tModel for the NAICS classification system is uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2. Click the Find Business button to initiate search. Figure 9.7 shows the successful discovery.

Figure 9.7. Inquiry structure in the UDDI registry.

9.5.3 UDDI4J

In the UDDI4J APIs, the method UDDIProxy.find_business provides the necessary functionality as used in FindBusiness.java. As with the UDDI .NET SDK example, the search is based on the category in which a business entity is classified. The class KeyedReference is used to populate the category information.

FindBusinessForm.cs
KeyedReference kr = new KeyedReference(
   p.getProperty("ClassificationName"),
   p.getProperty("ClassificationValue"));
kr.setTModelKey(p.getProperty("TModelKey"));

Once the search criteria are prepared, the search can be initiated using the UDDI proxy.

FindBusinessForm.cs
//Search the business on the registry
BusinessList bl =
   proxy.find_business(null, null, null, cb,null,null,5);

A successful discovery returns the business entity information in BusinessList class. A Vector form of this object is used to get information about the business entity such as the company name, primary contact, and phone number.

9.5.4 In Action

To run the Java example for finding a business, use the following command:

C:\>java FindBusiness FindBusiness.prop

Successful execution will show an output similar to:

-----------------------------------------------
Company: Prudentially401k, Inc.
Primary contact: John Doe
Phone: 212-555-1212
-----------------------------------------------

The request and response XML messages that are exchanged by the UDDI .NET SDK and UDDI4J for discovering a business entity to the UDDI registry are as follows:

Request body:
<find_business generic="2.0" maxRows="5"
   xmlns="urn:uddi-org:api_v2">
  <categoryBag>
    <keyedReference keyName="Pension fund,
       third party administrative services"
       keyValue="524292"
       tModelKey="uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"/>
  </categoryBag>
</find_business>
Response body:
<businessList generic="2.0" operator="Microsoft Corporation"
   truncated="false" xmlns="urn:uddi-org:api_v2">
  <businessInfos>
    <businessInfo
      businessKey="954eb479-cdbd-445b-b7a2-de33625ac015">
      <name xml:lang="en">Prudentially401k, Inc.</name>
      <description xml:lang="en">Prudentially401k, Inc.
        is known for outstanding sevrice to its customers
        for their 401(k) needs.
      </description>
      <serviceInfos>
        ...
      </serviceInfos>
    </businessInfo>
  </businessInfos>
</businessList>
Request body:
<get_businessDetail generic="2.0"
   xmlns="urn:uddi-org:api_v2">
 <businessKey>
   954eb479-cdbd-445b-b7a2-de33625ac015
  </businessKey>
</get_businessDetail>
Response body:
<businessDetail generic="2.0" operator="Microsoft Corporation"
   truncated="false" xmlns="urn:uddi-org:api_v2">
  <businessEntity authorizedName="Inside Webservices"
     businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
     operator="Microsoft Corporation">
    <discoveryURLs>
      <discoveryURLuseType="">
       http://www.insidewebservices.com/Prudentially401k
      </discoveryURL>
      ...
    </discoveryURLs>
    <name xml:lang="en">
       Prudentially401k, Inc.
    </name>
    <businessServices>
      <businessService
          businessKey="954eb479-cdbd-445b-b7a2-de33625ac015"
          serviceKey="fcc48a77-8f8c-4bd3-a1d1-17a599648705">
        <name xml:lang="en">
           P401kService
        </name>
        <description xml:lang="en">
           401(k) management service by Prudentially401(k), Inc.
           abiding by the FITSO TM401k tModel
        </description>
        <bindingTemplates>
          <bindingTemplate
             bindingKey="bfacc9f8-c636-4f41-9596-e4e0f8db98ec"
             serviceKey="fcc48a77-8f8c-4bd3-a1d1-17a599648705">
            <accessPoint URLType="http">
   http://www.insidewebservices.com/Prudentially401k/P401kService
            </accessPoint>
            <tModelInstanceDetails>
              <tModelInstanceInfo
   tModelKey="uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549"/>
            </tModelInstanceDetails>
         </bindingTemplate>
      </bindingTemplates>
      <categoryBag>
        <keyedReference keyName="KEYWORD" keyValue="401(k)"
           tModelKey=
           "uuid:a035a07c-f362-44dd-8f95-e2b134bf43b4"/>
      </categoryBag>
    </businessService>
   </businessServices>
  </businessEntity>
</businessDetail>


9.6 Search Qualifiers

The inquiry APIs including those for finding businesses, services, and tModels have a default behavior, described earlier, to execute queries with a ANDed set of search criteria. However, this behavior can be modified using an optional element named findQualifiers. The UDDI specification supports six findQualifier values. Table 9.2 summarizes the various qualifiers and their functions. For a detailed discussion on each of these qualifiers, please refer to the UDDI specification.

Table 9.2. Search Qualifiers for Find and Get APIs

Search Qualifiers

Description

exactNameMatch

Returns only those that exactly match

caseSensitiveMatch

Returns results whose value and case match

sortByNameAsc

Sorts results in ascending order by Name attribute

sortByNameDesc

Sorts results in descending order by Name attribute

sortByDateAsc

Sorts results in by date last updated, returning earliest first

sortByDateDesc

Sorts results in by date last updated, returning earliest first

orLikeKeys

Multiple search elements from same namespace are ORed together rather than ANDed

orAllKeys

Returns results whose value match ANY search criteria

combineCategoryBags

Returns a business entity for which the categories of services, contained or referenced within, are also searched for matches

serviceSubset

Returns a business entity for which only the categories of services, contained or referenced within, are searched for matches

andAllKeys

Default behavior; returns results that match ALL search criteria

While these are the built-in search qualifiers, the UDDI specification can be enhanced to support a wider range of search qualifiers. UDDI deployers can add additional search qualifiers they see appropriate for their environment. This is especially useful in a private registry deployment, where specialized searches might be desired. Private registries are discussed in more detail in Chapter 10.


9.7 Using Discovered Services

Once the decision is made on which service to use in the Web service solution being developed, an application can be written to interact with the discovered service. Recall from Chapter 8 that, when a service is published to the registry, the service binding is also provided. The service binding provides the service entry point and protocols supported. Using this information, an application can be written to communicate using the appropriate protocol to communicate to the service entry point.

In the UDDI .NET SDK environment, the class GetBindingDetail can be used to retrieve information about the service including the access point for the service using a specific protocol. The method UDDIProxy.get_bindingDetail can be used in UDDI4J for this purpose. Once the access point is retrieved, messages can be exchanged between the user and the application discovering the service. Provided there is domain knowledge built into the application, this process can be done automatically.

We have explained how basic interactions with a UDDI registry can be performed. However, UDDI supports a rich set of advanced interactions that allow UDDI to be incorporated into a sophisticated solution. These solutions are discussed in the next chapter.


Chapter 10. Building UDDI Solutions

  • Private Registry

  • Referencing Caching

  • Taxonomies and Identifier Systems

  • Versioning and Migration Policies

  • Registry Usage Models

In Chapters 8 and 9, the APIs for publishing and inquiry are discussed. These APIs provide means to publish and discover business entities and related services. Using these APIs, a company can either register its business assets as services to other companies in its ecosystem or use the services provided by other companies. These APIs essentially provide the necessary technical capabilities to advertise and discover various resources, including business entities, services, and tModels. However, technical capabilities are only part of the picture. The other part is how the registry is used in a solution; this can be considered the usage pattern of the registry. Each usage pattern has a unique set of requirements and uses various UDDI technical capabilities more prominently than others. Building registry-based solutions requires a good understanding of these usage patterns. In this chapter, we discuss the usage patterns and how each of them uses the UDDI registry. We also discuss prominent solution domains where UDDI registry can be used.


10.1 Private Registry

In the previous discussion, we have referred largely to the Universal Business Registry (UBR) when discussing UDDI registry. The examples themselves are also demonstrated using the Microsoft UBR instance. As mentioned in the earlier chapters, these examples also work on a private instance of the registry.

A private UDDI registry is an instance of a UDDI registry that is not part of the UBR cloud. Although called private, such an instance need not be accessible only to a specific individual or organization. It is possible to share a registry instance among a set of like-minded entities that come together for a specific purpose. For example, a company and all its suppliers can use a private registry to exchange information. As explained in Section 4.3.1, a private registry can act as an intermediary between communicating business entities. Besides this, a private registry provides several advantages over UBR.

10.1.1 Access Control

One of the chief advantages of a private registry is access control. Only the members that share the private registry can/will typically have access to a private registry. This means that the members can divulge a limited amount of potentially confidential data to be shared among the members. Sharing of such data may be essential for functioning facilitated by the registry.

10.1.2 Independence in Setting Governing Policies

The UBR has specified its own set of operational and functional policies. These policies are specified in the Operator Specification document. A UBR operator is bound by a contractual agreement to abide by these policies. These policies may not always be suitable for a company or a solution it is trying to put in place. A private UDDI instance will enable the organization to set and enforce its own policies to use the registry. For example, by default, the Microsoft UBR instance does not allow multiple business entity registrations per user account. A private registry owner, on the other hand, may not enforce such a restriction at all or may allow business entity registrations up to a certain limit.

10.1.3 Customizable Organization

A private registry owner can define its own set of organization rules above and beyond those specified by UDDI. This can ensure that the organization is commensurate with the needs of the community or solution using the registry. For example, a private registry that is used among several companies may have an organization structure where the name of the service or tModel must be in the for-mat company name:location:functionality name:version. Using such a hierarchical structure, it will be easy to find all the services that cater to a specific zip code or all versions of a certain interaction specification. Note that on UBR it is possible to create such a naming scheme, but it is not enforceable. The other use of customizable organization is creating synonyms for resources, as discussed in Section 10.2.

Currently, several companies including Microsoft, IBM, and Oracle provide a private UDDI registry that a company can implement.

10.1.4 Information Sanity

The UBR today suffers from a lot of data that is stale. Since any registered user is allowed to publish business entities and services, there are several registrations that are phony, i.e., being used for testing purposes. A private registry can enforce information sanity by ensuring a strict process for registering any resource on the registry — even by the members. The process through its checks and balances can ensure that the data available on the registry (such as access points to services) are fresh and may enforce the freshness of data through contractual agreements.


10.2 Referencing Caching

Recall that the UDDI architecture provides a loose coupling between interacting business entities. Such loose coupling enables these companies to form or dismantle business relationships at relatively short notice. While this dynamism is useful in the bigger picture, it creates an operational delay in the short run. Every time an application or a user wishes to use a service that provides certain functionality, it has to refer back to the concerned UDDI registry. One solution to this problem is to cache the reference to the found resource — whether a business entity, tModel, or service and its binding template. Once cached, the local reference can be used whenever corresponding functionality is needed. This will not only save the roundtrip delay to communicate with the registry, but will also remove transactional dependency on an external entity — the UDDI registry. The application can function with one less potential "point-of-failure" in the architecture. The concept of reference caching can be extrapolated further to create a link between an external UDDI registry such as the UBR and a private instance. Two interaction patterns emerge when defining linkages between two UDDI registries.

  • Reference import

  • Reference export

10.2.1 Reference Import

When a service-user organization needs certain functionality and has decided on the service provider (and the service instance within), the reference to concerned entities can be imported from the UBR or other UDDI registry. The reference can then be kept in a local private UDDI registry.

Reference import functionality also lets the service-user organization organize the references in a way suitable to its usage model. It could, potentially, create its own taxonomies, tModels, and other data structures and save the references using that organization. For example, if there are multiple specifications defined for interacting with a 401(k) service, a user can search services that comply by different specifications and save the found services under its own my401kTModel. It could also save the found services under its own naming scheme. Of course, the real data must kept as well to resolve the synonym to the real resource.

This private registry can be thought of as a repository of all the services that an organization uses during its day-to-day operation. Figure 10.1 depicts this scenario.

Figure 10.1. Reference importing.

10.2.2 Reference Export

Just as a service-user can import the service reference from another UDDI registry, a publisher can export service references to other registries.

A reference export mechanism is somewhat less intuitive than the reference import mechanism. One application of this mechanism could be the way a publisher manages its services. All the deployed services can be published within the publisher's private registry and appropriate instances could be exported as they are made public. Reference export could be used for versioning and service migration, as explained in the next section. Figure 10.2 depicts this scenario.

Figure 10.2. Reference exporting.
    [ Team LiB ]


10.3 Taxonomies and Identifier Systems

Taxonomies provide the means to classify the resources as discussed previously. In Chapter 6, we discuss how taxonomies are used during the design phase of a registry-based solution.

The identifier system is another orthogonal means for classifying resources. Compared to taxonomies, an identifier system is focused on discovering a specific resource more precisely, rather than finding a class of resources. When used together, taxonomies and identifier systems can be powerful in locating a set of resources with a great degree of precision. Due to their importance, the taxonomy and identifier systems deserve an in-depth discussion.

10.3.1 Publishing Taxonomies

In the previous examples, we use taxonomies that are built in the UBR registries. For example, the business entities are classified under ntis-gov:naics:1997 taxonomy, which represents North American Industry Classification System (NAICS). The service interaction specification TM401k uses the uddi-org:general_keywords taxonomy, which represents the generic taxonomy where keyword values are used to classify resources. As discussed in Chapter 6, when designing a registry-based solution, the designer must decide if the existing set of taxonomies and identifier systems are sufficient for the solution. If required, a new set of taxonomies and identifier systems must be designed, published, and employed in the proposed solution.

The ubiquitous tModel resource is used to register taxonomies and identifier systems as well. Given the multi-faceted role of tModels, it is essential to distinguish the tModels from each other. UDDI provides a special taxonomy to classify the tModels themselves. This taxonomy, uddi-org:types, is commonly referred to as the UDDI Type Taxonomy.

10.3.2 uddi-org:types Taxonomy

The UDDI Type taxonomy defines a predefined set of categorizations that can be used to denote what a tModel being registered is associated with. When registering a tModel, the UDDI Types taxonomy must be associated with key values that signify the type of tModel. For a taxonomy tModel, the value categorization should be used during registration. The corresponding XML message will be as follows:

<tModel authorizedName="..." operator="..."
   tModelKey="">
  ...
  <categoryBag>
    <keyedReference
       tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"
       keyName="uddi-org:types"
       keyValue="categorization"/>
  </categoryBag>
</tModel>

The UUID mentioned in the XML segment is associated with the UDDI Types taxonomy. Table 10.1 describes all the types defined in the UDDI Types taxonomy. When registering a tModel, corresponding values can be used to classify it appropriately. Note that it is not mandatory for a publisher to use the UDDI Types taxonomy for categorization. However, doing so helps in the proper representation of the tModel in the UDDI registry. Also, other users of the registry get a more refined view of the tModel.

Table 10.1. tModel Types Defined in UDDI Types Taxonomy.

Types

Description

tModel

Root level type for internal use only

identifier

tModel defines an identifier system

namespace

tModel defines a scope constraint or a domain

categorization

tModel represents a taxonomy

postalAddress

tModel represents the postal address in various forms

relationship

tModel used for publisher assertions

specification

tModel represents an interaction for Web services paradigm

xmlSpec

A refinement of specification that denotes that the interaction is via XML

soapSpec

A refinement of xmlSpec that denotes that the interaction is via SOAP

wsdlSpec

tModel represents a Web service described through WSDL

protocol

tModel represents a protocol of any sort

transport

A refinement of protocol that denotes tModels dealing with transport protocols

signatureComponent

tModel is part of a tModel collection that together represents a specification

unvalidatable

tModel that cannot be referenced in identifierBag or categoryBag. Used during registration of a checked tModel

checked

tModel is a namespace, identifier, or categorization type tModel that has a properly registered validation service

unchecked

tModel is a namespace, identifier, or categorization type tModel that does not have a validation service

10.3.3 Checked and Unchecked Taxonomies

UDDI specification provides further refinement of taxonomies registered through the UDDI Types taxonomy — checked and unchecked. This provides a clear distinction between tModels that are more formal than others. A checked taxonomy undergoes more scrutiny and has a more formal set of requirements than an unchecked taxonomy.

Registering an Unchecked Taxonomy

To register an unchecked taxonomy, the only additional step to the aforementioned process is to classify the taxonomy as "unchecked" in the categoryBag. The XML for that would be as follows:

<categoryBag>
  ...
  <keyedReference
     tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"
     keyName="uddi-org:types"
     keyValue="unchecked"/>
  ...
</categoryBag>
Registering a Checked Taxonomy

A checked taxonomy registration requires a more elaborate process. The six-step process aims at registration of a taxonomy that has gone through a "validation." The registration, in this case, requires active participation from a UDDI operator.

  1. The tModel is designated with two UDDI Type values: checked and unvalidatable. Marking a tModel "unvalidatable" prevents any referencing to that tModel until the process is completed. The tModel is not published by the user; instead, an operator must be contacted for the purpose.

  2. The UDDI operator publishes the tModel on the user's behalf. Once published, the operator owns the tModel. The ownership in this case refers to rights to updates. The ownership is eventually transferred to the user.

  3. After the initial registration, the user must implement and deploy a validation service for the tModel. This service must implement the validate_values message and return a disposition report indicating success or failure as described by the uddi-org:taxonomy_V2 tModel. Whenever any resource refers to the concerned tModel in its categoryBag or identifierBag, UDDI invokes the validation service that validates any values provided in the registration. It is this validation service that makes a checked tModel more formal and usable compared to unchecked tModels. The validation service specification can be found in the UDDI API reference guide.

  4. The operator performs an assessment of the validation service. Certain quality standards or uptime requirements may be imposed. There are also two specific pieces of information needed:

    • Caching: The operator can optimize the performance of validation by caching the valid values for the taxonomy. While caching reduces the transaction time, it also reduces the load on the validation service. It is recommended to allow caching if possible. Caching is not recommended if the validity of values is context-sensitive or if the cache can become invalid for some reason.

    • bindingTemplate: Like any other services registered at the UDDI registry, the validation service is also associated with a binding template. The binding template provides the details about how to communicate with the service. The only restriction on the access point in the binding template is that the access point should not be published in any other binding template on the same registry. The binding template should also reference the uddi-org:taxonomy_V2 tmodel.

  5. After the operator assesses the validation service, it is published in its operational business entity. The binding template is also published in that business entity. The service access point provided by the taxonomy provider is not published in the binding template. Instead, the binding template has a redirector URL that effectively conceals the actual service access point. This avoids denial-of-service attacks. At this point, the tModel ownership is transferred to the provider.

  6. The categorization unvalidatable is removed and any interested users or companies can now reference the tModel. Any time the tModel must be disabled, it is categorized as unvalidatable.

As can be seen, registering a checked tModel is a very elaborate process. Ideally, in the examples discussed in this book, FITSO, the financial standards body, would publish a checked taxonomy for the concerned financial transaction areas and other financial institutions would use that checked taxonomy when registering their services. It should also be noted that the identifier systems represented using tModel would also undergo the same process to register a "checked" identifier system.


10.4 Versioning and Migration Policies

During the service lifecycle, service versioning and migration policies play an important role. As the service goes through the lifecycle as depicted in Figure 4.5, it will undergo changes. The same is also true for a tModel, whether it describes taxonomy, identifier system, or service interface specification.

Unless the functionality provided by a service or a tModel is also obsolete, their obsolescence would be followed by another version or a totally different service or tModel replacing the obsolete one. For both the publisher and user of services and tModels, the versioning and migration policies provide a way to minimize any downtime. While there are no mandatory requirements in the UDDI specification forversioning, "best practices" documents make recommendations about how to handle it.

10.4.1 tModel Versioning

With continuation of service offering being the most important aspect of versioning, having new and old versions compatible on a common set of terms and values is most logical. In practice, it is always a balancing act to keep two versions compatible at a very granular level. The Versioning Taxonomy and Identifier Systems introduces the notion of upward compatibility among versions of a tModel repre-senting a taxonomy or an identifier system. This upward compatibility is based on the codes associated with the concerned specification.

A code in taxonomy T2 is upward compatible with a code in taxonomy T1 if and only if the two codes are identical and if the code's meaning in T2 is a superset of its meaning in T1. A code in an identifier system I2 is upward compatible with a code in identifier system I1 if and only if the two codes are the same and the code's meaning is the same.

Taxonomy or identifier system A2 is upward compatible with taxonomy or identifier system A1 if and only if every code in the code space of A1 has an upward compatible counterpart in the code space of A2.

The best practice behavior is to always keep taxonomy or identifier system upward compatible. In such a case, the associated tModel is simply updated to reflect the new version and republished under the same key. In reality, however, there will be situations when this is not possible at some times. In such a case, several migration steps can be taken to ensure operational continuation.

  1. The new version is developed in such a way that it introduces new codes rather than modifying existing ones. The obsolete codes can be still supported in the new version, so that existing applications can continue to refer to them. The new usage of the codes can be discouraged through the specification documents clearly identifying those values as obsolete.

  2. The old version is supported until its usage drops significantly. At that point, the tModel and related version can be retired without affecting a larger user population.

  3. The tModels representing the old and the new version can be chained together. In this case, the older tModel refers to the new tModel through a replacedBy relationship. Anybody finding the old tModel can check for this chaining and migrate to the newer version. The UDDI specification provides a tModel uddi- org:isReplacedBy specifically for this purpose.

  4. A Web service that can provide code-conversion service between the two versions can help the users to map codes and related information between the versions. Such a Web service must implement the specification represented by uddi-org:updateEntity tModel. This tModel is used to bring a resource up-to-date with respect to a specific tModel (the tModel undergoing version change in this case). Using such a service, a business entity or service that references the concerned tModel can get the new information and update its registration data with respect to the changing tModel.

Through these mechanisms, tModel versioning can be made a smoother experience. Note, however, that for a smooth transition, the tModel provider needs to implement these steps diligently.

10.4.2 Service Versioning

Service versioning issues are similar to the tModel versioning issues discussed previously. The operational continuance has a rather broader impact, due to contractual bindings around quality-of-service specifications.

The tModel versioning scheme discussed above could be modified for service versioning. Since, unlike tModel, services can have a much wider range of purpose, the precise steps in the process will be highly dependent upon the functionality provided by the service.

Service or tModel versioning can be facilitated through reference exporting. As explained in Section 10.2, a tModel or service provider can export references to the concerned resource to a UBR or other publicly available registry. When introducing anew version, the provider can first make it available on the local registry and then once it is tested and ready for use, publish it to the public registry. If the new version is upward compatible, the new version will register under the existing registration key, otherwise a new registration key can be requested. The older version can then be supported only at the local registry for interested customers.


10.5 Registry Usage Models

From the discussion until now, several patterns emerge for potential use of the UDDI registry. Based on the kind of information stored in the registry, it can be used to simply get contact information for a business entity ("white pages"-style information) or to understand the interaction pattern of a service and communicate with it ("green pages"-style information). These usage patterns can be classified into several categories as follows:

  • UDDI as Universal Registry

  • UDDI as Market Exchange Registry

  • UDDI for Reference Caching

  • UDDI as Portal Facilitator

  • UDDI as EAI Facilitator

10.5.1 UDDI as Universal Registry

As explained in Section 5.2.1, currently the UBR provides a "public UDDI infrastructure" that can be used as a means to test drive registry-based business processes. Figure 10.3 depicts this scenario.

Figure 10.3. UDDI Registry as UBR.

The UBR cloud of registries provides a uniform view across all registrations made at any node within the UBR. Note that this current usage pattern of the UBR is not likely to be the final usage pattern. As UDDI security policies and information sanity policies evolve, more sophisticated usages of the UBR may result.

10.5.2 UDDI as Market Exchange Registry

The notion of UDDI as a meeting point between service providers, service consumers, consortiums, and other standards bodies, is the basis for UDDI as a market exchange. However, the market exchange is a specialized and focused instance of private registries that are deployed to facilitate a specific industry.

Policies and information specific to the industry can be loaded into the exchange to ensure a smooth and efficient exchange of information. Market exchanges are likely to restrict access to only certain entities, for example, industry participants. Focusing on a specific industry or segment makes the market exchange a magnet for those trying to reach that particular audience. Thus, a service user will find a host of industry-specific services and businesses for its service portfolio. To ensure efficient querying within a market exchange, industry-specific taxonomies and search qualifiers may be deployed that "speak the industry jargon." An example of a market exchange could be a chemical exchange that brings together chemical industry traders and buyers. Figure 10.4 depicts the market exchange scenario.

Figure 10.4. UDDI as a market exchange.

Market exchanges can also provide additional services that make interacting with the exchange more useful. For example, rating services that allow third party agencies to rate various service providers might be important in certain industries.

10.5.3 UDDI for Reference Caching

In Section 10.2, we discuss the concept of caching (import and export) a reference to a specific service found in an external registry. A private registry instance can be deployed within an ecosystem to house either the services meant for export or to house those cached entries for quick access to these frequently used services. Figure 10.5 depicts this usage pattern.

Figure 10.5. Reference caching.

10.5.4 UDDI as Portal Facilitator

Portals have become a common component of most companies' technology landscape. Two main flavors of portals exist: intranet and Internet. Intranet portals often house information specific to the employees of the company. Internet portals often house company information specific to interested external parties, i.e., customers, press, and so on. Another type of Internet portal is a service-aggregating portal. The my.yahoo.com portal, for example, collects several types of services and allows users to customize their portal experience. A third flavor, which is essentially a hybrid of the intranet and Internet portals, is that of a virtual private portal. This type of portal is often external to the company but allows only limited access to partners, for example.

A UDDI registry can provide the services that are offered through these various portals. Figure 10.6 depicts this usage pattern. Chapter 11 expands on the concept of UDDI-powered intranet portals.

Figure 10.6. UDDI as a portal facilitator.

10.5.5 UDDI as EAI and B2B Facilitator

Web services promise to assist corporate Information Technology (IT) departments in linking their numerous enterprise applications. A typical large enterprise might have upward of eight hundred different applications. Imagine trying to deploy or orchestrate a business process on this infrastructure. While many enterprise application integration vendors exist to solve this problem, Web services also provide a technology to integrate these applications. The role that UDDI plays in this scenario is two-fold. As Web services are deployed within corporate boundaries, they can be published to the UDDI registry. The UDDI registry then acts as the library that applications are written to interact with to ensure the appropriate services are used.

A second role the UDDI registry plays is that of business-to-business integrator. Services ready for external consumption (by authorized parties) can be exported from the UDDI library and imported into an external facing UDDI registry deployed as part of a virtual private portal. Figure 10.7 depicts this usage pattern.

Figure 10.7. UDDI as EAI and B2B facilitator.

We have viewed UDDI from various perspectives: that of a service publisher, a service consumer, and of a solution deployer. Understanding these perspectives is critical in deploying any UDDI-based solution. However, it is also important to see how UDDI solves critical business problems. In the next part of the book, we offer case studies and delve into how UDDI fits into larger business solutions.


Part III: Case Studies

In this Part

Chapter 11: Employee Portal Unfolded

Chapter 12: UDDI in B2B and B2C Scenarios


Chapter 11. Employee Portal Unfolded

  • Corporate Employee Ecosystem

  • Technology Quilt

  • Modeling Business Entities

  • Defining Categories and Interactions

  • Final Analysis

Throughout the book, we used an employee portal as the basis for explaining UDDI-related concepts and demonstrating UDDI API usage. We have viewed UDDI from various perspectives: that of a service publisher, a service consumer, and of a solution deployer. Understanding these perspectives is critical in deploying any UDDI-based solution. However, it is also important to see how UDDI solves critical business problems. In this part of the book, we offer case studies and delve into how UDDI fits into larger business solutions.

In this chapter, we unfold the employee ecosystem of a global corporation and demonstrate how it can be fueled by a UDDI-powered employee portal. It is designed to facilitate interactions between corporations and their employees. We describe the UDDI-based employee ecosystem in detail but leave the deployment and actual development issues to the reader.


11.1 Corporate Employee Ecosystem

An ecosystem of a company consists of its partners, vendors, customers, and the regulatory environment. Thus, an employee ecosystem includes the people, technologies, processes, and services that are important to employees and other interested parties. As we mention in Chapter 2, the employee portal is one of the most popular solutions in the business to employee arena. It provides access to the many services that corporations provide to their employees. Figure 11.1 illustrates this ecosystem.

Figure 11.1. Corporate employee ecosystem.

11.1.1 Players

Key constituents of an employee ecosystem are the people, entities, and services that interact within the ecosystem. Some people manage the ecosystem and lay out the framework in which to operate, others use the services provided, and still others provide the services available within the ecosystem.

Human Resources

As in any ecosystem, the employee ecosystem has a governing body that determines the policies and interaction framework that will exist within the ecosystem. In the employee ecosystem, that governing body is primarily the Human Resources (HR) department. The HR department is responsible for some decisions such as which services to provide, how to classify those services, and finally who has service access and to what level.

Note that ecosystems interface together at touch points provided by the registries that fuel them. In such cases, the HR department also interfaces with governing bodies of these internal or external ecosystems and exchange relevant information such as service definitions, categories, and interaction specifications. For example, the health care insurance provider that participates in the ecosystem of the corporation may have a set of services that are made available to member employees. These service definitions would be brought into the employee ecosystem registry for efficient and easy access.

Global Corporate IT

The Global Corporate Information Technology department is in charge of the implementation and technology landscape of the employee ecosystem. Working in conjunction with the HR department, the IT department not only provides internal services for employees but also is the private UDDI registry operator for the UDDI instance that fuels the ecosystem. Both the services and the employee ecosystem technology landscape are discussed later in the chapter.

Users

Finally, the users are the principal entities in the Employee Ecosystem. In the context of the employee ecosystem, employees are the primary users. There are many types of users in this ecosystem:

  • General: employees that interact with services and processes for the purpose of consumption.

  • Administrative: users that manage the behind-the-scenes activities such as access control.

  • Superusers: users that may make global platform configuration changes.

However, people are not the only users of the employee ecosystem. Service consumer applications can also be designed and written to interact with the UDDI registry as well as the discovered services.

11.1.2 Processes and Services

Two other key components of the employee ecosystem are the services and processes provided for employees. For the purpose of this discussion, we separate processes and services. Note that processes are not necessarily supported by a technology backbone. For example, a process could be the corporate campus entrance authorization process wherein an employee shows a badge to a guard to enter the campus during off hours. A service is an isolated piece of logic that rests on a technology foundation. For example, managing the 401(k) elections of an employee is a service. There are several categories of processes and services. We group them at a high level and think of three major groupings:

  • Internal

  • External

  • Administrative

We make the distinction between internal and external services because these are owned and operated by different entities.

Internal

Internal processes and services are those that are provided for by the corporate environment itself. These processes and services are designed, developed, deployed, and managed by an internal group of people. Within the employee ecosystem, all corporate mandated and supported processes and services are registered within the employee portal UDDI registry. Hence, hereon we refer to both processes and services as services since they both will have an electronic representation within the UDDI registry.

Internal ownership of these services essentially means that the HR and IT departments own the service lifecycle discussed in Chapter 4. Migrations, upgrades, and so on are determined by the corporation and can be enhanced to best suit the needs of the employees. It is important to note also that the UDDI publishing information about the services is also owned by the internal organizations; hence, it can be tailored exactly to suit the needs of the consuming applications and employees. Examples of internal services are as follows:

  • Time Off Management Service

  • Education Course Registration Service

  • Conference Room Reservation Service

External

We mention that registries are the intermediaries between ecosystems. The purpose for this connection between ecosystems is primarily to share services. Technically, this sharing between UDDI registries can be made possible via the export and import usage models.

External services (again both manual processes and electronic services) are typically owned and operated by third-party service providers. Usage of these services by the employee ecosystem is contracted via business agreements and service level agreements set up prior to incorporation into the employee ecosystem. However, the independent nature of these services means that the service providers do have a higher level of autonomy. Generally, the only contractual guarantees that the service provider needs to uphold are of those around service levels and visible business logic (as opposed to internal functionality). The autonomy therefore implies that the service lifecycle is independently managed; while requirements may be influenced, the corporation does not own them. However, the corporation can and should influence the UDDI publishing information or service definition within the registry it controls. Recall that the UDDI operator and the ecosystem governor both play a significant role in determining the policies of the employee ecosystem. In this case, both of those entities are bodies internal to the corporation.

Examples of external services are as follows:

  • 401(k) Information Service

  • Employee Stock Purchase Plan Management Service

  • Credit Union Information Service

Administrative

We separate out administrative services because they may or may not ever be used by the general class of users described previously. These are services that mainly help HR and Corporate IT monitor what is happening within the ecosystem and the portal. These services could be either internal or external. For example, an Availability Service could be used by Corporate IT during troubleshooting exercises, to ensure that an internal or external service is available and accepting requests. Another example of an administrative service is the authentication service that could be used by all internal services.

11.1.3 Three Ps

The three Ps of the employee ecosystem are Policies, Procedures, and Policing. These are the guiding principals and enforcement constructs that are put in place for the ecosystem to function smoothly and as desired by the corporation. These may or may not have an electronic presence in the UDDI registry.

Policies

The HR and the IT departments develop policies instituted by the employee ecosystem. Policies of the ecosystem can be considered a sort of handbook for users, service providers, and administrators. There are a wide variety of situations for which policies to guide behavior are required.

There are policies that affect interentity communication with the employee ecosystem. For example, policies may dictate how an internal service can communicate with an external service to share information. This is especially important when sensitive information is passed as part of the transaction.

Other policies may be present surrounding the legal retention of the transactional information passed between users and services. Services that are affected by these policies may be able to interact with an administrative service that provides the business logic for the retention of transactional information.

Note

Policies that can be described and defined in an exact or semi-exact fashion may be modeled within the registry as a tModel. All such policy tModels could be classified under a specific category — policies.

Procedures

Procedures are the hows to do various tasks within the ecosystem. Procedures, just like, policies can be documented only or also defined for the UDDI registry. A procedure for obtaining access to the employee ecosystem is one example. There could be various subprocedures to handle different types of users. For example, a third-party service provider would need to follow a different set of steps to obtain access to an employee ecosystem as compared to an employee.

An example of a procedure that is unlikely to be modeled for the registry is that of reporting problems with a service, information, or a policy/procedure. That is likely to be a documented item that is available as part of the employee portal Web site.

Policing

Policing of any ecosystem is critical. However, the UDDI registry is not designed to be a gatekeeper and hence appropriate security policies, procedures, and technologies need to be designed within the ecosystem to ensure employee trust is obtained, fostered, and maintained. For example, each service should handle its own authorization policies and procedures.

11.1.4 Role of the Registry

Notice that in Figure 11.1, the internal employee portal UDDI registry has an important role within the ecosystem. In Chapter 10, we examine the role of a registry in a variety of scenarios. In this case, the registry plays several roles. These are as follows:

  1. Stores access information about approved internal and external services

  2. Stores important policies and procedures

  3. Provides access to administrative services for service developers and ecosystem monitors

  4. Houses interaction and classification framework

  5. Acts as a reference for service developers


11.2 Technology Quilt

The employee ecosystem is truly a technology quilt. Several disparate technologies work together to provide an interaction platform for the aforementioned users, services, policies, and procedures.

11.2.1 Portal Technology

The portal technology provides an interface accessing various enterprise applications, services (both electronic and manual), and corporate information sources. The portal Web pages may be written to communicate to the UDDI registry to access services meant for direct consumption.

Consider the example of a Corporate Approved Taxi Service. This service is designed to return the corporate approved taxi provider for a given zip code. It uses the employee portal registry to query the list of taxi service providers possible. The Web pages designed for the service facilitate communications between the employee and the registry.

Other portal Web pages may call on applications or Web services that in turn use sub-services to carry out administrative functions. Noteworthy is that by establishing the UDDI registry as the source for all services, the employee ecosystem operators can ensure that applications are using the latest service edition available and not an out-dated or since discontinued but not yet turned off service.

11.2.2 Internal and External Services

Several internal services are also another key component of the employee ecosystem. Examples of these services are discussed previously. However, it is interesting to note that these services can be either .NET based, J2EE based, or even manual services. The entry points or access points of these services are published to the UDDI private registry such that applications and direct user interfaces can be written to access them. With respect to UDDI, because it communicates via SOAP messages, .NET, JAVA, or any other platform-based services may interact with the registry directly so long as the appropriate SOAP messages are formatted.

11.2.3 Enterprise Applications

A variety of enterprise applications provide the business logic required for the services, processes, and procedures to work. These applications could include applications such as a payroll processing application, an employee benefits database, and a stock options grant database.

11.2.4 External Ecosystems and UDDI Registries

Corporations are unlikely to build all the business logic and procedures that are required by an employee ecosystem. Several companies specialize in certain niche areas. For example, 401(k) services are generally not provided directly by the corporation but by a contracted service provider. Often the services from these external entities will be available through partnering with an external ecosystem. Cross-ecosystem interactions such as import and export of service definitions may occur between the employee ecosystem UDDI registry and the external UDDI registries.

11.2.5 Security Infrastructure

Several interactions within this ecosystem are secured. This infrastructure ensures that authorized users initiate and complete transactions and the transactional data is not compromised. For example, service publisher interactions with the UDDI registry are carried out through secured Hyper Text Transfer Protocol (HTTPS) with username and password authentication.


11.3 Modeling Business Entities

A comprehensive technology landscape coupled with a consistent and efficient modeling design makes the employee ecosystem a powerful solution. Recall from Chapter 6 that modeling happens at various levels and of a variety of entities. In this case study, we model the key participants of the ecosystem:

  • Ecosystem Governor

  • Service Publishers

  • Service Consumers

  • Service Developers

11.3.1 Ecosystem Governor

An ecosystem governor is usually the corporate entity itself and must be modeled as such. In this case, both the HR department and the Corporate IT department within the company share the responsibility for setting the policies for service publishers and service consumers. They also provide the structure and framework for ecosystem interactions. Given the crucial role that a governing body plays in the ecosystem, it should be modeled as a separate entity in the registry. In this example, the HR and IT departments should have a separate representation as the governing body despite being part of the modeled parent company. Modeling the governing body in this independent manner helps in creating a clear demarcation of roles and responsibilities. The ecosystem governor entity sets the policies and procedures for the rest of the ecosystem. Some examples of policies and procedures that the ecosystem governors may set in this case include:

  • What services are included in the ecosystem

  • How long ecosystem logging information must be retained

  • When internal and external services may schedule system maintenance

Note

It is important to point out the relationship between the ecosystem governor and the parent company in the employee ecosystem. Since the governing body is fully subsumed by the parent company, this relationship can be modeled through publisher assertions as described in Chapter 6.

11.3.2 Service Publishers

There are definite differences between modeling for internal versus external service providers. These differences are primarily a result of the autonomy that external service providers enjoy with respect to their service offerings. Also the security and trust assumptions vary between internal and external service publishers. Thus, internal and external service providers should be modeled separately and differently from each other.

Internal Service Providers

Internal service providers need to model the service publishing entity as well as the services themselves. The ecosystem governor provides the categories that are available for classification. Hence, simply using the approved categories is sufficient.

It is important to note that even within the corporation there may be several departments that publish services to the ecosystem. With the ability to model entities and their relationships in the registry, the individuality of internal departments may be preserved. This is critical because the user name and password are linked to the published information. Thus, for individual service publishers to manage their service registrations, they need to have their own user names and passwords. The alternative would be one corporate-wide user name and password that is shared by all internal service publishers, but we do not recommend this as it causes ambi-guity in roles, responsibilities, and separation of duties. Publisher assertions then need to be deployed linking the department-level entities to the parent company entity.

External

External service providers are also modeled within the UDDI registry. Ecosystem governors have to determine on a case-by-case basis whether a third-party service provider should use an existing category or whether they should define their own categories. Once decided, the entity definition may be imported into the employee ecosystem UDDI registry.

11.3.3 Service Consumer

Service consumers are not necessarily modeled within the registry. In the employee ecosystem too, individual users, whether they be people or applications, do not necessarily have an electronic presence (a model) within the registry. Any authentication, tracking, or logging that is desired needs to be deployed with add-on solutions to the portal technology or the Web services technology described previously.

Figure 11.2 depicts the business entity-level modeling within the ecosystem.

Figure 11.2. Business-entity level modeling for the Employee Ecosystem UDDI Registry.
    [ Team LiB ]


11.4 Defining Categories and Interactions

Modeling entities and services also includes determining which categories and interaction specifications will be used. Thus, the model for business entities and services includes not only specifics on the entities/services themselves but also the relevant meta information.

11.4.1 Categories

The ecosystem governor determines the categories that are available for use within the registry. Several categories are built into the registry such as the North Amer-ican Industry Classification System (NAICS). However, external ecosystems and registries are also a source for categories. These categories may be imported into the employee ecosystem UDDI registry. For example, the Financial Services industry may have categories defined that are very prominently used by financial entities. These categories may be such well-defined standards that it makes sense for the ecosystem governor to import these rather than develop its own. The employee ecosystem governor would need to watch for other industry standards around classification schemes because loading the registry with standard definitions makes it more interoperable with the external world.

Internal and external entities and services need to determine which of the available categories makes sense to publish within. Both groups may find the need for additional categories and will need to make the case to the ecosystem governor for additional classification schemes. For example, the internal Time Off service developers may find that none of the existing categories serve its needs and, hence, a new Time Off category is desired. Likewise, the third party Counsel-ing Services entity might find that none of the existing categories are appropriate and also request a new category. Ideally, the ecosystem governor would abstract out a commonality between UDDI resources and develop higher-level categories. In this case, a new category called Personal Life may be published. Thus, a subset of categories can be published or imported into the UDDI registry and added to as necessary.

Finally, it is important to group internal and external entities and services separately. For this reason, the ecosystem governor may mandate that every entity and service classify themselves within the Internal or External categories. Being able to query on this will be useful for managing the registry and making broad declarations based on internal/external boundary. For example, all external services may undergo random testing to ensure quality of service levels are being met while internal services may be all unavailable during company-wide shutdowns.

It is critical to make these categories available to the service consumer application developers. This ensures that service consumer applications can be written to search within only a certain subset of categories. These categories and their appropriate values are published to the UDDI registry as explained in Chapter 8 as tModels.

11.4.2 Interaction Specifications

Interaction specifications, like categories, come from a variety of sources. More than likely, when there is a category standard (like in the Financial Services industry described previously) a set of accompanying interaction specifications will also be standardized. In this case, the ecosystem governor needs to import these into the registry and make them available for the service consumer applications to develop consumer logic that uses the services based on these interaction specifications.

The second scenario exists when the ecosystem governor has corporate policies and government/legal mandates that dictate certain interaction patterns. In these cases, the ecosystem governor defines an interaction specification that is published to the registry and imposes those on the internal and/or external service providers.

A third scenario is where no industry standard exists, but no internal standard needs to be mandated—hence the external or internal service provider need only to develop a de facto interaction specification from the services themselves.

In all three scenarios, issues of security and trust must be taken into consideration and accounted for.


11.5 Final Analysis

In Chapter 14, we discuss the enhancements made to the UDDI specification in Version 3. Version 3 of the specification is much more supportive of the global private networked registry scenario. To this end, there are many enhancements that are useful for the employee ecosystem. Key among these new features are increased support for internationalization, security, and private registry policy definition and execution.

By explaining the employee ecosystem and the role of the UDDI registry at a high level, we have highlighted several key aspects of planning such a platform. We focus mainly on the modeling of various entities and the role of the ecosystem governor in this case study. In subsequent case studies, we highlight the interactions among various ecosystem entities.


Chapter 12. UDDI in B2B and B2C Scenarios

  • Extended Supply Chains

  • RFQ Basics

  • RFQ Business Process Flow

  • RFQ Processing for AmCAR, Inc.

  • The AmCAR Procurement Ecosystem

  • Extending the Solution

  • Location-Based Mobile Services

In Chapter 11, we discuss a Business-to-Employee (B2E) solution, the employee portal, which uses a business registry to function. It is also possible to use registries in Business-to-Business (B2B) and Business-to-Consumer (B2C) scenarios. In the chapter, we discuss applications of registries in these two areas. Some of the issues faced by solutions using registries are the same irrespective of the application area. Thus, the issues or design principles discussed previously have been omitted in these case studies. However, they must all be addressed when deploying a real-world solution.


12.1 Extended Supply Chains

As we discussed in Chapter 2, during their product generation processes, companies need several types of raw materials and parts. Generally, required raw materials and parts for manufacturing a certain product are well known in a manufacturing process. This includes specifics such as:

  • Quantity required per unit

  • Quality level

  • Substitute material

When a manufacturing run (either forecasted or customer-specific) is planned, the raw materials and parts are procured. Companies usually stock up on these parts based on product generation requirements, using market forecasts. These parts must be available (on hand or readily obtainable) so that the manufacturing processes can flow smoothly. Typically, manufacturers manage relationships with several vendors to supply these. Usually, just-in-time manufacturing procedures dictate that when inventory of raw materials or parts goes below a certain level, the procurement procedures determine the inventory requirements for the raw materials and parts. A procurement order to restock the inventory to support the manufacturing plan is then placed with an appropriate vendor.

These requests are directed toward the set of suppliers that the company has established relationships with. The suppliers can then respond with their bid (quote) for supplying the desired quantity. A quote usually minimally includes the price for the quantity and the terms related to supplying at that price. An example term that could be associated with a quote could be its expiry date. Because the market price for many raw materials fluctuates, the expiry date protects the supplier from vast differences between the quoted price and the market price.

Optimizing procurement processes has long been recognized as a valuable tool to provide a competitive advantage to companies. The optimization, in this case, involves several factors. It is not always the cheapest supplier that wins orders. The quality, credit rating of the vendor, other references, and recommendations, as well as the company-vendor relationship history, all play a role in the awarding of a contract to a specific vendor. Something as fleeting as the procurement manager's bad vibe around a particular vendor might also throw a few vendors off the playing field. Similar criteria come into play when a supplier makes a decision to respond to a manufacturer's need for raw materials and parts. For example, even if a supplier has a good relationship with a manufacturer, it may decide not to respond to a particular request because the order is perhaps too small or too large for the supplier to handle. Optimizing the chain of events from the point in time when a inventory need is recognized to the time it is received (i.e., the procurement cycle) is a complex undertaking, mainly because so many nontechnical factors affect the final decisions made.

The process by which a buyer and a seller come to an agreement to engage in a trade is called the RFQ process. An RFQ (request for quote) is a very commonly used procurement process for obtaining goods, raw materials, supplies, labor for contract work, and other services from vendors. This is also called direct procurement because, in this case, the customer buys the goods directly from the vendor. It is interesting to note that the RFQ is a generic process that is useful whenever someone has a need for service to be performed or goods to be obtained outside the scope of their entity and needs to locate the appropriately skilled entity to fulfill that need. A state government desiring to widen a major freeway may develop an extensive RFQ to put forth in the civil engineering industry.


12.2 RFQ Basics

The most generic process of direct procurement involves the following steps:

  1. The buyer posts a list of required items to appropriate suppliers.

  2. The RFQ document includes specification, configurations, and other raw materials or parts criteria.

  3. The RFQ is reviewed by one or more suppliers.

  4. The suppliers then submit a bid or quote in response to the RFQ.

  5. The buyer reviews and awards the contract to one or more of the responding suppliers.

  6. The goods and money exchange hands.

The RFQ process can be classified into the following categories:

  • Single-Step RFQ: In this case, the buyer knows exactly what it wants (especially true in the case of tangible products). This is the process defined above. Industries that typically use single-step RFQ are the electrical, mechanical, semiconductor, medical equipment, aviation, metals, and customized parts industries.

  • Two-Step RFQ: In the two-step RFQ process, the buyer asks for a proposal based on a generic requirement (consisting of a description of the desired product or service) in the first step. This is generally used when the exact requirements, specifications, and desired result are not easily described. The document distributed by the buyer is called a Request for Proposal (RFP). The selected RFPs go into the second step, in which companies negotiate on the requirements and the price associated with those. Industries such as software services and civil construction employ a two-step RFQ process. In general, an RFQ is used for needs that can be described in a very specific manner. An RFP is used either when the products are complex or requirements are not very well understood. In such a case, the first step helps in solidifying the requirements, so that the supplier can quote a price based on these.

  • Multistep RFQ: In this type of procurement, there may be several steps before the actual bidding begins. Government contracts, typically, follow a multistep RFQ. The first rounds are related to supplier selection. For example, a certain contract may require that the supplier company have certain certificates of standardization or it must employ environment- and animal-friendly procedures in its manufacturing. Some companies are selected based on their abilities to satisfy the early step requirements. These chosen companies then can participate in RFQ processes similar to the single-step or two-step RFQ processes.

Another important factor is the process by which the buyer chooses to announce the RFQ. In general, a buyer can announce two types of RFQs:

  • Private RFQ: In this case, the buyer creates the RFQ and sends it to pre-selected suppliers; these suppliers could be a subset of the entire supplier list. These are the only ones eligible to bid on the particular RFQ. The list of suppliers is subject to the buyer's selection criteria and may vary from time to time. Usually, companies use private RFQs if they have a special trust and confidence in the suppliers' ability to deliver on the RFQ. A private RFQ is easy to administer. However, it limits the participation of the suppliers. The received quote is best only among the group of chosen suppliers.

  • Public RFQ: In a public RFQ, in contrast to the private RFQ methods, the buyer creates the RFQ and announces it to the public for bidding. All or any suppliers are free to bid on such an RFQ. The public RFQ ensures that all the interested suppliers get a chance to bid, but it is also difficult to administer.


12.3 RFQ Business Process Flow

In general, an RFQ goes through several stages during its processing cycle. Below, we define a very general description of the business process associated with RFQ processing. There are several variations in practice that are specific to each industry. Also, in most real-world implementations, there is a uniqueness associated with each company's business flows. Figure 12.1 depicts this process flow.

Figure 12.1. General RFQ process flow.

  1. Buyer identifies needs for purchase of direct procurement material and creates the RFQ, which typically includes a list of items, specifications, diagrams and pictures, terms and conditions, quality requirements, and delivery schedule for the material that needs to be purchased.

  2. Buyer chooses an RFQ methodology. This determines the steps involved in the RFQ process and the potential set of suppliers who are eligible to respond.

  3. After complete review of RFQ data, buyer posts the RFQ.

  4. Appropriate suppliers determined by buyer's RFQ methodology get an invitation to participate in the RFQ process.

  5. Interested suppliers review the RFQ and decide whether to send a response to the RFQ.

  6. Each interested supplier prepares the bid for the RFQ, which typically contains information about prices for the items requested by the buyer, delivery schedule, and the supplier's terms and conditions.

  7. Supplier, after review, submits the bid to the buyer.

  8. After a certain prespecified date, the RFQ is closed.

  9. Buyer reviews all the submitted bids.

  10. Buyer then rewards the bid to one of the suppliers. The selection of a specific supplier is based not only on the quoted price but also on other crucial factors, such as quality and availability of material (or some other deciding criteria appropriate to the situation).

  11. Buyer will send the appropriate bid award and rejection notification to participating suppliers.


12.4 RFQ Processing for AmCAR, Inc.

Consider a car manufacturer, AmCAR, Inc. AmCAR is a leader in the car industry and is known for its innovative car designs. AmCAR has manufacturing plants around the world to optimize the cost of manufacturing. These plants manufacture several different car models, based on the local market preferences and demands.

Manufacturing cars requires AmCAR to have several raw materials and parts on hand. Everything from the tires to the sunroof glass, to the metal for doors is procured from various suppliers. AmCAR has been in the car industry for several years and has developed an extensive list of suppliers. Its suppliers are categorized under several categories such as components they provide, geographic location, and the tier they belong to. Ideally, all procurement would happen from the top-tier suppliers, but as we noted before, suppliers also have a choice to respond to a company's material needs, and hence, managing a host of suppliers (multiple ones for any part in particular) is a very important part of the procurement process.

In most cases, AmCAR floats an RFQ to its list of suppliers. This list must be managed in an efficient manner and kept updated. The supplier that submits the most optimal bid is awarded the contract for that particular part list. Recall that the optimal bid is a combination of price, circumstance, and general confidence about the situation and the suppliers involved — especially when AmCAR's top-tier vendors choose not to respond to an RFQ. In some cases, AmCAR decides to award partial contracts to two or more suppliers to complete the desired quantities. The requirements for the platform that enables this interaction between AmCAR and its suppliers can be summarized as follows:

  • Support for private RFQ

  • Support for targeted RFQ delivery

  • Support for anonymous contract announcements

  • Support for easily discoverable RFQs

  • Support for easily discoverable bids

  • Support for real-time notification of new RFQs and bids


12.5 The AmCAR Procurement Ecosystem

AmCAR's procurement department and the participating suppliers must work together to create a solution that will enable AmCAR to float and process the RFQs effectively. Essentially, all the participants form an ecosystem that caters to a specific need — i.e., the exchange of RFQ information between AmCAR and its suppliers.

Since the RFQs are private in nature — being floated to only very specific vendors — the ecosystem is also private in nature. It exists to serve the car manufacturing needs of only AmCAR corporation. The access to this ecosystem is controlled by AmCAR, and AmCAR also makes business and technical policy decisions to operate this ecosystem. It is not unusual for big companies to create such private ecosystems that cater to their needs and the needs of their partners. Note that AmCAR could have also decided to participate in some existing public ecosystem. However, deploying a private ecosystem is desired for confidentiality reasons.

Note

There are several advantages to a private ecosystem. For the ecosystem host, which is usually the ultimate beneficiary of the ecosystem as well, a private ecosystem gives a high degree of control over the functioning of the ecosystem. The business and technology policy decisions can be made by the host swiftly and to the extent that they benefit the host itself. A private ecosystem is also a good alternative in absence of a (competent) public ecosystem. In such a case, the private ecosystem, if successful, can be transformed into a public ecosystem. The SABRE system developed by American Airlines is a good example of such a transition.

Because AmCAR is designing, developing, and implementing the platform to en-able the interaction between the ecosystem members and itself, it acts as the ecosystem host. It is also the governing body for this ecosystem because it makes the policy decisions for this private ecosystem.

Recall that the governing body is responsible for the operating framework in the ecosystem — i.e., the tModels, interaction specifications, and other operating procedures. Of course, some of these require active participation from the suppliers themselves. For example, it is essential that the major suppliers are involved in defining the RFQ process flow. The set of tModels and specifications defined for the ecosystem would be binding to all the members, and adherence to them is essential for smooth functioning of the ecosystem.

12.5.1 Interaction Specifications

As part of defining the functioning of this ecosystem, several interaction patterns and specifications must be defined. The RFQ process defined in Section 12.3 can define the overall process and may be registered with the registry as a tModel. In addition, several other candidate tModels could be those defining various terms or subprocesses. Table 12.1 depicts an example of terms used within an RFQ. This specification is represented by the corresponding tModel.

Table 12.1. RFQ Terminology tModel

Attribute

Description

RFQ number

15 character alphanumeric reference number used for RFQ.

RFQ description

Description of the RFQ in free-flow text.

Start date

Date (mm/dd/yy) on which the RFQ is posted onto the RFQ system and is available for bidding

End date

Date after (mm/dd/yy) which no bids are accepted: i.e., the RFQ is closed

Category list

The category to which the RFQ belongs

Billing details

Billing address

Shipping details

Shipping address

Payment details

Credit card, escrow, demand drafts, or otherwise

Vendor information

UUID of the business entity registered in the designated UDDI registry

Note

Free-formatted text for comments from the buyer (up to 1000 characters)

Terms and conditions

The different terms and conditions include payment terms, transportation terms, conditions for sale, and other terms (up to 1000 characters)

Item code

A unique item code (up to 16 characters)

Item name

Name of the item (up to 100 characters)

Item description

Description of the item (up to 100 characters)

Unit of measurement

The basic unit by which the quantity of the item is measured

Quantity

Quantity of the item

Expected delivery schedule

Expected delivery date for the item

Quality

Quality requirements for the item

Attachments

These might be specs or drawings related to items

Dimensions

Dimensions of the item

Unit of dimension

Unit of measure of the dimension; valid values are CM, METER, FT

Weight

Weight of the item

Unit of weight

Unit in which the weight is specified; valid values are KG, LB, OZ

In a complex ecosystem, such as this, a single set of interaction specifications may not be sufficient to include all the parties involved. Typically, various members will be already abiding by certain known standards and the ecosystem will need to incorporate some or all of them in order to minimize the impact on individual members. Failure to do this could result in significant design and development efforts, as the members strive to comply by the new standard, or withdrawal by members who are not interested in investing into the effort.

In such a case, the role of registry is even more important as it contains information about specific tModel-compliance by any registered service.

Figure 12.2 depicts the AmCAR Parts Procurement ecosystem. As shown, the UDDI registry plays a central role in this ecosystem.

Figure 12.2. AmCAR Parts Procurement ecosystem.

All the concerned business entities, AmCAR and the suppliers, are listed in the registry. The information included for these entities includes the usual set of fields such as contact name and contact address. Note that the purpose of the registry is limited to the private ecosystem it serves. Thus, the information contained here could be very specific to this ecosystem. For example, the contact name for AmCAR would be the operational manager responsible for day-to-day operations of the ecosystem. When a contact name is required for AmCAR home page registration within Universal Business Registry (UBR), it will perhaps be the official spokesperson for the public relations firm.

The registry also includes information on services deployed by these entities. A Procurement service that belongs to the AmCAR procurement department manages the RFQ process. This service is responsible for creating an RFQ and pub-lishing it to the suppliers through the AmCAR Procurement ecosystem. The Procurement service will interact with the registry to find all the suppliers and their bidding services. The designed architecture and interaction patterns among participants of the AmCAR Procurement ecosystem are shown in Figure 12.3.

Figure 12.3. Architecture of the AmCAR Procurement ecosystem.

12.5.2 Procurement and Supplier Services

With the selection of the deployment platform, the services (Procurement and Supplier) need to be described, registered, and discovered in a similar fashion to those discussed in the examples of this book. The AmCAR Procurement service is responsible for floating new RFQs, using information extracted from a system that contains the product information and the bill of materials (BOM). Each RFQ could be an UDDI-registered service, that is described and registered with the ecosystem. The supplier services respond to the RFQ positively by generating a quote or negatively by rejecting the RFQ. Like the RFQs, individual bids could also be UDDI-registered services in the ecosystem.

The services follow a defined set of specifications, represented by tModels in the registry, to participate in the ecosystem. The services describe themselves, register themselves, and finally, interact with others. As discussed in Chapter 3, these services could be implemented as Web services. In such a case, the operational interfaces of the Web services must be agreed upon and represented via corresponding tModels. The Web Service Description Language (WSDL) corresponding to this interface is provided as part of the overview documentation section of the tModel.


12.6 Extending the Solution

It is easy to imagine that the solution described above could be extended beyond just one pair of interacting nodes in the supply chain. After all, AmCAR will be supplier to its dealers and AmCAR's suppliers will also have their own raw material providers. The kind of interactions involved across this supply chain will be similar. Hence, a broader ecosystem could be perceived where many more roles could come together.

In such an extended supply chain, it may not be practical to have a single participating entity, like AmCAR, be the governing body and ecosystem host. The solution is likely to be more in public or jointly-owned environment. If such a setup exists, the AmCAR Procurement Ecosystem becomes only a piece of the bigger puzzle. Accordingly, respective registries for the bigger solution and the AmCAR ecosystem will carry different sets of data with some common sets of information shared. The registries themselves can be thought to be part of a "network of registries." This concept is explored further in Chapter 14.


12.7 Location-Based Mobile Services

While in the software industry Web services are making waves, in the hardware world, mobile devices seem to be in fashion. Literally millions of these smart devices have been sold worldwide. There are several different types of such devices available today, including pagers, cell phones, and Personal Digital Assistants (PDAs). Several other new information appliances are being designed and will be available soon. There are two noticeable trends in the mobile industry today: integrated devices that have dual (or multiple) functionality and services on top of the device. Both of these dimensions are enhancing the usability of these devices and making them more indispensable. The integration trend has resulted in devices such as Sony Clié (integrates an MP3 player with a PDA) and HP iPaq (integrates a cell phone with a PDA).

The value-added services, on the other hand, use an existing device and build a functionality stack on top. Services such as corporate email and mobile information systems for the sales force of a company are examples of such services. These mobile services are the intersection between the mobile space, and Web services. One important class of mobile services is location-based services.

Location-based services, as the name suggests, provide location-savvy functionality. As the user's location changes, service invocation results in a different outcome. Some examples of location-based services are: finding the nearest point of interest, dating services, and on-the-spot product promotions. In this section, we discuss a special case of point-of-interest, location-based services.

12.7.1 Mobile Printing Scenario

Consider Ron Danforth, a salesman with CoolSoft, Inc. — a company that makes accounting and financial software products for small and medium-size businesses. As part of his responsibilities, Ron is required to travel all over North America — his sales region — to talk to business owners and explore sales opportunities.

Being in the software industry, it is imperative for Ron to stay abreast with the latest happenings in the software industry, as well as in the financial services world — his clientele. In addition, he also needs access to customer-specific documents required during customer visits. These include product data sheets, customer information, such as buying history, and details of any contracts with the customers. Before mobile devices became popular, Ron used to take his laptop computer everywhere so that he would be able to connect to the Internet from his hotels and get the information he wanted. These days, however, Ron prefers to take his handheld device, Corona, on shorter trips. Corona is a top-of-the-line mobile device that has aPDA integrated with a cell phone. The PDA part of the device is also equipped with a wireless communication subsystem. Using the wireless subsystem, the device can connect to the Internet through a wireless Internet Service Provider (ISP). Corona can store contact information, limited customer data, and limited product information. Corona can satisfy most of Ron's information needs; however, it does not provide access to everything because of its limitations.

First, storage space limits the amount of data it can carry. Second, the current wireless protocols supported on it provide a very low bandwidth. This prevents downloading large documents through the communication link. Finally, because it is a handheld device, it has a very small form factor (screen size). This limits the amount of information that can be displayed on its screen. To optimize available storage space on the device, Ron takes only the company private data he needs on the device. He uses the Internet connection, albeit slow, to download any public information. These limitations make it difficult for Ron to have the information he needs — especially on important sales visits. According to him, it would be great to have a summary of the information (for example, news headlines) on the device, then get elaborate information on a specific item (for example, the article associated with a news headline) in print format when desired.

There are two problems that prevent Ron from making this scenario a reality. Due to bandwidth limitations, it is difficult to download detailed information. Even if he manages to download the information, he does not always have access to a printer. A mobile printing solution can help Ron stay informed, even if he is on the road. To understand the solution, it is useful to know more about the world of mobile devices.

12.7.2 Mobile Technologies

Although wireless communication technologies have been around for several years, they did not intersect with computing technologies. This is because wireless technologies were primarily focused on voice communication. Devices such as walkie-talkies and cell phones are examples of early versions of the devices that used wireless technologies. Recently, however, a number of more intelligent devices utilize wireless technologies for different purposes. These include handheld and pocket computers that extend the PDA functionality on the device, pagers, and Wireless Access Protocol (WAP)-enabled cell phones. This new breed of devices is much more intelligent, compared with earlier devices. They usually include a processor and an Operating System (OS) kernel that brings them closer to a computer. In fact, Microsoft-enabled devices are called handheld and pocket PCs!

The features of the mobile devices are defined by three dimensions — platform, protocols, and services. The platform provides the core of hardware and software functionality. The protocols are part of the communication subsystem that help the device connect to the rest of the digital world, and the services enhance the value of the device by adding more features. Figure 12.4 depicts the mobile space. The connectivity options available on a device play a crucial role in the effectiveness of any service offered on it.

Figure 12.4. Dimensions of mobile device features.

Mobile Communication Protocols

To connect to the public network, a handheld device needs to communicate with a gateway that is connected to the Internet. The connection protocols vary from device to device. For cell phones, the WAP has been available for some time.

ForPDA-type devices, protocols such as CDPD (Cellular Digital Packet Data) and GPRS (General Packet Radio Services) are gaining popularity. Both of these technologies fall under the Wireless Wide Area Network (WAN) technology class. These protocols provide public network connectivity through a wireless service provider. Another class of wireless access protocols is also emerging, called Wireless Local Area Network (LAN) protocols. The protocol 802.11b is a good example of such a protocol. Wireless LAN protocols, as the name suggests, provide access to a local area network. A wireless LAN infrastructure is typically deployed within a corporate network boundary. Wireless LANs are characterized by bandwidth that is much higher, compared with wireless WAN bandwidth. However, a wireless WAN is more pervasive, compared with a wireless LAN. The wireless LAN technologies offer connectivity for a device within a close proximity from the LAN access point. Compared with that, wireless WAN connectivity is possible virtually anywhere.

A hot spot is a location from where high-bandwidth connectivity (typically through wireless or wire-line LAN technology) is available. Examples of hot spots are corporate offices, airports, and coffee shops. Usually, these locations are equipped with high-speed Internet connectivity. A device that is connected to the network from a hot spot can transact more effectively, due to the availability of high bandwidth. Whenever possible, a user would prefer to have device connectivity established from a hot spot. However, when it is not possible to do so, the wireless WAN technology is another option. Together, the wireless LAN and WAN technology can provide close to an "always connected" experience from a mobile device. The mobile ecosystem that facilitates mobile printing on demand consists of such devices and a backend connectivity infrastructure.

Many Web sites are mobile-device savvy and can filter the content before it is sent to such a device. This filtering is called repurposing. A repurposed site appears, potentially, much different from the original Web site. Several features (for example, graphics and navigation icons) not supported on the device are omitted for a better user experience. Repurposing can also limit the amount of information sent to the device, and thus, only a subset of the information, that which is deemed vital, may be sent to the mobile device. Repurposing is a very effective and bandwidth-friendly way to get the gist of the information to a mobile user.

12.7.3 Mobile Printing Ecosystem

A solution to Ron's problem requires alliances between various entities, such as print service providers and location-savvy components in the mobile marketplace. It would be easy to think of this new set of interactions in terms of an ecosystem that serves a specific need — namely, mobile printing. The Mobile Printing ecosystem can bring necessary services together and define the interaction among them to facilitate mobile printing needs similar to Ron's. Figure 12.5 depicts one such ecosystem.

Figure 12.5. The Mobile Printing ecosystem.

The user of the ecosystem services in this case is a mobile professional who would like to stay connected with the Internet while on the road and would like to get as much information as he or she needs by circumventing the limits of the mobile device used. The service-user uses the mobile device to connect to the Internet through one of the connectivity options described previously and gets to the desired information. The general activity of web surfing is not necessarily visible to the ecosystem in this case. Presumably, the Web sites providing the information of interest to the user are repurposed for the device. When a user is interested in receiving detailed information, the interaction with the mobile printing ecosystem begins.

At the center of the mobile printing ecosystem is the ecosystem host. The ecosystem host brings together the mobile device users and the print service providers. From that aspect, its role is similar to the procurement ecosystem host, discussed previously in this chapter. A request from a service user typically includes the Uniform Resource Locator (URL) of the information that needs to be printed and the location of the user. The request also specifies certain print-quality instructions, such as color or black-and-white copies or two-sided and photo-quality printing.

Several methods and technologies to specify locations are available in the market today. UDDI Version 3 specification enhances the location capabilities further compared to the Version 2 specification. A location service that effectively determines the exact location of the service-user is an important part of the mobile printing ecosystem. Once the location of the service-user is determined, a suitable Print Service Provider (PSP) must be located that can fulfill the user's print request. This search, based on location information registered for the PSPs in the registry, can take into account several predefined and user-specified parameters to find a printing provider. To enable this discovery, each PSP must register a service representing itself (or each of its stores, if it is a chain) with the ecosystem and describe its capabilities. The tModels required in the ecosystem can be defined by an independent consortium or the ecosystem governing body.

Using the service descriptions and the location of the user, the Mobile Printing service can locate the most optimal PSP that can fulfill the user's request. Once a suitable PSP (or PSPs) is found, the service notifies the user about the PSP locations and other attributes, such as the price and rating associated with that PSP. The user then decides whether to respond to any offer and communicates his or her decision to the Mobile Printing service. The service then submits the request to the appropriate PSP. Once a PSP receives a print request, it is submitted in the print queue. When printing is completed, the PSP can notify the user so the user can pick up the document at a designated time.

The interaction sequence, agreed upon by the major players and represented in the registry as a tModel in the Mobile Printing ecosystem can be as follows:

  1. The Mobile Printing ecosystem host creates the necessary platform for its functioning.

  2. The ecosystem host invites appropriate entities to populate the ecosystem. These entities include the governing body, foundation and extended services, and potential service users.

  3. The PSPs that wish to participate in the ecosystem register their print capabilities with the ecosystem.

  4. The user submits a mobile printing request to the Mobile Printing service. The request includes the user's location, the URL of the document(s) to be printed, print-quality, and pickup instructions.

  5. The location service determines the list of potential PSPs that can fulfill the user request.

  6. Using the user parameters, the Mobile Printing service selects the best PSP that can fulfill the user request.

  7. The Mobile Printing service communicates the list of PSPs and pertinent data for the user's consideration.

  8. The user determines whether he or she wishes to submit the print request to one of the PSPs.

  9. The user submits electronic payment (digital wallet-based or credit card) to the PSP.

  10. The PSP receives the print request and determines the best printer from its printer farm to queue the print job.

  11. Once the document is printed, the PSP notifies the user that the document is complete and provides directions from the current location or a specified location to the PSP.

  12. The user retrieves the document from the PSP at the designated time.


Part IV: Expanding UDDI

In this Part

Chapter 13: Competitive Landscape

Chapter 14: Version 3 and Beyond


Chapter 13. Competitive Landscape

  • Recognized Leaders

  • Strong Industry Participants

  • Registry Technologies

The services-based economy is characterized by industry leaders and thinkers as the next wave in the high-tech world or the Next Chapter of the Internet unfolds. Keep in mind that several software companies, including a few software giants, have invested in this space and developed technologies to promote open and standards-based service-centric computing.

In this chapter, we depict the competitive landscape portraying both the recognized leaders in this space as well as competing registry technologies. Since the registry and Web services technologies are evolving, currently no specific product or vendor can be pointed out as a clear winner or leader. That can happen only after the standards and technologies mature and companies strive to accommodate them. We provide only comparative analysis in this discussion.


13.1 Recognized Leaders

Due to the close relationship between the UDDI registry and the Web services paradigm, several vendors include support technologies for both in their offerings. While surveying vendors, it is thus useful to compare the features for both these technology sets.

Microsoft and IBM are recognized as leading the effort for both furthering the Web services economy and providing technologies to support it. In this chapter, we primarily focus on the technologies provided by these companies.

13.1.1 Microsoft

Microsoft's DOT NET (or .NET) is the first Web service technology mentioned in this chapter because Microsoft — along with IBM — has taken a leadership role in defining what Web services means and how to make them a reality. The DOT NET strategy is a significant change in the way software applications are constructed and deployed.

Microsoft's DOT NET announcement was quickly followed by several white papers describing the Web services components, such as SOAP (Simple Object Access Protocol), the BizTalk 2.0 Framework, and UDDI (Universal Description, Discovery, and Integration). Microsoft also released software developer kits (SDKs) for DOT NET, UDDI, and BizTalk 2.0. This generated a lot of interest among the developer community as these components and related white papers explained Microsoft's vision for Web services by providing developers with sample infrastructure components that would allow them to test-drive Web services and DOT NET concepts.

The early foundations for Microsoft's DOT NET are SOAP (which began its life as XML-RPC) and the CLR (Common Language Runtime). CLR is Microsoft's new Operating System (OS) infrastructure that allows software applications and components written in different languages to intercommunicate. It is like a virtual machine that can execute Visual Basic, Java, C#, C++, and other languages. At an architectural level, the CLR resembles Sun's JVM (Java Virtual Machine). It provides garbage collection, namespaces, metadata, etc. But unlike Sun's JVM, the Microsoft CLR integrates smoothly into the overall operational infrastructure that Microsoft provides, including: IIS, COM+, ASP+, and DOT NET Web services.

Although Microsoft's CLR work may end up being extremely useful for advocates of multilanguage development and Java-like languages, the Web services portion of DOT NET does not really require much of the CLR infrastructure on the server side. And clients of DOT NET Web services can be written in any language — Microsoft CLR-compatible or not. In fact, a developer can easily connect a Perl client running on a Linux operating system to a Web service provider written using DOT NET software. And this is what Web services are all about. This flexibility has also assisted Microsoft in its ability to gain developer mindshare and strong support of the DOT NET platform.

DOT NET clients communicate with services by exchanging XML documents — usually via HTTP/S POST messages. XML documents that are exchanged contain no trace of what language was used to generate them. So, for example, Java Web services clients can easily communicate with COM+ Web services written in C#. The languages used to write the clients and servers just do not matter.

Note

At the core of the Web services vision lies the interoperability and the desire for platform/language independence. The important thing is that the client and the server can exchange XML documents with each other — and that both the client and server can interpret any "enveloping" that is used to wrap and transport those documents.

Developing clients and servers that can parse and create XML documents is rather simplistic at this point. The open source community provides a number of XML parsers and generators based on the Document Exchange Model (DEM) and Simple API for XML (SAX) standards. These parsers and generators exist for all the languages used to develop Internet-based applications today. Microsoft continues to provide up-to-date DOM- and SAX-based libraries that can be used from any Microsoft-supported language (such as C#, C++, Visual Basic, and JavaScript).

The tricky part of getting clients and servers to be able to communicate by exchanging XML documents is for there to be a universally agreed-upon "enveloping" technology used to wrap the XML business documents that are exchanged. Previously, the most likely candidate for transporting XML data between clients and servers was the XML-RPC standard — proposed by DevelopMentor. This was a standard that allowed clients to invoke methods synchronously on servers by sending the servers XML documents containing the name of the method to invoke and the parameters to pass into the method. Once a server received an XML-RPC message, it would invoke the requested method, then return the results of that method invocation (the return value — if any — from the method call) as an XML document. The XML-RPC request was sent by the client to the server in an HTTP POST, and the HTTP response to that post contained the XML-RPC response.

On the inside, XML-RPC defined an XML vocabulary representing an "envelope" that contained a "body." Within that body was the XML payload that a client was sending to the server (and that the server returned to the client). The rules were that the transport-specific information should be contained in the HTTP POST message and the envelope part of the XML- RPC message, and the body of the XML-RPC message would contain the business document. Because XML-RPC was originally about making method calls, the business document transported within the body was actually an XML representation of either a method invocation (if you were a client sending the XML to the server) or an XML representation of the results of a method call (if you were a server returning a result to a client).

XML-RPC was a good starting point, but it was designed primarily for synchronous calls. This is not a very scalable solution when there are very many clients concurrently invoking services provided by a single server. A better solution would be an enveloping technology that allowed for synchronous or asynchronous communication of XML documents. On top of that, it would allow the XML business documents exchanged to be either XML representations of method invocations or full-blown business documents — such as purchase orders, invoices, and receipts. DevelopMentor worked with Microsoft to extend the definition of XML-RPC to include these new features. This work later was renamed SOAP. The SOAP specification has been submitted to the W3C (World Wide Web Consortium) for standardization.

Early SOAP toolkits provided client-side code and a listener Active Server Page (ASP) that assisted in creating Web services and invoked them from any Microsoft-supported language. At that time, because a standard for describing the "public interfaces" of Web services was not developed, this toolkit used Microsoft-proprietary Service Definition Language (SDL). This language was used both to generate the client-side proxy for calling a Web service and for configuring the server-side listener so that the listener knew the action to be performed when it received a Web service call.

The DOT NET Framework SDK was available soon after the SOAP toolkit. This SDK was much richer than the early SOAP toolkit. It provided a plug-in for Internet Information Server (IIS) that allowed IIS to understand when it was hosting a servlet containing a Web service. And the SDK provided a simpler-to-use client-side Application Programming Interface (API) for invoking Web services from Visual Basic or C#. In fact, this SDK provided a C# compiler and early release components of the CLR. With this new SDK, all a developer had to know to create a Web service were the extra ASP labels required to tag or denote the code as a Web service as explained in Chapter 3.

At around the same time that Microsoft released its DOT NET SDK, it also released its UDDI SDK. The UDDI SDK provides client-side libraries for registering and looking up services whose metadata is stored in a UDDI registry. This SDK is the focus of Chapters 7– 9.

At the same time that technology companies are doing a good job of attempting to define and implement the infrastructure for Web services, there are standards organizations, such as RosettaNet and ebXML, that are defining higher-level concepts that will be necessary in order for truly rich business-to-business (B2B) communications to work using Web services. And the more time that these standards organizations spend defining how businesses will intercommunicate, the more they are reaching down the technology stack and defining the standards for implementing their specifications.

So what this all means is that the Web services work being done by Microsoft, IBM, and the W3C is beginning to collide with standards being proposed by RosettaNet and ebXML. This collision of standards will likely help the entire industry to mature the direction of Web services. However, in the short term, what this means is that the standards are still in a great deal of flux.

Microsoft is building its DOT NET story from the ground up, slowly releasing the low-level technologies that implement parts of the overall strategy.

Microsoft BizTalk 2.0 Framework

The goal for the BizTalk 2.0 Framework Specification is to provide an interoperability framework that allows servers to conduct business securely over the Internet. It basically adds the extra layers above SOAP that are required to provide an interoperability framework.

Microsoft's BizTalk 2.0 Framework is the business infrastructure that rides on top of its lower level Web services infrastructure based on SOAP. BizTalk 2.0 evolved from an earlier version of BizTalk (1.0). BizTalk 2.0 takes into account Web services and makes sense in the context of Web services and Microsoft's DOT NET initiative.

The BizTalk 1.0 Framework was announced prior to Web services (and thus DOT NET). It was basically a message routing and transformation technology that would allow businesses to front-end the backend transactions with a unified presentation layer. Clients could submit business documents to a BizTalk 1.0 server using Microsoft Message Queue (MSMQ), IIS, or Simple Mail Transport Protocol (SMTP). The server would then translate the message — if necessary — into the format that the backend service provider could understand. Then the BizTalk 1.0 server would send the message along to the Inbox (a real SMTP Inbox, a Uniform Resource Locator [URL], a message queue, etc.) of the service provider. So basically, BizTalk 1.0 was all about routing messages and transforming them.

The BizTalk 2.0 Framework is at least two additional things — a specification (that can theoretically be implemented in any language on any OS) and an implementation. The implementation is Microsoft's BizTalk 2000 Server. The BizTalk 2.0 Framework Specification is straightforward and sensible. It builds on the simple method invocation roots of SOAP and extends SOAP — by introducing new subelements of the SOAP Header element — to provide a robust, reliable transport mechanism for conducting business over the Internet.

SOAP does not define any way to associate documents together into a conversation or sequence of related documents. SOAP does not specify how to guarantee that messages are delivered or that they are not stale (i.e., not too old). A robust transport and enveloping technology must take into consideration these issues and more. This is where the BizTalk 2.0 Framework comes in. The framework defines properties for business documents that are transported using SOAP. A BizTalk document is a SOAP 1.1 message in which the body of the message contains the business documents, and the header contains BizTalk-specific header entries for enhanced message-handling semantics. The following concepts apply to BizTalk documents and are specific definitions from the BizTalk 2.0 Specification:

  • Lifetime: The time period during which a document is meaningful. A document must not be sent, accepted, processed, or acknowledged beyond its lifetime.

  • Identity: A universally unique token used to identify a document. This identity is subsequently used during various transactions handling the document.

  • Acceptance: The act of being accepted for delivery by a receiver. A received document is accepted if it is recognized as being intended for an endpoint served by the receiver, including documents that are copies or duplicates of previously received documents (based on the identity). Acceptance does not mean that all header entries and the body have been inspected and their contents verified for any specific purpose.

  • Idempotence: The ability of a document to be transmitted and accepted more than once with the same effect as being transmitted and accepted once.

  • Receipts: BizTalk Framework includes end-to-end protocols that prescribe certain receipts to be sent by the receiver to ensure delivery semantics in some cases. These receipts are first-class BizTalk documents with a prescribed syntax. There are two receipt kinds defined in this specification:

    • Delivery: A receipt to acknowledge that the receiver accepted a given document for delivery.

    • Commitment: A receipt to acknowledge that, in addition to being accepted, a given document has been inspected at the destination endpoint, all header entries marked mustUnderstand="1" have been understood, the correctness of their contents (as well as the contents of the body) have been verified, and there is a commitment to process the document.

In addition to specifying the headers required to guarantee a level of reliability and traceability, the BizTalk 2.0 Framework also discusses security techniques and the overall responsibilities for a BizTalk 2.0-compliant server. The most fundamental elements of a BizTalk 2.0 server are:

  • Interoperability: BizTalk servers need to be able to intercommunicate with each other using a wellknown transport and enveloping technology (SOAP). They also need to use standard Internet messaging technologies to transport SOAP messages. These include: HTTP/S, SMTP, and File Transfer Protocol (FTP), to name a few. The business documents that are exchanged need to be understandable by all intercommunicating nodes. Therefore, XML Schema and Data Type Definitions (DTDs) are used to provide metadata describing the content and meaning of XML business documents exchanged between BizTalk servers.

  • Service Description: BizTalk servers must provide metadata that describes service access points and their public interfaces. Microsoft's first vocabulary for doing this was called Service Control Language (SCL). This later evolved into SDL. The industry as a whole is now converging on using WSDL.

  • Service Discovery: In 1999, the year that Web services made their debut, there were a number of possible technologies that could have been used for service discovery. At that time, X.500 directories and the Lightweight Directory Access Protocol (LDAP) were strong candidates. They provide a very simple technology for storing strings in a directory and for accessing those strings. Often, these directory technologies were used to store public phone book entries, public keys for Internet security, and other strings that might be useful across large distances but that could be administered within a federation of directory servers. These technologies came out of the box with a well- known and rigid schema. However, they would allow you to extend their schemas for your needs. At about this time, IBM proposed ADS (Advertisement and Discovery of Service) and Microsoft proposed DISCO (Discovery of Web Services).

In its beta form, the BizTalk 2000 Server did not communicate using SOAP. Instead, clients could communicate with it using HTTP POSTs of non-SOAP messages or they could use Microsoft's MSMQ. But the BizTalk 2000 Server does introduce some concepts that are missing from the BizTalk 2.0 Framework Specification. These seem to be essential for real-world B2B communications to be enabled over aWeb services infrastructure. One of these concepts is that of a business process. Currently, the BizTalk word for business processes is XLANG schedules.

XLANG Schedules

An XLANG schedule is a set of steps — just like a workflow — that are invocations of objects, sends of messages, and receives of messages. All of the steps together form abusiness process. In its current implementation, BizTalk Server comes with a version of Visio that allows you to draw these business processes. The processes are then described using an XML vocabulary invented by Microsoft and called XLANG. An XLANG document describes a business process, and a running instance of one of these business processes is called an XLANG schedule.

Along the lines of the business process is the concept of orchestration. Basically, orchestration is the runtime component of an architecture that executes XLANG schedules. It is the part of the infrastructure that remembers where you are in a business process with a business partner. And it knows what steps of that process you have already completed. Orchestration enables execution of long-lived business processes.

Microsoft is proposing XLANG as the preferred XML vocabulary to use to describe public business processes. However, in its current form, XLANG does not do a very clean job of differentiating between the public steps of a business process and the private ones. It simply combines them all together, just like most workflow engines do today. HP has submitted to the W3C an XML vocabulary called Web Services Conversation Language (WSCL) for describing public business processes. IBM has also announced a similar XML vocabulary called Web Services Flow Language (WSFL). Regardless of which vendor's proposals influence the standards for describing business processes, the concept of a conversation or orchestration of messages flowing between business partners over the Internet is one of the primary contributions that the BizTalk 2000 Server has brought to the nascent Web services industry.

13.1.2 IBM

IBM is one of the industry leaders in the move to define and standardize Web services. It has been in this role since just about the time that Microsoft announced SOAP and IBM decided to support the SOAP specification.

IBM's involvement seemed to be driven by its push in the early 1998 timeframe to support the open source movement and the Linux OS. Around this time, IBM started to invest heavily in open source and published its AlphaWorks Web site (http://www.alphaworks.ibm.com). This site allowed anyone to download technology previews of XML parsers, XML transforms, security components, and eventually, Web services technologies. In addition to maintaining the AlphaWorks web site, IBM also became active in the Apache Project — contributing many of its XML technologies to that effort. IBM's path to Web service support and contribution is similar to Microsoft's — both these companies have published several white papers and released Web service SDK components. However, it is not reinventing itself around the concept as Microsoft seems to be doing. Instead, IBM appears to be more of a large research and development organization that has been advancing the state of the art of Web services.

IBM envisions its product offering being folded into the WebSphere line of products. IBM's Web server and application server technologies, therefore, will evolve into a tightly integrated yet open Web services infrastructure. It appears that whatever form WebSphere takes in the future, it will, as much as possible, be based on open Web services standards.

As mentioned above, the AlphaWorks Web site (and its content) has done a great service to help move the developer community toward the concepts of Web services. IBM led the introduction of WSDL as the de facto standard XML vocabulary for describing public interfaces of Web services. IBM has also been one of the primary forces behind establishing the UDDI organization. It is one of the initial three UDDI operators — those responsible for providing a highly available infrastructure of UDDI registries. (Microsoft and HP are the other two initial UDDI operators.) IBM's contribution to UDDI and other Web services standards is very notable. But it has been involved in other areas as well. One of these areas is that of interenterprise transactions (transactions across the Internet). IBM, Microsoft, and BEA recently announced the Business Process Execution Language for Web services (BPEL).

Another XML vocabulary being championed by IBM is Web Service Flow Language (WSFL). This language competes with Microsoft's XLANG. WSFL is a language that can describe the steps that comprise a Web service. The language also can be used to describe composed services: These are Web services that have a public interface (the service they provide) that is implemented by calls to a number of different services (behind the scenes). This concept is sometimes referred to as composed services. Clients of a composed service know about only its public interface — even though it is implemented by making calls to other Web services. WSFL fits into the area of Web services known as orchestration, choreography, or conversations.

It appears that WSFL may be useful behind the firewall, as well as in front of it. In front of the firewall, WSFL can describe the public interfaces of Web services. Behind the firewall, however, WSFL may be useful for describing workflows. IBM has a very successful workflow product called MQ Series, as well as a message routing and transformation product called MQ Series Integrator. WSFL may well be the glue that allows these behind-the-firewall technologies to be reachable across the Internet as Web services. If this is the case, IBM's WebSphere, combined with WSFL and MQ Series Integrator, is in direct competition with Microsoft's BizTalk 2000 Server and XLANG.

Although WebSphere and MQ Series Integrator are shipping products, IBM's Web services technologies are primarily still a work in progress. The best way to understand the current state of its Web services work is to log onto the AlphaWorks Web site and download the current version of the Web Services Toolkit (WSTK). In the current version, there are a number of components, including a UDDI registry, a UDDI browser, an Axis server (Web services dispatcher that runs above a web server), an embedded version of WebSphere, many tools, and many helpful white papers.

In its current incarnation, IBM's WSTK makes it very simple to create, deploy, and invoke Web services. For a deployment platform, you use your favorite open source Java Web Server (i.e., Jakarta/Tomcat), or you can use WebSphere. Then, you install the Axis server into your Java Web Server. The Axis server intercepts calls to Web services and invokes them on your behalf. In a sense, the Axis server does the same thing that Microsoft's IIS plug-in does with the latest DOT NET SDK. Basically, both of these components are the interceptors that are invoked by the web server when it does not know what to do with the request. These components are able to determine that the request is an invocation of a Web service, and they invoke the appropriate Web service.

The IBM WSTK makes it very simple to implement, deploy, and call Web services. The UDDI4J Java API that comes with the toolkit allows developers to create applications easily that can register and find Web services by using UDDI registries. Although many of the Web services technology downloads that IBM has released are works in progress, they provide a very rich suite of components that could be used by early adopters to develop solutions that build upon Web services. As IBM integrates these technologies into its core product lines, it is very well positioned to make a significant impact on the world of Web services.


13.2 Strong Industry Participants

Along with Microsoft and IBM, several other companies have made forays into Web services and registry technologies. Of course, not all of them have a strong footprint in the marketplace. We focus on some of the strong industry participants in the following discussion. These companies are likely to make a significant impact on the development and adoption of Web services technologies.

13.2.1 Systinet

Systinet, originally Idoox, Inc., was founded in March 2000 in an effort to capitalize on the service-based computing paradigm. The company, still in its infancy, has been involved heavily on the Web services technology development due to its focus. Systinet's WASP suite of products provides a platform for developing and managing Web service development and deployment in both Java and C++. It also includes an implementation of UDDI registry.

Systinet provides a public UDDI registry. This registry is not part of the UBR cloud, but has the same capabilities available at the sites in the UBR cloud. Systinet's UDDI implementation is also available as a free download, which is intended for use as a private registry.

Systinet has been active in the Web services initiatives and participates in UDDI, Web Services Interoperability (WS-I), and the Organization for the Advancement of Structured Information Standards (OASIS). Through its highly visible participation and contribution, Systinet stands to gain developer mind share.

13.2.2 Oracle

While the flagship products of the Oracle Corporation continue to be its database and Enterprise Resource Planning (ERP) software, it has also developed application server capabilities. The latest version, Oracle 9iAS includes several features useful for Web services development. Besides the development tools such as the Integrated Development Environment (IDE), Enterprise Java Bean (EJB) server, Oracle 9iAS also includes an implementation of the UDDI specification.

Although Oracle is not part of the UBR, its implementation can be used as a public or private registry. This implementation is, of course, integrated with Oracle's database software. Oracle is also an active participant in several Web services related standards bodies, including UDDI.

13.2.3 BEA

The WebLogic application server is BEA System's hallmark software. In its latest incarnation, WebLogic includes Web services development capabilities in its application and integration framework. Like the Oracle application server, the WebLogic server also packs several capabilities such as portal foundations, business process management, personalization engine, and Web services.

BEA is also a participant in the UDDI effort, as well as other Web services initiatives such as WS-I and BPEL. It, however, does not have an implementation of the specification. But, due to its market share and participation in Web services standards initiatives, BEA will be very influential in the direction and development of registry technologies.


13.3 Registry Technologies

One of the most important components of any distributed computing solution is a registry that can be used by components and services to advertise themselves and by clients to discover existing components and services they can access. All distributed object middleware solutions have some form of registry that serves this purpose. And, as the computer industry is beginning to realize, any viable Web service solution will need a similar component. The below sections discuss distributed computing registry technologies that serve this purpose.

13.3.1 CORBA Naming Service

CORBA specified a number of CORBA services that are pervasive throughout an ORB network. One of those services is the CORBA Naming Service. This service is actually a network-visible registry with a hierarchical data model that looks just like a file system. What you would think of as a directory in a file system is called a Naming Context in the CORBA Naming Service. Each Naming Context can contain other Naming Contexts, as well as named references to running CORBA objects.

CORBA objects make themselves "visible" to CORBA clients by placing named references to themselves within the CORBA Naming Service (or the CORBA Trader Service, which is discussed next). Clients then can obtain the remote references to running CORBA objects by asking the CORBA Naming Service for the objects by name. The CORBA Naming Service can store only references to CORBA objects. It cannot be used to store references to other sorts of distributed objects, such as COM+ objects or RMI objects.

13.3.2 CORBA Trader Service

The CORBA Trader Service was proposed by the OMG long after the release of the initial CORBA 1.0 specification. This service, unlike the Naming Service, allows CORBA objects to advertise themselves with a set of associated properties, rather than by a hierarchical "path" name. When clients search for CORBA objects using the Trader Service, clients must specify the IDL interface name they are looking for (such as BankAccount) and may optionally specify a set of properties as well, such as BankLocation=SantaCruz AND StreetName=Pacific. The Trader Service, like the Naming Service, can be used to advertise and look up only CORBA objects. The CORBA Trader Service has clearly influenced the architecture of many other registry technologies, including the JINI Lookup Service, Universal Description, Discovery, and Integration (UDDI), and ebXML's Registry.

Compared to UDDI, CORBA Trader Service provides a rather limited functionality. UDDI is designed as a generic service registry. It can be used to register electronic as well as physical services (where the binding information could be phone, fax, or email). It supports registration of services complying with several standards including SOAP, ebXML, CORBA, RMI, DCOM, FTP, and HTTP. A CORBA Trader Service in contrast is meant to be used to register and find a service compliant with the CORBA architecture.

13.3.3 Windows Registry and Windows Active Directory

Microsoft's DCOM and COM+ have been quite a success — as is evident by the number of solutions based on these technologies and the fact that they are now embedded in all Microsoft operating systems (OSs). But interestingly, Microsoft has never provided an easy-to-use network-accessible registry for advertising and finding DCOM/COM+ objects. In fact, until the release of Active Directory, the only registry that was provided for storing location information for DCOM objects was the local Windows Registry. This meant that if you had a number of client machines that wanted to have access to DCOM objects running on a server, each and every one of their Windows Registries would have to be configured with the location and interface information for the DCOM objects.

With the release of Active Directory, it can be used as a registry to store references to COM+ objects. Although this is a very simple technology with no more power than the CORBA Naming Service, it does provide for a manageable solution for advertising and discovering COM+ objects.

13.3.4 RMI Naming Service

The RMI Naming Service is simply an RMI-specific implementation of a registry that works just like the CORBA Naming Service. The only real difference is that you can store only RMI objects in the RMI Naming Service.

13.3.5 JINI Lookup Service

The JINI Lookup Service is like an RMI-specific implementation of the CORBA Trader Service. It is very similar to the CORBA Trader Service in that RMI objects are advertised into the JINI Lookup Service — and their advertisements have associated with them the Java interface of the object providing the service, as well as optional properties further defining the service being offered.

A major difference between the JINI Lookup Service and the CORBA Trader Service is that the JINI service uses IP multicasts and a special Join protocol and Discovery protocol for advertisement and lookup of services. Also, the client-side proxies for accessing services can be stored along with service advertisements published to the JINI Lookup Service. Of course, the same thing could not be done with the CORBA Trader Service because CORBA does not allow for streaming of objects over the network.

13.3.6 ebXML Registry Services Specification

The Electronic Business eXtended Markup Language (ebXML) initiative focuses on developing standards for the global electronic markets wherein interactions happen through open, secure, and public XML-based infrastructures. The primary objective is to lower the barrier of entry to electronic business for small- and medium-sized enterprises. OASIS and the United Nations Centre Initiative for Trade Facilitation and Electronic Business (UN/CEFACT) jointly sponsor ebXML. The initiative includes several components:

  • ebXML Collaboration Protocol Profile and Agreement (CPPA)

  • ebXML Implementation, Interoperability, and Conformance

  • ebXML Messaging Services

  • ebXML Registry

The ebXML registry component is often compared with the UDDI registry. With similar sounding goals, there is a lot of debate regarding the capabilities provided by ebXML registry and UDDI and whether they are competing or complimentary standards. Since the two standards are still under development and not fully mature, it is difficult to predict which standard will prevail.

Note

A likely outcome is that the two standards will ultimately find a specific niche and not only coexist but through XML will also interoperate.

The following discussion is focused on the relative strengths and weaknesses of both these standards. Note that as newer versions of these specifications appear, some of the weaknesses may be adequately addressed. Note that this comparison is based on the UDDI Version 2.0 specification.

The vision behind the ebXML initiative goes far beyond what is envisioned by UDDI. UDDI solves the problem of providing the ability to store and retrieve pointers to services by specifying attributes — in the form of name/value pairs — of the services stored.

Like UDDI, it provides mechanisms for storing pointers to ebXML-compliant services. And it also allows association of properties with those pointers and retrieval of pointers to services by specifying properties of those services. But ebXML's registry goes further. Its registry pays equal — if not more — attention to the many forms of metadata that describe Web services. In essence, ebXML is geared to store any kind of content, not just pointers. In fact, to store a pointer to a Web service within the ebXML registry, you first must have stored the following:

  • Metadata descriptions of any of the messages that can be exchanged with that Web service.

  • A metadata description of the business process that is implemented by that Web service.

  • The service provider's CPP, which describes the service provider's role in offering its service, as well as the technical details for how to access that service. When a CPP is stored within the ebXML registry, it is possible to associate a number of properties with it in order to classify it. This provides a mechanism whereby clients looking for a specific class of CPPs can query for and find the CPPs that meet their requirements.

When clients want to access Web services whose pointers are stored within the ebXML Registry, they begin by searching for those Web services whose CPPs promise to deliver the service they desire. Then clients use the CPP information to establish a connection with the Web service provider. Dynamically, the client and the service provider form a CPA which describes all the steps — and technical endpoints — that comprise the complete business transaction they will carry out.

The ebXML registry has a much richer set of lifecycle management APIs than those provided by UDDI. ebXML's Registry provides an extensible information model through the concept of slots. Slots are extra pockets of data that can be inserted into registry entries in order to store more information. ebXML Registry clients can use the Add Slot and Remove Slot APIs to perform schema modifications and add/remove data stored in slots.

Another feature that is unique to the ebXML Registry is rich support for categories and subcategories and sub-subcategories, etc. Categories are extremely useful properties to associate with Web services — they allow clients to "drill into" and "drill up from" areas of interest so that they can easily retrieve the service(s) they are interested in.

The querying and result-filtering features provided by the ebXML Registry are far richer than those provided by UDDI. Of course, this is necessary because there are so many different attributes that can be associated with ebXML services, such as categories, slots, business documents, business processes, and CPPs. Queries and result filters can be specified by using the ebXML data structures described in the ebXML Registry Information Model document. The ebXML Registry Services Specification also states that compliant registries can offer an interface whereby clients can query the registry using Structured Query Language (SQL) syntax.

Just like with the UDDI registry, the ebXML Registry offers its services through XML messages that are exchanged between clients and the registry. In the case of ebXML, those messages are compliant with the ebXML Message Service Specification. It is expected that clients will use object-oriented APIs to access the ebXML registry so that they are not exposed to the low-level XML messages and ebXML message envelopes that will be exchanged between clients and the registry. Currently, there is a Java Specification Request — JSR 93 — which specifies a Java API that will allow Java programs to communicate with both UDDI and ebXML registries in a consistent manner.

In terms of adoption by the software industry, both standards are in their infancy. UDDI enjoys strong participation from Microsoft, which given its role in the overall Web service space can help in wider adoption. For example, the .NET server plans to provide a built-in UDDI registry.

One area generating much interest is that of registry topologies. In an enterprise environment, where high availability and complex business relationships is norm, different ways to connect multiple registries together that exchange information are essential. Some of these topologies are discussed in Chapter 10. Version 3 of both these specifications allows for designing multiple topologies.

In the next chapter, we survey the UDDI Version 3 Specification and illustrate how the specification has evolved to provider greater sophistication in the UDDI technology.


Chapter 14. Version 3 and Beyond

  • Registry Interaction

  • API Enhancements

  • Enhancements to Discovery

  • Enhancements to Description

  • Internationalization

  • Security

  • Policy

  • OASIS

If we look at the early literature around Web services, we find that early thought leaders painted the picture of a global set of Web services that could be incorporated into a business solution upon dynamic discovery. Pragmatically, Web services are likely to be deployed in controlled environments with restricted and monitored usage. By the same token, they are initially likely to be consumed subsequent to a business relationship as opposed to a simple dynamic interaction, as originally thought.

Given this trend, the need for an extensive, global registry deployment such as the Universal Business Registry (UBR) takes a backseat to smaller, restricted registry deployments that talk to one another. This trend around Web services is reflected in the evolution of the UDDI Specification from Version 1 to Version 3. A major theme among the enhancements is that of the interaction and relationship among registries, especially private registries. Other enhancements include sophistication of the APIs, support of increased security, introduction of operating policies, and internationalization.

At the time of writing this book, the UDDI Version 3 Specification was just released to the public (July 2002) and none of the UDDI-compliant software packages or UBR deployments available was UDDI V3 compatible. In this chapter, we explain the highlights of the UDDI Version 3 Specification and explore the future beyond V3. For detailed specifics of these new features, please refer to the full UDDI Version 3 Specification.

Note

It is expected that applications written based on UDDI Version 2 Specification will continue to function when UDDI Version 3 Specification-based registries and software packages are available. These older applications will, however, not make use of some of the sophistication provided by the Version 3 specification.


14.1 Registry Interaction

Registry interaction is greatly enhanced in this latest version of the UDDI specification. An emphasis is placed on how a group of registries deployed in a disparate fashion with or without the protection of a firewall can relate to each other and interact with each other.

Earlier versions of the specification supported a single-replicated registry cloud that acted virtually as one monolithic registry (through replication), as seen in Figure 14.1.

Figure 14.1. Monolithic registry cloud.

This version of the UDDI specification supports a much more complex and rich set of relationships among registries. The usage models discussed in Chapter 10 can now be supported inherently with the new specification.

Some of the key enhancements to support these various registry relationships are as follows:

  • Registry root

  • Registry networks

  • Entity promotion

  • Namespace-Based Unique Identifier Keys

14.1.1 UBR as Root

In order to make some of the complex registry relationships possible, the UDDI project has established the concept of a root registry. Similar to the DNS architecture, the UDDI specification now supports a network of registries in which a root registry and node registries are defined off the root.

By acknowledging the UBR as a root, an affiliate registry can inherit corresponding inter-registry communication policies and procedures with both the UBR and any other registry that is an affiliate of the UBR. Note that this requires the UBR to be Version 3 compliant. The current UBR complies with Version 2. Designating a root registry also allows ensuring that the keys generated are unique.

14.1.2 Support for Registry Networks

The Version 3 specification envisions the UDDI nodes to be connected to each other forming a network of registries that exchange entity information. Having this networked architecture of registries allows for a registry domain to be created and information to be shared. Figure 14.2 depicts a network of registries.

Figure 14.2. Network of UDDI registries.

The concept of a network of registries will be important in distributed environments in which various registries play different roles and are not simply replicas of one another.

14.1.3 Entity Promotion

Each resource in a UDDI registry is assigned a unique identifier key (ID). This unique ID could not be moved, shared, or replicated among registries. Therefore, when copying a resource from one UDDI to another UDDI registry results in a new ID key on the receiving registry. However, the ID provides direct access to the resource and it is not always desirable for the ID to change simply because the housing registry changes. The new version of the specification allows for the ID to be preserved when information moves from one registry to another. Version 3 of UDDI approaches the issue of key generation in a significantly different fashion and, as such, the possibility of publishing an entity to another UDDI registry while preserving the key is allowed. This is achieved through a new concept referred to as entity promotion. Entity promotion allows a publisher to suggest a resource key. However, the decision to accept the suggested key is left to the receiving registry. Should approval be granted, the suggested key is provided to the receiving registry and a new key is not generated. Figure 14.3 depicts this sequence.

Figure 14.3. Entity promotion.

The ability to share the unique identifier keys is an important capability, especially for private registry networks. For example, if a subset of services is cached into a specialized child registry from a parent registry, the unique identifier keys of the published resources can be preserved, thus allowing for consistency among the hierarchy of registries in the registry network.

Another example is that preserving the keys allows a highly available registry environment to be created. Thus, an exact copy can be made of the primary registry such that if the primary registry is unavailable, the secondary registry can come online as an exact replica.

Note

Simply suggesting a resource unique identifier key for a resource to be published is not enough for entity promotion to occur. The receiving entity must also agree to the suggested unique identifier key. Through this handshake, the security of the system is preserved.

14.1.4 Namespace-Based Unique Identifier Keys

The ability to make the UDDI specification more suitable for distributed and federated registries required an enhancement to the actual unique identifier keys returned upon successful publishing with a registry. Earlier versions of the specification required that keys had to be a formatted Universally Unique Identifier (UUID). In the new version of the specification, namespace-keys are not only supported, but recommended. This allows publishers to establish a family of keys based on a particular namespace. For example, valid Version 3 keys might look as follows:

uddi:hp.com:1
uddi:hp.com:sales-division:53

These keys are not only much more intuitive for people; they are also logically grouped. Registry platforms vendors (discussed in Chapter 13) are likely to provide additional tools to manage the many keys generated by a network of registries.


14.2 API Enhancements

Given the new registry interactions possible with V3, the UDDI interactions possible via the APIs are also enhanced. Two key API enhancements are the Subscription API and the Custody and Ownership Transfer API.

14.2.1 Subscription APIs

The Subscription API set is a new API that supports notifications. An interested entity can subscribe to be notified on changes made either to published resource or to registries.

The notifications can be retrieved either synchronously or asynchronously. In synchronous notification, the subscriber invokes get_subscriptionResults to retrieve information on the activity based on the criteria. In the asynchronous mode, the subscriber must register a listener with the registry. Any time information regarding any resource, for which the subscriber has shown interest, changes, the registry invokes this listener to notify the subscriber of those changes.

Notification allows registry and resources to be tracked. A service consumer can be notified if a new business or service is registered that might be of interest. Registry operators can track information freshness and ensure that publishers are providing fresh information to the registry. Essentially, this new API provides a mechanism for entities that interact with the registry to know when something of interest has changed with resources or registries without having to explicitly inquire.

14.2.2 Custody and Ownership Transfer API

The ability to share information among registries warrants another new API. This new API provides custody and ownership transfer capabilities. Through these APIs, a publishing entity may transfer the custody and the ownership of a resource to another node in the registry network.

This feature would be critical when resources from multiple publishers need to be aggregated under a single publisher-registry network. Of course, the flip side is when entities are split and resources need to be reassigned. In that case, resources are assigned to the appropriate custodial entities. The previous two examples were related in intra-company/entity scenarios. However, publishers who provide services via an external UDDI deployment might find the UDDI registry unsatisfactory and may wish to change registries. This API makes these scenarios possible.


14.3 Enhancements to Discovery

Discovery has also been enhanced to support a richer and more sophisticated set of inquiries.

14.3.1 Nested Queries

UDDI specification Version 3 now provides support for nested queries. In Chapter 9, we discuss a multi-step approach to discovering a service to consume. Using nested queries, a service consumer application can reduce the number of separate interactions required to narrow in on a certain resource. For example, a nested query that queries for tModels within queries for services can be much more efficient then a set of disparate queries.

14.3.2 Extensible Search Qualifiers and Sort Orders

Search qualifiers are discussed in more detail in Chapter 9. UDDI has created a new set of find qualifiers in the V3 specification. The V3 specification also supports additional sort orders. An important new qualifier is the signaturePresent qualifier. This qualifier restricts results to those that are secured via digital signatures. The signatures can be subsequently retrieved via supported APIs — however, they must be verified locally by the service consumer application.

Recall that private registries can create and model specialized and focused find qualifiers and sort orders to suit the needs of the ecosystem the private registry participates in.

14.3.3 Extended Wildcard Support

The default behavior for inquiries made to the UDDI registry is to return an exact match. Wildcard behaviors can be introduced for resource attributes like name, keyName, and so on. Any of these string attributes may be queried using wildcards to return approximate matches.

The types of wildcards are as follows:

  • Find using starts with

  • Find using starts and ends with

  • Find using escaped literals

  • Find using wildcards with taxonomies

The extended wildcard support allows service consumer applications to be designed to more appropriately search for published resources. This is especially important when the specifics of how to locate a set of resources is not well-known.

14.3.4 Management of Large Results Sets

The ability to handle a large set of query results is now included in the new specification. This is achieved through the use of an element called listDescription. The listDescription element will allow a service consumer application to more efficiently manage the results returned. It will be possible to get a current count of matching results returned and use an index marker to keep approximate position within the list.


14.4 Enhancements to Description

In Chapter 8, we discuss the process of publishing your business for registry interaction. Describing a business entity and its resources is a critical outcome of the modeling process. The description communicates to the service consumer in search of a suitable service. Version 3 provides enhancements to description capabilities available to service publishers.

14.4.1 Support for Complex Categorization

Complex categories are a result of the need to further refine how resources are described in the UDDI registry. Sufficient support for simple categories was provided in the first two versions of the specification; however, more complicated categorizing is introduced in Version 3. Most notably is the support for the grouping of categories and deriving categories.

Grouping Categories

Recognizing that simple categories were not sufficient for describing complex entities and offerings, Version 3 of the UDDI specification provides the ability to group simple categories together when describing UDDI resources. The UDDI specification presents a very appropriate example to highlight the value of this feature. If a UDDI resource needs to describe its physical location, it may do so by grouping its longitude and latitude information. These simple category attributes are grouped together using the keyedReferenceGroup construct. Mobile Web services are likely to find this feature useful in searching for services that are geographically close to the current position on the mobile user.

Note

Should a UDDI resource describe itself using a grouped category attribute, the grouped category reference must be published to the registry as a tModel.

Derived Categories

Category schemes that are published within a registry may now be extended such that new category schemes inherit the parent category values. Through this capability, category values from multiple sources can be reused in a different context. To illustrate the use of derived categories, we can look at a registry deployment powering a car sales ecosystem. The UDDI registry in this ecosystem may contain several categories, including the following:

  • Geodesic location (a combined category)

  • NAICS business entity classification

  • Car types

A derived category combining the above could be created to describe car sales entities within the registry. Figure 14.4 illustrates the concept of derived categories.

Figure 14.4. Creating derived categories.

With both the ability to group and derive categories, Version 3 of the UDDI specification provides a more fine-tuned approach at classifying a resource. This is critical to accurately describing a service; however, it is also easy to create overly complex categorization structures that prevent the service consumer application from discovering the UDDI resource. It is critical that the target service consumers are aware of the structures put in place to foster discovery.

14.4.2 Multiple Overview Documents

Another enhancement possible to the description of a UDDI resource is the ability to provide multiple overview documents for tModels and binding templates. This feature allows a service publisher to provide technical details for the UDDI resources for various formats and types.

14.4.3 Access Point

The access point represents the network address of the resource under consideration. For a UDDI registered service, the access point is the URL of the service. This attribute supports a useType attribute in its description. This will allow service publishers to define multiple service entry point formats. A new set of predefined values for this attribute is as follows:

  • endPoint: points to an actual service entry point

  • bindingTemplate: points to another binding template

  • hostingRedirector: points to another registry

  • wsdlDeployment: points to a remotely hosted WSDL document

Service consumers now have the ability to interact and integrate with the access points more efficiently since they now have knowledge as to the type of the access point provided by the resource. For example, the access point of a business entity may point to another binding template for a child service. Another example is that the access point of a service may point directly to the SOAP-based URL or simply to the WSDL description file for the service. Consuming applications need to then integrate differently based on the access point provided.

This new feature also simplifies the ability to redirect a service consumer to another location. For example, if a service is moving registries (via the custody and ownership transfer process), it might be useful to put a redirection pointer in the earlier registry for some time. This is analogous to the concept of mail forwarding at the post office. Figure 14.5 summarizes access point enhancements.

Figure 14.5. Access type values.

14.4.4 Binding Templates

Binding templates may now be categorized using category bags. Recall that the binding template provides the technical details of a UDDI resource and that category bags allow for resources to be categorized in their own system. This new ability provides a powerful means to describe, categorize, and search the technical specifics of a resource. Since the technical details of the service, like the access point, are described here, this would be a suitable place for categorizing based on technical specifics. One example would be categorizing based on stage in lifecycle; i.e., binding templates could be categorized as Test, Production, or Obsolete to name a few.

14.4.5 Operational Information

Resources that are published to the UDDI registry contain important description information. However, there is some metadata associated with that resource information that can be very useful and has been abstracted out into an independent structure — operationalInfo. This metadata structure describes various attributes of core UDDI resources including the following:

  • Created date/time

  • Modified date/time

  • Modified including children

  • UDDI node where publication took place

  • Identity of the publisher

This separation was created for security enhancements (discussed in Section 14.6) surrounding digital signatures. The operationalInfo structure is linked to the resource being defined using the unique identifier key of that particular resource. Interesting to note is the manner in which the identifier of the publisher is presented. It is very dependent on the policies set forth by the registry operator. There could be data sensitivity issues that protect such information and hence registry operators need to determine how such sensitive information should be handled.


14.5 Internationalization

As stated in its name, universal access is a key goal of the UDDI specification. Providing universal access includes support of multiple languages and international data formats. The Version 3 Specification now provides sophisticated support for several important internationalization features.

14.5.1 Multi-lingual Support

Multi-lingual support is provided for several descriptive attributes of UDDI resources. The xml:lang attribute is used predominantly to facilitate the use of multiple languages. There are several supported scenarios that can be constructed using the xml:lang attribute. It may be used to specify the language of the content of an element. For example, if the name of an entity is in Japanese, the lang attribute would be configured to state that. Another usage that is possible is for denoting transliteration. Should service details primary in Japanese also have a romanized name as well, the lang attribute can be used. Finally, a third scenario possible is simply to denote information in a variety of languages. In a global enterprise, this will be an extremely useful feature. It would provide service publishers the ability to cater toward all regions without having to publish the same service in multiple languages. If we take the employee portal example, we see how it would be useful to register the 401(k) Information Service once with multiple entries for relevant language-specific details such as name, address, and so on. It is important to note that the basic UDDI architecture can produce and consume characters from language families other than American Standard Code for Information Interchange (ASCII). However, the final implementation is left to UDDI vendors and hence there may be differences in products available from different vendors.

Two other important internationalization features supported are listed below:

  • Language specific sorting order qualifiers; it is possible to sort query results by Japanese sorting standards, for example.

  • Internationalized addresses; it is possible to modify the address element to be suitable for other address formats.

UDDI is focused on providing a specification for a set of registries that interoperate in an open and standard fashion. Even though the vision of a grand global UDDI registry has taken a backseat to the concept of many internal and external registries with complex relationships among them, internationalization still plays an important role within the architecture. Many companies are either themselves global or affiliated with global entities and hence it is critical to support these global entities with a platform that understands the languages in various regions. The Version 3 specification provides a rich set of features to support the global market companies to play in.


14.6 Security

Security-related features are highlights of the UDDI Version 3 specification. These features build on the basic security principles laid out in earlier versions — i.e., ease of use, data integrity, and access based on authentication and authorization policies. In this version, the specification formalizes the security policies and processes in the form of a tModel.

Name: uddi-org:security v3

Description: UDDI Security API Version 3

UDDI Key (V3): uddi:uddi.org:v3 security

Derived V1,V2 format key: uuid:5f7e1d45-3c2e-3e6f-9b9c-737a20022a4f

Categorization: specification, xmlSpec, soapSpec, wsdlSpec

Recall that the main security constructs provided in the sample applications provided with this book was the use of a username and password over secured-HTTP for publish interaction with a UDDI registry. The Version 3 specification introduces use of digital signatures for the purpose of enhanced security, including authentication and authorization.

14.6.1 Support for Digital Signature

Using XML digital signatures, it is possible to ascertain validity and accuracy of exchanged XML documents. Inquirers of a registry can filter their queries, requesting only data that has, in fact, been signed. The inquirer can be confident that the data obtained this way is exactly as the publisher intended it. This feature helps in building trust between inquirers and publishers of data on a registry.

The publishers also have the assurance that they are not being misrepresented by someone claiming to own a UDDI entity. Once publishers have signed data, using digital signatures, they can have confidence in the integrity of that data.

The specification stipulates that this assurance be transitive, meaning that the information can be copied from one registry to another without losing data integrity.

The publishers of any UDDI-registered resource can digitally sign the information. Thus, APIs such as save_business, save_tModel would include the signature. This signature is included in the dsig:Signature tag in the corresponding XML document. This signature is part of the get_xxDetails calls. When an inquirer uses these APIs, the signature can be validated. The operations such as XML digital signature generation and validation would be most likely implemented with the UDDI APIs such as UDDI4J and Microsoft UDDI .NET SDK.

Ultimately, digital signatures improve the data quality within UDDI and allow both the protection and non-repudiation required for e-commerce and other Web services scenarios that call for a high degree of trust.

14.6.2 Mutual Authentication

In addition to the transaction-level security, the Version 3 specification also recommends additional security mechanisms and processes for certain operations. For example, for replication and custody-transfer, where two parties are involved in the exchange of sensitive data, the specification recommends mutual authentication through X.509v3 certificates. The certificates used for this purpose are part of the operator data structure. Using the mutual authentication mechanism, it is possible to ascertain the privacy of the data being exchanged. Table 14.1 depicts the security mechanisms recommended for various APIS sets.

Table 14.1. Recommended Security Mechanisms for UDDI APIs

API

Transport

Security Mechanism

Authentication

Inquiry

HTTP

Publication

HTTP

SSL V3

Security

HTTP

SSL V3

Custody Transfer

HTTP

SSL V3

Mutual Authentication

Replication

HTTP

SSL V3

Mutual Authentication

Subscription

HTTP

SSL V3

Value Set

HTTP

It must be noted that the security model for a registry and node can be extended beyond the mechanisms described in this specification. In such a case, appropriate policy documentation and validation services should be provided by the operator. Also, the security policies and guidelines described in the specification are applicable to a UDDI registry itself. The services listed on a specific registry or node must implement its own security structure. The binding templates associated with the service should describe the security policies used by the concerned service, so that the user discovering the service on the registry can check if those policies are in line with its own policies around security.


14.7 Policy

As discussed in Chapter 10, the UDDI specification assumes that the registry operates in several environments — Internet, intranet, and extranet. In some of these environments, two or more registries are involved in exchanging information about resources registered on one or more registries. In order to ensure data integrity across all instances of data representing a certain entity, it is necessary that the concerned registries follow a consistent set of operational processes and behaviors. The Version 3 specification describes the recommended processes and behaviors as Policies.

The policy hierarchy creates the entire of set of policies for a registry instance. This hierarchy describes the policies that are mandated by the specification and the ones that are within the domain of the registry operator. There are also several decision points, where an operator can have multiple choices for a certain policy.

The Policy Decision Points (PDPs) provide information about a Policy Rule. The PDPs can also define Policy Enforcement Point (PEPs) — entities that are responsible for enforcing a certain policy. The policies can be delegated within a registry structure. Figure 14.6 depicts the organization of policies. This organization of policies is expressed through the Policy Schema.

Figure 14.6. UDDI Policies.

Examples of policy decision points are authorization models, data custody and confidentiality, key generation, validation, subscription, and audit policy. Using the policy guide for these as well as other such policy decision points provided in the specification, it is possible to mold a registry instance to meet the needs specific to its environment.


14.8 OASIS

As we discuss in Chapter 5, the UDDI.org project is managed independently by the UDDI Working Group members. In July of 2002, the UDDI Working Group transitioned the specification enhancement to the Organization for the Advancement of Structured Information Standards (OASIS).

14.8.1 OASIS Charter

OASIS is a not-for-profit, global consortium that defines and evangelizes electronic business standards. The member companies use a lightweight and open process to obtain requirements and promote industry consensus on specific technical problems.

With its more than 400 corporate and individual members in 100 countries around the world, OASIS is one of the strongest XML supporters and promoters. It not only hosts and manages XML.org, but also hosts XML Coverpages (an online reference collection for interoperable markup languages). This places OASIS in an ideal position to carry forth an XML-based business registry such as UDDI. OASIS also (along with the United Nations) sponsors ebXML — another XML standard for business. The ebXML and its associated registry technology are discussed in Chapter 13.

14.8.2 OASIS and UDDI

It was always intended that the UDDI specification would transition to the custody of an industry consortium, like OASIS. The specification will continue to advance as a standard with industry participation and involvement. It will be possible for registry vendors and other interested parties to use future versions of the specification to build product and solution plans.

OASIS brings the intense focus on global interoperability to the UDDI project and will ensure that it continues to evolve in a manner that fosters interoperability.

At the time of writing, there were not publicly available plans on how OASIS intended to begin its work on enhancing from the Version 3 specification.


Part V: Appendixes

In this Part

Appendix A: Client UDDI APIs

Appendix B: Installing UDDI4J

Appendix C: UDDI Errors

Appendix D: UDDI .NET SDK

Appendix E: Setting Up DSN

Appendix F: Database Wrapper Utility

Appendix G: Simple Object Access Protocol

Appendix H: WSDL


Appendix A. Client UDDI APIs

    Section A.1. Publishing APIs

    Section A.2. Inquiry APIs

    Section A.3. Security APIs


A.1 Publishing APIs

add_publisherAssertions: Used to add relationship assertions to the existing set of assertions.

delete_binding: Used to remove an existing bindingTemplate from the bindingTemplates collection that is part of a specified businessService structure.

delete_business: Used to delete registered businessEntity information from the registry.

delete_publisherAssertions: Used to delete specific publisher assertions from the assertion collection controlled by a particular publisher. Deleting assertions from the assertion collection affects the visibility of business relationships. Deleting an assertion causes any relationships based on that assertion to be invalidated.

delete_service: Used to delete an existing businessService from the businessServices collection that is part of a specified businessEntity.

delete_tModel: Used to hide registered information about a tModel. Any tModel hidden in this way is still usable for reference purposes and accessible via the get_tModelDetail API, but is hidden from find_tModel result sets. There is no specified way to cause a tModel to be deleted.

get_assertionStatusReport: Used to get a status report containing publisher assertions and status information. This report is useful to help an administrator manage publisher assertions. Publisher assertions are used in UDDI to manage pub-licly visible relationships between businessEntity structures. Relationships help manage complex business structures that require more than one businessEntity or more than one publisher to manage. Returns an assertionStatusReport that includes the status of all assertions made involving any businessEntity controlled by the requesting publisher.

get_publisherAssertions: Used to get a list of publisher assertions that are controlled by an individual publisher. Returns a publisherAssertions structure containing all publisher assertions associated with a specific publisher. Publisher assertions are used to control publicly visible business relationships.

get_registeredInfo: Used to request an abbreviated synopsis of all information currently managed by a given publisher.

save_binding: Used to register new bindingTemplate information or to update existing bindingTemplate information. Use this to control information about technical capabilities exposed by a registered business.

save_business: Used to register new businessEntity information or update existing businessEntity information. Use this to control the full set of information about the entire business, including its businessService and bindingTemplate structures. Of the save xx APIs, this one has the broadest effect.

save_service: Used to register or update complete information about a businessService exposed by a specified businessEntity.

save_tModel: Used to register or update complete information about a tModel.

set_publisherAssertions: Used to save the complete set of publisher assertions for an individual publisher. Replaces any existing assertions, and causes any old assertions that are not reasserted to be removed from the registry. Publisher assertions are used to control publicly visible business relationships.


A.2 Inquiry APIs

find_binding: Used to locate specific bindings within a registered businessService. Returns a bindingDetail message.

find_business: Used to locate information about one or more businesses. Returns a businessList message.

find_relatedBusinesses: Used to locate information about businessEntity registrations that are related to a specific business entity whose key is passed in the inquiry. The Related Businesses feature is used to manage registration of business units and subsequently relate them based on organizational hierarchies or business partner relationships. Returns a relatedBusinessesList message.

find_service: Used to locate specific services within a registered businessEntity. Returns a serviceList message.

find_tModel: Used to locate one or more tModel information structures. Returns a tModelList structure.

get_bindingDetail: Used to get full bindingTemplate information suitable for making one or more service requests. Returns a bindingDetail message.

get_businessDetail: Used to get the full businessEntity information for one or more businesses or organizations. Returns a businessDetail message.

get_businessDetailExt: Used to get extended businessEntity information. Returns a businessDetailExt message.

get_serviceDetail: Used to get full details for a given set of registered businessService data. Returns a serviceDetail message.

get_tModelDetail: Used to get full details for a given set of registered tModel data. Returns a tModelDetail message.


A.3 Security APIs

discard_authToken: Used to inform a node that a previously obtained authentication token is no longer required and should be considered invalid if used after this message is received.

get_authToken: Used to request an authentication token in the form of an authInfo element from a UDDI node.


Appendix B. Installing UDDI4J

The Java examples in this book use the Application Programming Interfaces (APIs) provided by UDDI4J — an open source initiative.

The Java ARchive (JAR) file containing these APIs can be downloaded from the UDDI4J project Web site at: http://www.uddi4j.org. The examples discussed in the book use APIs from the UDDI Version 2 packaging. Refer to related documentation for more information on how to set up UDDI4J for your environment.


B.1 Apache SOAP

UDDI4J APIs need a Simple Object Access Protocol (SOAP) implementation to process incoming and outgoing SOAP messages. Several implementations such as those from Hewlett-Packard (HP) and the Apache project, are supported. To get the Apache SOAP implementation, download the file from the project Web site: http://xml.apache.org/dist/soap/.Version 2.3.1 is used in this book. After the installation, add the path to the JAR file into CLASSPATH.


B.2 Java Components

UDDI4J also uses Java utilities that are not part of the standard Java distribution. These utilities must be downloaded separately and installed before the APIs can work properly. All the utilities are available on Sun Microsystem's Web site.

B.2.1 JSSE

The package, Java Secure Socket Extension (JSSE), is needed in order to secure HyperText Transfer Protocol (HTTPS). Standard Java distribution only allows non-secure HTTP calls. However, since all the publish APIs in UDDI use HTTPS, JSSE is required. Note that in version 1.4, JSSE is part of standard Java distribution. The site http://java.sun.com/products/jsse/INSTALL.html provides installation instructions.

B.2.2 Java Mail

The package javax.mail is required for UDDI4J for its messaging needs. This package is available at http://java.sun.com/products/javamail/. After the download, add the corresponding JAR file into CLASSPATH. No specific configuration is needed on the user's part after that.

B.2.3 JavaBean Activation Framework

The JavaBean Activation Framework (JAF) provides ability to handle arbitrary data types including binary data. This is useful when handing UDDI messages. JAF is available at: http://java.sun.com/products/javabeans/glasgow/jaf.html.

Use the GettingStarted example explained in Chapter 7 to check the installation.


B.3 Configuring UDDI4J

The behavior of the UDDI4J APIs can be altered through several configuration parameters. The most commonly used parameters are described below. These parameters can be set either through the command-line or programmatically.

org.uddi4j.TransportClassName: The class name that provides entry point into a specific SOAP implementation. The version 2.0 provides support for SOAP implementations by HP and the Apache project. The corresponding entry points in the UDDI4J JAR files are as follows:

Apache SOAP: org.uddi4j.transport.ApacheSOAPTransport

Apache Axis: org.uddi4j.transport.ApacheAxisTransport

HP: org.uddi4j.transport.HPSOAPTransport

org.uddi4j.logEnabled: The switch turns logging on or off. When set to true, the exchange of messages between the APIs and the UDDI registry can be browsed. The default value is false.

http.proxyHost: This property is set when the client machine is behind a firewall. The proxy information is used when communicating with the UDDI registry. This property is used when making an HTTP connection.

http.proxyPort: The port number to be used when communicating with proxy during an HTTP connection.

https.proxyHost: This property is set when the client machine is behind a firewall. The proxy information is used when communicating with the UDDI registry. This property is used when making an HTTPS connection.

https.proxyPort: The port number to be used when communicating with proxy during an HTTPS connection.

http.proxyUserName: User name to be used for the proxy server.

http.proxyPassword: Password associated with the proxy server user name.

In addition, the following properties are used in the examples in the book. These properties can be used to alter the behavior of the examples.

inquiryURL: This parameter can be used to set the Uniform Resource Locator (URL) of the registry where the inquiry request is to be sent. Chapter 5 provides a list of URLs where UDDI registries are available publicly.

publishURL: The URL where the publish requests are to be sent.

userid: The user ID to be used during the authentication process. Authentication is required during publication.

password: The password associated with userid.


Appendix C. UDDI Errors

The UDDI specification defines several error codes that can be used to notify the user of any problems with the transactions. As the specification evolves, some of the error codes are amended or retired. The error codes defined in UDDI Version 2.0 API Specification are as follows:

E_assertionNotFound: (30000) Signifies that a particular publisher assertion (consisting of two businessKey values, and a keyed reference with three components) cannot be identified in a save or delete operation.

E_authTokenExpired: (10110) Signifies that the authentication token information has timed out.

E_authTokenRequired: (10120) Signifies that an invalid authentication token was passed to an API call that requires authentication.

E_accountLimitExceeded: (10160) Signifies that a save request exceeded the quantity limits for a given data type.

E_busy: (10400) Signifies that the request cannot be processed at the current time.

E_fatalError: (10500) Signifies that a serious technical error has occurred while processing the request.

E_invalidKeyPassed: (10210) Signifies that the uuid_key value passed did not match with any known key values. The details on the invalid key will be included in the dispositionReport element.

E_invalidProjection: (20230) Signifies that an attempt was made to save a businessEntity containing a service projection that does not match the businessService being projected. The serviceKey of at least one such businessService will be included in the dispositionReport.

E_invalidCompletionStatus: (30100) Signifies that one of the assertion status values passed is unrecognized. The completion status that caused the problem will be clearly indicated in the error text.

E_invalidValue: (20200) A value that was passed in a keyValue attribute did not pass validation. This applies to checked categorizations, identifiers, and other validated code lists. The error text will clearly indicate the key and value combination that failed validation.

E_languageError: (10060) Signifies that an error was detected while processing elements that were annotated with xml:lang qualifiers. Presently, only the description and name elements support xml:lang qualifications.

E_messageTooLarge: (30100) Signifies that the message is too large. The upper limit will be clearly indicated in the error text.

E_nameTooLong: (10020) Signifies that the partial name value passed exceeds the maximum name length designated by the policy of an implementation or Operator Site.

E_publisherCancelled: (30220) The target publisher cancelled the custody transfer operation.

E_requestDenied: (30210) A custody transfer request has been refused.

E_secretUnknown: (30230) The target publisher was unable to match the shared secret and the five (5) attempt limit was exhausted. The target operator automatically cancelled the transfer operation.

E_success: (0) Signifies that no failure occurred. This return code is used with the dispositionReport for reporting results from requests with no natural response document.

E_tooManyOptions: (10030) Signifies that too many or incompatible arguments were passed. The error text will clearly indicate the nature of the problem.

E_transferAborted: (30200) Signifies that a custody transfer request will not succeed.

E_unrecognizedVersion: (10040) Signifies that the value of the generic attribute passed is unsupported by the Operator Instance being queried.

E_unknownUser: (10150) Signifies that the user ID and password pair passed in a get_authToken message is not known to the Operator Site or is not valid.

E_unsupported: (10050) Signifies that the implementer does not support a feature or API.

E_userMismatch: (10140) Signifies that an attempt was made to use the publishing API to change data that is controlled by another party.

E_valueNotAllowed: (20210) Signifies that a value did not pass validation because of contextual issues. The value may be valid in some contexts, but not in the context used. The error text may contain information about the contextual problem.


Appendix D. UDDI .NET SDK

The .NET-based examples used in the book use the Microsoft .NET Framework. The .NET SDK Framework is installed as part of the Visual Studio .NET installation. In addition to the framework, Application Programming Interfaces (APIs) specific to UDDI must also be installed. Microsoft has released the Software Development Kit (SDK) for this called UDDI .NET SDK. At the time of writing this text, beta version of 2.0 is available at the Microsoft Developer Network (MSDN) site. This version, more specifically, Microsoft UDDI .NET SDK 2.0 Beta 1, is available at:

http://msdn.microsoft.com/downloads/default.asp?
   url=/downloads/sample.asp?
   url=/MSDN-FILES/027/001/874/msdncompositedoc.xml

The earlier versions of the SDK are not compatible with UDDI Version 2 specification. A comparison between this and the earlier version is available at:

http://msdn.microsoft.com/library/default.asp?
   url=/library/en-us/dnuddi/html/versuddisdk.asp

There is no user-specific configuration required after installation. To verify the successful installation of the APIs, run the sample example, UDDI Explorer, included as part of the installation. This program can be used to test basic search functionality as well as user configuration.


Appendix E. Setting Up DSN

A database in any system can be accessed using the driver provided for it by the vendor. This typically constitutes a vendor-specific solution to data access. Open Database Connectivity (ODBC) is a data access standard that aims at standardizing the data access mechanisms so that a programmer can write the applications without knowing the nuances of how the driver and the database from a vendor behaves. ODBC provides standard Application Programming Interfaces (APIs) and response guidelines for a database. An ODBC Data Source Name (DSN) contains metadata about a particular database. It contains information specific to the connection and location of the database, as well as the driver that manages the database. Java provides a package, Java Database Connectivity (JDBC), based on the ODBC standard. JDBC provides Java APIs based on ODBC. It uses a mechanism called the JDBC-ODBC bridge.

The Windows operating system (OS) provides a wizard to create a DSN entry based on the ODBC standard. We have used this wizard to create DSN names for the databases used in the example. Follow the steps below to create a user DSN.


E.1 Datasources

Go to Start [image] Settings [image] Control Panel and click on Data Sources (ODBC), as shown in Figure E.1. Under the User DSN tab, select the Add option to add a new DSN.

Figure E.1. ODBC Start panel.

Now select the database driver for which you want to set up a data source. For ex-ample, you will select Driver for Microsoft Access (*.mdb) for the Access database. Click on Finish to complete the task (Figure E.2).

Figure E.2. Choosing the ODBC driver.

Now you will be prompted for information related to your database. Enter a DSN of your choice (to which you can refer in your programs to connect to the database). This is depicted in Figure E.3.

Figure E.3. Attributing a DSN to a database.

Click on Select to select the database file located on your system (and *.mdb file, in this case). Locate your database file and click OK. Your DSN is ready for use. This DSN entry can be used for any application that supports ODBC. [1]

[1] DSN entries for different databases from vendors such as Oracle or Sybase can be created in a similar fashion, using their corresponding drivers.


Appendix F. Database Wrapper Utility

This book uses several examples that use a database in the business logic. This database access is provided through the Java Database-Open Database Connectivity (JDBC-ODBC) bridge. The Data Source Name (DSN) entries required for this are explained in Appendix E. The database access logic required in all these examples is similar and is packaged separately in the DatabaseWrapper class. This class is in the Shared directory.

The constructor for this class requires three parameters — the DSN name, as registered with the operating system, user name, and password. Both the user name and the password for all the databases in the book are set to null.

DatabaseWrapper.java
public DatabaseWrapper(String database, String usrName,
                                           String password)
{
   dbName = database;
   dbUserName = usrName;
   dbPassword = password;
}

The method connectToDb() has the logic to connect to the database. The method executeQuery() is a general-purpose method that interacts with the database to perform a database operation. The database operation to be performed must be specified to this method, using a Structured Query Language (SQL) statement. The result of the SQL execution is returned as a ResultSet object. The ResultSet object contains a table that contains the query results. The individual table rows can be retrieved using the next() method from the ResultSet class.

Several examples in the book use a database in the business logic. The database schemas for these databases are given below for easy reference.


F.1 Employee Contribution Database

The Employee Contribution database, with DSN name Emp401k, consists of two tables. The table EmpTable contains information about employees within a company. The schema for this table in shown in Table F.1, followed by a sample entry in Table F.2.

Table F.1. Schema for Table EmpTable

Field Name

Type

Description

EmpID

Text

Primary key

EmployeeName

Text

Employee name

Table F.2. Sample Entry for Table EmpTable

EmpID

EmployeeName

1001

Carl Cooper

The table FundTable contains information about the mutual funds that are available for investing. The Table F.3 depicts the schema for the table followed by a sample entry in Table F.4. Similarly, the table EmpContrib information about employee contribution percentages for participating employees. The fields in this table are related to employee and fund tables through foreign key relationship. Table F.5 shows the schema for this table. A sample entry is provided in Table F.6.

Table F.3. Schema for Table FundTable

Field Name

Type

Description

FundID

Text

Primary key

FundName

Text

Fund name

Table F.4. Sample Entry for Table FundTable

FundID

FundName

24675

Growth and Income Fund

Table F.5. Schema for Table EmpContrib

Field Name

Type

Description

EmpID

Text

Foreign key

FundID

Text

Foreign key

ContribPercent

Number

Contribution percentage

Table F.6. Sample Entry for Table EmpContrib

EmpID

FundID

ContribPercent

1001

24675

50


Appendix G. Simple Object Access Protocol

Simple Object Access Protocol (SOAP) is a simple and lightweight protocol for exchanging structured information between network applications in a distributed environment using extended Markup Language (XML). IBM, Microsoft, and others submitted SOAP to the World Wide Web Consortium (W3C) as the basis of XML protocol working group. SOAP is becoming popular as the chosen XML messaging protocol for several reasons:

  • Simplicity

  • Standardized enveloping mechanism that allows business documents to be transmitted using standard Internet protocols such as Hyper Text Transfer Protocol (HTTP)

  • Support for the publish, find, and bind operations in the Web services architecture

  • Programming language and platform independent

The SOAP protocol can be used in combination with other network protocols such as HTTP, Internet Inter-ORB Protocol (IIOP), and File Transfer Protocol (FTP). SOAP can be used to facilitate interobject communication across a network. In such a scenario, the objects communicate with each other, by exchanging SOAP messages. This is, in effect, a Remote Procedure Call (RPC) mechanism.


G.1 SOAP Message Components

A SOAP message consists of three parts:

  1. The SOAP envelope: defines the framework for describing what is in a message, which should deal with it and whether it is optional or mandatory.

  2. The SOAP encoding rules: define serialization mechanism to exchange instances of application-defined data types.

  3. The SOAP RPC: defines a convention for representing remote procedure calls and responses.

Under a typical scenario, based on the Web services, a service requestor or service provider should be able to build and parse a SOAP message and communicate over the network. A SOAP server running in a Web application server performs these functions for the service provider or service requestor.

The code segments below provide a sample SOAP request message and corresponding response.

Sample SOAP Request Message:

<?xml version='1.0' encoding='UTF-8'?>
<soap:Envelope
  xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
  xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
  xmlns:soapenc='http://schemas.xmlsoap.org/soap/encoding/'
  soap:encodingStyle=
    'http://schemas.xmlsoap.org/soap/encoding/'>
    <soap:Body>
      <n:getOSName
        xmlns:n='http://tempuri.org/SysteminfoService'>
        <arg0 xsi:type='xsd:string'>Hello</arg0>
        <arg1 xsi:type='xsd:string'>Shilpa</arg1>
      </n:getOSName>
  </soap:Body>
</soap:Envelope>

Sample SOAP Response Message:

<?xml version='1.0' encoding='UTF-8'?>
<soap:Envelope
  xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
  xmlns:xsd='http://www.w3.org/2001/XMLSchema'
  xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
  xmlns:soapenc='http://schemas.xmlsoap.org/soap/encoding/'
  soap:encodingStyle=
    'http://schemas.xmlsoap.org/soap/encoding/'>
  <soap:Body>
    <n:getOSNameResponse
      xmlns:n='http://tempuri.org/SysteminfoService'>
      <Result xsi:type='xsd:string'>
        Hello Shilpa the OS is: Windows 2000
      </Result>
    </n:getOSNameResponse>
  </soap:Body>
</soap:Envelope>

In these sample messages, the tag getOSNameResponse is the method name with XML namespace http://tempuri.org/SysteminfoService. A SOAP server can choose a specific XML namespace to use. Some SOAP servers also provide flexibility to the user to provide the namespace for certain tags. All the namespaces used in the SOAP message are declared in the SOAP envelope section of the message.

In the request message, the tags arg0 and arg1 represent the arguments passed to the method. These tags contain the data type of these arguments and the actual values of these arguments.

In the response message, the tag result represents the return value of the method. It contains the data type and the actual return value.

SOAP was developed by Microsoft, DevelopMentor, and Userland Software and has been proposed as a standard interface to the Internet Engineering Task Force (IETF). The SOAP specification is available at http://www.w3.org/TR/SOAP/.


G.2 Attachments to SOAP Messages

The SOAP specification allows attachments to be included in SOAP messages. These attachments can be related to either SOAP header or SOAP body. The specification provides information on how to include binary or text attachments to a SOAP message and package them all as a multipart Multi-Purpose Internet Mail Extensions (MIME) format. Using this, any additional information to a core SOAP message can be sent within the same transaction. Document Exchange Model (DEM)-based Web services can use SOAP attachments to send or receive multiple XML documents as part of a service request or corresponding response. More information on the SOAP attachments and their usage can be found at: http://www.w3.org/TR/SOAP-attachments.


Appendix H. WSDL

The need for the Web services Description Language (WSDL) specification arose from the need to standardize the Web service technology stack.

Microsoft's service description languages Service Description Language (SDL) and Service Control Language (SCL) and IBM's NASSL have been unified to form anew language called WSDL. WSDL is an eXtended Markup Language (XML) format for defining Web services and describing how to interact with them. In other words, WSDL defines the interface and the mechanics of service interaction.

As explained by W3C — "WSDL is an XML document for describing Web services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information."

A WSDL document is used to specify the location of a Web service and the interface used to interact with it. Operations in a WSDL document can be document oriented or Remote Procedure Call (RPC)-oriented. The document-oriented operation is characterized by exchange of XML documents between the client and service. Both the input and output messages, in this case, contain XML documents. In an RPC-oriented operation, on the other hand, the input message contains input parameters, and the output message contains output parameters.

The WSDL specification provides several elements and attributes to define a Web service. The elements are of two types

  • Abstract: platform- and language-independent elements, e.g., types, message, portType

  • Concrete: site-specific, machine-specific, or language-specific, e.g., binding, service

Here is a brief description of elements in a WSDL document:


H.1 <definitions>

This is root element of WSDL file that includes namespace definitions and contains other elements of the WSDL.

<definitions name ='HelloWorldService'
   xmlns='http://schemas.xmlsoap.org/wsdl/'>
    <service name='HelloWorldService' >
       ...
    </service>
</definitions>


H.2 <service>

A service element is used to collect a set of related ports. A service may be accessible on many ports: via SOAP, HTTP-GET etc.


H.3 <types>

The types element describes the different data types used to describe the messages exchange. XSD predefined types, e.g., xsd:int can be used or user defined can be used.


H.4 <message>

Specifies the XML data types that constitute various parts of a message. It is protocol-independent and may be used with SOAP, HTTP-GET or any other protocol. It is used to define the input and output parameters of an operation.


H.5 <operation>

Includes input and output messages of the operation/method forms a request-response pair corresponding to a method call.


H.6 <portType>

The methods of a Web service are described in the portType element. Identifies a set of operations and the input and output messages involved with each of those operations.


H.7 <binding>

The binding element describes concrete aspects of an operation such as the protocol, data format, security, and other attributes.


H.8 <port>

The port element defines the single communication endpoint by specifying the address for binding. It associates this address with the binding element from service interface definition. Each port has a unique name and a binding attribute and supports a different protocol.

For more information on WSDL: http://www.w3.org/TR/wsdl


Glossary

    A

    B

    C

    D

    E

    F

    G

    H

    I

    J

    K

    L

    M

    N

    O

    P

    Q

    R

    S

    T

    U

    V

    W

    X


A
Active Directory.

Microsoft's trademarked directory service, an integral part of the Windows 2000 architecture. Active Directory is a centralized and standardized system that automates network management of user data, security, and distributed resources, and enables interoperation with other directories.

Affiliation.

Registries that are grouped under similar operating policies including data indexing are considered to be affiliated.

API.

Application Programming Interface. (pl.: APIs.) An application programming interface is the exact structure described by a computer operating system or application program using which a programmer writing an consuming application can make requests of that operating system or application.

ASP.

Active Server Page. Microsoft's technology for scripted Web pages that can display dynamic content requested by a Web browser.

Asynchronous Interactions.

Not synchronized; that is, not occurring at predetermined or regular intervals. The term asynchronous interactions refers to interactions between the service and the client in which data can be transmitted intermittently, rather than in a steady stream.

See also [Synchronous Interaction]

Attributes.

A key-value pair that is used to describe the characteristics of a service.

Authentication.

A mechanism by which two or more communicating parties in a conversation can ascertain that the other entities involved are truly the same as their identities suggest.

Authorization.

Provides an increased level of security by controlling access to privileged information.


B
B2B.

Business-to-Business. An electronic, shared infrastructure that provides businesses a platform to interact in real time with buyers, partners, distribution channels, and suppliers. Also can be called a business-to-business exchange.

B2C.

Business-to-Customer. An electronic, shared infrastructure that provides businesses a platform to interact in real time with consumers.

Best Practice.

A document accompanying a UDDI specification that provides guidance on how to use UDDI registries. Best Practices not only represent the UDDI Working Group's view on some UDDI-related topic but also represent well-established practice.

BizTalk.

An open framework for B2B (or business-to-business exchange), which is being implemented across all major platforms and most major B2B products from other companies. In addition to being a leading B2B platform, BizTalk is also a new and impressive improvement over previous programming models and presents cost savings when used in internal IT projects.

BPSS.

Business Process Specification Schema. The ebXML BPSS provides a standard framework for business process specification.

Business Entity.

Entities that typically describe the organization responsible for UDDI registrations. For example, the "businesses" in a private registry may be internal organizations.

Business Logic.

Functionality provided by the service — usually focused on a specific task such as a pricing service or a sales tax service. This is the logic that is exposed by the service deployment.


C
Categorize.

To identify an entity with a category by placing an appropriate keyed reference or keyed reference group in the category bag of the entity. All entities categorized with the same value in the same category system are said to belong to the category named. E.g., in the North American Industry Classification System (NAICS) category system.

Category.

A value from a specified category system used to group various UDDI elements together in an organized manner.

See also [Categorize]

Certificate.

A data structure assigning a tag or name to a subject. Certificates are signed using cryptographic techniques so that they cannot be tampered with.

Checked.

A value set whose use is subject to validation before an entity that refers to it is published. Checked value sets may be internally hosted or externally hosted.

See also [Unchecked]

Choreography.

A Web service concept that addresses business process integration between business partners.

Client.

Any active entity (e.g., a process, thread, service provider) that interacts with a UDDI registry to discover a UDDI resource.

Client-Side Proxy.

Client-side proxy classes are responsible for exchanging messages with a Web service instance.

CLR.

Common Language Runtime. Microsoft's new operating system infrastructure that allows software applications and components written in different languages to intercommunicate. It resembles Sun's JVM (Java Virtual Machine).

COM.

Component Object Model. It enables programmers to develop objects that can be accessed by any COM-compliant application.

Composition.
See [Service Composition]
Consortium.

A group of entities that assemble together in support of a common cause or undertaking. For example, the WAP Forum is a 200-member consortium formed to guide WAP's future. In an ecosystem, consortiums or governing bodies usually define the framework in which ecosystem members will transact.

Co-opetition.

Business environment in which different entities are competing and cooperating at the same time with each other.

CORBA.

Common Object Request Broker Architecture. An architecture and specification for creating, distributing, and managing distributed program objects in a network. It allows programs at different locations and developed by different vendors to communicate in a network through an "interface broker."

CORBA Naming Service.

A standard service for CORBA applications, defined in the Object Management Group's (OMG's) CORBA services specification that allows you to associate abstract names with CORBA objects and allows clients to find those objects by looking up the corresponding names.

CORBA Trader Service.

A CORBA service that allows CORBA objects to advertise themselves with a set of associated properties. Conceptually, this is similar to an e-Speak advertising service.

CPP.

Collaboration Protocol Profile. Describes a service provider's role in offering its service, as well as the technical details for how to access that service. A CPP stored within the ebXML Registry provides a mechanism whereby clients looking for a specific class of CPPs can query for and find the CPPs that meet their requirements.

Custody.

Each entity in UDDI is said to be in the custody of the node at which it was published. That node is said to be the custodial node for the entity. Through Version 2 of the specification, any changes made to an entity had to be done through the custodial node.


D
DCOM.

Distributed Component Object Model. An extension of COM to support objects distributed across a network.

Decryption.

The process of decoding data that has been encrypted into a secret format. Decryption requires a secret key or password.

Delegation of Authority.

The process of transferring certain responsibilities to request or perform a task.

DEM.

Document Exchange Model. Interentity interaction mechanism that uses exchange of structured documents for communication.

Description.

A formal approach to express capabilities of a service using an attribute set that is based on standard specifications.

Digital signature.

An electronic signature that can be used to authenticate the identity of the sender of a message or the signer of a document. Digital signatures can also be used to ensure that the original content of the message or document is unchanged.

DMZ.

Demilitarized Zone. The public part of the Internet.

DOM.

Document Object Model. A platform- and language-neutral interface that will allow programs and scripts to access and update the content, structure, and style of documents dynamically.


E
EAI.

Enterprise Application Integration. A business computing term for the plans, methods, and tools aimed at modernizing, consolidating, and coordinating the computer applications in an enterprise.

ebXML.

Electronic Business eXtended Markup Language. A project to use the eXtensible Markup Language (XML) to standardize the secure exchange of business data. Among other purposes, ebXML would encompass and perhaps replace a familiar standard called Electronic Data Interchange (EDI). ebXML is designed to enable a global electronic marketplace in which enterprises of any size, and in any location, could safely and securely transact business through the exchange of XML-based messages.

Ecosystem.

A collection of related services. This collection, as a whole, provides a set of services in a specific domain.

Ecosystem Arbitrator.

The mediator to resolve various issues/disputes (noncompliance with guidelines, unsatisfactory quality of service, breach of contract or fraud) between the ecosystem members.

Ecosystem Framework.

A set of rules and guidelines that govern the participation and operational procedures in an ecosystem. Ecosystem members are generally expected to abide by the ecosystem framework. The ecosystem governing body and arbitrator use the framework to resolve disputes or enforce certain behavior among members.

Ecosystem Governing Body.
See [Governing Body]
Ecosystem Host.

Host that facilitates the general functioning of an ecosystem and is responsible for providing the necessary infrastructure for an ecosystem to function.

Ecosystem Member Services.

The ecosystem member entities are the very reason why an ecosystem exists. The ecosystem member services form the second tier of the ecosystem — the member class services. The entities in this category use the ecosystem infrastructure to function.

Ecosystem Monitor.

An entity that monitors the interactions between ecosystem members and ensures that the members of the ecosystem are following the interactions guidelines set by the ecosystem host and the governing body.

EJB.

Enterprise Java Beans. A Java-based specification for creating component-based transaction services.

See also [MTS]

Exporter.

The behavior of an inquirer associated with a given registry that publishes copied (and, perhaps, modified) data into some other registry.

Encryption.

The translation of data into a secret code.

ERP.

Enterprise Resource Planning. An industry term that encompasses a wider set of activities (facilitated through ERP software and applications) that a business employs for its efficient functioning. These activities include product planning, purchasing, inventory management, and order processing.


F
Find qualifier.

Modifiers that affect the results of an inquiry. These affect the default ANDed behavior. An example is the caseSensitiveMatch find qualifier which will return results whose case matches exactly. See also search qualifiers.

FTP.

File Transfer Protocol. FTP is an application protocol that uses the Internet's TCP/IP protocols. FTP is commonly used to transfer files from one computer to another computer.


G
Governing Body.

A service ecosystem entity that sets the policies in the ecosystem. These policies provide the framework for transactions in the ecosystem.


H
Higher Level Services.

Higher level services are a composition of several lower level services.

See also [Lower Level Services]

Hosting redirector.

An instance of a UDDI-registered Web service whose service type is a redirector which provides access (and other binding information) information through redirection to the binding template of another UDDI-registered Web service.

HTTP.

Hypertext Transfer Protocol. A protocol for exchanging files (text, graphic images, sound, video, and other multimedia files) on the World Wide Web (WWW).

HTTPS.

Secure Hypertext Transfer Protocol. A protocol that encrypts and decrypts user page requests, as well as the pages that are returned by the Web server.


I
Identifier.

Any value set that is used to uniquely identify the entities in which it is referenced. An identifier system is distinct from a category system in that only one entity in a given registry should be associated with a given identifier.

IDL.

Interface Definition Language. A generic term for a language that allows a program or object written in one language to communicate with another program written in an unknown language. Examples of IDL are: ESIDL, Java-RMI IDL, and CORBA IDL.

IETF.

Internet Engineering Task Force. The body that defines standard Internet operating protocol, such as TCP/IP.

Importer.

A registry operator that copies (and, perhaps, modifies) data stored in one or more other registries.

Information model.

An electronic abstraction and representation of the UDDI resources in a registry environment, their properties and attributes, and the way they relate to each other.

Inquirer.

Any client who uses the inquiry API set to query a UDDI registry.

Intelligent Matchmaking.

Discovery of a service — choosing, either deliberately or accidentally, a specific service from a class of services, using a specific description.

Internationalization.

Internationalization (sometimes shortened to "I18N" , meaning I - eighteen letters -N) is the process of planning and implementing products and services so that they can easily be adapted to specific local languages and cultures, a process called localization.

Introspection.

At the language level, introspection is a mechanism used to query functional aspects of an object. Introspection provides information about methods and properties of an object. In the services world, introspection allows an entity to get more information about functional aspects of a service, such as vocabularies and contracts supported, quality of service, and specific interface methods.


J
J2EE.

Java 2 Platform Enterprise Edition. A platform-independent, Java-centric environment from Sun for developing, building, and deploying Web-based enterprise applications online.

J2ME.

Java 2 Platform Micro Edition. A technology that allows programmers to use the Java programming language and related tools to develop programs for mobile wireless information devices, such as cellular phones and Personal Digital Assistants (PDAs).

J2SE.

Java 2 Platform, Standard Edition. A solution for rapidly developing and deploying mission-critical enterprise applications.

JAXB.

Java APIs for XML Binding. Provides an API and tools that automate the mapping between XML documents and Java objects.

JAXM.

Java APIs for XML Messaging. Enables applications to send and receive document-oriented XML messages, using a pure Java API.

JAXP.

Java APIs for XML Processing. Enables applications to parse and transform XML documents using a pure Java API that is independent of a particular XML processor implementation.

JAXR.

Java APIs for XML Registries. Provides access to standard XML registries.

JAX-RPC.

Java APIs for XML-based RPC. This API provides a transport-independent API for standard XML-based RPC protocols.

JCP.

Java Community Process. An open organization of international Java developers and licensees whose charter is to develop and revise Java technology specifications, reference implementations, and technology compatibility kits.

JDBC.

Java Database Connectivity. An API that lets you access virtually any tab-ular data source from the Java programming language.

JDBC-ODBC Bridge.

Allows Java programs to use JDBC with many existing ODBC drivers.

JINI.

A network technology that provides an infrastructure for delivering services in a network and for creating spontaneous interaction between programs that use these services, regardless of their hardware/software implementation.

Join and Discovery Protocols.

Entities that wish to start participating in a distributed system of JINI technology-enabled services and/or devices, known as a DJINN, must first obtain references to one or more JINI lookup services. The protocols that govern the acquisition of these references are known as the discovery protocols. Once these references have been obtained, a number of steps must be taken for entities to start communicating usefully with services in a DJINN; these steps are described by the join protocol.

JRMP.

Java Remote Message Protocol. A defined set of message formats that allow data to be passed across a network from one computer to another.

JSR-109.

Java Specification Request-109 defines the programming model and runtime architecture for implementing Web services in Java.


K
Kerberos.

A network authentication protocol. It is designed to provide strong authentication for client-server applications by using secret-key cryptography.

Key.

Each UDDI element published to the registry is associated with a unique identifier. Any of the unique tokens used to identify and refer to an entity stored in a registry are keys.

Key generator.

A unique identifier key is generated by the custodial node UDDI registry. This custodial node is responsible for applying any registry policies and generating the resource key.


L
LDAP.

Lightweight Directory Access Protocol. A software protocol for enabling anyone to locate organizations, individuals, and other resources, such as files and devices in a network, whether on the public Internet or on a corporate intranet.

List.

The collection of all elements that occur in a container element.

Lower Level Services.

Services that are atomic functional units.


M
Member Class Services.

The services in an ecosystem that use the standards and rules set by the regulatory class services to offer a certain service that is within the domain of the ecosystem.

Message.

Data packets used for interprocess communication on a network.

Metadata.

Data that is not part of the resource's implementation but is used to describe and protect the resource.

MQ Integrator.

IBM's application integration product based on message brokering technology.

MSMQ.

Microsoft Message Queueing. Technology that enables applications running at different times to communicate across heterogeneous networks and systems that may be temporarily offline.

MTS.

Microsoft Transaction Service. A service that allows creation of component-based and transaction-oriented applications.

See also [EJB]

Multi-node registry.

A registry architecture that consists of more than one node. Typically in a multi-node registry, each node maintains its own copy of the entities. In such cases the copies are typically kept synchronized using an implementation of the replication API set at each node.


N
.NET.

Microsoft's initiative around the Web services paradigm. Its goal is to provide a technology stack that is interoperable and make the functional interfaces of the devices and the applications more Web services-oriented.

Namespace.

Namespace is a set of distinct names represented as strings of characters. The distinctiveness, in this case, is limited to the specific namespace only. Usually the names in a namespace are constructed according to a set of rules provided by the definition of the namespace. For example, the URLs available through the HTTP protocol must start with string "http."

NOM.

Network Object Model. Interentity interaction model based on objects communicating with each other through some RPC mechanism.


O
ODL.

Object Description Language. A Microsoft-proposed IDL.

OLE.

Object Linking and Embedding. A compound document standard developed by Microsoft Corporation. It enables you to create objects with one application, then link or embed them in a second application.

ORB.

Object Request Broker. A component in CORBA architecture that mediates the interaction between distributed objects.

Orchestration.

Microsoft term for creating and managing business processes that span multiple applications, platforms, and Web services.

Operator.

The role of a person or business entity that sets UDDI node policy and also runs a node. The UDDI specification requires exactly one operator for a given node.

Overview Document.

A document providing the technical definition of the concept a given tModel represents. The concept in this case could be a business process, a technical interaction sequence, or other such idea that needs a standardized representation. The overview documents for a given tModel may be retrieved using the URLs contained within the overviewDoc structure of the tModel.

Owner.

A publisher entity that has the authority to change a given resource or entity in the UDDI registry.


P
Peer-to-Peer Architecture.

A nonhierarchical application design style in which no particular component is in complete control of the overall functioning. The components in this architecture, self-contained, and self-managed, are peers of each other.

Persistence.

The ability of an entity to retain its state and data in an offline mode.

Policy.

Policy represents a collection of behaviors that are permitted to vary from registry to registry or even from node to node within a registry. The concept of policy is formalized and enhanced in UDDI Version 3 specification.

Policy abstractions.

Policy abstractions are broad definitions of high-level information management policies. Policies can range from business goals to device specific configuration parameters. In UDDI there are often ways to model the poli-cies as a tModel. In other cases the policy may be documented and standardized in some other form.

Policy decision.

A process perspective that deals with the evaluation of a policy rule's conditions. When an instance of UDDI is implemented, choices are made about the support for the UDDI APIs. There are points at which the implementation is responsible for a determination about whether or not the request is processed based on the rule's specified for that node. Because UDDI can be implemented in a variety of ways, these actions are considered policy decisions and the implementation must document how these decisions are made within this implementation of UDDI.

Policy enforcement.

The execution of a policy decision.

Policy goals.

The business objectives or desired state intended to be maintained by a policy system. At the highest level of abstraction of policy, these goals are most directly described in business rather than technical terms.

Policy rule.

A basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions where the conditions are evaluated to determine whether the actions are performed.

Publisher.

Any client who uses the publish APIs to publish resources to a UDDI registry.

Publish

The act of placing one or more entities in a registry by invoking one of the publication APIs.

Publisher-assigned key.

Any key created by a publisher (as opposed to one created by a node). A publisher may propose a key for a new entity at the time it is first published. If the proposed key meets the registry's policy for publisher-assigned keys and the publish operation succeeds, the key proposed by the publisher becomes a publisher-assigned key.


Q
Quality of Service.

Defines consistency and predictability metrics for a service.


R
Registry.

A directory of Web services, including service description and information on service invocation. One or more UDDI nodes may be combined to form a UDDI Registry.

Regulatory Class Services.

Services that ensure interoperability among the members of the ecosystem and enforce standards and regulations required for that purpose.

Relationship Assertion.

UDDI concept that allows business entities to associate themselves with each other; the relationship needs to be acknowledged from all parties involved unless a single entity owns both sub-entities, in which case asserting the relationship also completes it.

See also [Relationship Completion]

Relationship completion.

To agree with and acknowledge the assertion of a relationship from another business entity. Completed relationships are visible to inquirers; relationships that have not been completed are visible only to the owners of the businessEntity structures involved.

See also [Relationship Assertion]

RMI.

Remote Method Invocation. A Java mechanism for interprocess communication.

See also [RPC]

RosettaNet.

A consortium of more than 400 worldwide companies. It is a self-funded, nonprofit organization dedicated to creating, implementing, and promoting open e-business standards. These standards form a common e-business language, aligning processes between trading partners on a global basis.

RPC.

Remote Procedure Call. A protocol that one program can use to invoke a method from another program deployed on a remote computer on the network without having to understand network details.

See also [RMI]

Registry administrator.

The role that sets the policies for a registry. There is exactly one registry administrator for every registry. Typically, a registry administrator is an organization consisting of the operators of the registry's nodes.

Registry-assigned key.

A key assigned by the registry. If no key is proposed for an entity at the time it is first published, the registry assigns a key.

Relationship.

An association between one business entity and another is established by completing a relationship.


S
S2ML.

Security Services Markup Language. A standard that provides an XML specification for the sharing of security services between companies engaged in B2B and business-to-customer business transactions.

SAX.

Simple API for XML. A standard interface for event-based XML parsing.

SDL.

Service Definition Language. Microsoft's specification for service description.

Service.

An active program or a software component, in a given environment, that provides and manages access to a resource that is essential for other entities in the environment to function.

Service Aggregators.

An ecosystem entity that composes a set of related services and creates a higher-level service.

Service-Centric Economy.

An economy where business interentity interaction happens through a network of services.

Service Composition.

Combines offerings of two or more services to create a new service.

Service Deployers.

These entities can advertise or register their services in such a registry for discovery by service users.

Service Description.

A formal and publicized way to characterize features and functionality of a service offering.

Service Discovery.

A process of finding a service, based on a description.

Service Lifecycle.

A sequence of stages that a service will undergo in its life — from strategic planning to obsolescence.

Service Obsolescence.

A service lifecycle stage in which a service is obsoleted.

Service Registry.
See [Registry]
Service Type.

The type of a Web service as defined by its technical fingerprint (tModel).

SGML.

Standard Generalized Markup Language. SGML is a standard for the definition of device-independent, system-independent methods of representing texts in electronic form.

See also [XML]

SMIME.

Secure Multipurpose Internet Mail Extensions. A secure and encrypted email protocol.

SMTP.

Simple Mail Transfer Protocol. A TCP/IP-based protocol used for sending and receiving email.

SOAP.

Simple Object Access Protocol. A lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML-based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing RPCs and responses.

Sort order.

Any of the find qualifiers that specify the base algorithm to be used to order the results returned by the find xx APIs.

SPKI.

Simple Public Key Infrastructure. A specific variant of PKI developed within the IETF and used by e-Speak. see also PKI.

SSL.

Secure Sockets Layer Version 3.0. A commonly used network protocol as defined in http://home.netscape.com/eng/ssl3/index.html.

Stub.

A client-side or server-side representation of a remote object. A stub contains the necessary logic for communicating with the remote object. It hides the complexity of network communication and remoteness of the object.

Subscriber.

Any client who uses the subscription APIs.

Synchronous Interaction.

A blocking interaction in which the transacting entities are blocked in their transaction sequence until the current interaction is complete.


T
TPP.

Trading Partner Profile. ebXML specification that provides the public interface that a single trading partner can exchange with other trading partners to interact with it.

tModel.

UDDI defines a special metadata construct called tModel to describe the specifications that a service abides by. Specifications include data formats, business processes, and industry standards to name a few.


U
UDDI.

Universal Description, Discovery, and Integration. The UDDI Project is an open industry initiative enabling businesses and their services to discover each other and to define how they interact over the Internet and share information in a global registry architecture.

UDDI schema.

Any of the documents written in the XML Schema Definition Language that accompany this specification and are a part of it.

Unchecked.

Value sets that are not validated.

See also [Checked]

Unicode.

The character set defined by the Unicode Consortium. See www.unicode.org. UDDI data is expressed using the Unicode character set.

URI.

A Uniform Resource Identifier as represented by the XML Schema.

URL.

Uniform Resource Locator. An address that identifies a document or resource on the World Wide Web.

UTF-8.

The encoding scheme used by UDDI to express Unicode characters.

UUID.

A 128-bit value that is either guaranteed to be unique or extremely likely to be unique until 3400 A.D., based on the choice of algorithm. Independent computers can generate UUIDs in such a way that the same one is never generated twice. UUIDs are typically expressed in hexadecimal format.


V
Value Set.

Any category system, identifier system, relationship system or postal address system used to specify the set of valid values under that system.

Value Set Provider.

Any publisher who publishes a checked value set tModel. Typically a value set provider also provides a get_allValidValues or a validate_values Web service or both.

VPN.

Virtual Private Network. A group of two or more computer systems, typically connected to a private, dedicated network with limited public network access that communicates securely over a public network.


W
W3C.

World Wide Web Consortium. The consortium was created in October 1994 to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability.

Web Services.

Self-contained applications based on peer-to-peer architecture that can be described, published, located, and invoked over a network, generally the Internet. They interact with and/or invoke each other, fulfilling specific tasks and requests, and carry out specific parts of complex transactions or workflows.

Workflow.

The sequence of activities performed in a business or entity.

WSDL.

Web Services Description Language. A standard proposed for service description. WSDL is an XML format for describing Internet or intranet services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.

WSFL.

Web Services Flow Language. An XML language for the description of Web services compositions proposed by IBM.

WSTK.

Web Services Toolkit. IBM's toolkit for development of Web services.


X
XLANG.

A complete language that uses XML as the written format for describing any business process.

XML.

eXtended Markup Language. A platform-independent information exchange format. XML is a special case of SGML.

See also [SGML]

XML DTD.

XML Document Type Definition. Specifies formatting rules for XML (or SGML) documents.

XML RPC.

A specification and set of implementations that allow software running on disparate operating systems running in different environments to make procedure calls over the Internet.

XML Schema.

Specification for information structure in XML documents.


Team LiB

Brought to You by