Rexx Language Binding für CORBA 3.0.

Seminar Paper
 
 
 
 
 
 

Björn Muschall
Submitted to 10.12.2000

Table of contents

The american standardisation organization Object Management Group (OMG) develops object-oriented standards for years. The Common Object Request Architecture (CORBA) permits to distributed objects to communicate over system boundaries away. Central constituent is the definition of the interfaces of distributed objects in a programming languages independent and descriptive specification language (IDL). A following implementation of the architecture is realized by using a concrete programming language. The OMG worked out so called language bindings for a set of programming languages(ADA, C, C++, COBOL, JAVA and SMALLTALK), that defines the conversion of the IDL-definitions to those programming languages and thus the way to implement those objects. For a number of further programming languages still no official Language binding exist at present time.

Target of this work is it to prepare for the language REXX the design of a language binding to enable the implementation of CORBA objects in REXX. A first step is to §§work/ figure out the architecture of CORBA and further constituents, which are to be regarded in view to the language binding. A further step is to look into some existing solutions, those inofficial language bindings for a set of similiar scriptin languages. The concrete design of such a language binding for REXX is worked out last.

The architecture of CORBA is worked out. CORBA is an infrastructure for the implementation of distributed systems. This infrastructure is regarded in the first section of the work.

Die Architektur von CORBA wird erarbeitet. CORBA selber ist eine Infrastruktur zur Realisierung verteilter Systeme. Wie diese Infrastruktur aussieht, wird im ersten Kapitel der Arbeit betrachtet.

Distributed systems communicate by means of exchange of messages. For this interaction an interface is necessary for transmitting and receiving such messages. For it a suitable data communication and protokols are necessary. By the definition of the interfaces in IDL and the translation into a programming language, which is based on an existing language mapping,§§ this mechanism remains unregarded by the developer of distributed objects, it remains transparent. This mechanism is investigated later (the Request, the protocols IIOP, GIOP)

The meta data of the Interface Repositories (IR), the type codes and their meaning for the transmission of messages is explained. The interoperable object reference (IOR) is part of the addressing concept. Further down the unofficial language mappings for a set of script languages are examined. More or less the features of a strongly typed language are missing to all script languages as with IDL. To carry out method calls type information are required. This paragraph prepares the view of the unofficial Language binding for a set of script languages.

The Interface definition Language is regarded.

The official Language binding exist for a set of programming languages. An introduction to the C, - and C++ language bindings follows.

A set of unofficial language mappings is regarded. The languages regarded here are just as REXX script languages likewise. Contrary to the above programming languages, they indicate some special features. The approaches can be divided into dynamic and static ones

As some of the presented approaches base on dynamicly generating requests, and these aktion represent an equal running pattern, a typical dynamic method call is demonstrated here.

The possibilities to arrange a language binding for REXX will be introduced.

CORBA is an infrastructure for the implementation of distributed systems. The constituents of such a system can be distributed over process boundaries, even over computer boundaries away. From view of a developer, who avails himself of a programming language, in order to implement these constituents, the system cannot be implemented with the exclusive means of its programming language, like functions, modules, and call relations. Means and ways over programming language boundaries away are needed. Such possibilities were often already used:

Pipes and files for the interprocess communication within a computer

Sockets and RPC for communication over computer boundaries away

An aspect from CORBA is that the constituents of its architecture are represented in uniform view in the form of objects. A fundamental characteristic of these objects is that they are described by defining their interfaces, which represents an abstraction of their actual implementation. The implementation of these objects can then be done in the programming language of choice. The interface description is specified in a uniform form, by means of a descriptive language, the interface definition language (IDL). This desctiption can be turned into the respective programming language by the language binding, a language binding maps the definition onto a definition in a programming language

A further aspect is that this mapping does not occur on direct way. The concepts that are contained in IDL (modelling concepts such as objects and inheritance relations, the type concept of a strictly typed language, name space structuring etc....)must have an corresoponding pondon in another programming language, or at least must be realized with other means. Internally a call of of a distant method is realized by means of dispatching messages, from which it is so far abstracted, in order to give the developer a transparent view within his programming language. Transparency consists of calling methods of distant objects in such a way as if they would be of local objects.
 
 
 

2.1 the constituents of the core (CORBA core)

Among the core of CORBA the object model, the objects Request broker (ORB), the interfaces to the ORB, and the IDL is ranked. The interfaces continue to divide into the ORB INTERFACE, the static and dynamic interfaces, and the object adapters

