java enterprise

java enterprise
Java EE-Anwendungsmigration
Java EE-Anwendungsmigration auf den SAP Web AS, Teil 1
Der Mythos von „Write
Once – Run Anywhere“
von helge martin und dr. halil-cem gürsoy
Von SAP als die Integrationsplattform zur Realisierung von serviceorientierten Architekturen (SOA) beworben, offeriert NetWeaver mit dem kombinierten Java EE/ABAP Stack sowohl einen unkomplizierten Zugriff
auf ABAP-Funktionen als auch deren nahtlose Integration in einen J2EE 1.3-zertifizierten Container. Eine
interessante Option für viele Unternehmen einer ohnehin breiten ERP-Kundenbasis, ihre bestehende Java EEApplikationslandschaft im Zeichen einer allgemeinen Konsolidierungswelle auf den SAP Web AS zu migrieren.
Die Szenarien für den Einsatz der NetWeaver-Plattform sind so unterschiedlich
und vielfältig wie die Unternehmen selbst.
Generelles Ziel ist es, die Produkt- bzw.
Herstellervielfalt sowie die Anzahl der
Serverinstanzen in einer heterogenen
Landschaft zu minimieren. Abbildung
1 beschreibt ein mögliches Szenario für
die schrittweise Einführung der NetWeaver-Plattform. Hier wird langfristig eine
komplette Abdeckung der Betriebsanforderungen durch die NetWeaver-Komponenten Enterprise Portal und Exchange
Infrastructure angestrebt. Die Konsolidierung der Application Server stellt hierfür den ersten wichtigen Schritt dar.
Nach allen strategischen Managemententscheidungen rund um die Total
Cost of Ownership und den Return on
Investment, muss die Java EE-Unternehmenssoftware nach theoretischen Überlegungen letztlich auf eine neue Java EEPlattform umziehen.
Viele IT-Abteilungen stellt dies vor
erhebliche, oftmals neue Herausforderungen und für viele Entwickler, Projektmanager und CIOs hat sich der schöne
Schein einer standardisierten „Write
Once – Run Anywhere“-Java EE-Welt
zum ersten Mal in einem Java EE-Migra-
46
3.2006
tionsprojekt getrübt. Denn neben den organisatorischen Hürden liegen die maßgeblichen Herausforderungen der technischen Java EE-Anwendungsmigration
im Spannungsfeld zwischen spezifikationstreuer Implementierung der Applikation und der Umsetzung der Java EE-Spezifikationen auf der Zielplattform.
In diesem Artikel wollen wir die Migra
tionsfreudigkeit des SAP Web AS genauer
unter die Lupe nehmen und die wichtigsten, immer wiederkehrenden technischen
und organisatorischen Erfahrungen mit
Java EE-Migrationsprojekten vorstellen.
Nach der Migration der bestehenden
Java EE-Anwendungen bleibt das Rad
aber nicht stehen. Welche Implikationen
der Umstieg auf NetWeaver und den Web
AS für die Entwicklung neuer Java EEAnwendungen hat, ist Thema des nächsten Teils der Migrationsserie. Unter dem
Motto „Prozessmigration“ widmen wir
uns dann den von SAP bereitgestellten
Konzepten und Technologien zur Unterstützung des Entwicklungsprozesses.
Der Weg ist das Ziel
Der Umstieg auf eine neue Plattform wie
NetWeaver ist für ein Unternehmen eine
Abb. 1: NetWeaver als Integrationsplattform
www.javamagazin.de
java enterprise
Java EE-Anwendungsmigration
Aufgabe mit vielen strategischen Implikationen. Java EE-Migrationsprojekte
stellen hierbei einen erfolgskritischen
und oftmals unterschätzten Faktor dar.
Größere organisatorische und finanzielle Aufwände für ein Migrationsprojekt
lassen sich zudem oftmals schlecht an die
Geschäftsführung kommunizieren. Hat
das Unternehmen doch erst vor kurzem
auf aktuelle Java EE-Technologien gesetzt und in diesem Rahmen hohe Investitionen in Hard- und Software sowie in
das Know-how der Mitarbeiter getätigt.
Ebenso wird die Portabilität der Java
EE-Technologie und die suggerierte Produkt- und Herstellerunabhängigkeit bei
der Entscheidung seiner Zeit sicherlich
eines der führenden Argumente gewesen
sein.
Um ein tragfähiges Vorgehen entwickeln zu können, das dann sowohl die
technischen und fachlichen als auch die
politischen, organisatorischen und strategischen Anforderungen des Unternehmens abbildet, muss zunächst ein grundlegendes Verständnis für die Dimensionen
des individuellen Migrationsprojekts aufgebaut werden.
Die Migration von Unternehmenssoftware auf eine neue Java EE-Plattform
umfasst in der Regel die sukzessive Mi
gration mehrer, zumeist interagierender
Anwendungen und Komponenten mit
unterschiedlicher Nähe zur Wertschöpfungskette des Unternehmens. Hierdurch
können ohne weiteres „Mission Critical“-Szenarien entstehen, die unter hohem Erfolgsdruck stehen.
Die Abhängigkeiten zwischen einzelnen Anwendungen und Komponenten
stellen somit also auch fachliche und organisatorische Abhängigkeiten zwischen
den verschieden Ebenen und Bereichen
eines Unternehmens dar. Neben der technischen Analyse dient deshalb auch die
genaue Analyse des Projektumfelds dazu, einen klar kommunizierbaren Migra
tionspfad zu entwickeln, um bestenfalls
alle Beteiligten an einem Strang ziehen zu
lassen.
Im Folgenden wollen wir uns auf die
konkreten Projektphasen und auf die
technischen Aspekte konzentrieren. Die
Abbildung 2 zeigt schematisch die grundsätzlichen
www.javamagazin.de
Abb. 2: Projektphasen
Phasen eines typischen Migrationsprojekts.
Pilot gesucht
Da bei einer Plattformumstellung häufig
mehrere Anwendungen auf die Zielplatt-
form migriert werden sollen, hat ein Pilotprojekt wichtige Funktionen innerhalb
komplexer Migrationsvorhaben. Neben
dem Sammeln von Erfahrungen im Umgang mit der Zielplattform werden in
einem abgesteckten Zeitrahmen auch der
NetWeaver und Web Application Server
Als strategische Technologieplattform der SAP ist NetWeaver die Basis für die Entwicklung aktueller
und kommender SAP-Lösungen und die Integration existierender Anwendungen. Dem aktuellen
Trend hin zu SOA folgend, liefert SAP mit NetWeaver eine komplette Tool-Palette (NWDS; WebDynpro) und mit der Enterprise Service Architecture (ESA) die entsprechenden Blueprints. Die folgende
Abbildung gibt einen Überblick über die fachlichen Komponenten der NetWeaver-Technologieplattform zur Umsetzung von Portal-, Informations- und Prozessintegrationslösungen.
NetWeaver und
Web AS
Der Web AS repräsentiert die Applikationsplattform im NetWeaver-Komponentenmodell. Der kombinierte Java EE/ABAP Stack des Web AS ermöglicht es, Business-Objekte sowohl in ABAP als auch
in Java zu implementieren oder bereits existierende Geschäftslogik aus beiden parallel zu betreiben.
Der Web AS stellt die zugrunde liegende Infrastruktur für Produkte wie SAP R/3 Enterprise, mySAP
ERP, SAP Enterprise Portal, SAP Exchange Infrastructure dar.
Der zurzeit aktuelle und bereits weit verbreitete SAP Web AS 6.40 ist J2EE 1.3-konform. Die für das
Frühjahr 2006 angekündigte Version 7.x des Web AS wird den J2EE 1.4-Standard erfüllen. Tabelle 1
gibt Aufschluss über die Versionshistorie des SAP Web AS.
Version
Java EE-Konformität
Key Features
6.10
Nur ABAP
Nativer HTTP- und XML-Support
6.20
J2EE 1.2
Kombinierter Java EE/ABAP Stack; JSP und BSP; Web
Services (WSDL, SOAP, UDDI)
6.30
J2EE 1.3
6.40
J2EE 1.3
7.x
J2EE 1.4
Software Lifecycle Management; ABAP-Erweiterungen
Versionshistorie SAP Web AS
3.2006
47
java enterprise
Java EE-Anwendungsmigration
Abb. 3: Pilotprojekt –
Komponentenmodell
Szenario anhand der einzelnen Phasen
des Migrationsprozesses das technische
Vorgehen einer Java EE-Anwendungsmigration auf den Web AS vorgestellt
werden. In unserem Beispiel soll eine Java
EE-Anwendung von einem WebLogic Application Server auf den Web AS migriert
werden (Abb. 3).
Einen Ausgangspunkt definieren
Aufbau des Migrationsumfelds und insbesondere der zukünftigen Entwicklungsumgebung vorangetrieben. Dazu sollte
am besten eine möglichst repräsentative
Applikation als Migrationskandidat mit
einer durchschnittlichen Anzahl an technischen und fachlichen Schnittstellen
gewählt werden, um technische und organisatorische Stolperfallen in Hinblick auf
Folgemigrationen zu identifizieren. Ziel
ist ein ohne viele Anpassungen reproduzierbarer Migrationsprozess.
Aus projektorganisatorischer Sicht
gehört solch eine initiale Migration einer
Anwendung also mit in die Planungs- und
Analysephase und kann als Proof of Concept betrachtet werden. Die Retrospektive
auf ein Pilotprojekt ermöglicht neben der
Optimierung des Vorgehens konkretere
Aufwandsschätzungen für die anstehenden Folgemigrationen. Aufwände für den
Wissensaufbau bei den eigenen Mitarbeitern können in einem Pilotprojekt auch
übersichtlich gekapselt werden.
Ist erst einmal ein idealer Migrationskandidat ausgemacht, kann mit der technischen Migration begonnen werden.
Im Folgenden soll mit einem typischen
Sun Application Verification Kit
Das AVK ist eine Sammlung von Tools, die es
dem Entwickler erleichtern, spezifikationstreue
Java EE-Anwendungen zu entwickeln. Das AVK
prüft eine Applikation und ihre einzelnen Komponenten in statischen und dynamischen Tests.
Über die Kompilierbarkeit hinaus prüfen die statischen Tests auf ein konformes Packaging und
die Existenz proprietärer Bibliotheken auf Basis
von Deskriptoren- und Code-Scans. Darüber hi
naus wird die web.xml der Webkomponente auf
vollständige Servlet Mappings untersucht. Für
die dynamischen, sprich Laufzeittests bringt das
AVK eine um Test-Tools erweiterte Referenzimplementierung des Sun Application Server mit.
•Static Archive Test: überprüft die Java EEKonformität des Packaging der Komponenten.
•Introspection: erstellt eine Liste aller öffentlichen Methoden der Bean Interfaces sowie
ihrer Create- und Remove-Methoden und bemängelt fehlende oder fehlerhafte Methoden-
48
3.2006
signaturen. Aus den Einträgen in ejb-jar.xml
und web.xml werden eine weitere Liste aller
EJB- und Webkomponenten generiert und das
Vorhandensein der deklarierten Komponenten
geprüft.
•Code Scan: durchsucht Quellcode und De
skriptoren nach Referenzen auf proprietäre
Bibliotheken.
•Runtime Verification: Während der Laufzeit
werden alle Aufrufe unter den Komponenten
geloggt, um die faktische Codeabdeckung zu
ermitteln.
Die Kriterien für eine erfolgreiche Verifizierung
der Java EE-Konformität erfordern, dass EJBKomponenten alle statischen und dynamischen
Tests bestehen und in den Laufzeittests eine
Codeabdeckung von 80 Prozent ohne Exceptions aufweisen. Die Webkomponenten müssen
vollständige Servlet Mappings sowie kompilierbare JSPs und Servlets aufweisen.
Eine saubere Codebasis ist die absolute
Voraussetzung für die erfolgreiche Mi
gration. Zunächst sollte die zu migrierende
Applikation im Versionsmanagement vom
aktuellen Entwicklungszweig getrennt
werden (z.B. durch Branchen unter CVS).
Von der Weiterentwicklung sollte während
der Migration abgesehen werden.
Um nach der Migration sicherstellen
zu können, dass die Anwendung im vollen
Umfang so funktioniert wie vor der Mi
gration, bietet es sich an, alle funktionalen
Tests noch einmal durchzuführen und zu
dokumentieren. Idealerweise liegt eine
hochgradige Abdeckung des Codes mithilfe von Unit-Tests vor.
Nach der Migration wird die Anwendung auf dem Zielsystem gegen die bereits
vorliegenden Ergebnisse getestet und
optimiert. Zudem solten die nichtfunk
tionalen Anforderungen umfassend dokumentiert sein, um dann die Anwendung
und Serverkonfiguration abschließend
für den produktiven Einsatz zu optimieren. Nicht zuletzt lassen sich mit einer guten Testdokumentation die oftmals zähen
Abnahmeverfahren erheblich beschleunigen beziehungsweise unnötige Diskussionen vermeiden.
Proprietäre Bibliotheken
Der stetige Ruf nach aktuellster Java EEFunktionalität und einer breiten FeaturePalette in einem zuweilen Buzzword- und
Hype-getriebenen Java EE-Markt drängt
die Serverhersteller in immer kürzere
Produktzyklen. Und während man in
diversen Konsortien, im JCP und nicht
zuletzt in der Open-Source-Community
an den Standards von morgen laboriert,
wird das eigene Produkt mit proprietären
Erweiterungen wie PK-Generatoren oder
EJB/QL-Erweiterungen garniert.
Unter dem Gesichtspunkt der Migration bekommt Kundenbindung schnell
www.javamagazin.de
java enterprise
Java EE-Anwendungsmigration
eine neue Bedeutung, denn die Implika
tionen der Nutzung herstellerspezifischer
Bibliotheken in der zu migrierenden Applikation sind als Aufwand mit zu kalkulieren. Hier stellt sich die Frage, ob die
Zielplattform das gewünschte Feature
schon bereitstellt, ob es integriert werden
kann oder ob gar eine umfangreichere Refaktorisierung einer oder mehrerer Komponenten notwendig wird.
In der Testphase empfiehlt sich daher
der Einsatz von Suns Application Verification Kit for the Enterprise (AVK) [1]. Vor
allem bei einer breiten Codebasis können
mit dem AVK die spezifikationstreue Implementierung der Anwendung, die Vollständigkeit der Komponenten sowie das
Laufzeitverhalten getestet werden (siehe
Kasten). Ob die vollständige Migration
der Anwendung auf die Sun Java EE-Referenzimplementierung zur Durchführung
der Laufzeittests immer sinnvoll ist, ist
hinsichtlich des Aufwands von Fall zu Fall
fraglich. Die einfach anzuwendenden statischen Tests sollten vor einer Migration
jedoch unbedingt durchgeführt werden.
Neben den Checks auf Spezifikationstreue und Codeabdeckung ist der Einsatz
des AVK auch nützlich, um proprietäre
Bibliotheken zu identifizieren. „Out of
the box“ erkennt das AVK proprietäre Bibliotheken von Sun One, WebLogic, Web
Sphere und JBoss. Wurde die zu migrierende Anwendung hingegen auf der Basis von
Oracles OC4J entwickelt, kann die AVKKonfiguration in der <AVK_Home>/bin/
lib/asmt-config.xml über einen kleinen
Trick wie folgt angepasst werden:
<jboss>

