J2EE , CORBA und .NET by usr10478

VIEWS: 71 PAGES: 12

									                  Nahtlose Integration von
           J2EE , CORBA und .NET
   Integration der unterschiedlichen Welten ohne zusätzliche
                        Brückenprodukte
                        Autor: Martin Heinzl, Senior Consultant


Immer wieder müssen von IT-Verantwortlichen schwerwiegende Technologie-
Entscheidungen getroffen werden, die meistens nicht nur ein Projekt sondern eine
gesamte IT Landschaft beeinflussen. Da immer wieder neue Technologien entstehen
müssen Entschieder alle paar Jahre ihre bisherigen Strategien überdenken. Neue
Technologien und neue Standards können der Softwareentwicklung eines Unternehmens
erhebliche Vorteile gegenüber älteren Technologien bringen. Allerdings sind
Technologie- und Strategieänderungen für Altsysteme meist mit großen
Migrationsaufwänden verbunden oder gar aufgrund von Budget- und Zeitbeschränkungen
überhaupt nicht realistisch. Eine sehr wichtige Eigenschaft neuer Technologien und
Strategien ist daher immer deren Fähigkeit sich mit den vorhandenen Systemen zu
integrieren.

Der neueste Trend der Softwarenetwicklung geht mit dem Themenbereich Webservices
dazu über Systeme sehr lose miteinander zu koppeln und Daten über XML
auszutauschen. Dies ist jedoch nicht ein Allheilmittel für alle Probleme der
Softwareentwicklung. Für eine serverlastige Infrastruktur innerhalb eines Unternehmens
– zwischen Unternehmen oder auch Unternehmenszweigen ist die Kommunikation über
Webservices zweifelsfrei eine sehr gute Wahl – bedarf es einer soliden Infrastruktur, die
nicht nur sicher ist, sondern bei der besonders Themen wie Verfügbarkeit,
Ausfallsicherheit, Lastverteilung, Wartbarkeit und Betrieb eine große Rolle spielen.

Zwei wesentliche Kandidaten sind in der heutigen Zeit in der Diskussion für derartige
Softwareinfrastrukturen:
   • J2EE (Java 2 Enterprise Edition), eine Sammlung von java basierten Standards
   • .NET, die neue Technologie von Microsoft

Eine Entscheidung für eine dieser beiden Welten hat auf die Softwareentwicklung und
die Architektur in den Unternehmen großen Einfluss. Die beiden Plattformen J2EE und
.NET beherrschen schon heute 85 Prozent der geplanten Applikationsinvestitionen
(Quelle: Gartner). Es ist nicht immer notwendig, sich 100% auf eine dieser beiden
Welten festzulegen. Auch eine Mischform ist möglich und wird oft genutzt.
Die Komplexität der Plattformen macht eine Entscheidung nicht einfach. Daher müssen
den Entscheidern die Unterschiede bzw. die Vor- und Nachteile der beiden Plattformen
bewußt sein.
Es gibt allerdings noch eine dritte Plattform, die heutzutage – oft zu Unrecht – immer
weiter in den Hintergrund gedrängt wird, und das CORBA (Common Object Request
Broker Spezifikation der Ombject Management Group) selber. Frei nach dem Motto:
„Totgeglaubte leben länger“ gibt es sehr wohl noch Projekte, die direkt mit CORBA
arbeiten. CORBA ist alles andere aber nicht tot sondern hat gerade durch J2EE in seiner
aktuellsten Form einen neuen Aufschwung erlebt, was allerdings nicht immer für alle
Beteiligten sichtbar ist.

Die J2EE Spezifikation hat sich dazu entschieden, CORBA als generelles
Kommunikationsmedium für die Kommunikation zwischen den unterschiedlichen
Kontainern zu definieren. Als besondere Einsteigspunkte gibt es daneben natürlich auch
JMS (Java Message Service) bzw. Webservices und SOAP (Simple Object Access
Protocol). Das bedeutet das eine bestehende CORBA Infrastruktur sehr wohl in eine
J2EE Infrastruktur eingebunden werden kann. Darüberhinaus gehen Hersteller dazu über
die oben erwähnten Eigenschaften (u.a. Ausfallsicherheit, Lastverteilung) der
zugrundeliegenden CORBA Infrastruktur zu nutzen (z.B. beim Borland Enterpise Server
der intensiv die bewährte VisiBroker (die CORBA Implementierung von Borland)
Infrastruktur nutzt).

