Mathematical Web Services

W3C Note 1 August 2003

This version:
http:/www.w3.org/Math/Documents/Notes/services.xml
Latest version:
http:/www.w3.org/Math/Documents/Notes/services.xml
Previous version:
none
Editor:
Laurent Bernardin, Maplesoft Inc. <lbernardin@maplesoft.com>

Abstract

This note outlines the current state of implementing mathematical web services.

Status of this Document

This document is an editors' copy that has no official standing.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This document has been produced as part of the W3C Math Working Group's activity. The authors of this document are the members of the Math Working Group.

This is an early Draft of a W3C Note. For direct comments and report errors in this document to www-math@w3.org.

Table of Contents

1 Introduction
2 Web Service Components
    2.1 Message Exchange
    2.2 Service Description
    2.3 Service Discovery
3 Example Mathematical Web Service
    3.1 Sample Request using SOAP
    3.2 Sample Response using SOAP
    3.3 Sample Description using WSDL
4 High-Order Services
5 Semantic Descriptions
6 Conclusions


1 Introduction

Web services have the potential to transform the landscape of mathematical software. Authoring tools and mathematical software have been very successful with taking advantage of MathML for data exchange and reuse, yet these software tools still consist of monolithic systems that only occasionally interconnect directly, mostly using proprietary methods.

Web services will pave the way for more light-weight systems that are able to locate and use specialized mathematical services on demand. Authoring systems will take advantage of available computational or visualization services without having to build these capabilities into their core. Computational systems will increase their breath of applicability by calling onto specialized mathematical services. The same systems also make their own capabilities accessible to a wider audience by deploying these as mathematical web services. A whole new kind of mathematical problem solving systems may emerge, taking advantage of the combined mathematical knowledge and computational power of a large pool of (specialized) mathematical services, which are called directly or composed with other services in order to solve more complex problems.

The present note investigates the current state of available technologies and tools for implementing mathematical web services. We focus on building on top of the infrastructure supplied by the W3C, in particular by the Math working group and the working groups within the Web Services activity.

We briefly discuss open problems and ongoing efforts to address these, within the W3C and elsewhere.

2 Web Service Components

Three major components are involved in a web service scenario:

We discuss these components in the context of mathematical web services, below.

2.1 Message Exchange

At the base of a web service interaction is always a message exchange. A request is packaged into a message and sent to the service provider. Optionally, the latter sends back a response, again packaged into a message. The format or syntax of these messages is specified by the SOAP 1.2 candidate recommendation. SOAP can also specify, via the bindings framework, the mechanism with which a message is transported from the sender to the receiver, e.g. HTTP POST, HTTP GET, e-mail, etc.

The SOAP 1.2 candidate recommendation has provisions for all essential features required by a messaging format for mathematical web services:

  • Both input and output of mathematical web services will typically involve mathematical expressions. Such expressions can be easily embedded into SOAP messages using a namespace qualifier. Since mathematical expressions are likely to be used in the context of a computation, it is preferable to use an encoding that carries an adequate level of semantic information. Often these expressions will be encoded using MathML and in this case content markup is preferable over presentation markup. Alternative encodings exist, which we will discuss in section 5 Semantic Descriptions.

  • The ability to identify the service or operation to be performed allows a single service to offer multiple operations. For example, an algebraic computation service could perform a symbolic differentiation or an integration on the supplied data, depending on the contents of the message that is received. An operation can be identified in a number of ways: The URI used to invoke a service can represent the requested operation. The operation can be specified in a header field in an HTTP request (similar mechanisms are available for other bindings). The operation can be specified within the message body, using a domain-specific namespace.

  • Chaining of message processors allows for preprocessing of data and the building of compound services. For example, the first service in a chain could be a unit converter, which makes sure that the input data is using SI. This data is then forwarded to a service that checks that the units in the mathematical expressions are consistent, strips the units and forwards the equations to a numeric optimization engine which provides the final result.

  • Faults arising during the processing of a message can be signaled back to the originator of a request. This is especially important for mathematics because it is in practice often impossible to predict whether an operation will succeed on a set of input data or not. For example, during the numeric solution process of a differential equation, it may turn out that the algorithm does not converge quickly enough or not at all. An unexpected division by zero error may occur in a Gaussian elimination algorithm due to numeric round-off. Solving a seemingly simple system of equations may result in exhausting all available memory due to huge intermediate expressions.

A problematic aspect of using MathML embedded in a SOAP message is that SOAP does not allow the specification of a DTD or an internal subset. This means that MathML expressions containing named entities as defined by the MathML2.0 specification can not be used within a SOAP message. Luckily the content part of the MathML2.0 specification does not make use of named entities and such expressions are thus not affected by this problem.

Messages in the context of a mathematical service will share some common structure. One, simple, approach to the structure for a service request message would be to identify the operation by the URI used to refer to the service and to pass all input arguments as children of the SOAP body element. Similarly, a simple structure for a response message would be to return the result of a request as the child or children of the SOAP body element.

