A Web Services Matchmaking Engine for Web Services

3 downloads 29311 Views 197KB Size Report
EC-Web, DEXA 2003 conference, Prague 1-5 September 2003. A Web Services ... and buying Capacitors can be created with WSME is given. Finally, conclu-.
EC-Web, DEXA 2003 conference, Prague 1-5 September 2003

A Web Services Matchmaking Engine for Web Services Christian Facciorusso1, Simon Field2, Rainer Hauser1, Yigal Hoffner1, Robert Humbel1, René Pawlitzek1, Walid Rjaibi3 and Christine Siminitz4 1

IBM Research, Zurich Research Laboratory, 8803 Rüschlikon, Switzerland Contact author: [email protected] 2 Matching Systems Ltd., Switzerland [email protected] 3 IBM Toronto Software Laboratory, Canada [email protected] 4 IBM Storage Software Products Division, NC, USA [email protected]

Abstract. This paper concentrates on the issue of matchmaking in the context of web services. It provides a brief review of the difference between directory services and matchmaking facilities and explains why directories such as UDDI are important but insufficient for web services and need to be complemented with advanced matchmaking facilities. It discusses the requirements that web services place on matchmaking, namely symmetry of information exchange, the ability of each party to specify requirements of the other party, rich languages to describe services and their consumers as well as their demands, and the ability to dynamically update and configure what is being offered. These requirements are addressed by the Web Services Matchmaking Engine (WSME) - a powerful matchmaking engine capable of matching complex entities, and a Data Dictionary Tool for defining the language of the corresponding matchmaking process. The WSME matchmaking process and property and rules languages are described. An example of how a dynamic market for selling and buying Capacitors can be created with WSME is given. Finally, conclusions and possible future avenues of work are presented.

1

Finding Compatible Web Services and Consumers

Ensuring that web service providers and consumers are compatible business partners will become increasingly important as web service technology and its exploitation for serious business purposes become more pervasive. In this context, several issues are of paramount importance: • Facilitating the specification of complex information models by developing appropriate languages for describing services as well as consumers. • Reaching agreements in specific domains on service and consumer definitions that can be used to create internal or external markets. • Building matchmaking facilities that can deal with the complexity of service and consumer descriptions and the two-way relationship between them.

EC-Web, DEXA 2003 conference, Prague 1-5 September 2003

This paper concentrates on the issue of matchmaking in the context of web services. It provides a brief review of the difference between directory services and matchmaking facilities and explains why directories such as UDDI are important but insufficient for web services and need to be complemented with advanced matchmaking facilities. It discusses the requirements that web services place on matchmaking, namely symmetry of information exchange, the ability of each party to specify requirements of the other party, rich languages to describe services and their consumers as well as their demands, and the ability to dynamically update and configure what is being offered. These requirements are addressed by the Web Services Matchmaking Engine (WSME) - a powerful Matchmaking Engine capable of matching complex entities, and a Data Dictionary Tool for defining the language of the corresponding matchmaking process. The WSME matchmaking process and property and rules languages are described. An example of how a dynamic market for selling and buying Capacitors can be created with WSME is given. Finally, conclusions and possible future avenues of work are presented.

2

Directories and Matchmaking Facilities

Most early directories provided a mapping from a name to an address. With work on distributed system in the 80’s, directories changed to a more advanced form where the search is not carried out for a specific entry by name but rather based on its attributes. In other words, it is possible to search for something of a certain ‘type’ with certain attributes, rather than having to know its name. Along with the notions of searching by attribute rather than by name, came the idea of qualifying the search with an expression, referring to the description of the service and acting as a requirement. This was the basis of the ANSAware Trader [ANSAware 93] and the CORBA/ODP Trading Service [OMG 96, ODP 95]. Such services can be regarded as an advanced form of a directory, a ’Yellow Pages’ in an electronic form. One shortcoming of those directories is that they provide an asymmetric form of selection, where the selection criteria are provided entirely by the potential consumer. Work on advanced Matchmaking Engines (MMEs) extended these ideas by introducing symmetry into the selection process [HOFFNER 00]. Here, the potential consumer is able to provide a description of themselves and what they offer as consumers. This allows the service provider to specify their demands of the potential consumer, thereby being able to select them, just as the consumer selects the service. This advanced form of matchmaking opened up ways of dynamically updating the description of the service at matchmaking rather than advertising time. By coupling this with the notion of symmetry, directories can be more dynamic and facilitate the configuration of what is being offered to suit the needs of the specific consumer, thus introducing dynamic customisation. To summarise - it is possible to discern a spectrum ranging from the simplest form of a directory, implemented as a simple query to a database, and the matchmaking process with its multi-dimensions: symmetry, rich description and requirement languages, dynamic configuration, etc. [FIELD 02].

