<%BANNER%>

Constraint-based brokering for publishing and discovery of web services

University of Florida Institutional Repository

PAGE 1

CONSTRAINT-BASED BROKERING FOR PUBLISHING AND DISCOVERY OF WEB SERVICES By SEEMA DEGWEKAR A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2002

PAGE 2

Copyright 2002 by Seema Degwekar

PAGE 3

To my parents, Sachin and Nikhil

PAGE 4

ACKNOWLEDGMENTS I would like to thank my advisors, Dr. Stanley Y. W. Su and Dr. Herman Lam, for their invaluable and timely guidance throughout this project. It is due to their incessant efforts and unlimited patience that I have been able to complete this thesis. They have been and will always be a source of inspiration for me in whatever task I undertake. I would also like to thank Dr. Stephen Thebaut for kindly agreeing to be on my supervisory committee. It has been a great experience to work with all my project colleagues in the DB center. Special thanks are due to Ms. Sharon Grant for making the Database Research Center a great place to work. Finally, this thesis would not have been possible without a strong support on the personal front. I am extremely thankful to my parents for their constant guidance and encouragement. I am also very grateful to my friends Nikhil, Naren, Nandhini, Akhil and Kaumudi for being my family here in Gainesville. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS..................................................................................................iv LIST OF FIGURES...........................................................................................................vii ABSTRACT.......................................................................................................................ix CHAPTER 1 INTRODUCTION............................................................................................................1 1.1 Web Services An Overview...................................................................................2 1.2 Universal Description, Discovery and Integration (UDDI) An Overview.............5 1.3 The Problem Statement.............................................................................................6 1.4 Goal of Thesis and the Intended Contribution..........................................................7 1.5 Organization of Thesis..............................................................................................7 2 RELATED RESEARCH AND TECHNOLOGIES.........................................................9 2.1 UDDI.........................................................................................................................9 2.2 WSDL......................................................................................................................11 2.3 SOAP.......................................................................................................................13 2.4 Persistent Object Manager......................................................................................13 2.5 Constraint Satisfaction Processor and Cost-Benefit Evaluation Server..................14 2.5.1 Constraint Satisfaction Processor..................................................................14 2.5.2 Cost-Benefit Evaluation Server.....................................................................15 3 CONSTRAINT-BASED BROKERING........................................................................17 3.1 Web Service Constraints.........................................................................................17 3.2 Constraint Specification Language.........................................................................19 3.3 Constraint Matching................................................................................................21 3.4 Extending WSDL....................................................................................................25 4 DESIGN OF THE CONSTRAINT-BASED BROKER................................................32 4.1 System Architecture................................................................................................32 4.2 Publish and Discovery Coordinators.......................................................................33 4.2.1 Information Flow during Publishing a Web Service.....................................33 4.2.2 Information Flow during Discovering a Web Service..................................35 v

PAGE 6

4.3 UDDI and UF Registries.........................................................................................37 4.4 Constraint Satisfaction Processor and Cost-Benefit Evaluation Server..................43 5 IMPLEMENTATION DETAILS..................................................................................49 5.1 Data Structures and Class Definitions.....................................................................49 5.1.1 WSConstraint Object.....................................................................................50 5.1.2 OperationConstraint Object...........................................................................51 5.1.3 ServiceConstraint Object...............................................................................52 5.1.4 AttributeConstraint Object............................................................................52 5.1.5 InterAttributeConstraint Object.....................................................................54 5.2 IBM UDDI v2.0 Business Test Registry and Persistent Object Manager..............57 5.3 IBM Web Services Toolkit.....................................................................................58 5.4 Sample Scenario......................................................................................................59 5.4.1 Registration....................................................................................................60 5.4.2 Discovery.......................................................................................................66 6 CONCLUSION AND FUTURE WORK.......................................................................69 6.1 Summary.................................................................................................................69 6.2 Limitations and Future Work..................................................................................69 APPENDIX A SCHEMA OF THE EXTENDED WSDL DOCUMENT.............................................72 B BNF SYNTAX OF OBJECT-ORIENTED CONSTRAINT SPECIFICATION LANGUAGE (OOCSL)....................................................................................................84 LIST OF REFERENCES..................................................................................................87 BIOGRAPHICAL SKETCH.............................................................................................89 vi

PAGE 7

LIST OF FIGURES Figure page 1.1 The Web Services Technology Stack............................................................................3 1.2 The Web Services Architecture.....................................................................................4 1.3 The UDDI Technology Stack........................................................................................5 2.1 The UDDI Business Registry......................................................................................10 3.1 Constraint Specification of an Example Web Service................................................20 3.2 Constraint Specification of a Web Service Provider...................................................23 3.3 Constraint Specification of a Web Service Requestor................................................24 3.4 Constraint Matching Result between Provider 1 and Requestor.................................24 3.5 Constraint Matching Result between Provider 2 and Requestor.................................25 3.6 Extended Service Interface Document for an Example Web Service.........................28 3.7 Extended Service Implementation Document for an Example Web Service..............31 4.1 System Architecture....................................................................................................32 4.2 Information Flow During the Registration Process.....................................................34 4.3 Information Flow During the Discovery Process. A) First Phase...............................36 4.3 Information Flow During the Discovery Process. B) Second Phase...........................36 4.4 UDDI Data Structures and their Inter-relationship.....................................................39 4.5 POM System Architecture..........................................................................................40 4.6 Attribute and Inter-Attribute Constraints of two Example Constraint Sets................46 5.1 Class Definition of the WSConstraint Object.............................................................50 5.2 Class Definition of the OperationConstraint Object...................................................51 5.3 Class Definition of the ServiceConstraint Object.......................................................52 5.4 Class Definition of the AttributeConstraint Object.....................................................53 5.5 Class Definition of the InterAttributeConstraint Object.............................................54 vii

PAGE 8

5.6 Class Definition of the Constraint Object...................................................................55 5.7 Class Definition of the CSPResult Object...................................................................56 5.8 Create Table Command of the Persistent Object Manager.........................................58 5.9 Constraint Specification of a Web Service Requestor................................................59 5.10 Constraint Specification of a Web Service Provider.................................................60 5.11 Screenshot Showing all the Steps Necessary in the Registration Process................61 5.12 Screenshot Showing the Service Provider Entering Service Information.................62 5.13 Screenshot Showing the Service Provider Selecting an Operation...........................62 5.14 Screenshot Showing the Specification of Attribute Constraints...............................63 5.15 Screenshot Showing the Specification of Inter-Attribute Constraints......................64 5.16 Screenshot Showing the Specification of Service Attribute Constraints..................64 5.17 Screenshot Showing the Extended WSDL Document..............................................65 5.18 Screenshot Showing the Service Requestor Entering Interface Information............66 5.19 Screenshot Showing the Result of the Constraint Match..........................................67 5.20 Screenshot Showing the Detailed Result of the Satisfied Constraint Match............68 viii

PAGE 9

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science CONSTRAINT-BASED BROKERING FOR PUBLISHING AND DISCOVERY OF WEB SERVICES By Seema Degwekar December 2002 Chair: Dr. Stanley Y. W. Su Cochair: Dr. Herman Lam Major Department: Computer and Information Science and Engineering As e-business systems gain rapid popularity, the current focus is on effective and efficient sharing of not only data but also application systems. Traditional system architectures incorporate tight coupling among distributed components and are thus inflexible. The current trend in application development is moving away from tightly coupled systems towards systems of loosely coupled, dynamically bound components. Systems built with this principle will dominate the next generation of e-business systems. The Web service model advocates the principle of creating dynamic, loosely coupled systems based on published services over the Internet. The fundamental notion is that everything is a service and APIs are published to invoke the service, thereby hiding its implementation details. Thus, application system sharing is achieved through service invocation. The model describes three roles and three operations to define the interactions among these roles. The role of a service provider is to define the sharable functionality of ix

PAGE 10

an application as a Web service. The role of a service requestor is to use Web services to accomplish his/her tasks. Service providers publish their Web services to the third role, a service registry, which resides at a well-known network site. Using the service registry, the service requestor finds the appropriate provider and then dynamically binds the request to the service of the provider. Any service is naturally constrained by factors such as service duration, service cost, input and output data requirements, etc. If these constraints are not specified explicitly, a service requestor may unknowingly submit an illegal parameter causing the request to fail or activate a time-consuming service without getting useful information in return. However, if both the service provider and the service requestor are able to specify their own constraints, the service registry can match them and select the provider that best matches a particular request. The UDDI Project is a platform-independent, open framework for publishing and discovery of Web services. There are some publicly available implementations of the service registry based on UDDI; however, these implementations do not support constraint specification and constraint matching. In this work, we extend the functionality of the service registry to include constraint specification and constraint matching. We describe the components developed to perform constraint processing and integrate them with an existing UDDI-enabled broker to develop a constraint-based broker. We also extend the Web Services Description Language (WSDL) to allow the specification of constraints in WSDL documents. The data structures and algorithms used in constraint processing are described in this thesis. x

PAGE 11

CHAPTER 1 INTRODUCTION With e-business systems gaining rapid popularity, organizations are focusing on effective and efficient sharing of not only data but also application systems. Traditional system architectures incorporate tight coupling among distributed system components. Such systems are sensitive to change. A small number of changes may be manageable, but as the scale and rate of change increase, traditional systems are likely to break down. We therefore need a flexible architecture capable of handling this change. Meanwhile, the current trend in application development is shifting away from the traditional tightly coupled system structure to a loosely coupled one. Also, more and more applications are being built keeping a component-based architecture in mind. Furthermore, there is a growing tendency towards sharing these applications in an efficient and effective manner. The principles of flexible architecture, loosely coupled systems, and component-based systems will govern the next generation of e-business systems. The Web service framework has put forward an architecture based chiefly on these principles. The main focus is flexibility. The framework describes no single implementation but instead puts forward the concept of just-in-time integration. The system components are services that encapsulate discrete functionality. Each service publishes a communication API that is used for its invocation. The underlying service implementation is encapsulated and is therefore very flexible. 1

PAGE 12

2 In order to make this system work, we need a platform-independent framework to describe and discover services. The Universal Description, Discovery and Integration (UDDI) project is aimed at creating such a framework. Both the Web service and the UDDI technologies form a core part of our research. We now give a brief overview of each of them. 1.1 Web Services An Overview Web services can be defined as loosely coupled reusable software components that together perform specific tasks and are accessible via programs over a network [12]. As Web services are reusable software components, they represent the next step of evolution from object-oriented systems. Being loosely coupled, they are more amenable to change. They describe the inputs and outputs in such a way that it is easy to determine exactly what they do. Web services are programmatically accessible; they operate at the code level and are not designed for human interaction. Finally, Web services make use of the existing protocols so that they can be within the reach of everyone. The Web service structure is composed of several related technologies. Altogether, they describe a Web Services Technology Stack, as shown in Figure 1.1 [12]. It has three core layers and four emerging layers. The base technology is XML. It is the building block for nearly every other layer in this stack. Another core layer is SOAP. This protocol is used for messaging and RPC-like communication among applications. It is based on XML and uses HTTP. The third core layer represents common Internet protocols. These lower layers have been more or less standardized, but the same cannot be said about the higher layers. Currently, many different approaches have come into play in order to better describe these layers.

PAGE 13

3 Common Internet Protocols (TCP/IP, HTTP, etc.) Extensible Markup Language (XML) Simple Object Access Protocol (SOAP) Web Services Description Language (WSDL) Universal Description, Discovery and Integration (UDDI) Web Services Flow Language (WSFL) Other Business Rules (not yet defined) Emerging Layers Core Layers Figure 1.1 The Web Services Technology Stack The Web Services Description Language (WSDL) is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information [3]. The Universal Description, Discovery and Integration (UDDI) project defines a set of protocols and a publicly available registry that facilitates the publishing and discovery of Web services [12]. The Web Services Flow Language (WSFL) is an XML language for the description of Web services compositions [9]. The highest layer representing complex business rules has not yet been defined. It is aimed at taking care of issues such as security, quality of service, etc. The Web service architecture describes three roles: service provider, service requestor, and service registry. Along with these roles, it also defines three operations that describe the interaction among these roles: publish, find and bind. Service providers

PAGE 14

4 publish services to the service registry. Service requestors find the required services from the registry and then bind to the appropriate services of service providers. This model is shown in Figure 1.2 [5]. Bind Publish Find Service Provider Service Requestor Service Broker Figure 1.2 The Web Services Architecture In this framework, the service registry is the vital link between service providers and service requestors. Research efforts are being directed to ensure that a service broker, which implements the registry, performs its tasks as efficiently and as accurately as possible. This architecture has many advantages [5]. It allows dynamic service discovery and invocation, thereby enabling just-in-time integration. The service information published by service providers is kept at a well-known location. It minimizes the requirements for shared understanding and thus promotes interoperability. As each Web service defines its interface clearly, it reduces complexity.

PAGE 15

5 1.2 Universal Description, Discovery and Integration (UDDI) An Overview The UDDI project is a global platform-independent, open framework that can be used by businesses to discover each other, to define how their services interact over the Internet, and to share information in a global registry [16]. It is a highly developing area with more and more functionalities being added over a period of just a few months. Below, we give a brief introduction to UDDI. A more detailed description is given in Chapter 2. Common Internet Protocols (HTTP, TCP/IP) Extensible Markup Language (XML) Simple Object Access Protocol (SOAP) Universal Description, Discovery and Integration (UDDI) Universal Service Interop Protocols (not yet defined) Figure 1.3 The UDDI Technology Stack The UDDI standard is based on simple principles. It provides the three links that are missing in the existing approaches towards developing Web service applications [13]. It gives a simple transparent mechanism to describe Web services. It describes a simple mechanism for invoking services and provides a publicly accessible registry of services. Just like the Web services structure, the UDDI standard is not monolithic. It is composed of several technologies forming a UDDI Technology Stack, as shown in Figure 1.3 [13].

PAGE 16

6 SOAP provides a simple approach to link applications over the Internet. Therefore, SOAP forms the core technology in the UDDI stack. UDDI has combined the SOAP messaging layer with its own directory to create a standard that is technically sound and extremely simple to implement. The UDDI specification provides an implementation of the Web service broker mentioned in Section 1.1. Using this standard, organizations can make their services publicly known, thereby reaching new customers. It enables organizations to discover the business most suited to their needs. The standard also defines how further communication should take place once the discovery is done. 1.3 The Problem Statement As we have mentioned earlier, the topmost layer of the Web services technology stack is not yet well defined. We feel that one of the issues this layer should represent is that of service constraints. Any service is naturally constrained by factors such as cost, time, input and output data requirements, etc. It is very important to be able to specify such constraints on a service from both the service providers and the service requestors points of view. This would allow Web services to be specified more precisely to reflect their real world constraints. This facility of constraint specification has to be provided at a well-known site to ensure that it is available to everyone. Similarly, there should be a publicly available mechanism to match the constraints of the service provider versus those of the requestor. Thus we see the need of adding the functionality of both constraint specification and constraint matching at the broker site. In the UDDI framework, service providers and service requestors can access any broker site that has been made public. To ensure that constraint specification and

PAGE 17

7 matching is done uniformly; we need a language to specify these service constraints. We could choose to either define a new language or make some extensions to an already accepted service representation. The latter approach seems to be more acceptable, as explained in the next section. 1.4 Goal of Thesis and the Intended Contribution In this thesis, we explore the possibility of adding the capability of constraint specification and constraint matching to the service registry defined in the Web service framework. We show how we can extend the current UDDI registry so that service providers and service requestors will be able to specify their own constraints over the services they wish to provide or request, respectively. The result is a constraint-based broker capable of finding a service provider whose constraints best satisfy/match those of a requestor. We make use of the Constraint-based Requirement Specification Language, a result of our earlier research efforts in this area [15], to specify constraints. However, we use this language only to define the data structures that we shall need for constraint specification. To make sure that this constraint information is available in a format already well understood and accepted, we show how we can extend the current WSDL specification to accommodate this information and to enable its effective use. 1.5 Organization of Thesis This thesis is organized as follows. Chapter 2 describes the state-of-the-art in this area. It points out the important and relevant features of some of the systems that we use. Chapter 3 explains the concept of constraint-based brokering and illustrates the entire process with a typical example. Chapter 4 presents the design of a constraint-based broker. It also explains the flow of information among the different components of our

PAGE 18

8 system. Chapter 5 gives the implementation details of the constraint-based broker. Chapter 6 summarizes the thesis by pointing out the key features of our system and describes our future work in this area.

PAGE 19

CHAPTER 2 RELATED RESEARCH AND TECHNOLOGIES In this chapter, we look at current research efforts and emerging technologies related to our work. In Sections 2.1 and 2.2, we elaborate on the concepts proposed by both UDDI and WSDL. In Section 2.3, we give a brief overview of on SOAP. In the next section, we discuss the Persistent Object Manager, which is used to store Java objects in a persistent fashion. In the last section, we briefly describe a Constraint Satisfaction Processor and a Cost-Benefit Evaluation Server, which are used by the constraint-based broker for provider selections. 2.1 UDDI The concept of service-centric computing offers advantages like increased revenue, meeting new customers, and lowered costs for organizations that have moved their businesses online [16]. However, most e-commerce-enabling applications have no uniform means of uniting buyers and suppliers. The solution to this dilemma is provided by the Web services technology, which is based on standard methods of description, discovery and integration. To realize the benefits of this technology, we need a standard platform for communication between service providers and service requestors. UDDI provides this platform. A common analogy used for UDDI is a phone book for Web services [16]. It has business names, business addresses, service contact information, and technical service information. Though much of the information stored in the UDDI registry is meant for automated computing, there is other information that is of interest to people. 9

PAGE 20

10 The registry is so designed that it can be programmatically accessed without any human intervention. As a result, valuable technical and business staff can focus on more strategic questions. At the same time, there is a well-known URL that provides a GUI for the registry. A service provider or service requestor can browse through this information and use it to learn more about the registry. UDDI is a platform-independent, open framework that describes how businesses can discover each other, interact with each other, and share information stored in a global registry. The information provided by service providers during the business registration process consists of three components. These are called the white pages which consist of company contact information, yellow pages which consist of business categories, and green pages which contain the technical information about any exposed service. Figure 2.1 [13] illustrates this concept. Business name Contact information Human-readable description Identifiers Services and product index Industry codes Geographic index GREEN PAGES E-business rules Service descriptions Application invocation Data binding YELLOW PAGES WHITE PAGES Figure 2.1 The UDDI Business Registry There are two main reasons why this technology will succeed [13]. The first one is that business and economic conditions are right for tackling the problems that UDDI solves. The second one is that the standards technology has been developed using simple and effective principles. UDDI promises to remove the bottleneck in finding web-based services and significantly improve the ability of web-based software to connect to other software.

PAGE 21

11 Instead of developing our own registry to demonstrate the constraint-based brokering concept, we have used and extended the functionality of the publicly available IBM UDDI version 2.0 Business Test Registry. We will look at the features and design principles of this specification in Chapter 4. 2.2 WSDL WSDL defines an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication [3]. A WSDL document is a set of definitions. The abstract information about a service, such as the operations that it supports, and the input and output parameters to these operations, is kept separate from the concrete network deployment. The abstract information is called service interface information, and the network information is called service implementation information. Because WSDL separates these two kinds of information, it allows the reuse of the abstract definitions. Input and output parameters of service operations are put together in a structure called a message. Operations are grouped together in port types. The concrete protocol and data format specifications for a particular port type constitute a reusable binding. A port is defined by associating a network address or an access point with a reusable binding. Services are defined as collections of ports. A WSDL document uses the following elements in the definition of network services [3]: 1. Types: The types element encloses data type definitions that are relevant for exchanged messages. For maximum interoperability and platform neutrality,

PAGE 22

12 WSDL prefers the use of the XML Schemas Definition (XSD) as the canonical type system, and treats it as the intrinsic type system. 2. Message: Messages consist of one or more logical parts. Each part is associated with a type from some type system using a message-typing attribute. Parts describe the abstract content of a message. For example, if we are defining a message for use with RPC, a part may represent a parameter in the message. However, the actual meaning of the part is located in the binding information. 3. Port Type: A port type is a named set of abstract operations and the abstract messages involved. WSDL has four transmission primitives that an endpoint can support one-way, request-response, solicit-response, and notification. These primitives are called operations. Each operation has input and output elements that specify the corresponding abstract message format. 4. Binding: A binding defines message format and protocol details for operations and messages defined by a particular port type. There may be many bindings for a given port type. A binding must specify exactly one protocol and it must not specify address information. 5. Port: A port defines an individual endpoint by specifying a single address for a binding. A port must not specify more than one address, and it must not specify any binding information other than address information. 6. Service: A service groups a set of related ports together. Ports within a service do not communicate with each other. A service may have several ports that share a port type. In that case, these ports are alternatives to one another as they employ different bindings or addresses. By examining its ports, we can determine a services port types. Thus, we can choose whether we want to communicate with a particular service based on what port types it supports. As WSDL is an XML format, it is very open to language extensions. Also, it provides a uniform manner of service description. For maximum interoperability, any service provider will use WSDL to describe his/her service. Also, UDDI provides a data structure support to both service interface and service implementation information. Taking all these factors into consideration, we have proposed an extension to the current WSDL specification in order to incorporate service constraint information. The details of this procedure are given in Chapter 3.

PAGE 23

13 2.3 SOAP SOAP provides a simple and lightweight mechanism for exchanging structured and typed information among peers in a decentralized, distributed environment using XML. SOAP itself does not define any application semantics, such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules [1]. This allows SOAP to be used in a large variety of systems ranging from messaging systems to RPC. SOAP consists of three parts: The SOAP envelope construct defines an overall framework for expressing what is in a message, who should deal with it, and whether it is optional or mandatory. The SOAP encoding rules defines a serialization mechanism that can be used to exchange instances of application-defined data types. The SOAP RPC representation defines a convention that can be used to represent remote procedure calls and responses. A major design goal for SOAP is simplicity and extensibility. This has resulted in several features from the distributed object systems or traditional messaging systems such as garbage collection, batching of messages, etc., to be absent in the core SOAP specification. In this thesis, we use the SOAP specification through the WSDL specification. The IBM Web Services Toolkit also makes use of SOAP messages, as we shall see in Chapter 5. 2.4 Persistent Object Manager In order to build flexible, scalable, mainstream business software systems, we need object-oriented or object-based technology. Most of these business application

PAGE 24

14 systems need to handle persistent data. Hence, a persistent object storage service is required to make these applications useful [11]. Persistence can be achieved in many ways. The Persistent Object Manager (POM) [11] explores the different approaches to providing persistence and then selects the most efficient and effective one. The first approach to providing persistence is the use of object serialization. However, this method has the drawback of the inability to manage large volumes of data. The second approach is to use Object Oriented Database Systems (OODBMS); however, query facilities and transaction management are not well developed in these systems and this presents a major drawback. The approach used by POM is to use the proven, mature and stable technology of relational database systems. POM uses an Object-relational database called Cloudscape to store objects in a persistent fashion. It bridges the gap between the object-oriented paradigm and the relational paradigm by providing an effective mapping between the relational and the object-oriented mechanisms. POM provides the features of object storage, object retrieval, object updating and object deletion. All of these features are executed as a transaction. It also provides concurrency control and transaction management to enable data sharing among multiple users. The design details of POM are given in Chapter 4. 2.5 Constraint Satisfaction Processor and Cost-Benefit Evaluation Server In this section, we will briefly describe the goals of the Constraint Satisfaction Processor (CSP) and the Cost-Benefit Evaluation Server (CBES). 2.5.1 Constraint Satisfaction Processor In Chapter 1, we defined the roles of a service provider, a service requestor and a service registry. A service provider publishes his/her Web service to the service registry.

PAGE 25

15 The service requestor makes a request for a particular service to the service registry. This registry is responsible for finding a suitable match for the given request. As we have said earlier, constraint matching will provide a service requestor with better results. For this purpose, we have the Constraint Satisfaction Processor. This module takes two constraint specifications as input and gives a detailed result of their match. The algorithm used will be explained in Chapter 4. The result gives a list of values for each parameter of the submitted constraints. These values satisfy both constraint requirements and are thus safe to use. By adhering to these values, a requestor is guaranteed that illegal parameters will never be sent during the invocation of a service. The Constraint Satisfaction Processor was developed for an automated negotiation system [4, 15]. In order to use it in the context of Web services, we have extended the language used to specify constraints with several additional constructs. We have also added support for some more data types. These details will be given in Chapter 5. 2.5.2 Cost-Benefit Evaluation Server A business company often faces the need to evaluate the costs and benefits of several competing business offers to determine the one that best meets its criteria. In e-business, there is a need to automate this process of cost-benefit evaluation. The Cost-Benefit Evaluation Server (CBES) [10] is based on a quantitative cost-benefit decision model [14]. In our system, we need to use CBES in case there are multiple providers that satisfy a particular request after the constraint matching process. This will help us choose the best provider among the ones that meet the service requestors constraint

PAGE 26

16 requirements. The design details and the method employed to calculate the costs and benefits of a particular service provider or service requestor are given in Chapter 4.

PAGE 27

