Most of the CASs do not yet support OpenMath as an encoding model for data exchange with other CASs. Older versions of CASs that do not support OpenMath are still in use and a migration process is not entirely possible due to compatibility issues between older and newer versions. Non-standard data representations meaningful only for a certain CAS or even for a certain version of a CAS are therefore still required. Integration of such CASs within distributed environments is also necessary due to the functionality that these CASs provide.
The same generic execute() operation provided by the CAS Server’s interface as single point of entry can be called using two types of encodings to describe the task. Additional to the format specified by SCSCP protocol tasks can be encoded as surrogate OpenMath objects. This alternative encoding uses OpenMath as a frame in which various details regarding which CAS engine, which function from which package should be invoked and which are the arguments to be passed to the function call. The code snippet shown below provides a generic example of this format.
At client side a remote function call is translated to the corresponding OpenMath object as the one in the following example. The message is parsed at CAS Server side and the
information encapsulated in the OpenMath object is used to create the appropriate CAS specific command. This process is similar to the one that phrasebooks use to translate OpenMath encoded objects to commands that a particular CAS understands. The full OpenMath encoding is preferred because it is more generic and any CAS implementing a particular OpenMath CD internally maps OpenMath objects to data structure. This is not the case with the encoding below since the procedure, package, and argument details are specific for a certain CAS and are meaningless when used with other CASs.
<OMOBJ>
<OMA>
<OMS cd="casall1" name="procedure_call"/>
<OMSTR>procedure</OMSTR>
<OMSTR>package</OMSTR>
<OMSTR>Arg1</OMSTR>
<OMSTR>Arg2</OMSTR>
</OMA>
<OMOBJ>
Listing 3.2: Example of Plain Call Encoding
In Listing 3.2 the procedure call OpenMath symbol marks the type of call being formu-lated. The first two OMSTR objects describe the function to be called and the package that the function is part of. The rest of the following OpenMath string objects, in our case Arg1, Arg2 represent the plain string encodings of the arguments that have to be passed to the function call.
Using the message encoding in Listing 3.2 functions implemented by CASs are made available through remote function invocation. This approach though breaks the CAS to CAS interoperability requirement and it should be used only as a compromise for CASs that do not support SCSCP and OpenMath. Another problem is that arguments are not encoded using a standard format and therefore the function to which the arguments are passed has to implement ad-hoc functionality to parse and interpret the string represen-tations.
Regardless of the data type of the arguments at the client side, the remote function call will only receive their plain string encodings. For any other type than plain strings, the client must map/transform values to their string representation before enclosing them in the message call. The result obtained by calling the target function is the exact string returned by the CAS, and thus, the client is responsible for parsing the string result and for extracting the useful information.
If for SCSCP format, the Client Manager component of the CAS Server only extracts some meta information and then forwards the original SCSCP encoding to the target CAS. The Client Manager acts like an adapter by implementing a bridge between the client and CAS, through the interface of the Grid Service. The client manager is respon-sible for extracting the details of the call from the message and formulate a meaningful call that has to be submitted to the CAS. Most often, this requires that a string represen-tation of the call with the format package.function(Arg1,Arg2) is created and sent to the CAS to be evaluated. The call string should be exactly the same as the one a human user would submit through the common interface of the CAS that is locally accessible.
An important difference between this type of call and a call submitted through the com-mand line interface of the target CAS is persistence. When working locally with a CAS such as GAP using the command line interface, a function call may affect the state of system or session variables that are stored in the memory of the CAS. A subsequent call in command line could potentially use the initialized values. This interactive behaviour is not available between two subsequent calls to a CAS Server without additional inter-mediary steps that would store and resume a certain state. For simplicity, calls to the CAS Server must be self explanatory and self contained and no previous state should be assumed.
3.7 Summary
In this chapter we have shown that distributed infrastructures for symbolic computations represent the solution for allowing computer algebra specialists to solve large symbolic problems. The design aspects of the CAS Server component presented in this chapter were previously presented in [58, 61, 148, 150, 129].
Computer Algebra Systems (CASs) represent the main computational engines for sym-bolic computing. We have shown that the most convenient way to build an infrastructure for symbolic computing is to reuse the capabilities of CASs by integrating them in a broader architecture. There are three important problems that have to be considered for successful integration of CASs: the encapsulation technique used to communicate with the CAS that further allows remote clients to communicate with the CAS; the data model used for encoding messages exchanged by the client and the CAS; the technology to be used for exposing CASs functionality to ensure that potential clients may access the functionality in a seamless fashion.
The CAS Server component was designed to allow more than one CAS to be exposed through the same interface. To achieve this, the CAS Server acts like a mediator between remote clients and exposed CASs. As discussed in Section 3.4 the way a CAS may be interconnected with the CAS Server depends on the capabilities that the CAS natively implements. Building wrappers specific to a certain CAS is the most convenient and flexible solution.
Interoperability represents one of the major issues in establishing a distributed symbolic environment. Lack of interoperability impedes potential clients from accessing func-tionality provided by CAS Servers. To overcome these problems three important issues have to be addressed: the consistency of the interfaces; the data model used for encod-ing messages and; the technology used for implementencod-ing the interfaces. The structure of the interface that the CAS Server exposes is unchanged irrespective the CASs that are exposed by the CAS Server. Driven by the requirements specified in 3.2, as a minimum
the following set of capabilities has to be provided: the ability to receive computational tasks and provide the results in an asynchronous way; a single point of entry through which the tasks should be submitted allowing thus more than one CAS to be exposed through the same interface; a set of operations to allow the user to discover provided functionality and; capabilities to manage execution of tasks. We have also shown that exposing CASs functionality should be done by permitting clients to access selected routines implemented by various CASs.
Symbolic components integrated in a distributed architecture, whether they are service providers or clients must use a common encoding format that can be used by all parties.
The most successful standard for encoding mathematical formulae is OpenMath. The SCSCP protocol is currently the ’de facto’ standard for CAS to CAS communication. We have designed the CAS Server component to use the SCSCP protocol for interconnection with CASs as most of the popular CASs already provide support of SCSCP. The use of OpenMath and SCSCP protocol is of paramount importance for interoperability and cooperation between CASs. Lack of support for SCSCP and OpenMath may be partially overcome by using an alternative non-standard encoding model that we have described in Subsection 3.6.2. The latter has the advantage that it may be used as a workaround in particular scenarios but it lacks the generality and flexibility that SCSCP and OpenMath provide.
Due to the advantages that Grid Services provides, as shown in 3.5 Grids may be consid-ered as the most suitable technology of building a distributed infrastructure for symbolic computations. We have used WSRF compliant Grid Services to implement the CAS Server component’s interface. Thus, the CAS Server may provide access to one or more CASs installed on a ordinary desktop machine or, in more advanced set-ups, it may hide a whole LAN or computational cluster.
The CAS Server is therefore a suitable solution for exposing CAS functionality to be accessible by remote clients. Grid Services and Web Services are standardized solutions for implementing the RPC architectural style. The interface of services is clearly defined
by the WSDL document of the service and any client can use a service if they are able to formulate correct requests, independent of the platform they use. New functions im-plemented by a CAS can be easily exposed through the Grid Service interface without the need to modify the services. In addition CAS Server provides a set of functional-ity that allows clients to discover which functions the CAS Server provides and they can control the execution of tasks by pausing, resuming and cancelling tasks. The ad-vantages that Grid Services provide in comparison with Web Services for implementing CAS Server are default security mechanisms and data management services that allow seamless transfer of files between execution nodes.
Orchestration of Web/Grid Symbolic Services
This chapter addresses the problem of composing the functionality of several CASs for solving symbolic computation problems as reported in [60, 61, 66, 148]. In Section 4.1 we analyse scientific workflows particularities and the special requirements they raise.
Symbolic computation workflows have to be expressed in a format that can be under-stood by existing workflow execution engines, usually as compositions of generic work-flow patterns. In Section 4.1.2 we provide a set of guidelines for translating common existing patterns in symbolic computations to the generic workflow pattern format.
An overview of generic tools and technologies for description, execution and manage-ment of scientific workflows is provided in Section 4.3. Their capabilities may be used to support the execution of symbolic computation workflows. In Section 4.4 we introduce a new component of our architecture, namely the Architecture for Grid Symbolic Ser-vices Orchestration (AGSSO) Server component. The AGSSO Server provides support for automatic execution of workflows for symbolic computation by orchestrating CAS Server components previously described in Chapter 3.
4.1 Service Orchestration for Symbolic Computing
In Subsection 4.1.1 we analyse the most important differences between regular business workflows and workflows for scientific computation. In Subsection 4.1.2 we briefly present the most common workflow patterns and workflow categories.