J2EE , CORBA and .NET by usr10478

VIEWS: 170 PAGES: 13

									                   Seemless Integration of
           J2EE , CORBA and .NET
                Integration of the different environments
                   without additional bridge products
                        Author: Martin Heinzl, Senior Consultant

The integration of software solutions like J2EE, CORBA or .NET is a never ending
story for the software development. Borland introduces with Janeva a new and very
easy possibility which enables developers to integrate different IT worlds without
additional bridge software products.

Again and again serious and longterm technology decisions must be made by IT decision
makers, which affect in most cases not only a single project but an entire IT landscape.
Since new technologies do develop again and again decision makers must consider every
few years their past strategies. New technologies and new standards can bring substantial
advantages to the software development of an enterprise in relation to older technologies.
However technology changes and strategy decisions normally require huge migration
efforts for legacy systems or due to budget and time limits are not realistic at all. A very
important characteristic of new technologies and strategies will always be their abilities
to integrated with the existing systems.

The newest trend of the software development integrates different systems and
technologies using Web services. Furthermore the flexible and everywhere available data
exchange format XML will be used for exchanging data. For the communication between
enterprises or also within branches of enterprises the communication using Web services
is most likely a very good choice. This is not however a universal remedy for all
problems of the software development. For a server infrastructure within an enterprise a
solid infrastructure is required, which is not only safe, but also supports failover,
loadbalancing and 24x7 support.

Two substantial candidates are in the today’s time in the discussion for such software
    • J2EE (Java 2 Enterprise edition)
    • .NET, the new technology from Microsoft

A decision for one of these two worlds has large influence on the software development
and architecture in an enterprises. The two platforms J2EE and NET control today
already 85% of the planned application investments (source: Gartner). It is not necessary
always to commit itself 100% to one of these two worlds. Also a mixed combination is
possible and often used. The complexity of the platforms does not make a decision easy.
Therefore the differences and/or the pro and cons of these two platforms must be known
and understood by the dicision makers

There is however still another third platform, which is nowadays - often to injustice –
pretty often ignored. This is CORBA (Common Object Request broker specification of
the Object Management Group) itself. Freely after the slogan: “The Deaths are living
longer” there are still projects, which work directly with CORBA. CORBA is everything
but dead and experienced a new upswing with the victory of J2EE in its most current
form. This is not visible or recognized by everybody.

The J2EE specification decided to define CORBA as general communication medium for
the communication between the different container. As special entry points exist of
course also JMS (Java Message service) and/or Web-services and SOAP (simple Object
ACCESS Protocol). That means that an existing CORBA infrastructure can be integrated
into a J2EE infrastructure very naturally. In addition manufacturers utilize the above
mentioned characteristics (e.g. reliability, loadbalancing) of the underlying CORBA
infrastructure (e.g. with the Borland Enterprise Server which uses extensively the proven
VisiBroker (the CORBA implementation of Borland) infrastructure).

The .NET platform developed by Microsoft of course also knows the communication
with distributed (remote) systems. This is an important aspect of the NET Frameworks
which is part of the “Remoting” framework of .NET. The NET infrastructure naturally
does not offer another possibility to communicate with J2EE or CORBA servers than
Web services. There are meanwhile some solutions systems - so-called bridges – which
allow communication from .NET to J2EE and CORBA servers.
As the nature of bridge products impose, these solutions however add both, an additional
network access and a new bottleneck or even single point of failure.

Picture 1.: Shortcuts of today’s solutions
This article would like to present another kind of communication possibility. Borland
develops a possibility with the product Janeva (internal project name is VisiNET) to
communicate directly from a .NET process via CORBA (based on the proven VisiBroker
technology) with CORBA and/or J2EE servers. This technology is based on the
Remoting architecture of .NET. As this product is based on the .NET framework (and
actually a native .NET implementation) it is neither a bridge product nor a bottleneck or
additonal point of failure. It is integrated directly into a .NET process and not an
additional system process.

Picture 2.: Janeva approach

The integration solution with Janeva therefore solves three very important goals:
       1. No additional infrastructures needed
       2. No changes required to back end infrastructure and source code
       3. Seamless interoperability without forcing .NET developers to learn J2EE or