Die von Microsoft entwickelte .NET Plattform kennt selbstverständlich ebenfalls die
Kommunikation mit entfernten Systemen. Dies ist ein wichtiger Aspekt des .NET
Frameworks der normalerweise als „Remoting“ bezeichnet wird. Die .NET Infrastruktur
bietet von Haus aus außer WebServices keine Möglichkeit an mit einem J2EE oder
CORBA Server zu kommunizieren. Es gibt mittlerweile einige Systeme – sog. Brücken
oder Bridges genannt – die eine Kommunikation möglich machen. Diese allerdings
erzeugen sowohl einen zusätzlichen Netzwerkzugriff als aus eine neue mögliche
Fehlerquelle bzw. Engpass in der Architektur.

Dieser Artikel möchte eine andere Art von Kommunikationsmöglichkeit vorstellen.
Borland entwickelt mit dem Produkt Janeva (interner Projektname ist VisiNET) eine
Möglichkeit direkt aus einem .NET Prozess heraus via CORBA (aufbauend auf der
bewährten VisiBroker Technologie) mit CORBA bzw. J2EE Servern zu kommunizieren.
Diese Technologie setzt auf der Remoting Architektur von .NET auf. Da dieses Produkt
auf Basis von .NET entwickelt wurde ist es weder ein typische Software- oder
Kommunkationsbrücke noch ein Systemflaschenhals. Es ist daher direkt in einen .NET
Prozess integriert und kein zusätzlicher Systemprozess oder –komponente.

