Interview mit Michael Fiedler und Steve Speicher über Eclipse Lyo

Eclipse Lyo: Toolentwicklung verlagert sich ins Web und in die Cloud

Steve Speicher und Michael Fiedler leiten gemeinsam das Projekt Eclipse Lyo, bei dem es darum geht, Tools für die OSLC (Open Services for Lifecycle Collaboration) Spezifikationen bereit zu stellen. Im JAXenter-Interview sprechen sie über den Stand der Dinge im Lyo-Projekt und das neue Paradigma der Tool-Entwicklung im Web.

Eclipse Magazin: Mit welchen Argumenten würdet ihr versuchen, ein Unternehmen davon zu überzeugen, den OSLC (Open Services for Lifecycle Collaboration [s. Kasten]) beizutreten?

Michael Fiedler/Steve Speicher: Das hängt von der Rolle ab, die der User bzw. die Organisation in der Lebenszyklusintegration spielt. Ein Toolentwickler oder -anbieter kann sich dank einer offenen Integration wie bei den OSLC auf seine Kernkompetenzen konzentrieren, weil er zur Entwicklung seiner Software wiederverwendbare und offene Komponenten wie Lyo nutzen kann, die mit anderen Tools – sowohl innerhalb als auch außerhalb des eigenen Wirkungsbereichs – interoperabel sind. Dadurch spart man Zeit und Kosten.

Für Tooluser reduzieren sich durch die offene Integration die Unübersichtlichkeit und die Risiken, die immer komplexer werdende Softwareinfrastrukturen nach sich ziehen. Das steigert für viele interne und externe Stakeholder den Wert der Software.

Systemintegratoren können ihre Energie und Ressourcen darauf ausrichten, hochwertige individuelle Anpassungen vorzunehmen, dem Kunden dadurch einen höheren geschäftlichen Nutzen zu bieten und damit eine höhere Kundenzufriedenheit zu erzielen.

Das europäische CESAR-Projekt [1] hat ein großartiges Video produziert [2], in dem Probleme bei der Toolintegration im Bereich Systems Engineering aufgezeigt werden, und die Vorteile, die man gewinnt, wenn man diese Probleme mithilfe eines Linked-Data-Ansatzes wie dem der OSLC angeht.

Insgesamt werden Tools durch einfache und flexible Integrationen mit den OSLC für fast jeden nützlicher und wertvoller.

OSLC
Die Open Services for Lifecycle Collaboration ist eine 2008 u. a. von IBM gegründete offene Community, die sich das Ziel gesteckt hat, die Integration von Lifecycle-Tools zu vereinfachen. Nach dem Vorbild der WWW-Architektur verfasst sie Spezifikationen, die ein standardisiertes Teilen von Daten zwischen ALM-Tools ermöglichen sollen. Mehr Informationen unter http://open-services.net/.

EM: Was macht die Integration von Lifecycle-Tools denn so schwierig?

Fiedler/Speicher: Die bisherigen Ansätze hatten immer einige Nachteile. Jedes einzelne Werkzeug brachte in der Regel sein eigenes API mit – oft nicht öffentlich und ohne Unterstützung –, um auf seine Daten zuzugreifen. Das Ganze war meist an eine bestimmte Technologie, also Programmiersprache oder Plattform, gebunden. Wenn man dann versucht, viele verschiedene Tools von verschiedenen Anbietern miteinander zu integrieren, ist das Ergebnis ein Netz aus fragilen Punkt-zu-Punkt-Integrationen. Es wird schwierig, bestehende Tools durch neue zu ersetzen. Selbst der Versuch, bestimmten Tools ein Upgrade zu verpassen oder sie zu migrieren, kann durch die Abhängigkeiten von speziellen API-Versionen scheitern.

