Von CW-Redakteur Sascha Alexander

MÜNCHEN (COMPUTERWOCHE) - Java-Applikations-Server mausern sich zu einer der wichtigsten Technologie- und Integrationsplattformen in Unternehmen. Sie orientieren sich an den Spezifikationen der Java 2 Enterprise Edition (J2EE) und bieten ganz allgemein Werkzeuge, eine laut Hersteller leistungsstarke, skalierbare Ablaufumgebung für Java-Komponenten sowie Schnittstellen für diverse Integrationsaufgaben. Sie ermöglichen die einheitliche Verwendung einer Programmiersprache, bieten eine gute Web-Unterstüzung, umfangreiche Bibliotheken und Java-Frameworks (z.B. JWAM). Der Server übernimmt zudem Aufgaben wie Failover, Lastverteilung, Transaktionssicherheit, Clustering und das Pooling von Datenbankverbindungen.

Anbieter wie IBM, Bea Systems, Sun/IPlanet, Iona, Borland, Oracle oder Silverstream nutzen mittlerweile das Komponentenmodell Enterprise Javabeans (EJB). Dieses bildet den Kern von J2EE und ermöglicht, innerhalb einer verteilten objektorientierten Umgebung selbst entwickelte oder zugekaufte Serverbausteine (Geschäftslogik) für die Entwicklung oder Integration bestehender Anwendungen innerhalb eines "Containers" zu nutzen. Wichtige, obligatorische J2EE-Technologien sind unter anderem Java Naming und Directory Interface (JNDI), Java Database Connectivity (JDBC), Java Servlets, Java Server Pages (JSP), Java Transaction API (JTA), Java Transaction Service (JTS), Java Messaging Service (JMS) sowie Remote Method Invocation (RMI).

Im Projektalltag müssen Anwender beim Einsatz von App-Servern und Java-Technologie allerdings viele technische und organisatorische Hürden nehmen, um der erhofften integrierten, komponentenbasierten IT-Architektur tatsächlich näher zu kommen. Zu den schwierigsten und zugleich wichtigsten Aspekten zählt dabei laut einhelliger Meinung von Analysten und Praktikern die Produktauswahl. Zwar hat sich der Markt in den letzten zwei Jahren erheblich konsolidiert, und immer mehr Server unterstützen J2EE. Aber der Standard ist trotz höherer Stabilität weiter im Fluss (J2EE 1.3 steht kurz vor der Freigabe); die Produkte sind nicht identisch und werden insbesondere aus Gründen des Marketings und der Diversifizierung immer vielfältiger. So haben Hersteller wie Bea Systems, IBM, Iplanet, Iona und andere die Server mittlerweile um Funktionen für E-Commerce und die Kundenverwaltung erweitert. Außerdem laufen Arbeiten etwa am Channeling für Mobile Computing, der Steuerung von Geschäftsprozessen über ein Control-Flow-Framework und der bisher rudimentären XML-Unterstützung.

Uta Pollmann, Beraterin im Bereich E-Business bei der Systor GmbH in Köln, rät in dieser schwierigen Situation dringend dazu, sich nicht auf Marketing-Broschüren zu verlassen, sondern selbst zu evaluieren. Dabei sollte der Anwender gemeinsam mit dem Hersteller oder anderen Experten einen Prototyp installieren und konfigurieren, der inklusive Lasttests ein für das eigene Unternehmen relevantes Anwendungsszenario abbildet. Pollmanns Kollege Gernot Starke empfiehlt Anwendern, dass sie wichtige fachliche Fälle wählen, Anforderungen wie Skalierbarkeit, Security festlegen und den Piloten am besten gemeinsam mit dem Hersteller zu implementieren. Anhand dieses einfachen Prototypen können dann weitere Aussagen über das Verhalten des Servers gemacht werden, insbesondere inwieweit er sich an die J2EE-Standards hält. Die Erfahrung hat laut Pollmann allerdings gezeigt, dass sich praktisch mehr als bis drei Produkte nicht parallel prüfen lassen.

Klare Strategie gefragt

Unternehmen müssten sich vorab auch darüber im Klaren sein, wofür sie die Anwendungen einsetzen wollen. Geht es um B2B oder B2C (Business-to-Business/Consumer)? Oder soll die gesamte bisherige OO-Anwendungsentwicklung auf eine Plattform gezogen werden? Ist angesichts bestehender Systemlandschaft, einschließlich der Aspekte Security, Legacy, Entwicklungsumgebung, Systems Management, eine Integration überhaupt möglich? Wichtig ist es laut Pollmann auch, zu verstehen, dass erst im Laufe der Zeit weitere Vorzüge eines App-Servers zum Tragen kommen: gute Monitoring-Möglichkeiten, Skalierung und Failover.