However, by adding a little more structure, we can ensure that a message is easily recognized as being part of a an interaction in the context of a mathematical service. A SOAP processor that is not expecting such a message can tell unambiguously that it has been misdirected. We can achieve this by using elements from an application-specific namespace in the SOAP message body or header.

2.2 Service Description

Before a request can be sent to a service, a message has to be assembled in such a way that it contains all the data the service needs and encodes it in a form that the service can interpret it. To allow the originator of a request to construct such a message, each service has to publish the format of the request messages it expects as well as the format of the response messages it generates. The service also needs to advertise the transport mechanisms or bindings, which clients can use to send messages to it. WSDL is an XML format used to describe these aspects of a web service.

The following features of the WSDL 1.2 working draft are critical for mathematical web services:

  • Given a WSDL description of a mathematical web service, it is straightforward to construct an appropriate message to initiate a service request. Likewise, the WSDL description makes it obvious in what form the response message is to be expected and what fault conditions can arise.

    In particular, a WSDL description includes information on number and type of the input and output parameters of a service, crucial information when interacting with a mathematical service.

  • WSDL does not allow a formal description of the semantics of a mathematical web service. However, writing down a formal description for a mathematical service is hard, in general. For example, writing a formal specification for the semantics of the symbolic integration functionality of a computer algebra system like Maple or Mathematica would be a daunting task. WSDL does allow a human-readable description for each operation of a service, which is often necessary for practical purposes, especially in the absence of a (machine-readable) formal description.

  • The type system that WSDL uses to describe the components of a message is extensible, allowing math services to go beyond the capabilities of the default type system, XML Schema. However, even if we had a special type system for mathematical data, this would not be enough to formally describe the semantics of a complex mathematical operation. Replacing the type system also does not help with the inability to specify constraints and relationships among the components of a message or among different messages that are involved in a service interaction.

  • WSDL allows the separation of the abstract description of a service, from the message format and transport mechanism being used to communicate with the service. Mathematical services can thus be delivered via multiple different delivery mechanisms and message formats without having to duplicate a, potentially large, description of what the service does.

Although WSDL is perfectly adequate for specifying the syntax of a message for mathematical web services, it is not able to describe all aspects of a mathematical service. In particular, WSDL cannot be used to specify the semantics of a mathematical service or constraints between input data or between input and output data. We will discuss this issue in greater detail in section 5 Semantic Descriptions.

3 Example Mathematical Web Service

We will describe the implementation of a sample mathematical service.

3.3 Sample Description using WSDL

The following is a WSDL description of our sample service. It contains enough information for a client to construct an appropriate SOAP request as well as for the service to construct a reply in the appropriate form. The WSDL description also contains information on where to find the service and how to establish a communication channel.


<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="com.example.ws.IntegrationService"
    targetNamespace="urn:com.example.ws.IntegrationService"
    xmlns:tns="urn:com.example.ws.IntegrationService"
    xmlns:ns0="http://mathematics.com/xsd/SchemaTypes/"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
    <wsdl:types>
        <xsd:schema targetNamespace="urn:com.example.ws.IntegrationService"
            elementFormDefault="qualified"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:tns="urn:com.example.ws.IntegrationService"
            <xsd:complexType name="Argument">
            </xsd:complexType>
            <xsd:complexType name="Response">
            </xsd:complexType>
        </xsd:schema>
        <xsd:schema targetNamespace="http://systinet.com/xsd/SchemaTypes/"
            elementFormDefault="qualified"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:tns="http://systinet.com/xsd/SchemaTypes/"
            xmlns:xns4="urn:com.example.ws.IntegrationService">
            <xsd:import namespace="urn:com.example.ws.IntegrationService"/>
            <xsd:element name="integrand" type="xns4:Argument" nillable="true"/>
            <xsd:element name="indeterminate" type="xns4:Argument"
                nillable="true"/>
            <xsd:element name="Response" type="xns4:Response"
                nillable="true"/>
        </xsd:schema>
    </wsdl:types>
    <wsdl:message name="IntegrationService_indefiniteIntegration_1_Request">
        <wsdl:part name="integrand" element="ns0:integrand"/>
        <wsdl:part name="indeterminate" element="ns0:indeterminate"/>
    </wsdl:message>
    <wsdl:message name="IntegrationService_indefiniteIntegration_Response">
        <wsdl:part name="response" element="ns0:Response"/>
    </wsdl:message>
    <wsdl:portType name="IntegrationService">
        <wsdl:operation name="indefiniteIntegration"
            parameterOrder="integrand indeterminate">
            <wsdl:input
            message="tns:IntegrationService_indefiniteIntegration_1_Request"/>
            <wsdl:output
            message="tns:IntegrationService_indefiniteIntegration_Response"/>
        </wsdl:operation>
    </wsdl:portType>
    <wsdl:binding name="IntegrationService" type="tns:IntegrationService">
        <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
            style="document"/>
        <wsdl:operation name="indefiniteIntegration">
            <soap:operation
                soapAction="urn:com.example.ws.IntegrationService#indefiniteIntegration"
                style="document"/>
            <wsdl:input>
                <soap:body use="literal"/>
            </wsdl:input>
            <wsdl:output>
                <soap:body use="literal"/>
            </wsdl:output>
        </wsdl:operation>
    </wsdl:binding>
    <wsdl:service name="IntegrationService">
        <wsdl:port name="IntegrationService" binding="tns:IntegrationService">
            <soap:address
            location="http://ws.example.com/IntegrationService/"/>
        </wsdl:port>
    </wsdl:service>