Object model:
In the object model, apart from the characteristics of objects, that are operations and attributes, also interfaces and types are declared §§fixed. CORBA differentiates between basically two differently groups of types, which are the simple and the contstructed ones. The constructed ones are such, which themselves consist of simple types. To the data types also the object references belong and in addition exception and data types like the "any" or recently the "value type ", which any other types can take up. The object references are divided into domain-internal and the spreading, external, interoperable object reference (IOR), which are to serve the unique identification §§spreading the Orb, and thus world-wide.

IDL
INTERFACE definition LANGUAGE (short IDL), contains:

The syntactic description of the IDL
The specification of the elementary interfaces written in IDL
The LANGUAGE Mappings

 
Object Request broker (ORB) and the ORB-domain
The whole of all object implementations and their instances one calls ORB domain. The Orb represents the backbone of these objects and a collection of regulations of the interaction between the objects. It is neither prescribed, nor probably that the Orb consists only of a component, or that it concerns a concrete object, on the contrary it is a logical structure, which is distributed over many objects of a domain. It is an abstract Konstrukt. However in most implementations/ ORB-products thres ist a ORB-object, in form of a pseudo object.
 

 
Interface
Directly arranged to the Orb and therefore belonging to the core of CORBA, one can find the Interfaces. These can be divided into static and dynamic ones and the ORB interfaces. Access to remote objects is from view of the calling object transparent, but one needs local deputies, whose methods have the same signature as the distant methods, so-called Proxies of objects. To each implementation of a distant object there must be a corresponding implementation of a ProxyObjektes.
In CORBA there are the stub and the skeleton, which represent the static version of the proxy objects. The dynamic version is available with the DynamicInvocationInterface (DII) on the client side and for the server side with the DynamicSkeletonInterface (DSI). The DII makes the complete functionality available, in order to produce and execute remote calls dynamically. By the DSI applications can process invocations dynamically.

 
InterfaceRepository (IR)
The IR is attached at the Orb and serves the entry of interface information, which at run-time can be accessed far away. Therefore they are available in machine-readable form, directly derived from the IDL definition and thus in standardized form. The interface repository is again build up with CORBA-objects. It contains all by means of IDL specified information, offers access on definitions by means of pseudo interfaces. In this interface repository operation signatures and inheritance hierarchies of the objects are resolved transparently.

 
Object adapter
The Object adapter offers an interface for the core of the ORB, and thus to central services like a producing and an interpreting of object references, an activating and a deactivating of distant objects. Distant objects are usually implemented in the form of Servants. A server can contain several Servants. An object adapter serves the registration of Servants and passing on calls to these. A Servant is a real deputy of an object. The object is abstract, a Servant is the implementation of an object in a programming language. A Sevant must be well-known, must have an identity. This provides the objects adapters for it.

 
CommonObjectServices (COS)
The COS are not any more constituents of the core, but built upon the core, additional functionality. They are collected and defined unified services, which mean a standardization and a alleviataion for the development of distributed objects, since they do not have constantly again to be invented. Each service has at minimum a  standardized interface, can also have several ones..
One of the central services, is even in view to the dynamic method call of interestd. The NamingService serves as central directory for object references and administers these. It provides a resolving of object references for other objects transparently.

 
NamingService
Function of the NamingService is it to enter as many as desired CORBA objects under freely eligible names. Similarly as in a file system it arranges the references of the objects hierarcly in contexts. Contexts are comparable thereby with directories and the, in those directories arranged, addresses with files. Thus it permits the determination of all other necessary object references and represents thereby the first inital object reference, which must be well-known to an object. Such Naming service can contain contexts of different domains.

 

illustration1: The architecture of the ORB

2.2 the mode of operation of data exchange:
 
 

In figure 1 architecture and mode of operation are shown by CORBA. On  it is to be seen that the call of methods results into dispatching Requests.

An aspect of the design of CORBA is to let to the programmer the call of a remote operation appear exactly the same as if he would call the method of a local object. This is carried out by transparently producing messages. These messages are called Request. Such Request will be produced, and can be sent over system, - and process boundaries away. For this interaction an interface is necessary for transmitting and receiving such messages. A suitable form of the data communication and protocols are necessary.

In the case of CORBA requests can be formed by means of the protocol IIOP. From the specifications of the OMG it follows that communication within a domain can be relativ freely implemented, those between the domains however is strictly defined. Interactions beyond domain boundaries are described by the IIOP protocol. Within an ORB however any protocol can be implemented, as long as it is ensured that this can be translated outward over a so-called bridge into the IIOP protocol.

This means that the developer arrives sometime at the point, at which he must transfer remote method calls into the form of IIOP requests, or find a possibility of reusing this work, which already was implemented for other languages. He must related to this supply a series of marshalling routines himself, or by integration of Stubs, which already contain integrated this logic  firmly, and are implemented in a language such as C++. A later presented approach uses the possibilities of a script language, in C or C++ implemented Stubs to integrate.