CHAPTER 3 CONSTRAINT-BASED BROKERING In this chapter, we outline the process of constraint-based brokering. In Section 3.1, we explain what we mean by constraints and the need to specify them. We also give examples of the different kinds of constraints that we have identified. In Section 3.2, we discuss a suitable language for constraint specification. In Section 3.3, we explain the constraint matching technique with examples. In Section 3.4, we discuss how we can extend the current Web Service Description Language (WSDL) to incorporate this constraint information. 3.1 Web Service Constraints When we talk about a Web service, we can think of many attributes that can characterize the service. For example, one attribute can be the time required for completing this service. Another attribute can be the availability of this service. A third attribute can be the cost of using this service. These attributes characterize the service in its entirety. We shall call this type of attributes as service attributes. A service may have one or more operations. An operation can also be characterized by some attributes (e.g., cost of invoking the operation, the estimated time to perform the operation, etc.). We shall call this type of attributes as operation attributes. An operations input and output data are characterized by a set of attributes or objects with attributes, which we shall call input and output attributes, respectively. We can now define constraints as the values that these different types of attributes should or can have. When a service provider publishes a Web service, it is important to 17

PAGE 28

18 specify the constraints associated with these attributes. There are two general types of constraints. One is associated with the individual attributes and is called attribute constraint. The other type specifies the inter-relationship among these attributes and is called inter-attribute constraint. The specifications of these two types of constraints are called Web service constraint specifications. These constraint specifications can represent simple or complex business rules or policies. For example, consider a product order service. A service provider for this service may wish to make it available only to a restricted group of companies, or only for some limited time during weekdays. This constraint on the service attribute availability is an example of an attribute constraint. This service can have an operation order with an input attribute quantity. The service provider may have a minimum and maximum value for this attribute. So, the constraint quantity lies between 100 and 500, (i.e., the range of values that quantity can have is [100..500]), is another example of an attribute constraint. Lets say that the operation order has another attribute delivery_days that gives the number of days required to deliver a product. This attribute has some dependency on the quantity of a product ordered. An example of an inter-attribute constraint for this service would then be If the quantity of a product ordered is greater than 800 units, the number of days for product delivery will be greater than 10 days. So far, we have considered the constraint specification from the service providers side. Now consider a service requestor making a request to the service broker for this service. S/he may want to specify some constraints associated with the service and the operation to be invoked, and its input and output data. For example, the requestor may specify that the product order service should not cost more than 3 dollars, the delivery

PAGE 29

19 days cannot be greater than 5 days, and the product to be ordered is a computer. Without constraint specification and processing capabilities, the broker may select a wrong service provider for a service request and a time-consuming service could be invoked without producing meaningful data to the requestor. Constraints in both Web service specifications and service requests can allow the broker to select the suitable service providers that satisfy the requestors requirements. Thus we see the need for constraint specification and matching. But, in order for this to work at the Web service level, we need to have a uniform mechanism, i.e., a language to specify constraints. Also, we need an efficient and effective algorithm for constraint matching. We will look at these issues next. 3.2 Constraint Specification Language The constraint specification language must enable service providers to specify attribute and inter-attribute constraints at the time of publishing their Web services to the broker. The same language must also be used by service requestors to specify their constraints at the time of submitting their requests to the broker. For constraint specifications, we adopt the syntax and semantics of the Constraint-Based Requirement Specification Language [15]. Figure 3.1 shows a Web service specification with constraints in a tabular format. The example used is an E-auction service, by which people auction certain items on the Internet. This service has several operations, including buy, sell and checkstatus. Each of these operations has its own input, output and operation attributes. Input, output, operation, and service attributes are distinguished from each other by the prefixes in, out, op, and svc, respectively. Also, to avoid naming conflicts while specifying inter-attribute constraints, we prefix the operation name as well to the input, output and operation attributes.

PAGE 30

20 SERVICE: E-AUCTION ATTRIBUTE_CONSTRAINT: Svc_basecost Float EQUAL 4 OPERATION: BUY ATTRIBUTE_CONSTRAINT: Buy_in_item String ENUM {Printer, Computer, Scanner} Buy_in_price Float RANGE [100.00..5000.00] Buy_out_orderno String Buy_op_cost Float LESSEQUAL 3 OPERATION: SELL ATTRIBUTE_CONSTRAINT: Sell_in_item String ENUM {Printer, Computer, Scanner} Sell_in_pricequote Float RANGE [100.00..5000.00] Sell_out_orderno String Sell_op_cost Float EQUAL 3 OPERATION:CHECKSTATUS ATTRIBUTE_CONSTRAINT: Checkstatus_in_orderno String Checkstatus_out_status String ENUM {Accepted, Rejected} Checkstatus_op_cost Float EQUAL 3 INTERATTRIBUTE_CONSTRAINT: IC1 Buy_in_item= Computer Implies Buy_in_price>800 IC2 Buy_in_price>=3000.00 Implies Buy_op_cost = 1 Figure 3.1 Constraint Specification of an Example Web Service The service has an attribute basecost, which is the cost of using the service regardless of what operations are to be used. For the operation buy we have two input attributes: item (first row) signifying the commodity to be bought and price (second row) signifying the price at which the item is to be bought. The output attribute orderno (third row) gives the order number assigned when this operation is invoked. There are no constraints on this attribute. This operation has its own cost (fourth row). Similarly, the operation sell has two input attributes: item signifying the commodity to be sold and price_quote signifying the initial quoted price. The output attribute orderno is the order number assigned when this operation is invoked. This operation also has its own cost attribute. The operation checkstatus has an input attribute orderno, which has no

PAGE 31

21 associated constraints. The output attribute status signifies the status of this order, i.e., whether it has been accepted or rejected. Constraints associated with the above mentioned attributes are given in columns 2-4. Each attribute constraint has a data type (second column), a keyword (third column) that tells us the nature of these constraint values, and the actual values and value ranges (fourth column). In Figure 3.1, we have shown the data types of float, and string and keywords of range, enum (for enumeration), lessequal (for less than or equal to) and equal. The inter-attribute constraint IC1 states that, if the product a customer wishes to buy is a computer (the second column), the price has to be greater than $800.00 (the fourth column). The second inter-attribute constraint IC2 is a business rule that guarantees the buyer of a lower operation cost if s/he buys goods worth $3,000 or more. In its general form, an inter-attribute constraints If and Then conditions can be complex Boolean expressions. In addition to the attribute and inter-attribute constraints illustrated above, priority values (not shown in the figure) can be assigned to these constraints. They specify the relative importance of these attributes and are used by the constraint matcher to establish the order of evaluation. Another language facility is to allow the specification of an attribute to be either negotiable or not. The violation of a nonnegotiable attribute will immediately terminate the constraint evaluation process. These attributes will be described in detail in Chapter 5. 3.3 Constraint Matching For provider selection, the service broker needs a mechanism to match the constraints given in a service request against those of service providers. In this work, we use a Constraint Satisfaction Processor (CSP) developed for an automated negotiation

PAGE 32

22 system, reported in Su et al. [15]. This processor takes two constraint objects (i.e., constraints of the request and those of a potential provider) to be matched as its input. The output basically tells us whether the input objects matched or not. Along with that, CSP also gives the attribute values and the combinations of these values that can satisfy both sets of constraints. Recall in the example given in Figure 3.1, attribute constraints are specified by ranges, enumerations, and single values with comparison operators. CSP normalizes the constraint specifications of all numerical attributes into interval sets. For example, the attribute value >5 is converted to [(5,)]. The enumeration (4, 6, 10) is converted to [[4,4], [6,6], [10,10]] and the range specification remains in its interval form. For each numerical attribute, the interval values from both sets of interval sets are compared and intersections between intervals are taken to generate the resulting interval sets, which contain the common values in both sets of interval sets (i.e., the values that satisfy the constraints of both the provider and requestor). For non-numerical attributes, the value constraints of the provider and the requestor are matched in a straightforward manner. After the attribute constraint matching, inter-attribute constraints of the provider and the requestor are then examined to filter out those attribute values that violate the inter-attribute constraints. If the value(s) of any attribute in the request does not satisfy the corresponding constraint of the provider, the constraint satisfaction processing fails. Otherwise, the provider is a candidate provider for the request. CSP would generate all combinations of attribute values that satisfy the constraints of both the provider and the requestor. If multiple providers satisfy the constraints of a request, cost-benefit

PAGE 33

23 evaluations are then performed on these combinations by a Cost-Benefit Evaluation Server [14, 15] to perform provider selection. SERVICE: E-AUCTION ATTRIBUTE_CONSTRAINT: Svc_basecost Float EQUAL 5 OPERATION: BUY ATTRIBUTE_CONSTRAINT: Buy_in_item String ENUM {Printer, Scanner} Buy_in_price Float RANGE [500.00..5000.00] Buy_out_status String ENUM {Processing, Shipped} Buy_op_cost Float LESSEQUAL 4 OPERATION: SELL ATTRIBUTE_CONSTRAINT: Sell_in_item String ENUM {Printer, Scanner} Sell_in_pricequote Float RANGE [500.00..5000.00] Sell_out_finalprice Float RANGE [500.00..5000.00] Sell_op_cost Float EQUAL 4 OPERATION: CHECKSTATUS ATTRIBUTE_CONSTRAINT: Checkstatus_in_orderno String Checkstatus_out_status String ENUM {Accepted, Rejected} Checkstatus _op_cost Float EQUAL 4 INTERATTRIBUTE_CONSTRAINT: IC1 Buy_in_item= Printer Implies Buy_in_price>500 IC2 Buy_in_price>=2900.00 Implies Buy_op_cost = 2 Figure 3.2 Constraint Specification of a Web Service Provider In order to use the CSP in the Web service scenario, we have made a few extensions. We have introduced some new data types and keywords to describe constraint values. CSP basically defines inter-attribute constraints by means of implications. We have extended this concept further so that it can incorporate business rules. Thus, a business rule such as The sum of quantity A and quantity B cannot be greater than 50 as an implication is defined as True implies the sum of quantity A and quantity B cannot be greater than 50.

PAGE 34

24 To give an example of constraint matching, we use the Web service E-Auction described in the preceding section. Figure 3.1 describes the service provider constraints of one service provider. Another service providers constraints are given in Figure 3.2. To give an example of constraint matching, we use the Web service E-Auction described in the preceding section. Figure 3.1 describes the service provider constraints of one service provider. Another service providers constraints are given in Figure 3.2. SERVICE: E-AUCTION ATTRIBUTE_CONSTRAINT: Svc_basecost Float EQUAL 4 OPERATION: BUY ATTRIBUTE_CONSTRAINT: Buy_in_item String ENUM {Computer} Buy_in_price Float RANGE [200.00..5000.00] Buy_out_orderno String Buy_op_cost Float LESSERTHAN 3 INTERATTRIBUTE_CONSTRAINT: IC1 Buy_in_price>=2500.00 Implies Buy_op_cost<=2 Figure 3.3 Constraint Specification of a Web Service Requestor Figure 3.3 Constraint Specification of a Web Service Requestor Prior to constraint matching, both the service providers seem to satisfy the requestors needs; however, after we run the matching algorithm, we find that only the provider described in Figure 3.1 satisfies the requestors constraints in Figure 3.3. This is reflected in the results shown in Figures 3.4 and 3.5. Prior to constraint matching, both the service providers seem to satisfy the requestors needs; however, after we run the matching algorithm, we find that only the provider described in Figure 3.1 satisfies the requestors constraints in Figure 3.3. This is reflected in the results shown in Figures 3.4 and 3.5. CONSTRAINT MATCH RESULT Satisfied : True ValueLists: Attribute Value Buy_in_item {Computer} Buy_in_price (800.00..5000.00] 0..5000.00] Buy_out_orderno Buy_out_orderno No constraint No constraint Buy_op_cost Buy_op_cost (-,3) (-,3) Svc_basecost Svc_basecost 4 4 Figure 3.4 Constraint Matching Result between Provider 1 and Requestor Figure 3.4 Constraint Matching Result between Provider 1 and Requestor

PAGE 35

25 CONSTRAINT MATCH RESULT Satisfied: False ViolatedAttributes: item Figure 3.5 Constraint Matching Result between Provider 2 and Requestor Only a part of the actual generated result is shown in Figure 3.4. The actual result also includes all the combinations of attribute values that satisfy the constraints, but they are not shown here to keep the explanation brief. The complete result specification will be shown in Chapter 5. Based on the results of these two matches, the service broker would select Provider 1 for the request. The requestor is guaranteed that the service invocation will not fail if s/he adheres to the attribute value combinations returned by the broker. 3.4 Extending WSDL Though the constraint specification language discussed in Section 3.2 is a very effective means of specifying constraints, it would be more useful if we could provide an extension to an already established language. In this section, we propose such an extension to WSDL. The Web Services Description Language (WSDL) is the current standard for specification of Web services. WSDL documents can be used to register services with the UDDI registry. There are two kinds of documents that are used while registering a service [2]. The first is known as the Service Interface Document, that gives only the input and output attributes for each service operation and omits implementation details such as port address, communication protocol, etc. The other document is the Service Implementation Document. It refers to some previously defined Service Interface Document and gives the implementation details for the service operations defined in that document.

PAGE 36

26 For constraint specifications, WSDL is extended in our work to include the statements of our Constraint-Based Requirement Specification Language in XML format. Extensions are made in both types of documents. In the interface document, the names and data types of both operation attributes and service attributes are added as shown below. This will result in a well-defined set of attributes for the interface, and all service providers wishing to implement it will work with the same set of attributes Standard WSDL service interface definition for an e-auction service

PAGE 37

27

PAGE 38

28
cost float cost float cost float basecost float
Figure 3.6 Extended Service Interface Document for an Example Web Service The service and operation attributes are added to the WSDL document by adding another XML tag interface_attributes as a child of the main tag definitions. Under this new tag, we have the XML tags operation_attributes and service_attributes. Each operation_attributes tag has the operation name as its attribute. Under each operation_attributes tag, we have a number of operation_attribute tags that give the name and data type of each such attribute. Similarly, under each service_attributes tag, we have a number of service_attribute tags that give the name and data type of each service attribute.

PAGE 39

29 Constraints represent specific information given by each service provider who implements a service based on a service interface document. This information should therefore be given in a Service Implementation Document. The extended Service Implementation Document is shown below. It contains the constraints shown in Figure 3.1 This service provides an implementation of an e-auction service. Electronic Auction Service Electronic Auction Service Port item string ENUM {"Printer", "Computer", "Scanner"} price float RANGE [100.00..5000.00]

PAGE 40

30 status string ENUM {"Processing", "Shipped"} cost float LESSEQUAL 3
item string ENUM {"Printer", "Computer", "Scanner"} pricequote float RANGE [100.00..5000.00] finalprice float RANGE [100.00..5000.00] cost float EQUAL 3 status string ENUM {"Accepted", "Rejected"} cost float EQUAL 3

PAGE 41

31 basecost float EQUAL 4
IC1 Buy_in_item="Computer" Buy_in_price>800 IC2 Buy_in_priceprice>=3000.00 Buy_op_cost=1
Figure 3.7 Extended Service Implementation Document for an Example Web Service The required constraint information is incorporated in the WSDL specification by adding another XML tag, constraints, as a child of the main tag, definitions. Under this new tag, we have the XML tags constraint, service_constraints and interattribute_constraints. Each constraint tag has the operation name as its attribute. Under each constraint tag, we have a number of tags, namely, input_constraint, output_constraint, and operation_constraint tags, which give the constraint descriptions for the input, output and operation attributes, respectively. Under each service_constraints tag, we have a number of service_constraint tags that give the description of each service attribute constraint. Each interattribute_constraints tag contains a number of interattribute_constraint tags that describe the inter-attribute constraints among all the constraint attributes, as shown in Figure 3.7

PAGE 42

CHAPTER 4 DESIGN OF THE CONSTRAINT-BASED BROKER In this chapter, we first give the overall design of our system, followed by an explanation of how the system works. We then give the detailed design of the key components of our system. 4.1 System Architecture The architecture of the Constraint-based Broker is shown in Figure 4.1. CBES Constraint-based Broker Publish Coordinator Discovery Coordinator UF Registr y (POM) CSP UDDI Registry Service Requestor Service Provider Figure 4.1 System Architecture The key components of this system are the UDDI Registry, the UF Registry and the Constraint Satisfaction Processor (CSP). The Discovery Coordinator and the Publish Coordinator form the communication link among these three components. Optionally, we can make use of a Cost-Benefit Evaluation Server [10], the details of which will be explained in Section 4.4. 32

PAGE 43

33 There are two operation scenarios here: one is the service provider registering (publishing) a Web service and the other is the service requestor trying to find (discover) a suitable service. The Publish Coordinator handles the registration scenario and the Discovery Coordinator handles the find scenario. The system works as follows. The service provider registers his Web service with the system through the Publish Coordinator. The registration information contains UDDI information as well as constraint information. It is up to the Publish Coordinator to store this information in the appropriate registries. When the service requestor asks for a Web service that will meet his needs, the Discovery Coordinator carries out a two-phase search procedure. In the first phase, a list of service providers is obtained from the UDDI registry. In the second phase, the service requestors constraint information is matched with that of the service providers in the list to filter out those providers that do not satisfy the requestors constraints. During these phases, the list of service providers is thus pruned till we get the final list of suitable service providers. This is then returned to the service requestor. We now present the design details of the components in our system. 4.2 Publish and Discovery Coordinators As mentioned earlier, these two components handle different operation scenarios. Let us now look at the information flow for each scenario and the function of each component. 4.2.1 Information Flow during Publishing a Web Service When registering a service with a UDDI-enabled broker, the service provider needs to give UDDI information, such as the service name, service access point, UDDI classification of the service, etc. But with the Constraint-based Broker, the service

PAGE 44

34 provider needs to provide constraint information as well. Current UDDI registries are not designed to accept this information. Hence, we store this information in our own homegrown registry. This registry is called Persistent Object Manager (POM), which is the result of an earlier project of our research center [11]. This POM can store constraint information in the form of Java Objects in a persistent fashion so that they can be retrieved and queried upon later. Key 4 Service Provide r Publish Coordinato r UDDI Registry UF Registry (POM) Separate registration information to be stored in appropriate registries 2 Register Service 1 UDDI Information 3 Constraint Information + Key 5 Acknowledgement 6 The Registration Process Figure 4.2 Information Flow During the Registration Process As shown in Figure 4.2, the request to publish a service goes to the Publish Coordinator component of the broker. This request contains UDDI information along with a constraint specification. The Publish Coordinator separates the UDDI information from the submitted request and stores it into the UDDI registry. It then takes the constraint specification and stores it into the POM.

PAGE 45

35 After the publish operation is done, the service provider gets back an acknowledgement from the Publish Coordinator. Optionally, a service provider may use the user interface facility of a Cost-Benefit Evaluation Server (CBES [10]) (not shown in Figure 4.2) to register her/his preferences with respect to different values and value ranges of all the attributes specified in the service interface document, and to provide cost information if it is available. Thus, in case of more than one service provider satisfying a service request, the CBES would make use of the registered preferences and cost information of these providers to do cost-benefit analysis and provider selection. 4.2.2 Information Flow during Discovering a Web Service When discovering a service with the UDDI-enabled broker, the service requestor needs to give some search criteria, such as the service category, owning business, etc. Accordingly, a list of services that satisfy this request is returned. Normally, a service requestor has enough knowledge about the service interface that s/he wants. Using this knowledge, first a suitable service interface is found, and then implementations of this interface are requested. In the constraint-based broker system, we separate the discovery procedure into two phases. The first phase is shown in Figure 4.3a. As soon as a service request is submitted, a component called the Discovery Coordinator starts the first phase. The UDDI registry is contacted with the submitted search criteria and the results returned are given back to the service requestor. These results contain a list of satisfactory service interfaces. The service requestor then uses these results to select a suitable service interface that has the desired operations.

PAGE 46

36 Service Requesto r Discovery Coordinato r UDDI Registry UDDI Search Criteria 2 Search for Interface 1 Results 4 3 List of Suitable Interfaces The Discovery Process Phase I Figure 4.3 Information Flow During the Discovery Process. A) First Phase. Once that is done, the service requestor is asked for service constraint information. This starts the second phase of the discovery process, which is shown in Figure 4.3b. Service Requesto r Discovery Coordinato r UF Registry List of Service Pr ov i de r s 7 Constraint Information 5 Satisfying Service Provider Information 10 First phase r esu lt s 6 CSP Requestor and Provider Constraint Information 8 Constrain t match results 9 The Discovery Process Phase II Figure 4.3 Information Flow During the Discovery Process. B) Second Phase.

PAGE 47

37 The Discovery Coordinator queries the POM using the results of the first phase to get a list of potential service providers. CSP is then used to match request constraints against those of each of the providers. If multiple providers satisfy the request, the CBES (not shown in Figure 4.3b) is used to find the best service provider. 4.3 UDDI and UF Registries In order to leverage the existing knowledge in this area, we have designed the system to take advantage of the currently implemented UDDI-enabled registries. In our work, we use IBMs UDDI version 2.0 Business Test Registry as the UDDI registry [6]. We now discuss the design principles of the UDDI version 2.0 specification and the data structures used. The basic design principle behind the specification is simplicity. The API has been so designed that there is minimal overlap and the basic registered information is available readily without much programming overhead. In order to design such a simple and efficient system, many issues need to be addressed [18]. We will examine these one by one. 1. Security: UDDI is programmatically accessed via API calls. We have two sets of APIs here. One set is defined for the use of the service provider and the other set is for the use of the service requestor. We have a different type of security for each set. Only authenticated users are allowed to use the service provider API. Each provider has access to only those businesses, services and interfaces that s/he has published. On the other hand, the API provided for the requestor can be used by anybody. The service requestor cannot modify any information. These different security levels guarantee a secure transaction during registration, and, at the same time, provide easy access during discovery. 2. Versioning: The UDDI specification is undergoing much change in a very short time period. As a result version control is a very important issue. In case of different versions of APIs between two parties (for example, provider and requestor or requestor and registry), there needs to be some way of determining the correct version to be used. This is facilitated by the use of XML as the base of the API. The API is version stamped and this stamp appears as an XML attribute. This attribute is named generics. Thus, UDDI v 2.0 will have the generics

PAGE 48

38 attribute set to a value of 2.0. All sites supporting a particular version are required to support at least the previous version. 3. SOAP Messaging: UDDI uses SOAP in conjunction with HTTP to provide a simple mechanism for XML message passing. Each version of the specification has its own support for different attributes of the SOAP mechanism. These include support for SOAP Action, SOAP Header, SOAP encoding, SOAP Fault, SOAP Error, etc. We will not go into the details here. The important point is that SOAP is a very convenient way of linking applications over the Internet. As such, the use of SOAP in the UDDI specification will ensure easy accessibility by applications in the future. 4. Error Handling: Most of the error reporting is governed by the SOAP specification. As a result, the UDDI specification needs to define error codes for only those errors not handled by SOAP. Most of the invalid requests can be handled by SOAP fault reporting and fault codes. In case of an application level error, a structure called a dispositionReport will be embedded inside a SOAP fault report. Generally, errors are detected prior to processing a request. Thus, invalid requests are not considered further, and this results in a minimum load on the registry at any one time. UDDI error codes are defined to describe some general errors. However, in case of an unusual error, the operating site is allowed to return other error codes. Also, the error that is detected first is the only one that is reported. 5. Unique Identifiers: During the registration process, a service provider can register a business, service, or a service interface. All this information is kept in separate data structures, as we will see shortly. Each of these structures is accessed by way of unique identifiers called a Universal Unique Identifier (UUID). These identifiers are generated when the information is first saved. Each service provider can use this identifier later to add, modify, or delete this information. The identifier is a hexadecimal string generated by a very exacting algorithm so that no two generated UUIDs are duplicates of each other. We will now look at the data structures used by this specification. There are basically five data types defined in this specification; but for our purposes, we shall need four of these. These four types and the interaction among them are shown in Figure 4.4. We will now give the details of each [17]. 1. The businessEntity Structure: This structure represents all known information about a business entity. This structure is the topmost level of the data structure hierarchy. Each such structure is assigned a businesskey that is its UUID. It contains descriptive information about the entity, such as the categorization of the business, the contacts for this particular entity, etc. It also contains information about the services that this entity offers. This information is stored in another

PAGE 49

39 structure called the businessService structure, as we shall see next. This information is expressed within a businessEntity structure by a containment relationship, as shown in Figure 4.4. b indingTemplate data contains references to tModels. These tModels designate the interface specifications for a service. businessService : Contains descriptive information about a business service. bindingTemplate: Contains technical information about a service access point and other implementation details. tModel: Contains descriptions of specifications like service interfaces. businessEntity : Contains information about the provider who registers a family of services. Figure 4.4 UDDI Data Structures and their Inter-relationship 2. The businessService Structure: This structure represents each service registered by the service provider. It holds descriptive information such as the category of the service, language-qualified text descriptions of the service, etc. The technical information such as binding information, service access points, a reference to the service interface, etc., is also stored via containment of another structure called the bindingTemplate structure. In case the service information is available as a WSDL document, the URL of the document can also be stored here. 3. The bindingTemplate Structure: Technical descriptions of Web services are accommodated via individual contained instances of the bindingTemplate structure. These structures provide support for determining a technical entry point or optionally support remotely hosted services. They also provide a facility for describing the unique technical characteristics of a given implementation. This information is most vital for service description and discovery. 4. The tModel Structure: The tModel structure takes the form of keyed metadata. This structure can define almost anything. One of the purposes of this structure is to mark a service with information that designates how it behaves, what

