Herausforderung an die Produktivität der Anwendungsentwicklung

Application Lifecycle Framework (ALF)

Lorne Cooper und Matthew Laudato

Das Application Lifecycle Framework Project (ALF) erweitert die Eclipse-Plattform dahingehend, dass es für die Lösung des Integrationsdilemmas sorgen will: Wo bislang Insellösungen zum Einsatz kamen, sollen künftig Application-Lifecycle-Tools integriert und miteinander kombiniert werden.

Niklaus Wirth, der bekannten Schweizer Informatiker, hat folgende berühmte Gleichung verfasst: Algorithmus + Datenstrukturen = Programme. Wäre er Professor an einer Business School gewesen, hätte er möglicherweise Folgendes geschrieben: Menschen + Prozesse + Tools = Anwendungen. Menschen, Prozesse und Tools sind die drei entscheidenden Faktoren für die Produktivität der Anwendungsentwicklung.

Obwohl diese drei Faktoren gleichermaßen wichtig sind, sind sie jedoch im Anwendungsentwicklungs-Projektbudget nicht gleichermaßen repräsentiert. Von der Gesamtsumme, die z.B. jährlich in den USA für Softwareentwicklung ausgegeben werden (275 Milliarden US-Dollar) [The Standish Group, Chaos Report, 1999], werden weniger als zwei Prozent für Tools und Prozessentwicklung ausgegeben [Gartner, 2004].

Der Einfluss, um die Softwareproduktivität mithilfe von Tools und Prozess(en) im großen Stil zu erhöhen, ist enorm. Viele effektive Tools und Entwicklungsprozesse sind im vergangenen Jahrzehnt entwickelt worden, aber ihre Gesamtauswirkung auf die Produktivität der Anwendungsentwicklung fiel geringer aus als erwartet. Die Analyse dieses Defizits hat dazu geführt, dass die Industrie nach Wegen sucht, um die entstehenden Entwicklungsprozesse in die konstant herauskommenden neuen Produktivitäts-Tools einzubeziehen.

Tools und Prozesse oder Tool- und Prozessintegration

Heutzutage schließt eine typische Anwendungsentwicklungs-Umgebung eine Kombination von konventionellen Wasserfall-Methoden, „iterativen“ Design-Stilen, Ad-hoc-Management-Methoden und heterogenen kommerziellen, Open-Source- und hausgemachten Tools und Technologien mit ein. Der Prozess ist implizit in den Datenfluss und die Kontrolle zwischen Tools und dem Zustand der Daten, die in die Tools eingebettet sind, eingebunden.

Tools und Prozess sind jedoch entweder gar nicht oder nur via zahlreiche Point-to-Point-Integrationen, die Annahmen über den Entwicklungsprozess verankern, integriert und besonders zerbrechlich und mit großem Arbeitsaufwand instand zu halten. Das schränkt den Wert, den Anwendungsentwicklungs-Umgebungen durch ihre Tools und Methodologien realisieren können, ein.

Ziel des ALF-Projektes ist es, dieses Integrationsproblem zu lösen, indem es vielfältige heterogene Tools und Prozesse an der Spitze einer modernen, flexiblen EAI-Architektur verbindet.

Der ALF-Ansatz

ALF stellt ein SOA-Framework zur Verfügung, das einen zentralen Event- und Prozessmanager enthält, der die Interaktion zwischen den Anwendungen kontrolliert. Die Anwendungen kommunizieren mithilfe des sog. ALF Adapter mit dem zentralen Prozessmanager und signalisieren Änderungen im Zustand oder in den Daten. Der ALF-Server lässt dann seine Prozess-Management-Engine laufen, bestimmt den nächsten Schritt innerhalb des Prozesses und gibt Informationen an eine oder mehrere andere Anwendungen weiter, ändert die Daten, den Zustand oder sogar seinen eigenen Prozess.

Abb. 1: ALF – die Architektur
Die Entwicklung von ALF Adapters

