The previous sections present a high level overview of the main features that have to be supported by a distributed symbolic system and have drawn the guidelines that need to be followed. The CAS Server components act as mediators between the remote client and
the actual computational engines. Clients that require access to a certain functionality provided by the CAS engine do not need to call a different service for each particular function they access. The CAS Server provides a service that behaves as a single point of entry to which any request that describes a new task to be computed should be submitted.
Internally, the request is routed to the appropriate CAS engine.
The relation between the CAS Server, client components, indexing services and as well to the various systems whose functionality it provides to clients is depicted in Figure 3.2.
The role of the CAS Server is to expose CAS’s functionality or of any other software package providing symbolic computation capabilities to remote clients. As shown in Figure 3.2, not only CASs may be exposed but other systems as well. For example, SymGrid-Par [200] is a framework that is able to manage installed CASs on a local cluster and even a Grid with the purpose of optimising execution time and usage of resources. As described further in this section, CAS Servers advertise their capabilities both through their interface or to centralised discovery repositories.
It is not uncommon to find personal computers on which multiple CASs are installed.
As computational power becomes more accessible it is also a common approach to use multiple personal computers connected through a LAN to support a set of services and even to use more advanced set-ups such as computational clusters. For such hardware configurations it may be convenient to have more than one CAS installed on a particular machine or even have dedicated machines to host different CASs. Having a single point of entry makes possible to provide access to routines implemented by multiple CAS instances that are in the scope of the CAS Server at the same time. As a result the discovery and invocation process is easier for clients since there is only one service to invoke. At the service provider level, this approach provides the opportunity to use advanced solutions of job scheduling and load balancing.
The structure of the interface and the functionality that CAS Server provides is driven by the general requirements that we have discussed in the previous section: task sub-mission and retrieval of results; discovery of the capabilities implemented by the service
CLIENT
Figure 3.2: CAS Server and Relation to other Components
provides; support for task level management; support for data management and sharing.
For all these features the common requirement is to ensure interoperability. One step towards this goal is to provide a standardized set of interfaces that do not vary over time which makes automated clients more easy to design and implement. Because the same interface is exposed by all CAS Server components, they can be easily interchanged or replaced.
Each of the requirements aforementioned is supported by a corresponding set of services.
For submitting tasks and result retrieval the CAS Server is designed to support for two separated conversation patterns. The most common scenario is the one is which the client submits a task and receives an identifier that the client can later use to retrieve the result.
This approach is suitable for submitting long running tasks because the client does not have to block while waiting for the result neither has to keep the connection alive. Task request can be easily sent through one device that is afterwards disconnected from the network. The result may be later retrieved using the same device or a different one. As an additional solution CAS Server can receive together with the task a URL address to which the result should be sent when the computation has finished. The capability is
particularly useful for dedicated servers that provide a service interface through which the result can be submitted. As we will see in the following chapter this features play an important role in automatic orchestration of services.
CAS provided functionality is grouped in packages of functions and exposing CAS’s functionality through the interface is most conveniently achieved at function level. Vir-tually any routine provided by a CAS can be transformed into a service. Basically, a symbolic task submitted to a CAS Server has to provide as mandatory information the CAS type that the task should be managed by, the function name including its package name and the input values for parameters. Exposing each function as an entry on the interface would break the requirement for uniform interfaces on one hand and makes the discovery process difficult on the other hand. The tasks submitted through the generic entry point must adhere to one of the two encoding formats that we discuss further in this chapter, which are both OpenMath compliant.
Tasks that are submitted to a certain CAS Server are considered atomic in the sense that the CAS handling the task is not expected to further decompose the task and connect to other CAS Servers in the case it is not able to entirely solve the problem. Still, it may be possible that the task itself specifies that an external call should be made to another CAS Server, in which case an external call will be initiated. A current general limitation of existing CASs is they are not able to detect that a certain sub-task is better handled by another CAS and automatically forward it. Thus, we expect that for most of the cases, tasks are computed within the boundaries of the same CAS Server.
Using the CAS Server component to expose CASs functionality does not exclude the possibility of using specific systems for cluster and LAN level computation management such as the ones that SymGrid-Par [200] component implements. These systems have the goal of orchestrating CASs installed in a LAN to obtain efficient management of resources. From the CAS Server perspective they are seen as regular CASs and tasks received through the CAS Server interface are assigned to these components based on the same criteria used for selecting any other CAS. CASs themselves may be designed
to collaborate with other CAS instances installed on the LAN or to embed other CASs as internal engines. In such cases the way the CASs collaborate is not driven explicitly by the task’s description. Features provided by software tools such as Maple Grid Toolbok [6] can still be used.
The manager sub-component of the CAS Server receives requests, decides whether the requested functionality is available locally and selects the most suitable CAS to solve the request. The selection process is based on information regarding the CASs and the functionality they provide stored internally by the Local Registry index component.
From index the manager sub-component extracts information about which CASs are installed at the CAS Server, which is the physical machine that hosts it, which are the functions the can be invoked for a particular CAS and which physical resources are available.
The index keeps track of all information related to the hardware and software configura-tion of the CAS Server. As a consequence, the index also plays a role in the security of the whole system. Only functions that are registered to the index component by the CAS Server administrator can be called remotely. Functionality that should not be available for remote invocations for various reasons, including security reasons, are therefore not accessible.
Data required to compute a task is an important issue in symbolic computing. For large scale computations the amount of data produced and consumed by individual services that solve a large symbolic problem requires a careful consideration of data dependency problems. Tasks submitted to particular CAS Server may depend on data that is not stored within the CAS Server where the computation is done. Cooperation between the CAS Servers and intelligent handling of large data sets has to be supported by CAS Server components to ensure that at the time of execution all required data is available.
A detailed description of data management scenarios that the CAS Server implements is provided in Chapter 6. For simplicity we exclude capabilities such as replica manage-ment and we rely on mechanisms to reference data sets that enable us to locate them in
a deterministic way.
Large symbolic tasks may take a long time to compute. There are often situations when such tasks have to be paused and resumed later or even cancelled. We group these related features under the generic term of task management. CAS Server supports task management features for the tasks that it executes based on features that are compatible with existing CASs. While operations such as cancelling a task are easy to implement by sending signals to corresponding CASs or by interrupting their execution, lack of support for check pointing at CAS level makes pausing and resuming tasks impossible in certain stages of the computation. Depending on the actual stage of computation in which a certain task is, the actions taken internally by the CAS Server may vary. Task management and related functionality is further addressed in Chapter 6.
Because the computational infrastructure we envisage is highly dynamic with regard to the actual CAS Servers available and the particular functionality that they provide, ad-vertising and discovery mechanisms play an important role. Local Registry components depicted in Figure. 3.2 provide indexing capabilities in order to support the service dis-covery process. The CAS Server itself provides a set of services that may be used by a regular client to discover the functionality provided. The CAS Server is also able to notify dynamically interested third party components such as centralized indexes about any meaningful change that occurs within the server. Third party indexing components have to be expressly registered by the CAS Server administrator. To be able to receive update information they have to expose a predefined interface through which the CAS Server submits status updates.
Less related to the symbolic computations core requirements but playing an important role for system’s interoperability is the middleware used for building the distributed in-frastructure. Web Services are a good candidate for building interoperable components because they use standards that are platform and programming language independent.
Due to their capabilities previously discussed in Section 2.4, they were considered as a viable solution for developing symbolic computational infrastructures by all recent
sys-tems including the ones developed within Monet [11] and MathBroker [2] frameworks.
Built over these native capabilities, Grid services that are compliant with the WSFR standard provide support for interoperability, and additional capabilities such as security and data management. Important features that otherwise a CAS Server should provide by itself are already provided and ready to be used by the Globus Toolkit 4. Therefore the interface of the CAS Server is exposed as Grid Services implemented using Globus Toolkit 4.
Except from the GENSS project which has considered a single service to accommodate all the requests for symbolic services, the rest of existing solutions to expose CASs’
functionality are using independent services. In Monet for instance, privileged users that want to create symbolic services have to create a set of files containing the code that should be run when the service is invoked and additionally, XML documents to describe the functionality and the interface of the service. Therefore, for each CAS that needs to provide support for a certain service an additional entry is declared on the interface [31]. One of the advantages of describing services using mathematical specific ontologies is that a formal description may be used to better evaluate the service and its capabilities but requires complicated matching techniques to discover which services to use. Within the system proposed by Monet, a client must properly formulate the problem it needs to solve and the broker must correctly identify the service. Matching is done using algebraic equivalence which may itself represent a symbolic computation problem sometimes impossible to solve [127].
3.3.1 Features Summary
The main features provided by the CAS Server component are:
1. multiple CASs may be exposed through a standard interface implemented using Grid Services technology;
2. The CAS Server acts like a mediator between remote clients and CASs installed locally. It provides capabilities that are not in the scope of CASs to allow their integration as computation engines in distributed computation environments;
3. The standard interface of the CAS Server provides support for: submission of tasks and retrieval of result; discovery of provided functionality through a set of indexing services; data management capabilities; task management features;
4. The CAS Server may use a variety of mechanisms to communicate with exposed CASs, e.g. TCP/IP socket connections and communication through pipes.