Es muss ein Umdenken stattfinden, was das Zusammenspiel von Tools angeht. Die OSLC schlagen einen Ansatz vor, der mit der Funktionsweise des Internets vergleichbar ist: ein Modell, das auf einheitlichem Ressourcenzugang basiert, mit URLs und gemeinsamen minimalen Datenformaten, dabei aber erweiterbar ist. Es sollen RESTful-Protokolle verwendet werden, die nicht von einer bestimmten Programmiertechnologie abhängig sind. Statt Daten zwischen Tools zu synchronisieren oder hin- und herzukopieren, verwenden die OSLC Verlinkungen, um ein Netz aus Lebenszyklusdaten aufzubauen. Die OSLC definieren auch ein paar einfache Protokolle, um Web-UI-Komponenten für Szenarien wie Ressourcenpreviews, -erstellung und -auswahl zu teilen.

Der OSLC-Ansatz sieht ein Minimum an Spezifikationen vor, mit denen man die von den Arbeitsgruppen entwickelten Integrationsszenarien angehen kann. Dadurch wird ein weiteres Problem vermieden, dem sich frühere Vorstöße in Richtung Interoperabilität stellen mussten: mühsame Implementierung und Unterstützung durch Überspezifikation.

EM: Vor einem Jahr haben wir mit dir, Steve, ein erstes Interview fürs Eclipse Magazin geführt [3]. Damals hattet ihr eine ziemlich klare Roadmap für 2012. Um dich zu zitieren: „erstens ein SDK für Java und andere Technologien – abhängig von den Interessen des jeweiligen Mitwirkenden – zweitens eine Referenzimplementierung für ausgewählte OSLC-Spezifikationen, drittens eine Testsuite für OSLC-Implementierungen, inklusive Compliance Reports, und viertens Beispiele bereits existierender Anwendungen, die OSLC-Integrationen ermöglichen (Adapter für Bugzilla, Excel u. a.)“.  Ist auf dem Weg zum 1.0-Release vergangenen Oktober alles nach Plan verlaufen?

Speicher: Lyo hat alle diese Ziele erreicht. Das Java-SDK wird gut angenommen, und verschiedene Organisationen verwenden die OSLC Testsuite, um ihre Implementierungen einzuschätzen. Die Beispiele sind ein guter Einstieg für Entwickler, denen die OSLC neu sind und die auf anfängliche Unterstützung angewiesen sind.

Der Bugzilla-OSLC-Adapter hat sich als besonders gelungene Demonstration der 1.0- und 1.1.-Features von OSLC4J erwiesen. Er wurde in einen Workshop aufgenommen und ist die Grundlage für das OSLC-Tutorial [4].

EM: Was waren bisher die größten Herausforderungen bei der Verbreitung der OSLC-Spezifikationen in der Eclipse-Community?

Fiedler/Speicher: Viele oder sogar die meisten Toolentwickler denken, die Eclipse-Community wäre nur zur Toolintegration auf dem Desktop in einer Entwicklungsumgebung da. Wir verbringen viel Zeit damit, zu erklären, dass Lyo kein Eclipse-Plug-in ist. Lyo stellt Werkzeuge zur Toolintegration bereit, die mit vielen verschiedenen Eclipse-Technologien kompatibel sind. Zur Toolentwicklung gehört viel mehr, als Java-Code zu schreiben und ihn mit Eclipse auf dem Desktop zu debuggen. Toolentwicklung verlagert sich ins Web und in die Cloud. Orion, Hudson und Lyo sind sehr gute Beispiele für Eclipse-Projekte, die auf diese Umgebungen ausgerichtet sind.

EM: Gab es in der OSLC-Community im vergangenen Jahr starke strukturelle Veränderungen oder ist sie einfach nur größer geworden?