EC-Web, DEXA 2003 conference, Prague 1-5 September 2003

A service often put forward as a directory for web services, is the Universal Description, Discovery and Integration or UDDI [UDDI 2002] [Graham 01a, b]. UDDI is an example of a directory aimed at to publishing and discovering information about Web services and serves as a repository for web service descriptions with a limited search capability. UDDI is an ‘open’ directory, in the sense that the contents are available to everybody who has access to the directory. Restrictions can be placed on the availability of advertisements, but only on the basis of the identity of the consumer, not by using any attributes that may describe them. The search is thus asymmetric - only consumers have the ability to express their requirements of the service and its provider, but not vice versa. UDDI is a static directory - its content is specified at advertising time and can only be updated if an advertisement is replaced by a new one. We claim that if web services are to be used as the building blocks for creating internal as well as cross organisational business processes, then UDDI may serve as a basic introduction service but lacks the matchmaking capability essential for selecting the right web services and consumers.

3

Requirements of Web Service Matchmaking

3.1

Symmetry of Information Exchange and Selection

The process of finding the right service for a given service consumer is not necessarily a one-way process of having the consumer state their requirements and select a winner from the matching services. Service providers may wish to receive information from the consumer before deciding to make a particular service available to that consumer. The input to the matchmaking process (Figure 1) therefore needs to take account of the demands of both service consumers and providers, relating these demands to information provided by both parties - resulting in a symmetric exchange by service consumers and providers of both information and demands. P r o v id e r r e q u ir e m e n ts o f c o n su m e r (R u le s) S e r v ic e d e s c r ip tio n a n d d e liv e r y g u a r a n te e s (P r o p e r tie s)

P r o v id e r

R

M a tc h m a k in g

P

M a tc h m a k in g

M a tc h m a k in g E n g in e (M M E )

P

R

C on su m er d e s c r ip tio n a n d g u a r a n te e s (P r o p e r tie s) C on su m er r e q u ir e m e n ts o f p r o v id e r (R u le s )

C o n su m er

Figure 1: The two-way exchange of information and selection in the symmetric matchmaking process.

EC-Web, DEXA 2003 conference, Prague 1-5 September 2003

3.2

Powerful Description and Requirement Language

Powerful languages are needed to describe complex services and similarly, powerful languages are needed to describe complex compatibility criteria, i.e. requirements relating to the description of the other party. The matchmaking language has to be sufficiently powerful to express the type of properties that organisations are looking for when selecting a partner. The descriptions created with this language should be capable of using complex data structures to express complex attributes such as delivery dates with price tags attached and associated Quality of Service parameters, etc. Similarly there is a need to be able to access these complex data structures and extract the relevant information from them within a specification of requirements or rules. 3.3

Dynamic service configuration

Matchmaking should allow a provider to describe its offer as a skeleton or a generating function that can be used to offer different service configurations. This can be done in the form of a reference to an external system as shown in Figure 2 or alternatively by supplying a script that the MME can evaluate locally. Thus, the MME can generate the specific service offer dynamically at the time of searching. Input to the process that provides the specific value can contain information from the potential consumer, each service configuration can be tailored to the circumstances of the specific consumer. This is needed for several reasons: • It facilitates an up-to-date description of the service where service properties such as the cost, availability or quality of service may be subject to variations. Such variations can for example be due to load, maintenance, etc. • It provides a way to specify a range of services without having to enumerate all the options associated with them in the MME as this may overload the MME. • It provides a way to configure the service and the consumer application according to the needs and properties of the both parties. This facilitates personalisation of the service. • It provides a way to integrate existing applications that reside on back-end systems (legacy problem).