Da sich daher alle Welten miteinander kombinieren lassen, wird man sich mit keiner
dieser Technologien ins Abseits navigieren. J2EE hat sowieso CORBA als
zugrundeliegende Kommunikationsplattform. Für .NET kommen durch CORBA (z.B.
mit Janeva) weitere Möglichkeiten wie z.B. Firewall Support, Sicherheit, HTTP
Tunneling, Services, ... hinzu. Darüberhinaus können sich alle Systeme selbstverständlich
nach wie vor auch mittels Webservices kombinieren lassen. Hauptsächlich für Intranet
Anwendungen entwickelt Borland eine native .NET CORBA Implementierung um die
Integration dieser Welten elegant (nur ein andere Art (nicht CORBA spezifisch) von
     Kommunikation auf der .NET Seite) und vor allem performant und skalierbar zur
     Verfügung zu stellen.



     Architektur der .NET CORBA Implementierung
     Ähnlich wie alle CORBA Systeme (vergleiche auch VisiBroker für Java und C++
     Produkte) besteht das Produkt Janeva aus einer Laufzeitumgebung und verschiedenen
     Codegeneratoren. Janeva ist im Kern eine Portierung von VisiBroker für Java nach J#
     und wird daher nach und nach alle Eigenschaften der VisiBroker Produktfamilie zur
     Verfügung haben.

     Es werden in der ersten Version 2 Compiler mit ausgeliefert werden. Ein Compiler um
     Stubs aus CORBA-IDL zu generieren und ein weiterer Compiler um Stubs von java RMI
     Interfaces zu generieren (hauptsächlich für Zugriff auf J2EE Systeme). Ein interessanter
     Aspekt bei den generierten Stub besteht darin, das diese nicht auf für eine bestimmte
     Sprache generiert werden sondern auf dem CTS (Common Type System – dem Microsoft
     sprachunabhängigen Typsystem) aufbauen. Das bedeutet, das die von einem IDL2CS
     (IDL nach C#) Compiler generierten Stubs ebenso in anderen .NET Sprachen, wie z.B.
     JScript, ... verwendet werden können.


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


     Abb.:1 Deployment Architektur des Janeva Produktes

     Ein wichtiger Aspekt beim Deployment ist es, das keinerlei Komponenten von Janeva auf
     der Serverseite (weder für CORBA noch J2EE) notwendig sind (vgl. Abb. 1). Dies zeigt
     deutlich, das die .NET Kommunikation vollständig transparent und damit für die Server
     (J2EE und CORBA) als reine CORBA Kommunikation erscheint.

     Für Client Entwickler ist eine der Hauptstärken von Janeva die Möglichkeit
     ausschließlich gegen das .NET Modell zu programmieren. Es sind auf der Client Seite
     wenige CORBA oder J2EE Kenntnisse notwendig. Bei genauerer Betrachtung der
     generierten Stubs bemerkt man, das diese in 2 Schichten aufgeteilt sind (vgl. Abb. 2) , ein
     „Raw Stub Layer“ für den Zugriff auf pure CORBA Technologie und einen „Ease-of-
     Use Layer“ der eine .NET Variante für den Zugriff auf J2EE Technologien enthält.
                                                  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




Abb.:2 Schichtenmodell des Janeva Produktes




Eigenschaften von Janeva
Die CORBA Implementierung Janeva basiert auf der soliden Codebasis des Produktes
VisiBroker/Java. Daher hat auch schon die erste Version von Janeva folgende
Eigenschaften. Es handelt sich um eine komplette (vorläufig clientseitige)
Implementierung des CORBA Standards. In der ersten Version wird kein (für den
Programmierer) funktionsfähiger POA mitgeliefert, dies ist allerdings für eine
Nachfolgerversion geplant. Janeva enthält eine hochperformante
Marshalling/Demarshalling Engine für CORBA konforme IIOP Kommunikation, die
Unterstütung der VisiBroker TCP/IP Verbindungsverwaltung, die komplette
Unterstützung von Objects-by-Value was für die Kommunikation RMI/IIOP unerläßlich
ist und viele der sonstigen VisiBroker Eigenschaften. Eine Unterstützung für Sicherheit
und Transaktionen sowie die Möglichkeit den ORB mittels Interceptoren zu erweitern ist
für eine Nachfolgerversion geplant, genauso wie die Möglichkeit .NET Programme als
CORBA Server anzusprechen.
Beispiel für die Integration der 3 Welten
Das folgende Programmbeispiel soll die Integration zwischen den unterschiedlichen
Welten zeigen. Dabei soll besonders die Transparenz zwischen den Welten dargestellt
werden. Daher wird auf eine komplizierte Geschäftslogik verzichtet und nur ein String
zurückgegeben, welche Arbeit eigentlich hätte gemacht werden sollen. Das Beispiel
besteht aus einem .NET Client, einer entfernten DateiAblage (CORBA Server) und einer
entfernten DatenbankAblage (J2EE). Um alle möglichen Integrationen zu zeigen, wird
die DatenbankAblage alle Daten auch an die DateiAblage schicken und andersherum
ebenfalls. Dieses Beispiel zeigt gleichzeitig das eine kombinierte J2EE und CORBA Welt
Sinn machen kann, da J2EE (speziell Entity Beans) beim Datenbankzugriff (inkl.
Transaktionssicherheit, ...) besser geeignet sind aber laut Spezifikation von EJBs auf
Dateien nicht direkt zugegriffen werden darf. CORBA dagegen kennt kein
Persistenzmodell, hat aber dagegen keine Entschränkung beim Dateisystem. Diese
Einschänkungen, bzw. Freiheiten haben schon in vielen Praxisprojekten zu einer
heterogenen Landschaft aus J2EE und CORBA Elementen geführt.




Abb.:3 Kommunikation in der Beispielanwendung. Die unterschiedlichen Farben sollen nur die zwei
unterschiedlichen Kommunikationswege des Beispiels zeigen und haben sonst keinerlei Bedeutung.




In dem folgenden Beispiel wird der komplette Sourcecode aller drei beteiligten
Applikationen gezeigt. Die von den unterschiedlichen Compilern generierten
Sourcecodes wurden allerdings aus Platzgründen weggelassen.
Definition der Schnittstellen
Als erstes müssen die Schnittstellen der beiden Server definiert werden. Dazu benötigt
man die IDL (CORBA) Definition des DateiAblage-Servers und das Home- und Remote
Interface (EJB) des DatenbankAblage-Servers. In jedem Interface sind zwei Methoden
definiert. „speichereDaten“ für den Zugriff vom .NET Client und
„speichereDatenInternal“ für den Zugriff der Server untereinander.


IDL Schnittstelle des CORBA Servers:

       module integrationtest {

         exception SpeicherException {};
         typedef sequence<octet> TestDaten;

         interface DateiAblage {
           string speichereDaten(in string id, in TestDaten data)
                  raises (SpeicherException);
           string speichereDatenInternal(in string id, in TestDaten data)
                  raises (SpeicherException);
         };
       };




Remote Schnittstelle des Beispiel-EJBs:

       package integrationtest.ejb;

       public interface DatenbankAblage extends javax.ejb.EJBObject
       {
         public String speichereDaten(String id, byte[] daten)
                       throws RemoteException,integrationtest.ejb.SpeicherException;
         public String speichereDatenInternal(String id, byte[] daten)
                       throws RemoteException,integrationtest.ejb.SpeicherException;
       }


Home Schnittstelle des Beispiel-EJBs:
       package integrationtest.ejb;

       public interface DatenbankAblageHome extends javax.ejb.EJBHome {
         public DatenbankAblage create() throws CreateException, RemoteException;
       }




In diesem Beispiel wird bewußt auf weitere Details wie Absicherung der Zugriffrechte
durch entsprechende Sicherheitstechnologien oder aus Aufteilen in unterschiedliche
Schnittstellen für den Zugriff der Server untereinander bzw. Zugriff vom .NET Client
verzichtet. Hierbei soll ebenfalls erwähnt werden, das Borland jetzt schon über eine
einheitliche Sicherheitsinfrastruktur zwischen allen EJB Komponenten, EJB-Clients,
Java/CORBA Servern und Java/CORBA Clients besitzt. Eine entsprechende
Implementierung der Sicherheitstechnologien (CSIv2, JAAS ähnlich) für VisiBroker C++
ist bereits als TechPreview verfügbar und eine Portierung auf C# für eine spätere Version
von Janeva geplant, so das nicht nur eine einheitliche Kommunikationsplattform, sondern
auch eine einheitliche Sicherheits- und Transaktionsplattform für die gesamte Borland
Middleware zur Verfügung stehen wird. Für eine asynchrone Kommunikation wird
ebenfalls der Borland CORBA-Notifcationservice auf allen Plattformen verfügbar sein,
da dieser auch in den J2EE Server (Borland Enterprise Server) von Borland integriert ist.




Implementierung des EJBs des DatenbankAblage-Server:
Bei dieser Implementierung ist besonders auf die ejbCreate() Methode zu achten. Hier
sieht man, das die standard J2EE Funktionen (lookup, PortableRemoteObject.narrow)
auch dazu benutzt werden um eine Referenz auf einen CORBA Server zu bekommen.
Daher kann man (außer duch die Namenswahl) nicht zwischen dem Zugriff auf ein
anderes EJB und den Zugriff auf einem CORBA Server unterscheiden. Durch RMI/IIOP
werden beide Zuriffe identisch behandelt.

       package integrationtest.ejb;

       public class DatenbankAblageBean implements SessionBean {
         SessionContext sessionContext;

         DateiAblage myCORBAService = null;

         public void ejbCreate() throws CreateException
         {
           try {
             InitialContext ctx = new InitialContext();
             myCORBAService = (DateiAblage)
                 PortableRemoteObject.narrow(
                          ctx.lookup("DateiAblage"),
                          DateiAblage.class);
           }
           catch (Exception ex) {
             throw new EJBException(ex);
           }
         }

         public String speichereDaten(String id, byte[] daten)
             throws integrationtest.ejb.SpeicherException
         {
           try {
             return
                 speichereDatenInternal(id,daten) +
                 myCORBAService.speichereDatenInternal(id, daten);
           }
           catch (Exception ex) {
             throw new integrationtest.ejb.SpeicherException(ex.getMessage());
           }
         }


         public String speichereDatenInternal(String id, byte[] daten)
             throws integrationtest.ejb.SpeicherException
         {
             return "Daten mit ID:" + id + " in der Datenbank gespeichert !\n" ;
         }


       < andere EJB Methoden ... >
       }




Implementierung des DateiAblage-Servers (CORBA Server):
Bei dieser Implementierung ist besonders auf den Konstruktor des Servant zu achten.
Hier sieht man, das die standard CORBA Funktionen (resolve,narrow) auch dazu benutzt
werden um eine Referenz auf ein EJB Home Objekt zu bekommen. Daher kann man
(außer duch die Namenswahl) nicht zwischen dem Zugriff auf ein EJB und den Zugriff
auf einen anderen CORBA Server unterscheiden.

       package integrationtest.corba;

       public class DateiAblageImpl extends DateiAblagePOA
       {
         DatenbankAblage mySession = null;

           public DateiAblageImpl(NamingContextExt root)
           {
             try {
               // Get DatenbankAblage Home Object and cast it
               Object mObj =
                   root.resolve(root.to_name("DatenbankAblage"));

                 DatenbankAblageHome datenbankAblageHome
                     = DatenbankAblageHomeHelper.narrow(mObj);

                 mySession = datenbankAblageHome.create();
               }
               catch (Exception ex) {
                 ex.printStackTrace();
               }
           }

           public String speichereDaten (String id,
                                         byte[] daten)
                         throws integrationtest.SpeicherException
           {
             try {
               return
                   speichereDatenInternal(id,daten)+
                   mySession.speichereDatenInternal(id,daten);
             }
             catch (Exception ex) {
               throw new integrationtest.SpeicherException(ex.getMessage());
             }

           }

           public String speichereDatenInternal (String id,
                                         byte[] daten)
                         throws integrationtest.SpeicherException
           {
               return "Daten mit ID:"+id+" auf Datenträger gespeichert !\n";
           }
       }


Zusätzlich zu dem Servant muss der eigentliche CORBA Serverprozess entwickelt
werden. Dies ist lediglich die Initialisierung des ORBs, der Zugriff auf den
Namingservice and anlegen und aktivieren des Servants und dessen Eintrag in den
Namingservice. Dieser Sourcecode ist nur der zur Vollständigkeit hier mit aufgelistet:
       package integrationtest.corba;

       public class DateiAblageServer     {

           public static void main(String[] args) {
             try {
               ORB orb = ORB.init(args,null);
               POA root_poa = POAHelper.narrow(
               orb.resolve_initial_references("RootPOA"));

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

                 // Create
                 DateiAblageImpl myService = new DateiAblageImpl(root);
                 root_poa.activate_object(myService);

                 // Register in NamingService
                 root.rebind(root.to_name("DateiAblage"),myService._this());

                 root_poa.the_POAManager().activate();
                 System.out.println("Server ready ...");
                 orb.run();
               }
               catch (Exception ex) {
                  ex.printStackTrace();
               }
           }
       }




Implementierung des .NET Clients mit Zugriff auf beide Server
Dieser Sourcecode ist der einzige Codeblock in C# und zeigt daher die Benutzung von
Janeva in .NET. Alle vorherigen Codebeispiele waren in Java geschrieben. Nach der
Initialisierung des ORBs kann die benötigte Referenz auf den Namingservice aufgelöst
werden. Dazu gibt es mehrere Möglichkeiten. Eine davon (IOR) wird in diesem Beispiel
verwendet.

Danach ist für beide Beispiele (CORBA Zugriff und EJB Zugriff) das gleiche Vorgehen.
Referenz vom Namingservice abfragen, umwandeln und dann auf dieses Objekt
zugreifen. Im Falls von EJBs muss natürlich erst vom gefunden Home-Objekt mittels
„create()“ eine Referenz auf eine EJB Instanz (Zugriff über das Remote Interface) erzeugt
werden. Dieses Designpattern (Factory) ist auch bei CORBA Servern weit verbeitet.

Das Beispiel zeigt ebenfalls, wie aus beiden Welten (CORBA und EJB) u.U. auftretende
Benutzerexceptions (hier SpeicherException genannt) gefangen werden können.

Ich möchte hier noch einmal darauf hinweisen, das dieser Code in C# geschrieben wurde
und das auch Janeva primär C# code erzeugt. Selbstverständlich kann das unten
abgebildete Beispiel in allen unterstützen .NET Sprachen geschrieben werden. Dazu
müssen lediglich die von den Compilern generierten Klassen in C# kompiliert und als
Assembly verpackt zur Verfügung gestellt werden.
Um genauer unterscheiden zu können, was CORBA und was EJB Zugriffe sind, wurde in
dem Beispiel auf ein „using“ für den EJB Namensraum verzichtet und bei EJBs immer
der komplette Namensraum angegeben.

      using System;
      using CosNaming;
      using integrationtest;

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

             // Obtain the root context.
             CORBA.Object rootObj = orb.StringToObject("IOR:000000000000…….0000");

             NamingContextExt root = NamingContextExtHelper.Narrow(rootObj);


              // ****   Der erste Teil ist ein Zugriff auf ein CORBA Objekt ! ********


             CORBA.Object mgrObj = root.Resolve(root.ToName("DateiAblage"));
             DateiAblage meinAblage = DateiAblageHelper.Narrow(mgrObj);

             try
             {
                // call CORBA Server
                Console.WriteLine(meinAblage.SpeichereDaten("mein Daten", new byte[0]));

             }
             catch (SpeicherException e_speicher)
             {
                     Console.WriteLine("Achtung CORBA User-Exception gefangen !!");
                     Console.WriteLine(e_speicher);
             }


              // ******    Der zweite Teil ist ein Zugriff auf ein EJB ! *********

             new integrationtest.ejb.SpeicherExceptionValueFactory();
             CORBA.Object homeObj = root.Resolve(root.ToName("DatenbankAblage"));

             integrationtest.ejb.DatenbankAblageHome myHome =
                   integrationtest.ejb.DatenbankAblageHomeHelper.Narrow(homeObj);

             integrationtest.ejb.DatenbankAblage mySession = myHome.Create();

             try
             {
                // Call EJB
                Console.WriteLine(mySession.SpeichereDaten(
                                 "mein EJB Daten", new byte[0]));
             }
             catch (integrationtest.ejb.SpeicherException e_speicher) {
                Console.WriteLine("Achtung EJB User-Exception gefangen !!");
                Console.WriteLine(e_speicher);
             }
            }
            catch (SpeicherException e_speicher) {
              Console.WriteLine("Achtung User-Exception gefangen !!");
              Console.WriteLine(e_speicher);
            }
            catch (Exception e) {
                       Console.WriteLine(e);
                   }
               }
           }
       }




