ASCoDT Component Specification

For the specification of components, ports and interfaces we use a simplified version of SIDL. The grammar for the simplified language can be downloaded from File:Grammer.doc. The language in our implementation is meant only for prototyping purposes. It supports only a small set of types, which are crucial for scientific applications.

SIDL - Short Introduction

A component in ASCoDT is an autonomous soft- ware entity with a state and an interface. Multiple instances of one component may exist. Hence, a component is similar to an object of a class, and we use class as synonym for component definitions. Our components can be distributed among different computers running in processes or applications, respectively, of their own. The static structure of our applications consists of interfaces and classes, i.e. components interacting due to these interfaces. Both are organised in packages mirroring the namespace concept of C++ and Java. Interfaces prescribe a signature, i.e. comprise methods, and they can extend other interfaces. A class implements interfaces and uses interfaces. Whenever a class implements an interface, the class has a provides port. The port’s type is given by the interface. Whenever a class uses another interface, the class has a uses port. The port’s type is given by the interface. This static structure in our case is written down in a simplified scientific interface definition language (simplified SIDL).

Interfaces and classes

An interface in sidl includes a set of operations. The operations correspond to void function from the c language. Two types of parameters are supported: the input parameters and input/output parameters. The first is parameter with read-only semantics and seconds allows the realisation of return semantics. We support the following atomic types and 1D- arrays from them:

• int
• double
• bool
• String

The following example shows a simple interface with the name Interface1 located in the package pa.pb. The interface offers one operation: the foo operation with one read-only integer parameter and one read/write array from doubles. The second interface offers the function bar without parameteres.

package pa{

 package pb{
   interface Interface1{
     foo(in int a, inout double[]b);
   } 
   interface Interface2{
     bar();
   }
   
   @target = java_local
   class Component1 implements-all Interface1{
   }
   @target = java_native
   class Component2 uses Interface2 as entryPoint{
   }
 }

}

Interfaces can extend already existing interfaces through the extends keyword. Components are represented in sidl as classes. To type of relations exists between components and interfaces : uses-relationship and provides-relationship. In the previous example you can see two component definitions: Component1 and Component2.

Targets

Components in ASCoDT can be written in three different languages C++,Fortran and Java. Additionally those components can run locally in the same process space as ASCoDT or remotely. To distinguish between the different cases we introduced the target keyword in our sidl dialect. The following targets are currently implemented in ASCoDT:

• java_local : for components written in java, which should run in the same process space as ASCoDT.
• cxx_local : for components written in C++, which should run in the same process space as ASCoDT
• fortran_local : tbd
• java_remotef : for components written in java, which should run remotely. Communication is done trough a file protocol.
• cxx_remotef : for components written in C++, which should run remotely. Communication is done trough a file protocol.
• fortran_remotef : tbd
• java_remotes : for components written in java, which should run remotely. Communication is done trough sockets.
• cxx_remotes : for components written in C++, which should run remotely. Communication is done trough sockets.
• fortran_remotes : tbd