Observatories and Research Facilities for EUropean Seismology
Volume 1, no 3 October 1999 Orfeus Newsletter

Fissures, Java and Corba

Philip Crotwell
Seismology Program, Department of Geological Sciences, University of South Carolina, Columbia, South Carolina 29208

Introduction - Java - Corba - Fissures


Fissures is an effort by IRIS to develop a software framework that address the common, basic functionality needed by seismologists and that will enable the rapid creation of new and interesting scientific and teaching applications. Fissures began as a realization that the inability of current software both to communicate and to handle large volumes of data was hampering the progress of seismologists. It is not uncommon, and might in fact be the norm, for a seismologist wishing to process some data to get the data in one format, read it into a conversion program, output it into another format, read it into a second analysis program do do one step, output the result, translate the results for input into a third program, and so on. If only these specialized applications could communicate directly, much extra effort could be avoided. Secondly, whenever new seismology software packages are developed, they usually start from the ground up, and recreate the same functionality that has been done many times before. If only there was a standard library of seismology objects that took care of the common, boring, low level functionality, then seismologists could concentrate on doing the fun part, which is doing science. To address these issues the FISSURES initiative was begun by IRIS in 1997. FISSURES is based on two complementary technologies, Java and Corba. Java for its object oriented nature and cross-platform abilities, and Corba for its strong, industry standard distributed computing mechanism.


There is a complementary article focusing on Java contained within this edition of the newsletter, and so we leave the details to it. Suffice it to say that Java has received a huge amount of attention in the computer industry lately, and for good reason. It is a clean, well designed object oriented language that has the ability to run on many different platforms without recompiling. It also has a large framework of classes that do many useful, common tasks. These range from advanced GUI elements to database access and from networking to complex data structures. In short, Java makes it easy to do useful things that are very complicated in other languages.


While Java has received a huge amount of press and hype over the past few years, Corba has only recently been widely noticed in spite of its relative maturity. Thus, most programmers are unfamiliar with what Corba is and what it can do for them. Corba, the Common Object Request Broker Architecture, is a system for doing language and platform neutral distributed computing. It allows applications to access the services of other systems that may be running on different computers, with different CPU types and even different byte ordering, and even written in different languages. Corba allows the access of remote services while giving the appearance that they are local.

At its core, Corba is the combination of first an interface definition language, IDL, along with mappings into various programming languages, and second, an over the wire protocol, IIOP, with Orbs, Object Request Brokers, that listen and translate to and from the protocol.

The object request broker, or Orb, provides for the common needs of distributed systems such as creating the connection from the client to a remote service and exposing a service to the outside world once it is ready to receive requests. The orb is the manager for all Corba interaction within an application. It communicates with other orbs using IIOP, the Internet Inter-Orb Protocol. IIOP defines a mapping from data structures to a byte sequence that can be sent across a communication channel. By using this type of protocol, Corba allows the programmer to operate at a higher level that the more traditional socket level. The programmer need only define what his data objects look like, and the orb handles all of the marshaling and demarshaling to and from IIOP. Lastly, because IIOP is an inter-orb protocol, the only reason anyone would directly interact with it is if they were writing a new orb implementation. Otherwise, it is sufficient to know that IIOP exists and that the orb takes care of the rest.

The interface definition language, or IDL, along with an IDL compiler that maps IDL into the target language, are the real pieces that programmers regularly interact with. IDL allows you to explicitly define the interface to a service independent of its implementation. This strong separation between interface and implementation is a good design principle in general, and by forcing you to do this explicitly, Corba can actually help you to make better design decision early in a project, when they are most helpful. Examples of interfaces in the real world are everywhere. The most common example given is usually a bank. When you go to your bank or any bank, you expect a common interface. In other words you expect to be able to do certain things, like open an account, check your balance, make a deposit, and make a withdrawal. It is really irrelevant to you how the bank accomplishes these things internally, just so long as you get a valid result back. They could have an envelope in the back with your money in it, or they could keep track of how much you have in a sophisticated accounting system, you don't care so long as you can get to your money. This same technique is a good way to design a complex software system. Break it into subsystems and be very explicit about the interfaces between them.