Neben solchen Evaluierungen hat Systor-Berater Starke in Projekten bei Großkunden zudem die Erfahrung gemacht, dass als weitere Auswahlkriterien mittlerweile nicht mehr die Lizenzkosten an erster Stelle stehen, sondern vielmehr dem Renommee, der Größe und Überlebensfähigkeit des Herstellers eine extrem hohe Bedeutung beigemessen wird. "Dafür nehmen die Kunden sogar technische Abstriche in Kauf", sagt Starke. In diesem Zusammenhang verlangten Anwender auch, dass der Hersteller "wirkliche Experten" für Beratung und Prototyping anbieten kann. Bei der Implementierung überwiegen hingegen die Bedenken, dass sie den Hersteller "nie wieder los werden" könnten. Daher würden in dieser Phase Dienstleister bevorzugt. Doch auch diese vermissen manchmal den Herstellersupport. So treten laut Hennig Wolf und Martin Lippert, Softwarearchitekten bei Apcon Workplace Solutions GmbH, in der Praxis immer wieder technische Probleme auf. "Dann ist man auf das langwierige Suchen in den entsprechenden Newsgroups angewiesen, wo sich aber im Allgemeinen sehr gute Hinweise und kompetente Kollegen finden."

Licht und Schatten der Technik

Klaus Grieger, Teamleiter beim IT-Dienstleister Itelligence und zuständig für Softwaretechnik und -entwicklung, sieht bezüglich des J2EE-Einsatzes mehr Licht als Schatten. So würden Servlets, JSPs, JNDI, JDBC und Data-Sources heute keine großen Probleme mehr bereiten, wenn etwa eine Portierung zwischen Servern anstehe. Auf seiner Wunschliste stehen vor allem bessere Entwicklungswerkzeuge, da insbesondere das Deployment und Konfigurations-Management zur Zeit noch weitgehend von Hand erledigt werden müssten.

Ebenso sei eine bessere Integration von Datenbankkonzepten wie Entity-Relationship-Design, Stored Procedures, Integritätsregeln, Zugriffsrechte etc. nützlich. Bessere Administrations-, Monitoring- sowie Tuning-Möglichkeiten der Server wären zudem ebenso nötig wie weitere und leistungsstärkere Adapter für Legacy-Systeme. Als komplexes Problem stellt sich hingegen die Entwicklung mit EJBs in der Praxis dar. Hier konkurrieren unterschiedliche EJB-Versionen (1.0, 1.1 und künftig 2.0) miteinander, und innerhalb der EJB-1.1-Spezifikationen würde das Thema Persistenz nicht ausreichend definiert. Grieger vermisst zudem Aspekte wie Relationships, komplexe Attribute, Mapping-Regeln und eine Query-Sprache. Die Folge sei, dass Hersteller für EJB 1.1 eigene proprietäre Lösungen für diese Aufgaben entwickelt hätten.

Vor allem aber streiten sich die Experten über Art und Weise der notwendigen dauerhaften Speicherung von EJB-Komponenten (Entity Beans). Laut Harmaz Mehmanesh, Geschäftsführer beim Münchner Java-Spezialisten MGM EDV-Beratung GmbH, ist die Lösung des Persistenzproblems in J2EE nicht praxistauglich. Vielmehr würden Anwender bisher ein zusätzliches Persistenz-Framework kaufen und in erster Linie nur Session Beans verwenden. Da aber Entity Beans mit Version 1.1. der EJB-Spezifikationen verpflichtend und für manche Szenarien notwendig sind, kommt auf Entwickler die Aufgabe zu, sich für die Entity Beans mit automatischer, Container-managed-Persistence (CMP) oder besser mit Bean-managed Persistence (BMP) zu entscheiden.

Im Hinblick auf die wichtigsten Trends im J2EE-Umfeld sollten Anwender sich insbesondere mit dem Thema Messaging auseinander setzen und Server-Hersteller danach fragen. So werden in den für dieses Jahr erwarteten EJB-Spezifikationen 2.0 mit Hilfe der neuen "Message Driven Beans"(MDS) erstmals asynchrone Methodenaufrufe mit Hilfe des JMS-APIs möglich. Clients stellen dabei ihre Nachricht in eine Warteschlange, für die der EJB-Server als Subscriber registriert ist. Die MDS arbeiten dann die Requests ab und rufen dabei die On-Message-Methode auf. Die Clients müssen dabei nicht wie bisher bei synchronen Verbindungen auf Antwort warten. Systor-Expertin Pollmann ist allerdings noch kein Projekt begegnet, in dem der Anwender nicht auch mit synchronen Mechanismen auskam. "Aber in anderen Projekten gibt es bestimmt sinnvolle Anwendungsfälle", räumt sie ein. MGM-Chef Mehmanesh weist darauf hin, dass die JMS-Erweiterungen auf Wunsch von Anwendern in die EJB-Spezifikationen aufgenommen wurden und der EJB-Server künftig als Basisplattform vergleichbarer Messaging-Produkte für Enterprise Application Integration fungieren könnte.

