Mike Milinkovich und Ricco Deutscher im Gespräch

„Man gewinnt, indem man loslässt“ – Gespräch über Eclipse und Open Source

Die Redaktion

Mit Open Source entstehen neue Unternehmensmodelle und die Zusammenarbeit gewinnt beim Verhältnis der Unternehmen untereinander zunehmend an Bedeutung. Immer mehr Unternehmen erkennen den Wert, den ihnen Open Source – und zwar die Technologie und die Community! – bieten kann. Sopera ist eines dieser Unternehmen und hat das Projekt „Swordfish“ mit der Eclipse Foundation Open Source veröffentlicht. Wir haben die Gelegenheit genutzt, mit Mike Milinkovich, Executive Director der Eclipse Foundation, und Ricco Deutscher, Geschäftsführender Gesellschafter von Sopera, ein Gespräch über das Projekt und den nahenden Wandel der Software-Industrie zu führen.

Eclipse Magazin: Ricco, ihr bei Sopera seid dabei, die Open-Source-Veröffentlichung eures Projekts Swordfish vorzubereiten. Ist das letztlich nur ein weiterer ESB (Enterprise Service Bus) oder steckt mehr dahinter?

Ricco Deutscher: Man muss zwischen der Open-Source-Veröffentlichung der SOA Suite Sopera und des Eclipse-Projekts Swordfish unterscheiden. Sopera basiert auf dem SOA-Framework der Deutschen Post und umfasst eine komplette und praxiserprobte SOA-Suite. Die Suite enthält eine sehr leistungsfähige Tooling-Plattform, die Eclipse WTP nutzt, sowie einen Service-Editor, einen Policy-Editor, einen Deploying-Mechanismus und einen ESB und deckt damit den gesamten SOA-Lebenszyklus ab. Swordfish ist das Framework für einen ESB. Das neue an diesem Framework ist, dass es als erstes Open-Source-Projekt die drei wichtigen Standards SCA, JBI und OSGi vereinheitlicht. Es bietet darüber hinaus eine verteilte Peer-to-Peer-Architektur und Policies, was nur wenige SOA-Plattformen umfassen

EM: Ist es möglich, Plug-ins oder Add-ons hinzuzufügen?

Deutscher: Sopera basiert bereits auf einem Plug-in-Konzept und diese Eigenschaft bringen wir jetzt in das neue Eclipse-Projekt ein. Die Erfahrung aus der Praxis zeigt, dass eine SOA mit den Anforderungen mitwachsen können muss. Ein Komponentenkonzept bietet dabei nicht nur Kostenvorteile, sondern ist auch leichter zu beherrschen und verringert nicht zuletzt die Abhängigkeit von einzelnen Herstellern. Kommerzielle Händler bieten ihre SOA-Plattformen hingegen meist integriert an. Das bedeutet aber, dass, wenn man eine BPEL Engine haben möchte, die anderen Komponenten auch gekauft werden müssen, sodass man keine Wahl hat. Die Idee des Sopera-Frameworks ist aber, Freiheit und Flexibilität zu bieten und nur das zu benutzen, was man wirklich braucht. Das Gute dabei ist, dass alle notwendigen Plug-ins bereits Open Source verfügbar sind. Sollte der User aber ein kommerzielles Produkt brauchen, kann er das austauschen und problemlos als Plug-in betreiben.

EM: Gibt es Schlüsselkomponenten, die sozusagen Out-of-the-Box mitgeliefert werden?

Deutscher: Ja, gibt es. Die Ende des Jahres gelieferte Open-Source-Distribution baut auf einer ganzen Reihe von Open-Source-Plug-ins auf. Zum Beispiel für das Messaging Joram, die BPEL Engine Apache ODE (Orchestration Director Engine) sowie Active BPEL als Open-Source-Alternative. Wir werden z.B. auch einen BPEL-Editor von Elipse mitliefern. Die Idee von Sopera ist, die besten SOA-Komponenten, die auf dem Markt sind, zu identifizieren und daraus bedarfsgerechte Pakete für den Anwender zu schnüren. Dabei bieten wir sowohl Open- als auch Closed-Source-Komponenten an. Auf der kommerziellen Seite kooperieren wir z.B. mit Oracle, die ihre Produkte damit auch an Sopera-Kunden verkaufen können. Von dieser Strategie profitieren auch Anwender, die zum Beispiel schon bestimmte kommerzielle Komponenten einsetzen, wie etwa IBM MQ für das Messaging. Mit Sopera können sie diese einfach weiter nutzen.