<supported></supported>
<unsupported>
<name>com.oracle</name>
<name>oracle.j2ee</name>
<name>com.evermind.server</name>
</unsupported>

</jboss>
Da die asmt-config.xml kein CostumElement oder Ähnliches vorsieht, müssen die Paketnamen der proprietären
Bibliotheken wie bereits gezeigt zum Beispiel in das JBoss-Element eingetragen
werden.
Entwicklungsumgebung –
von WebLogic zu NWDS
Wenn man auf eine neue Java EE-Plattform umsteigt, ändert sich in der Regel
auch die Entwicklungsumgebung. In unserem Beispielprojekt zieht die Codebasis
aus der WebLogic IDE in das NetWeaver
Developer Studio (NWDS) um. Dabei ist
es die einfachste Möglichkeit ist, wenn
man die Codebasis mittels des SAP J2EE
Migration Kit Plug-in in das NetWeaver
Developer Studio importiert.
Das Plug-in generiert alle SAP-proprietären Deskriptoren und passt die Verzeichnisstruktur den NWDS-Projekten
an. So können alle weiteren Anpassungen
und das Deployment aus dem Eclipsebasierten NWDS vorgenommen werden. Zurzeit unterstützt das Plug-in den
Anzeige
www.javamagazin.de
3.2006
49
java enterprise
Java EE-Anwendungsmigration
Import von WebSphere-, WebLogic- und
JBoss-Projekten.
Wurde die Applikation in einer anderen IDE, beispielsweise im JDeveloper,
entwickelt, müssen die Sourcen händisch
importiert werden. Diese Tätigkeit steht
leider auch dann an, wenn die Projektstruktur exotisch sein sollte oder z.B. nur
der Split Development Directory von BEA
folgt. Bei einer breiten Codebasis kann es
sich daher durchaus lohnen, einen eigenen Transformator mit XSLT-Stylesheets
zur automatisierten Anpassung der De
skriptoren zu erstellen.
Zur Migration weniger umfangreicher Applikationen bietet auch das mit
dem Web AS mitgelieferte Deploy Tool
eine durchaus brauchbare Alternative,
da es unabhängig vom NWDS ist. In der
Swing-Anwendung werden DeploymentProjekte angelegt, in denen die einzelnen
Java EE-Komponeten, wie WEB und EJB
Module, definiert und in deploybaren
EARs gepackt werden können. Alle SAPproprietären Deskriptoren werden vom
Deploy Tool generiert. Oftmals konnten
so kleinere Applikation mit nur geringen Anpassungen an den Deskriptoren
schnell migriert werden.
Web AS konfigurieren
Vor dem ersten Deployment auf den Web
AS sollten alle benötigten Konfigurationen
für JDBC und JMS Connectivity, falls vorhanden, vorgenommen werden. Die Definition des JMS-Servers und das Anlegen
von anwendungsspezifischen Connection
Factories sowie der Queues und Topics erfolgen über den JMS Provider Service im
Visual Administrator des Web AS.
Die Konfiguration von JDBC 1.1- und
2.0-(XA-)Treibern z.B. für verteilte Transaktionen kann sowohl im JDBC Connector Service über den Visual Administrator als auch über den SAP-proprietären
Deskriptor data-sources.xml geschehen,
die man zusammen mit der zugehörigen
Anwendung deployt. Die SQL Engine des
JDBC Connector Service unterstützt die
SQL-Typen OPEN_SQL, NATIVE_SQL
und VENDOR_SQL. OPEN_SQL ist ein
SAP-eigener Satz von SQL-Standardanweisungen und wird auch im ABAP-Stack
genutzt, um unabhängig vom Hersteller
auf Datenbanken zuzugreifen. Nutzt die
50
3.2006
Anwendung allerdings herstellerspezifische Schemata oder Funktionen wie zum
Beispiel Stored Procedures, muss NATIVE_SQL respektive VENDOR_SQL
gewählt werden.
Deskriptoren- und
Quellcodeanpassungen
Strukturell einfache, aus Stateless Session
Beans, JSP/Servlets und POJOs bestehende Java EE-Applikationen stellen in
der Regel keine größere technische He
rausforderung dar. Es müssen meistens
lediglich die Deskriptoren angepasst
und, wenn überhaupt, nur geringfügige
Änderungen im Code vorgenommen werden. Bei Nutzung des J2EE Migration Kit
Plug-in werden die meisten Anpassungen
in den Deployment-Deskriptoren automatisch erledigt.
Das J2EE Migration Kit Plug-in hat
allerdings seine Grenzen, weshalb für die
Konfiguration speziell von containernahen Technologien wie Stateful Session
und Message Driven Beans sowie CMP
Entity Beans oder O/R-Mappern selber
Hand angelegt werden muss. Anpassungen im Quellcode werden vom Plug-in
nicht vorgenommen.
Im Folgenden betrachten wir die Ausstattung und Eigenheiten des Web AS im
Querschnitt durch die Schichten unserer
Beispielapplikation (Abb. 3).
Präsentationsschicht & JNDINamenskonventionen
Unsere Beispielanwendung präsentiert sich
über eine Struts-basierte Webapplikation.
Die Migration des Frameworks stellt sich
in der Regel als unproblematisch dar. Allerdings ist darauf zu achten, dass der Web
AS im Umgang mit JSP-Tags pingeliger ist
als der WebLogic und entsprechend der
Spezifikation auf einer korrekten Groß-/
Kleinschreibung besteht [2].
Des Weiteren sollten Ressourcen wie
Message Properties innerhalb einer Servlet-Definition in der web.xml stets über
einen voll qualifizierten Pfadnamen referenziert werden:
<servlet>
<servlet-name>myAction</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet
</servlet-class>
<init-param>
<param-name>Application</param-name>
<param-value>de.cdiag.demo.Messages</param-value>
</init-param>
...
</servlet>
Die Ressourcen-Dateien sollten sich
dementsprechend im Package de.cdiag.
demo unter WEB-INF/classes befinden.
Zusätzlich dazu müssen die Ressourcen
in gleicher Weise in der struts-config.xml
nachgepflegt werden: <message-resources
parameter=“de.cdiag.demo.Messages“/>.
Der Web AS JNDI Provider erwartet
die Einhaltung spezieller Namenskonven
tionen zur Differenzierung von Komponententypen. Lokale Home Interfaces
sind im Lookup nur mit dem Präfix local
ejbs/... zu finden, während Remote Interfaces ohne dieses Präfix, also unter comp:
java/env/ejb im JNDI Tree eingebunden werden. Ressourcen wie z.B. Data
Sources erhalten das Präfix jdbc/… und
JMS Queues und Topics entsprechend
jmsqueues/... und jmstopics/....
Die Spezifikation empfiehlt an dieser
Stelle nur das Ablegen der EJB-Objekte
unter comp:java/env/ejb und der Ressourcen unter comp:java/env [3]. Der Nutzen
einer gesonderten Deklaration erschließt
sich hier nicht unbedingt auf Anhieb. Die
Deklaration in ejb.jar.xml und der entsprechende Lookup eines lokalen EJBObjekts sehen demnach wie folgt aus:
<ejb-local-ref>
<ejb-ref-name>ejb/LocalDemoBean</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<local-home>de.cdiag.demo.ejb.LocalDemoHome</
local-home>
<local>de.cdiag.demo.ejb.LocalDemo</local>
<ejb-link>AnotherDemoBean</ejb-link>
</ejb-local-ref>
Context jndiContext = new InitialContext();
PersonCMPLocalHome home = (LocalDemoHome)
jndiContext.lookup(“localejbs/LocalDemoBean“);
Während die Spezifikation hier etwas freier ausgelegt wurde, stellt sich der Web AS
auf der anderen Seite wiederum penibler
an. So toleriert der Web AS im Gegensatz
zum WebLogic keine Context-Präfixe wie
java:/comp/env. Auf dem Web AS müssen
JNDI Lookups den konformen Context
www.javamagazin.de
java enterprise
Java EE-Anwendungsmigration
java:comp/env nutzen (ohne Slash vor
comp).
Es müssen gegebenenfalls alle JNDIDeklarationen in Deskriptoren und Sourcen angepasst werden, um Komponenten
auf der neuen Plattform wieder zu finden.
Zusätzlich setzt man in allen Clients noch
den InitialContextFactory-Parameter
auf die SAP-Implementierung com.sap.en
gine.services.jndi.InitialContextFactory
Impl. In geclusterten Systemen kann entsprechend com.sap.engine.services.jndi.
InitialReplicatingContextFactoryImpl
definiert werden, um die Replikation der
JNDI-Objekte über alle Cluster Nodes zu
gewährleisten.
staltet sich hingegen unproblematisch. So
muss zur Konfiguration lediglich die Nutzung des Web AS-Transaktionsmanagers
in der TopLink session.xml deklariert
werden:
<toplink-configuration>
<session>
...
<uses-external-transaction-controller>true</
uses-external-transaction-controller>
</login>
<external-transaction-controller-class> com.sap.engine.
services.ts.jta.impl.TransactionManagerImpl
</external-transaction-controller-class>
...
</session>
</toplink-configuration>
Context ctx = null;
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, ”com.sap.engine.services.jndi.
InitialContextFactoryImpl“);
env.put(Context.PROVIDER_URL, ”localhost:50004“);
try {
ctx = new InitialContext(env);
} catch (NamingException ne) {}
Methodensignaturen
Der WebLogic erlaubt das Werfen eigener Exceptions in EJB-Methoden wie ejb
Create(). Nach unserer Einschätzung legt
der Web AS die EJB 2.0-Spezifikation hier
falsch aus. Im Gegensatz zum WebLogic
erlaubt er hier nur CreateExceptions. Sollen eigene Exceptions geworfen werden,
müssen diese CreateException erweitern.
Nach EJB 2.0 dürfen in der throws-Klausel eigene Exceptions geworfen werden
(siehe EJB 2.0 Spec, Kapitel 7.10.3 [4]).
Persistenz
In unserem Beispiel wird in der Persistenzschicht TopLink eingesetzt. Auf CMP und
proprietäre Features wie Type Mapping
und PK-Generierung wurde verzichtet. Es
sei jedoch kurz erwähnt, dass der Web AS
das vom WebLogic bekannte Type Mapping in CMP-Deskriptoren nicht unterstützt. Mappings sind also programmatisch in den Beans selbst vorzunehmen.
Auch bei der PK-Generierung und den
EJB/QL Statements geht der Web AS eigene Wege, sodass bei Applikationen mit
CMP weitere Aufwände zu kalkulieren
sind. Die Konfiguration von TopLink ge-
www.javamagazin.de
Die Migration anderer O/R-Mapper wie
z.B. Hibernate gestaltet sich in der Regel
ähnlich unproblematisch, da es sich für
gewöhnlich um geringe Anpassungen in
der Konfiguration handelt. Ganz anders
gestaltet sich die Situation, wenn unsere Applikation statt z.B. über TopLink
die Persistenzschicht mithilfe von Entity Beans, hier im Speziellen mit CMPs,
implementiert. In diesem Fall hängt die
Qualität der Migration sehr stark von der
Spezifikationstreue des bisher verwendeten Containers ab.
Zudem nutzen die meisten Application Server gerade für Entity Beans eigene,
proprietäre Deployment-Deskriptoren.
Hier wird das konkrete objektrelationale
Mapping ausdetailliert. Der WebLogic
verwendet hierfür z.B. die Datei weblogic-cmp-rdbms-jar.xml. In dieser Datei
finden sich auch sehr viele Details der
Engine-Konfiguration. So wird über diese Datei der Zeitpunkt des tatsächlichen
Inserts in die Datenbank gesteuert (Element delay-database-insert-until) oder
die Cache-Größe bestimmt.
Wird das J2EE Migration Kit zur Mi
grationserleichterung eingesetzt, wird ein
großer Teil der Mapping-Informationen,
sofern der ursprünglich eingesetzte
Container unterstützt wird, in den De
ployment-Deskriptor persistent.xml des
Web AS übernommen. Dennoch bleibt
häufig noch einiges bei der Migration von
CMPs nachzubearbeiten, falls proprietäre PK-Generatoren oder andere Erweiterungen eingesetzt wurden.
Anzeige
java enterprise
Java EE-Anwendungsmigration
Gerade hinsichtlich der EJB-QL entwickelten die meisten Java EE-ContainerEntwickler eine rege Fantasie und dies
natürlich auf Kosten der Portabilität der
Applikation. In Vorwegnahme der EJB
2.1-Spezifikation wurde z.B. im WebLogic 8.1 die „Orderby“-Klausel aufgenommen. Weiterhin wurden als Extension
Subqueries eingeführt, die erst jetzt mit
EJB 3 Einzug in die Spezifikation halten.
Sicherlich erleichtert dies bei einigen Fragestellungen das Leben des Entwicklers,
dürfte aber umso mehr Kopfschmerzen
bei der Migration verursachen. Diese
Liste ließe sich um einiges verlängern und
auch die anderen Hersteller haben sich
vor EJB-QL Extensions nicht gescheut.
Selbst der bei vielen Entwicklern beliebte
JBoss prahlt hier mit seiner JBossQL.
Web Services
Das NetWeaver Developer Studio stellt
komfortable Wizards zur Generierung
Der Web AS 6.40 steht seinen Konkur-
renten wie WebLogic, WebSphere,
JBoss und anderen in Sachen Spezifikations(un)treue in nichts nach.
einer serverseitigen Web-Service-Infrastruktur zur Verfügung. EJB- oder POJOMethoden können so leicht als Web Service konfiguriert und deployt werden.
Dieses Vorgehen setzt natürlich den
Einsatz des Developer Studios voraus.
Die Migration bestehender Web-ServiceFrameworks ist natürlich auch möglich.
In unserer Beispielanwendung kommt
Axis zum Einsatz. Für die Migration auf
den Web AS mussten keinerlei Anpassungen vorgenommen werden.
Standalone Clients
Um Standalone Clients via RMI/IIOP mit
EJBs auf dem Web AS kommunizieren zu
lassen, müssen neben den entsprechenden
Bean Interfaces die SAP-Bibliotheken
sapj2eeclient.jar, logging.jar und exception.jar im Klassenpfad des Clients liegen. Die Bibliotheken finden sich unter
usr\sap\J2E\JC00\j2ee\j2eeclient\ in der
Web AS-Installation. Die benötigten Bean
52
3.2006
Interfaces können über den Visual Admin
in der Übersicht aller deployten Komponenten über den Button Get Client Jar
generiert werden.
Da man sich sowieso gerade im Visual
Admin befindet, kann gleich geprüft werden, ob der IIOP Provider Service sowohl
im Dispatcher als auch auf der aktuellen
Serverinstanz gestartet ist. Per Default
ist der Service nämlich deaktiviert. Natürlich muss auch bei Standalone Clients
die passende Context Factory im Lookup
definiert sein (siehe JNDI-Namenskonventionen).
Zum guten Schluss
Nachdem alle nötigen Änderungen in
Deskriptoren und Quellcode vorgenommen worden sind und die Anwendung erfolgreich deployt wurde, ist der Job noch
nicht getan. So müssen abschließend alle
vorhandenen Tests erneut durchgeführt
und mit den Ergebnissen der Testläufe vor
der Migration abgeglichen werden. Vor
dem Testen sollten alle automatisierten
Tests auf die neue Laufzeitumgebung angepasst werden.
Fazit
Trotz Java EE-Standards und Tool-Support sind Java EE-Anwendungsmigrationen nicht auf Knopfdruck zu realisieren.
Der Web AS 6.40 stellt hierbei als Zielplattform keine Ausnahme dar. Als vollwertiger J2EE 1.3 Application Server steht
er seinen Konkurrenten wie WebLogic,
WebSphere, JBoss und anderen in Sachen
Spezifikations(un)treue in nichts nach.
Die Erfahrung zeigt, dass der Erfolg von
Java EE-Migrationsprojekten vielmehr
von einem soliden Vorgehen abhängt und
aus technischer Sicht dann sowohl die Eigenheiten der Quell- als auch die der Zielplattform bekannt sein müssen.
Dass die Zielplattform in der Regel zunächst noch unbekannt ist, muss natürlich
bedacht werden. Hier ist der Entwickler,
neben Schulungen und Zertifizierungen,
auf eine funktionierende Community angewiesen, um sich bei einem noch recht
jungen Produkt wie dem Web AS nicht
bei jeder Exception wie der erste Mann
auf dem Mond zu fühlen. SAP hat diesen
Bedarf erkannt und mit dem SAP Developer Network eine lebendige und ständig
wachsende Community etabliert. Als
Senior Vice President für das Platform
Ecosystem Development, das NetWeaver-Partnernetzwerk, zeichnet hierfür
kein geringerer als George Paolini verantwortlich. Der ehemalige Sun-Manager
ist Mitbegründer des Java Community
Process, des weltweit größten Entwicklernetzwerks. Im SDN-Portal [5] bietet SAP
natürlich auch eigene Hilfestellungen speziell zum Thema Java EE-Migration an.
Ohne einen Anspruch auf Vollständigkeit zu erheben, hoffen wir einen hilfreichen Überblick über die aus unserer
Erfahrung relevanten technischen und
organisatorischen Aspekte der Anwendungsmigration auf den SAP Web AS
vermittelt zu haben. Natürlich lassen
sich diese Erfahrungen auf andere Migra
tionsszenarien mit alternativen Zielplattformen übertragen.
Im nächsten Artikel dieser Serie widmen wir uns den von SAP bereitgestellten
Konzepten und Technologien zur Unterstützung des Entwicklungsprozess wie
dem DTR und dem NWDI und stellen sie
gängigen Konzepten wie Continuous Integration und den entsprechenden Tools
wie CVS, Subversion, Ant oder CruiseControl aus der Open-Source-Welt gegenüber.
Helge Martin ist Consultant und Coach in
Softwareentwicklungsprojekten mit dem
Schwerpunkt Java EE bei der CDI Concepts
Development Integration AG (www.cdi-ag
.de) in Dortmund. Er beschäftigt sich seit
mehreren Jahren intensiv mit der Entwicklung und Migration von Java EE-Anwendungen, insbesondere auf dem SAP Web AS.
Dr. Halil-Cem Gürsoy ist Senior Consultant
bei der CDI Concepts Development Integration AG und ist in diverse Java EE- und
WebDynpro-Projekte seit dem Ramp-up des
Web AS 6.30 involviert. Er kann auf eine
mehrjährige Erfahrung in Java EE-Entwicklung und -Architektur auf unterschiedlichen Plattformen
zurückblicken. Sein aktueller Fokus liegt auf der Planung
und Implementierung von event-getriebenen Architekturen auf der Basis von SOA und der Erarbeitung von
Konzepten zur Migration von Java EE-Applikationen.
Sie erreichen die Autoren unter [email protected].
Links und Literatur
[1]Sun AVK: java.sun.com/j2ee/avk/
[2]JSP 1.2-Spezifikation: www.jcp.org/aboutJava/
communityprocess/final/jsr053/
[3]J2EE 1.3-Spezifikation: java.sun.com/j2ee/
j2ee-1_3-fr-spec.pdf
[4]java.sun.com/products/ejb/docs.html
[5]SDN: www.sdn.sap.com
www.javamagazin.de