Die meisten modernen Tools haben eine offene Architektur, die es erlaubt, den Zustand der Tools sowie die Daten durch ein stabiles Interface (meist mit XML) zu manipulieren. Der ALF Adapter beeinflusst diese Interfaces im Hinblick auf Änderungen der lokalen Daten und des Zustandes, mappt sie auf das ALF-Vokabular (zum größten Teil WSDL-Definitionen) und sendet anschließend die entsprechende Web-Service-Nachricht an den zentralen Event-Manager.

Das ALF-Projekt hat ein Set von Standard-Events entwickelt in der Hoffnung, dass Organisationen diese Events ausbauen werden, damit sie ihren eigenen Bedürfnissen entsprechen. Außerdem unterstützt das Projekt verschiedene Vokabular-Gruppen mit dem Ziel, das ALF-Vokabular zu entwickeln und grundlegend zu standardisieren.

Abb. 2: ALF-Vokabular

Zum Bau des ALF-Adapters kann jede Sprache oder Technologie, die in der Lage ist, Web-Service-Nachrichten zu konstruieren, verwendet werden. Tool-Anbieter mit bestehenden Perl-, Java- oder C-APIs können proprietäre oder Open-Source-Web-Services-Toolkits nutzen, um ihre Produkte dahingehend zu modifizieren, dass sie mit einer ALF-Umgebung interoperieren können.

Die Modellierung des Applikationsentwicklungs-Prozesses mit ALF

Der ALF Event Manager verarbeitet Nachrichten, die er von den ALF-Adaptern, die unter der Kontrolle des ALF Service Flow stehen. Ein Service Flow ist eine Definition des Entwicklungsprozesses, der durch den Gebrauch von BPEL modelliert wurde.

Abb. 3: Beispiel des Service Flow

Ein ALF Service Flow ist ein BPEL-Prozess, bei dem es sich um ein XML-Dokument handelt, das mit grafischen Design-Tools in der Regel eher von Prozess-Experten als von Entwicklern generiert wird. Diese BPEL-Prozesse werden durch den ALF Event Manager durchgeführt. Der Event-Manager kann einen BPEL-Prozess durch ein Web-Services-Interface herausgeben oder er tritt in Aktion, um Bedingungen, die innerhalb des Prozesses selbst aufgestellt worden sind, auszulösen.

BPEL stellt eine robuste, störungstolerante Workflow-Technologie zur Verfügung, um individuelle Web Services in komplexen Business-Prozessen zu vereinen. Tool-Anbieter, die mit ALF kompatible Workflows entwickeln und dabei BPEL ntzen, müssen nur einige spezifische BPEL Extensions für Web-Services-Technologien wie XML, SOAP und WSDL kennen lernen. Eclipse-basierte Design-Tools wie z.B. den ActiveBPEL Designer unterstützen Entwickler mit einer stabilen Plattform für das Service-Flow-Design bzw. -Deployment (mehr Informationen zu BPEL: www.oasis-open.org, www.activebpel.org).

In einem typischen ALF Deployment werden die ALF Events mithilfe des Event Manager registriert, der die Events von einem Tool auf die ALF Service Flows mappt, wobei er andere registrierte Tools verwendet. Wenn ein Tool einen registrierten Event ausgibt, schlägt der Event Manager diesen Event in seiner Registratur nach und initiiert dann einen oder mehrere Service Flows, die mit diesem Event assoziiert sind. Auf diese Weise werden die Tools durch gemappte Events im Event Manager eher lose aneinander gekoppelt, als dass sie – wie in traditionellen Integrationen – hart kodiert werden.

Der Ansatz der „losen Kopplung“ ermöglicht den Tools Flexibilität und ist ein entscheidender Teil jeder modernen Integrationsstrategie. Die Flexibilität der Tools muss in zwei Dimensionen möglich sein: Tools entwickeln sich kontinuierlich im Lauf der Zeit und unterschiedliche Gruppen und Organisationen mit unterschiedlichen Bedürfnissen könnten unterschiedliche Tools übernehmen, um denselben Stand eines Prozesses zu erreichen. ALF Flows können beispielsweise mehrere Issue-Tracking-Systeme updaten, während sich der Status eines Issues ändert: die am Helpdesk orientierte Anwendung, die Defect-Tracking-Organisation oder ein Projekt-Management-Tool.

