JLCA 3.0 - CORBA - Dealing with Other Languages
Since JLCA only converts Java applications and Java CORBA support is targeted through .NET Remoting, server and/or client applications written in other languages are not be converted entirely. Usually, a converted application could require extensive user-intervention to adapt the .NET Remoting application to the multi-language environment commonly seen in CORBA applications. Table 13 discusses possible scenarios behind Java applications using CORBA and suggests how to deal with converted applications.
CORBA Scenario |
A Non Java Server If there is a CORBA server which is not written in Java with Java and non Java clients. JLCA can convert the Java clients into .NET Remoting clients. However, it would be necessary to build a proxy application behaving as a bridge between .NET Remoting and CORBA. Such application would act as a Remoting server and a CORBA client. It listens to .NET Remoting requests and converts them into CORBA requests. |
A Java Server If there is a CORBA server written in Java with Java and non Java clients. JLCA can convert the Java server, object implementations and clients into .NET Remoting. However, to let non-java clients to connect through .NET Remoting, it would be necessary to build a proxy application behaving as a bridge between CORBA and .NET Remoting. Such an application would act as a Remoting server and a CORBA client. It would listen to CORBA requests and would convert them into .NET Remoting. |
Table 13: CORBA Conversion Scenarios
The suggested bridge application takes the advantage of the fact that servers and clients can be written in C++ and this language is fully supported by .NET Framework. Note that in both the above scenarios, the proxy approach is just a temporary solution. As soon as a third-party .NET solution is provided for the involved languages, the bridge will turn impractical. Table 14 summarizes the main advantages and disadvantages of the proxy-like application:
Advantages |
Disadvantages |
A great workaround for the unconverted features and they can continue working |
Mixed architecture: CORBA and .NET Remoting instead of 100% .NET Remoting |
CORBA and .NET Remoting applications can work together |
A bridge adds a level of indirection. |
Unconverted code remains unchanged |
|
Proxy generation is relatively easy |
|
Table 14: An Analysis for a Schema Involving a Bridge Application