By the marshalling one understands the conversion of a method call to a message. Such a message needs a transfer form, which is independent of different computer architectures. Therefore a transformation of the data into a network-suited form is employed/ used, in the case of CORBA it is the common data representation (CDR). The structuring of the message, their syntax, is given by the protocol.
 
 
 

Type codes
The CORBA meta data language is IDL, the CORBA meta data repository is the IR. CORBA uses type codes, in order to associate each IDL data type with a global unique identifier. Thus data become self-describing on the basis of their unique identifier. The type codes are to be received over certain methods, and can also dynamicly be received from the IR.
As previously mentioned IDL is a strict-typed language. On the basis of these type codes type examination on side of the Orb can be enabled only. Besides, over these codes it is caused that different Orbs uses unique types.
As it is further down shown a side effect of these type codes is that one needs its information for the dynamic generation of requests. Since a request corresponds to a method call, as with the call of methods likewise, the type information of the arguments and the return value are of interest.
 
 
 

The InterNet Interorb Protokol (IIOP)

The protocols GIOP and IIOP run under the fascade of the CORBA architecture. The Interfaces specifyable in IDL form the APIS from programmers view to these protocols. For the direct acces to this mechanism there are no interfaces, these protocols are applied automatically by the Orb and are thereby transparent for the developer.

The interface definition language is a language for the uniform, implementation-independent description of the exported attributes and methods of remote objects. Their central constituent are interfaces, which can be grouped to modules, which on their part represent a concept of structuring the name space.
Basic constructs that build up the IDL are operations, interfaces and modules. In addition IDL is descriptive, it is missing operational items, algorithmic aspects, and contrary to some script languages IDL is strictly-typed.
 

Omg standardizes the language bindings, in order to map this constructs into other languages and solves thereby also a set of mapping problems, since different structuring concepts are subject to each language.
Some languages are object-oriented. Under the object-oriented languages there are different class concepts.(for example a JAVA interface corresponds in C++ to an abstract class)
IDL specifications resemble syntacticly the class declarations in C++. Correspondence to a C++ class is thereby an IDL interface. Within this interface the complete signatures are indicated.
IDL offers an inheritance mechanism too. Interfaces can inherit from other interfaces, also multiple ways Overloading or overwriting of inherited methods is however not possible. This also for reasons of a compatibility to languages, that does not support object orientation (as for example C)
 

Interfaces are class definitions without implementation section, thus without attached method definitions. Operations are methods with return value, parameters and the ability to raise exceptions and to provide a description of its context.
Data types, whereby the type any, which can take up every other type, is particularly interesting. It enables polimorphic call situations, with parameters, which are not certain at compilation time.

IDL contains a set of simple data types:

• short, long, char, octet and boolean
• float, doubles

Furthermore a set of constructed types:

• struct, union, enum, any, sequence, stringer

Types take a privileged position, how the exception and the object references, from which there are two different. A further feature, which distinguishes IDL, is that it supports the exception handling mechanism, whichs maps to all target languages by using the adequate language binding.

4. The official Language binding
 

    4.1 C Language Binding
 

Because of lacking object orientated characteristics of the language C a convention was encountered, which allow to differentiate operations on remote objects:
Functions that are called on the Stub receive in addition the reference of the target object, as well as an EnvironmentVariable. Different class definitions can be distuingished by the way, that the operations belonging to a class are been identified by a name, which forms a combined primary key. The name of the interface  (the class) and the opations name are assembled in the form:  Interface1_operation1 ()

see an example:
    interface Bsp1{
            int op1(in int etwas)}

becomes
    extern Corba_int   Bsp_op1(Bsp1 zielref, Corba_int etwas, Corba_Environment *ev);
 

The referenz of the target object is required, because derefering by Bsp.op1() as usual in C++ , does not work.

Die Zielreferenz wird dabei benötigt, da die Form einer Dereferenzierung der Form Bsp.op1() wie in C++ üblich, nicht zur Verfügung steht.

By the mapping, the responsibility for allocating and deallocation memory is given to the clients and servers. According to the parameter type (in, inout, out), memory ist allocated and deallocated on different sides, on client or on server side, which result in different adress spaces  Therefore CORBA supports, to use CORBA specific object references, that cannot be automatically deleted in the run-time environment of a certain programming language

