Matchmaking Portal for the Discovery of Numerical and Symbolic. Services. Simone A. Ludwig1, Omer F. Rana1, William Naylor2 and Julian Padget2. 1School ...
Matchmaking Portal for the Discovery of Numerical and Symbolic Services Simone A. Ludwig1 , Omer F. Rana1 , William Naylor2 and Julian Padget2 1
School of Computer Science/Welsh eScience Centre, Cardiff University 2
Department of Computer Science, University of Bath Abstract
A significant number of applications within eScience make use of numerical algorithms, developed as part of a project or obtained from third parties such as numerical libraries from the Numerical Algorithms Group (NAG). The complexity of such algorithms can vary from simple matrix solving to more complex data analysis functions such as clustering or classification techniques. The ability to access such algorithms as Web Services allows easy integration of such capability within existing applications while also providing a loose coupling between the application and the numerical algorithm. The matchmaking portal developed focuses on the provision, discovery and use of mathematical services.
1
Introduction
The deployment of agent/Web Services is increasing this creates a problem for software agents that is the analog of the human user searching for relevant HTML pages. Humans typically use Google, but they can filter out the irrelevant and spot the useful, so while UDDI (the Web Services registry) with keyword searching essentially offers something similar, it is a long way from being very helpful. Consequently, there has been much research on matchmaking architectures, such as Infosleuth [8], LARKS [10], and IBROW [6] and its significance is underlined in the following quote: ”Matchmaking is an approach based on emerging information integration technologies whereby potential producers and consumers of information send messages describing their information capabilities and needs. These descriptions, represented in rich, machine-interpretable description languages, are unified by the matchmaker to identify potential matches.” [7]
be available. The functionality being demonstrated comprises of the matchmaker for mathematical services. Service descriptions including pre- and post-conditions are provided in an XML-based language (OpenMath [11]). OpenMath has been adopted as it is being widely used by developers of mathematical libraries such as NAG. OpenMath is intended to be a standard for representing mathematical objects, and for exchanging them between computer programs. There is a strong relationship with the MathML [9] recommendation from the Worldwide Web Consortium, and a large overlap between the two developer communities. Whereas MathML deals principally with the presentation of mathematical objects, OpenMath is solely concerned with their semantic meaning or content.
2 2.1
Matchmaking Portal Mathematical Service Description
Mathematical services are represented in OpenMath syntax. OpenMath is based on the concept of Content Dictionaries (CDs). These are definition repositories in the form of files It is perhaps telling that much of the literature ap- defining a collection of related symbols and their meanings, pears to focus on architectures for brokerage, which are as together with various Commented Mathematical Properties such domain-independent, rather than concrete or domain- (for human consumption) and Formal Mathematical Propspecific techniques for identifying matches between a task erties (for machine consumption), In other words each CD or problem description and a capability or service descrip- is a small, specialised ontology. tion. The matchmaking portal1 developed focuses on the proviOpenMath expressions are composed of a small number sion, discovery and use of mathematical services. The portal of primitives. The definition of these may be found in [11], assumes that in the future we are likely to see a service-rich but four of the more commonly used symbols are: OMA environment where mathematical libraries as services will (OpenMath Application), OMI (OpenMath Integer), OMS 1 http://agentcities.cs.bath.ac.uk:8080/ genss axis/GENSSMatchmaker/index.htm
(OpenMath Symbol) and OMV (OpenMath Variable). Symbols are used to represent objects defined in the CDs, with at-
tributes cd to specify the CD and name to specify the symbol. Symbols may represent basic mathematical objects e.g. Z (the integers) is represented by:2
that is the symbol Z from the CD setname1. Or they may represent more complex mathematical objects, e.g. the application of a function where the element is with the first child being the function and the rest being the arguments. OpenMath variables have a name attribute to specify the name of the variable. OpenMath integers are just containers for an integral value. As an example, consider the algebraic expression x2 − y 2 , this could be represented in OpenMath as: 2 2
where the symbols minus and power are defined in the CD arith1.
2.2
Functionality and Architecture
The portal developed consists of an architecture which supports five kinds of match modes these include: 1. Basic structural match: this mode compares the XML tree structure of the OpenMath describing the query with that describing the service description (residing in the repository). 2. Syntax and ontology match: this mode first performs a structural match, and then performs a syntax match based on the attribute values of the OMS elements, and some inclusion rules referring to certain (set valued) OpenMath symbols. 3. Algebraic equivalence match: this mode compares the query with the service description by using algebraic means. Algebraic equivalence in this context is primarily related to how mathematical expressions can be rewritten.
Figure 1: Sequence Diagram - Service Request
between the expressions for the task and capability. Equivalence is determined if the difference returns 0. This is not a deterministic process, however, as the values may have coincided with a root of the expression, for a non identically zero expression. Effectively this match is a Monte Carlo technique and can only guarantee correctness to a certain probability. 5. Decomposition match: in case an exact service match cannot be found, the decomposition match will attempt to discover an equivalent mathematical expression. Essentially, this involves dividing the query into subqueries, and trying to find a match for each decomposed sub-query. The decomposition is supported by applying a set of rules that try to match each service description. The rules are applied recursively to decompose a mathematical expression into a normal form with respect to the given set of rules. The matchmaker uses the individual match scores from each of the plug-ins above to compute a ranking of matched services. The matchmaking architecture comprises the following: • The Client interface: this is employed by the user to specify their service request. • The Matchmaker: this consists of a reasoning engine and the matching module. • Matching algorithms: where the logic of the matching is defined.
4. Value substitution match: this mode compares numerical valued expressions in the task descriptions with numerical valued expressions in the capability descriptions, by substituting suitable values into the difference
• Mathematical ontologies: eg. OpenMath Content Dictionaries (CDs), GAMS (General Algebraic Modeling System), etc..
2 The prefix om is used to denote the namespace: http://www. openmath.org/
• A registry service: this enables storage of the mathematical service descriptions.
Figure 2: List Services
• Mathematical Web Services: which are available on third party sites, accessible over the Web.
Figure 3: Service Invocation
The sequence diagram in Figure 1 shows the interactions of a search request as follows: (1) the user contacts the matchmaker, then (2) the matchmaker loads the matching algorithms specified by the user; in the case of an ontological match, further steps are necessary (3) the matchmaker contacts the reasoner which in turn loads the corresponding ontology (4) having additional match values results in the registry being queried, to see whether it contains services which match the request and finally (5) service details are returned to the user via the matchmaker. The parameters stored in the registry (a database) are service name, URL, taxonomy, input, output, pre- and post-conditions. Using contact details of the service from the registry, the user can then invoke the Web Service.
2.3
Portal Description
There are two things which can be done with the portal: • List the services in the registery.
Figure 4: Search Services - Input Screen
• Search the available services for a given task description The List services page, shown in Figure 2, lists all mathematical services stored in the repository displaying service name and service URL. By clicking on the service name another screen opens displaying the service details. These are: (i) the service name, (ii) the service URL, and (iii) the preand post-conditions in OpenMath syntax. By clicking on the service URL another screen pops up allowing to invoke the mathematical service (Figure 3). The Search services page, shown in Figure 4, allows the user to search for mathematical services expressing queries in OpenMath syntax. This screen contains a section where the number of pre- and post-conditions can be given in order to provide the input fields for the pre- and post-conditions. The match mode section provides the five matching modes (structural, ontological, algebraic equivalence and substitution).
The Search for Matches button performs the matchmaking depending on the match mode chosen. The results of matched services, shown in Figure 5, are displayed in the table Returned Matches showing the service details. These are (i) the service name, (ii) service URL, (iii) match type and (iv) three match score numbers for pre-, post-conditions and overall respectively. We have registered three services with the portal which are from disparate areas of mathematics and therefore provide a useful test of our prototype. These services are: • Factorisor – this performs factorisation of a square free integer. • Quad-Sieve – this performs a quadratic sieve on an integral interval. • LU decomposition – this performs an LU decomposi-
Figure 5: Search Services - Matched Services
and platform-independent. • The matchmaking service is implemented as a Web service using WSDL (Web Service Description Language) and SOAP (Simple Object Access Protocol) [5]. WSDL provides a simple way for service providers to describe the basic format of requests to their systems regardless of the underlying protocol (such as SOAP or XML) or encoding (such as Multipurpose Internet Messaging Extensions). • The matchmaking algorithms are themselves implemented as web services and are registered in a UDDI [5] registry, a Web-based distributed directory that enables businesses to list themselves on the Internet and discover each other, similar to a traditional phone book’s yellow and white pages. This allows the matchmaking service to dynamically load the different matchmaking algorithms specified. • The service registry is implemented as a database to store the mathematical service descriptions using MySQL [4] an open source database. • The ontology service consists of an OWL ontology and a JESS (Java Expert Systems Shell) [3] engine as a reasoner. JESS was chosen as a rule-based language for the matchmaker as it provides the functionality for defining rules and queries in order to reason about the ontologies specified. • The Mathematical Web services provide the numerical and symbolic services. 2.4.1
Differences to the JSR 168 and WSRP Standard
A portal is a Web application that typically provides end users with personalisation, single sign-on, security and content aggregation from different sources. It is the responsibility of a portlet container to run portlets, providing them with a runtime environment and managing their life cycles. Figure 6: Matchmaking Portal Implementation The container also persists portlet user preferences, enabling a customized end-user experience. The Java Specification Request for the Portlet Specification, standard JSR 168, articulated by the Java Community Process, aims to provide tion of a matrix a standard for portlets. The specification defines a contract The user can then select and invoke a returned service by between a portlet and the portlet container that powers it. Arclicking on the link provided. If the Quad-Sieve service were eas covered by the APIs defined in the specification include chosen then Figure 3 would be displayed. topics such as aggregation, personalisation, presentation and security. In order to enable interoperability between portlets and portals these concepts needed to be addressed by a spec2.4 Implementation ification. An example for an implemented JSR standard is Figure 6 shows the implementation of the matchmaking por- GridSphere [1], which is a portal framework and provides tal. This prototype system is based on the latest Web Service an open-source portlet based Web portal. technology standards. It consists of the following compoThe standardisation of Web Services for Remote Portlets nents: (WSRP) goes one step further by specifying the remote ren• The Client portal is built as a web client using Java dering of portlets. WSRP enables the functionality of deServer Pages (JSPs) [2]. JSP provides a simplified, fast ploying portlets once delivering them anywhere. This allows way to create dynamic web content and enables rapid bringing together third-party portlets and enhances interopdevelopment of web-based applications that are server- erability between portals from different vendors.
Both standardisation efforts moves the work of portals and portlets towards a unified, federated portal framework, where sharing portal componets paves the way for sharing business services. Federated portals allow for increased flexibility in the sharing of content between different business units and partners. The matchmaking portal described here does not match the JSR 168 standard in that it has no personalisation, no sign-on and no security. This is because the portal primarily focuses on a proof of concept prototype. However, signon and security issues must be considered in the case of a more commercial usage, for example provision by NAG of a mathematical service library.
3
Example - Factorisor Service
Figure 7: Factorisor Service
The Factorisor service was chosen as an example. This service finds all prime factors of an Integer. The Factorisor has the following post-condition:
where n is the number a user wishes to factorise and lst_fcts is the output list of factors. The post-condition for the Factorisor service represents: n=
l Y
this represents the following mathematical statement: ∀i|1 ≤ i ≤ |lst fcts| ⇒ n mod lst fctsi = 0
(2)
where l = |lst fcts|
(1) which is equivalent to equation 1. A match should occur if enough mathematical knowledge is available in the system. In practice, this is only achievable in the algebraic equivaConsider the situation where a user specifies that he is lence and substitution match modes. The user should get a searching for a service with the following post-condition: match with the Factorisor service which can then be invoked (Figure 7). The given input parameter is: lst fctsi
i=1
10403
and the returned values are the prime factors 101 and 103.
4
Conclusion
With the portal implementation we have presented an approach to matchmaking in the context of mathematical Web services. The semantic description of mathematical services, expressed in OpenMath syntax, greatly assists in identifying suitable services in some cases, but also significantly complicates matters in others, due to the inherent richness of the mathematical description. Consequently, we have put forward an extensible matchmaker architecture supporting plug-in matchers that may employ a variety of reasoning
techniques, utilising theorem provers and computer algebra systems as well as information retrieval from textual documentation of mathematical routines. Although our set of test cases is as yet quite small, the results are promising and we foresee the outputs of the project being of widespread utility in both the e-Science and Grid communities, as well as more generally advancing semantic matchmaking technology.
5
Acknowledgments
The work reported here is partially supported by the Engineering and Physical Sciences Research Council under the Semantic Grids call of the e-Science program (grant reference GR/S44723/01).
References [1] GridSphere Portal Framework. Available from http://www.gridsphere.org/ gridsphere/gridsphere. [2] J2EE JavaServer Pages Technology. Available from http://java.sun.com/products/jsp/. [3] Java Expert Systems Shell. Available from http://herzberg.ca.sandia.gov/jess/ docs/61/index.html. [4] MySQL Database. Available from http://www. mysql.com/. [5] A.E. Walsh. UDDI, SOAP, and WSDL: The Web Services Specification Reference Book, 2002. UDDIORG. [6] V.R. Benjamins, B. Wielinga, J. Wielemaker, and D. Fensel. Towards Brokering Problem-Solving Knowledge on the Internet. In Dieter Fensel and Rudi Studer, editors, Proceedings of the 11th European Workshop on Knowledge Acquisition, Modeling and Management (EKAW-99), volume 1621 of LNAI, pages 33–48, Berlin, May 26–29 1999. Springer. [7] D. Kuokka and L. Harada. Matchmaking for information integration. Journal of Intelligent Information Systems, Feb 1996. [8] W. Bohrer M. Nodine and A.H. Ngu. Semantic brokering over dynamic heterogenous data sources in infosleuth. In Proceedings of the 15th International Conference on Data Engineering, pp. 358-365, 1999. [9] MathML. Mathematical markup language (mathml) version 2.0, www. Available from http://www. w3.org/Math/.
[10] K. Sycara, S. Widoff, M. Klusch, and J. Lu. Larks: Dynamic matchmaking among heterogeneous software agents in cyberspace. Journal of Autonomous Agents and Multi Agent Systems, 5(2):173–203, June 2002. [11] The OpenMath Society. The OpenMath Standard, October 2002. Available from http://www.openmath.org/standard/ om11/omstd11.xml.
