Author: Frank Schneider
Date: 15:16:02 02/20/98
Hello!
With this posting I'd like to start a discussion about the
(re-) use of IDL-interfaces for chessprograming.
Please excuse me if my english is incorrect - I'm not a native
speaker. To get the (more comprehensive) german version send a
mail to hobblefrank@t-online.de.
Throughout this document I will use the following acronyms
CORBA Common Object Request Broker Architecture
See [1]. In this context:
'A software architecture offering interoperability'.
DCOM Distributed COM. Microsofts technology for distributed
objects.
ORB Object Request Broker.
A 'software-bus' offering mechanisms for calling methods
of (possibly remote) objects. Could be implemented as a dll.
(See [2]).
IDL Interface Definition Language (used in CORBA)
A .idl-file is similar to a .hpp-file, it describes
interfaces of objects in a language-independend way.
GUI Graphical User Interface
Contents
--------
1. Idea
2. Background
2.1 Chessprogram-development
2.2 IDL and CORBA
3. possible next steps
4. Bibliography
1. Idea
-------
The idea is to develop a set of chess-specific interfaces in IDL,
describing the boundaries between components (GUI, engine, book,...)
of chessprograms. These interfaces could be discussed and developed
by members of the ccc or rgcc. They could ease development and
usage of chessprograms in various ways:
- Interoperability between components of different chessprograms.
Basis for combining different components. Combining one GUI with
different engines and openingbooks (or other components) allows
users to stick to their favourite GUI.
- Component reuse. Possibility to reuse whole components when writing
a chessprogram. Interoperability and component reuse could be based
on CORBA or other middleware. Prevents re-invention of the wheel
and helps standardization of functions and fileformats (.pgn, ...).
- Design reuse. The interfaces represent condensed chess-programming-
knowledge and help people writing new programs or restructuring
old ones.
- Code reuse. Reuse of (C++- or Java-) classes without middleware.
Once interfaces are established, commercial and free software could
support them, enabling interoperability between them. Freeware
developers could stick to their favourite component (engine,
openingbook, endgametablebase, database, GUI) and components that
were developed independendly could interoperate via a CORBA ORB.
Possible uses:
a) A XBoard-like (client) offers a GUI for services by different
servers.
b) A 'Tournament director'-program (client or server) coordinates a
tournament of engine-servers without human interference.
The engines could be on one machine, on a local network or even
anywhere on the internet.
c) Engines could register with a test-server that tests various
testpositions.
d) Small java-applets offering a GUI could use components anywhere
on the web. Notice that Netscape Navigator offers a build-in
ORB and that the JDK 1.2 will contain an ORB.
other possibilities:
- specialized GUIs for blind children, blind people, ...
- special engines or GUIs like CSTal
- a 7-man-endgame-database offerd by IBM over the www ;-) for
public usage.
Of course these things will not be realized quickly. But the
development of interfaces is a first step, and it is a step
that is relatively easy for experienced chess-programers.
Since IDL-interfaces are platform- and languageindependend, they
could provide a common basis for future developments in computerchess.
For the spare-time-programer they offer a chance to concentrate
on the most interesting components, reduce development-effort
and increase quality by reuse of tested components.
CORBA-IDL is a suitable language, because it is a stable standard
(ISO DIS 14750) with increasing importance ("In our opinion, IDL
is comparable in significance to Backus-Naur Form" ... "We suggest
that a working knowledge of IDL is an essential skill for every
practicing
software architect and software developer." [3]).
IDL very easy to learn for people who know C++. I hope that
experienced users of CORBA and IDL are interested and offer guidance.
2. Background
-------------
2.1 Chessprogram-development
There are lots of commercial and free chessprograms around. Most
of them were developed independendly, that means everyone wrote
their own GUI, openingbook and file-services. As a consequence
there are lots of bad GUIs, incompatible openingbook-formats and
fileformats. Even some professional programs still use DOS based
GUIs and aren't easy to use. This is bad for users, but even worse
for the programer who had to write things he is not interested
in (and sometimes he is not good at it, too).
2.2 IDL and CORBA
I had the idea to exploit CORBA for chessprograming, because
on the one hand I'm currently writing my thesis about a
CORBA-related topic and I'm impressed by the possibilities for
reuse and interoperability CORBA offers. On the other hand I
reinvented some wheels while writing my program Gromit and I
think there should be a better way.
I can not give an introduction into CORBA here, see [1] and [3]
instead. If you want to experiment with CORBA try the OmniBroker [2].
The alternative middleware to CORBA is DCOM by Microsoft. Since the
definition of interfaces is relatively independend of the
middleware, and there will be bridges between both technologies,
I will concentrate on CORBA.
CORBA offers interoperability between programs by means of remote
methodinvokation. It could be seen as an object-oriented remote
procedure call (RPC).
Interfaces of objects are described in a platform- and language-
independend Interface Definition Language (IDL). An IDL-compiler
takes the interfacefile and produces language-specific files
the programer uses to implement the methods of the IDL-interface
(supported languages contain C, C++, Java, Ada95, Smalltalk and Cobol).
On the clientside the IDL-compiler generates a (C++-) class that
can can be used like a normal class. However, whenever a method
is invoked, its arguments are transparently transmitted via an
ORB to a serverobject.
On the serverside a skeleton-class is generated. The programmer
subclasses this class and provides it with the implementations of
the methods. Client- and serverprogram can be located on different
machines and programed in different languages; all these details are
hidden by the CORBA-implementation. Differnt ORBs can interoperate
via IIOP (Internet Inter ORB Protocol).
Remote methodinvokation will not be quick enough to connect
search and evaluation of a chessprogram, but it is quick enough
to connect for example GUI and engine. (A remote methodinvokation takes
about 10-70 ms for most ORBs).
The CORBA-standard also defines IDL-interfaces of some general services
(CORBAservices: NamingService, TraderService, ...) and specialized
services (CORBAdomains: CORBAfinancials, CORBAmed, CORBAchess?, ...)
and companies can implement these interfaces and sell their
implementations.
("CORBAdomains standardize a level of interoperability
needs that are close to the needs of applications. The CORBAdomains
will undoubtedly be of high value to developers and to end users
for the delivery of component software." [3]).
Advantages of CORBA:
- platform-independence
- language-independence
- company-independence (not true for DCOM)
- commercial and free products are available for many platforms,
including Windows, most Unix-systems and Linux.
- ..., see [1]
Drawbacks:
- I expect CORBA to be new for most chessprogramers.
- Installation of a CORBA ORB could be difficult for users today
(but will be easier in the future).
- If the ORB is statically linked against a program it leaves a
'footprint' of 50KB-1MB.
(will not be a problem for Java JDK 1.2 programs).
Example for using a CORBA client and server on one machine:
1. Start a nameservice and obtain its 'adress'
(IOR:Interoperable Object Reference).
2. Start a (engine-)server. It could get the IOR as a parameter, from
file or from a webpage. The server creates an engine-object and
tells the nameservice its name.
3. Start a client. The client asks the nameserver for an
objectreference of the engine and is then ready to use this object.
This is a small example, there could be more clients and server, and
they could be located on a network, rather than on one machine.
3. possible next steps
----------------------
At first, I'd like to start a discussion about this idea and see
what happens. If enough people are interested, people could
collect requirements.
Basis for the development of interfaces should be a kind of
coarse-grained 'standard chessprogram architecture', defining
what interfaces are needed.
Based on a minimal set of interfaces, programs could be adopted
to support them and experiments could lead to refinement
of the interfaces.
Even if it takes a year to define a minimal set of interfaces -
why not? They could be useful for many years.
Looking forward to interesting replys,
Frank Schneider
4. Bibliography
---------------
[1] http://www.omg.org
Homepage of the Object Management Group. Source of all
official CORBA-material, lots of links and very good
tutorials on CORBA and IDL.
[2] http://ooc.com
Homepage of Object Oriented Concepts, provider of OmniBroker
(free for non-commercial use). OmniBroker is available
for Windows, AIX, HP-Unix, Sun and Linux and supports C++ and Java.
It contains a good manual and some examples.
[3] Thomas J. Mowbray and William A. Ruh,
Inside CORBA: distributed object standards and applications,
Addison Wesley 1997,
ISBN 0-201-89540-4
Very good introduction and overview of CORBA.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.