Das ALF-Setup

Da ALF auf Standard-EAI-Technologien basiert, kann eine ALF-Umgebung durch eine Vielzahl von Technologien konfiguriert werden, angefangen bei einem reinen Open-Source-Stack, der Tomcat, Axis oder ActiveBPEL benutzt, bis hin zu einer, die technisch ausgereifte kommerzielle Infrastrukturkomponenten benutzt. Für den Open-Source-Ansatz ist der Tomcat das Tool der Wahl für das Hosten der Services. Der Tomcat ist ein Application Server, der es den Entwicklern ermöglicht, WAR-Files hineinzuwerfen, um ein Servlet oder eine Web-Services-Anwendung zu deployen.

Daneben ist Axis ein bevorzugtes Tool, um Java Web Services zu bauen und zu deployen. Axis ermöglicht sowohl „Bottom up“- als auch „Top down“-Entwicklungen der Services. Beim Bottom-up-Ansatz können Entwickler das Axis-Toolkit nutzen, um Web Services Wrapper um existierende Java-Klassen zu bauen.

Das hat den Vorteil, dass existierende Applikationen beeinflusst werden können und die Web-Services-Lernkurve minimiert werden kann. Bei neuen Anwendungen wird häufig die Top-down-Methode bevorzugt. Bei dieser Methode schreiben Anwendungsentwickler WSDL, das die Nachrichten und Interfaces, die von einer Anwendung unterstützt werden, beschreibt, und können dann das Axis-Toolkit benutzen, um Java-Code zu generieren. Anschließend modifiziert der Entwickler den generierten Code, um eine applikationsspezifische Logik und Error Handling zur Verfügung zu stellen.

ALF in Aktion

Schauen wir einmal eine einfache Prozessdefinition an und betrachten, wie die Information in ALF fließen würde. Stellen Sie sich eine Organisation vor, deren Prozesse zwei separate Reviews von Softwareänderungen mit einschließen: einen traditionellen Code Walkthrough durch einen „Architekten“ und eine Untersuchung durch einen Compliance Officer. Lassen Sie uns die Umgebung noch zusätzlich erschweren, indem wir annehmen, dass der „Architekt“ ein anderes SCM-Tool nutzt, das vom Entwickler eingesetzt wurde, und dass das Compliance Checking ein halbautomatisierter Prozess ist, der seine eigenen Tool Flows mit einbringt.

Der Entwickler schließt ein lokales Testing bezüglich der Änderungen ab, macht ein „Check-in“, formatiert eine ALF-Nachricht und sendet sie an den ALF Event Manager. Anschließend lässt der Event Manager den (BPEL-)Prozess-Flow laufen, der Daten aus der Nachricht nimmt, führt ein „Check-in“ im SCM-System des Architekten durch, modifiziert die Task-Liste des Architekten in seinem Issue-Tracking-System (ITS) und beginnt den Prozess-Flow, der mit dem Compliance-Prozess assoziiert ist, wobei er möglicherweise das erste Compliance-Tool auf dem Check-in-Code zur Hilfe nimmt, während er dem Compliance Officer die Notwendigkeit signalisiert, den Output zu reviewen.

Die Mehrzahl der ALF-Architekturen würde ebenfalls zulassen, dass der Compliance-Prozess in seinem eigenen ALF Event Manager modelliert wird, und der erste Event-Manager würde den Compliance-Prozess mit seiner ersten Nachricht ausgeben.

Software als gemanagter Business-Prozess