Ebenso bedeutsam könnten auch die J2EE-Spezifikation Java Connectors Architecture (JCA) werden. Sie verspricht vom Konzept her eine JDBC vergleichbare standardisierte Integration beispielsweise von SAP R/3, Legacy-Anwendungen oder CRM-Produkten. Hier melden Hersteller wie Borland oder Bea Systems bereits heute ihre Unterstützung an.

Warten auf Standardadapter

Allerdings sind Systor-Beraterin Pollmann und andere Praktiker derzeit noch skeptisch bezüglich JCA, da deren Erfolg von der Unterstützung durch die Standardsoftwarehersteller abhängt, die ihrerseits eine JCA-konforme API publizieren müssen. "Wenn dazu in größerem Maße Aufrüstungen der Host-Systeme (neues IMS/CICS, neues OS) notwendig sind, werden Anwender auf die JCA-Vorteile wie Transaktion, Security verzichten und sowieso weiter Adapterlösungen einsetzen."

Schließlich werden so genannte Web-Services in absehbarer Zeit die gesamte Java-Entwicklung beschäftigen. Anwender sollten sich deshalb mit dem Thema beschäftigen und beispielsweise mit Toolkits, wie sie etwa IBM und Borland bereits anbieten, experimentieren. Einfach gesagt, verheißen solche Dienste einen standardisierten Weg, über den Programme/Komponenten mit Hilfe von Standardprotokollen und festgelegten Nachrichtenformaten untereinander bestimmte Dienste etwa über das Internet veröffentlichen und nutzen können. Zwar folgt J2EE einem zunächst ähnlichen Konzept, in dem JNDI ein Directory mit Business Services bietet, während RMI/EJB und JMS für den Aufruf solcher Dienste genutzt werden könnten. Der Unterschied ist aber der, dass dies nur zwischen Java-Programmen funktioniert, während Web Services von einem beliebigen Client über das Simple Object Access Protocol (SOAP) erreichbar sein werden. Erste Vorschläge für neue Java-Schnittstellen zu den Web-Services wurden zudem dieser Tage in den Standardisierungsprozess eingereicht.

WEB-SERVICES

Dem Java Community Process liegt seit kurzem der Vorschlag eines Java API´s for XML based Remote Procedure Call (RPC) vor. Kombiniert mit dem Vorschlag eines "Java API for XML Registries" (JAXR) und dem schon etwas älteren "Java API for XML Messaging" (JAXM) sind es die ersten Schritte, um J2EE Web-Services zu spezifizieren. JAXR soll ein Standard-API liefern, über das Java-Anwendungen mit neuen Initiativen für den Aufbau einer Web-Services-Infrastruktur wie UDDI und ebXML kommunizieren können. Programmierer erhalten die Möglichkeit, entfernte Dienste aufzufinden, deren Web-Adresse zu erhalten sowie aufzurufen, ohne dass JNDI notwendig ist. JAXM definiert eine Java-API, die speziell auf ebXML abgestimmt ist, das von manchen Beobachtern als der Nachfolger für EDI-Messaging betrachtet wird.

JAXM soll wie JMS genutzt werden und den automatisierten Empfang und das Versenden von XML-Nachrichten (ebXML-Dokument) über HTTP erlauben. Die Kombination aus JAXR für die Service-Suche und JAXM für asynchrone Aufrufe könnten J2EE-Entwickler in die Lage versetzen, Anwendungen für Web-Services zu erstellen, die vergleichbar traditioneller Message-oriented Middleware (MOM) arbeiten. Das Java API for XML RPC (JAX RPC) wird hierbei für die standardisierte Interoperabilität zwischen SOAP und den neuen W3C XP-Protokoll sorgen. Vergleichbar mit EJB, wird es einem Rechner ermöglichen, Methoden und Prozeduren synchron über das Internet aufzurufen und XML-Dokumente über HTTP zu verschicken.