PAGE 50

40 specifications or standards it follows, etc., thus, it provides a convenient place to store information about the service interface and it is for this purpose that we are using the tModel structure. In our system, service interface documents are available in WSDL format. The tModel structure stores the URL of these documents. Each such structure also has a UUID called the tmodelKey. However, there is no direct hierarchical relationship between this structure and the previous three structures. We now discuss the design principles of the Persistent Object Manager (POM) [11] and explain how it helps us in storing the constraint information in the appropriate format. We also give the advantages of using such a system. Cloudscape TCP/IP JDBC Driver JDBC Driver JDBC Driver POM POM POM Java Application Java Application Java Application Figure 4.5 POM System Architecture

PAGE 51

41 As discussed in Chapter 2, the POM uses an object-relational database system called Cloudscape. This DBMS extends the functionality of a traditional RDBMS by providing a data type to store and process user-defined objects. The main hassle in using such a system is the different goals of object-oriented design and relational database development. As a result, an object-relational chasm is developed and a mapping framework is required to fill in this gap [11]. The POM provides this capability by integrating the Java programming language, JDBC and the Cloudscape DBMS, as shown in Figure 4.5. In order to provide this object-relational mapping, many issues need to be addressed. We give below a brief explanation of each of these issues. Wherever possible, we have tried to include how POM handles that particular issue. 1. Performance: This is one of the major forces that should be taken into consideration. An attempt for storing or retrieving an object will result in at least one access to the underlying database. Enough care has to be taken while designing the mapping strategy so that the number of database calls is minimized. 2. Maintenance Cost: Relational database design tries to eliminate redundancy by using normal forms. However, in order to achieve good performance we have to minimize database accesses. This would involve ignoring the rules of normalization and thus will result in a less maintainable system. The goals of maintenance and performance are contradictory and POM strives to achieve a balance between them. 3. Inheritance: As POM has been designed for use by Java applications, it does not cover the concept of multiple inheritance. Simple inheritance is adequate in many cases, especially in our case of the constraint-based broker. There are various ways of mapping inheritance hierarchies to relational database tables. Some of these approaches are as follows. The first strategy that we consider is that of providing one table per inheritance tree. Thus, a union of all the attributes of all the objects is used as the columns of a single database table. Null values are stored in unused fields. The advantages of this approach are the sufficiency of a single database operation to read or write, a straightforward mapping strategy, and easy formulation of ad hoc queries. The disadvantages are the

PAGE 52

42 inflexibility of the inheritance hierarchy once the mapping is done and poor performance due to heavy traffic on a single table. The second strategy is to map all the attributes occurring in an inheritance path to a single database table. Thus each class is mapped to a different table. This approach still needs a single database operation to read or write. Also, the traffic is evened out and hence performance improves. However, adding or deleting attributes in a super class results in corresponding changes to all derived classes. The base class information is stored in all the derived classes, introducing redundancies. Also, query formulation is difficult. The third strategy is to use Binary Large Objects (BLOBs). This approach provides the advantages of minimal space consumption and simple schema evolution, but it causes a significant overhead for maintenance. Query formulation is also difficult in this case. The POM approach to mapping inheritance is to map each class in an inheritance hierarchy to a separate database table with a super class object identifier (OID) column to link the rows in each derived class table with the corresponding rows in the parent class table. This approach provides a very flexible mapping and has near optimal space consumption. Query formulation is difficult here, too, but this system has a high-level query processor, which takes care of this drawback. 4. Aggregation: In an object-oriented model, we have the concept of container classes. Thus one class can have as an attribute an object of another class. The mapping strategy needs to take care of this scenario also. Again, there are a number of strategies that can be used to take care of this problem. The first strategy is to use single table aggregation. The attributes in the contained class are expanded to become the attributes of the container class. This approach is optimal in terms of performance and object deletion is straightforward. But the object structure becomes inflexible once the tables have been created. The second strategy is foreign key aggregation. The container class is mapped to a table and the contained class is mapped to another table. The container class table stores the OID of the contained class table. Mapping is more flexible and easy to maintain. However, due to the join operation while accessing a container object, performance decreases. The POM approach towards solving this problem is to make use of the serialize data type supported by Cloudscape. Thus, complex data types can be stored as columns of a table. For each container class, POM stores the contained object in its serialized form as one column of the database. This approach has the advantages of the single table approach and also the benefit of easy query

PAGE 53

43 formulation. The disadvantage of this approach is due to serialization, which is a relatively slow process. 5. Application Type: Though POM provides a facility of storing virtually any type of objects in a persistent fashion, there are limitations to the application types that it can support. Applications that require manipulation of complex interrelated objects cannot be supported by this system. CAD applications and CASE tools are some such examples. The object structure that we need to store in a persistent fashion conforms to the type of objects stored by POM. We do not make use of the inheritance concept, but we do use the concept of aggregation in the class structure constructed to store constraint information. POM provides a very effective way of mapping this concept and thus is very useful to us. Also, once the appropriate tables are created to store the constraint objects, any further store operation results in the creation of object instances only and no new tables need to be created. This reduces the load on the database as database accesses are done only for storing a new instance. All these factors make POM a very efficient tool to be used for our system. 4.4 Constraint Satisfaction Processor and Cost-Benefit Evaluation Server As explained in Section 4.2, the service provider gives the constraint information associated with his/her service during the registration process. This information is stored in the Persistent Object Manager to be retrieved during the discovery phase. In this phase, the service broker matches the service requestors constraints with those of the service providers. The provider that best matches the requestor constraints is then returned to the service requestor. In this section, we will describe the algorithm used to match the constraints. As mentioned in Chapter 3, there are different kinds of constraints, such as input constraints, output constraints, service constraints, and operation constraints. All of these form one

PAGE 54

44 type of constraints called the attribute constraints. They specify the properties of a particular attribute. The second type of constraints specifies the properties that must hold among multiple attributes. In other words, this type gives the relationship among the attributes. These are called inter-attribute constraints. In Chapter 3, we gave a brief overview of how the constraint matching process works. Constraint matching by itself is an NP hard problem. The key behind the reduced complexity of our algorithm is its use of interval sets. The value lists of every attribute are first converted into interval sets. For example, the constraint > 10 is converted into the set [10..), and the constraint enumeration {1, 2, 3} is converted into a set of intervals [[1,1], [2,2], [3,3]]. We will now explain the algorithm used for constraint matching. Given two sets of constraints, CS1 and CS2, each with a set of attribute constraints (AC) and a set of inter-attribute constraints (IAC). The algorithm is as follows [4]: 1. First, each AC and IAC set is sorted based on the assigned priority. Constraints denoted as not-negotiable have the highest priority. If no priority is assigned, the order in which the constraints were specified is assumed as the priority order. 2. For each constraint set For each AC in the set The domain values represented as single values, range of values, or an enumeration of values are transformed to a set of intervals. 3. Let ACS1 be the set of attribute constraints in CS1 and ACS2 be the set of attribute constraints in CS2. For each attribute, a, in ACS1 and ACS2 Let ACVa1 be the interval set of a in ACS1 and AVCa2 be the interval set of a in ACS2.

PAGE 55

45 The intersection of ACVa1 and ACVa2 forms the result ACVa. If for some attribute, this set is empty, a value of unsatisfied is returned. Otherwise, we go to step 4. 4. After all attribute constraints are handled in this manner, we generate a combination list. This contains a list of all the valid combinations among the attributes. As no inter-attribute constraints are handled at this time, this list just contains one combination. This is the result of putting all the ACVas of every attribute a together. 5. Let IACS1 and IACS2 be the inter-attribute constraint sets of CS1 and CS2, respectively. For each IAC in IACS1, the IAC is first parsed. For each simple expression, i.e., one that involves one attribute and one value (e.g., x > 10), the expression involving attribute a is transformed into an interval set denoted as ACIa. This set is used to partition the set ACVa generated in step 3. Thus, we get two interval sets. One is the intersection of the sets ACIa and ACVa, i.e., ACVa ACIA. The other set is ACVa [ACVa ACIA]. This latter set may generate two sets. 6. Let SATISFYa be the satisfied interval sets of attribute a. For all attributes, the combination list that satisfied both the attribute and the inter-attribute constraints is generated. Let UNSATISFYa be the unsatisfied interval sets of attribute a. For all attributes, the combination list that does not satisfy the constraints is generated. We now give an example of using the above algorithm to match two constraint sets. Let the two constraint sets be defined as shown in Figure 4.6. Given below is the result generated at every step in the algorithm. Result of Step 1 The two constraint sets are sorted so that attribute A is examined first, followed by attribute B. There is only one inter-attribute constraint, so sorting is not necessary. Result of Step 2: The values for attributes A and B are transformed as follows. CS1: A [1,10], B [[str1], [str2]] CS2: A [2,15], B [[str1], [str2], [str3]]

PAGE 56

46 Constraint Set 1 (CS1): Attribute Constraints: Name Type Keyword Value List Priority A Integer RANGE [1..10] NON NEGOTIABLE B String Enumeration {str1, str2} PRIORITY[3] Inter-Attribute Constraints: Name If Then Priority IAC1 A > 5 B = str2 NON NEGOTIABLE Constraint Set 2 (CS2): Attribute Constraints: Name Type Keyword Value List Priority A Integer RANGE [2..15] NON NEGOTIABLE B String Enumeration {str1, str2, str3 } PRIORITY[3] Inter-Attribute Constraints: Name If Then Priority IAC1 A < 4 B = str1 NON NEGOTIABLE Figure 4.6 Attribute and Inter-Attribute Constraints of two Example Constraint Sets Result of Step 3: The intersection for attributes A and B is: A [[2,10]] B [[str1], [str2]] Result of Step 4: The combination list generated is : Combination 1 [[2,10]] and [[str1], [str2]] Result of Step 5: The interval sets generated due to the two inter-attribute constraints are: A [[2,4), [4,5], (5,10]] B [[str1], [str2]]

PAGE 57

47 Result of Step 6: The combinations generated that satisfy the constraints are: Combination 1 [[2,4)] and [[str1]] Combination 2 [[4,5]] and [[str1], [str2]] Combination 3 [(5,10]] and [[str2]] The combinations generated that do not satisfy the constraints are: Combination 4 [[2,4)] and [[str2]] Combination 5 [(5,10]] and [[str1]] The results returned by the Constraint Satisfaction Processor include all these combinations. This helps the requestor to adhere to his/her own constraints and also to those of the service provider. We will now present the design details of the Cost-Benefit Evaluation Server (CBES). The CBES has been built to support decision-making in collaborative e-business. It has been designed and developed on the extended cost-benefit decision model [14] and includes a set of build-time knowledge specification tools and a run-time evaluation engine [19]. These tools are briefly discussed below. A detailed discussion of CBES [19], however is not presented here. 1. Knowledge Specification: At build-time, CBES allows the service provider to specify his/her elementary criteria for some possible values of the service, operation, input, and output attributes. The provider can specify a preference score in the range of [0..1] that indicates his/her satisfaction with a particular value or ranges of values for each attribute. Since the explicit specification of these scores for all values may be difficult, CBES also provides the facility of interpolating the remaining preference scores once the scores for some key attribute values or value ranges are specified. Also, a service provider may wish to assign a higher priority or score to some specific combinations of attribute values. For such cases, CBES provides the facility of defining a preference score for aggregations of attribute values. CBES supports a wide range of aggregation functions, each of which determines the way preference scores associated with

PAGE 58

48 different subsets of attributes are to be aggregated to produce an aggregated preference score. Cost information associated with some attributes and values, if available, are also entered. 2. Run-time Evaluation Engine: For CBES to be used in our system, it is required that the service providers and the service requestor register their preference scores and cost information in advance. At run time then, the CBES takes the result returned by CSP for each provider and evaluates it against the preference score and cost information given by the service requestor to generate an overall cost-benefit score. The providers service that received the best overall cost-benefit score will be the one selected to perform the service requested by the requestor. There are several modes of operation for CBES. In the exhaustive mode, CBES evaluates the value combinations of the input attributes for all the attributes. In the best mode, CBES evaluates only those combinations for which each individual attribute value range has the highest preference score. In the worst mode, CBES evaluates only those combinations for which each individual attribute value range has the lowest preference score. In the approximate mode, CBES assigns a preference score to each attribute as a whole, based on the different scores assigned to the range of values this attribute can take. The cost-benefit analysis is an optional step during the discovery phase in our system. The service broker may find many service providers that satisfy the service requestors constraints. In that case, if the service providers and the service requestor have their preferences and cost information registered, CBES can be used to evaluate all of them based on the requestors preferences and cost information. Thus, a providers service that is most desirable from the requestors cost-benefit point of view can be selected.

PAGE 59

CHAPTER 5 IMPLEMENTATION DETAILS This chapter is organized into four sections. In Section 5.1, we give the data structures used for our system along with the Java Class definitions. In Section 5.2, we give the details of using the IBM UDDI Business Test Registry and also give an overview of how POM maps our Java object into classes. In Section 5.3, we give the details of using the IBM Web Services Toolkit. In Section 5.4, we give screenshots of a sample scenario. 5.1 Data Structures and Class Definitions As we have explained in Chapter 3, the service provider and the service requestor both use the constraint-based broker for different purposes. The service provider uses our system to register his services with the broker, whereas the service requestor uses it to discover service providers that satisfy his/her service constraints. Even though we have two views of the system, the data structure that we use for constraint specification in both cases is the same; however, we are using a Constraint Satisfaction Processor (developed earlier for automated negotiation purposes), for constraint matching between the service providers and the service requestors constraints. In order to preserve the data structures used by CSP, we map our constraint specification objects to the corresponding constraint specification objects of CSP. There is a constraint specification hierarchy in our system. Each Web service encapsulates many related operations. Each of these operations has input and output 49

PAGE 60

50 parameters. At the highest level, we have constraints that characterize the service itself. Examples of such constraints are constraints on the attributes of service cost, service usage policy, etc. The next level is of constraints that characterize an operation as a whole. Examples of such constraints are constraints on the attributes of operation cost, time required to carry out that particular operation, etc. Then at the lowest level, we have constraints that are specified on the operation parameters. Examples of such constraints include limiting the range of values a particular input parameter can take, enumerating valid input attribute values, etc. Also, there may be constraints as a result of the inter-relationship of these input, output, operation, and service attributes. In order to reflect this hierarchy, we have five Java Objects whose class definitions are given below: 5.1.1 WSConstraint Object This is a high-level object that models the Web service constraint information as a whole. The class definition is shown in Figure 5.1. The variables are as given below: public class WSConstraint implements java.io.Serializable { public String serviceKey; public String interfaceKey; public Hashtable operationConstraintList; public Hashtable serviceConstraintList; public Hashtable interAttributeConstraints; } Figure 5.1 Class Definition of the WSConstraint Object 1. serviceKey: This variable gives the service key of the service for which this particular object is a constraint specification. This is a Universal Unique Identifier (UUID) generated by the UDDI registry at the time the service is registered by the service provider. We use this key to link the service specification in the UDDI registry with the constraint specification in our registry. For the service requestors constraint specifications, we use the same class definition. The serviceKey variable is replaced by the string requestor in this case, since there is no registered service specification in the UDDI registry for the service requestor during the discovery phase.

PAGE 61

51 2. interfaceKey: This variable gives the key of the service interface that this particular service (i.e., the one that we are specifying constraints for) implements. This is also a UUID generated by the UDDI registry when the service interface is first registered. As we explained in Chapter 3, the service requestor finds a suitable interface using the UDDI find mechanism. The key of this interface is then used to retrieve the constraint specifications of those services that implement this particular interface. This step locates the appropriate constraint specifications to match. 3. operationConstraintList: This data structure gives a list of all the operation constraints associated with this service. It is implemented as a hash table with the operation name as the key. The class definition of each operation constraint object is explained in Section 5.1.2. 4. serviceConstraintList: This data structure gives a list of all the service constraints that characterize this service. It is implemented as a hash table with the service key as the lookup key of the hash table. For each service implementation, we can have only one service constraint object. So, there is no real need for a hash table. We have still used a hash table in order to simplify any future changes that may be needed to this structure. The class definition of each service constraint object is explained in Section 5.1.3. 5. interAttributeConstraintList: This data structure gives the inter-attribute constraints among all input, output, operation and service attributes. It is implemented as a hash table with the name as the lookup key. The class definition for each inter-attribute constraint object is explained in Section 5.1.5. 5.1.2 OperationConstraint Object This object models the constraint specification for an entire operation as a whole. The class definition is given in Figure 5.2. It consists of the following variables: public class OperationConstraint implements java.io.Serializable { public String interfaceKey; public String operationName; public Hashtable attributeConstraintList; } Figure 5.2 Class Definition of the OperationConstraint Object 1. interfaceKey: This variable gives the interface key of the service interface that this operation belongs to. Even though this key appears as a variable of the WSConstraint object, which contains this object, it is provided here for future

PAGE 62

52 extensions. A service implementation can implement two interfaces at a time, just as a Java Class can implement two Java Interfaces. In order to distinguish the operations of these different interfaces, the interface key variable has been duplicated here also. 2. operationName: This variable gives the name of the operation for which this object provides the constraint specification. It is the key used to look up this object in the hash table contained in the WSConstraint class. 3. attributeConstraintList: This data structure gives the actual constraint specification for this particular operation. It gives the constraints for input, output and operation attributes of this operation. The class structure used for each attribute constraint object is explained in Section 5.1.4. 5.1.3 ServiceConstraint Object This object gives the constraint specification for service attributes. The class definition is shown in Figure 5.3. It contains the following variables: public class ServiceConstraint implements java.io.Serializable { public String serviceKey; public Hashtable attributeConstraintList; } Figure 5.3 Class Definition of the ServiceConstraint Object 1. serviceKey: This variable gives the service key of the service that this constraint specification belongs to. It is provided here so that ServiceConstraint objects can be shared among higher level WSConstraint objects. 2. atttributeConstraintList: This data structure gives the constraint specification for the service attributes of this particular service. The class structure used for each attribute constraint object is explained in Section 5.1.4. 5.1.4 AttributeConstraint Object This object is used to specify the attribute constraints. It can be used for constraint specification of input, output, operation and service attributes. The class definition is shown in Figure 5.4. It consists of the following variables:

PAGE 63

53 public class AttributeConstraint implements java.io.Serializable { public String name; public String type; public String keyword; public boolean negotiable; public Vector valueList; public int priority; public boolean nomatch; } Figure 5.4 Class Definition of the AttributeConstraint Object 1. name: This variable gives the name of the particular attribute of the service, operation, input or output attribute of which this object is a constraint specification. 2. type: This variable gives the data type of the attribute. The data types can be string, integer, float, date, time, datetime, or duration. 3. keyword: This variable gives the keyword associated with each attribute. The keyword helps in identifying the kind of constraint being specified. The constraints can be specified on a range of values, on an enumeration of values, or on a single value along with comparison operators. So, the keywords can be range, enumeration, =, !=, >, <, >=, and <=. 4. valueList: This variable gives the list of values that a particular attribute can take. The form of this list depends on the keyword specified. If the keyword is range, this list, implemented as an object of the class java.util.Vector, contains two elements that denote the start and the end of the range, respectively. If the keyword is enumeration, this list contains all the valid attribute values. If the keyword is one of the six comparison operators, the list just contains a single value. 5. negotiable: This variable determines whether a particular attribute constraint is flexible or not. If a constraint is flagged as non-negotiable and it is not satisfied, constraint matching terminates and the Constraint Satisfaction Processor reports a constraint mismatch. 6. priority: In case an attribute constraint is negotiable, this variable determines its priority, and hence its order of evaluation. As stated above, non-negotiable attributes are evaluated first followed by attributes in the order of decreasing priority. 7. nomatch: This variable is used to differentiate those attributes for which there is a constraint specification from those for which there is none. When specifying constraints for an operation, for example, a service provider or a service requestor

PAGE 64

54 may not want to specify constraints on some attributes. This variable is set to true in these cases. The Constraint Satisfaction Processor tries to match all attributes by default. But when there are no constraints for a particular attribute, the value list variable is empty. Thus, there is no need to match it with the constraint of the other party. Only those attributes for which the nomatch variable value is false, are matched. 5.1.5 InterAttributeConstraint Object This object is used to specify the constraints that specify the relationship among different attributes of the service. For example, we can have an inter-attribute constraint as, if x > 50 then y > 70. Each inter-attribute constraint has an if part and a then part. In order to model constraints which do not explicitly have such an implication structure (for example, x + y >z), we can set the if part to true and state the remaining constraint in the then part. The class definition for this object is given in Figure 5.5. The variables contained in this object are as follows: public class InterAttributeConstraint implements java.io.Serializable { public String name, antecedence, consequence; public int priority; public boolean negotiable; } Figure 5.5 Class Definition of the InterAttributeConstraint Object 1. name: This variable assigns a unique name to the inter-attribute constraint. This name is used as the key to lookup this object and thus all inter-attribute constraints within an object must have unique names. 2. antecedence: This variable specifies the if part of an inter-attribute constraint. It is a boolean expression specified in the Disjunctive Normal Form. 3. consequence: This variable specifies the then part of an inter-attribute constraint. Like the antecedence, this is also a Boolean expression specified in the Disjunctive Normal Form. However, in many cases, the consequence is generally one predicate that must hold if many other predicates hold. 4. negotiable: This variable determines if an inter-attribute constraint is negotiable or not. Non-negotiable constraints are evaluated first. If a non-negotiable

PAGE 65

55 constraint is violated, the Constraint Satisfaction Processor terminates the evaluation process and reports a constraint mismatch. 5. priority: This variable gives the priority assigned to the inter-attribute constraint during constraint specification. Inter-attribute constraints are always evaluated in priority order. Instances of the Java classes WSConstraint, OperationConstraint and ServiceConstraint are used to store the constraint information. However, CSP uses a slightly different constraint object structure for actual matching. We match constraints specified by the service provider and the service requestor for a particular operation. At run time, we retrieve the WSConstraint object belonging to each service provider, and extract the required OperationConstraint object and the ServiceConstraint object. These objects are then mapped to the Constraint object structure used by CSP. This structure is shown in Figure 5.6. The variables used are similar to those of the OperationConstraint and WSConstraint objects and hence are not repeated here. public class Constraint implements java.io.Serializable { public Hashtable attributeConstraintList; public Hashtable interAttributeConstraints; } Figure 5.6 Class Definition of the Constraint Object We now describe the structure of the result returned. The result returned by CSP contains the class structure shown in Figure 5.7. The variables are as follows: 1. satisfied: This variable determines whether the constraint matching process was successful or not. Details such as what attributes were violated, if any, what combinations of values are valid, etc., are determined by the other variables. 2. myOwnViolated: This variable determines which constraint was violated. Traditionally, CSP denotes the two input constraint objects as MyConstraint and YourConstraint. In our system, MyConstraint is the constraint object of the service provider and YourConstraint is the constraint object of the service

PAGE 66

56 requestor. If the variable satisfied were set to false, a true value of myOwnViolated would mean that the provider constraint was violated, and a false value of myOwnViolated would mean that the requestor constraint was violated. public class CSPResult { boolean satisfied; boolean myOwnViolated; boolean attributeViolated; boolean iacViolated; Vector violatedConstraint; Vector violatedList; Vector ISList; Vector combinationList; } Figure 5.7 Class Definition of the CSPResult Object 3. attributeViolated: This variable determines whether any of the attribute constraints were violated. 4. iacViolated: This variable determines whether any of the inter-attribute constraints were violated. 5. violatedConstraint: This data structure gives us the list of violated attributes, if any. It is implemented as an object of the class java.util.Vector [8]. 6. violatedList: This data structure gives us the list of violated inter-attribute constraints, if any. It is also implemented as an object of the class java.util.Vector [8]. 7. ISList: This data structure gives us the list of the interval sets for each attribute that satisfy both the attribute constraint objects. Thus, all possible permissible ranges for each attribute are contained in this list. 8. combinationList: This data structure gives us the combinations of values which when used do not violate both the inter-attribute constraint objects. While invoking a service, the service requestor must not only check that the attribute values sent conform with the ISList, but must also check with the combinationList to see if a valid combination is being used for invocation. This concludes the description of the data structures used in the constraint-based broker system.

PAGE 67

