Hallo Hans,
 
ich antworte hier mal direkt auf Deutsch, da ich annehme, dass es verstanden 
wird (jedenfalls besser als mein Englisch).
Ich sehe eine gewisse Ähnlichkeit zu der Situation, in der wir uns hier 
befinden. Wir haben mehrere produktive Anwendungen
laufen (einerseits auf dem WeblogicServer von BEA, andererseits auf JBoss), die 
in der Größenordnung dem von Dir beschriebenen
Szenario entsprechen (z.T. mehr als 110 Entitäten (CMP) mit annähernd 100 
Relationen (CMR)).
Seit einiger Zeit beschäftige ich mich (mehr privat) mit der Frage einer 
Portierung auf Geronimo, wobei allerdings einige Punkte vielleicht
doch einen Unterschied zu Deiner Fragestellung ausmachen. Wir haben uns (wie 
wahrscheinlich die meisten) den Umgang mit dem etwas
schwerfälligen EJB 2.0 Standard (Interfaces etc.) durch Einsatz eines 
Generierungssystems erleichtert, das auf Basis von XDoclet,
XSLT-Transformationen und eigenen kleineren Werkzeugen die Erzeugung eines 
Programmrahmens aus einem in einer Datenbank hinterlegten
Modell gestattet. Das gestattet die relativ leichte Erzeugung aller notwendigen 
Klassen inklusive von Datentransferobjekten (value objects)
quasi auf Knopfdruck. Mir scheint nach meinen bisherigen Einsichten eine 
Übertragung eines solchen Vorgehens auf Geronimo durchaus
möglich. (Hinzu kommt nur die Notwendigeit einen Deployment Plan für Geronimo 
zu erzeugen, was XDoclet nach meiner Kenntnis zur Zeit
noch nicht bietet (?).
Es hat sich hier nur ein einziger Haken gezeigt: Sowohl beim BEA-Server als 
auch beim JBoss verwenden wir das Konzept der Erzeugung
von Abfragen zur Laufzeit (dynamic queries), um uns einen unübersehbaren Wust 
an statischen Abfragen auf Deskriptorebene zu ersparen.
Leider gibt es ein solches Konzept zur Zeit innerhalb von openEJB resp. tranQL 
nicht (soweit ich weiss). Andererseits hat unsere
praktische Erfahrung gezeigt, dass hinsichtlich Performanz Abfragen via JDBC 
(jdbc for reading) in vielen Fällen sowieso der einzig gangbare
Weg sind. Hier kann man insofern ansetzen, als dass es z.B. möglich ist, via 
Introspektion aus Datentransferobjekten direkte Abfrage über
JDBC zu erzeugen; meinetwegen um zunächst die Primärschlüssel der gesuchten 
Entitäten zu ermitteln und dann das Objekt nach Bedarf komplett
nachzuladen (was in etwa der Vorgehensweise der von uns benutzten AppServer 
entspricht).
So scheint mir auf diesem Weg eine Portierung auf Geronimo möglich zu sein; 
allerdings verbleibt dies im Rahmen von EJB 2.0.
Eine andere Frage ist, ob ein Wechsel auf EJB 3.0 nicht aus weitergehenden 
Gründen angeraten ist. Bislang lese ich immer nur, dass
EJB 3.0 die Arbeit des Programmieres erleichtern soll (was natürlich je nach 
gewählter Vorgehensweise eine relative Frage ist), während
sich das interne Verhalten des AppServers gar nicht wesentlich ändert (?). Das 
kann ich zur Zeit nicht richtig beurteilen, würde mich aber
sehr interessieren.
 
Gruss
Michael

-----Ursprüngliche Nachricht-----
Von: Hans J. Prueller [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 25. Januar 2007 07:15
An: [email protected]
Betreff: other appserver/ejb2.1 to geronimo 2.0 migration strategy?



hi together,

 

I have been working with the JOnAS Java 2 EE application server for about 5 
years now, meanwhile

I have several projects, one of them is rather big already, it contains about 
60-70 EJB's, two thirds

of them are CMP/CMR'ed entity beans, the rest stateless session beans.

 

I am thinking about migrating these projects to Geronimo for some months now, 
and I decided to

wait for the first Java EE 5 release of Geronimo (Geronimo 2) - as it will be 
released within the 

near future I would be interested in which migration strategies you could 
suggest?

 

I think the most problematic part will be to migrate the ca. 50 CMP entity 
beans, there are a lot

of EJB-QL finders and all of those beans are inter-related with CMR. 

 

Currently I'm thinking of doing a "soft" migration, i.e. migrating 1 by 1 of 
those EB's within the

currenty architecture from CMP to hibernate, and after that performing the move 
to Geronimo (which will

mean that then only the session beans will have to be migrated which should be 
less problematic).

 

what do you think about that?

 

Anybody already migrated large CMP/CMR apps to Geronimo?

 

regards,

Hans

 

=========================== 
virtually hanzz...

 

 <http://hanzz.zapto.org/> http://hanzz.zapto.org (personal)
 <http://www.cse.dmu.ac.uk/~hansp> http://www.cse.dmu.ac.uk/~hansp (research)

 

 

 

Reply via email to