As IDL types fix a certain realm of values, there must be an adequate C++ type that have the same realm of values, on which the IDL type can map onto. Simple types in C++ have different memory layouts on different platforms. Unlike in Java where the internal representation of the data types is standardized plattform independently, by implementing the C and C + + compiler, the internal representations of the data types have adapted to the possibilities of the different platform. The one or other architecture has another word length, a byte ordering etc. An int is 32bit large on a PC however on a Workstation it isnt. Therefore an indirect Mapping was selected on types with the Suffix "CORBA_" :

    idl    : long   C   : CORBA _long
    idl    : int   C:    CORBA_int
   ...

Inheritance of interfaces can better be mapped onto object oriented languages. An interface in Idl maps directly onto a class in C++. The functions that are inherited by a derived class, the class contains implicitly. In C, there are no classes. An interface is mapped on a set of  functions, that begin with the classes name, for example : Interface1_op1.
An inherited function are explicitly listed therefore. Inherits an interface2 this method op1 and only defines op2 newly, it will be automatically generated:

    externally CORBA_int Interface2_op1 () {}
    externally CORBA_int interface2_op2 () {}

The  method op1 therefore again is explicitly itemized/ listed.

For the Exeptionhandling there is  a struct that the Exeption maps onto, as well as a struct CORBA_Environment, that can contain either no or any exception and represents the third parameter of each operation.

An interface corresponds to an abstract C++ class with some public definitions. This class represents a basic class in C++, which however cannot be derived selfly to generate a different basic class. It is only for the purpose to implement. If someone needs a different basic class, he must derive an IDL interface from another, from which the IDL compiler will generate the basic class in C++. This has to be done because of the CORBA specific polymorphism mechanism by narrow().

A pointer on an object of an C++ class must be either declared as _var or as _ptr. This is necessary  for the sake of the allocation of memory.

The interface of the Naming service delivers always a reference of the type object in order not to be restricted to a single type. As C++ is a strictly typed language, a reference must be limited to the actual type by use of the method narrow().

An exception is mapped onto a C++ class, which is declared in the respective modulxx.h file. There are basis exception classes from which the user exceptions and the system exceptions and therefrom again the exception defined by the programer can be derived. Therefore the modulxx exception are defined in CORBA-Modul and  declared in the modulxx.h.

Valuetype are new, they  unite it interface behavior and behavior of data types. A simple type is mapped onto a type in C++, and has solely a state. An interface is solely an interface, corresponds to a class in which methods are declared, but not implemented, such as an abstact class in C++(no data types in form of attributes, because this attributes ar translated into an set of   set,- and get- methods). The valuetype should unite both.

The inofficial language bindings introduced here have been constructed for a set of different script languages. Thereby the developers had less the intention to realize a complete language binding with all aspects. The introduced bindings have the goal, to combine the advantages of a selected script language with those of the use of CORBA.

Script languages as TCL, PERL or just REXX offer a set of advantages in comparison with programmier languages as C JAVA, C++

• They are to be learned substantially more simply and are to be handled more flexibly.
• Many times they are employed for reaching littler program tasks, like the generation of a prototype or the assembling of a primitive test environment faster. One doesn't have to declare first a set of variable, and to integrate a lot of low-level functions. Moreover the integration of functions and programs with their environment is better guaranteed.
• Modifications at a script can immediatly be tried out. Time-consuming compiling and linking processes can be avoided. This result in, because script languages are interpreted. For this reason they mostly offer also a shell in which one can work interactive, what cannot be solved with a program language like C + + approximately so comfortable.

 
The employment of a script language in connection with CORBA should ease following:
 

• Because distributed systems are right complex, it is more a standard situation that several remote objects, or components (Corba objects are per definition components) are simultaneously  modified.
• A script language eases this with its dynamic aspects, and a much shorter turnaround can be reached. Just in regard on such CORBA objects, the corba components how they were specified  in the recent component specification by CORBA3, there are efforts with the corba scripting for  the configuring of corba components by using scripting languages

The integration approaches introduced here orient itself to the possibilities how invocations of remote object methods can be realized. How above already mentioned, invocations can be executed on the one hand in static, on the other hand on dynamic form. The static approach suggest a firm linking of the interface information of distributed objects in proxy objects, the information ist fixed by compilation. Based on the IDL for each class of remote objects an corresponding stub and a corresponding skeleton is generated by  a IDL compiler A stub contains the methods signatures corresponding to the IDL interface. Integrated firmly in the stub, there are some marshalling routines that produce transparently a request. This causes that the type informations of the arguments are contained implicitly within the request. One time the IDL  definition changes, -for example the amount and arrangement of the arguments of a remote method-  stub and skeleton must be compiled once again. This approach ist the less flexible, but more performant.
 