P r o v id e r

M a tc h m a k in g E n g in e (M M E )

R

M a tc h m a k in g

P

M a tc h m a k in g

B a c k -E n d S y s te m

R e q u e st fo r u p -to -d a te d e sc r ip tio n m a y c o n ta in c o n su m e r p r o p e r tie s

C on su m er P

R

R e su ltin g d e sc r ip tio n c a n b e c o n su m e r sp e c ific

Figure 2: Dynamic properties can be updated when needed during the matchmaking process either by the script provided to the MME or by calling a Back-end system on the provider side.

EC-Web, DEXA 2003 conference, Prague 1-5 September 2003

4

The WSME Matchmaking Process

The rest of this article contains a description of WSME - Web Services Matchmaking Engine. It is deployed as a web service that can receive queries and advertisements and also provide management and auxiliary functionality. WSME combines Internet and web-technology to create, operate and manage an arena where advertisements can be placed and where searches can be conducted with the aim of pairing compatible entities. WSME is a web service supplied as part of the IBM Web Services Tool Kit (WSTK) [ALPHAWORKS 02] and can be downloaded and used for experimentation. The WSME has its origins in ANSAware [ANSAWare 93], and the CORBA/ODP Trading Service standard [OMG 96] [ODP 95]. It addresses all the requirements discussed in Section Error! Reference source not found.. The WSME matchmaking process is a two-way or symmetric process: each party to the process submits a description of itself and the requirements it has of the other party. The evaluation of those demands against the descriptions of the two parties during the matchmaking process, allows both parties to “select” each other. D a ta D ic tio n a r y (2 ) A d v e r tise m e n t S u b m issio n : M yT yp e, Y o u rT yp e, P ro p erties, R u les

R P

(4 )/(7 ) M a tc h m a kin g p r o ce ss

(1 ) In p u t d a ta d ic tio n a r y

P

R

M a tc h m a kin g M a tc h m a kin g

(3 ) Q u ery S u b m issio n : M yT yp e, Y o u rT yp e, P rop erties, R u les

(5 )

S c rip t p ro c essin g

P r o v id er P r o v id er B a c k -E n d S y ste m

(5 * ) R e q u e st v a lu e o f d yn a m ic P ro p erty

(6 )

W SM E

(6 * ) S u p p ly d yn a m ic P ro p erty v a lu e

(8 ) Sequence of O ffer s: C o n ta in P ro p erties

C o n su m er

Figure 3: The WSME matchmaking process.

The WSME matchmaking process is shown in Figure 3: 1. The Data Dictionary is injected into the WSME through one of its web service operations, so that the WSME can check the correctness of properties and rules submitted to it. 2. The Advertisement submission is sent from the provider to the WSME and is long lived, remaining in the WSME until it is explicitly withdrawn by the provider or until the application server is stopped. The advertisement contains the following information: • MyType: this specifies the advertisement record-type.

EC-Web, DEXA 2003 conference, Prague 1-5 September 2003

• YourType: this specifies the record-type expected to be submitted by the con-

sumer query. • Properties: a list of the properties defined as MyType. Some of those properties

may be defined as dynamic properties by the provider. In this case, the provider will have to supply a script to evaluate the property in the WSME, or alternatively, a reference to a location where the value of the property can be obtained, e.g. a back-end system. The specification of the dynamic property may define the consumer properties that have to be supplied for it to be resolved. • Rules: what the provider requires from the consumer. 3. A Query submission is sent from the consumer to the WSME and is transient, terminating after initiating the matchmaking process and bringing it to its conclusion. The query contains the following information: • MyType: this specifies the query record-type. • YourType: this specifies the provider’s advertisement record-type that the query is looking for. • Properties: a list of the properties defined as MyType. • Rules: what the consumer requires from the provider. 4. The Matchmaking Process brings together matching advertisements and queries by applying the rules of each party to the description of the other party. The WSME matchmaking process is a two-way or symmetric process carrying out the evaluation of the demands of each party against the descriptions of the other parties, thus allowing both parties to 'select' each other. 5. If during the matchmaking process, a rule that contains a reference to a provider dynamic property is evaluated, a call will be made to resolve the property’s value. Depending on what the advertisement contained, this will either be a call to a script in the WSME, or an external call to a provider back-end system, for example (5*). In either case, the input to the request may contain details of the consumer query currently being matched. This allows the reply to be specially tailored to that particular consumer. 6. The value of the dynamic property is returned to the matchmaking process, either from the local script or from the external location (6*). 7. The matchmaking process can now continue. If more dynamic properties are encountered, steps (5) and (6) are repeated. A matching advertisement is called an offer. If more than one offer is available, they are collected together. 8. Zero, one or more matching offers are sent to the consumer. The exchange of information coupled with the ability to apply rules to the submitted information requires that the parties in a matchmaking space agree on a common language and terminology. The results of this agreement are data dictionary definitions, which will be discussed later.

