Communication Interface between SAC-2 and LiDIA
Gábor A. Simon
Wilhelm-Schickard-Institut
Universität Tübingen
Germany
simon@informatik.uni-tuebingen.de
Unfortunately, the pictures are missing in this archive.
Motivation
- In the development of computer algebra algorithms
one would frequently like to use (perhaps only temporarily) existing
algorithms, which are implemented in different, possible incompatible systems.
- This means, that one needs possibilities which allow the cooperation,
communication between programs, applications, objects and environments despite
differences in
implementation language, execution environment and model abstraction.
There are a lot of computer algebra systems with different objectives.
- Huge, multipurpose systems (e.g., Mathematica or Maple etc.)
offering broad varieties of algorithms, which implies that it is impossible
to cope for them with the actual research state in every context.
- Highly specialized systems (KANT, SIMATH,
SINGULAR, PARI-GP etc.) with very efficient implementations of the latest
results in their particular field,
but these algorithms are only usable on the basis of their own system, because
of the tight coupling to the used arithmetic, memory management or model
abstraction.
One possible way to make these innovative algorithms available
outside their native system is standardization (E.g., OpenMath).
But there is little indication that the trend towards this diversity will
drastically change, and even if the standardization activities become more
and more stronger, the adaptation of the standards for all of these systems
will take a long time.
Our presented approach tries to use available industrial standards and
techniques to
solve these problems. We will discuss the advantages and disadvantages of this
attempt and show what parts have to be supplied by the application developer and
what can be automatically generated by tools.
Proposition
- A system should be constructed as a set of interacting objects.
It enables the implementation of different objects in different
programming languages. In order to enable interaction between such objects,
one needs to abstract the functionality provided by each object by clearly
defined interfaces.
- Tools should help to reduce the complexity of developing distributed
applications.
- The developer of an application should not need detailed knowledge
about the internals of the foreign systems to use their services exported
by an server application.
- Users of the client application should not have to care about localizing a
server application, they should be found automatically.
Is it realistic?
Distributed object managers as e.g, CORBA (Common Object Request Broker
Architecture) makes distributed application development easier,
providing an infrastructure.
- The Object Management Group, (OMG) is a consortium of
software vendors and end users.
- CORBA
provides the mechanisms by which objects transparently make
requests and receive responses, as defined by OMG's ORB.
The CORBA ORB provides interoperability between applications
built in (possibly) different languages, running on (possibly) different
machines in heterogeneous distributed environments.
Inter-Language Unification (ILU)
Xerox Corporation PARC
- CORBA like
- idl2isl convert CORBA IDL to ILU ISL
- Interoperability
- Between different programming languages
(Common Lisp, Modula-3, ANSI C, C++, Java, FORTRAN, ...)
- Between different operating systems
(UNIX, Windows NT, MacOS, ...)
- Between different binding models
(same (IPC) or different address space (RPC))
- using different RPC protocols
(ONC RPC, XNS Courier, DCE RPC, OMG CORBA)
ILU specific features
ILU Interface Specification Language (ISL)
- ISL is a declarative language which allow the definition of
object types (with methods) and attributes.
- An ISL interface contains four kinds of statements:
- the interface header,
- type declarations,
- exception declarations,
- constant declarations.
- Constructors for specifying complex data types are: ARRAY, SEQUENCE, RECORD
,
UNION, OPTIONAL, ENUMERATION, OBJECT.
- The In, Out, and InOut ISL specifications indicate that the associated argument
is to be read only, write only, or read/write respectively. These indications
in an ISL interface definition tell the stubber to either
send the argument data, receive the argument data, or both.
Stubber and Runtime Library
- The stubber typically generates a stub source file for clients, a stub
file for servers, and an include file of interface definitions.
E.g. the c-stubber generates the following files:
- InterfaceName-surrogate.c client specific file, used by users
of the modules (naming convention: Interface_Type_Method)
- InterfaceName-true.c server specific file, used by implementors of the modules (naming convention: server_Interface_Type_Method)
- InterfaceName-common.c functions common to both client and server
- InterfaceName.h include file for the stubs
- Client stubs and server stubs automat the following activities (in
conjunction with the ILU Kernel and the language specific runtime libraries (LSRL):
- Object location and binding
- Parameter marshalling and demarshalling
- The language specific runtime system is responsible for interfacing
between the generated stubs, client, server and the ILU kernel.
It must initialize the kernel, register objects, and respond to messages sent.
Sample Application
Using the following sample problem, we will demonstrate the
main steps the developer has to do to build an application based on
interoperable objects.
The client application generates a matrix with arbitrary precision coefficients, sending a request to the LiDIA server to compute its determinant,
and receiving the result or some error messages.
The first step is to build a server application, based on the interface definition using a selected subset of the LiDIA objects. The LiDIA package is implemented in C++.
The client application is written in ALDES, using the SAC-2 library. We used an
ANSI C backend for the ALDES implementation. That is why the communication specific part is written in C. The client application has to convert the arguments
of the requested LiDIA methods, if the arguments do not match the interface
used by the LiDIA server.
As the next Figure shows, both the client and server applications have
several parts, libraries and automatically generated stubs.
Server and Client-side Components of the Application
- Server-side
- ISL Specification
- Method Definition and Implementation
- Main Server Program
- Client-side
- Generated Stubs
- Method Activation
- Conversion modules
Server-side ISL Specification
Defines the interface between client and server.
INTERFACE det;
EXCEPTION DivideByZero;
EXCEPTION NumTooBig;
TYPE BigIntBJEC = OBJECT
METHODS
isbiggerthan ( x : INTEGER) : BOOLEAN,
setValue ( w : INTEGER),
setbigValue ( bw : BigInteger),
getValue () : INTEGER RAISES NumTooBig END,
add ( a : INTEGER),
bigadd ( ba : BigInteger),
mul ( m : INTEGER),
divrem (d : INTEGER) : INTEGER RAISES DivideByZero END
END;
TYPE BigIntMatriC = OBJECT
METHODS
setnorows (y : INTEGER),
setnocolumns (x :INTEGER),
setelem (x :INTEGER, y :INTEGER, e : BigInteger)
END;
TYPE bigintlib = OBJECT
METHODS
bigint ( wert : INTEGER ) : BigInteger,
bigintmatrix () : BigIntMatrix,
mul ( b : BigInteger, c : BigInteger) : BigInteger,
determ ( a : BigIntMatrix) : BigInteger
END;
This defines an interface det, exceptions DivideByZero and
NumTooBig, object types BigInteger, BigIntMatrix and
bigintlib. The interface, det, is a way of grouping a number o
f type
and exception definitions. This is important to prevent collisions
between names.
Server-side Method Definitions
The developer writes C++ definitions for the methods:
...
class BigIntMatrix : public det_T_BigIntMatrix {
public:
BigIntMatrix(); // constructor
// methods
void setnorows (detStatus *_status, long int y);
void setnocolumns (detStatus *_status, long int x);
void setelem (detStatus *_status, long int x, long int y,
class det_T_BigInteger *e);
// data
bigint_matrix M;
};
...
void
BigIntMatrix::setelem(detStatus *_status, long int x, long int y,
class det_T_BigInteger *e)
{
M.sto(x,y, ((class BigInteger *)e)->Wert);
_status->returnCode = detReply_Success;
}
...
Writing Main Server Program
...
int
main (int argc, char *argv[])
{
det_T_bigintlib *i;
iluServer s("det-server", NULL);
s.AddPort (NULL, NULL, ilu_TRUE);
ilu::SetDefaultServer(&s);
i = new bigintlib("BIGINT", &s);
if (!i->ILUPublish()) {
cerr << "**** Error, couldn't publish object\n" ;
exit(1);
}
cout << "Exported " << i->ILUStringBindingHandle() << "\n";
s.Run();
}
Binding a Client to a Target Object
Steps for binding a client to a target object:
- A client obtains an object reference from the server (
det_server_
connect
).
This object reference serves as a local proxy for the remote target object.
- Object references may be passed as parameters to other remote objects
(
m = det_bigintlib_bigintmatrix(l,&env);
).
- The client may then invoke methods on its proxy.
Client-side Example
The client programmer writes the following:
#include "det.h"
#define ERRCHECK if (!ILU_C_SUCCESSFUL(&env))
{ fprintf (stderr, "error signalled <%s>.\n",
ILU_C_EXCEPTION_ID(&env)); exit(1); }
int
LiDDET(int M)
{
int time;
/* LiDIA variables */
det_bigintlib l;
det_BigIntMatrix m;
det_BigInteger e;
det_BigInteger d;
/* ALDES/SAC-2 variables */
extern int SPACE[], BETA, BETA1;
/* ILU variables */
ILU_C_ENVIRONMENT env;
...
extern int libi2abi();
extern det_BigInteger abi2libi();
extern det_bigintlib det_bigintlib_determ();
l = det_server_connect();
/* creating LiDIA - BigIntMatrix m */
...
d = det_bigintlib_determ (l, &env, m); ERRCHECK;
time = CLOCK()-time;
printf("execution time : %d ms\n", time);
/* get back the result and convert to SAC-2 format */
time = CLOCK();
D = libi2abi( d);
time = CLOCK()-time;
printf("transf.+conv. of the determinant d : %d ms\n", time);
return D;
}
Conclusion
- Advantages
- The main advantage of the CORBA approach is the universality. One can
use the same technique not only between CA systems, but in connection with
graphic (e.g., FRESCO), numeric, or database libraries.
- Some convenient features of the communication (server lookup etc.).
- Disadvantages
- The lack of special facilities for algebraic structures and contexts.
Relation to OpenMath
- The use of interfaces describing the functionality of the exported
objects allows a great flexibility. This enables the implementation of
server
applications using an export interface on the basis of OpenMath even if the
internal representation is totally different. (Sutor: Object Standard?)
This means that the server stubs, generated from the
OpenMath conform interface, should be extended with the necessary
conversions mapping the external representation onto the internal
implementation.
- In this case, the client applications are working only with the
external representation defined in the interface definition.
Future plans
- It would be interesting to rebuild an OpenMath
prototype application using this technique. (MathEdge)
- Dynamic interface invocation
The interface definition which a client program can use is determined at
compile time. Hence the client code is limited to using those servers
which contain objects that provide the interface selected by the client
when building an application.
Dynamic interface invocation allows an application to issue requests
for any interface, even if it was unknown at compile time.
- High level interface definition language, with
algebraic type information. (Schupp, SUCH THAT)
This page is part of the OpenMath Web archive,
and is no longer kept up to date.