57 5.2 IBM UDDI v2.0 Business Test Registry and Persistent Object Manager We use the IBM UDDI Version 2.0 Business Test Registry to register the service specifications. This registry implements most of the features provided by UDDI v2.0. In order to familiarize the general e-business community with UDDI, IBM has made this registry accessible over the worldwide web. As this User Interface is already well developed, we have used it in our system instead of developing a similar one. During the registration phase, we use the IBM UDDI Version 2.0 Business Test Registry to register UDDI-specific service information. When registering a service for the first time, the UDDI registry generates a service key to be used for uniquely identifying the service later. This service key is returned to the service provider. The constraint-based broker then asks the service provider to enter this service key, along with the service interface key of the service interface that this service implements and the URL of the WSDL document describing the service. Once that is done, the information such as service and operation attributes, input and output attributes of each operation are retrieved and the service provider uses the GUI to specify constraint information. During the discovery phase, the service requestor first uses the UDDI registry to find the service interface that conforms to his/her request. The Test Registry provides several ways of finding this information. The service requestor can enter the name of the interface, or the category information, etc., to locate the appropriate service interface. Once this is done, the requestor uses our GUI to specify the interface key and the location of the extended WSDL document describing the interface. This document contains the names of operation and service attributes in addition to the normal WSDL elements, and, hence, is an extended WSDL document. The requestor then uses the GUI to specify his/her constraint information. This information is then matched with that of all the

PAGE 68

58 registered service providers who implement the interface. The match result determines the best provider for a particular request. POM maps the constraint objects into a relational table. We show the create table command for the WSConstraint object in Figure 5.8. Similar tables are created to store the other objects. Each table is assigned a primary key column when it is created. This is called the Object Identifier (OID) column. This key can be used to update or delete the object once created. The WSConstraint object contains three hash tables. These hash tables are not SQL datatypes. A new table is created for every non-SQL data type [11]. Another table called the Foreign Keys table is created to link the objects in the original table with the ones created in the new table. CREATE TABLE WSConstraint ( OID INTEGER, serviceKey VARCHAR(255), interfaceKey VARCHAR(255), operationConstraintList SERIALIZE(java.util.Hashtable), serviceConstraintList SERIALIZE(java.util.Hashtable), interAttributeConstraints SERIALIZE(java.util.Hashtable), PRIMARY KEY(oid) ) Figure 5.8 Create Table Command of the Persistent Object Manager 5.3 IBM Web Services Toolkit Web services are programmatically accessible over the Internet. It therefore follows that the registration and discovery of such services must also be programmatically accessible. The IBM Web Services Toolkit [7] provides this facility. This toolkit has methods using which a service provider can register his/her service with the UDDI registry given the WSDL document describing the service as input. Similarly,

PAGE 69

59 if the appropriate criteria are given, a service requestor can find a suitable service provider. We have extended these methods to allow programmatic constraint registration and constraint matching. The service provider can give an extended WSDL document, which contains both the UDDI information and the constraint information as input to the method used for registration. The UDDI information will be registered with the UDDI registry, and the constraint information will be registered with POM. Similarly, during the discovery phase, the service requestor can use the find methods from the Toolkit to find an interface. The constraint object and the interface key can then be provided as command-line input to our extended find method. The result of the constraint match will then be returned to the requestor. 5.4 Sample Scenario In this section, we illustrate the entire constraint specification and matching process with screenshots. We will use the constraint specifications of the service requestor and the service provider given in Chapter 3 for this purpose. These specifications have been reproduced in Figures 5.9 and 5.10 for completeness. SERVICE: E-AUCTION ATTRIBUTE_CONSTRAINT: Svc_basecost Float EQUAL 4 OPERATION: BUY ATTRIBUTE_CONSTRAINT: Buy_in_item String ENUM {Computer} Buy_in_price Float RANGE [200.00..5000.00] Buy_out_orderno String Buy_op_cost Float LESSERTHAN 3 INTERATTRIBUTE_CONSTRAINT: IC1 Buy_in_price>=2500.00 Implies Buy_op_cost<=2 Figure 5.9 Constraint Specification of a Web Service Requestor

PAGE 70

60 SERVICE: E-AUCTION ATTRIBUTE_CONSTRAINT: Svc_basecost Float EQUAL 4 OPERATION: BUY ATTRIBUTE_CONSTRAINT: Buy_in_item String ENUM {Printer, Computer, Scanner} Buy_in_price Float RANGE [100.00..5000.00] Buy_out_orderno String Buy_op_cost Float LESSEQUAL 3 OPERATION: SELL ATTRIBUTE_CONSTRAINT: Sell_in_item String ENUM {Printer, Computer, Scanner} Sell_in_pricequote Float RANGE [100.00..5000.00] Sell_out_orderno String Sell_op_cost Float EQUAL 3 OPERATION:CHECKSTATUS ATTRIBUTE_CONSTRAINT: Checkstatus_in_orderno String Checkstatus_out_status String ENUM {Accepted, Rejected} Checkstatus_op_cost Float EQUAL 3 INTERATTRIBUTE_CONSTRAINT: IC1 Buy_in_item= Computer Implies Buy_in_price>800 IC2 Buy_in_price>=3000.00 Implies Buy_op_cost = 1 Figure 5.10 Constraint Specification of a Web Service Provider Though we have not specified the priority and negotiation information in Chapter 3, we have included it in the screenshots. We will describe the GUI for the registration phase in Section 5.4.1, and present the GUI for the discovery phase with constraint match results in Section 5.4.2. 5.4.1 Registration We present step-by-step screenshots to show service registration by the service provider. This registration process is the same for any kind of service provider. Before any process can be started, the service provider is given the steps necessary to complete the registration.

PAGE 71

61 As shown in Figure 5.11, the service provider uses the IBM Test Registry to register his service with the UDDI registry in the first step. In the second step, the provider gives the necessary service information to the constraint-based broker, and in the third step the service provider specifies constraint information and obtains an extended WSDL document containing the service and constraint information. Figure 5.11 Screenshot Showing all the Steps Necessary in the Registration Process In Figure 5.12, we see the use of two separate frames for the Graphical User Interface (GUI) of the constraint-based broker. This interface allows the user to access the UDDI registry and our registry in a single session. The service provider uses the GUI on the left hand side to register service information with the UDDI registry. The provider then uses the GUI on the right side to specify the service key, the service interface key and the location of the WSDL document describing the service implementation as shown. Thus with the help of this GUI, the service provider registers service information with the UDDI registry and constraint information with the UF registry.

PAGE 72

62 Figure 5.12 Screenshot Showing the Service Provider Entering Service Information Figure 5.13 Screenshot Showing the Service Provider Selecting an Operation The WSDL document contains a reference to the service interface document. The broker extracts the input, output, operation and service attribute information from both of

PAGE 73

63 these documents. Constraints are specified one operation at a time. The service provider is then asked to choose the operation for which he/she wants to specify constraint information. For the E-Auction service discussed in Chapter 3, we have three operations: buy, sell and checkstatus. This list of operations is shown in Figure 5.13. On selecting the appropriate operation, the service provider can specify constraints on each attribute. As shown in Figure 5.14, the service provider gives the keyword, valuelist and priority information for the input attributes item and price and the operation attribute cost. The output attribute orderno has no constraints, and the valuelist and priority information are therefore left blank. Figure 5.14 Screenshot Showing the Specification of Attribute Constraints Inter-attribute constraints are also specified at this time, as shown in Fig 5.15. The service provider specifies an inter-attribute constraint stating that if the item to be bought

PAGE 74

64 is a computer, the price must be greater than $800.00. Each input, output or operation constraint is assigned a priority value and a negotiable/non-negotiable value. After the service provider specifies constraints for all operations, service attribute constraints are specified as shown in Figure 5.16. Figure 5.15 Screenshot Showing the Specification of Inter-Attribute Constraints Figure 5.16 Screenshot Showing the Specification of Service Attribute Constraints After specifying service constraints, the registration process is completed. An extended WSDL document containing the constraint information appended to the initial

PAGE 75

65 service description information is generated. A portion of this extended document is shown in Figure 5.17. Here, we show the constraints tag appended as the last child of the definitions tag. This tag has a number of constraint tags as its children. Each constraint tag gives the constraint specification of each operation. This is specified by an operation_constraint tag. This tag has a number of input_constraint, output_constraint, and operation_constraint tags as shown. Each such tag describes the name, type, keyword, etc. information about that particular constraint. Figure 5.17 Screenshot Showing the Extended WSDL Document This concludes the registration phase.

PAGE 76

66 5.4.2 Discovery During this phase, the service requestor first uses the UDDI mechanism to locate a suitable service interface. The service requestor then enters the interface information such as the interface key and the location of the interface document, as shown in Figure 5.18. We see a similar Graphical User Interface as that used for the registration phase. On the left side is the Graphical User Interface for the UDDI registry, and on the right side we have Graphical User Interface for the constraint-based broker. Figure 5.18 Screenshot Showing the Service Requestor Entering Interface Information The service requestor uses similar steps as the service provider to specify the attribute and inter-attribute constraints for the desired operation. The attribute and inter-attribute constraints are as specified in Figure 5.10. When the service requestor submits his request, the interface key is used to retrieve constraint specifications of all service

PAGE 77

67 providers who implement that particular interface. After the constraint matching is done, the service requestor gets back the service key and the service access point of the service that best matches his/her constraints. This is shown in Figure 5.19. The requestor can access a detailed list that gives the satisfied value ranges for all the attributes and all valid combinations of these ranges by clicking on the More Information button. He/she can start a new session by clicking on the Start next session button. Figure 5.19 Screenshot Showing the Result of the Constraint Match The detailed result is shown in Figure 5.20. We see that the input attribute item is restricted to the value Computer and the input attribute price is restricted to a range of [200.00..5000.00]. The output attribute orderno has no restrictions on its value. The operation attribute cost is restricted to values less than 3. The valid combinations are generated keeping the inter-attribute constraints of both the service provider and the requestor in mind.

PAGE 78

68 Figure 5.20 Screenshot Showing the Detailed Result of the Satisfied Constraint Match Using the information obtained by constraint matching, the service requestor can invoke the service using valid parameters. This will assure to a greater extent than before that the service will not fail. This concludes the discovery phase. The service requestor can now use the service key information to learn more about the service from the UDDI registry, and use the access point to invoke the service. Thus constraint matching guarantees that a time-consuming service will not be invoked without producing meaningful results. This saves the service requestors resources to a large extent.

PAGE 79

CHAPTER 6 CONCLUSION AND FUTURE WORK 6.1 Summary Adding constraints to the specifications of Web services and Web service requests captures more accurately the limitations of services registered by service providers and the requirements of service requestors. As a result, it also allows the service broker to better select the proper providers that satisfy the requestors requirements. Without constraint specification and processing capabilities, a service broker may identify a service provider for a request that cannot produce useful information to the requestor. A time-consuming service operation can be invoked without producing the desirable result due to a mismatch of provider and requestor constraints. In this work, we have extended WSDL to include constraint specifications in both service specifications and service requests. We have also described the Constraint-based Requirement Specification Language by giving examples, the architecture of a Constraint-based Broker, the constraint matching technique, and the implementation details about the broker with a sample scenario. We believe that the constraint-based brokering service is a significant improvement over the existing implementations of the UDDI service registry. 6.2 Limitations and Future Work This is our first venture of integrating our constraint satisfaction processor, which was developed for an automated negotiation system, and a persistent store developed for an Event Server, with the UDDI registry that IBM implemented for publishing and 69

PAGE 80

70 discovery of Web services. Due to the different initial objectives of these systems, integrating them involved a nontrivial mapping process. The integrated system can, however, be extended to make it more complete as follows. One extension can be to tightly integrate the components of these two registries. Since we used a publicly available UDDI registry, we do not have access to the source code and hence are not able to modify it accordingly. Instead, we used another registry (POM), to store constraint information. The system appears as one to the user (either the service provider or service requestor), but the registration and the discovery phases have to be separately handled when using the Graphical User Interface. The user must first register to the IBM UDDI version 2.0 Business Test Registry with UDDI information, and then use our GUI to register constraint information. However, if the user submits an extended WSDL document, the registration is automatically done in both the registries and this difference is not noticed. Another significant advancement can be achieved by handling constraints that generate an exhaustive number of combinations. For example, with a constraint of type A+B>100, consider that A and B both can take values from the range [1..100]. For the value for A, we have satisfying values of B as [100]. For the value for A we have the satisfying values of B as [99..100]. Thus, there are a total of 100 combinations. These constraints are checked better by the provider stub, but can be incorporated at the broker site for better matching. Our future work is on the integration of the Constraint-based Broker with an Event-Trigger-Rule Server to perform event subscription, event filtering and notification, and rule processing in the Web service infrastructure to support collaborative e-business,

PAGE 81

71 e-government, and biomedical research and applications. We are also exploring the use of the Constraint-based Broker to support a semi-automated approach to discover composite Web services.

PAGE 82

APPENDIX A SCHEMA OF THE EXTENDED WSDL DOCUMENT This type is extended by component types to allow attributes from other namespaces to be added. 72

PAGE 83

73
to support extensibility elements

PAGE 84

74


PAGE 85

75


PAGE 86

76


PAGE 87

77


PAGE 88

78


PAGE 89

79


PAGE 90

80

PAGE 91

81
element name="name" type="string"/>

PAGE 92

82


PAGE 93

83


PAGE 94

APPENDIX B BNF SYNTAX OF OBJECT-ORIENTED CONSTRAINT SPECIFICATION LANGUAGE (OOCSL) entity ::= ENTITY IDENTIFIER BL ATTRIBUTE_CONSTRAINT COLON ac_list INTER_ATTRIBUTE_CONSTRAINT COLON iac_list BR ; ac_list ::= ac_list ac | ; ac ::= path att_type att_cons priority ; att_type ::= STRINGTYPE | INTEGERTYPE | FLOATTYPE | BOOLEANTYPE | DURATIONTYPE | DATETIMETYPE | TIMETYPE | DATETYPE ; att_cons ::= ENUMERATION LBRACKET value_list RBRACKET | ANY | EQUAL val | LESSTHAN val | LESSEQUAL val | GREATERTHAN val | GREATEREQUAL val | NOTEQUAL val | DERIVED | RANGE LBRACKET numeric DOT DOT numeric RBRACKET ; value_list ::= str_val_list | int_val_list | real_val_list | bool_val_list ; str_val_list ::= STRING 84

PAGE 95

85 |STRING COMMA str_val_list ; int_val_list ::= INTEGER |INTEGER COMMA int_val_list ; real_val_list ::= FLOAT |FLOAT COMMA real_val_list ; bool_val_list ::= YES | NO numeric ::= INTEGER | FLOAT ; val ::= numeric | STRING ; priority ::= NONNEGOTIABLE | PRIORITY LBRACKET INTEGER RBRACKET ; iac_list ::= iac_list iac | ; iac ::= IDENTIFIER constraint IMPLIES constraint priority ; constraint ::= bool_or | ; bool_or ::= bool_or OR bool_and | bool_and ; bool_and ::= bool_and AND bool_compare | bool_compare ; bool_compare ::= expr EQ expr | expr NOTEQ expr

PAGE 96

86 | expr LESS expr | expr LESSEQ expr | expr GREATER expr | expr GREATEREQ expr | expr ; expr ::= expr PLUS term | expr MINUS term | term ; term ::= term TIMES factor | term DIVIDE factor | factor ; factor ::= LPAREN bool_or RPAREN | path | val | TRUE | FALSE ; path ::= IDENTIFIER | IDENTIFIER DOT path ;

PAGE 97

LIST OF REFERENCES [1] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen, S. Thatte, D. Winer, Simple Object Access Protocol (SOAP) 1.1, http://www.w3.org/TR/SOAP, May 2000. Accessed on November 20, 2001. [2] P. Brittenham, F. Curbera, D. Ehnebuske, S. Graham, Understanding WSDL in a UDDI Registry, http:// www-106.ibm.com /developerworks /webservices /library/ws-wsdl/, September 2001. Accessed on January 10, 2002. [3] E. Christensen, F. Curbera, G. Meredith, S. Weerawarna, Web Services Description Language (WSDL) 1.1, http://www.w3.org/TR/wsdl, March 2001. Accessed on November 20, 2001. [4] C. Huang, A Web-based Negotiation Server for Supporting Electronic Commerce, Ph.D. Dissertation, Department of Computer and Information Science and Engineering, University of Florida, 2000. [5] IBM DeveloperWorks, Web Services Architecture Overview, http://www-106.ibm.com/developerworks/webservices/library/w-ovr/, September 2000. Accessed on October 10, 2001. [6] IBM UDDI Business Test Registry, https://uddi.ibm.com/testregistry/ registry.html. Accessed on February 10, 2002. [7] IBM Web Services Toolkit, http://www.alphaworks.ibm.com/tech /webservicestoolkit, April 2002. Accessed on April 25, 2002 [8] Java 2 Platform Standard Edition, v 1.3.1, API Specification http://java.sun.com/j2se/1.3/docs/api/. Accessed on March 3, 2002 [9] F. Leymann, Web Services Flow Language (WSFL 1.0), http:// www-3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf, May 2001. Accessed on November 25, 2002 [10] Y. Liu, F. Yu, S. Y. W. Su, and H. Lam, A Cost-Benefit Evaluation Server for Decision Support in E-business, to appear in Journal of Decision Support Systems and Electronic Commerce, 2002. 87

PAGE 98

88 [11] A. Shenoy, A Persistent Object Manager for Java Applications, M.S. Thesis, Department of Computer and Information Science and Engineering, University of Florida, 2001. [12] B. Sleeper, Defining Web Services, http:// www.stencilgroup.com /ideas_scope_200106wsdefined.html, June 2001. Accessed on February 2, 2002. [13] B. Sleeper, Why UDDI will succeed quietly, http:// www.stencilgroup.com /ideas_scope_200104uddi.pdf, April 2001. Accessed on February 14. 2002. [14] S. Y. W. Su, J. Dujmovic, D. S. Batory, S. B. Navathe, and R. Elnicki, A Cost-Benefit Decision Model: Analysis, Comparison, and Selection of Database Management Systems, ACM Transactions on Database Systems, Vol. 12, No. 3, pp. 472-520, Sept. 1987. [15] S. Y. W. Su, C. Huang, J. Hammer, Y. Huang, H. Li, L. Wang, Y. Liu, C. Pluempitiwiriyawej, M. Lee, and H. Lam, An Internet-based Negotiation Server for E-Commerce, VLDB Journal, Vol. 10, No. 1, pp. 72-90, August 2001. [16] UDDI.org, UDDI Executive White Paper, http://www.uddi.org/pubs/ UDDI_Executive_White_Paper.pdf, November 2001. Accessed on March 15, 2002. [17] UDDI.org, UDDI version 2.03 Data Structure Reference, http://www.uddi.org/pubs/DataStructure-V2.03-Published-20020719.pdf, July 2002. Accessed on August 10, 2002. [18] UDDI.org, UDDI version 2.04 API Published Specification, http://www.uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf, July 2002. Accessed on August 25, 2002. [19] F. Yu, A Cost-Benefit Evaluation Server for Supporting General Decision-making, M.S. Thesis, Department of Computer and Information Science and Engineering, University of Florida, 2001.

PAGE 99

BIOGRAPHICAL SKETCH Seema Degwekar was born in Thane, India, on November 10, 1978. She received her Bachelor in Computer Engineering degree from Vivekanand Education Societys Institute of Technology, affiliated with the Mumbai University, in June 2000. She stood eighth in the University in the Final Undergraduate Examination among approximately 2000 students. She joined the CISE graduate program at the University of Florida in August 2000. She worked at the Database Research and Development Center from August 2001. She graduated in December 2002 with a Master of Science degree. While at the University of Florida, she worked as a teaching assistant and also taught an undergraduate course for two semesters. Her research interests include web databases, query processing, and heterogeneous database systems. 89


Permanent Link: http://ufdc.ufl.edu/UFE0000521/00001

Material Information

Title: Constraint-based brokering for publishing and discovery of web services
Physical Description: Mixed Material
Creator: Degwekar, Seema ( Author, Primary )
Publication Date: 2002
Copyright Date: 2002

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000521:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000521/00001

Material Information

Title: Constraint-based brokering for publishing and discovery of web services
Physical Description: Mixed Material
Creator: Degwekar, Seema ( Author, Primary )
Publication Date: 2002
Copyright Date: 2002

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000521:00001


This item has the following downloads:


Full Text











CONSTRAINT-BASED BROKERING FOR PUBLISHING AND DISCOVERY OF
WEB SERVICES















By

SEEMA DEGWEKAR


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2002




























Copyright 2002

by

Seema Degwekar




























To my parents, Sachin and Nikhil















ACKNOWLEDGMENTS

I would like to thank my advisors, Dr. Stanley Y. W. Su and Dr. Herman Lam, for

their invaluable and timely guidance throughout this project. It is due to their incessant

efforts and unlimited patience that I have been able to complete this thesis. They have

been and will always be a source of inspiration for me in whatever task I undertake.

I would also like to thank Dr. Stephen Thebaut for kindly agreeing to be on my

supervisory committee. It has been a great experience to work with all my project

colleagues in the DB center. Special thanks are due to Ms. Sharon Grant for making the

Database Research Center a great place to work.

Finally, this thesis would not have been possible without a strong support on the

personal front. I am extremely thankful to my parents for their constant guidance and

encouragement. I am also very grateful to my friends Nikhil, Naren, Nandhini, Akhil and

Kaumudi for being my family here in Gainesville.
















TABLE OF CONTENTS
page

A CK N O W LED G M EN T S .............. ............................... ............................................... iv

LIST OF FIGURE S.......... ........................................ .. ................vii

A B S T R A C T ............... ............................ ................................................... ix

CHAPTER

1 IN TR OD U CTION .................. .............. ...................... .............. ............. 1

1.1 W eb Services A n O verview ............................................................................ 2
1.2 Universal Description, Discovery and Integration (UDDI) An Overview ............ 5
1.3 T he P problem Statem ent ............................................................................. ... ........ 6
1.4 Goal of Thesis and the Intended Contribution .................................................... 7
1.5 O organization of Thesis .................................................... ... .. ........ ..

2 RELATED RESEARCH AND TECHNOLOGIES....................................................... 9

2 .1 U D D I ...................................... ....................................... ............... 9
2 .2 W S D L ............... ................................................................................ ........ ...... 1 1
2 .3 S O A P ................... .................................................................. 1 3
2.4 P ersistent O bject M manager ................................................................ ............... ... 13
2.5 Constraint Satisfaction Processor and Cost-Benefit Evaluation Server................ 14
2.5.1 Constraint Satisfaction Processor............................................................... 14
2.5.2 Cost-Benefit Evaluation Server .......................................... ............. 15

3 CON STRAINT-BASED BROKERING .............................................. ... ................. 17

3 .1 W eb Service C on straints ................................................................................ 17
3.2 Constraint Specification Language .................... .................................... 19
3.3 C onstraint M watching ............................................................... .. 2 1
3.4 Extending W SD L .................. .............................. .. .. .......... .............. .. 25

4 DESIGN OF THE CONSTRAINT-BASED BROKER ............................................. 32

4 .1 Sy stem A architecture ......... ..... ................................................ .................... 32
4.2 Publish and D discovery Coordinators ........................ ................. ..... ............ 33
4.2.1 Information Flow during Publishing a Web Service............................ 33
4.2.2 Information Flow during Discovering a Web Service ............................35









4.3 U D D I and U F R egistries ................................................................................. ... 37
4.4 Constraint Satisfaction Processor and Cost-Benefit Evaluation Server.................. 43

5 IMPLEMENTATION DETAILS .............. ......................................................... 49

5.1 Data Structures and Class Definitions.................................................................. 49
5.1.1 W SC onstraint O bject......................................... ............... .............. 50
5.1.2 OperationConstraint Object........................................ ...... .... .......... 51
5.1.3 ServiceC onstraint O bject..................................................... ... ................. 52
5.1.4 A ttributeC onstraint O bject ...................................... .............................. .. 52
5.1.5 InterAttributeConstraint Object................................................. ................. 54
5.2 IBM UDDI v2.0 Business Test Registry and Persistent Object Manager ............. 57
5.3 IBM W eb Services Toolkit ....................... .............................. ............ .............. 58
5.4 Sample Scenario.............................................. 59
5.4.1 R registration ....................................... ......... 60
5.4.2 D discovery ................................................... .......................... ....... 66

6 CONCLU SION AND FUTURE W ORK ................................................. .................... 69

6 .1 Sum m ary ......................................................... ........... ... ......... ...... 69
6.2 L im stations and Future W ork ......................................................................... ... 69

APPENDIX

A SCHEMA OF THE EXTENDED WSDL DOCUMENT............................................ 72

B BNF SYNTAX OF OBJECT-ORIENTED CONSTRAINT SPECIFICATION
L A N G U A G E (O O C SL ) ................................................................... ......................... 84

LIST O F R EFER EN CE S ..................................................... ................................. 87

BIOGRAPHICAL SKETCH ................. .......... ............................................. 89









LIST OF FIGURES


Figure pge

1.1 The W eb Services Technology Stack........................... .......... .... .............. 3

1.2 The W eb Services Architecture...................... ...... ............................. 4

1.3 The U D D I Technology Stack............................................ ................................ 5

2 .1 T he U D D I B u siness R egistry ...................................................................................... 10

3.1 Constraint Specification of an Example Web Service ............................................ 20

3.2 Constraint Specification of a Web Service Provider....................................... 23

3.3 Constraint Specification of a Web Service Requestor ...................................... 24