The more flexible approach, uses the dynamic invocation. By use of some standard methods the interface information of a remote object are questioned and a request build up at run-time. The operation name in form of a strings and the return value as well as a cunning of arguments with its corresponding types based on the information of the IR are needet to put together for a request. Therefore additionaly type informations are necessarily that can be also reviewed by the orb at run-time, which just costs a little performance. Modifications on an interface cause solely the renewed transmitting of the interfaces information.
In contrast to the static stub and skeleton, this proceeding is however not specific for a class of objects.
 
 
 

In addition to the language mapping, an  infrastructure is required, that manages the handling of object reference, the connection management, and the marshalling in GIOP messages.The way choosed here to realize language binding leads leads to the dynamic methods invocation, how it was described above. Based on the IDL definition of the interface, not a stub is produced, in which the type informations of the arguments are integrated firmly, but  the compiler generates a machine readable form of an IR-entry. This is loaded then into the IR, to facilitate dynamically inquiry.

The author of Mico criticizes himself, that a GIOP request contains information on the target object, the method name, and the parameters, but no type informations regarding the arguments are transmitted at all. These are however necessary so that transmitter and receiver know, how the detailed binary data are to be interpreted. .
Even the IOR, that contain the adress information for different networks, containes no type formation, as well as it is partially opaque.
The only introspective CORBA supports, is that by use of the defined method CORBA::type () type codes can be received out of the IR, and so that the type checking  is possible.

Until TCL 8.0, the uniform data representation was the string, with TCL8.0 an  type system was added backward compatible, in which there remain two different representations side by side, the internal and a stringified one. In order to add a new type, there must be made available a pair of two-way conversion function. Strings remain common denominator, remain common data representation. "Whenever a  value is requested to have a certain type  the old type updates the string represantation and the integer type for example scans the string.."

The IDL types are translated according to the COMBAT mapping. Two possibilities are imaginable: a slow one that uses COMBAT, therefore the translation on TCL types, and therewith the use of the types int, boolean, double, string, and the list as complex type, or as alternative to form the mapping opaque with access functions for each different type apiece.

In Combat for each object reference a TCL procedure -named handle- is generated apiece, that contains type information and the object reference. This handle interprets the first argument as an operation name, and the remaining as a parameter for this operation.
Such a handle marshalles the parameters into a GIOP message and let it be transported over the ORBt. For each handle there must exist an entry in the IR, so that the marshalling generally can be carried out. The invocation of the method get-interface () on a remote object returns a pointer on an entry in a remote IR, an so-called IR record.

The proceeding in Combat in the detail looks as follows:
The client side ist generated, by writing the IDL definitions in a central file. A compiler generates with the informations of the file another file in form xxx.tcl, that can be included in a script to form the client. After sourcing the script, a certein variable -ir-xxx contains the informatione, which must be entered into the IR  The entering into the IR happens within the script on client side, just before any commands come is carried out.

A handle must be generated and is required in order to carry out operations in the form:
$handle operationX <parameter>        //operation is carried out
$handle attributX                               //operation "$handle read attributX"
$handle atrributX value                    //operation "$handle set attributX value"

Such a handle, is a TCL command that corresponds to a server object. Operations on that handle cause execution on the Server. Therefore that handle is a proxy objekt. By calling the method CORBA::string-to-objekt(), one receives a handle , which can be stored in a variable.
As COMBAT pulls its information regarding the operations out of an IR, for each handle there must be at minimum an entry in the InterfaceRepository. (an Ir-entry corresponds to an interface, to a handle also)

This approach has been implemented in C++ and can be installed on every ORB, that comes shipped with an language binding for C++.  It forms therefore a glue package, a not purely in TCL implemented solution.

5.2. Rapid CORBA server development in TCL

 

This Implementierung comes from a proposal submitted to the usenix conference called "rapid CORBA server Development in TCL" [] and describes more how within TCL a remote object can be accessed, than how to implement a complete form of a language binding.
Future applications will not place things like strict typing system and inheritance as a primary demand, but rather the possibility, information and applications that are implemented in most deceased languages to integrate together.
The idea of the article is, the "core as scripting language idea", therefore the kernel of an application, that combines a quantity of existing applications, is implemented in a script language. Some of the components of such a application, that are realized in a variety of languages are located locally and benefit from the integrative characteristics of TCL, the remote ones benefint in addition of CORBAS possibilities of distribution.
 

The linking part between TCL and an ORB is built by utilization of compiled stubs and skeletons, that are implemented in C++. One considers that this approach in contrast to the already introduced  is a static one, which requieres renewed compilation of the corresponding stubs and skeletons with each modification of the IDL definitions.

The design determined further, that not only the client could be written in TCL, but the server, which contains the remote procedures and therewith the head share of the application logic, also. For that such a server must contain a TCL interpreter, in which the Idl method invocations are forwarded to TCL commands, which have the same signatures.
In the client, in which the invocation of the remote method is been released, these commands should appear as usual commands, that are typed in the shell and executed in the TCL Interpreter. Therefore a Shell had to be expanded in this way, that it is guaranteed, that the previous functions of the shell are executed unchanged in the local TCL kernel while the new defined, remote commands are transparently diverted and executed in a remote TCL kernel/ interpreter. (In this context one can separate conceptual the shell and the kernel. In the client-shell, the commands are released, in the kernel of the server side the commands are implemented.)

The central question at the beginning is how one can map CORBA objects on type-less TCL strings. A possibility is, to regard each data type in TCL as a pair of a value associated with an identifier of a data type, therefore to carry type formation with, and to base the marshalling onto this information.
Another possibility is to use stubs and skeletons as linking part, which are generated by an IDL compiler for another programming language, for example a C++ stub and skeleton. These linking parts contain the logic firmly compiled to translate the message invocation in a request.
Then one has to be aware, that another problem ocurs. The problem, how to transform the TCL strings into the respective C++ types, that are used within the C++ stubs and skeletons, which are linked in.

One considers that the type information is implicitly contained in a methods proclamation by the arrangement of the formal arguments, one does not need to carry them with explicitly. As the Idl definition of the methods is basis for the generation of the corresponding C++ method signature in the proxy objects (stub,skeleton), it is always known, that for example the first argument of a method corresponds to a certain type. There must be implemented only one time a serie of converting functions for the conversion of TCL types into respective C++ types, which can be applied several times. The problem to solve is, how this conversion functions can be applied automaticly depending on a concrete IDL definition, and how they can be automaticly connected with the automticly generated proxy object of the reused IDL to C++ compiler.
Respectively a pair of of conversion function  from TCL to C + +, as well as from C + + to TCL, Convert::form_tcl() and Convert::to-tcl ()  is implemented.
According to the description, this is a task easy to be automated by means of scripts.
 
 

illustration2: implementation of the introduced bindings

 
CORBA SCRIPT:
CORBA script is a script language newly written for CORBAs purposes. It provides features for object orientation, classes can be defined, polymorphism and multiple inheritance is supported. By using modules
modules it becomes also possible to summarize reusable program parts into a package and capsulate them in an name space. The existing language mapping is based also on the dynamic invocation and the necessary type information are requested from the IR at run-time. CORBA script itself was realized by throug the use of C++. The implementations architecture is formed by different layers, of those the lowest layer forms an abstraction for the orb, with the reason, that -in spite of standardization- function signatures and its elements can vary from ORB implementation to implementation
CORBA Script:

 
TCL-DII and its new edtion TCL-IIOP
Both approaches have in common, that they realize the invocatione by using the dynamic invocation. The type information for the transformation of the arguments however is not obtained by a query of the interface repository, but rather by some proprietar type codes,  that the programmer has to carry with the arguments.
The dynamic invocation is executed by means of only method orb_call(). These are delivered as arguments the identifier of the function to be called, followed by a place stop for the return value to be received and the single arguments in pairs with identifier and type data.
This look like:     inherited_call  $result  methodname    f  1.35
To mention further, that both solutions cover only the Clientseite.

 
FNORB
Fnorb by means of Phyton. This approach differs in as far as, that requests are packed and sent directly in form of IIOP messages.
Bsp  : inherited = CORBA: orb_init (argv, CORBA:orb_id)
        object = orb.string_to_objekt(StringIOR)
        object.methodname($something)

 
COPE
At this point COPE should be introduced. COPE supports an integration of PERL and CORBA. This implementation, like the above introduce one, called TCL-DII depends very on  proprietary features of a certain ORB produkt, because to obtain type information the IDL2PERL compiler needs translate the proprietary type codes of the interface repository of the ORBACUS implementation. The proceeding is that uniquely  skeletons and stubs are generated by use of the information of the interface repository.
 
 
 

illustration3: the flow of a dynamic methods invocation

 
 

In image 2, the flow of a dynamic method invocation is represented. In the prior chapter was mentioned that some of the unofficial language bindings dynamically produce method invocations. In fact some of the language bindings do not adhere to the naming conventions of the used methods and manage the generation of requests in their characteristic language, but a common difficulty for the approaches occurs: that of the pseudoobjects, that must be available within the respective program language.

 
1. Achieve access to an ORB
Condition to participate around in the CORBA communication is that a client accesses an ORB. For that purpose a so-called ORB object must be created and subsequently been initialized.
This ORB-object is a special object, it is a pseudoobject. pseudoobjects are those objects, that are located in the local name space of  the programming language and are handled just the same way as remote objects, which means that from view of the programmer no difference is to be recognized with the methods invocations. As soon as the ORB ist known, a further pseudoobject, the object adaptor must be created and initialized by use of boa_init ().

2. Obtain an object reference of a remote object. This can be achived by a name service or trader service. Over its object reference, remote objects can be called. This object reference is comparably with a reference in a program language with the difference, that it is not restricted on the local name space of a run-time environment.

3. Obtain an description of a certain method. Over an object reference, the method get-interface() can be called in order to receive a reference on an Interface-def object. This object is a component of an interface repositories and enables to get details about an interface of an certain object.

4. A list for arguments will contain the actual parameters that are delivered to the remote method. This list for arguments is a special selfdefining data structure. It is createcd only for the purpose of the invocation and is also a pseudoobjekt.

5. The invocation is carried out.

7 The language binding for REXX
 

    7.1  REXX and IDL
 

REXX itself shows some common features with the script languages introduced in this work.
Here is now tried, to represent, onto which features of the language REXX IDL can be conceptually mapped:
The simple data types can be mapped onto strings like in the other script languages . For complex data type, this is also possible as far as there are implemented some corresponding conversion routines as shown in COMBAT

 
For the operations, that belong to an IDL-interface, in classical REXX  a similar approach must be used, like in the C language binding. Lacking objectoriented characteristics in classical REXX, the in IDL called operations are mapped onto classic functions or so-called subroutines in REXX. Therefore a reference of a conceptual object always must be delivered as an additional first argument of a subroutine. That a so-called method of a certain object  is unambiguously determined, is be reached in the object orientation by means of qualifying dereferring the object in this form: Objekt1.methode1(). In contrast, this qualifying can be reached with classic functions with some sort of naming convention: objekt1_methode1(). A real form of incapsulation it is not, but is working well as long as the convention is not injured.

For the name space, that is given by IDL modules, as well as the interfaces, the extensionis missing here. Orientation is found certainly also in the conversion of the C Language Bindings.
Für den Namensraum, der durch IDL Module gegeben ist, sowie die Interfaces, fehlt hier der Ansatz. Orientierung findet sich sicherlich auch bei der Umsetzung des C Language Bindings.

For an exeption handling, REXX offers the possibilities to map those exceptions onto environment variables. It would be imagenable, like in the C mapping, to map an exception onto a struct, that then is passed to each method in a uniform way as a third argument per reference. Also possible is to map an exception onto a global variable that within the servants or clients possesses global validity. REXX offers the possibility of the boxing into each other of  environments and their environment variables.

Also for REXX, there is an object oriented expansion, or better: constructing on the classic REXX Objekt-REXX emerged, that offers a similar backward compatibility to the classic REXX, like it is the analogous case with C and C++. To use some object orient characteristics would be of advantage: on the one hand for the use  of servants, of which one must perhaps create a larger amount of instances, to the other hand for the later mentioned pseudoobject.
 
 
 
 

The REXX Interpreter itself exists in form of a dynamically linkable file. Potentially every application can link and use this interpreter. It is fully reentrant and supports that in the same process several REXX procedures can run in different threads. By linking of an already existing header file Rexx.h one can use this Interpreter within  C, C++.

Part of REXX is an API named SAA. This describes an interface, between the REXX interpreter and other compiled programs. The specification subdivides itself into several lower areas:
 

Include Subcommand Handler which are able to include commands for external environments and guarantee the access to a single subcommand out of the surrounding application

External Function handler, shall expand the REXX language with external functions. These are for the reversed way, the access out of the interpreter on the functions of the surrounding application, or the functions of a dynamic library.

Carrying out of REXX scripts located in seperated files

The variable interface, permits the access from outside to the variables in the interpreter

 
SubcommandHandler
This section describes the subcommand handler that permits an application to include commands that are located in a REXX script, and to carry them out.
It is assumed that an application started the REXXInterpreter, this therefore runs in the same adress space like the process. After loading of a REXX script, the functions contained in the script can be carried out then by the surrounding program. From the view of the interpreter, this program is an external environment. The Interpreter calls the subcommand handler and delivers the name of the command as parameter, so that the can execute the command, which looks like:

 
    APIRET APIENTRY handler (
        PRXSTRING command,
        PUSHORT fly
        PRXSTRING returnstring,)

REXXRegisterSubcomExe ()
This function should register a subcommand with the interface. This subcommand handle how above mentioned, must be located within the code of the calling program. After this registration, a REXX interpreter can carry out this subcommand by calling and delivering the name of the subcommand to the subcommand handle, that is located in the calling program, is called, and this will deliver the name of the Subkommandos.

 
External Function Handle
This section describes an external function that extends the language by enabling external functions to be written in different languages.
 

On the servers side, the implementation can be written in REXX and run in an interpreter, that is located within a servers, that is realized in a different  language. Exactly this advantage the introduced solutions utilize, that the C++ language binding can be a good base, because of its great availability among ORB products. A script with the subroutinen written in REXX can be loaded into a REXX interpreter.
 
 
 

illustration: the realization of a static server

 
How mentioned, there is the possibility in REXX, to bind functions in the format of a Dll by using  RXFuncadd (), and to use them as if it were commands implemented in REXX. As far as it is possible therefore to produce a dynamic link library of that in C++ implemented stub file, one could access to the functions contained within the stub out of the REXX  interpreter.
Another alternative, also possible with the SAA, seems to be the exterenal function handle, with which one can use after the registration of the external function by calling rexxegisterfunctionexe() this external function can be used within REXX.
 
 
 

illustration5: the realization of a static client

 
We recapitulate once the process in the dynamic method invocation, how it was itemized in chapter 6. In order to get an access to CORBA, one must obtain access to the ORB first. For this purpose a so-called ORB object  had to be created and to be initialized. For that threre ist in an object oriented program language some method similar to a classes method that belongs to the pseudoobject.
At the beginning it was mentioned that the objects ORB and BOA are pseudoobjects.
Here the question places itself, how pseudo objects can be used correctly for the purposes. To emphasize some quotations:
 
 
 
• "pseudoobjects are objects, that are located in the local adress space of the related program language are treated the same way as normal CORBA objects.From the programmers view there is no difference in the appearance of remote method invocations an local method invocations."
• "a pseudoobject is an object, that ist directly created by the ORB, which is itself an pseudoobject"
• "a reference on an instance of the pseudoobject ist obtained by calling the method orb-init().
• "pseudo objects are language specific objects, such an orbobject is not of necessity remote. It characteristically a process-local construct in a programming language and therewith obay  to restrictions: on the one hand that it is not represented in the IR, on the other side, that it is mapped on an public abstract class, that does not expand no other classes (or in JAVA inherit from interfaces).

 
 
 


illustration6: the connection with the pseudoobjects

The question places itself, how such a pseudoobject that exist for C + + can be made available for REXX?
For the static approach shown in chapter 7.2, the language binding in REXX forms a layer that lies above the stub. The Stub contains inherit conceptual the instance one. That inherited is found in form of in the Stub miteinkompilierten functions again.
For this approach solely the problem must be solved how the transformation of the REXX arguments in C++ is performed, and how can be automated.
 
 
 

illustration7:

The dynamic side

Considering a couple of ORB, there can be figured out, that they support only some few language bindings. In case of some ORBs it seemes, that the implementation of the ORB ist aligned very tight to the implementation of the language binding

In the description of the COMBAT package, that contains that above mentioned TCL binding, can be read that it runs on theoretically each ORB, that supports a language binding for C++. "Combat is a glue-package, written in C++, and access to features that are not available in TCL.
 

Even if the pseudoobjects, or better the parts, that closely are aligned with the implementation of the ORB, remain in their own program language, the DII doesn't have to be implemented in C++ for example, if the ORB internal protocol mechanism is known -as far as it differs from the IIOP-, or if the IIOP request can be created with other means. Because this can happen with a socket suitable for standard connections in TCP/IP, one could write the DII actually in REXX.
 
 
 

illustration8:

 
 
 
 
 
 
 
 
 

Literature index:

[1]    John Siegel "Corba3-fundamentals and programming"-OMG-Press 2000
[2]    OMG-C Language Mapping Spec-Orbos99-07-35
[3]    OMG-C++ Language Mapping Spec-Orbos99-07-41
[4]    OMG-Corba Specification 2.3-Orbos99-10-07
[5]    Frank Pilhofer-"A Corba Language Mapping"-7th Usenix Tcl/Tk Conference
[6]    Frank Pilhofer-"Combat"-http//www.informatik.uni-frankfurt.de/~fp/Tcl/Combat
[7]    Jason Brazile-"Rapid Corba Server Development"-7th Usenix Tcl/Tk Conference
[8]    "Perl Binding"-System Management Hewlett Packard
[9]    Orfali/ Harkey-"Corba Programming with JAVA and CORBA"-Wiley Press 1998
[10]  "MICO is CORBA, an open source CORBA 2.3 implementation"-Dokumentation zum Orb-http://www.mico.org
[11]  Christensen-"the REGINA REXX interpreter"-8.2000
[12]  Pilhofer/Merkle-"Corba-Mapping für Skriptsprachen"-Ix Magazin 4.1999