Artikel

 
Juni 2009 | Artikel

EclipseLink: Eine Persistenzlösung für alle Bedürfnisse?

(Link zum Artikel: http://www.it-republik.de/jaxenter/artikel/2362)

Doug Clarke, Project Lead von EclipseLink, im Gespräch mit dem Eclipse Magazin.

2007 entscheidet sich Oracle, die Quellcodes seines erfolgreichen Persistenz-Projektes TopLink an die Eclipse Foundation zu übergeben. Seither wird das Projekt unter dem Namen EclipseLink weiterentwickelt und wurde jüngst als Referenzimplementierung für die Java Persistence API 2.0 ausgewählt. EclipseLink-Lead Doug Clarke spricht im Interview mit dem Eclipse Magazin über die Hintergründe der Migration zur Eclipse Foundation und über die Vorzüge von EclipseLink gegenüber anderen Persistenz-Frameworks wie Hibernate.
Teil 1   Teil 2   

Eclipse Magazin: Doug, kannst du zu Beginn erklären, welche Rolle du im EclipseLink-Projekt inne hast?

Doug Clarke: Ich bin Co-Leader des Eclipse-Persistence-Services-Projekts, besser bekannt unter dem Namen EclipseLink (siehe Kasten: EclipseLink und Oracle TopLink). Ich teile die Projektleitung mit Peter Krogh, ebenfalls von Oracle. Peters Schwerpunkt liegt bei der Entwicklung, während ich mich um die Zusammenarbeit mit anderen Projekten kümmere, und um die Community im Ganzen. Außerdem vertrete ich das EclipseLink-Projekt auch im Eclipse RT Project Management Council (RT-PMC). Das RT-Top-Level-Projekt wurde ins Leben gerufen, um verwandte Runtime-Technologien bei Eclipse auf den Weg zu bringen und zu unterstützen.

EclipseLink und Oracle TopLink
EclipseLink ist durch eine Spende von Oracle an die Eclipse Foundation aus Oracle TopLink hervorgegangen. TopLink, ursprünglich eine ORM-Lösung für Smalltalk, wurde 1996 als kommerzielles Produkt für Java veröffentlicht und seit dieser Zeit sehr erfolgreich in vielen Enterprise-Java-Projekten eingesetzt. Oracle TopLink liegt aktuell in der Version "11g" (11.1.1.0.1) vor. Dies ist die erste Version, die auf EclipseLink aufbaut. Sie umfasst zusätzlich eine Integration mit der Clustering-Lösung Coherence von Oracle. Darüber hinaus bietet Oracle Support für TopLink. Für Evaluierungszwecke ist TopLink frei im Oracle Technology Network verfügbar. Ein produktiver Einsatz setzt jedoch eine entsprechende Lizenz voraus. Oracle bietet TopLink-Lizenzen auch im Bundle mit anderen Produkten wie dem Oracle WebLogic Server an.

Eclipse Magazin: Was hat Oracle zur Spende der Quellcodes von TopLink an die Eclipse Foundation bewogen?

Doug Clarke: Generell möchte Oracle für den Anwender Vielfalt, Flexibilität und niedrige Kosten ermöglichen. Oracle investiert erhebliche Mittel in Entwicklung, Testen und Optimierung von Open-Source-Technologien wie Linux, PHP, Apache, Eclipse, Berkeley DB und InnoDB, und unterstützt so die Schaffung praktikabler Open-Source-Lösungen für Entwicklung und Deployment.

Ausgangspunkt für die Spende der Quellcodes von TopLink waren die positiven Erfahrungen und das großartige Feedback nach der Veröffentlichung des Quellcodes der TopLink-ORM-Funktionalität durch TopLink Essentials, der JPA-1.0-Referenzimplementierung des GlassFish-Projekts. Oracle kann auf eine langjährige Zusammenarbeit mit der Eclipse Foundation zurückblicken, und die lebhafte, aktive Eclipse Community sowie die organisatorische Professionalität passten gut zu unseren Zielen. Es gab zudem eine starke Nachfrage nach einer umfassenden Persistenzlösung, die den Bedürfnissen der nächsten Generation von Softwareentwicklung auf Basis von Java EE, SE, OSGi und Serviceorientierung gerecht wurde, und TopLink stellte hier eine einzigartige und mächtige Lösung dar. Das führte schließlich zu der Entscheidung von Oracle, TopLink gänzlich als Open-Source-Projekt bei Eclipse weiterzuentwickeln und so die reichhaltige Funktionalität von TopLink der gesamten Java-Community zugänglich zu machen.

EclipseLink ist einzigartig, da es neben den fortschrittlichsten objektrelationalen Features noch zusätzliche Persistenzservices bietet, wie MOXy (Objekt-XML-Mapping mit JAXB-Support), Service Data Objects (SDO) und Database Web Services (DBWS). Dass diese Möglichkeiten jetzt durch das EclipseLink-Projekt der ganzen Java Community offen zur Verfügung stehen, fördert die schnelle und umfassende Verbreitung der Technologie. User können nun mit einer einzigen Persistenzlösung Technologien miteinander kombinieren, die auf unterschiedlichen Standards basieren, wie SDO und JPA (für mehr Details siehe [1]).

Eclipse Magazin: Welche Auswirkungen hat es auf deine tägliche Arbeit und die Arbeit des Teams, nun ein Open-Source-Projekt zu sein?

Doug Clarke: Hauptsächlich wirkt sich der Open-Source-Ansatz in einer größeren Transparenz aus. Anwender und Mitwirkende am Projekt können leicht die fortschreitenden Entwicklungsbemühungen mitverfolgen und sofort kommentieren. Als Folge davon haben wir eine steigende Anzahl von Anfragen, Verbesserungsvorschlägen und Bug-Meldungen während der Entwicklungsarbeit zu berücksichtigen. Diese erhöhte Interaktion mit der Community stellt zunächst einmal einen zusätzlichen Aufwand dar, aber sie ist auch ein riesengroßer Gewinn, da wir so besser in der Lage sind, von den Usern tatsächlich benötigte Funktionalität in kurzen Release-Zyklen umzusetzen. Der Nutzen aus dieser intensiven Interaktion mit der Community ist bei weitem größer als die Kosten durch den Mehraufwand, und wir schätzen die Leute aus der Community sehr, die sich die Zeit nehmen, uns dieses wertvolle Feedback zu geben.

Eclipse Magazin: Kannst du den EclipseLink-Entwicklungsprozess beschreiben? Welche Entwicklungswerkzeuge benutzt ihr, abgesehen von Eclipse? Welches Build-Tool? Welche Continuous-Integration-Produkte oder -Lösungen verwendet ihr?

Doug Clarke: Die EclipseLink-Committer nutzen die Eclipse Bug Database, das Wiki und die Mailing-Liste, um die Entwicklung von neuen Features und die Behebung von Fehlfunktionen offen zu diskutieren, sodass alle interessierten Parteien partizipieren können. Alle Verbesserungen der Codebasis benötigen eine Begutachtung durch Fachleute. In einem wöchentlichen Treffen der Committer können Fragen bezüglich Zeitplan, Bug Closure Rates und Design erörtert werden. Alle Interessierten sind eingeladen, teilzunehmen und ihren Beitrag zu leisten. Die EclipseLink-Roadmap und der Release-Fahrplan werden in einer standardisierten Form zugänglich gemacht, sodass User und Committer alle kommenden Meilensteine auf eclipse.org mitverfolgen können.

Builds und automatisierte Regressionstests basieren auf ANT und laufen auf einem Server, der bei der Eclipse Foundation gehostet wird. Automatisierte Builds und Tests starten jede halbe Stunde und erzeugen sofort Berichte, sodass Fehler schnell behoben werden können. Nightly Builds sowie monatliche Milestone Builds werden zum Download bereitgestellt. Die Nightly Builds, Meilensteine und Releases können sofort heruntergeladen werden und werden außerdem in einem Maven Repository gehostet.

Eclipse Magazin: Der Großteil der EclipseLink-Entwickler arbeitet für Oracle. Was entgegnet ihr auf Befürchtungen, EclipseLink sei vor allem auf die Arbeit mit der Oracle-Datenbank und dem Oracle Application Server zugeschnitten?

Doug Clarke: Es stimmt zwar, dass eine große Anzahl der Entwickler für Oracle arbeitet, doch ich möchte betonen, dass viele Mitstreiter auch von außerhalb kommen, sowohl einzelne Personen als auch Unternehmen. EclipseLink hat in seiner langen Geschichte stets eine breite Unterstützung aller großen Anwendungsserver und Datenbanken geboten. Das wird von den Usern erwartet. Allerdings fordern die Anwender auch die Unterstützung von proprietären Eigenschaften der führenden Datenbanken. Wegen seiner Herkunft ist EclipseLink zwar besser auf die Features der Oracle-Datenbanken abgestimmt als andere ORM-Produkte. Nichtsdestotrotz unterstützt EclipseLink aber auch spezifische Funktionalitäten anderer Datenbanken, wie DB2, SQL Server, MySQL und Derby.

Es ist sicher auch von Interesse, dass EclipseLink Teil von Oracles internem Tool Kit ist. Anwender von EclipseLink innerhalb von Oracle-Datenbanken müssen, wie viele andere User auch, hochgradig kommunikationsfähig zu anderen Anwendungsservern und Datenbankplattformen sein. Wer z. B. die Oracle-SOA-Suite oder die Oracle-WebCenter-Suite einsetzt, benötigt das Deployment sowohl auf Oracle- als auch auf anderen JavaEE-Containern.

Teil 1   Teil 2   

andere Artikel dieser Serie


Anzeige

Kommentare


Anzeige

zurück zum Seitenanfang