</wsdl:definitions>

4 High-Order Services

Mathematics is a highly structured application domain. Before a complex mathematical operation can be carried out, it is often necessary to construct the mathematical domain in which this operation is defined.

For example, a web service that offers the operation of decomposing a polynomial with integer coefficients into irreducible factors, first needs to construct the domain that this operation is defined over, i.e. polynomials over the integers. The same operation, when applied in the domain of polynomials with algebraic number coefficients could yield an entirely different result.

A solution to this is to specify the domain along with the input parameters in the service request. This is a viable solution but implies a non-negligible overhead if the mathematical structures that are being used are large and multiple operations are to be carried out over the same domain.

Another viable solution is to use a URI scheme to identify the domain of computation and use caching techniques to create the corresponding mathematical structures on demand.

An alternate solution, which more closely models the way this issue is addressed in common mathematical programming languages, is to use a high-order service. Given a mathematical structure and an operation descriptor as input, this high-order service generates a new service that performs the given operation over the specified mathematical domain. The generated service can then be used repeatedly without the overhead of regenerating the mathematical structures at each call.

SOAP does not currently support high-order services, although it may be possible to model them on top of the SOAP extensibility model. High-order services can of course be implemented on top of SOAP by generating services on the fly and returning a URI, identifying the generated service.

5 Semantic Descriptions

The Semantic Web activity is about attaching semantics to all resources available on the World Wide Web and thereby enabling automatic agents to take advantage of the contents of a resource and its relationship with other resources. Just as this will transform the web as we know it today, the full potential of mathematical web services will begin to be realized once it is possible for automated agents and brokers to match a description of a mathematical task to a list of mathematical services that will be able to adequately perform this task.

A simple model, which integrates well into currently available infrastructure for service discovery, is to find a matching web service, given pre- and post-conditions for the operation to be performed. However, this leads to combinatorial growth in the number of web services that are required, because a distinct service is required for each type of input and each type of output.

Composed services address this problem by automatically assembling a chain or graph mathematical web services to perform the task in multiple steps. The first node may transform the input into a form suitable for the second service, which is able to partly solve the mathematical problem, splitting it into two independent sub-problems. These subproblems will be addressed by separate services and their output will be merged by yet another service that is then able to return a solution to the client. The Choreography working group within the Web Services activity is concerned with these problems, but not specifically in the context of mathematical services, which offer their own challenges. The plan to be used for composing web services in order to perform a given task depends on the problem description and the available web services. In general such a plan is not unique and a combinatorial number of possible routes may have to be considered. The planner itself can be implemented as a web service, which takes as input the problem description as well as a list of available services.

Both for enabling the simple pre- and post-condition model as well as for enabling composed services, we need a way to specify the semantics of a web service, as well as those of a mathematical task. This is beyond the scope of WSDL, which merely describes how to build a message for a service and how to disassemble a response received from a service but not what the service will do with the contents of a request or how a the contents of a response is to be interpreted.

MathML is concerned with the semantics of mathematical objects, as opposed to mathematical operations and can thus not be used to address this problem. Similarly, OpenMath is also not an adequate solution.

What is needed is a language for formally describing the semantics of a mathematical operation, taking into account the properties of the input data and the constraints among the input data as well as between the input and the output data.

Once we are able to formally describe the semantics of a service agents and brokers will be able to query these semantics and make decision based upon them. Deciding whether a given mathematical problem can be solved by a service is still a very hard problem, even if the semantics of the service is completely described. Assembling a chain or a graph of services is an even harder problem. It is not enough to compare the input specification of one service with the output specification of another to determine whether they are compatible. A match may be found, even if the output of a service is a subset of the input of the other one. Determining this requires techniques from automated reasoning. Another issue is whether one can build a chain or a graph without having to try an exponential number of combinations from a large pool of services.

Several research projects are currently investigating these problems, notably the Monet project.

6 Conclusions

Using MathML in conjunction with the existing Web Services infrastructure, notably SOAP and WSDL, it is possible to implement useful mathematical web services, today.

For convenience as well as for robustness it would be useful to be able to structure messages with elements from a, to be defined, mathematical web service namespace. Such elements would be used to identify operations as well as optional and required parameters of these operations.

To fully realize the promise of mathematical services and for full integration into the Semantic Web, we need to be able to formally describe the semantics of such a service, paving the way for automatic service selection and composition.