CW: Unter dem Namen SOA Runtime Project (Codename Swordfish) entwickelt Eclipse das SOA-Framework der Deutschen Post weiter. Wie wichtig ist das Konzept der Service-orientierten Architektur innerhalb der Eclipse-Community?
MILINKOVICH: SOA spielt für uns eine bedeutende Rolle. Wir sehen Eclipse als eine Plattform, die sowohl unabhängige Softwarehäuser als auch führende Anwenderunternehmen einsetzen und in ihre eigenen Produkte und Applikationen integrieren können. Immer mehr dieser Unternehmen wollen auch SOA-Konzepte in der Softwareentwicklung nutzen. Für den weiteren Erfolg der Eclipse Community ist es sehr wichtig, dass wir diesen Bedarf nun mit dem SOA Runtime Project und einem SOA Tools Project abdecken können. Nach unserer Erfahrung sehen sich Softwareexperten zunehmend als SOA-Entwickler statt als Java- oder PHP-Programmierer: Sie bauen Services.
CW: Wo sehen Sie die größten Vorteile von Open-Source-Software gegenüber kommerziellen SOA-Paketen?
MILINKOVICH: Gegenwärtig liegt der größte Vorteil darin, dass die Software kostenlos ist. Mittelfristig hoffen wir, dass das überzeugendste Argument die Flexibilität der Open-Source-Systeme sein wird. Softwarehersteller wollen Unternehmen typischerweise vertikal integrierte Lösungen verkaufen. Diese funktionieren aber häufig nur mit einem bestimmten Messaging-System, bestimmten Datenquellen oder Authentifizierungssystemen. Wir sind überzeugt, dass Anwender Wahlfreiheit wollen. Aus der Sicht des Programmiermodells beispielsweise bieten wir ihnen eine einheitliche SOA-Laufzeitarchitektur, wie wir sie im Rahmen von Swordfish entwickeln. Gleichzeitig geben wir ihnen die Flexibilität, über unser Plug-in-Konzept Komponenten ihrer Wahl einzuklinken. Dieses Prinzip gilt übrigens für alle Eclipse-Projekte.
CW: Die kommerziellen Hersteller argumentieren, alle ihre Produkte basierten auf gängigen Standards. Damit ließen sie sich beliebig mit Systemen anderer Anbieter kombinieren.
MILINKOVICH: Sie sollten Ihren Softwarehersteller fragen: Sind Sie bereit, die Integrationsarbeiten zu übernehmen und zu garantieren, dass alle Komponenten zusammenarbeiten? Oder ist alles nur Theorie? Open Source und offene Standards sind aus meiner Sicht komplementär. Ein Standard kann aber niemals funktionierenden Softwarecode ersetzen.
CW: Unternehmen, die etwa das SOA-Framework der Deutschen Post einsetzen und mit diversen anderen Open-Source-Komponenten kombinieren möchten, fehlen häufig die notwendigen Fachkenntnisse. Was raten Sie diesen Anwendern?
MILINKOVICH: Zunächst müssen Sie sehen, dass das Swordfish-Projekt noch ganz am Anfang steht; es handelt sich um ein langfristiges Vorhaben, das sicher einige Jahre dauern wird. Wir können uns aber durchaus vorstellen, dass sich eine kleine Gruppe hochqualifizierter SOA-Entwickler die Software von Eclipse herunterlädt und damit ihrem Management aufzeigt, was möglich ist. Die Servicequalität wird wahrscheinlich anfangs noch nicht für geschäftskritische Einsätze ausreichen. In einem zweiten Schritt könnten Unternehmen aber auf dieser Basis Systeme entwickeln, die ihren anspruchsvollen Standards und Service Levels entsprechen. Hier könnten dann auch kommerzielle Anbieter ins Spiel kommen: Sie übernähmen den Support und die Wartung einer zertifizierten Konfiguration, die aus Open-Source- und kommerziellen Produkten besteht. Aus der Sicht eines CIO bedeutet das mehr Auswahl. Er kann zu sehr geringen Kosten Softwaremodule testen und sich dann für einen Service-Level entscheiden, der beispielsweise zu seinen geschäftskritischen Anwendungen passt.
CW: Es geht bei dem Open-Source-Framework also darum, die Eintrittschwelle für SOA zu senken?
MILINKOVICH: Richtig. Wenn später die Implementierung der SOA ansteht, treten kommerzielle Anbieter auf den Plan, auf die sich die Anwender verlassen können. Wir würden Swordfish gerne als Plattform sehen, die von möglichst vielen kommerziellen Herstellern genutzt und weiterentwickelt wird.
CW: Die großen Plattformanbieter wie Bea oder IBM dürften Eclipse Swordfish eher als Konkurrenz ansehen.
MILINKOVICH: Das mag sein. Ich glaube sie warten erst einmal ab und entscheiden dann, wie sie vorgehen. Einige werden sich unseren Code ansehen und prüfen, inwieweit sie ihn für eigene vermarktbare Produkte nutzen können. Ehrlich gesagt gehe ich davon aus, dass die Tage der Infrastrukturanbieter, die alles selbst entwickeln, gezählt sind. Langfristig kommen die Hersteller nicht umhin, ihre Strategie zu ändern.
CW: Im ESB-Bereich (Enterprise Service Bus, Anm. d. Red.) gibt es bereits eine Reihe von Open-Source-Produkten. Entwickeln sich solche Systeme nicht zu Commodity-Produkten wie beispielsweise Java Application Server?
MILINKOVICH: Soweit ist es noch nicht. Über kurz oder lang werden sich meiner Meinung nach aber alle Infrastrukturprodukte bis zu einem gewissen Grad zu Commodities entwickeln. Nehmen Sie das Beispiel der Application Server, wo vor allem IBM, Bea, Oracle und SAP miteinander konkurrieren. Kaufentscheidungen in diesem Segment fallen heute nicht mehr aufgrund von taktischen Erwägungen auf Produktebene. Vielmehr geht es darum, welche Geschäftsbeziehungen schon bestehen oder mit welchem Anbieter ein Unternehmen langfristig zusammenarbeiten will. Generell bin ich nicht ganz glücklich damit, dass Software als Commodity angesehen wird. Denn es wird immer Unterschiede zwischen einzelnen Systemen geben, nicht nur in technischer Hinsicht sondern beispielsweise auch bezüglich Markenbildung, Support und Wartung. Darüber können sich die Hersteller im Wettbewerb voneinander unterscheiden. Wenn sie bei der Plattformentwicklung zusammenarbeiten, wie es Eclipse ermöglicht, sparen sie Kosten und können ihren Kunden maßgeschneiderte Produkte auf dieser Basis anbieten.
CW: Inwieweit stärkt die Codespende der Deutschen Post die Position von Eclipse gegenüber Microsofts .NET-Framework?
MILINKOVICH: Wir konkurrieren mit Microsoft auf verschiedenen Ebenen. Das ursprüngliche Ziel von Eclipse war, ein Tool-Ökosystem aufzubauen, das Microsofts "Visual Studio" Paroli bietet. Inzwischen aber gibt es unter dem Eclipse-Dach auch Entwicklungsumgebungen für Embedded-Systeme, das SOA-Framework und vieles mehr. Wir decken fast alle Bereiche der Softwareentwicklung ab, von kleinsten Devices über Clients bis hin zu Servern. Damit positionieren wir uns auf breiter Basis gegen Microsofts .NET. (wh)
Mehr zum Thema Service-orientierte Architekturen finden Sie im SOA-Expertenrat der COMPUTERWOCHE.