3.4 Constraint Matching Result between Provider 1 and Requestor............................ 24

3.5 Constraint Matching Result between Provider 2 and Requestor ............................. 25

3.6 Extended Service Interface Document for an Example Web Service..................... 28

3.7 Extended Service Implementation Document for an Example Web Service............ 31

4.1 System A architecture ........... .. .......................... ............... .. 32

4.2 Information Flow During the Registration Process......................................... 34

4.3 Information Flow During the Discovery Process. A) First Phase............................ 36

4.3 Information Flow During the Discovery Process. B) Second Phase....................... 36

4.4 UDDI Data Structures and their Inter-relationship .............................................. 39

4 .5 P O M Sy stem A architecture ........................................ ............................................ 40

4.6 Attribute and Inter-Attribute Constraints of two Example Constraint Sets .............. 46

5.1 Class Definition of the WSConstraint Object........................................................ 50

5.2 Class Definition of the OperationConstraint Object............................... ............... 51

5.3 Class Definition of the ServiceConstraint Object ............................................... 52

5.4 Class Definition of the AttributeConstraint Object............... ...... ............... .. 53

5.5 Class Definition of the InterAttributeConstraint Object.................... ............ 54









5.6 Class Definition of the Constraint Object ......................................... .............. 55

5.7 Class Definition of the CSPResult Object........................................... ................ 56

5.8 Create Table Command of the Persistent Object Manager............... .................... 58

5.9 Constraint Specification of a W eb Service Requestor .............................................. 59

5.10 Constraint Specification of a Web Service Provider................................. 60

5.11 Screenshot Showing all the Steps Necessary in the Registration Process .............. 61

5.12 Screenshot Showing the Service Provider Entering Service Information............... 62

5.13 Screenshot Showing the Service Provider Selecting an Operation....................... 62

5.14 Screenshot Showing the Specification of Attribute Constraints............................ 63

5.15 Screenshot Showing the Specification of Inter-Attribute Constraints .................... 64

5.16 Screenshot Showing the Specification of Service Attribute Constraints................ 64

5.17 Screenshot Showing the Extended WSDL Document.................... ........ ........ 65

5.18 Screenshot Showing the Service Requestor Entering Interface Information.......... 66

5.19 Screenshot Showing the Result of the Constraint Match...................................... 67

5.20 Screenshot Showing the Detailed Result of the Satisfied Constraint Match ............ 68















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

CONSTRAINT-BASED BROKERING FOR PUBLISHING AND DISCOVERY OF
WEB SERVICES

By

Seema Degwekar

December 2002


Chair: Dr. Stanley Y. W. Su
Cochair: Dr. Herman Lam
Major Department: Computer and Information Science and Engineering

As e-business systems gain rapid popularity, the current focus is on effective and

efficient sharing of not only data but also application systems. Traditional system

architectures incorporate tight coupling among distributed components and are thus

inflexible. The current trend in application development is moving away from tightly

coupled systems towards systems of loosely coupled, dynamically bound components.

Systems built with this principle will dominate the next generation of e-business systems.

The Web service model advocates the principle of creating dynamic, loosely

coupled systems based on published services over the Internet. The fundamental notion is

that everything is a service and APIs are published to invoke the service, thereby hiding

its implementation details. Thus, application system sharing is achieved through service

invocation. The model describes three roles and three operations to define the interactions

among these roles. The role of a service provider is to define the sharable functionality of









an application as a Web service. The role of a service requestor is to use Web services to

accomplish his/her tasks. Service providers publish their Web services to the third role, a

service registry, which resides at a well-known network site. Using the service registry,

the service requestorfinds the appropriate provider and then dynamically binds the

request to the service of the provider.

Any service is naturally constrained by factors such as service duration, service

cost, input and output data requirements, etc. If these constraints are not specified

explicitly, a service requestor may unknowingly submit an illegal parameter causing the

request to fail or activate a time-consuming service without getting useful information in

return. However, if both the service provider and the service requestor are able to specify

their own constraints, the service registry can match them and select the provider that

best matches a particular request. The UDDI Project is a platform-independent, open

framework for publishing and discovery of Web services. There are some publicly

available implementations of the service registry based on UDDI; however, these

implementations do not support constraint specification and constraint matching.

In this work, we extend the functionality of the service registry to include

constraint specification and constraint matching. We describe the components developed

to perform constraint processing and integrate them with an existing UDDI-enabled

broker to develop a constraint-based broker. We also extend the Web Services

Description Language (WSDL) to allow the specification of constraints in WSDL

documents. The data structures and algorithms used in constraint processing are

described in this thesis.














CHAPTER 1
INTRODUCTION

With e-business systems gaining rapid popularity, organizations are focusing on

effective and efficient sharing of not only data but also application systems. Traditional

system architectures incorporate tight coupling among distributed system components.

Such systems are sensitive to change. A small number of changes may be manageable,

but as the scale and rate of change increase, traditional systems are likely to break down.

We therefore need a flexible architecture capable of handling this change.

Meanwhile, the current trend in application development is shifting away from the

traditional tightly coupled system structure to a loosely coupled one. Also, more and

more applications are being built keeping a component-based architecture in mind.

Furthermore, there is a growing tendency towards sharing these applications in an

efficient and effective manner. The principles of flexible architecture, loosely coupled

systems, and component-based systems will govern the next generation of e-business

systems.

The Web service framework has put forward an architecture based chiefly on

these principles. The main focus is flexibility. The framework describes no single

implementation but instead puts forward the concept of just-in-time integration. The

system components are services that encapsulate discrete functionality. Each service

publishes a communication API that is used for its invocation. The underlying service

implementation is encapsulated and is therefore very flexible.









In order to make this system work, we need a platform-independent framework to

describe and discover services. The Universal Description, Discovery and Integration

(UDDI) project is aimed at creating such a framework. Both the Web service and the

UDDI technologies form a core part of our research. We now give a brief overview of

each of them.

1.1 Web Services An Overview

Web services can be defined as loosely coupled reusable software components

that together perform specific tasks and are accessible via programs over a network [12].

As Web services are reusable software components, they represent the next step of

evolution from object-oriented systems. Being loosely coupled, they are more amenable

to change. They describe the inputs and outputs in such a way that it is easy to determine

exactly what they do. Web services are programmatically accessible; they operate at the

code level and are not designed for human interaction. Finally, Web services make use of

the existing protocols so that they can be within the reach of everyone.

The Web service structure is composed of several related technologies.

Altogether, they describe a Web Services Technology Stack, as shown in Figure 1.1 [12].

It has three core layers and four emerging layers. The base technology is XML. It is the

building block for nearly every other layer in this stack. Another core layer is SOAP.

This protocol is used for messaging and RPC-like communication among applications. It

is based on XML and uses HTTP. The third core layer represents common Internet

protocols. These lower layers have been more or less standardized, but the same cannot

be said about the higher layers. Currently, many different approaches have come into

play in order to better describe these layers.











Other Business Rules
(not yet defined)


Web Services Flow Language (WSFL)
Emerging Layers
Universal Description, Discovery and Integration
(UDDI)


Web Services Description Language (WSDL)


Simple Object Access Protocol (SOAP)


Extensible Markup Language (XML) Core Layers

Common Internet Protocols
(TCP/IP, HTTP, etc.)


Figure 1.1 The Web Services Technology Stack

The Web Services Description Language (WSDL) is an XML format for

describing network services as a set of endpoints operating on messages containing either

document-oriented or procedure-oriented information [3]. The Universal Description,

Discovery and Integration (UDDI) project defines a set of protocols and a publicly

available registry that facilitates the publishing and discovery of Web services [12]. The

Web Services Flow Language (WSFL) is an XML language for the description of Web

services compositions [9]. The highest layer representing complex business rules has not

yet been defined. It is aimed at taking care of issues such as security, quality of service,

etc.

The Web service architecture describes three roles: service provider, service

requestor, and service registry. Along with these roles, it also defines three operations

that describe the interaction among these roles: publish, find and bind. Service providers









publish services to the service registry. Service requestorsfind the required services from

the registry and then bind to the appropriate services of service providers. This model is

shown in Figure 1.2 [5].




Service
S Broker




Publish Find





Service Bind Service
Provider Requestor



Figure 1.2 The Web Services Architecture

In this framework, the service registry is the vital link between service providers

and service requestors. Research efforts are being directed to ensure that a service broker,

which implements the registry, performs its tasks as efficiently and as accurately as

possible.

This architecture has many advantages [5]. It allows dynamic service discovery

and invocation, thereby enabling just-in-time integration. The service information

published by service providers is kept at a well-known location. It minimizes the

requirements for shared understanding and thus promotes interoperability. As each Web

service defines its interface clearly, it reduces complexity.









1.2 Universal Description, Discovery and Integration (UDDI) An Overview

The UDDI project is a global platform-independent, open framework that can be

used by businesses to discover each other, to define how their services interact over the

Internet, and to share information in a global registry [16]. It is a highly developing area

with more and more functionalities being added over a period of just a few months.

Below, we give a brief introduction to UDDI. A more detailed description is given in

Chapter 2.


Universal Service Interop Protocols
(not yet defined)

Universal Description, Discovery and Integration
(UDDI)


Simple Object Access Protocol (SOAP)


Extensible Markup Language (XML)

Common Internet Protocols (HTTP, TCP/IP)



Figure 1.3 The UDDI Technology Stack

The UDDI standard is based on simple principles. It provides the three links that

are missing in the existing approaches towards developing Web service applications [13].

It gives a simple transparent mechanism to describe Web services. It describes a simple

mechanism for invoking services and provides a publicly accessible registry of services.

Just like the Web services structure, the UDDI standard is not monolithic. It is

composed of several technologies forming a UDDI Technology Stack, as shown in

Figure 1.3 [13].









SOAP provides a simple approach to link applications over the Internet.

Therefore, SOAP forms the core technology in the UDDI stack. UDDI has combined the

SOAP messaging layer with its own directory to create a standard that is technically

sound and extremely simple to implement.

The UDDI specification provides an implementation of the Web service broker

mentioned in Section 1.1. Using this standard, organizations can make their services

publicly known, thereby reaching new customers. It enables organizations to discover the

business most suited to their needs. The standard also defines how further communication

should take place once the discovery is done.

1.3 The Problem Statement

As we have mentioned earlier, the topmost layer of the Web services technology

stack is not yet well defined. We feel that one of the issues this layer should represent is

that of service constraints. Any service is naturally constrained by factors such as cost,

time, input and output data requirements, etc. It is very important to be able to specify

such constraints on a service from both the service providers' and the service requestors'

points of view. This would allow Web services to be specified more precisely to reflect

their real world constraints.

This facility of constraint specification has to be provided at a well-known site to

ensure that it is available to everyone. Similarly, there should be a publicly available

mechanism to match the constraints of the service provider versus those of the requestor.

Thus we see the need of adding the functionality of both constraint specification and

constraint matching at the broker site.

In the UDDI framework, service providers and service requestors can access any

broker site that has been made public. To ensure that constraint specification and









matching is done uniformly; we need a language to specify these service constraints. We

could choose to either define a new language or make some extensions to an already

accepted service representation. The latter approach seems to be more acceptable, as

explained in the next section.

1.4 Goal of Thesis and the Intended Contribution

In this thesis, we explore the possibility of adding the capability of constraint

specification and constraint matching to the service registry defined in the Web service

framework. We show how we can extend the current UDDI registry so that service

providers and service requestors will be able to specify their own constraints over the

services they wish to provide or request, respectively. The result is a constraint-based

broker capable of finding a service provider whose constraints best satisfy/match those of

a requestor.

We make use of the Constraint-based Requirement Specification Language, a

result of our earlier research efforts in this area [15], to specify constraints. However, we

use this language only to define the data structures that we shall need for constraint

specification. To make sure that this constraint information is available in a format

already well understood and accepted, we show how we can extend the current WSDL

specification to accommodate this information and to enable its effective use.

1.5 Organization of Thesis

This thesis is organized as follows. Chapter 2 describes the state-of-the-art in this

area. It points out the important and relevant features of some of the systems that we use.

Chapter 3 explains the concept of constraint-based brokering and illustrates the entire

process with a typical example. Chapter 4 presents the design of a constraint-based

broker. It also explains the flow of information among the different components of our






8


system. Chapter 5 gives the implementation details of the constraint-based broker.

Chapter 6 summarizes the thesis by pointing out the key features of our system and

describes our future work in this area.














CHAPTER 2
RELATED RESEARCH AND TECHNOLOGIES

In this chapter, we look at current research efforts and emerging technologies

related to our work. In Sections 2.1 and 2.2, we elaborate on the concepts proposed by

both UDDI and WSDL. In Section 2.3, we give a brief overview of on SOAP. In the next

section, we discuss the Persistent Object Manager, which is used to store Java objects in

a persistent fashion. In the last section, we briefly describe a Constraint Satisfaction

Processor and a Cost-Benefit Evaluation Server, which are used by the constraint-based

broker for provider selections.

2.1 UDDI

The concept of service-centric computing offers advantages like increased

revenue, meeting new customers, and lowered costs for organizations that have moved

their businesses online [16]. However, most e-commerce-enabling applications have no

uniform means of uniting buyers and suppliers. The solution to this dilemma is provided

by the Web services technology, which is based on standard methods of description,

discovery and integration.

To realize the benefits of this technology, we need a standard platform for

communication between service providers and service requestors. UDDI provides this

platform. A common analogy used for UDDI is a "phone book for Web services" [16]. It

has business names, business addresses, service contact information, and technical

service information. Though much of the information stored in the UDDI registry is

meant for automated computing, there is other information that is of interest to people.









The registry is so designed that it can be programmatically accessed without any human

intervention. As a result, valuable technical and business staff can focus on more strategic

questions. At the same time, there is a well-known URL that provides a GUI for the

registry. A service provider or service requestor can browse through this information and

use it to learn more about the registry.

UDDI is a platform-independent, open framework that describes how businesses

can discover each other, interact with each other, and share information stored in a global

registry. The information provided by service providers during the business registration

process consists of three components. These are called the "white pages" which consist of

company contact information, "yellow pages" which consist of business categories, and

"green pages" which contain the technical information about any exposed service. Figure

2.1 [13] illustrates this concept.


WHITE PAGES YELLOW PAGES GREEN PAGES

Business name Services and product E-business rules
Contact information index Service descriptions
Human-readable Industry codes Application
description Geographic index invocation
Identifiers Data binding


Figure 2.1 The UDDI Business Registry

There are two main reasons why this technology will succeed [13]. The first one

is that business and economic conditions are right for tackling the problems that UDDI

solves. The second one is that the standard's technology has been developed using simple

and effective principles. UDDI promises to remove the bottleneck in finding web-based

services and significantly improve the ability of web-based software to connect to other

software.









Instead of developing our own registry to demonstrate the constraint-based

brokering concept, we have used and extended the functionality of the publicly available

IBM UDDI version 2.0 Business Test Registry. We will look at the features and design

principles of this specification in Chapter 4.

2.2 WSDL

WSDL defines an XML grammar for describing network services as collections

of communication endpoints capable of exchanging messages. WSDL service definitions

provide documentation for distributed systems and serve as a recipe for automating the

details involved in applications communication [3].

A WSDL document is a set of definitions. The abstract information about a

service, such as the operations that it supports, and the input and output parameters to

these operations, is kept separate from the concrete network deployment. The abstract

information is called service interface information, and the network information is called

service implementation information. Because WSDL separates these two kinds of

information, it allows the reuse of the abstract definitions. Input and output parameters of

service operations are put together in a structure called a message. Operations are

grouped together in port types. The concrete protocol and data format specifications for a

particular port type constitute a reusable binding. A port is defined by associating a

network address or an access point with a reusable binding. Services are defined as

collections of ports.

A WSDL document uses the following elements in the definition of network

services [3]:

1. Types: The types element encloses data type definitions that are relevant for
exchanged messages. For maximum interoperability and platform neutrality,









WSDL prefers the use of the XML Schemas Definition (XSD) as the canonical
type system, and treats it as the intrinsic type system.

2. Message: Messages consist of one or more logical parts. Each part is associated
with a type from some type system using a message-typing attribute. Parts
describe the abstract content of a message. For example, if we are defining a
message for use with RPC, a part may represent a parameter in the message.
However, the actual meaning of the part is located in the binding information.

3. Port Type: A port type is a named set of abstract operations and the abstract
messages involved. WSDL has four transmission primitives that an endpoint can
support one-way, request-response, solicit-response, and notification. These
primitives are called operations. Each operation has input and output elements
that specify the corresponding abstract message format.

4. Binding: A binding defines message format and protocol details for operations
and messages defined by a particular port type. There may be many bindings for a
given port type. A binding must specify exactly one protocol and it must not
specify address information.

5. Port: A port defines an individual endpoint by specifying a single address for a
binding. A port must not specify more than one address, and it must not specify
any binding information other than address information.

6. Service: A service groups a set of related ports together. Ports within a service do
not communicate with each other. A service may have several ports that share a
port type. In that case, these ports are alternatives to one another as they employ
different bindings or addresses. By examining its ports, we can determine a
service's port types. Thus, we can choose whether we want to communicate with
a particular service based on what port types it supports.

As WSDL is an XML format, it is very open to language extensions. Also, it

provides a uniform manner of service description. For maximum interoperability, any

service provider will use WSDL to describe his/her service. Also, UDDI provides a data

structure support to both service interface and service implementation information.

Taking all these factors into consideration, we have proposed an extension to the

current WSDL specification in order to incorporate service constraint information. The


details of this procedure are given in Chapter 3.









2.3 SOAP

SOAP provides a simple and lightweight mechanism for exchanging structured

and typed information among peers in a decentralized, distributed environment using

XML. SOAP itself does not define any application semantics, such as a programming

model or implementation specific semantics; rather it defines a simple mechanism for

expressing application semantics by providing a modular packaging model and encoding

mechanisms for encoding data within modules [1]. This allows SOAP to be used in a

large variety of systems ranging from messaging systems to RPC. SOAP consists of three

parts:

* The SOAP envelope construct defines an overall framework for expressing what
is in a message, who should deal with it, and whether it is optional or mandatory.

* The SOAP encoding rules defines a serialization mechanism that can be used to
exchange instances of application-defined data types.

* The SOAP RPC representation defines a convention that can be used to represent
remote procedure calls and responses.

A major design goal for SOAP is simplicity and extensibility. This has resulted in

several features from the distributed object systems or traditional messaging systems such

as garbage collection, watching of messages, etc., to be absent in the core SOAP

specification. In this thesis, we use the SOAP specification through the WSDL

specification. The IBM Web Services Toolkit also makes use of SOAP messages, as we

shall see in Chapter 5.

2.4 Persistent Object Manager

In order to build flexible, scalable, mainstream business software systems, we

need object-oriented or object-based technology. Most of these business application









systems need to handle persistent data. Hence, a persistent object storage service is

required to make these applications useful [11].

Persistence can be achieved in many ways. The Persistent Object Manager (POM)

[11] explores the different approaches to providing persistence and then selects the most

efficient and effective one. The first approach to providing persistence is the use of object

serialization. However, this method has the drawback of the inability to manage large

volumes of data. The second approach is to use Object Oriented Database Systems

(OODBMS); however, query facilities and transaction management are not well

developed in these systems and this presents a major drawback.

The approach used by POM is to use the proven, mature and stable technology of

relational database systems. POM uses an Object-relational database called Cloudscape

to store objects in a persistent fashion. It bridges the gap between the object-oriented

paradigm and the relational paradigm by providing an effective mapping between the

relational and the object-oriented mechanisms.

POM provides the features of object storage, object retrieval, object updating and

object deletion. All of these features are executed as a transaction. It also provides

concurrency control and transaction management to enable data sharing among multiple

users. The design details of POM are given in Chapter 4.

2.5 Constraint Satisfaction Processor and Cost-Benefit Evaluation Server

In this section, we will briefly describe the goals of the Constraint Satisfaction

Processor (CSP) and the Cost-Benefit Evaluation Server (CBES).

2.5.1 Constraint Satisfaction Processor

In Chapter 1, we defined the roles of a service provider, a service requestor and a

service registry. A service provider publishes his/her Web service to the service registry.









The service requestor makes a request for a particular service to the service registry. This

registry is responsible for finding a suitable match for the given request. As we have said

earlier, constraint matching will provide a service requestor with better results. For this

purpose, we have the Constraint Satisfaction Processor.

This module takes two constraint specifications as input and gives a detailed

result of their match. The algorithm used will be explained in Chapter 4. The result gives

a list of values for each parameter of the submitted constraints. These values satisfy both

constraint requirements and are thus safe to use. By adhering to these values, a requestor

is guaranteed that illegal parameters will never be sent during the invocation of a service.

The Constraint Satisfaction Processor was developed for an automated

negotiation system [4, 15]. In order to use it in the context of Web services, we have

extended the language used to specify constraints with several additional constructs. We

have also added support for some more data types. These details will be given in Chapter

5.

2.5.2 Cost-Benefit Evaluation Server

A business company often faces the need to evaluate the costs and benefits of

several competing business offers to determine the one that best meets its criteria. In e-

business, there is a need to automate this process of cost-benefit evaluation. The Cost-

Benefit Evaluation Server (CBES) [10] is based on a quantitative cost-benefit decision

model [14].

In our system, we need to use CBES in case there are multiple providers that

satisfy a particular request after the constraint matching process. This will help us choose

the best provider among the ones that meet the service requestor's constraint






16


requirements. The design details and the method employed to calculate the costs and

benefits of a particular service provider or service requestor are given in Chapter 4.














CHAPTER 3
CONSTRAINT-BASED BROKERING

In this chapter, we outline the process of constraint-based brokering. In Section

3.1, we explain what we mean by constraints and the need to specify them. We also give

examples of the different kinds of constraints that we have identified. In Section 3.2, we

discuss a suitable language for constraint specification. In Section 3.3, we explain the

constraint matching technique with examples. In Section 3.4, we discuss how we can

extend the current Web Service Description Language (WSDL) to incorporate this

constraint information.

3.1 Web Service Constraints

When we talk about a Web service, we can think of many attributes that can

characterize the service. For example, one attribute can be the time required for

completing this service. Another attribute can be the availability of this service. A third

attribute can be the cost of using this service. These attributes characterize the service in

its entirety. We shall call this type of attributes as service attributes.

A service may have one or more operations. An operation can also be

characterized by some attributes (e.g., cost of invoking the operation, the estimated time

to perform the operation, etc.). We shall call this type of attributes as operation attributes.

An operation's input and output data are characterized by a set of attributes or objects

with attributes, which we shall call input and output attributes, respectively.

We can now define constraints as the values that these different types of attributes

should or can have. When a service provider publishes a Web service, it is important to









specify the constraints associated with these attributes. There are two general types of

constraints. One is associated with the individual attributes and is called attribute

constraint. The other type specifies the inter-relationship among these attributes and is

called inter-attribute constraint. The specifications of these two types of constraints are

called Web service constraint specifications. These constraint specifications can represent

simple or complex business rules or policies. For example, consider a product order

service. A service provider for this service may wish to make it available only to a

restricted group of companies, or only for some limited time during weekdays. This

constraint on the service attribute availability is an example of an attribute constraint.

This service can have an operation order with an input attribute quantity. The service

provider may have a minimum and maximum value for this attribute. So, the constraint

"quantity lies between 100 and 500," (i.e., the range of values that quantity can have is

[100..500]), is another example of an attribute constraint.

Let's say that the operation order has another attribute delivery days that gives

the number of days required to deliver a product. This attribute has some dependency on

the quantity of a product ordered. An example of an inter-attribute constraint for this

service would then be "If the quantity of a product ordered is greater than 800 units, the

number of days for product delivery will be greater than 10 days."

So far, we have considered the constraint specification from the service provider's

side. Now consider a service requestor making a request to the service broker for this

service. S/he may want to specify some constraints associated with the service and the

operation to be invoked, and its input and output data. For example, the requestor may

specify that the product order service should not cost more than 3 dollars, the delivery









days cannot be greater than 5 days, and the product to be ordered is a computer. Without

constraint specification and processing capabilities, the broker may select a wrong service

provider for a service request and a time-consuming service could be invoked without

producing meaningful data to the requestor. Constraints in both Web service

specifications and service requests can allow the broker to select the suitable service

providers that satisfy the requestor's requirements.

Thus we see the need for constraint specification and matching. But, in order for

this to work at the Web service level, we need to have a uniform mechanism, i.e., a

language to specify constraints. Also, we need an efficient and effective algorithm for

constraint matching. We will look at these issues next.

3.2 Constraint Specification Language

The constraint specification language must enable service providers to specify

attribute and inter-attribute constraints at the time of publishing their Web services to the

broker. The same language must also be used by service requestors to specify their

constraints at the time of submitting their requests to the broker.

For constraint specifications, we adopt the syntax and semantics of the Constraint-

Based Requirement Specification Language [15]. Figure 3.1 shows a Web service

specification with constraints in a tabular format. The example used is an E-auction

service, by which people auction certain items on the Internet. This service has several

operations, including buy, sell and checkstatus. Each of these operations has its own