Es gibt drei Gründe, warum ein ALF-Projekt so vielversprechend für die Applikationsentwicklungs-Community ist:

  • Die moderne Organisation braucht Flexibilität, um jedwede Tools oder Prozesse, die sie benötigt, auf ihren eigenen Fahrplan übernehmen zu können (Incremental Adoption), ohne dabei durch verkäuferspezifische Integrationsanforderungen eingeschränkt zu werden.
  • Die vielfältigen heterogenen Tools, die innerhalb eines komplexen Unternehmens zu finden sind, müssen den gewünschten Prozess abbilden, nicht umgekehrt.
  • Schließlich muss das Management des Entwicklungsprozesses mit den Prozess-Management-Techniken, die in anderen Gebieten eines modernen Unternehmens angewandt werden, kompatibel sein.

Die Zugkraft von ALF wächst in demselben Maß wie auch die Größe der Entwicklungsorganisation wächst. Die traditionelle Komplexität der Applikationsentwicklungs-Umgebung ergibt sich aus der Zahl der Menschen multipliziert mit der Zahl der Prozessschritte multipliziert mit der Zahl der Tools. ALF vereinfacht die Angleichung der Anzahl der Menschen mit der Anzahl der ALF Service Flows. Jeder ALF Service Flow kann eine Vielzahl von einzelnen Prozessschritten kombinieren. Die Verkapselung von ALF im Hinblick auf Tool- und Prozess-Flow verringert die Applikationsentwicklungs-Komplexität auf dramatische Weise, wobei die Management-Kontrolle, die Sichtbarkeit und in dem Maß, in dem der definierte Prozess effektiv ist, die tatsächliche Produktqualität ansteigen.

Der Einfluss von ALF im Hinblick auf die EAI-Infrastruktur und -Techniken wird es den Nutzern ermöglichen, diese in ihre Enterprise Dashboards und ihre Prozess-Management-Infrastruktur zu integrieren. Der Gebrauch von Web Services und BPEL macht die ALF-Infrastruktur ideal für Organisationen, die über Geographien und Zeitzonen verteilt sind, und erlaubt die transparente Entwicklung paralleler Systeme: In unserem Beispiel kann ein dritter Parallelprozess (vielleicht ein QA-Prozess) an jedem Ort und an jedem Server integriert werden, ohne dass dadurch der Originalprozess beeinflusst wird.

Die Zukunft von ALF

Das Versprechen von ALF an die Applikationsentwicklungs-Community ist eine bessere Produktivität durch besseren Zugang zu Tools und Prozessen, Compliance und Flexibilität. ALF wurde von der Tools- und Methodologie-Verkäufer-Community inspiriert und ursprünglich gegründet. Was ALF heute braucht, ist die Unterstützung der Anwendungsentwickler selbst. Es müssen Adapter geschrieben, Dashboards und Instandhaltungs-Tools designt, Prozesse kodiert und Tests in allen Bereichen durchgeführt werden.

Das ALF-Komitee hat im März 2006 ein sog. Working Proof of Concept vorgelegt, in dem Service Flows innerhalb der üblichen Entwicklungs-Tools (Source-Kontrolle, Build, Test und Issue Tracking) mit eingeschlossen waren. Die aktuellen Planungen verlangen, dass die Version 1.0 von ALF bis Ende 2006 ausgeliefert wird. Diese wird eine auch Referenzimplementierung des ALF-Event-Managers sowie ein Eclipse-Plug-in enthalten, das für eine einfachen Verwaltung der ALF Service Flows und des Event Mapping sorgt. Das Release wird darüber hinaus Entwurfs-Vokabulare für die üblichen Tools enthalten, zu denen auch Souce Control, Build- und Issue Management gehören.

Lorne Cooper ist Präsident von AccuRev Inc. (www.accurev.com). AccuRev stellt einen Best-of-Breed-Ansatz für das Application Lifecycle Management (ALM) zur Verfügung, der sich insbesondere auf das Software-Konfigurationsmanagement (SCM) für verteilte und parallele Entwicklung konzentriert.
Matthew Laudato ist Engineering Manager für Anwendungsentwicklung bei AccuRev. Er verfügt über einen Bachelor of Science in Physik von der SUNY Stony Brook und einen Master of Science von der Universität von Wisconsin, Madison.
Geschrieben von
Lorne Cooper und Matthew Laudato
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.