EC-Web, DEXA 2003 conference, Prague 1-5 September 2003

5

WSME Data-Structure and Script Languages

This section describes the WSME languages used to describe the matchmaking parties, what they offer and require of each other. This requires the creation of Properties and Rules. The two languages that are used to construct properties and rules are the WSME Data-Structure language and the WSME Script language. 5.1

Properties

The WSME Property Language provides the building blocks for describing entities such as products, services, components and descriptions of the providers and consumers. Those descriptions are contained in the advertising and query submissions sent to the WSME. A Property is a 'name-value' pair, where the name consists of a string and the value can be: One of a set of pre-defined basic types, a sequence of basic types or a user defined record type. A property can be defined as one of the following: • Static property contains the appropriate value associated with the property at the point of submitting it to the WSME. The value of a static property does not change during the life of a submission. • Dynamic property does not contain the value at the point of submission. Instead, a reference is provided, either to a local Script (an executable program that can calculate the required value) or alternatively, a reference to an external service that can be called to provide the value. For example, the following properties can be defined: Age, StockLevel, QuantityRequired, QuantityAvail can be defined as integers, and Price and Payment as floats. To facilitate the symmetric matchmaking process described in Section 4, each party has to be able to relate to the other party's properties as well as to its own. Therefore, when a property is referred to, it is prefaced by an indication of the side it is coming from as in ‘my.property-name’ and ‘your.property-name’. For example: my.QuantityRequired and your.QuantityAvail can be compared in a rule as explained below. The prefix ‘my’ and ‘yours’ is relative to the originator of the rule in which the expression is found. 5.2

Rules

