20071112zb Application Lifecycle Framework von Eclipse Serena

It’s about the process, stupid! – neues Leitmotiv für die Softwareentwicklung

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

n den Wandlungen des Eclipse-Projekts lassen sich sehr gut die strukturellen Veränderungen aufzeigen, die die Softwareentwicklung in den letzten Jahren erlebt hat. 2001 wollte sich IBM mit der Freigabe des Quellcodes seiner Entwicklungsumgebung Visual Age for Java im Markt der IDEs (Integrated Development Environment) besser positionieren, vor allem gegenüber Microsofts Visual Studio und Suns Netbeans. Damals galt die IDE mit ihrer Integration von Editor, Compiler, Linker und Debugger noch als das natürliche Zentrum des Entwicklungsprozesses Hier sollte Eclipse eine Plattform bereitstellen, die es beliebigen Softwareherstellern erlaubt, systemspezifische Anpassungen zu schreiben und Tools als Plug-Ins anzuhängen. Die Initiatoren des Projekts erhofften sich, dass so, mit »Best-of-breed«-Werkzeugen unterschiedlicher Hersteller, die gesamte Breite der Softwareentwicklung besser abzudecken sei, als das einem einzelnen Hersteller gelingen könnte – und sei es der Marktführer.

Heute, rund fünf Jahre nach dem Start von Eclipse, kann man zwar sagen, dass dieses Konzept ein voller Erfolg war, jedoch funktioniert Eclipse heute nicht mehr so wie man es sich anfangs vielleicht vorgestellt hatte. Eclipse genießt breite Unterstützung durch die Hersteller und es gibt im Bereich Softwareentwicklung kaum etwas das nicht auch für Eclipse verfügbar wäre; es gibt mittlerweile rund 780.000 Eclipse-Plug-Ins. Eclipse ist ohne Zweifel heute etabliert, auch in den Unternehmen also überall da, wo mit Software Geld verdient werden muss.

Andererseits ist die Fokussierung auf die IDE ein Konzept der 90er-Jahre. Spätestens in der zweiten Hälfte dieses Jahrzehnts nötigen die steigenden Anforderungen an die Applikationen zum Einsatz neuer Methoden und zur Einsicht, 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 Erfassung der Anforderungen, Modelldesign, Codierung, Test, Deployment sowie Betreuung und Betrieb als Gesamtprozess verstanden, dessen Phasen ineinander greifen müssen – das Leitmotiv der Softwareentwicklung stellt heute der Prozessgedanke.

Eclipse hat auf diese Neuorientierung der Branche schnell reagiert. Seit der Version 3 ist Eclipse nicht mehr eine Java-IDE, in die andere Tools als Plug-Ins eingeklinkt werden, sondern stellt alle Funktionalitäten als Plug-Ins zur Verfügung. Auch die Java-IDE ist jetzt »nur« noch ein Plug-In. Damit ist Eclipse sehr flexibel geworden und verhält sich neutral gegenüber einzelnen Technologien. Es ist seither keine Java-Entwicklungsumgebung mit Erweiterungsmöglichkeiten, sondern eine hoch-integrative Plattform für Softwareentwicklung. Entsprechend breit ist die Unterstützung für Eclipse, die von einer Vielzahl von Editoren bis zu Change und Configuration Management auf höchstem Niveau reicht.

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. Eclipse bietet den Anwendern so mehr 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 usw. hinweg gleiten. 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 aufwendig, 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.

Eclipse ist in Sachen Integration mittlerweile einen großen Schritt weiter: Das von Serena Software initiierte Application Lifecycle Framework-Projekt (ALF) erweitert Eclipse 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, setzt einen Workflow in Gang, der vielleicht Zuständigkeit oder Freigabe überprüft, und gibt diesen Workflow bei Erfüllen definierter Bedingungen als neues Event weiter, zum Beispiel an die Modellierung oder die Codierung. Die beteiligten Tools müssen dafür nicht fest verknüpft sein – sie müssen 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 serviceorientierten Architektur (SOA) realisiert; die Komponenten des ALM werden dabei als Web-Services entwickelt, womit die Konventionen der Kommunikation im Rahmen allgemein anerkannter Standards erfolgt, ohne Geheimnisse und ohne Fallstricke. Grundlegend ist, dass ALF unabhängig von bestimmten Tools und Herstellern arbeitet und ganz auf etablierten Open-Source-Komponenten beruht. Serena als Initiator selbst bringt zwar sein Know-how aus den Bereichen Requirements Management sowie Change und Configuration Management in das Projekt ein, aber ALF funktioniert natürlich auch ohne die Serena-Lösungen.

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 dazukommen, 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.

Es war klar, dass eine echte Prozessintegration im ALM nicht ohne eigene Infrastruktur auskommen würde. Es gibt Dienste wie Workflow-Steuerung oder Sicherheitsfunktionen, die für die gesamte Landschaft verbindlich geregelt werden müssen. Es war allerdings auch klar, dass jeder herstellerspezifischer 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 setzt. Insofern kommt Open Source für ALM wie gerufen: Eclipse hat bisher schon gezeigt, dass sich Offenheit bewährt, dass sie 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.

Aus dem ALF-Vokabular

l ALF Adapter: die Schnittstelle des ALF-Frameworks zu den herstellerspezifischen Tools

l ALF Event: eine Web-Services-Message, die von einem Tool an die ALF-Infrastruktur geschickt wird

l ALF Event Manager: Steuerungseinheit, die die vom ALF-Adapter kommenden Nachrichten in Rahmen des ALF Service Flow verarbeitet

l ALF Service Flow: in BPEL dargestellter und als XML-Dokument abgelegter Prozess; Service Flows sind das Ergebnis von Events

l BPEL (Business Process Execution Language): Workflow-Technologie die Web-Services zu Business-Prozessen vereint

l ALF Server: arbeitet die einzelnen Schritte des Workflow ab

l ALF-Orchestrierung: Koordination von Web-Services, um eine aus mehreren Einzelschritten bestehende Aktion auszuführen

Über das Application Lifecycle Framework (ALF) lassen sich Tools leichter integrieren.

Der ALF-Event-Manager nimmt Informationen aus den Werkzeugen auf und stößt einen Workflow an

Copyright © 2003-2012 ap Verlag GmbH