Since all worlds can be combined, technology decisions can be revised for new projects
without isolating projects are technology worlds. J2EE has CORBA as underlying
communication platform anyway. For .NET further possibilities are added e.g. Firewall
support, security, HTTP Tunneling, services... by CORBA (e.g. with Janeva). In addition
all systems can be still combined using Webservices. Mainly for Intranet applications
Borland develops a native .NET CORBA implementation for a native and elegant
integration of these worlds elegantly (only another kind of communication on the .NET
     Architecture of the Janeva .NET CORBA Implementation
     Similar to all CORBA the products (see also VisiBroker for Java and C++) the Janeva
     product consists of a runtime environment and different code generators. Janeva is in
     reality a port of VisiBroker for Java to J# and will therefore gradually have all
     characteristics of the VisiBroker product family.

     Two compilers with will be delivered with the first version. One compiler in order to
     generate stubs out of CORBA-IDL and another compiler to generate stubs out of java
     RMI interface (mainly for access to J2ÈE systems). An interesting aspect of the generated
     stubs is the fact that these are not generated for a specific language only but for the CTS
     (Common type system - the Microsoft develop language independent type system). This
     means, that from idl2cs (IDL to C#) compiler generated stubs can be used likewise in
     other .NET languages, e.g. JScript...

C#    Basic      C++           C#      Basic    JScript

Janeva .NET Stubs              Janeva .NET Stubs                 EJB1   EJB2          Obj1     Obj2

                                                                 J2EE Server             CORBA
  .NET Runtime                 ASP.NET Runtime

 Janeva Runtime                  Janeva Runtime                   RMI-IIOP              IDL-IIOP

     Picture 3.: Deployment Architecture of the Janeva product

     An important aspect with the deployment is that no parts of Janeva are required on the
     server side (neither for CORBA nor J2EE) - see Picture 1. This shows clearly that the
     complete ,NET communication is transparent and thus for the servers (J2EE and
     CORBA) received as pure CORBA communication.

     For client developer one of the main strengths of Janeva is the possibility to exclusively
     develop against the .NET model. Only limited CORBA or J2EE knowledge is needed on
     the client side. By looking closer at the generated stubs you can realize that these are
     separated into two different layers (see Picture 2). One layer is a “ Raw a Stub Layer” for
     the access to the pure CORBA technology and the second (higher) layer is an “ Ease of
     Use Layer” which allows .NET access to the CORBA or J2EE technologies.
                                                    J2EE Server Environment

                                                                Naming Service
                     C# Client

                   Ease-of-Use Layer
                                                            Transaction Service
                 Raw Stub Layer

                  .NET Runtime                                  EJB Container

                Janeva Runtime                                      Home Objects

                                                                  Remote Objects

Picture.:4 Layermodel of the Janeva Product

Characteristics of Janeva
The CORBA implementation Janeva is based on the solid codebase of the product
VisiBroker/Java. Therefore already the first version of Janeva has the following
characteristics. It contains a complete (temporary clientseitige) implementation of the
CORBA standard. In the first version no functional POA is provided. This is however
planned for a successor version. Janeva contains the high performant
marshalling/demarshalling engine for CORBA conformal IIOP communication, the
support of the VisiBroker TCP/IP connecting handling, the complete support of objects
by value which is essential for RMI/IIOP communication and many the other VisiBroker
features. A support for security and transactions as well as the possibility to extend the
ORB functionality with interceptors are planned for a successor version as well as the
support for CORBA server functionality for .NET.
Example for the integration of these three worlds
The following programming example shows the integration between the different
technology worlds. The focus of this example is the demonstration of the transparency
between the different worlds. Therefore a complicated business logic is omitted and the
different server only returns a string information of the job which should have been done.
The example consists of a NET Client, a remote file access server (CORBA server) and a
remote database access server (J2EE). In order to show all possible integrations, the
database access server will also ask the file server to save the information on disk and the
file access server will also ask the database server to save the information in the database.
This example shows that a combined J2EE and CORBA world makes sense, since J2EE
(special Entity Beans) are better suitable for database access (inclusive transaction
security...) however according to specification of EJBs files cannot be accessed directly.
CORBA on the other hand does not have a persistence model but has no restriction for
file access. These restrictions, and/or liberties already led in many projects to a
heterogeneous landscape with J2EE and CORBA elements.

Picture:5 Communication in the example application. The different colours just show the different
communication paths implemented in the example and have no further meaning.

The following example shows the complete source code of all three applications. The
genereated code is omitted.
Definition of the required Interfaces
First of all the required interfaces of the two servers must be defined. The IDL (CORBA)
definition of the FileAccess server and the Home and Remote interface (EJB) of the
database access server must be defined. In each interface two methods are defined:
“ saveData” for the access from the NET Client and “ savaDataInternal” for the access of
the servers among themselves.

IDL Interface of the CORBA Server:

       module integrationtest
         exception SaveException {};
         typedef sequence<octet> TestData;

         interface FileAccess {
           string saveData(in string id, in TestData data)
                           raises (SaveException);
           string saveDataInternal(in string id, in TestData data)
                           raises (SaveException);

Remote interface of the example-EJB (DatabaseAccess):

       package integrationtest.ejb;

       < import statements … >

       public interface DatabaseAccess extends javax.ejb.EJBObject
         public String saveData(String id, byte[] data)
                        throws RemoteException, SaveException;
         public String saveDataInternal(String id, byte[] data)
                        throws RemoteException, SaveException;

Home interface of the example-EJB (DatabaseAccess):
       package integrationtest.ejb;

       < import statements … >

       public interface DatabaseAccessHome extends javax.ejb.EJBHome {
         public DatabaseAccess create() throws CreateException, RemoteException;

In this example further details such as J2EE security based on access rights or other
security technologies as well as dividing the interface into different interfaces for the
access of the servers among themselves and/or the access of the NET Client are omitted
on purpose in order to keep the example simple. It is also worthwhile to mention that
Borland already has a uniform security infrastructure between all EJB components, EJB
Clients, Java/CORBA servers and Java/CORBA clients. An preview implementation of
the safety technologies (CSIv2, JAAS similarly) for VisiBroker C++ is already available
and a port to C # for a later version of Janeva planned. Therefore a commin security and
transactional infrastructure for all platforms will be available.

Implementation of the EJB of the DatabaseAccess Server:
The ejbCreate() method is of particular interest. You can see that the standard J2EE
functionality (lookup, PortableRemoteObject.narrow) can also be used in order to get a
remote reference to a CORBA server and narrow it. Therefore it is impossible (except
through expressive name choice) to differentiate between the access to a CORBA server
and the access to another EJB. Through RMI/IIOP both Zuriffe are treated identically.

       package integrationtest.ejb;

       < import statements … >

       public class DatabaseAccessBean implements SessionBean {
         SessionContext sessionContext;

           FileAccess myCORBAService = null;

           public void ejbCreate() throws CreateException
             try {
               InitialContext ctx = new InitialContext();
               myCORBAService = (FileAccess)
             catch (Exception ex) {
               throw new EJBException(ex);

           public String saveData(String id, byte[] data)
               throws SaveException
             try {
                   saveDataInternal(id,data) +
                   myCORBAService.saveDataInternal(id, data);
             catch (Exception ex) {
               throw new SaveException(ex.getMessage());

           public String saveDataInternal(String id, byte[] data)
               throws SaveException
               return "Data with ID:" + id + " saved into database !!\n" ;

           < other Ejb methods … >

Implementation of the FileAccess-Server (CORBA Server):
The constructor of the servant is of particular interest. You can see that the standard
CORBA functionality (resolve, narrow) can also be used in order to get a remote
reference to an EJB Home and narrow it. Therefore it is impossible (except through
expressive name choice) to differentiate between the access to another CORBA server
and the access to an EJB.

       package integrationtest.corba;

       < import statements … >

       public class FileAccessImpl extends FileAccessPOA
         DatabaseAccess mySession = null;
         public FileAccessImpl(NamingContextExt root)
           try {
             // Get DatenbankAblage Home Object and cast it
             Object mObj =

                DatabaseAccessHome databaseAccessHome
                    = DatabaseAccessHomeHelper.narrow(mObj);

                 mySession = databaseAccessHome.create();
               catch (Exception ex) {

           public String saveData (String id, byte[] data) throws SaveException
             try {
             catch (Exception ex) {
               throw new SaveException(ex.getMessage());


           public String saveDataInternal (String id, byte[] data)
                         throws SaveException
               return "Data with ID:"+id+" saved on file system !\n";

Additionally to the Servant the actual CORBA server process must be developed. This is
only the initialization of the ORBs, the access to the Namingservice and the creation and
activation of the servant and its registration into the Namingservice. This SOURCE code
is only listed for completeness.

       package integrationtest.corba;

       < import statements ... >

       public class FileAccessServer {
           public static void main(String[] args)
             try {
               System.out.println("Initializing the ORB...");
               ORB orb = ORB.init(args,null);

                System.out.println("Getting a reference of the root POA...");
                POA root_poa = POAHelper.narrow(

                // Get NamingService
                Object rootObj = orb.resolve_initial_references("NameService");
                NamingContextExt root = NamingContextExtHelper.narrow(rootObj);

                // Create
                FileAccessImpl myService = new FileAccessImpl(root);

                // Register in NAmingService

                System.out.println("Server ready ...");
               catch (Exception ex) {

Implementation of the .NET Client with access to both
This source code is the only code block in C # and shows therefore the use of Janeva in
.NET. All previous code examples were written in Java. After the initialization of the
ORB the necessary reference on the Namingservice can be obtained. There are several
possibilites including the use of ResolveInitialReferences which is demonstrated here. By
analying the code you can realize that the method names of the J2EE and CORBA server
methods are adopted by the idl2cs and java2cs compilers to .NET style names. This
behaviour can also be disabled when running the compilers.

Afterwards it is the same procedure is for both examples (CORBA access and EJB
access). Query the naming service, convert (narrow) and access the obtained object. In
case of EJBs the JNDI naming reference and the PortableRemoteObject can be used. This
is not a requirement. It is also possible to use the default CORBA naming service
reference and the standard CORBA narrow.

The example shows also, how from both worlds (CORBA and EJB) possibly arising user
exception (“ SaveException” called here) can be caugth.

I would like to mention again that this code is written in C# and that Janeva primarily
generates C#. Of course the example could be written in all supported .NET languages. In
order to write this example in other languages it is only required to compile the generated
C# stubs into .NET assemblies and make these available to the other languages.

       using       System;
       using       CosNaming;
       using       integrationtest;
       using       integrationtest.ejb;

       namespace Integrationstest
         class Client
           static void Main(string[] args)
               // initialize the ORB
               CORBA.ORB orb = CORBA.ORB.Init(args);

                    // Obtain the root context.
                    CORBA.Object rootObj = orb.ResolveInitialReferences("NameService");
                    NamingContextExt root = NamingContextExtHelper.Narrow(rootObj);

                    CORBA.Object mgrObj = root.Resolve(root.ToName("FileAccess"));
                    FileAccess myFileSystem = FileAccessHelper.Narrow(mgrObj);

                    // call CORBA Server
                    try {
                            Console.WriteLine(myFileSystem.SaveData("my Data", new byte[0]));
                    catch (integrationtest.SaveException e_save) {
                            Console.WriteLine("Caught CORBA User-Exception !!");

                    // Resolve and narrow an EJB Reference
                    object homeObj = J2EE.Naming.InitialContext().Lookup("DatabaseAccess");
                    DatabaseAccessHome myHome = (DatabaseAccessHome)
                    DatabaseAccess mySession = myHome.Create();

                    // Call EJB
                    try {
                            Console.WriteLine(mySession.SaveData("my EJB Data", new byte[0]));
                    catch (integrationtest.ejb.SaveException e_save) {
                            Console.WriteLine("Caught EJB User-Exception !!");
                   catch (Exception e) {

Futher Integrations with Janeva
The example in this article shows clearly, how simply and transparent these worlds can
be integrated. In this example both J2EE and CORBA access were represented. A further
possible combination alos exists from .NET clients to Delphi, since a VisiBroker
implementation is also available for the Delphi development environment.

At present no .NET Servers can be written with Janeva (this is planned for a future
release). Of course Web services can be used by J2EE and CORBA components to
communicate back to .NET if required. A future version of Janeva will also make server-
side CORBA components in .NET possible.

Borland Enterprise Server
The J2EE and CORBA server in this article were developed and tested with the Borland
Enterprise Server 5.2. The server-side source code in this article though contains no
Borland specific code and should therefore run on all standard-conform application
servern and/or ORBs. Due to its CORBA architecture the Borland Enterprise Server is
however best suited for such integrations.

The purpose of this article is to show that .NET, J2EE and CORBA are by no means only
competitive systems. Free of doubts there are some overlaps. Nevertheless heterogeneous
system landscapes do exist and will always exist in the industry. Therefore this kind of
integration offers a very simple and natural possibility to integrate the different worlds.
Furthermore this still offers very transparent programming on all sides.
CORBA offers in addition a safer and more performant communication than Web
services. Free of doubts this possibility cannot be used everywhere (see e.g. Internet)
however by using matured CORBA technology (VisiBroker offers among other things
also a OMG FirewallProxy) this technology can in many cases provide a problem-free
integration make a heterogeneous system landscape possible.

The Author

Martin Heinzl works since more then 5 years at Borland as distributed technology specialist in the
area of distributed systems with the main focus on J2EE and CORBA and all surrounding
technologies. As Senior Consultant he is involved in trainings, architectural and product
consulting within all stages of the projects (Requirements analysis, software architecture,
implementation, deployment architecture, …).

To top