Fiedler/Speicher: Es gab einige wichtige Entwicklungen. Die erste war eine Anpassung der OSLC-Governance, die im Juni 2012 in Kraft trat. Ziel ist es, den Communityzuwachs zu verstärken. Die Community soll außerdem ihre eigenen Vorgehensweisen bestimmen, und die Weitergabe von OSLC-Spezifikationen an Organe, die Standards definieren, soll ermöglicht werden. Also wurden verschiedene Änderungen umgesetzt: Erstens wurde ein OSLC-Führungskomitee ins Leben gerufen, ein ausführendes Organ, bestehend aus Repräsentanten aus sechs Mitgliedorganisationen [5]. Das Führungskomitee entscheidet über Vorgehensweisen, beispielsweise was die Gründung von Arbeitsgruppen angeht, oder über die Zustimmung zu finalen Spezifikationen. Auch unternehmerische Entscheidungen bezüglich des Marketings und der Communityrekrutierung übernimmt es. 

Zu den weiteren Änderungen der Governance zählen neue Mitgliedervereinbarungen sowie Vereinbarungen zur Teilnahme an den Arbeitsgruppen, mit klareren Abläufen im Umgang mit intellektuellem Eigentum.

Das OSLC-Führungskomitee hat neulich eine Strategie mitgeteilt, nach der eine Spezifikationsentwicklung und Standardisierung bei der OASIS [Organization for the Advancement of Structured Information Standards, Anm. d. Red.] angestrebt wird. Das scheint der natürliche nächste Schritt für die OSLC und ihre heranreifenden Spezifikationen zu sein.

Außerdem sind einige Mitglieder der OSLC-Arbeitsgruppe in der W3C Linked Data Platform aktiv [6]. Einige Konzepte aus der Linked-Data-Plattform-Spezifikation werden in die nächste Überarbeitung der OSLC-Kernspezifikation einfließen.

EM: Haben sich im vergangenen Jahr besonders nennenswerte Unternehmen der OSLC angeschlossen?

Fiedler/Speicher: In der OSLC-Community gibt es weder besonders wichtige noch weniger wichtige Mitglieder oder Teilnehmer. Auf der Website ist eine vollständige Liste an teilnehmenden Organisationen [7] und Implementierern [8] zu finden.

Was Lyo angeht: Eine Sache, die eure Leser interessieren könnte, ist, dass Lyo-Mitwirkende angefangen haben, mit dem Eclipse-Hudson-Team an einer Implementierung des OSLC Automation Providers für Hudson zu arbeiten. Das lässt sich in Bug 398226 [9] mitverfolgen.

EM: Welche Features sind im 1.1 Release von Lyo hinzugekommen und wozu?

Fiedler/Speicher: Ein neues Client-API für Entwickler. Das war die meistersehnte Verbesserung. Der Kern des API vereinfacht Interaktionen mit üblichen OSLC-Ressourcen wie den Service-Provider-Verzeichnissen und Service-Providern. Es stellt auch eine Java-Repräsentation für andere OSLC-Ressourcen wie Change Requests, Test Plans und Anforderungen bereit, außerdem Methoden, mit denen sich die Objekte als RDF serialisieren und deserialisieren lassen.

Mehrere Bibliotheken sind dazugekommen, und eine Webanwendung, um OSLC-Implementierungen OAuth-Unterstützung hinzuzufügen. OAuth ist ein beliebtes Authentifizierungsprotokoll, aber die korrekte Implementierung ist nicht immer leicht. Die neuen Lyo-Bibliotheken vereinfachen das. Die Webanwendung enthält einige vorgefertigte Tools, die bei Delegated Logins und der Administration von OAuth Tokens helfen.

Eine OSLC Query Library ist ein weiterer, vielfach gewünschter Zusatz. Die Library stellt APIs für das Parsen und Verarbeiten der OSLC-Query-Syntax bereit, neben Beispielen. 

Verbesserungen in der Testsuite sind auch hinzugekommen. Die OSLC Testsuite wurde auf den neuesten Stand gebracht und enthält nun Tests für die neue OSLC-Automatisierungsspezifikation. Zu den Verbesserungen gehören auch erweiterte Requirement- und Asset-Management-Tests und ein paar kleinere Verbesserungen und Bugfixes.

EM: In eurem Projektplan steht, dass ihr SDKs für „andere Technologien neben Java“ bereitstellen wollt. Welche sind das im Einzelnen? Ihr erwähnt Perl, und ich meine, ich hätte etwas von Python und JavaScript gelesen …