Weitere Integrationsmöglichkeiten mit Janeva
Das Beispiel in diesem Artikel zeigt deutlich, wie einfach und transparent sich diese
Welten integrieren lassen. In diesem Beispiel wurden J2EE und CORBA Zugriffe
dargestellt. Eine weitere mögliche Kombination besteht ebenfalls von .NET (client) nach
Delphi, da auch eine VisiBroker Implementierung für die Delphi Entwicklungsumgebung
zur Verfügung steht.

Zur Zeit können mit Janeva keine .NET-Server geschrieben werden (zukünftiges
Release). Selbstverständlich können aber WebServices eingesetzt werden um von J2EE
und CORBA zurück nach .NET zu kommunizieren. Eine zukünftige Version von Janeva
wird auch serverseitige CORBA-Komponenten in .NET möglich machen.




Borland Enterprise Server
Die J2EE und CORBA Server in diesem Artikel wurden mit dem Borland Enterprise
Server 5.2 entwickelt und getestet. Der in diesem Artikel abgedruckte serverseitige
Sourcecode enthält keinerlei Borland spezifischen Code und sollte daher auf allen
standardkonformen ApplicationServern bzw. ORBs laufen. Aufgrund seiner CORBA
Architektur ist der Borland Enterprise Server jedoch bestens für derartige Integrationen
geeignet. Die durchgängige Security-Infrastruktur und die Firewallunterstütung durch
den GIOP-Firewallproxy Gatekeeper sowie stabile und performante Enterpriseservices
wie der Naming- und der Notificationservice, die alle auf der selben CORBA
Infrastruktur aufgesetzt sind erleichtern und vereinfachen die Integration der
unterschiedlichen Welten sehr und machen jegliche Brückenprodukte überflüssig.
Zusammenfassung
Dieser Artikel soll zeigen, das .NET , J2EE und CORBA keineswegs nur konkurrierende
Systeme sind. Zweifelsfrei gibt es etliche Überschneidungen aber trotzdem wird es in der
Industrie sehr oft zu heterogenen Landschaften kommen. Daher bietet diese Art der
Integration eine Möglichkeit eine sehr einfache und natürlich Integration der
verschiedenen Welten zu schaffen, die noch dazu eine sehr transparente Programmierung
auf allen Seiten ermöglicht. CORBA bietet darüberhinaus eine sichere und performantere
Kommunikation als es WebServices ermöglichen. Zweifelsfrei kann diese Möglichkeit
nicht überall eingesetzt werden (siehe z.B. Internet) aber durch ausgereifte CORBA
Technologie (VisiBroker bietet u.a. auch einen OMG-FirewallProxy) kann diese
Technologie in vielen Fällen eine problemlose Integration erfüllen und eine heterogene
Systemlandschaft möglich machen.

Der vorliegende Artikel wurde mit einem Beta-Release von Janeva und dem Borland
Enterprise Server 5.2 entwickelt und getestet.

								
To top