Mit JAX-RPC steht eine Schnittstelle zur Verfügung, mit der sich die Methoden einer so genannte Stateless Session Bean als synchrone Prozedur von einem beliebigen Client (VB, Perl, C# etc.) aufrufen lassen wird. Ebenso wird jede beliebige verteilte Anwendungsplattform, die einen Web-Service anbietet, über JAXR zu finden und über JAX-RPC aufrufbar sein.

Während Gernot Starke nach ersten Experimenten über die einfache Handhabung von SOAP und der Entwicklung von Web-Services (in diesem Fall auf Basis von EJB) über deren Einfachheit begeistert ist, ist seine Kollegin Pollmann derzeit noch skeptisch. Zwar sei es sinnvoll, interne Funktionen zu entkoppeln, um sie einem Business-Partner anbieten zu können, ohne ihm Kenntnis über die interne Struktur der Anwendung geben zu müssen. "Aber diese Diskussion hatte man ja früher schon mal mit Corba als Integrationsplattform und IDL für die syntaktische Beschreibung der Schnittstellen", meint Pollmann. Dennoch rechnet sie mit entsprechenden Web-Service-Modulen als Aufsatz, der wie ein Dispatcher (Servlet) auf dem Web-Server laufen könnte. "Der App-Server wird dadurch aber nichts an seiner Wichtigkeit für die Anwendungsintegration verlieren."

Strategische Entscheidungen stehen an

Die hier vorgestellten technischen Aspekte zu J2EE und dem Applikations-Server zeigen, welche Herkulesaufgabe auf die Anwender wartet. Ein pragmatisches Vorgehen mit Prototypen, wie oben geschildert, wird deshalb von Java-Experten favorisiert. Allerdings haben eine Reihe von EJB-Anwendungen trotz viele Probleme im Detail die Pilotphase bereits hinter sich. So beobachtet Andrew Parker, Senior Analyst bei Forrester, dass sich derzeit strategische Produktentscheidungen bei den Unternehmen anbahnen: "App-Server werden jetzt als Framework für strategische E-Business-Anwendungen ausgewählt, denn sie sind absolut zentral, um zu einer effizienten Architektur zu kommen. Bei Firmen mit weiter fortgeschrittenen Plänen in Deutschland und Großbritannien beobachten wir, dass dabei vor allem Produkte von IBM und Bea für die kritischen Anwendungen gewählt werden. Daneben wird aber auch Microsoft-Technologie in einzelnen Abteilungen und/oder Anwendungen mit weniger Netzverkehr implementiert."

BEISPIEL

Lars Rosenberg, Chefarchitekt beim Reisedienstleister Start/Amadeus, berichtet von den Plänen mit Java in seinem Unternehmen:

Die Architektur unserer Website wurde 1999 auf eine hauptsächlich Servlet-basierte Architektur umgestellt. Diese migrieren wir derzeit vom "Oracle Application Server" zum Servlet-Container "Tomcat". Grund für den Umstieg sind unnötig hohe Lizenzkosten und Performance-Probleme. Auch gab es am Anfang Schwierigkeiten bei der Integration mit dem "Apache"-Web-Server, da ihn Oracle nicht unterstützte.

Parallel zu den Websites bauen wir derzeit eine Integrationsarchitektur mit Hilfe von "Bea Weblogic Enterprise" (WLE) auf, die in Produktion die Echtzeit-nahe Kommunikation mit maximal 50 000 Clients in der Endausbaustufe handhaben soll. Bisher ist hier der Transaktionsmonitor "Tuxedo" im Einsatz. Die Integrations-Lösung soll hauptsächlich auf WLE aufsetzen und sowohl Corba- als auch Java-Technologie nutzen.

Mit EJBs haben wir bisher nur in ersten Tests gearbeitet, da wir derzeit mehr mit der Integration bestehender Anwendungen und neuen Frontends beschäftigt sind und weniger mit der Entwicklung von zusätzlicher Geschäftslogik. Im nächsten Jahr könnte sich das aber ändern. Wir interessieren uns auch für SOAP, da wir eine Nachrichten-blasierte Architektur haben.

Anwendungen für die Personalisierung oder Portalsoftware sind ebenfalls von Interesse für uns. Wir befinden uns aber momentan noch in der Evaluierung und haben uns bisher nicht entschieden, ob wir ein Portal auf Basis der Middleware entwickeln oder ein fertiges Produkt kaufen. Bei der Umsetzung werden wir damit beginnen, einfache Funktionen zu implementieren, etwa solche, die Kunden zum Beispiel die Einsicht in unsere kundenspezifische Daten über das Web erlauben. In der Endausbaustufe wollen wir dann das Portal zur Schnittstelle für unsere Anwendungen machen. Was den Einsatz von zugekauften Erb-Klassen betrifft (Beispiel Bea Commerce Server), um etwa E-Commerce-Anwendungen aufzubauen, so wird der Einsatz bei uns von Fall zu Fall auf Funktionalität geprüft.