EM: Eine Frage, die euch sicherlich häufig gestellt wird: Wie wollt ihr bei Sopera eigentlich euer Geld verdienen?

Deutscher: Ganz einfach: Indem wir Dienstleistung anbieten. Das Unternehmensmodell von Sopera ist vergleichbar mit dem von SuSE, Red Hat oder JBoss. Wir bieten Support- und Wartungsverträge, technisches Consulting und Training an.

Milinkovich: Integration und Zertifizierung ist definitiv eine Dienstleitung. IT-Konsumenten haben kein Problem damit, Geld für eine solche Leistung auszugeben, wenn sie dafür den entsprechenden Gegenwert erhalten. Es war nie ein Problem, CEOs dazu zu bewegen, Geld für Software und Services zu zahlen. Was sich aber ändert, ist deren Einstellung hinsichtlich der Anbieter, mit denen sie zu tun haben. Es gibt da den Anbieter, der eben alles selber macht, oder denjenigen, der einen Integration Stack und entsprechend mehr Flexibilität bietet.

EM: Mike, welche Rolle spielt das Swordfish-Projekt für die Eclipse Foundation?

Milinkovich: Es ist auf jeden Fall ein sehr wichtiges Projekt hinsichtlich der Reife von Eclipse als Anwendungs- und Integrations-Plattform für Runtimes. Ganz offensichtlich ist eine serverseitige Runtime sehr wichtig, um aus Eclipse eine Anwendungs- und Integrations-Plattform für Runtimes zu machen und das in die Realität umzusetzen.
Bei Swordfish ist natürlich bemerkenswert, dass schon eine Menge Code mitgebracht wird, der bereits in echten Deployments genutzt wurde. Aber es gibt noch eine Menge zu tun, um auf der Strategic Roadmap der Foundation stehen zu können. Die bevorstehenden Aufgaben mögen größer und kleiner sein, aber sie sind alle ein Teil des Prozesses, den ein Projekt durchlaufen muss, um ein voll entwickeltes Eclipse-Projekt zu werden. Realistisch gesehen wird es noch etwa ein Jahr dauern, bis es soweit ist.

EM: Wird dieses Projekt den Charakter der Foundation verändern?

Milinkovich: Das Projekt ist wie gesagt ein Teil des Prozesses, der aus der reinen Tools- und Integrations-Plattform Eclipse eine serverseitige Anwendungs- und Integrations-Plattform machen wird, aber es ist nicht das einzige Projekt, das in diese Richtung geht. Es gibt z.B. auch das Projekt von Oracle für die Eclipse Persistence Services, das auf der sehr reifen TopLink-Technologie basiert, was auch eine serverseitige Idee ist. Es gibt auch noch weitere Projekte und all diese tragen dazu bei, dass aus Eclipse eine Anwendungs- und Integrations-Plattform wird.
Wirklich cool ist jedoch bei Eclipse, dass all diese Technologien eine gemeinsame Runtime teilen, ein gemeinsames Komponentenmodell und ein gemeinsames Set an servicebasierten Attributen, die bestimmen, wie Komponenten zusammengestellt werden und miteinander kommunizieren etc. Und all das entwickelt sich durch zunehmende Investitionen von verschiedenen Unternehmen innerhalb von Eclipse.
Die einzige Organisation, die neben uns die Vision eines gemeinsamen Komponentenmodells und einer gemeinsamen Plattform hat, die von Devices über Clients bis hin zu Servern reicht, ist Microsoft. Der Unterschied ist aber, dass sich das bei Eclipse alles von selbst innerhalb der Community entwickelt. Und das ist wirklich ziemlich cool!

Geschrieben von
Die Redaktion
Kommentare

Schreibe einen Kommentar

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