Nahtlose Integration von J2EE, CORBA und.net

Transkript

1 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.

2 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

3 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 EJB 1 EJB 2 Obj 1 Obj 2.NET Runtime ASP.NET Runtime J2EE Server CORBA 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.

4 J2EE Server Environment C# Client Ease-of-Use Layer Raw Stub Layer.NET Runtime Janeva Runtime Naming Service Transaction Service EJB Container 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.

5 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.

6 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

7 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... >

8 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:

9 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.

10 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: "); 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)

11 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.

12 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.