
%%% latex2e file
%%%
%%% $Id: groebner-in-java.tex,v 1.14 1998/03/27 13:37:52 weber Exp $
%%%

%\documentclass{acmconf}
\documentclass{article}
%\documentclass[twocolumn]{article}
\usepackage{times}
%\usepackage{a4}
%\usepackage{exposso}
%\textwidth  15.5cm  
%\textheight 22.0cm
%\oddsidemargin 0.5cm
%\evensidemargin 0.5cm
%\topmargin 0.0cm

\def\Maple{{Maple}} 

\def\Mathematica{{Mathematica}}
\def\Macsyma{{Macsyma}}
\def\CORBA{{CORBA}}
\def\ILU{{ILU}}
\def\Mupad{{Mupad}}
\def\MathBus{{MathBus}}
\def\OpenMath{{OpenMath}}
\def\SACLIB{{SACLIB}}
\def\CANNES{{CANNES}}
\def\LiDIA{{LiDIA}}
\def\IPGCDC{{IPGCDC}}
\def\IPGCD{{IPGCD}}
\def\IPQ{{IPQ}}
\def\PoSSo{{PoSSo}}
\def\CANNES{{CANNES}}
\def\PARCANNES{{PARCAN}}
\def\CASPI{{CAS/PI}}
\def\COM{{COM}}
\def\DSOM{{DSOM}}
\def\UNIX{{UNIX}}
\def\JAVA{{Java}}
\def\AXIOM{{Axiom}}
\def\Magma{{Magma}}
\def\Reduce{{Reduce}}
\def\Matlab{{Matlab}}
\def\Scilab{{Scilab}}
\def\Octave{{Octave}}

\begin{document}
\sloppy