There are two main pieces to actual IDL. The first is naturally interfaces. An interface is a collection of methods (functions) along with their input types and output types. An implementation of this interface must provide each of these functions. This interface definition defines the extent of a subsystem. The second main thing that is possible within IDL is the definition of data structures. These are similar to structs in C and provide for the creation of more complex data types and can be used within their associated interfaces. The IDL for a corba version of "hello world" might look like this.

module example {
	struct Name {
		string lastname;

hello_world {
		string say_hello(in Name my_name);

In this example, say_hello is a method or function within the hello_world interface. It takes a Name structure as an argument and returns a string. It is worth repeating that IDL only defines interfaces, the "what". The "how" of the implementation does not appear.

Once IDL has been created, you must run an IDL compiler on it to produce usable code within the language of you choice. If you want to code in Java, you would use a Java IDL compiler, and similarly for C, C++, Smalltalk, and COBOL. When you run the compiler, the output is source code in the chosen language. So, for instance, in Java each struct is mapped to a class and each interface is mapped to a Java interface. In addition you will get a couple of helper classes and an implementation base. This "ImplBase" class provides the functionality that Corba needs to make use of the interface, it is also knows as a skeleton because it provides the bare bones framework and it is up to you to flesh it out. Lastly, you also get what is known as a stub. This is the functionality that Corba needs on the client side to forward requests and deal with the response. It acts as a local proxy for the remote service.

There are several good sources of information on Corba. The natural first is the OMG, which is the organization that develops and standardizes the specifications for Corba. While there is a lot of information there, the site is a bit confusing and it can be hard to find what you are looking for. Another interesting site is the Free Corba page, which tracks implementations of Corba that are freely available. The TAO orb is a free C++ orb with many features. Also of interest is Orbacus, a Java and C++ orb that is commercial, but is free for non-commercial use. Lastly, there is a built in orb within Java1.2, which can be found at Javasoft.


How will Fissures make use of these two technologies. Well, first we are designing interfaces in Corba to several standard services that seismologists use regularly, such as a data repository, travel time calculation service, and filtering service, and building prototypes of each. Also, we are creating a large business model of common seismology objects, along with their basic, commonly needed functionality. For instance, we have defined classes for seismograms, picks, events, origins and predicted arrivals. We have also defined two other objects, DataSet and ChannelGroup that allow for grouping of data. The ChannelGroup holds up to three seismograms and defines them as representing the three components of motion. DataSets in turn hold ChannelGroups and other DataSets, and allow for organization much like folders or directories do on a hard disk. In addition, we are developing a set of display components that will allow new, special purpose GUIs to be quickly developed. For example, a seismogram display widget knows how to display a seismogram. Several seismogram displays can be combined to form an overlay plot or a record section. A particle motion display widget would display the particle motion from two seismograms.

Several things that we think are needed, but not currently widely used will also be included. Such as an auditing system so that the entire processing history of a piece of data can be examined. Units are widely and explicitly used. Thus, if an amplitude is measured in units of meters per second, then that fact will be kept with the measurement. If you later average it with one in centimeters per second, the conversion will automatically happen. And if it is in centimeters, then it will warn you that the units are not compatible. If you don't think units are important, just ask the Mars Climate Orbiter team.

The first use of the fissures framework will be with SCEPP, the South Carolina Earth Physics Project, which will use fissures for both the realtime data recovery as well as for the development of educational software applications. This will provide a good first test as well as becoming a source of additional fissures friendly software.

A great deal of design work has been done, with UML models that you can view if you are interested. Also, slides from my IUGG talk are available as well. We are slowly working on implementing these designs and hope to have a release at the pre-alpha level at the beginning of 2000. The system should progress and change frequently over the following year. A beta release will likely be done late in 2000 or early in 2001. The first general release should be relatively soon after that. Any comments on the design are welcome.

page 25
Copyright © 1999. Orfeus. All rights reserved.