The WSME Rules allow one party to define requirements from the other party by referring to the properties of both parties. Rules allow both sides to select the other party they wish to deal with by specifying their eligibility. A rule is a WSME script that is evaluated at matchmaking time, resulting in a Boolean value. A rule can refer to the properties of the two parties whose advertisement and query are involved in the matchmaking process. Example of a possible provider rule is the following: boolean result = false; if (my.QuantityRequired y o u r .Y

C o n su m er P r o p e r t ie s

C o n su m er r u l e s a p p l ie d to p ro v id er p r o p e r tie s ( p o s s i b ly r e f e r r in g to i t s o w n a s w ell)

Figure 4: The 'typed' matchmaking process - applying the rules of one party to the properties of the other, within the confines of the Data Dictionary definitions. Each party can refer to its own properties as well as those of the other party.

The matchmaking process applies the rules of the submission of one party to (an instance of) the properties of the submission of the other and vice versa as shown in Figure 4. Only if the result of the evaluation of all submission-rules is 'true', will the advertisement-query be considered a matching pair. An Offer (to be returned to the query submitter) is an advertisement submission that matches the query with all its dynamic properties resolved. 5.3

WSME Data-Structure Language

The WSME Data-Structure Language provides the building blocks and composition instructions for defining the value of a property. The value of a property can be any of the following: One of a set of pre-defined basic types - boolean, integer, float, string, and date, a sequence of these basic types or of record types, or a user defined record type made of any combination of the above. In other words, it is possible to create records of sequences and sequences of records with any combination of the basic and composite record-types. 5.4

WSME Script Language

The WSME Script (Programming) Language provides the building blocks and composition instructions for writing logical expressions or programs. Scripts can be used for:

EC-Web, DEXA 2003 conference, Prague 1-5 September 2003 • Dynamic properties: Properties that may include a script at advertising time, to be

evaluated at matchmaking time. Scripts may return any of the simple or complex types of the property language. • Rules: These define requirements from the other party using a script containing a logical expression or a program that is evaluated to a Boolean value at matchmaking time. The WSME Script Language can be regarded as a simplified programming language consisting of Data structures (as defined by the Data-Structure Language), temporary variables and value assignments, Logical expressions, Arithmetic expressions, Conditional expressions, Control flow expressions and Built in functions.

6

A Capacitor Market Example

The WSME Capacitor Market example specifies a matchmaking space where providers can advertise their Capacitors with the aim of finding suitable buyers, and where buyers can search for Capacitors that are appropriate for their needs. The translation of a business model into a list of properties (name-value pairs) is an important part of creating the matchmaking space. 6.1

The Capacitor Market Data Dictionary

The Capacitor Market data dictionary definition is shown in Figure 5.

Provider/product description: • ProviderDetails (record): Name (string) and Email (string). • CapacitorTypes (sequence of string): a list of any combination of the following -

Tantalum, Aluminium or Ceramic. • Capacitance (float): expressed in micro Farad. • QuantityAvail (integer): shows the current stock level. • TotalPrice (float): this is a dynamic property - the price of the capacitors requested

by a buyer is calculated at matchmaking time and is dependent of the quantity requested and the price of a single unit. The example script shown here is calculated at matchmaking time and is dependent on the quantity requested and the price of a single unit: float sum; if (your.CapacitorType == "Ceramic") sum = your.QuantityRequired * .55; if (your.CapacitorType == "Tantalum") sum = your.QuantityRequired * .65; if (your.CapacitorType == "Aluminium") sum = your.QuantityRequired * .75; return sum;

The dynamic property will be evaluated in case either a provider or a consumer

EC-Web, DEXA 2003 conference, Prague 1-5 September 2003

rule refers to it. If a dynamic property has not been evaluated earlier, it will be evaluated before the advertisement is made into an offer and sent to the consumer. • WSBindingInfo (record): WebService_URL - this is the URL of the service used to order the capacitors; WSDL_URL - this is the URL where the WSDL description of the ordering service can be found.

Buyer description: • • • • •

BuyerDetails (record): Name (string), and Email (string). CapacitorType (string): Tantalum, Aluminium or Ceramic. Capacitance (float): expressed in micro Farad. QuantityRequired (integer): DaysToDelivery (integer): indicates the expected speed of delivery of capacitors. C a p a c it o r P r o v id e r P r o v id e r D e t a ils

C a p a c it o r B u y e r B u y e r D e t a ils

P a r t y D e t a ils

P a r t y D e t a ils

N am e

S tr in g

N am e

S tr in g

E m a il

S tr in g

E m a il

S tr in g

C a p a c it o r T y p e s

S tr in g

C a p a c it a n c e

C a p a c it o r T y p e

C a p a c it a n c e

F lo a t

S tr in g

F lo a t

Q u a n t it y A v a i l

I n te g e r

Q u a n t it y R e q u i r e d I n te g e r

T o ta lP r ic e

F lo a t

D a y s T o D e liv e r y

I n te g e r

W S B in d in g I n f o W e b S e r v ic e B in d in g

W e b S e r v ic e _ U R L

S tr in g

W SD L _U R L

S tr in g

D e f i n i t io n o f p r o v i d e r s u b m iss io n r e c o r d ty p e

D e f i n i t io n o f c u s to m e r s u b m iss io n r e c o r d ty p e

Figure 5: The two parts of the data dictionary define the properties expected to be included in the submissions from the Capacitor provider and buyer.

6.2

Buyer and Provider Rules

An example of a rule from the provider side could be: boolean result = false; if ( your.CapacitorType in my.CapacitorTypes && your.Capacitance == my.Capacitance ) { result = true; } return result;

Similarly, a rule from the consumer could look like this: return ( my.QuantityRequired 3 ) { r e s u lt = tr u e ; } re t u r n r e s u lt ;

( 1 ) A d v e r ti s e m e n t s

(2 ) Q u e r y

MME (3 ) M a tc h m a k i n g p ro cess

P r o v id e r C P r o v id e r B P r o v id e r A

( 5 ) M a tc h i n g p r o v id er (s) o f fe r ( s )

C u sto m er XYZ

Figure 6: An example of the matchmaking process in the Capacitor Market.

7

Conclusions and Future Work

This paper discussed the requirements that web services place on matchmaking symmetry of information exchange, the ability of each party to specify requirements of the other party, rich languages to describe services, their consumers and their demands, and the ability to dynamically update and configure what is being offered. The Web Services Matchmaking Engine (WSME) - capable of matching complex entities was described and an example of how a dynamic market for selling and buying Capacitors can be created with WSME was given. There are a number of areas for future work: Tools: in addition to the Data Dictionary tool that helps define the (type of) properties of entities to be matched, several other tools are needed: Advertising and querying

EC-Web, DEXA 2003 conference, Prague 1-5 September 2003

tool to help create instances of those types that can be used to advertise and query the WSME and a management tool for supervising the state of the WSME. Distributed matchmaking spaces: in some complex matchmaking spaces, it may be desirable to divide the information between different matchmaking engines. This can result if an extended dialogue conducted between the consumer and multiple WSMEs. Each WSME may contain different type of information, related to a different stage in the dialogue. N-party matchmaking process: the current matchmaking process has two parties. There are some business scenarios which call for more parties to the matchmaking process. Post-matchmaking processing: once several matching offers to a query are found, it is possible to compare them and rank them according to some criteria. Ways of specifying and evaluating complex utility functions may use the script languages or extensions thereof. Monitoring and statistics derivation: this can be envisaged at different levels: • When a matchmaking process fails, it is sometimes useful to know exactly where

in the rule the failure occurred. • Overall statistics may provide useful marketing information and insight.

Long-lived queries: If queries can be made long-lived in a similar manner to advertisements, a host of interesting possibilities opens up.

8

References

[ALPHAWORKS 02] Alphaworks, Web Services Toolkit, http://www.alphaworks.ibm.com/tech/webservicestoolkit, 2002. [ANSAware 93] "The ANSAware 4.1 Reference Manual", Architecture Projects Management (APM), http://www.ansa.co.uk/, Poseidon House, Castle Park, Cambridge, UK, 1993. [Field 02] Field, S., Hoffner, Y.: In Search of the Right Partner. In: Camarinha-Matos, L. (ed): Collaborative Business Ecosystems and Virtual Enterprises, PRO-VE'02, 3rd IFIP Working Conference on Infrastructures for Virtual Enterprises. Kluwer, Dordrecht (2002) 56-62. [Graham 01a] Graham, S.: The Role of Private UDDI Nodes in Web Services, Part 1: Six Species of UDDI. Web Services Architect, IBM Emerging Internet Technologies, May 2001a. [Graham 02b] Graham, S.: The Role of Private UDDI Nodes, Part 2: Private Nodes and Operator Nodes. Web Services Architect, IBM Emerging Internet Technologies, May 2001b. [Hoffner 00] Hoffner, Y., Facciorusso, C., Field, S., Schade, A.: Distribution Issues in the Design and Implementation of a Virtual Market Place. Computer Networks 32 (2000) 717730. [Hoffner 01] Hoffner, Y., Field, S., Grefen, P., Ludwig, H.: Contract-Driven Creation and Operation of Virtual Enterprises. Computer Networks 37 (2001) 111-136. [ODP 95] ODP, Open Distributed Processing Reference Model. ISO/IEC 10476. ITU-T Recommendation X.900, Parts 1–3 (1995).

EC-Web, DEXA 2003 conference, Prague 1-5 September 2003 [OMG 96] OMG, Object Management Group and X/Open Standard: CORBA Trading Object Service. Document orbos/96-05–6, 1996. [FELLER 02] Feller, J.: IBM Web Services ToolKit - A Showcase for Emerging Web Services Technologies. http://www-3.ibm.com/software/solutions/webservices/wstk-info.html, 2002. [UDDI 2002] The UDDI Version 3 Specification, 19 July 2002, http://www.uddi.org/.