\author{Andreas Weber\thanks{Supported by 
{\em Deutsche Forschungsgemeinschaft\/} 
under grants We~1945/1-1 and Ku~966/4-1.}
 \and Wolfgang K\"uchlin \and Bernhard Eggers
\\
Wilhelm-Schickard-Institut f\"ur Informatik \\
Universit\"at T\"ubingen,
72076 T\"ubingen, Germany\\
E-mail:~{\tt \{weber,kuechlin\}@informatik.uni-tuebingen.de} \\
WWW:~{\tt http://www-sr.informatik.uni-tuebingen.de}}
\title{Parallel Computer Algebra Software \\
as a Web Component}
\maketitle

\begin{abstract}
In the field of computer algebra, joining separate 
computer algebra systems with individual strengths into
problem solving environments is an 
important recent research direction.
In this paper we describe how we wrapped a
specialized computer algebra system, which uses
shared-memory parallelism to speed up  Gr\"obner basis
computations, into a Web component that can be used
by other systems.
By this component also a new algorithmic development in Gr\"obner
basis computations---the use of the  
{\em Fractal Gr\"obner Walk\/}---was made available 
to various general purpose computer algebra systems
in the form of a single optimized implementation.
Previously, all of the important algorithmic improvements to an
algorithm had to be reimplemented in the general purpose systems.
Our implementation allows access to the Gr\"obner basis
computations via ``intelligent'' graphical user interfaces
and via scripting from existing general purpose algebra systems.
\end{abstract}


\section{Introduction}


Joining separate numeric and algebraic
systems and algorithmic software components with individual strengths into
problem solving environments is an 
important recent research direction.
Currently, the existing systems can be subdivided roughly
into two categories.


{\em General purpose systems\/} --- algebra systems such as  
\AXIOM{}, % \cite{JenksSutor92}, 
\Macsyma{}, %\cite{ },
\Magma{}, % \cite{CannonPlayoust97},
\Maple{}, % \cite{CharGeddes91,CharGeddes91a}, 
\Mathematica{}, %\cite{Wolfram91}, 
\Mupad{},
\Reduce{} %\cite{Hearn87},
or numeric systems such as
\Matlab{}, %\cite{Matlab5},
\Octave{},
\Scilab{} %\cite{ScilabHomePage}
 ---
come with nice user interfaces and
sophisticated graphical capabilities
and contain a broad range of computer algebra or numeric algorithms.
However, because of the size of the systems and the
broad range they cover, they cannot be always up to date
algorithmically.
Also the software architecture of such a general purpose 
system---consisting of a kernel and an interpreted language
in which many algorithms are written---yields 
computational overheads that can be avoided by 
systems optimized for a certain class of algebra problems.
Also these systems are in general not suited to make
use of special hardware, such as shared-memory multiprocessors.


{\em Specialized systems\/} are usually 
      developed by  research groups 
      that concentrate on algorithm
      research in one special area of computer algebra
      or scientific computing. These systems usually
      contain the latest algorithms of these areas and
      their implementations are very often tuned up
      considerably. Several of these systems are
      developed for high-performance computing architectures
      such as parallel machines.
      However, these systems usually have
      a limited scope and crude user interfaces.

Connections between different algebra systems---or algebra
systems and other scientific code---are
of major interest for different reasons.

      First, instead of reimplementing a new algorithm in all
      of the general purpose systems, a single optimized
      implementation could be used, 
      if the specialized system
      in which the algorithm is implemented,
      and which runs e.\,g.\ on a parallel machine, could be reused as
      a {\em software component\/}.

      Second, the different areas of computer algebra overlap 
      and many of the fundamental algorithms developed 
      in one area can be used in other areas, too.
      As a result, in many specialized systems many
      algorithms have to be reimplemented because
      they are needed for further extensions. This reimplementation
      is then often done by a group specialized in another area,
      who might not implement the best available algorithm but
      only a well known one.
    
      Third, solving problems that arise in ``real world situations''
      usually requires a combination of methods, 
      not only from computer algebra but also from other areas.

    
Below we will describe how we achieved such a combination
of systems in the case of a high performance Gr\"obner basis
solver which can use the power of shared-memory multiprocessors.
Thus this software will perform best on special hardware
and should not be ported to all platforms
on which a potential user works.

The encapsulation of the parallel system and access to it
is done with \JAVA{} using various techniques that
are well supported by \JAVA{}. 
We use the  \MathBus{} \cite{mathbus-termstructure} exchange 
format for the transmission
of mathematical data that has been developed over the last
years. We can easily adapt our software to
another exchange format such as \OpenMath{} \cite{DalmasGaetanoWatt:97}
or can use several formats simultaneously.
Having such an exchange format is one important
prerequisite for the combination of various systems.
Exchange formats  address the data aspect of
the communication between systems. The orthogonal issue
of calling the functionality of a remote system
has to be treated by different means.
For this purpose we found the various techniques 
offered by \JAVA{} very useful---provided the
remote functionality is coarse grained enough
so that the performance penalties given by \JAVA{}
for the communication are negligible.\footnote{For
low or medium grained applications the
use of a \CORBA{} object broker is advantageous.
We refer to \cite{WeberKuechlinHoss98a} for a case study
which shows that \CORBA{} object brokers can be used
to efficiently call remote functionality of a surprisingly
low granularity.}
So we assume that our solution is prototypical for
many other systems, too.



The organization of the paper will be as follows:
In Sec.~\ref{sec:backgr} we will give some background
information about Gr\"obner basis computations in general
and the high-performance Gr\"obner solver which we made
accessible in particular.
In Sec.~\ref{sec:wwwaccess} we describe the various
access methods we provided and their technical realization.
In the concluding Section~\ref{se:concl} we discuss
various aspects of the use of \JAVA{} for our project
that will apply to similar projects.


\section{Background}
\label{sec:backgr}

\subsection{Gr\"obner Bases}
\label{subse:grba}

The computation of 
Gr\"obner bases \cite{Buchberger:65,Buchberger:70,BeckerWeispfenning93}
is of central importance in computer algebra.
They have many applications ranging from
pure mathematics to the solution of systems of
non-linear polynomial
equations arising, for example,
in the inverse kinematic problem in robotics.
Full sections of conferences like ISSAC
\cite{ISSAC97,ISSAC96,ISSAC95}, or even entire conferences 
\cite{GB:98} are devoted to 
the topic of Gr\"obner basis computations.
Thus we can only give a rough sketch of the topic and refer
to the literature for further details.

Given a set ${\cal P}$ of (in general non-linear)
polynomials, a Gr\"obner basis is a unique normal form
${\rm GB}({\cal P})$ for ${\cal P}$ with the same roots.
The shape of ${\rm GB}({\cal P})$ depends on an ordering
on the monomials, the so-called term ordering.
Different orderings are useful for different purposes;
e.\,g.\, total degree orderings usually lead
to fast Gr\"obner basis computations, lexicographic
orderings lead to systems from which the actual solutions
can be extracted relatively easily.

Given any ${\cal P}$ and term order $>$, Buchberger's famous
algorithm will compute ${\rm GB}_{>}({\cal P})$
in finite (but possibly astronomic) time.
Given any ${\rm GB}_{>}({\cal P})$ and
another term order $\succ$, the
{\em Gr\"obner walk algorithm} \cite{CollartKalkbrennerMall97a,AmrheinGloorKuechlin:97}
will compute ${\rm GB}_{\succ}({\cal P})={\rm Walk}_{\succ}({\rm GB}_{>}({\cal P}))$ in finite time.
Practical experience shows that
it is often much more efficient to compute
${\rm Walk}_{\rm lex}({\rm GB}_{\rm tot}({\cal P}))$
than
${\rm GB}_{\rm lex}({\cal P})$.
Experience has also shown that Buchberger's algorithm is extremely difficult
to parallelize.


The speed of a Gr\"obner basis computation heavily depends
on several other parameters, whose choice has been the topic
of intense research. The result of the computation will
be independent of the choice of these internal parameters.
However, they usually have a dramatic influence on the necessary
computation time.
There is no best choice for any of these internal parameters,
but there are examples for which each of the possible
settings performs better than the others.
However, some  heuristics have
been developed that will yield good results
for many examples. We included one of these heuristics
into our system, cf.\ Sec.~\ref{subse:newgui}.


Each of the general purpose computer algebra systems
has an implementation of Gr\"obner basis algorithms,
but because of the algorithmic developments these
implementations perform worse in general than the recent
high-performance implementations. To our knowledge
the so called 
{\em Fractal Gr\"obner Walk\/} \cite{AmrheinGloor:98}---an improved 
Gr\"obner walk procedure---has not been integrated into
one of the general purpose systems up to now.
On the one hand, since the computation
time for Gr\"obner bases given by application problems
very often ranges from
several minutes or hours to intractably large, fast Gr\"obner basis 
algorithms are important. On the other hand---since the
computation of a Gr\"obner basis is very often only one step
in a series of computations---the integration of a fast Gr\"obner
basis engine into a larger environment is also important.

Thus the general situation sketched in the
introduction applies particularly well
to Gr\"obner basis computations. 



\subsection{High Performance Gr\"obner Basis Computation}

The high-performance Gr\"obner solver 
that we made available via the WWW is
an improvement of the system described
in \cite{AmrheinGloorKuechlin:96}.
It is
based on the parallel computer algebra nucleus
\PARCANNES{} \cite{GloorMueller:98}.
This nucleus gives a very efficient implementation
of arbitrary precision integers on the basis of
GNU/MP and of lists, including an automatic
garbage collection. 
Using the parallel features of \PARCANNES{} 
the Gr\"obner solver
shows remarkable speed-ups
on shared-memory multiprocessors. Even
super-linear speed-ups due to strategy effects have been
observed \cite{AmrheinGloorKuechlin:96}.
It currently runs on  multi-processor SUN SPARC stations.

On the algorithmic side, improvements of the
Gr\"obner walk technique
have been developed 
\cite{AmrheinGloorKuechlin:96b,AmrheinGloorKuechlin:97} and implemented.
So far the most efficient of these is the
{\em Fractal Walk\/} \cite{AmrheinGloor:98}, which
is the version we use in the system described in this paper.



\section{Accessing the High-Performance Gr\"obner Basis Software via the WWW}
\label{sec:wwwaccess}


We provide three different access methods to our high-performance
symbolic software. 


 Methods that allow scripting access to the high-performance
      solvers out of a general purpose algebra system are one of them.
      This method of access will be described in Sec.~\ref{subse:script}.

 A graphical user interface in the form of a \JAVA{} applet
 will be more convenient for casual users.
      Using copy and paste operations data can be
      transferred from an application into the data input Window
      of the applet. The format of various algebra systems
      can be used for input and output to the applet.
      Support for other formats
      can be added dynamically by a user, if
      converters to the new target system
      and our internally used format are provided.
      The graphical user interface in  this sophisticated
      version uses several features of JDK 1.1.
      We will describe it in more detail in Sec.~\ref{subse:newgui}.
 
  To allow access to the system from older browsers
      we still export a simpler graphical user interface that
      uses JDK 1.0.2. 

\bigskip\noindent
The graphical user interfaces can be reached from the following URL: \\
{\tt http://\linebreak[2]www-sr.informatik.uni-tuebingen.de/\linebreak[2]projects/\linebreak[2]webcomponents/
}\\
If you are interested in the software for scripting
access, write an e-mail to the first author.



\subsection{A Sophisticated Graphical Java Interface}
\label{subse:newgui}

For a description of the functionality of this user
interface, we refer to the URL given above. From this 
Web page, the \JAVA{} applet building the
graphical user interface itself and some commenting Web pages
can be reached.
Below we will focus on some important points in its
internal organization.

\paragraph{Dealing with Different Representations of Mathematical Data.}


Different computer algebra systems often use different syntactic 
representations
of the mathematical objects they are dealing with.
Since input of data into our graphical user interface
will be typically achieved
by copy and paste operations of textual representations
of mathematical expressions
out of a general purpose computer algebra system,
we support several formats for input and output
of mathematical data.


Internally we use a single exchange format
and provide parsers and
converters from and to other formats.
The exchange format we use is the
\MathBus{} \cite{mathbus-termstructure}, which was especially developed
as a bridge between different systems, especially computer
algebra systems.
However, we can easily adapt our software to
another exchange format such as \OpenMath{} \cite{DalmasGaetanoWatt:97}
or can use several formats simultaneously.


Up to now we have implemented converters from and to the computer algebra
systems \Maple{} and \Mathematica{} and the 
format used by the parallel Gr\"obner solver. 
Converting data from the \MathBus{}
into another format is quite easy, since the \MathBus{}
format is a quite general expression tree format.
Converting data from \Mathematica{} into the \MathBus{} format
could be done with a parser generator.\footnote{The same holds
for the format used by \Maple{} or the parallel Gr\"obner solver.} 
We used the \JAVA{} Bison system
\cite{jbf-manual54} for this purpose.
Incorporating  converters for other algebra systems---such as \Mupad{},
\Macsyma{}, or \Reduce{}---can be done by simply adapting
the grammar of the parser
for the algebra system
and writing the straight-forward conversion from the \MathBus{} format into the format of the new system. 
So an extension
to many other formats is straight forward. 

The converter classes all inherit from a common class,
and the choice of the actually used converter class
is done via the dynamic class selection and load mechanism
of \JAVA{}. The user can choose a converter
via selection from a list or by providing
its name. Thus an unlimited number of new converters
can be included into the graphical user interface dynamically,
if the appropriate naming conventions are obeyed.


\paragraph{Choice of a Good Computation Strategy.}

The result
of a Gr\"obner basis computation is
independent of the value of several {\em internal parameters\/}
but their appropriate choice 
usually has a dramatic influence on the computation
time. 
Many users who need the result of a Gr\"obner
basis computation but are not researchers in the field
of Gr\"obner bases
will find it valuable if the system provides a good 
heuristic choice for these internal parameters.
Thus we have included the computation of such a heuristic into our applet.
Having the full power of an object-oriented language
such as \JAVA{} available at the WWW-interface, this is 
a relatively easy task. However, using a simpler interface
such as an HTML-form, this useful functionality
would be hard to provide.


\begin{figure*}
\begin{tabular}{l}
Client \\
(\JAVA{})
\end{tabular}
\hfil
\begin{tabular}{|cccc|}
\hline
\multicolumn{4}{|c|}{GUI} \\
\hline
\hline
\multicolumn{3}{|c||}{Format converters} &
\multicolumn{1}{|c|}{Strategy} \\
\multicolumn{3}{|c||}{} &
\multicolumn{1}{|c|}{selection} \\
\multicolumn{3}{|c||}{
} 
&
\multicolumn{1}{|c|}{} \\
\hline
\multicolumn{4}{|c|}{Algebraic function choice and} \\
\multicolumn{4}{|c|}{composition (uses \MathBus{})} \\
\hline
\hline
Poly.\ expand proxy & \multicolumn{2}{|c|}{Gr\"obner solver proxy} & Walk proxy \\
(wrapped version) & \multicolumn{2}{|c|}{(wrapped version)} & 
(wrapped version) \\
\hline
\end{tabular}

\bigskip
\hfil 
{\large
{\bf RMI} \quad {\boldmath $\Updownarrow$}
}



\bigskip
\begin{tabular}{l}
Server \\
(\JAVA{} / C)
\end{tabular}
\hfil
\begin{tabular}{|c|}
\hline
Java wrapper \\
\hline
Poly.\ expand \\
\\
\hline
\end{tabular}
\quad
\begin{tabular}{|c|}
\hline
Java wrapper \\
\hline
Gr\"obner solver \\
(parallel system) \\
\hline
\end{tabular}
\quad
\begin{tabular}{|c|}
\hline
Java wrapper \\
\hline
Walk \\
 \\
\hline
\end{tabular}

\medskip
\caption{Schematic overview of the software components: graphical user interface}
\label{fig:newguischema}
\end{figure*}

\paragraph{Internal Organization of the Different Computations.}
A schematic view of the internal organization
is given in Fig.~\ref{fig:newguischema}.
The graphical user interface, the functions that select 
a computation strategy and the converters from the different
data formats are all written in \JAVA{} and will be performed
on the client computer.

The following programs will be executed on our
parallel server computer.
      The parallel Gr\"obner solver;
      a high-performance implementation of the Fractal Gr\"obner Walk;
      a small C program based on the \SACLIB{} 
      computer algebra library \cite{BuchbergerCollins93}
      which expands polynomials. This function
      serves as an improvement to the user friendliness
      of the interface,
      because the user might give polynomials
      in non-expanded form, but the Gr\"obner solver
      expects its input polynomials in expanded form.
These programs are wrapped into \JAVA{} classes.
The connection between the applet residing on the
client and the classes on the server side
is achieved via RMI.
For performance reasons the first two of these programs
should always run on a high-performance computer.
The last of these functions  could be included into the applet.
However, using an existing C-library the required functionality
could be implemented with little effort in C,
whereas porting the needed functionality from the \SACLIB{}
to \JAVA{}
would have required a much greater effort.
Thus this functionality also is
assigned to the server machine.
Wrapping it as a \JAVA{} class and making it available
to the applet via RMI gave almost the same functionality
as a direct \JAVA{} implementation
and allowed the reuse of proven C-code.


RMI allowed a very nice integration of this wrapped
high-performance code into the \JAVA{} code written for
the client. 
Besides the interaction of the user with the
GUI, the general data flow is that the input
data are parsed into \MathBus{} format according
to the user specified parser. The input polynomials are
normalized by the component that expands polynomials,
and the result is used as input to the Gr\"obner solver,
together with the user input of the term ordering induced
by the ordering on variables specified by the user.
Moreover, this function also gets the ``internal parameters''
as input, which were either chosen by our heuristics or
specified by the user.
The return value of this function is the desired result
unless a Gr\"obner Basis with respect to the lexicographic
ordering has to be computed using the Fractal Gr\"obner Walk.
In this case, the return value is 
the input to the Gr\"obner walk component, together with
the parameters for start ordering and target ordering,
which are known to the program.

This data flow requires several calls to the remote objects
together with some minor computations in the client.
The implementation of the code for these computations
and the required calls to the remote objects
could be written almost as if only local calls
to \JAVA{} objects had to be performed.
Especially the treatment of exceptional states---parse
errors in the converters written in \JAVA{}, out of memory exceptions
for the remote components or other special states
such as a failure in a Gr\"obner basis computation---could be
done uniformly by the \JAVA{} exception mechanism, independent
of their status as local or remote calls.
For this purpose the \JAVA{} wrapper for the C-programs
examine and transform diagnostic output of the C-programs
into \JAVA{} exceptions, which are then transported transparently
to the client by RMI. The output of the C-programs which
constitute the result of the computation is wrapped
into the return value of the \JAVA{} wrapper function.

Thus this program infrastructure is well suited to be enhanced
by additional software components---e.\,g.\ ones
that solve a system of non-linear equations via a Gr\"obner basis
computation. The program complexity for connecting such remote
components is not higher than using local \JAVA{} method
calls in the implementation of a new \JAVA{} method.



\subsection{Scripting Access to the High-Performance Software}
\label{subse:script}

      Although access via one of the graphical user interfaces described
      above is much more convenient for a casual use of 
      the parallel software,  frequent users might want
      to have scripting access to our parallel system
      out of their own algebra systems.
  
      We thus provide \JAVA{} classes that allow the various general purpose
      systems to encapsulate the remote access to the parallel
      Gr\"obner solver in a function of the 
      particular system.
      To overcome the security restrictions on applets
      these classes have to be installed
      on the client computer. 
      Most of the client side classes of the sophisticated graphical user
      interface (cf.\ Sec.~\ref{subse:newgui}) are reused for this
      purpose, and via RMI they access the {\em identical server side
      software\/} as the sophisticated graphical user interface does.
      A schematic view of these software components is given
      in Fig.~\ref{fig:scr}.
      
      \begin{figure*}
\bigskip
\begin{tabular}{l}
Client \\
(Language of \\
Algebra System)
\end{tabular}
\hfil
\begin{tabular}{|c|}
\hline
Mathematica function \\
\hline
call of external program \\
\hline
\end{tabular}
\quad
\begin{tabular}{|c|}
\hline
Maple function \\
\hline
call of external program \\
\hline
\end{tabular}



\smallskip
\hfil 
{
{OS File/Pipe} \quad {\boldmath $\Updownarrow$}
}

\smallskip



\begin{tabular}{l}
Client \\
(\JAVA{})
\end{tabular}
\hfil
\begin{tabular}{|c|c|c|}
\hline
IO-Adaptor & IO-Adaptor & IO-Adaptor \\
\hline
Format converters & Format converters & Format converters \\
\hline
\MathBus{} & \MathBus{} & \MathBus{} \\
\hline
Poly.\ expand proxy & {Gr\"obner solver proxy} & Walk proxy \\
(wrapped version) & {(wrapped version)} &  (wrapped version) \\
\hline
\end{tabular}

\bigskip
\hfil 
{\large
{\bf RMI} \quad {\boldmath $\Updownarrow$}
}


\bigskip
\begin{tabular}{l}
Server \\
(\JAVA{} / C)
\end{tabular}
\hfil
\begin{tabular}{|c|}
\hline
Java wrapper \\
\hline
Poly.\ expand \\
\\
\hline
\end{tabular}
\quad
\begin{tabular}{|c|}
\hline
Java wrapper \\
\hline
Gr\"obner solver \\
(parallel system) \\
\hline
\end{tabular}
\quad
\begin{tabular}{|c|}
\hline
Java wrapper \\
\hline
Walk \\
 \\
\hline
\end{tabular}


\medskip
\caption{Schematic overview of the software components: scripting access to general purpose system}
\label{fig:scr}
      \end{figure*}

      
     If a host algebra system allows direct access to \JAVA{},
     these classes can be incorporated directly.
     However,  the current general purpose algebra
     systems do not have this feature.
     Usually they allow system calls
     and communication via pipes.
     Thus for the client side proxies
     we have implemented wrapper \JAVA{}
     programs that read their input from standard input, write
     the result to standard output, and write the values of any exceptions
     to standard error. 
     In addition to the parameters of the algebraic functions 
     these programs also take the
     name of an algebra system as an additional
     parameter and perform the appropriate conversions
     for the input and output data.

     Using these client side \JAVA{} programs we will provide functions
     for the computer algebra systems \Maple{} and \Mathematica{}, 
     which behave
     to the user in the same way as the built-in \Maple{} resp.\
     \Mathematica{} functions
     for Gr\"obner basis computations do, but which use the scripting
     access to our parallel Gr\"obner solver and the
     Fractal Gr\"obner Walk component to perform the computations
     instead of using a local sequential computation.
     Since \Maple{} and \Mathematica{} allow system calls
     and communication via pipes, the client side \JAVA{} programs
     can be accessed from the \Maple{} resp.\ \Mathematica{} functions
     in this way. The client side \JAVA{} programs
     access the server functionality via RMI
     in the same way as it is accessed from the graphical user interface.
     The heuristics to choose the internal parameters
     will be computed in the \Maple{} resp.\ \Mathematica{} functions
     we provide.
     

\subsection{Use of \JAVA{} Beans}

So far we have not provided our \JAVA{} components
as \JAVA{} Beans but as simple applets
and stand alone \JAVA{} programs and \JAVA{} class libraries. 
Using 
\JAVA{} Beans for a graphical user interface would have the advantage
that
frequent users could store
their own default settings instead of using the ones
provided by us.
However, there are few default
settings independent of the computation 
of a heuristics for the choice
of the internal parameters. 
Changes in these heuristics cannot be easily accomplished
by the user by the currently available \JAVA{} Beans mechanisms.
Thus up to now the use of \JAVA{} Beans seems to have little advantages
over a simpler \JAVA{} applet for our particular application.

Moreover, we think that for frequent users the access method of choice
is  to use the scripting interface
out of their general purpose algebra systems.
Up to now the use of \JAVA{} Beans gives little
advantages for the scripting interface: some of our
functions need an additional parameter which could 
be avoided using \JAVA{} Beans, but this is a minor issue
in the few lines of code that have to be written once for
any target algebra system.

As soon as the
general purpose computer algebra systems  provide 
direct access to \JAVA{} and \JAVA{} Beans, 
the use of \JAVA{} Beans will be 
reconsidered. Nevertheless,
it takes only a relatively
minor effort to transform our components to \JAVA{} Beans.



\section{Conclusion}
\label{se:concl}

The idea of software components is certainly not a new one.
E.\,g., the success of \UNIX{} can be attributed in part to the concept 
of many small software tools that can be combined to 
more powerful ones by pipes or shell scripts.

However, \JAVA{} based software components have
all the advantages of \UNIX{} components but also give
several important enhancements over the \UNIX{} concept.
The arguments to a \UNIX{} software component
are usually given in the string of command line
arguments. Thus no static argument type checking
can be done, but all typing errors in the arguments
of a \UNIX{} components can only be detected at run
time. Wrapping software components---such as ours---in \JAVA{}
programs gives the full type checking support of a \JAVA{}
compiler to detect type errors at compile time.

Another very important advantage of \JAVA{} as a wrapper language
is the possibility to use the \JAVA{}
exception mechanism to reliably communicate
exceptional states of our software components---such
as parse errors, out of memory exceptions,
or resource limitations that we have imposed on remote users.

Moreover, \JAVA{} as a scripting language is much more powerful
than the scripting languages for \UNIX{} shells or
similar ones that had to be used otherwise.
The support of the object-oriented paradigm, which has proven to be
so fruitful for many larger
applications, is missing in most of
the traditional scripting languages.

The use of a single programming language for implementing
or wrapping
additional software components such as the parser classes
and as a scripting language to connect different components
has several additional advantages.
\begin{itemize}
\item It is not necessary that the implementer is proficient
      in several languages in order to produce high-quality code.
\item A much better interaction between the different components
      is possible, if they are written or included within the
      same programming language.
\item Since the user interface is also written in \JAVA{},
      a much better integration between the software and
      the user interface is possible. For instance the intelligent
      selection of a good computation strategy out of
      user requirements would have been much harder to realize
      if the user interface and the scripting language that
      connects the software components had been different.
\end{itemize}

%The fact that \JAVA{} classes are \JAVA{} objects and
%can be dynamically added to existing and even running
%\JAVA{} code has been used to give a user the possibility
%to dynamically extend our user interface with a converter into
%his own format. This nice feature, which comes almost
%for free with \JAVA{}, is one that were quite hard to achieve
%with a traditional programming language.

The most important aspect for our purpose was the availability
of RMI. Although we also implemented access to the Gr\"obner system
and to the Gr\"obner walk in our JDK~1.0.2 interface
in a more traditional client server system---using
socket communication and cgi-scripts---the integration
of several remote components into one new system
was greatly facilitated by RMI.
Connecting several remote components---the Gr\"obner  solver,
the program computing a Fractal Gr\"obner Walk, or the small
component that expands polynomials---together with
some additional functionality written in
\JAVA{}---such as the converter classes---can be done
in a clear software structure using RMI.

With RMI the wrapped high-performance C-code could be used
within \JAVA{} as if it had been written in \JAVA{}.
Thus there is no need to port the high-performance
code to other architectures.
Since high-performance code is often optimized towards
a specialized architecture, porting this code to other
architectures is often not only difficult but would often
yield a suboptimal solution. In this respect we suppose
that our solution is not only prototypical for
high-performance computer algebra code, but
also for any high-performance code.

Moreover, this tight integration of
code into \JAVA{} gave the flexibility not only to access the
high-performance code on a remote shared-memory multiprocessor,
but also to reuse some legacy code
as a component, which is not bound to a specialized hardware.

Since the parallel Gr\"obner code should run with the highest
possible performance but any invocation of it is of quite
coarse granularity, wrapping the existing code and accessing
it via RMI  currently
has a much better performance characteristics
than translating all of the Gr\"obner code into \JAVA{}.


\bigskip\noindent
{\bf Acknowledgments.} We are grateful to B.~Amrhein and O.~Gloor
for many helpful discussions about Gr\"obner basis computations.
The software kernels that we wrapped to components,
connected via \JAVA{},
and made available on the WWW were built within
their research on high-performance Gr\"obner basis computations,
supported by {\em Deutsche Forschungsgemeinschaft\/}
under grant Ku~966/2-2.
We are grateful to R.~Zippel for many helpful
discussions about the \MathBus{}.

%\iftrue
%\bibliographystyle{acm}
%\addcontentsline{toc}{section}{References}
%\bibliography{weber}
%\fi

\begin{thebibliography}{10}

\bibitem{AmrheinGloor:98}
{\sc Amrhein, B., and Gloor, O.}
\newblock The Fractal Walk.
\newblock In Buchberger and Winkler \cite{GB:98}, pp.~305--322.

\bibitem{AmrheinGloorKuechlin:96}
{\sc Amrhein, B., Gloor, O., and K{\"u}chlin, W.}
\newblock A case study of multi-threaded {G}r{\"o}bner basis completion.
\newblock In Lakshman \cite{ISSAC96}.

\bibitem{AmrheinGloorKuechlin:96b}
{\sc Amrhein, B., Gloor, O., and K{\"u}chlin, W.}
\newblock Walking faster.
\newblock In {\em Design and Implementation of Symbolic Computation Systems ---
  International Symposium {DISCO~'96}\/} (Karlsruhe, Germany, Sept. 1996),
  J.~Calmet and C.~Limongelli, Eds., vol.~1128 of {\em Lecture Notes in
  Computer Science}, Springer-Verlag.

\bibitem{AmrheinGloorKuechlin:97}
{\sc Amrhein, B., Gloor, O., and K{\"u}chlin, W.}
\newblock On the {W}alk.
\newblock {\em Theoretical Comput. Sci. 187\/} (1997), 179--202.

\bibitem{BeckerWeispfenning93}
{\sc Becker, T., and Weispfenning, V.}
\newblock {\em {Gr{\"o}bner} Bases: A Computational Approach to Commutative
  Algebra}, vol.~141 of {\em Graduate Texts in Mathematics}.
\newblock Springer-Verlag, 1993.

\bibitem{Buchberger:65}
{\sc Buchberger, B.}
\newblock {\em Ein {A}lgorithmus zum {A}uffinden der {B}asiselemente des
  {R}est\-klas\-sen\-ringes nach einem nulldimensionalen {P}olynomideal}.
\newblock PhD thesis, Universit{\"a}t Innsbruck, 1965.

\bibitem{Buchberger:70}
{\sc Buchberger, B.}
\newblock Ein algorithmisches {K}riterium f{\"u}r die {L}{\"o}sbarkeit eines
  algebraischen {G}leichungssystems.
\newblock {\em Aequationes Mathematicae 4}, 3 (1970), 374--383.

\bibitem{BuchbergerCollins93}
{\sc Buchberger, B., Collins, G.~E., Encarnaci{\'o}n, M.~J., Hong, H., Johnson,
  J.~R., Krandick, W., Loos, R., Mandache, A., Neubacher, A., and Vielhaber,
  H.}
\newblock {\em {SACLIB} User's Guide}.
\newblock Johannes Kepler Universit\"at, 4020~Linz, Austria, Mar. 1993.
\newblock Available via anonymous ftp at {\tt melmac.risc.uni-linz.ac.at} in
  {\tt pub/saclib}.

\bibitem{GB:98}
{\sc Buchberger, B., and Winkler, F.}, Eds.
\newblock {\em {Gr{\"o}bner} Bases and Applications---Int.\ Conf.\ 33 Years of
  {Gr{\"o}bner} Bases\/} (Feb. 1998), vol.~251 of {\em London Mathematical
  Society Lecture Notes Series}, Cambridge University Press.

\bibitem{CollartKalkbrennerMall97a}
{\sc Collart, S., Kalkbrener, M., and Mall, D.}
\newblock Converting bases with the {Gr{\"o}bner} walk.
\newblock {\em Journal of Symbolic Computation 24\/} (1997), 465--469.

\bibitem{DalmasGaetanoWatt:97}
{\sc Dalmas, S., Ga{\"e}tano, M., and Watt, S.}
\newblock An {O}pen{M}ath 1.0 implementation.
\newblock In K{\"u}chlin \cite{ISSAC97}, pp.~241--248.

\bibitem{GloorMueller:98}
{\sc Gloor, O., and M{\"u}ller, S.}
\newblock {\sc Parcan}---a parallel computer algebra nucleus.
\newblock In preparation, 1998.

\bibitem{jbf-manual54}
{\sc Heimbigner, D.}
\newblock {\em {JAVA Bison}---Parser and Lexer Generation for Java}.
\newblock University of Colorado at Boulder, 1997.
\newblock Available at {\tt
  ftp://\linebreak[2]ftp.cs.colorado.edu/\linebreak[2]%
  pub/cs/\linebreak[2]distribs/\linebreak[2]arcadia/\linebreak[2]jb.tar}.

\bibitem{ISSAC97}
{\sc K{\"u}chlin, W.}, Ed.
\newblock {\em Proceedings of the 1997 International Symposium on Symbolic and
  Algebraic Computation ({ISSAC~'97})\/} (Aston Wailea Resort, Maui, Hawaii,
  1997), The Association for Computing Machinery, ACM.

\bibitem{ISSAC96}
{\sc Lakshman, Y.~N.}, Ed.
\newblock {\em Proc.\ Intl.\ Symposium on Symbolic and Algebraic Computation
  ({ISSAC~'96})\/} (Z\"urich, July 1996), Association for Computing Machinery.

\bibitem{ISSAC95}
{\sc Levelt, A. H.~M.}, Ed.
\newblock {\em Proc.\ Intl.\ Symposium on Symbolic and Algebraic Computation
  ({ISSAC~'95})\/} (Montreal, July 1995), Association for Computing Machinery.

\bibitem{WeberKuechlinHoss98a}
{\sc Weber, A., K{\"u}chlin, W., and Hoss, J.}
\newblock Connecting computer algebra systems via {CORBA}---a case study.
\newblock Submitted to ISSAC~'98.

\bibitem{mathbus-termstructure}
{\sc Zippel, R.}
\newblock {\em The {MathBus} Term Structure}.
\newblock Cornell University, Ithaca, NY 14853, U.\,S.\,A., 1997.
\newblock {\tt http://\linebreak[2]www2.cs.cornell.edu/%
  \linebreak[2]Simlab/papers/\linebreak[2]mathbus/mathTerm.htm}.

\end{thebibliography}




\end{document}


