Als Eclipse vor rund fünf Jahren entstand, galt eine integrierte Entwicklungsumgebung (IDE) mit Editor, Compiler, Linker und Debugger noch als das natürliche Zentrum des Entwicklungsprozesses. Eclipse sollte hierfür eine Plattform anbieten, die es beliebigen Softwareherstellern erlaubt, systemspezifische Anpassungen zu schreiben und Tools als Plug-ins anzuhängen. Die Initiatoren des Projekts erhofften sich, dass mit Best-of-Breed-Werkzeugen unterschiedlicher Hersteller die gesamte Breite der Softwareentwicklung besser abzudecken sei, als das einem einzelnen Hersteller gelingen könnte.

Neue Aufgaben

Heute kann man zwar sagen, dass dieses Konzept ein voller Erfolg war, jedoch funktioniert Eclipse inzwischen nicht mehr so, wie man es sich anfangs vorgestellt hatte. Spätestens in der zweiten Hälfte dieses Jahrzehnts erzwingen die steigenden Anforderungen an Applikationen den Einsatz neuer Methoden. Es wird sich die Einsicht durchsetzen, dass man die Softwareentwicklung als ganzheitlichen Prozess begreifen muss, bei dem der Programmcode nur ein Abschnitt im Lebenslauf der Software ist, nicht aber die Nabe, um die sich alles dreht. Mit dem Übergang zum Application-Lifecycle-Management (ALM) werden die Erfassung der Anforderungen (Requirement), das Modelldesign, die Codierung, der Test, das Deployment sowie Betreuung und Betrieb als Gesamtprozess verstanden, dessen Phasen ineinandergreifen müssen - das Leitmotiv der Softwareentwicklung stellt heute der Prozessgedanke.

Neben- statt miteinander

Eclipse hat auf diese Neuorientierung schnell reagiert. Seit Version 3 handelt es sich nicht mehr nur um eine Java-IDE, in die andere Tools als Plug-ins eingeklinkt werden. Vielmehr stehen zahlreiche andere Funktionen als Plug-ins zur Verfügung, die Java-IDE selbst ist jetzt nur noch eines davon. Damit ist Eclipse sehr flexibel geworden und verhält sich neutral gegenüber einzelnen Technologien.

In letzter Zeit haben sich jedoch auch Schwächen gezeigt: Eclipse ist mit der Steuerung des ALM überfordert. Die einzelnen Tools unterschiedlicher Hersteller können zwar über Plug-ins in Eclipse eingebunden werden, sie arbeiten dann aber mehr neben- als miteinander; keine gute Basis für die Verarbeitung von Prozessen. Insofern bietet Eclipse seinen Benutzern eher eine Art Portal, über das sich die jeweiligen Anwendungen ansprechen und Daten austauschen lassen, von einer Integration auf Prozessebene kann dabei jedoch keine Rede sein. Dabei ist es gerade das, was Anwender vom ALM erwarten: durchgängige Prozesse, die über alle Hürden von unterschiedlichen Systemen, Programmiersprachen, Herstellern etc. hinweggleiten. Nur so können Anwender den Entwicklungsprozess wirklich steuern und kontrollieren, und das wiederum ist unter dem Aspekt der Softwarequalität unerlässlich.

Derartige Schwächen im Umgang mit ALM sind natürlich keineswegs auf Eclipse beschränkt. Stand der Technik ist im ALM-Umfeld noch immer die Punkt-zu-Punkt-Verbindung der Werkzeuge, was aufwändig, wenig flexibel und fehleranfällig ist. Fast alle Hersteller ringen derzeit um die Integration von Tools, die sie in den letzten Jahren meist durch Merger oder Käufe ihrem Produktportfolio angegliedert haben. Sie decken heute in der Regel zwar alle Segmente des Entwicklungszyklus ab, aber es ist schwierig bis unmöglich, einen Prozess über alle Phasen methodisch zu begleiten, erst recht, wenn die Tools von verschiedenen Anbietern stammen.

Workflow für Plug-ins

Eclipse ist in Sachen Integration mittlerweile einen großen Schritt weiter: Das Projekt Application Lifecycle Framework (ALF) erweitert die Plattform um eine Infrastruktur, mit der sich Prozesse über unterschiedliche Werkzeuge hinweg steuern lassen. Dabei erfährt das Eclipse-Konzept abermals eine Veränderung: Die ALM-Komponenten werden nicht als mehr oder weniger statische Plug-ins mit Eclipse verbunden, sondern mittels eines Workflows. ALF stellt einen Workflow-Manager zur Verfügung, der die Kommunikation zwischen den einzelnen Lösungen steuert. Er nimmt beispielsweise eine im Requirements-Management bearbeitete Anforderung auf und setzt einen Workflow in Gang, der etwa die Zuständigkeit oder Freigabe überprüft. Anschließend gibt er diesen Workflow, wenn definierte Bedingungen erfüllt sind, als neues Event weiter, zum Beispiel an die Modellierung oder das Coding.

Die beteiligten Tools müssen dafür nicht fest verknüpft sein, sondern lediglich den Workflow-Manager verstehen können. Für diese Kommunikation zwischen Tool und Infrastruktur dient der ALF-Adapter. Technisch wird die Zusammenarbeit der Einzelteile im Rahmen einer Service-orientierten Architektur (SOA) realisiert. Die Komponenten des ALM werden dabei als Web-Services entwickelt, womit die Konventionen der Kommunikation im Rahmen allgemein anerkannter Standards erfolgen. Grundlegend ist, dass ALF unabhängig von bestimmten Tools und Herstellern arbeitet und ganz auf etablierten Open-Source-Komponenten beruht.

Die lose Kopplung der Komponenten und Tools verleiht dem ALF-Konzept eine sehr große Flexibilität. Egal ob vorhandene Tools von den Herstellern weiterentwickelt werden oder ob neue hinzukommen, durch die Einbindung in den ALF-Workflow können sie alle unmittelbar am Entwicklungsprozess beteiligt werden und im Rahmen der definierten Vorgaben in ihn eingreifen.

Open Source - ideale Basis

Es war klar, dass eine echte Prozessintegration im ALM nicht ohne eigene Infrastruktur auskommen würde. Dienste wie Workflow-Steuerung oder Sicherheitsfunktionen müssen für die gesamte Landschaft verbindlich geregelt werden. Es war allerdings auch klar, dass jeder herstellerspezifische Ansatz dafür im Markt auf große Skepsis stoßen würde, denn wer die Infrastruktur kontrolliert, hat früher oder später das Sagen - und wer entwickelt schon gerne Tools für ein System, in dem der Mitbewerber die Regeln bestimmt. Insofern kommt Open Source für ALM wie gerufen: Eclipse hat bisher schon gezeigt, dass sich Offenheit bewährt, sich sehr gut mit Professionalität verbindet und dass alle Beteiligten - Hersteller wie Anwender - daraus ihren Nutzen ziehen können. Deshalb ist ALF für die Softwareentwicklung ein großer Schritt nach vorn.

Fazit

Eclipse hat sich von der quelloffenen IDE zur unabhängigen Plattform für die Steuerung des Entwicklungsprozesses weiterentwickelt. Im Application Lifecycle Framework werden nun die Werkzeuge unterschiedlicher Hersteller per Workflow lose gekoppelt. Dem Anwender bringt das mehr Flexibilität und eine produktivere Softwareentwicklung. (ue)