input, output and operation attributes. Input, output, operation, and service attributes are

distinguished from each other by the prefixes in, out, op, and svc, respectively. Also, to

avoid naming conflicts while specifying inter-attribute constraints, we prefix the

operation name as well to the input, output and operation attributes.











SERVICE: E-AUCTION
ATTRIBUTE CONSTRAINT:
Svc_basecost Float EQUAL 4

OPERATION: BUY
ATTRIBUTE CONSTRAINT:
Buyin item String ENUM {"Printer", "Cor
Buy_inprice Float RANGE [100.00..5000.00
Buyout ordemo String
Buy_op_cost Float LESSEQUAL 3

OPERATION: SELL
ATTRIBUTE CONSTRAINT:
Sell in item String ENUM {"Printer", "Compute
Sellinpricequote Float RANGE [100.00..5000.00]
Sell out ordemo String
Sellop_cost Float EQUAL 3

OPERATION: CHECKSTATUS
ATTRIBUTE CONSTRAINT:
Checkstatus in ordemo String
Checkstatus out status String ENUM {"Accepted", "F
Checkstatusop_cost Float EQUAL 3

INTERATTRIBUTE CONSTRAINT:
IC1 Buy_initem= "Computer" Implies Buy_inprice>800
IC2 Buyinprice>=3000.00 Implies Buy_opcost = 1


iputer", "Scanner"}






:r", "Scanner"}


Rejected"}


Figure 3.1 Constraint Specification of an Example Web Service

The service has an attribute basecost, which is the cost of using the service

regardless of what operations are to be used. For the operation buy we have two input

attributes: item (first row) signifying the commodity to be bought andprice (second row)

signifying the price at which the item is to be bought. The output attribute orderno (third

row) gives the order number assigned when this operation is invoked. There are no

constraints on this attribute. This operation has its own cost (fourth row). Similarly, the

operation sell has two input attributes: item signifying the commodity to be sold and

price quote signifying the initial quoted price. The output attribute orderno is the order

number assigned when this operation is invoked. This operation also has its own cost

attribute. The operation checkstatus has an input attribute orderno, which has no









associated constraints. The output attribute status signifies the status of this order, i.e.,

whether it has been accepted or rejected.

Constraints associated with the above mentioned attributes are given in columns

2-4. Each attribute constraint has a data type (second column), a keyword (third column)

that tells us the nature of these constraint values, and the actual values and value ranges

(fourth column). In Figure 3.1, we have shown the data types offloat, and string and

keywords of range, enum (for enumeration), lessequal (for less than or equal to) and

equal.

The inter-attribute constraint IC1 states that, if the product a customer wishes to

buy is a computer (the second column), the price has to be greater than $800.00 (the

fourth column). The second inter-attribute constraint IC2 is a business rule that

guarantees the buyer of a lower operation cost if s/he buys goods worth $3,000 or more.

In its general form, an inter-attribute constraint's If and Then conditions can be complex

Boolean expressions. In addition to the attribute and inter-attribute constraints illustrated

above, priority values (not shown in the figure) can be assigned to these constraints. They

specify the relative importance of these attributes and are used by the constraint matcher

to establish the order of evaluation. Another language facility is to allow the specification

of an attribute to be either negotiable or not. The violation of a nonnegotiable attribute

will immediately terminate the constraint evaluation process. These attributes will be

described in detail in Chapter 5.

3.3 Constraint Matching

For provider selection, the service broker needs a mechanism to match the

constraints given in a service request against those of service providers. In this work, we

use a Constraint Satisfaction Processor (CSP) developed for an automated negotiation









system, reported in Su et al. [15]. This processor takes two constraint objects (i.e.,

constraints of the request and those of a potential provider) to be matched as its input.

The output basically tells us whether the input objects matched or not. Along with that,

CSP also gives the attribute values and the combinations of these values that can satisfy

both sets of constraints.

Recall in the example given in Figure 3.1, attribute constraints are specified by

ranges, enumerations, and single values with comparison operators. CSP normalizes the

constraint specifications of all numerical attributes into interval sets. For example, the

attribute value >5 is converted to [(5,o)]. The enumeration (4, 6, 10) is converted to

[[4,4], [6,6], [10,10]] and the range specification remains in its interval form. For each

numerical attribute, the interval values from both sets of interval sets are compared and

intersections between intervals are taken to generate the resulting interval sets, which

contain the common values in both sets of interval sets (i.e., the values that satisfy the

constraints of both the provider and requestor). For non-numerical attributes, the value

constraints of the provider and the requestor are matched in a straightforward manner.

After the attribute constraint matching, inter-attribute constraints of the provider and the

requestor are then examined to filter out those attribute values that violate the inter-

attribute constraints. If the values) of any attribute in the request does not satisfy the

corresponding constraint of the provider, the constraint satisfaction processing fails.

Otherwise, the provider is a candidate provider for the request. CSP would generate all

combinations of attribute values that satisfy the constraints of both the provider and the

requestor. If multiple providers satisfy the constraints of a request, cost-benefit










evaluations are then performed on these combinations by a Cost-Benefit Evaluation

Server [14, 15] to perform provider selection.


SERVICE: E-AUCTION
ATTRIBUTE CONSTRAINT:
Svc_basecost Float EQUAL 5

OPERATION: BUY
ATTRIBUTE CONSTRAINT:
Buyin item String ENUM
Buy_inprice Float RANGE
Buyout status String ENUM
Buy_op_cost Float LESSEQUAL

OPERATION: SELL
ATTRIBUTE CONSTRAINT:
Sell in item String ENUM {
Sellinpricequote Float RANGE [5
Sell out finalprice Float RANGE [5
Sellop_cost Float EQUAL 4

OPERATION: CHECKSTATUS
ATTRIBUTE CONSTRAINT:
Checkstatus in ordero String
Checkstatus out status String ENUM
Checkstatus _op_cost Float EQUAL

INTERATTRIBUTE CONSTRAINT:
IC1 Buy_initem= "Printer" Implies
IC2 Buyinprice>=2900.00 Implies


{"Printer", "Scanner"}
[500.00..5000.00]
{"Processing", "Shipped"}
4



'Printer", "Scanner"}
o00.00..5000.00]
o00.00..5000.00]





{"Accepted", "Rejected"}


Buy_inprice>500
Buyopcost= 2


Figure 3.2 Constraint Specification of a Web Service Provider

In order to use the CSP in the Web service scenario, we have made a few

extensions. We have introduced some new data types and keywords to describe constraint

values. CSP basically defines inter-attribute constraints by means of implications. We

have extended this concept further so that it can incorporate business rules. Thus, a

business rule such as "The sum of quantity A and quantity B cannot be greater than 50"

as an implication is defined as "True implies the sum of quantity A and quantity B cannot

be greater than 50."










To give an example of constraint matching, we use the Web service E-Auction

described in the preceding section. Figure 3.1 describes the service provider constraints

of one service provider. Another service provider's constraints are given in Figure 3.2.


SERVICE: E-AUCTION
ATTRIBUTE CONSTRAINT:
Svcbasecost Float EQUAL 4

OPERATION: BUY
ATTRIBUTE CONSTRAINT:
Buyin item String ENUM {"Computer"}
Buy_inprice Float RANGE [200.00..5000.00]
Buyout orderno String
Buy_op_cost Float LESSERTHAN 3

INTERATTRIBUTE CONSTRAINT:
IC1 Buyinprice>=2500.00 Implies Buyopcost<=2


Figure 3.3 Constraint Specification of a Web Service Requestor

Prior to constraint matching, both the service providers seem to satisfy the

requestor's needs; however, after we run the matching algorithm, we find that only the

provider described in Figure 3.1 satisfies the requestor's constraints in Figure 3.3. This is

reflected in the results shown in Figures 3.4 and 3.5.


CONSTRAINT MATCH RESULT
Satisfied : True
ValueLists:


Attribute
Buyin item
Buy_in_price
Buyout orderno
Buy_op_cost
Svc basecost


Value
{"Computer"}
(800.00..5000.00]
No constraint
(--,3)
4


Figure 3.4 Constraint Matching Result between Provider 1 and Requestor









CONSTRAINT MATCH RESULT
Satisfied: False
ViolatedAttributes: item

Figure 3.5 Constraint Matching Result between Provider 2 and Requestor

Only a part of the actual generated result is shown in Figure 3.4. The actual result

also includes all the combinations of attribute values that satisfy the constraints, but they

are not shown here to keep the explanation brief. The complete result specification will

be shown in Chapter 5.

Based on the results of these two matches, the service broker would select

Provider 1 for the request. The requestor is guaranteed that the service invocation will not

fail if s/he adheres to the attribute value combinations returned by the broker.

3.4 Extending WSDL

Though the constraint specification language discussed in Section 3.2 is a very

effective means of specifying constraints, it would be more useful if we could provide an

extension to an already established language. In this section, we propose such an

extension to WSDL.

The Web Services Description Language (WSDL) is the current standard for

specification of Web services. WSDL documents can be used to register services with the

UDDI registry. There are two kinds of documents that are used while registering a

service [2]. The first is known as the Service Interface Document, that gives only the

input and output attributes for each service operation and omits implementation details

such as port address, communication protocol, etc. The other document is the Service

Implementation Document. It refers to some previously defined Service Interface

Document and gives the implementation details for the service operations defined in that

document.










For constraint specifications, WSDL is extended in our work to include the

statements of our Constraint-Based Requirement Specification Language in XML format.

Extensions are made in both types of documents. In the interface document, the names

and data types of both operation attributes and service attributes are added as shown

below. This will result in a well-defined set of attributes for the interface, and all service

providers wishing to implement it will work with the same set of attributes




targetNamespace= "http://www.eauction.com/EAuctionService-interface"
xilni L Inis="Ilip \ \\ \\ .eauction.com/ EAuctionService-interface"
xilnsii \isd="llp \\\\ .w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">


Standard WSDL service interface definition for an e-auction service


























































encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />


encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />





encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />


encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />





encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />









28

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />







cost
float




cost
float




cost
float




basecost
float







Figure 3.6 Extended Service Interface Document for an Example Web Service

The service and operation attributes are added to the WSDL document by adding

another XML tag interface attributes as a child of the main tag definitions. Under this

new tag, we have the XML tags operation attributes and service attributes. Each

operation attributes tag has the operation name as its attribute. Under each

operation attributes tag, we have a number of operation attribute tags that give the

name and data type of each such attribute. Similarly, under each service attributes tag,

we have a number of service attribute tags that give the name and data type of each

service attribute.










Constraints represent specific information given by each service provider who

implements a service based on a service interface document. This information should

therefore be given in a Service Implementation Document. The extended Service

Implementation Document is shown below. It contains the constraints shown in Figure

3.1



targetNamespace="http://www.eauction.com/EAuctionService"
xmlns:interface="http://www.eauction.com/ EAuctionService-interface"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xilnsi\ \tsd="Illp \\ \\.w3.org/2001/XMLSchema">


This service provides an implementation of an e-auction service.


namespace="http://www.eauction.com/ EAuctionService-interface" />


Electronic Auction Service

Electronic Auction Service Port







item
string
ENUM< kc '\ old >
{"Printer", "Computer", "Scanner" }


price
float
RANGE< kc \ \old >
[100.00..5000.00]












status
string
ENUM< kc \ \old >
{ "Processing", "Shipped" }


cost
float
LESSEQUAL< kc, \ old >
3




item
string
ENUM< kc %\ old >
{"Printer", "Computer", "Scanner" }


pricequote
float
RANGE< kc \ \old >
[100.00..5000.00]


finalprice
float
RANGE< kc% \ \oid >
[100.00..5000.00]


cost
float
EQUAL< kc\ \\oid >
3




status
string
ENUM< kc% \\oid >
{ "Accepted", "Rejected" }


cost
float
EQUAL< kc\ \\oid >
3













basecost
float
EQUAL< kI, \ \old >
4




IC 1
Buy_in item="Computer"
Buy_in_price>800


IC2
Buy_in_priceprice>=3000.00
Buy_op_cost=






Figure 3.7 Extended Service Implementation Document for an Example Web Service

The required constraint information is incorporated in the WSDL specification by

adding another XML tag, constraints, as a child of the main tag, definitions. Under this

new tag, we have the XML tags constraint, service constraints and

interattribute constraints. Each constraint tag has the operation name as its attribute.

Under each constraint tag, we have a number of tags, namely, input constraint,

output constraint, and operation constraint tags, which give the constraint descriptions

for the input, output and operation attributes, respectively. Under each

service constraints tag, we have a number of service constraint tags that give the

description of each service attribute constraint. Each interattribute constraints tag

contains a number of interattribute constraint tags that describe the inter-attribute

constraints among all the constraint attributes, as shown in Figure 3.7















CHAPTER 4
DESIGN OF THE CONSTRAINT-BASED BROKER

In this chapter, we first give the overall design of our system, followed by an

explanation of how the system works. We then give the detailed design of the key

components of our system.

4.1 System Architecture

The architecture of the Constraint-based Broker is shown in Figure 4.1.


Constraint-based Broker


UDDI Registry UF Registry
CBES CSP (POM)




Discovery Coordinator Publish Coordinator


Service Requestor Service Provider


Figure 4.1 System Architecture

The key components of this system are the UDDIRegistry, the UFRegistry and

the Constraint Satisfaction Processor (CSP). The Discovery Coordinator and the Publish

Coordinator form the communication link among these three components. Optionally, we

can make use of a Cost-Benefit Evaluation Server [10], the details of which will be

explained in Section 4.4.









There are two operation scenarios here: one is the service provider registering

(publishing) a Web service and the other is the service requestor trying to find (discover)

a suitable service. The Publish Coordinator handles the registration scenario and the

Discovery Coordinator handles the find scenario.

The system works as follows. The service provider registers his Web service with

the system through the Publish Coordinator. The registration information contains UDDI

information as well as constraint information. It is up to the Publish Coordinator to store

this information in the appropriate registries. When the service requestor asks for a Web

service that will meet his needs, the Discovery Coordinator carries out a two-phase

search procedure. In the first phase, a list of service providers is obtained from the UDDI

registry. In the second phase, the service requestor's constraint information is matched

with that of the service providers in the list to filter out those providers that do not satisfy

the requestor's constraints. During these phases, the list of service providers is thus

pruned till we get the final list of suitable service providers. This is then returned to the

service requestor.

We now present the design details of the components in our system.

4.2 Publish and Discovery Coordinators

As mentioned earlier, these two components handle different operation scenarios.

Let us now look at the information flow for each scenario and the function of each

component.

4.2.1 Information Flow during Publishing a Web Service

When registering a service with a UDDI-enabled broker, the service provider

needs to give UDDI information, such as the service name, service access point, UDDI

classification of the service, etc. But with the Constraint-based Broker, the service









provider needs to provide constraint information as well. Current UDDI registries are not

designed to accept this information. Hence, we store this information in our own

homegrown registry. This registry is called Persistent Object Manager (POM), which is

the result of an earlier project of our research center [11]. This POM can store constraint

information in the form of Java Objects in a persistent fashion so that they can be

retrieved and queried upon later.


The Registration Process


UF Registry
UDDI Registry (POM)

Key 4
3/ KeConstraint
UDDI Information +
Information Key


Separate registration
Publish Coordinator information to be stored in
A appropriate registries





SRegister Service Acknowledgement

Service Provider


Figure 4.2 Information Flow During the Registration Process

As shown in Figure 4.2, the request to publish a service goes to the Publish

Coordinator component of the broker. This request contains UDDI information along

with a constraint specification. The Publish Coordinator separates the UDDI information

from the submitted request and stores it into the UDDI registry. It then takes the

constraint specification and stores it into the POM.









After the publish operation is done, the service provider gets back an

acknowledgement from the Publish Coordinator. Optionally, a service provider may use

the user interface facility of a Cost-Benefit Evaluation Server (CBES [10]) (not shown in

Figure 4.2) to register her/his preferences with respect to different values and value

ranges of all the attributes specified in the service interface document, and to provide cost

information if it is available. Thus, in case of more than one service provider satisfying a

service request, the CBES would make use of the registered preferences and cost

information of these providers to do cost-benefit analysis and provider selection.

4.2.2 Information Flow during Discovering a Web Service

When discovering a service with the UDDI-enabled broker, the service requestor

needs to give some search criteria, such as the service category, owning business, etc.

Accordingly, a list of services that satisfy this request is returned. Normally, a service

requestor has enough knowledge about the service interface that s/he wants. Using this

knowledge, first a suitable service interface is found, and then implementations of this

interface are requested. In the constraint-based broker system, we separate the discovery

procedure into two phases.

The first phase is shown in Figure 4.3a. As soon as a service request is submitted,

a component called the Discovery Coordinator starts the first phase. The UDDI registry

is contacted with the submitted search criteria and the results returned are given back to

the service requestor. These results contain a list of satisfactory service interfaces. The

service requestor then uses these results to select a suitable service interface that has the

desired operations.











The Discovery Process Phase I



UDDI Registry



List of Suitable
UDDI Search Criteria Interfaces


Discovery Coordinator


1 Search for 4
Interface Results

Service Requestor


Figure 4.3 Information Flow During the Discovery Process. A) First Phase.

Once that is done, the service requestor is asked for service constraint

information. This starts the second phase of the discovery process, which is shown in

Figure 4.3b.


The Discovery Process Phase II
Requestor
and 8
CSP Provider
Constraint
Constraint Information
match
results
9 A


7

List of Sei
Providers


First phase 6
results


Figure 4.3 Information Flow During the Discovery Process. B) Second Phase.









The Discovery Coordinator queries the POM using the results of the first phase to

get a list of potential service providers. CSP is then used to match request constraints

against those of each of the providers. If multiple providers satisfy the request, the CBES

(not shown in Figure 4.3b) is used to find the best service provider.

4.3 UDDI and UF Registries

In order to leverage the existing knowledge in this area, we have designed the

system to take advantage of the currently implemented UDDI-enabled registries. In our

work, we use IBM's UDDI version 2.0 Business Test Registry as the UDDI registry [6].

We now discuss the design principles of the UDDI version 2.0 specification and the data

structures used.

The basic design principle behind the specification is simplicity. The API has

been so designed that there is minimal overlap and the basic registered information is

available readily without much programming overhead. In order to design such a simple

and efficient system, many issues need to be addressed [18]. We will examine these one

by one.

1. Security: UDDI is programmatically accessed via API calls. We have two sets of
APIs here. One set is defined for the use of the service provider and the other set
is for the use of the service requestor. We have a different type of security for
each set. Only authenticated users are allowed to use the service provider API.
Each provider has access to only those businesses, services and interfaces that
s/he has published. On the other hand, the API provided for the requestor can be
used by anybody. The service requestor cannot modify any information. These
different security levels guarantee a secure transaction during registration, and, at
the same time, provide easy access during discovery.

2. Versioning: The UDDI specification is undergoing much change in a very short
time period. As a result version control is a very important issue. In case of
different versions of APIs between two parties (for example, provider and
requestor or requestor and registry), there needs to be some way of determining
the correct version to be used. This is facilitated by the use of XML as the base of
the API. The API is version stamped and this stamp appears as an XML attribute.
This attribute is named generics. Thus, UDDI v 2.0 will have the generics









attribute set to a value of 2.0. All sites supporting a particular version are required
to support at least the previous version.

3. SOAP Messaging: UDDI uses SOAP in conjunction with HTTP to provide a
simple mechanism for XML message passing. Each version of the specification
has its own support for different attributes of the SOAP mechanism. These
include support for SOAP Action, SOAP Header, SOAP encoding, SOAP Fault,
SOAP Error, etc. We will not go into the details here. The important point is that
SOAP is a very convenient way of linking applications over the Internet. As such,
the use of SOAP in the UDDI specification will ensure easy accessibility by
applications in the future.

4. Error Handling: Most of the error reporting is governed by the SOAP
specification. As a result, the UDDI specification needs to define error codes for
only those errors not handled by SOAP. Most of the invalid requests can be
handled by SOAP fault reporting and fault codes. In case of an application level
error, a structure called a dispositionReport will be embedded inside a SOAP fault
report. Generally, errors are detected prior to processing a request. Thus, invalid
requests are not considered further, and this results in a minimum load on the
registry at any one time. UDDI error codes are defined to describe some general
errors. However, in case of an unusual error, the operating site is allowed to return
other error codes. Also, the error that is detected first is the only one that is
reported.

5. Unique Identifiers: During the registration process, a service provider can register
a business, service, or a service interface. All this information is kept in separate
data structures, as we will see shortly. Each of these structures is accessed by way
of unique identifiers called a Universal Unique Identifier (UUID). These
identifiers are generated when the information is first saved. Each service
provider can use this identifier later to add, modify, or delete this information.
The identifier is a hexadecimal string generated by a very exacting algorithm so
that no two generated UUIDs are duplicates of each other.

We will now look at the data structures used by this specification. There are

basically five data types defined in this specification; but for our purposes, we shall need

four of these. These four types and the interaction among them are shown in Figure 4.4.

We will now give the details of each [17].

1. The businessEntity Structure: This structure represents all known information
about a business entity. This structure is the topmost level of the data structure
hierarchy. Each such structure is assigned a businesskey that is its UUID. It
contains descriptive information about the entity, such as the categorization of the
business, the contacts for this particular entity, etc. It also contains information
about the services that this entity offers. This information is stored in another










structure called the businessService structure, as we shall see next. This
information is expressed within a businessEntity structure by a containment
relationship, as shown in Figure 4.4.




businessEntity : Contains
information about the provider who
registers a family of services.


businessService : Contains
descriptive information about a
business service.


bindingTemplate: Contains
technical information about a
service access point and other
implementation details.


tModel: Contains descriptions of
specifications like service
interfaces.


bindingTemplate data contains
references to tModels. These
tModels designate the interface
specifications for a service.


Figure 4.4 UDDI Data Structures and their Inter-relationship

2. The businessService Structure: This structure represents each service registered
by the service provider. It holds descriptive information such as the category of
the service, language-qualified text descriptions of the service, etc. The technical
information such as binding information, service access points, a reference to the
service interface, etc., is also stored via containment of another structure called
the bindingTemplate structure. In case the service information is available as a
WSDL document, the URL of the document can also be stored here.

3. The bindingTemplate Structure: Technical descriptions of Web services are
accommodated via individual contained instances of the bindingTemplate
structure. These structures provide support for determining a technical entry point
or optionally support remotely hosted services. They also provide a facility for
describing the unique technical characteristics of a given implementation. This
information is most vital for service description and discovery.

4. The 1\ lh,,,l Structure: The 7. 1b,,k' structure takes the form of keyed metadata.
This structure can define almost anything. One of the purposes of this structure is
to mark a service with information that designates how it behaves, what









specifications or standards it follows, etc., thus, it provides a convenient place to
store information about the service interface and it is for this purpose that we are
using the i ,l,'1l structure. In our system, service interface documents are
available in WSDL format. The tModel structure stores the URL of these
documents. Each such structure also has a UUID called the tmodelKey. However,
there is no direct hierarchical relationship between this structure and the previous
three structures.

We now discuss the design principles of the Persistent Object Manager (POM)

[11] and explain how it helps us in storing the constraint information in the appropriate

format. We also give the advantages of using such a system.


TCP/IP


Cloudscape


Figure 4.5 POM System Architecture









As discussed in Chapter 2, the POM uses an object-relational database system

called Cloudscape. This DBMS extends the functionality of a traditional RDBMS by

providing a data type to store and process user-defined objects. The main hassle in using

such a system is the different goals of object-oriented design and relational database

development. As a result, an object-relational chasm is developed and a mapping

framework is required to fill in this gap [11]. The POM provides this capability by

integrating the Java programming language, JDBC and the Cloudscape DBMS, as shown

in Figure 4.5.

In order to provide this object-relational mapping, many issues need to be

addressed. We give below a brief explanation of each of these issues. Wherever possible,

we have tried to include how POM handles that particular issue.

1. Performance: This is one of the major forces that should be taken into
consideration. An attempt for storing or retrieving an object will result in at least
one access to the underlying database. Enough care has to be taken while
designing the mapping strategy so that the number of database calls is minimized.

2. Maintenance Cost: Relational database design tries to eliminate redundancy by
using normal forms. However, in order to achieve good performance we have to
minimize database accesses. This would involve ignoring the rules of
normalization and thus will result in a less maintainable system. The goals of
maintenance and performance are contradictory and POM strives to achieve a
balance between them.

3. Inheritance: As POM has been designed for use by Java applications, it does not
cover the concept of multiple inheritance. Simple inheritance is adequate in many
cases, especially in our case of the constraint-based broker. There are various
ways of mapping inheritance hierarchies to relational database tables. Some of
these approaches are as follows.

The first strategy that we consider is that of providing one table per
inheritance tree. Thus, a union of all the attributes of all the objects is used
as the columns of a single database table. Null values are stored in unused
fields. The advantages of this approach are the sufficiency of a single
database operation to read or write, a straightforward mapping strategy,
and easy formulation of ad hoc queries. The disadvantages are the









inflexibility of the inheritance hierarchy once the mapping is done and
poor performance due to heavy traffic on a single table.

The second strategy is to map all the attributes occurring in an inheritance
path to a single database table. Thus each class is mapped to a different
table. This approach still needs a single database operation to read or
write. Also, the traffic is evened out and hence performance improves.
However, adding or deleting attributes in a super class results in
corresponding changes to all derived classes. The base class information is
stored in all the derived classes, introducing redundancies. Also, query
formulation is difficult.

The third strategy is to use Binary Large Objects (BLOBs). This approach
provides the advantages of minimal space consumption and simple
schema evolution, but it causes a significant overhead for maintenance.
Query formulation is also difficult in this case.

The POM approach to mapping inheritance is to map each class in an inheritance
hierarchy to a separate database table with a super class object identifier (OID)
column to link the rows in each derived class table with the corresponding rows in
the parent class table. This approach provides a very flexible mapping and has
near optimal space consumption. Query formulation is difficult here, too, but this
system has a high-level query processor, which takes care of this drawback.

4. Aggregation: In an object-oriented model, we have the concept of container
classes. Thus one class can have as an attribute an object of another class. The
mapping strategy needs to take care of this scenario also. Again, there are a
number of strategies that can be used to take care of this problem.

The first strategy is to use single table aggregation. The attributes in the
contained class are expanded to become the attributes of the container
class. This approach is optimal in terms of performance and object
deletion is straightforward. But the object structure becomes inflexible
once the tables have been created.

The second strategy is foreign key aggregation. The container class is
mapped to a table and the contained class is mapped to another table. The
container class table stores the OID of the contained class table. Mapping
is more flexible and easy to maintain. However, due to the join operation
while accessing a container object, performance decreases.

The POM approach towards solving this problem is to make use of the serialize
data type supported by Cloudscape. Thus, complex data types can be stored as
columns of a table. For each container class, POM stores the contained object in
its serialized form as one column of the database. This approach has the
advantages of the single table approach and also the benefit of easy query









formulation. The disadvantage of this approach is due to serialization, which is a
relatively slow process.

5. Application Type: Though POM provides a facility of storing virtually any type of
objects in a persistent fashion, there are limitations to the application types that it
can support. Applications that require manipulation of complex interrelated
objects cannot be supported by this system. CAD applications and CASE tools are
some such examples.

The object structure that we need to store in a persistent fashion conforms to the

type of objects stored by POM. We do not make use of the inheritance concept, but we do

use the concept of aggregation in the class structure constructed to store constraint

information. POM provides a very effective way of mapping this concept and thus is very

useful to us. Also, once the appropriate tables are created to store the constraint objects,

any further store operation results in the creation of object instances only and no new

tables need to be created. This reduces the load on the database as database accesses are

done only for storing a new instance. All these factors make POM a very efficient tool to

be used for our system.

4.4 Constraint Satisfaction Processor and Cost-Benefit Evaluation Server

As explained in Section 4.2, the service provider gives the constraint information

associated with his/her service during the registration process. This information is stored

in the Persistent Object Manager to be retrieved during the discovery phase. In this phase,

the service broker matches the service requestor's constraints with those of the service

provider's. The provider that best matches the requestor constraints is then returned to the

service requestor.

In this section, we will describe the algorithm used to match the constraints. As

mentioned in Chapter 3, there are different kinds of constraints, such as input constraints,

output constraints, service constraints, and operation constraints. All of these form one









type of constraints called the attribute constraints. They specify the properties of a

particular attribute. The second type of constraints specifies the properties that must hold

among multiple attributes. In other words, this type gives the relationship among the

attributes. These are called inter-attribute constraints.

In Chapter 3, we gave a brief overview of how the constraint matching process

works. Constraint matching by itself is an NP hard problem. The key behind the reduced

complexity of our algorithm is its use of interval sets. The value lists of every attribute

are first converted into interval sets. For example, the constraint '> 10' is converted into

the set [10..0), and the constraint 'enumeration { 1, 2, 3 }' is converted into a set of

intervals [[1,1], [2,2], [3,3]].

We will now explain the algorithm used for constraint matching. Given two sets

of constraints, CS1 and CS2, each with a set of attribute constraints (AC) and a set of

inter-attribute constraints (IAC). The algorithm is as follows [4]:

1. First, each AC and IAC set is sorted based on the assigned priority. Constraints
denoted as 'not-negotiable' have the highest priority. If no priority is assigned, the
order in which the constraints were specified is assumed as the priority order.

2. For each constraint set

For each AC in the set

The domain values represented as single values, range of values, or an
enumeration of values are transformed to a set of intervals.

3. Let ACS1 be the set of attribute constraints in CS1 and ACS2 be the set of
attribute constraints in CS2.

For each attribute, a, in ACS1 and ACS2

Let ACVal be the interval set of a in ACS1 and AVCa2 be the interval set
of a in ACS2.









The intersection of ACVal and ACVa2 forms the result ACVa. If for
some attribute, this set is empty, a value of 'unsatisfied' is returned.
Otherwise, we go to step 4.

4. After all attribute constraints are handled in this manner, we generate a
combination list. This contains a list of all the valid combinations among the
attributes. As no inter-attribute constraints are handled at this time, this list just
contains one combination. This is the result of putting all the ACVas of every
attribute a together.

5. Let IACS1 and IACS2 be the inter-attribute constraint sets of CS1 and CS2,
respectively.

For each IAC in IACS1, the IAC is first parsed. For each simple expression,
i.e., one that involves one attribute and one value (e.g., x > 10), the expression
involving attribute a is transformed into an interval set denoted as ACIa. This
set is used to partition the set ACVa generated in step 3. Thus, we get two
interval sets. One is the intersection of the sets ACIa and ACVa, i.e., ACVa n
ACIA. The other set is ACVa [ACVa rACIA]. This latter set may generate
two sets.

6. Let SATISFYa be the satisfied interval sets of attribute a. For all attributes, the
combination list that satisfied both the attribute and the inter-attribute constraints
is generated. Let UNSATISFYa be the unsatisfied interval sets of attribute a. For
all attributes, the combination list that does not satisfy the constraints is generated.

We now give an example of using the above algorithm to match two constraint

sets. Let the two constraint sets be defined as shown in Figure 4.6. Given below is the

result generated at every step in the algorithm.

Result of Step 1

The two constraint sets are sorted so that attribute A is examined first, followed

by attribute B. There is only one inter-attribute constraint, so sorting is not

necessary.

Result of Step 2:

The values for attributes A and B are transformed as follows.

CS1: A- [1,10], B [["strl"], ["str2"]]


CS2: A- [2,15], B [["strl"], ["str2"], ["str3"]]











Constraint Set 1 (CS1):

Attribute Constraints:


Name
A
B


Type
Integer
String


Keyword Value List
RANGE [1..10]
Enumeration {"strl", "str2"}


Priority
NON NEGOTIABLE
PRIORITY[3]


Inter-Attribute Constraints:


Name If Then Priority
IAC1 A>5 B="str2" NON NEGOTIABLE


Constraint Set 2 (CS2):

Attribute Constraints:


Name Type Keyword Value List Priority
A Integer RANGE [2..15] NON NEGOTIABLE
B String Enumeration {"strl", "str2", "str3" I PRIORITY[31


Inter-Attribute Constraints:


Name If Then Priority
IAC1 A<4 B ="strl" NON NEGOTIABLE


Figure 4.6 Attribute and Inter-Attribute Constraints of two Example Constraint Sets

Result of Step 3:

The intersection for attributes A and B is:

A- [[2,10]]

B [["strl"], ["str2"]]

Result of Step 4:

The combination list generated is :


Combination 1


[[2,10]] and [["strl"], ["str2"]]


Result of Step 5:

The interval sets generated due to the two inter-attribute constraints are:

A-[[2,4), [4,5], (5,10]]


B [["strl"], ["str2"]]









Result of Step 6:

The combinations generated that satisfy the constraints are:

Combination 1 [[2,4)] and [["strl"]]

Combination 2 [[4,5]] and [["strl"], ["str2"]]

Combination 3 [(5,10]] and [["str2"]]

The combinations generated that do not satisfy the constraints are:

Combination 4 [[2,4)] and [["str2"]]

Combination 5 [(5,10]] and [["strl"]]

The results returned by the Constraint Satisfaction Processor include all these

combinations. This helps the requestor to adhere to his/her own constraints and also to

those of the service provider.

We will now present the design details of the Cost-Benefit Evaluation Server

(CBES). The CBES has been built to support decision-making in collaborative e-

business. It has been designed and developed on the extended cost-benefit decision model

[14] and includes a set of build-time knowledge specification tools and a run-time

evaluation engine [19]. These tools are briefly discussed below. A detailed discussion of

CBES [19], however is not presented here.

1. Knowledge Specification: At build-time, CBES allows the service provider to
specify his/her elementary criteria for some possible values of the service,
operation, input, and output attributes. The provider can specify a preference
score in the range of [0.. 1] that indicates his/her satisfaction with a particular
value or ranges of values for each attribute. Since the explicit specification of
these scores for all values may be difficult, CBES also provides the facility of
interpolating the remaining preference scores once the scores for some key
attribute values or value ranges are specified. Also, a service provider may wish
to assign a higher priority or score to some specific combinations of attribute
values. For such cases, CBES provides the facility of defining a preference score
for aggregations of attribute values. CBES supports a wide range of aggregation
functions, each of which determines the way preference scores associated with









different subsets of attributes are to be aggregated to produce an aggregated
preference score. Cost information associated with some attributes and values, if
available, are also entered.

2. Run-time Evaluation Engine: For CBES to be used in our system, it is required
that the service providers and the service requestor register their preference scores
and cost information in advance. At run time then, the CBES takes the result
returned by CSP for each provider and evaluates it against the preference score
and cost information given by the service requestor to generate an overall cost-
benefit score. The provider's service that received the best overall cost-benefit
score will be the one selected to perform the service requested by the requestor.
There are several modes of operation for CBES. In the exhaustive mode, CBES
evaluates the value combinations of the input attributes for all the attributes. In the
best mode, CBES evaluates only those combinations for which each individual
attribute value range has the highest preference score. In the worst mode, CBES
evaluates only those combinations for which each individual attribute value range
has the lowest preference score. In the approximate mode, CBES assigns a
preference score to each attribute as a whole, based on the different scores
assigned to the range of values this attribute can take.

The cost-benefit analysis is an optional step during the discovery phase in our

system. The service broker may find many service providers that satisfy the service

requestor's constraints. In that case, if the service providers and the service requestor

have their preferences and cost information registered, CBES can be used to evaluate all

of them based on the requestor's preferences and cost information. Thus, a provider's

service that is most desirable from the requestor's cost-benefit point of view can be


selected.

















CHAPTER 5
IMPLEMENTATION DETAILS

This chapter is organized into four sections. In Section 5.1, we give the data

structures used for our system along with the Java Class definitions. In Section 5.2, we

give the details of using the IBM UDDI Business Test Registry and also give an

overview of how POM maps our Java object into classes. In Section 5.3, we give the

details of using the IBM Web Services Toolkit. In Section 5.4, we give screenshots of a

sample scenario.

5.1 Data Structures and Class Definitions

As we have explained in Chapter 3, the service provider and the service requestor

both use the constraint-based broker for different purposes. The service provider uses our

system to register his services with the broker, whereas the service requestor uses it to

discover service providers that satisfy his/her service constraints. Even though we have

two views of the system, the data structure that we use for constraint specification in both

cases is the same; however, we are using a Constraint Satisfaction Processor (developed

earlier for automated negotiation purposes), for constraint matching between the service

provider's and the service requestor's constraints. In order to preserve the data structures

used by CSP, we map our constraint specification objects to the corresponding constraint

specification objects of CSP.

There is a constraint specification hierarchy in our system. Each Web service

encapsulates many related operations. Each of these operations has input and output









parameters. At the highest level, we have constraints that characterize the service itself.

Examples of such constraints are constraints on the attributes of service cost, service

usage policy, etc. The next level is of constraints that characterize an operation as a

whole. Examples of such constraints are constraints on the attributes of operation cost,

time required to carry out that particular operation, etc. Then at the lowest level, we have

constraints that are specified on the operation parameters. Examples of such constraints

include limiting the range of values a particular input parameter can take, enumerating

valid input attribute values, etc. Also, there may be constraints as a result of the inter-

relationship of these input, output, operation, and service attributes. In order to reflect this

hierarchy, we have five Java Objects whose class definitions are given below:

5.1.1 WSConstraint Object

This is a high-level object that models the Web service constraint information as a

whole. The class definition is shown in Figure 5.1. The variables are as given below:


public class WSConstraint implements java.io.Serializable


public String serviceKey;
public String interfaceKey;
public Hashtable operationConstraintList;
public Hashtable serviceConstraintList;
public Hashtable interAttributeConstraints;


Figure 5.1 Class Definition of the WSConstraint Object

1. serviceKey: This variable gives the service key of the service for which this
particular object is a constraint specification. This is a Universal Unique Identifier
(UUID) generated by the UDDI registry at the time the service is registered by the
service provider. We use this key to link the service specification in the UDDI
registry with the constraint specification in our registry. For the service
requestor's constraint specifications, we use the same class definition. The
serviceKey variable is replaced by the string "requestor" in this case, since there
is no registered service specification in the UDDI registry for the service
requestor during the discovery phase.









2. interfaceKey: This variable gives the key of the service interface that this
particular service (i.e., the one that we are specifying constraints for) implements.
This is also a UUID generated by the UDDI registry when the service interface is
first registered. As we explained in Chapter 3, the service requestor finds a
suitable interface using the UDDI find mechanism. The key of this interface is
then used to retrieve the constraint specifications of those services that implement
this particular interface. This step locates the appropriate constraint specifications
to match.

3. operationConstraintList: This data structure gives a list of all the operation
constraints associated with this service. It is implemented as a hash table with the
operation name as the key. The class definition of each operation constraint object
is explained in Section 5.1.2.

4. serviceConstraintList: This data structure gives a list of all the service constraints
that characterize this service. It is implemented as a hash table with the service
key as the lookup key of the hash table. For each service implementation, we can
have only one service constraint object. So, there is no real need for a hash table.
We have still used a hash table in order to simplify any future changes that may
be needed to this structure. The class definition of each service constraint object is
explained in Section 5.1.3.

5. interAttributeConstraintList: This data structure gives the inter-attribute
constraints among all input, output, operation and service attributes. It is
implemented as a hash table with the name as the lookup key. The class definition
for each inter-attribute constraint object is explained in Section 5.1.5.

5.1.2 OperationConstraint Object

This object models the constraint specification for an entire operation as a whole.

The class definition is given in Figure 5.2. It consists of the following variables:


public class OperationConstraint implements java.io.Serializable


public String interfaceKey;
public String operationName;
public Hashtable attributeConstraintList;




Figure 5.2 Class Definition of the OperationConstraint Object

1. interfaceKey: This variable gives the interface key of the service interface that this
operation belongs to. Even though this key appears as a variable of the
WSConstraint object, which contains this object, it is provided here for future









extensions. A service implementation can implement two interfaces at a time, just
as a Java Class can implement two Java Interfaces. In order to distinguish the
operations of these different interfaces, the interface key variable has been
duplicated here also.

2. operationName: This variable gives the name of the operation for which this
object provides the constraint specification. It is the key used to look up this
object in the hash table contained in the WSConstraint class.

3. attributeConstraintList: This data structure gives the actual constraint
specification for this particular operation. It gives the constraints for input, output
and operation attributes of this operation. The class structure used for each
attribute constraint object is explained in Section 5.1.4.

5.1.3 ServiceConstraint Object

This object gives the constraint specification for service attributes. The class

definition is shown in Figure 5.3. It contains the following variables:


public class ServiceConstraint implements java.io. Serializable

{
public String serviceKey;
public Hashtable attributeConstraintList;
I


Figure 5.3 Class Definition of the ServiceConstraint Object

1. serviceKey: This variable gives the service key of the service that this constraint
specification belongs to. It is provided here so that ServiceConstraint objects can
be shared among higher level WSConstraint objects.

2. atttributeConstraintList: This data structure gives the constraint specification for
the service attributes of this particular service. The class structure used for each
attribute constraint object is explained in Section 5.1.4.

5.1.4 AttributeConstraint Object

This object is used to specify the attribute constraints. It can be used for constraint

specification of input, output, operation and service attributes. The class definition is


shown in Figure 5.4. It consists of the following variables:










public class AttributeConstraint implements java.io.Serializable
{
public String name;
public String type;
public String keyword;
public boolean negotiable;
public Vector valueList;
public int priority;
public boolean nomatch;



Figure 5.4 Class Definition of the AttributeConstraint Object

1. name: This variable gives the name of the particular attribute of the service,
operation, input or output attribute of which this object is a constraint
specification.

2. type: This variable gives the data type of the attribute. The data types can be
string, integer, float, date, time, datetime, or duration.

3. keyword: This variable gives the keyword associated with each attribute. The
keyword helps in identifying the kind of constraint being specified. The
constraints can be specified on a range of values, on an enumeration of values, or
on a single value along with comparison operators. So, the keywords can be
range, enumeration, =, !=, >, <, >=, and <=

4. valueList: This variable gives the list of values that a particular attribute can take.
The form of this list depends on the keyword specified. If the keyword is range,
this list, implemented as an object of the class java.util.Vector, contains two
elements that denote the start and the end of the range, respectively. If the
keyword is enumeration, this list contains all the valid attribute values. If the
keyword is one of the six comparison operators, the list just contains a single
value.

5. negotiable: This variable determines whether a particular attribute constraint is
flexible or not. If a constraint is flagged as non-negotiable and it is not satisfied,
constraint matching terminates and the Constraint Satisfaction Processor reports a
constraint mismatch.

6. priority: In case an attribute constraint is negotiable, this variable determines its
priority, and hence its order of evaluation. As stated above, non-negotiable
attributes are evaluated first followed by attributes in the order of decreasing
priority.

7. nomatch: This variable is used to differentiate those attributes for which there is a
constraint specification from those for which there is none. When specifying
constraints for an operation, for example, a service provider or a service requestor









may not want to specify constraints on some attributes. This variable is set to true
in these cases. The Constraint Satisfaction Processor tries to match all attributes
by default. But when there are no constraints for a particular attribute, the value
list variable is empty. Thus, there is no need to match it with the constraint of the
other party. Only those attributes for which the nomatch variable value is false,
are matched.

5.1.5 InterAttributeConstraint Object

This object is used to specify the constraints that specify the relationship among

different attributes of the service. For example, we can have an inter-attribute constraint

as, "ifx > 50 then y > 70". Each inter-attribute constraint has an if part and a then part. In

order to model constraints which do not explicitly have such an implication structure (for

example, x + y >z), we can set the if part to true and state the remaining constraint in the

then part. The class definition for this object is given in Figure 5.5. The variables

contained in this object are as follows:



public class InterAttributeConstraint implements java.io.Serializable
{
public String name, antecedence, consequence;
public int priority;
public boolean negotiable;
}


Figure 5.5 Class Definition of the InterAttributeConstraint Object

1. name: This variable assigns a unique name to the inter-attribute constraint. This
name is used as the key to lookup this object and thus all inter-attribute
constraints within an object must have unique names.

2. antecedence: This variable specifies the if part of an inter-attribute constraint. It is
a boolean expression specified in the Disjunctive Normal Form.

3. consequence: This variable specifies the then part of an inter-attribute constraint.
Like the antecedence, this is also a Boolean expression specified in the
Disjunctive Normal Form. However, in many cases, the consequence is generally
one predicate that must hold if many other predicates hold.

4. negotiable: This variable determines if an inter-attribute constraint is negotiable
or not. Non-negotiable constraints are evaluated first. If a non-negotiable









constraint is violated, the Constraint Satisfaction Processor terminates the
evaluation process and reports a constraint mismatch.

5. priority: This variable gives the priority assigned to the inter-attribute constraint
during constraint specification. Inter-attribute constraints are always evaluated in
priority order.

Instances of the Java classes WSConstraint, OperationConstraint and

ServiceConstraint are used to store the constraint information. However, CSP uses a

slightly different constraint object structure for actual matching. We match constraints

specified by the service provider and the service requestor for a particular operation. At

run time, we retrieve the WSConstraint object belonging to each service provider, and

extract the required OperationConstraint object and the ServiceConstraint object. These

objects are then mapped to the Constraint object structure used by CSP. This structure is

shown in Figure 5.6. The variables used are similar to those of the OperationConstraint

and WSConstraint objects and hence are not repeated here.


public class Constraint implements java.io. Serializable

{
public Hashtable attributeConstraintList;
public Hashtable interAttributeConstraints;
I


Figure 5.6 Class Definition of the Constraint Object

We now describe the structure of the result returned. The result returned by CSP

contains the class structure shown in Figure 5.7. The variables are as follows:

1. satisfied: This variable determines whether the constraint matching process was
successful or not. Details such as what attributes were violated, if any, what
combinations of values are valid, etc., are determined by the other variables.

2. myOwnViolated: This variable determines which constraint was violated.
Traditionally, CSP denotes the two input constraint objects as MyConstraint and
YourConstraint. In our system, MyConstraint is the constraint object of the
service provider and YourConstraint is the constraint object of the service









requestor. If the variable satisfied were set to false, a true value of
myOwnViolated would mean that the provider constraint was violated, and a false
value of myOwnViolated would mean that the requestor constraint was violated.

public class CSPResult
{
boolean satisfied;
boolean myOwnViolated;
boolean attribute Violated;
boolean iacViolated;
Vector violatedConstraint;
Vector violatedList;
Vector ISList;
Vector combinationList;



Figure 5.7 Class Definition of the CSPResult Object

3. attribute Violated: This variable determines whether any of the attribute
constraints were violated.

4. iacViolated: This variable determines whether any of the inter-attribute
constraints were violated.

5. violatedConstraint: This data structure gives us the list of violated attributes, if
any. It is implemented as an object of the class java.util.Vector [8].

6. violatedList: This data structure gives us the list of violated inter-attribute
constraints, if any. It is also implemented as an object of the class java.util.Vector
[8].

7. ISList: This data structure gives us the list of the interval sets for each attribute
that satisfy both the attribute constraint objects. Thus, all possible permissible
ranges for each attribute are contained in this list.

8. combinationList: This data structure gives us the combinations of values which
when used do not violate both the inter-attribute constraint objects. While
invoking a service, the service requestor must not only check that the attribute
values sent conform with the ISList, but must also check with the combinationList
to see if a valid combination is being used for invocation.

This concludes the description of the data structures used in the constraint-based


broker system.









5.2 IBM UDDI v2.0 Business Test Registry and Persistent Object Manager

We use the IBM UDDI Version 2.0 Business Test Registry to register the service

specifications. This registry implements most of the features provided by UDDI v2.0. In

order to familiarize the general e-business community with UDDI, IBM has made this

registry accessible over the worldwide web. As this User Interface is already well

developed, we have used it in our system instead of developing a similar one.

During the registration phase, we use the IBM UDDI Version 2.0 Business Test

Registry to register UDDI-specific service information. When registering a service for the

first time, the UDDI registry generates a service key to be used for uniquely identifying

the service later. This service key is returned to the service provider. The constraint-based

broker then asks the service provider to enter this service key, along with the service

interface key of the service interface that this service implements and the URL of the

WSDL document describing the service. Once that is done, the information such as

service and operation attributes, input and output attributes of each operation are

retrieved and the service provider uses the GUI to specify constraint information.

During the discovery phase, the service requestor first uses the UDDI registry to

find the service interface that conforms to his/her request. The Test Registry provides

several ways of finding this information. The service requestor can enter the name of the

interface, or the category information, etc., to locate the appropriate service interface.

Once this is done, the requestor uses our GUI to specify the interface key and the location

of the extended WSDL document describing the interface. This document contains the

names of operation and service attributes in addition to the normal WSDL elements, and,

hence, is an extended WSDL document. The requestor then uses the GUI to specify

his/her constraint information. This information is then matched with that of all the









registered service providers who implement the interface. The match result determines

the best provider for a particular request.

POM maps the constraint objects into a relational table. We show the "create

table" command for the WSConstraint object in Figure 5.8. Similar tables are created to

store the other objects. Each table is assigned a primary key column when it is created.

This is called the Object Identifier (OID) column. This key can be used to update or

delete the object once created. The WSConstraint object contains three hash tables. These

hash tables are not SQL datatypes. A new table is created for every non-SQL data type

[11]. Another table called the Foreign Keys table is created to link the objects in the

original table with the ones created in the new table.


CREATE TABLE WSConstraint
(
OID INTEGER,
serviceKey VARCHAR(255),
interfaceKey VARCHAR(255),
operationConstraintList SERIALIZE(java.util.Hashtable),
serviceConstraintList SERIALIZE(java.util.Hashtable),
interAttributeConstraints SERIALIZE(ava.util.Hashtable),

PRIMARY KEY(oid)



Figure 5.8 Create Table Command of the Persistent Object Manager

5.3 IBM Web Services Toolkit

Web services are programmatically accessible over the Internet. It therefore

follows that the registration and discovery of such services must also be

programmatically accessible. The IBM Web Services Toolkit [7] provides this facility.

This toolkit has methods using which a service provider can register his/her service with

the UDDI registry given the WSDL document describing the service as input. Similarly,










if the appropriate criteria are given, a service requestor can find a suitable service

provider.

We have extended these methods to allow programmatic constraint registration

and constraint matching. The service provider can give an extended WSDL document,

which contains both the UDDI information and the constraint information as input to the

method used for registration. The UDDI information will be registered with the UDDI

registry, and the constraint information will be registered with POM. Similarly, during

the discovery phase, the service requestor can use thefind methods from the Toolkit to

find an interface. The constraint object and the interface key can then be provided as

command-line input to our extendedfind method. The result of the constraint match will

then be returned to the requestor.

5.4 Sample Scenario

In this section, we illustrate the entire constraint specification and matching

process with screenshots. We will use the constraint specifications of the service

requestor and the service provider given in Chapter 3 for this purpose. These

specifications have been reproduced in Figures 5.9 and 5.10 for completeness.

SERVICE: E-AUCTION
ATTRIBUTE CONSTRAINT:
Svcbasecost Float EQUAL 4

OPERATION: BUY
ATTRIBUTE CONSTRAINT:
Buyin item String ENUM {"Computer"}
Buy_inprice Float RANGE [200.00..5000.00]
Buyout ordero String
Buy_op_cost Float LESSERTHAN 3

INTERATTRIBUTE CONSTRAINT:
IC1 Buy_in_price>=2500.00 Implies Buy_op_cost<=2


Figure 5.9 Constraint Specification of a Web Service Requestor











SERVICE: E-A AUCTION
ATTRIBUTE CONSTRAINT:
Svcbasecost Float EQUAL 4

OPERATION: BUY
ATTRIBUTE CONSTRAINT:
Buy in item String ENUM {"Printer", "Con
Buy_inprice Float RANGE [100.00..5000.0C
Buyout ordemo String
Buy_op_cost Float LESSEQUAL 3

OPERATION: SELL
ATTRIBUTE CONSTRAINT:
Sell in item String ENUM {"Printer", "Comput(
Sell_inpricequote Float RANGE [100.00..5000.00]
Sell out ordemo String
Sell_op_cost Float EQUAL 3

OPERATION:CHECKSTATUS
ATTRIBUTE CONSTRAINT:
Checkstatus in ordemo String
Checkstatus out status String ENUM {"Accepted", "I
Checkstatus_op_cost Float EQUAL 3

INTERATTRIBUTE CONSTRAINT:
IC1 Buy in item= "Computer" Implies Buy_inprice>800
IC2 Buy_in_price>=3000.00 Implies Buy_op_cost = 1


iputer", "Scanner"
, "Scanne





er", "Scanner"}


Rejected"}


Figure 5.10 Constraint Specification of a Web Service Provider

Though we have not specified the priority and negotiation information in Chapter

3, we have included it in the screenshots. We will describe the GUI for the registration

phase in Section 5.4.1, and present the GUI for the discovery phase with constraint match

results in Section 5.4.2.

5.4.1 Registration

We present step-by-step screenshots to show service registration by the service

provider. This registration process is the same for any kind of service provider. Before

any process can be started, the service provider is given the steps necessary to complete

the registration.











As shown in Figure 5.11, the service provider uses the IBM Test Registry to

register his service with the UDDI registry in the first step. In the second step, the

provider gives the necessary service information to the constraint-based broker, and in

the third step the service provider specifies constraint information and obtains an

extended WSDL document containing the service and constraint information.








Howto Register a Service

SU1 the IBM Teat Restry to ente IUDD~ p.efl ILntmation or web
erylew regiztration.

A. nter th c-81r-i Key, 6-l1ri Interfhg Ky, -d the WSDL/UML
Documnt loatln dcrind th. .ervic to spec. contrints.

Obtain a new SL Document with the cotraint Informtion
-em dded inide.





Figure 5.11 Screenshot Showing all the Steps Necessary in the Registration Process

In Figure 5.12, we see the use of two separate frames for the Graphical User

Interface (GUI) of the constraint-based broker. This interface allows the user to access

the UDDI registry and our registry in a single session. The service provider uses the GUI

on the left hand side to register service information with the UDDI registry. The provider

then uses the GUI on the right side to specify the service key, the service interface key

and the location of the WSDL document describing the service implementation as shown.

Thus with the help of this GUI, the service provider registers service information with the

UDDI registry and constraint information with the UF registry.





























UDDI Business Registry Version 2
Universal Description, Discovery, and Integration

Technical Model Details

The details ofthe selected technical model are shown below



UUID 963D35DO-C367-11 D6-8C2F-000629DCOA7B

E-Auction Service Interface



This is atest tModel en



htto JAn.ww cise ufl edul-s dJEAS- This is a test tModel
interface eml

LK,,[ "" lii I'


UDDI Business
Registry
Logout
Publish
Find
Account


Reae Lns
Wo Stie and


Please enter the information belowto register
service constraints.

Servce nplementation Key
iC860AAO-C4B9-11 D-8C2F000629DCOA7B

Service Interface Key
UUID 963D35D-0C367-11D 8C2F000629DCOA7B

TRL ofthe Service Implementation Document
http /A ecise ufl edu/spd/EAS wsdl


i1 I II I S



Figure 5.12 Screenshot Showing the Service Provider Entering Service Information


Constraints are specified on one operation at a tnme. Please choose the operation from the list below to proceed.



Operation Name uy

sell
checkstatus


Figure 5.13 Screenshot Showing the Service Provider Selecting an Operation



The WSDL document contains a reference to the service interface document. The



broker extracts the input, output, operation and service attribute information from both of


81 11 1 0600 Application service provider


lI IS


S Fie Edit View Favorites Tools Help

Back Forward Stop Refresh Home Search Favortes Hitory Mal Print Real.cm
Links CbLink JChat CustomizeLinks ExploretheWeb t FreeHotmall []Hotmall Maps NewUser MNews Search [] 5hopplng 2Support MTheA.rena ]TheMall
I- 1 I .. P_ G


UNSPSC v7 3


-I------IA1....1-L...L----------------------












these documents. Constraints are specified one operation at a time. The service provider


is then asked to choose the operation for which he/she wants to specify constraint


information. For the E-Auction service discussed in Chapter 3, we have three operations:


buy, sell and checkstatus. This list of operations is shown in Figure 5.13.


On selecting the appropriate operation, the service provider can specify


constraints on each attribute. As shown in Figure 5.14, the service provider gives the


keyword, valuelist and priority information for the input attributes item and price and the


operation attribute cost. The output attribute orderno has no constraints, and the valuelist


and priority information are therefore left blank.



File Edit Vew Favorites Tools Help

Back Forward Stop Refesh Home earch Favorites History Mall Pint Real.com
S * I *
|ai n~p


Input Constraints :
For each input attribute specify the following fornaton

Input Attribute Type Keyword Negotiable
pnce float IRNGE I
Item string IENU | I



Output Constraints:
For each output attribute specify the following mfonnation

Output Attribute Type Keyword Negotiable
ordemo string IENUi I I



Operation Constraints :
For each operation attabute, speciy the following tfornaton

Name Type Keyword N
cost float pI I


egotiable


Value List [Piority
[1[ 00 5000 00] IF3
ilputer ,"Sc nner"} I3






IValue List Priority







VI alueList Priority
113 V


Figure 5.14 Screenshot Showing the Specification of Attribute Constraints


Inter-attribute constraints are also specified at this time, as shown in Fig 5.15. The


service provider specifies an inter-attribute constraint stating that if the item to be bought


I












is a computer, the price must be greater than $800.00. Each input, output or operation


constraint is assigned a priority value and a negotiable/non-negotiable value. After the


service provider specifies constraints for all operations, service attribute constraints are


specified as shown in Figure 5.16.


P Ad It-tobt,,L-t~it. Mi-tft ntcuctE~ -,pciidd b E.think In.


Please enter the following information to specify the interattribute constraint. The 'if and 'then' clauses can be complex Boolean expressions. You can add more
predicates to the existing ones by clicking on the More Predicates button. Note: The Boolean Expressions are assumed to be in the Disjunctive Normal Form. For more
information on this particular form click here
If

buy-nterm I "Co mputer"

Then

buy_,n_price F o1800 00

Negotiable IVes_
Pnonty F3l





Figure 5.15 Screenshot Showing the Specification of Inter-Attribute Constraints



File Edit Vew Favorites Tools Help
4`1 ~, + 0 a- b
Back Forward Stop Refesh Hone each Favorites History all Print Real.co
II .. -1l a* -
i |_ 1 i i'J


You have finished specifying constraints for operations that you wish to provide. Please enter the service constraint information below.
Service Constraints :

Name ype Keyword Negotiable ValueList Priority
basecost flot *fi F I I D| F F


Figure 5.16 Screenshot Showing the Specification of Service Attribute Constraints


After specifying service constraints, the registration process is completed. An


extended WSDL document containing the constraint information appended to the initial









65




service description information is generated. A portion of this extended document is



shown in Figure 5.17. Here, we show the constraints tag appended as the last child of the



definitions tag. This tag has a number of constraint tags as its children. Each constraint



tag gives the constraint specification of each operation. This is specified by an



operation constraint tag. This tag has a number of input constraint, output constraint,



and operation constraint tags as shown. Each such tag describes the name, type,



keyword, etc. information about that particular constraint.





File Edit View Favorites Tools Help
+* -+ M I a a a 9
Back Forward Stop Refresh Home Search Favortes History Mail Print Realcom

1 1 *1 j ,C1


S xmlns; nterface="http://wwl.eauction.com/EAuctionService-interface' xmlns:soap="http://schemas.xmlsoap.org/ssdl/soap/"
xmlns; sd="http://www.v3.org/2001/XMLSchema">
This service provides an implementation of a standard interest calculation service.


Electronic Auction Service

Electronic Auction Service



constraints xmlns="">
constraint operationname="buy">

item
string
ENUIMERATE
{"Printer" ,"Computer" "Scanner" }
true
PRIORITY[3]

-
price
float
RANGE
val ueList>[100.00 .. 5000.00 ]
true
PRIORITY[3]


cost
float
LESSEQLAL
3.0
true
PRIORITY[3]



I F Local ntranet


IC Done



Figure 5.17 Screenshot Showing the Extended WSDL Document



This concludes the registration phase.













5.4.2 Discovery


During this phase, the service requestor first uses the UDDI mechanism to locate


a suitable service interface. The service requestor then enters the interface information


such as the interface key and the location of the interface document, as shown in Figure


5.18. We see a similar Graphical User Interface as that used for the registration phase. On


the left side is the Graphical User Interface for the UDDI registry, and on the right side


we have Graphical User Interface for the constraint-based broker.





:- 1" -1 :
-, -, ,- zi [] .4 4 I z I

.' -, _;,, j,, 2 , J, _, ..
I- [ .. .. .


UDDI Business Registry Version 2
Universal Description, Discovery and Integration Please enter the info
your request ronstra
Technical Model Details
The details ofthe selected technical model are shown below Please use your browser's
Back button to return to the previous page OR Press the New Search button to search Serice Interface Key
again


UUID 963D35DO-C367-11 DB-8C2F-000629DCOA7B

E-Auction Service Interface



This isaesttModel en



htt //www cise ufl edul-sdJEAS- This is a test tModel
interface xml



81 11 21 06 00 Applicaon service providers UNSPSC v7 3

I -- i '


rmation requested to specify
lints.


UUID 963D35DO-C367-11 D6-BC2F-000629DCOA7B

URL ofSece Interface Document
http /vww cise ufl edu/ spd/EAS-interface xml















4I I _


Figure 5.18 Screenshot Showing the Service Requestor Entering Interface Information


The service requestor uses similar steps as the service provider to specify the


attribute and inter-attribute constraints for the desired operation. The attribute and inter-


attribute constraints are as specified in Figure 5.10. When the service requestor submits


his request, the interface key is used to retrieve constraint specifications of all service


UDDI Business
Registry
Publish
Find
Account


ReatdLns
We Gevis :a-d
-D I











providers who implement that particular interface. After the constraint matching is done,

the service requestor gets back the service key and the service access point of the service

that best matches his/her constraints. This is shown in Figure 5.19. The requestor can

access a detailed list that gives the satisfied value ranges for all the attributes and all valid

combinations of these ranges by clicking on the More Information button. He/she can

start a new session by clicking on the Start next session button.



I Fle Edit V -ew Favorite Tools Hell
Back Forard top Refresh Home Search Favoites History Mal Print Real.cor
Links bLink Chat CustomizeLinks ExploretheWeb FreeHotmal [ Hotmal Maps NewUser [ News Se arch [ Shopping ~ support TheArena TheMall
I G
I------------------------------------------------------------------------------------


The following matches to your query were found:
1. Service Key :C860ASAO-C4B9-11D6-8C2F-000629DCOA7B
Service Access Point :http:/Aww .getinterest.comlinterestcalculationservice
You can get more information such as the possible attribute values and their combations that you can use without violation of any constraints by checking on the button below






Figure 5.19 Screenshot Showing the Result of the Constraint Match

The detailed result is shown in Figure 5.20. We see that the input attribute item is

restricted to the value Computer and the input attribute price is restricted to a range of

[200.00..5000.00]. The output attribute orderno has no restrictions on its value. The

operation attribute cost is restricted to values less than 3. The valid combinations are

generated keeping the inter-attribute constraints of both the service provider and the

requestor in mind.














Back Forward top Refresh Home Search Favorltes Hitory Mal Print Real.rom
jLinks ]bLink IChat )CustomizeLinks LExploretheWeb #)FreeHotmall R Hotmall Maps NewUser News ]Search R Shopping
I .


Possible values for each attribute are :

IName
buy outordeno
Ibuy ltem
Is basecost
Ibuy op cost'


ValueList
[No Constrant]
["Computer "]
[4 0,4 0]
(-Infa~ tyr, 2 0]0,3 0)


Ibuy m_pnce (2500 0,5000 0](800 0,2500 0][200 0,800 0]

Possible combinations are:

Combination Number buyout ordernmo buy in item svc basecost buy_op_cost buy pricee
1 No Constrat "Computer" 1[4 0,4 0] (-Inty,2 0] 2500 ,5000 0]
2 Constrat "Computer" 1[4 0,4 0 -Ifty, 0] ( 0,2500 0]
3 No Constrat Computer" [4 0,4 0] (2 0,3 0) 0 00 0]


Figure 5.20 Screenshot Showing the Detailed Result of the Satisfied Constraint Match


Using the information obtained by constraint matching, the service requestor can


invoke the service using valid parameters. This will assure to a greater extent than before


that the service will not fail. This concludes the discovery phase.


The service requestor can now use the service key information to learn more


about the service from the UDDI registry, and use the access point to invoke the service.


Thus constraint matching guarantees that a time-consuming service will not be


invoked without producing meaningful results. This saves the service requestor's


resources to a large extent.














CHAPTER 6
CONCLUSION AND FUTURE WORK

6.1 Summary

Adding constraints to the specifications of Web services and Web service requests

captures more accurately the limitations of services registered by service providers and

the requirements of service requestors. As a result, it also allows the service broker to

better select the proper providers that satisfy the requestors' requirements. Without

constraint specification and processing capabilities, a service broker may identify a

service provider for a request that cannot produce useful information to the requestor. A

time-consuming service operation can be invoked without producing the desirable result

due to a mismatch of provider and requestor constraints.

In this work, we have extended WSDL to include constraint specifications in both

service specifications and service requests. We have also described the Constraint-based

Requirement Specification Language by giving examples, the architecture of a

Constraint-based Broker, the constraint matching technique, and the implementation

details about the broker with a sample scenario. We believe that the constraint-based

brokering service is a significant improvement over the existing implementations of the

UDDI service registry.

6.2 Limitations and Future Work

This is our first venture of integrating our constraint satisfaction processor, which

was developed for an automated negotiation system, and a persistent store developed for

an Event Server, with the UDDI registry that IBM implemented for publishing and









discovery of Web services. Due to the different initial objectives of these systems,

integrating them involved a nontrivial mapping process. The integrated system can,

however, be extended to make it more complete as follows.

One extension can be to tightly integrate the components of these two registries.

Since we used a publicly available UDDI registry, we do not have access to the source

code and hence are not able to modify it accordingly. Instead, we used another registry

(POM), to store constraint information. The system appears as one to the user (either the

service provider or service requestor), but the registration and the discovery phases have

to be separately handled when using the Graphical User Interface. The user must first

register to the IBM UDDI version 2.0 Business Test Registry with UDDI information,

and then use our GUI to register constraint information. However, if the user submits an

extended WSDL document, the registration is automatically done in both the registries

and this difference is not noticed.

Another significant advancement can be achieved by handling constraints that

generate an exhaustive number of combinations. For example, with a constraint of type

A+B>100, consider that A and B both can take values from the range [1..100]. For the

value '1' for A, we have satisfying values of B as [100]. For the value '2' for A we have

the satisfying values of B as [99.. 100]. Thus, there are a total of 100 combinations. These

constraints are checked better by the provider stub, but can be incorporated at the broker

site for better matching.

Our future work is on the integration of the Constraint-based Broker with an

Event-Trigger-Rule Server to perform event subscription, event filtering and notification,

and rule processing in the Web service infrastructure to support collaborative e-business,






71


e-government, and biomedical research and applications. We are also exploring the use of

the Constraint-based Broker to support a semi-automated approach to discover composite

Web services.















APPENDIX A
SCHEMA OF THE EXTENDED WSDL DOCUMENT

xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/
targetNamespace=http://schemas.xmlsoap.org/wsdl/
elementFormDefault="qualified">



















This type is extended by component types
to allow attributes from other namespaces to be added.






















































maxOccurs= "unbounded"/>
maxOccurs= "unbounded"/>

maxOccurs="1"/>




to support extensibility elements























































































maxOccurs= "unbounded"/>























































="0" maxOccurs="unbounded"/>







="0" maxOccurs="unbounded"/>

















































minOccurs="0" maxOccurs="unbounded"/>











minOccurs="0"/>
minOccurs="0"/>




use="required"/>

























maxOccurs="unbounded"/>

maxOccurs= "unbounded"/>












maxOccurs= "unbounded"/>




































maxOccurs= "unbounded"/>


































































maxOccurs= "unbounded"/>
maxOccurs= "unbounded"/>
maxOccurs= "unbounded"/>












maxOccurs= "unbounded"/>
maxOccurs= "unbounded"/>
maxOccurs= "unbounded"/>

































element name="name" type="string"/>






























































maxOccurs= "unbounded"/>






















maxOccurs= "unbounded"/>












maxOccurs= "unbounded"/>













maxOccurs="1"/>
maxOccurs="1"/>























APPENDIX B
BNF SYNTAX OF OBJECT-ORIENTED CONSTRAINT SPECIFICATION
LANGUAGE (OOCSL)


entity ::= ENTITY IDENTIFIER BL ATTRIBUTE_CONSTRAINT COLON aclist
INTER ATTRIBUTE CONSTRAINT COLON iac list BR


ac list ::= ac list ac


ac ::= path atttype att_cons priority

att_type ::= STRINGTYPE
INTEGERTYPE
FLOATTYPE
BOOLEANTYPE
DURATIONTYPE
DATETIMETYPE
TIMETYPE
DATETYPE

att cons::= ENUMERATION LBRACKET value list RBRACKET
ANY
EQUAL val
SLESSTHAN val
SLESSEQUAL val
SGREATERTHAN val
SGREATEREQUAL val
SNOTEQUAL val
DERIVED
RANGE LBRACKET numeric DOT DOT numeric RBRACKET


value list :: str val list
int val list
real val list
bool val list


str val list := STRING









STRING COMMA str val list


int val list ::= INTEGER
INTEGER COMMA intvallist


real val list ::= FLOAT
|FLOAT COMMA realvallist


bool val list ::= YES


SNO


numeric ::= INTEGER
FLOAT


val ::= numeric
STRING

priority ::= NONNEGOTIABLE
PRIORITY LBRACKET INTEGER RBRACKET


iac list ::= iac list iac



iac ::= IDENTIFIER constraint IMPLIES constraint priority


constraint ::= bool or



bool or ::= bool or OR bool and
bool_and


booland ::= booland AND boolcompare
Sbool_compare


bool_compare ::= expr EQ expr
Sexpr NOTEQ expr









Sexpr LESS expr
Sexpr LESSEQ expr
expr GREATER expr
expr GREATEREQ expr
expr

expr ::= expr PLUS term
Sexpr MINUS term
term


term ::= term


TIMES factor
Term DIVIDE factor
factor


factor ::= LPAREN bool
path
val
TRUE
FALSE


or RPAREN


path ::= IDENTIFIER
I IDENTIFIER DOT path















LIST OF REFERENCES


[1] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen,
S. Thatte, D. Winer, "Simple Object Access Protocol (SOAP) 1.1,"
http://www.w3.org/TR/SOAP, May 2000. Accessed on November 20, 2001.

[2] P. Brittenham, F. Curbera, D. Ehnebuske, S. Graham, "Understanding WSDL in a
UDDI Registry," http:// www-106.ibm.com /developerworks /webservices
/library/ws-wsdl/, September 2001. Accessed on January 10, 2002.

[3] E. Christensen, F. Curbera, G. Meredith, S. Weerawarna, "Web Services
Description Language (WSDL) 1.1," http://www.w3.org/TR/wsdl, March 2001.
Accessed on November 20, 2001.

[4] C. Huang, "A Web-based Negotiation Server for Supporting Electronic
Commerce," Ph.D. Dissertation, Department of Computer and Information
Science and Engineering, University of Florida, 2000.

[5] IBM DeveloperWorks, "Web Services Architecture Overview," http://www-
106.ibm.com/developerworks/webservices/library/w-ovr/, September 2000.
Accessed on October 10, 2001.

[6] IBM UDDI Business Test Registry, https://uddi.ibm.com/testregistry/
registry.html. Accessed on February 10, 2002.

[7] IBM Web Services Toolkit, http://www.alphaworks.ibm.com/tech
/webservicestoolkit, April 2002. Accessed on April 25, 2002

[8] Java 2 Platform Standard Edition, v 1.3.1, API Specification
http://java.sun.com/j2se/1.3/docs/api/. Accessed on March 3, 2002

[9] F. Leymann, "Web Services Flow Language (WSFL 1.0)," http:// www-
3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf, May 2001. Accessed
on November 25, 2002

[10] Y. Liu, F. Yu, S. Y. W. Su, and H. Lam, "A Cost-Benefit Evaluation Server for
Decision Support in E-business," to appear in Journal of Decision Support
Systems and Electronic Commerce, 2002.









[11] A. Shenoy, "A Persistent Object Manager for Java Applications," M.S. Thesis,
Department of Computer and Information Science and Engineering, University of
Florida, 2001.

[12] B. Sleeper, "Defining Web Services," http:// www.stencilgroup.com
/ideas_scope_200106wsdefined.html, June 2001. Accessed on February 2, 2002.

[13] B. Sleeper, "Why UDDI will succeed quietly," http:// www.stencilgroup.com
/ideas_scope_200104uddi.pdf, April 2001. Accessed on February 14. 2002.

[14] S. Y. W. Su, J. Dujmovic, D. S. Batory, S. B. Navathe, and R. Elnicki, "A Cost-
Benefit Decision Model: Analysis, Comparison, and Selection of Database
Management Systems," ACM Transactions on Database Systems, Vol. 12, No. 3,
pp. 472-520, Sept. 1987.

[15] S. Y. W. Su, C. Huang, J. Hammer, Y. Huang, H. Li, L. Wang, Y. Liu, C.
Pluempitiwiriyawej, M. Lee, and H. Lam, "An Internet-based Negotiation Server
for E-Commerce," VLDB Journal, Vol. 10, No. 1, pp. 72-90, August 2001.

[16] UDDI.org, "UDDI Executive White Paper," http://www.uddi.org/pubs/
UDDI Executive_White Paper.pdf, November 2001. Accessed on March 15,
2002.

[17] UDDI.org, "UDDI version 2.03 Data Structure Reference,"
http://www.uddi.org/pubs/DataStructure-V2.03-Published-20020719.pdf, July
2002. Accessed on August 10, 2002.

[18] UDDI.org, "UDDI version 2.04 API Published Specification,"
http://www.uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf, July
2002. Accessed on August 25, 2002.

[19] F. Yu, "A Cost-Benefit Evaluation Server for Supporting General Decision-
making," M.S. Thesis, Department of Computer and Information Science and
Engineering, University of Florida, 2001.















BIOGRAPHICAL SKETCH

Seema Degwekar was born in Thane, India, on November 10, 1978. She received

her Bachelor in Computer Engineering degree from Vivekanand Education Society's

Institute of Technology, affiliated with the Mumbai University, in June 2000. She stood

eighth in the University in the Final Undergraduate Examination among approximately

2000 students.

She joined the CISE graduate program at the University of Florida in August

2000. She worked at the Database Research and Development Center from August 2001.

She graduated in December 2002 with a Master of Science degree.

While at the University of Florida, she worked as a teaching assistant and also

taught an undergraduate course for two semesters. Her research interests include web

databases, query processing, and heterogeneous database systems.