[evla-sw-discuss] Implementation languages for the observing layer

[Ramon E. Creager]

There are many other choices based on SOAP (Simple Object Access Protocol):

<your favority scripting language (except glish)>/C++ via SOAP
or
<your favority scripting language (except glish)>/Java via SOAP

These combinations have all of the advantages given here for the Python/C++
via CORBA option used by ALMA, without the very heavy CORBA technology and
the need for an IDL.  SOAP (http://www.w3.org/TR/SOAP/) is an XML based
protocol.  We (the GB Software Development Division) are using SOAP as an
alternative to traditional RPC between Java and C++ apps in our prototype
observation configuration tool and it works very well.  It has several
significant advantages over traditional RPC:

  * Type and structure information in the transmitted data is
    preserved.  Scripted languages can construct objects of the
    correct type using information encoded in the SOAP message.
  * It is text based (XML); architecture/compiler issues like
    big/little endianism and data addressing simply do not exist.
    Also, because it is text based, it is relatively easy to read
    a SOAP message for debugging purposes.  (A binary data type
    does exist, for the transmission of images, object code etc.)
  * Libraries exist for all popular languages, compiled or scripted.

This last point allows you to use any combination of languages without
locking you into any particular combination.  This point alone should be
cause to carefully consider using SOAP. Implementations can be found at:
http://www.soapware.org/directory/4/implementations.  For C++, we have used
gSOAP (http://www.cs.fsu.edu/~engelen/soap.html) with success.


-----Original Message-----
From: evla-sw-discuss-admin at donar.cv.nrao.edu
[mailto:evla-sw-discuss-admin at donar.cv.nrao.edu]On Behalf Of Barry Clark
Sent: Wednesday, November 13, 2002 12:09
To: evla-sw-discuss at bclark.aoc.NRAO.EDU
Subject: [evla-sw-discuss] Implementation languages for the observing
layer


It seems to me that we should consider the scripting-language/
implementation-language pairs listed below.  (I include with minor
comments.)

glish/C++
This is the pair chosen for AIPS++, and would therefore have the
advantage of using a lot of stuff developed by the AIPS++ group.
On the minus side, glish is now supported by NRAO, and the
enthusiasm for continuing to do so is not very great.  It seems
to me a poor choice for a new system.

Python/C++ via CORBA
This is the route chosen for ALMA.  It has large advantages in that
CORBA handles a lot of the differences between how things are handled
in the two languages, and pretty flexibly lets you transmit data
from the script interpreter to the underlying code.

Python/C++ directly linked
Higher efficiency than the one above, but I suspect that one
would be driven to passing only atomic data types between the
two languages because anything more gets rather messy.  On this
grounds, I think I would recommend against this choice.

XML/C++
Rather tidy, in that an observation descriptor would suddenly
appear full-blown as a structure.  But it is less than clear to me
how to handle differences between antennas (eg to designate a
reference antenna for holography, and the like), or how to handle
subarraying.  This can probably be resolved, but it would take quite
a bit of thought to be sure.

TCL/C++
This is the choice of the GBT.  Other than that, I don't know enough
about the combination to make a sensible comment.

HomeBrew/C++
Possibly starting from the script parser currently running in the
VLBA correlator.  We would make such a thing do exactly what we want it
to do, not much more, not much less.  This would give us the future
flexibility that we could decide for new features whether to add them
to the parser or at a level above or below.  This route has the
disadvantage of a fair amount of initial work to make it go in the first
place, though probably only a few man-months.  Such an approach might
become a maintenance problem, though the ones running in the VLBA
correlator and the VLBA stations have not proved to be.  (The one
running in the the current VLA hasn't been a maintenance problem per se,
but getting Observe/JObserve to do what it would like them to do is a
bit of a problem.)  The only significant advantage this offers is that
everything else places one at double jeopardy - a significant lack of
support for either side of the language pair would put us in a major bind.

Jython/Java
This has the major advantage that the integration seems pretty tight
(one can just import Java Classes), without having to go through the
IDL mucking about necessary with Python/C++ via CORBA.  Seems very
attractive on the surface, but I haven't looked very deeply.

XML/Java
Same comments as XML/C++.  Both included here in hopes of inciting a
religous melee over the question of whether Java or C++ is more likely
to be around in the far future.

TCL/Java
I see no possible advantage over Jython/Java.

HomeBrew/Java
I find this less attractive than HomeBrew/C++, though the difference is
small.


Is there any other pair we should be considering?
_______________________________________________
evla-sw-discuss mailing list
evla-sw-discuss at listmgr.cv.nrao.edu
http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss