JLCA 3.0 - Common Object Request Broker Architecture (CORBA)

  • [アーティクル]

CORBA is a core part of the Object Management Architecture (OMA), a complete infrastructure for distributed computing. It was developed to merge remote procedure calls and object orientation to achieve support for distributed objects. The standard can be implemented with hardware, OS and programming language independence using the Interface Definition Language (IDL). IDL is a purely declarative language to define interfaces to CORBA objects.

 

It is important to mention that the IDL defines some definitions not natively supported by Java (like structures, valuetypes and unions). Java CORBA support simulates CORBA support with classes. Java CORBA support is related to OMG CORBA Specification 2.3, specifically IBM WSDK (IDLJ Compiler) and API org.omg.CORBA. Java CORBA support is mainly converted to .NET Framework using System.Remoting API. Special analysis allows JLCA 3.0 to convert Java simulations to .NET Framework native constructions. A shared assembly between server and clients - with interfaces or base abstract classes - needs to be defined to publish the remote objects.

 

Main conversion of Java CORBA in JLCA 3.0 supports the following features in IDL files: Names and Scoping, Modules, Interfaces, Typedefs, Exceptions, Basic Data Types, Constants, Arrays, Sequences, Enums, Structs, Unions and Value Types; Serialization and, Server and Client Sides.

 

Table 10,Table 11 and Table 12 contain relevant details for conversion of Java applications using CORBA. In a summarized manner, they enunciate the CORBA features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting applications using CORBA.

 

Coverage Details

IDL File Element

.NET Framework Equivalent

JLCA 3.0 Coverage

Description

Arrays

Arrays

Converted

IDL Arrays are converted to C# boundless arrays.

Basic Datatypes

Basic Datatypes on Namespace System

Converted

IDL Basic Datatypes are converted to .NET’s native datatypes.

Constants

public static readonly fields

Converted

IDL Constants within an Interface or Value Type are converted to public static readonly fields inside their respective owner.

IDL Constants within modules are converted into public static readonly fields inside C# structs whose name is the name of the module + “_Fields”.

IDL global constants (outside the modules) are converted inside a C# struct whose name is “global Fields”.

Exceptions

RemotingException

Converted

Exceptions are converted to user exceptions extending System.Remoting.RemotingException and implementing the interface ISerializable.

Interfaces

Interfaces

Converted

Multiple-Inheritance is supported at interface-level. Interfaces are converted to C# interfaces (inside the corresponding shared assembly). Abstract interfaces are converted as non-abstract ones.

Attributes and Operations are converted to interface properties and methods respectively. Also in, out, and inout parameters are converted to normal, out and ref parameters.

Furthermore, classes implementing IDL interfaces (published objects) are converted to classes implementing their converted interface and extending System.MarshallByRefObject.

Modules

Namespaces

Converted

IDL Nested modules are converted to nested namespaces.

Operation Contexts

-

 

JLCA 3.0 Warns the user when Operation Context Expressions are not converted.

Sequences

Arrays

Converted

IDL Sequences are converted to C# arrays. Bounded sequences are converted as boundless.

Structures

Enumerations

Structs

Enums

Convereted

IDL structs and enums are converted to serializable C# structs and enums respectively.

Unions

Structs

Converted

IDL Unions are converted to serializable C# structs with a discriminant used to select which value to use.

Value Types

Classes and Interfaces

Converted

Concrete Value Types are converted to serializable C# abstract classes. Factory methods are converted to public static methods. Custom Value Types are converted as non-custom ones. Also, Abstract Value Types are converted to interfaces.

Furthermore, classes implementing IDL value types (published objects) are converted to serializable classes extending from/implementing its converted value type.

Table 10: CORBA Conversion Coverage (1)

Java

JLCA 3.0 Coverage

Description

CORBA Server And Client Applications

Partially

Converted

CORBA Server and Clients conversion is based on source patterns using the methods rebind/bind and resolve (for servers and clients, respectively) of classes org.omg.CosNaming.NamingContext and javax.naming.InitialContext. Conversion of servers produces a Configuration file (".config") to specify information about .NET Remoting.

Object Implementation (Published Objects)

Converted

Published Objects are converted to respective classes generated in the shared assemblies. These classes implement the corresponding converted IDL interface/valuetype and inherit from the class System.MarshallByRef.

Table 11: CORBA Conversion Coverage (2)

Issues

Issue

Description

Dynamic Skeleton Interface

(DSI)

Java CORBA applications using DSI are not converted The object implementations requires user-intervention as a pre-conversion step.

Converting object implementations extending from org.omg.CORBA.DynamicImplementation requires the source code to be modified changing the inheritance to the right skeleton and implementing the functionality declared in the respective IDL file.

General Issues And .NET Projects

Since IDL files contain the interface declaration for published objects which is used to organize the resulting .NET Framework Remoting application and to convert user objects implementations, CORBA conversion depends on these IDL files. For each IDL file inside the source code directory, JLCA 3.0 creates a shared .NET Framework Remoting Project with the same name as the IDL file (inside a folder called “IDLProjects”). It contains all the interfaces declared in the respective IDL file (published objects) and the implementation of objects passed by value between servers and clients. These projects should be shared for both server and client applications (just as the IDL File was “shared” in Java).

Conversion for servers, clients and user-classes is contained inside the conversion’s target project. In this project, the user needs to add all the references for the required shared assemblies.

IDL, Skeleton And Stub Files

IDL files are required for CORBA conversion. Converting Java applications using CORBA without providing the corresponding IDL files will not successfully convert the CORBA functionality. This might require creating the respective IDL files before converting the code.

Skeleton and Stub files are discarded because they are not needed in .NET. Thus, the user code existing in skeletons and stubs would be lost. In fact, in Java CORBA, it is highly recommended that users should not modify the stubs and skeleton files (as they are automatically generated).

Non IBM-WSDK Object Request Brokers

Object Request Brokers (ORB) implementations different than IBM WSDK (such as VisiBroker) are not converted. Thus, server/clients require intervention in the sections related to objects accesses and ORB initialization because the code is vendor dependant.

Also, conversion of applications using Portable Object Adapters (POA) instead of Basic Object Adapters (BOA) requires some user-intervention. The POA policies functionality could be lost during the conversion. Clients that use Dynamic Invocation Interface (DII) are not converted.

Non-Java Servers/Clients

As Java CORBA is converted to .NET Remoting, the ideal scenario for CORBA conversion is when both server and client applications are being ported to .NET.

However, a commonplace CORBA environment involves server and client applications implemented in different languages. Since JLCA only converts Java Code and Java CORBA support is targeted through .NET Remoting, such scenarios are not converted at all and require extensive user-intervention.

This issue is extensively addressed in the next section.

Table 12: CORBA Conversion Issues

Comments