- 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>

Copyright © 2003 W3C^{®} (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

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

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.

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

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

Three major components are involved in a web service scenario:

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

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.

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**.

A more expressive description language will allow discovery to become more automated and not rely solely on human-readable descriptions. Such a description language is, for example, being developed within the Monet project.

The result of a service discovery can be a mathematical service broker which is able to match a given problem specification to an appropriate service in its registry, making service discovery a two stage process. However, the power of such a broker is equally limited by the expressiveness of the service description language being used.

A popular service discovery mechanism is UDDI.

We will describe the implementation of a sample mathematical service.

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.