One of the goals of the SCIEnce project was to develop a communication protocol that would enable CASs to interact using a standard data encoding model. As a result SCSCP [96] protocol was designed. The SCSCP has become a de-facto standard with implemen-tations available for many CASs. Several major CASs, amongst them GAP and Maple, Kant, Macaulay [109], Mathematica, MuPAD, TRIP [103] provide support for SCSCP.
Frameworks and libraries for SCSCP implementations are available in C/C++ [16] and Java [17].
The design and the implementation of CAS Server and the design of the SCSCP protocol were done by two distinct teams working in the framework of the SCIEnce project and the CAS Server component was one of the first to support the use of SCSCP. As further described in Subsection 3.6.2 CAS Server supports a second format for encoding data.
There are two dimensions of the SCSCP protocol that influence CAS Server’s design.
The first one is related to the message encoding. It specifies the possible request and response formats for messages that a client exchanges with the SCSCP enables server.
Secondly, the SCSCP protocol encourages CASs to act as service providers. Playing the server role, a CAS should be started as a daemon process that listens to specific TCP/IP ports to which requests formulated using the SCSCP protocol should be submitted.
Even if the CAS is not prepared to provide TCP/IP connections this should not represent a major impediment. Its ability to understand SCSCP would still represent an important step ahead towards interoperability with other CASs. Alternative means could be used to deliver the messages to the CAS and retrieve the responses. According to SCSCP specification, any message exchanged between CASs should be a valid OpenMath ob-ject describing the call and meta-data regarding the call. Therefore, the CAS should also implement the OpenMath CDs used by the client to formulate the request. Currently, the support for OpenMath is growing and an increasing number of CASs consider imple-menting OpenMath parsers.
The SCSCP calls target functions that are implemented by the CAS handling the call.
When parsing a SCSCP call, the CAS should be able to identify the function that in-ternally should be executed and the list of arguments that have to be passed. Basically, OpenMath symbols from the SCSCP call are mapped locally to function names. By placing a certain OpenMath symbol inside the call the message actually requests that the associated local function is invoked. All arguments specified within the call and all responses should be described using OpenMath standard. An example of such message is given in Listing 3.1.
1. <OMOBJ>
2. <OMATTR>
3. <OMATP>
4. <OMS cd="scscp1" name="call_ID"/>
5. <OMSTR>anid</OMSTR>
6. </OMATP>
7. <OMA>
8. <OMS cd="scscp1" name="procedure_call"/>
9. <OMA>
10. <OMS cd="SCSCP_transient_1" name="Factorial"/>
11. <OMI> 10</OMI>
12. </OMA>
13. </OMA>
14. </OMATTR>
15. </OMOBJ>
Listing 3.1: Example of SCSCP Call
The call in Listing 3.1 represents a simple example that requests a the computation of a factorial. The header section of the SCSCP message may specify meta information regarding the request and the computational requirements that the machine on which the CAS is running should meet to be able to handle the call. Within the call the header is specified using the<OMATP> element starting at line 3. Conversational communica-tion patterns may even be supported by using a cookie mechanism that is able to relate multiple calls to a single client session. The mechanism of cookies that a CAS is able to understand should be supported by the the inner core of the CAS. External mecha-nism that could provide support for this feature, such as WS-Resources, are less generic.
Internal management should be preferred when sessions are required.
The OpenMath symbol used at line 8 is specific to SCSCP and instructs the CAS parsing the call that this is a remote call that targets a function implemented by the CAS. At line 10 the message specifies the OpenMath symbol that identifies the function that should be called, and further, it states that the simple OpenMath object<OMI>10</OMI> should
be passed as a parameter. Based on its internal configurations the CAS should be able to identify the correct function to call internally, to execute it and formulate a response to be returned to CAS’s client.
Using OpenMath for data encoding is an important step forward for CAS to CAS inter-operability. The use of OpenMath ensures that both the request and the response provide sufficient information to be mapped to internal data types in a deterministic way. Any CAS that implements support for the OpenMath dictionaries used within the call is able to understand the call and to take the appropriate actions. The SCSCP protocol provides a clear message structure that should be preferred for CAS to CAS communication.