Fiedler/Speicher: Perl, Python und JavaScript halten wir für die wichtigsten drei Technologien, zumal aus der Sicht eines OSLC-Nutzers. Skriptsprachen sind eine sehr gern gewählte Methode, wenn es darum geht, Integrationen schnell zu entwickeln. JavaScript ist wegen der wachsenden Popularität von Node.js für serverseitiges Scripting interessant. Wir versuchen gerade abzuschätzen, wie groß das Interesse an Libraries und Beispielen für Node.js ist. Es gibt, je nach Interessenlage und Mitwirkung, sicher noch mehr Möglichkeiten, was andere Technologien – PHP, Ruby etc. – betrifft.

EM: Die OSLC-Community hat neulich das OSLC4Net-Projekt angekündigt, das auf Microsofts Codeplex entwickelt wird. Würdet ihr sagen, dass man als Entwickler von Lifecycle-Tools in einem größeren – vielleicht sogar globalen – Kontext denken muss, um Toolinteroperabilität zu gewährleisten? Über die Grenzen einzelner Communitys und Ökosysteme hinaus?

Fiedler/Speicher: Auf jeden Fall. Toolintegration und -interoperabilität erfordern naturgemäß, dass Entwickler ihren Wirkungsbereich erweitern und zwingen sie oft dazu, sich aus ihrer Komfortzone hinauszubewegen. Kein einzelnes Ökosystem, ob kommerziell oder Open Source, kann all diese Probleme lösen. Initiativen wie die OSLC stellen technologieneutrale Lösungsansätze bereit. Wichtige Weichen werden aber auch in Communitys wie dem W3C und OASIS gestellt und im Open-Source-Bereich. Viele Linked-Lifecycle-Data-Projekte kommen aus Open-Source-Communitys wie Eclipse, Apache, Codeplex, GitHub und dergleichen. Jede Community hat einen eigenen Kollaborationsstil und eigene Probleme zu lösen.

EM: Ein weiterer Punkt in eurem Projektplan lautet: „eine Community aufbauen“. Könnt ihr genauer erklären, was ihr vorhabt?

Fiedler/Speicher: Eine Community aufzubauen bedeutet mehr als die bloße Anzahl an Lyo-Mitwirkenden und -Usern zu erhöhen. Es bedeutet, die Vielfalt innerhalb der Community und die Qualität der Beiträge und des Feedbacks zu erhöhen. Wir möchten möglichst viele Downloads erreichen, viele neue Fehlermeldungen und Verbesserungsanträge erhalten.

Es gibt viele verschiedene Parteien, die Tools entwickeln und auf Integration und Interoperabilität ausgerichtet sind: Toolanbieter, betriebsinterne Entwicklergruppen, Universitäten, Individuen und Open-Source-Projekte sind nur einige davon. Die OSLC sind eine breitere Community, die sich auf Lifecycle-Integration spezialisiert hat, und wir sehen das Lyo-Projekt als wichtigste Open-Source-Teilcommunity. Es ist ideal für die Zusammenarbeit geeignet. Vom Expertenwissen, der Erfahrung und den technischen Fähigkeiten einer bunt gemischten Gruppe von Mitwirkenden und Nutzern profitiert jeder.

Steve Speicher und Michael Fiedler leiten gemeinsam das Projekt Eclipse Lyo. Steve gehört der IBM Senior Technical Staff an und ist an der Ausarbeitung der W3C-Linked-Data-Platform-Spezifikation beteiligt. Als leitender Entwickler im IBM Change Management trägt er die Verantwortung für die Arbeitsgruppen OSLC Core und Change Management. Michael ist Senior Software Engineer bei IBM. Er leitet die OSLC Automation Workgroup, ist ein Mitglied der OSLC Core Workgroup und leitender Entwickler im IBM Quality Management. Außerdem agiert er als Projektleiter des Codeplex-Projekts OSLC4Net.

Kommentare

Schreibe einen Kommentar

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