Nicht ganz perfekt, aber sehr erfolgreich

Feature | 12. Mai 2003 von admin 0

Die Zusammenarbeit mit der internationalen Java-Entwicklergemeinde wird seit 1995 durch den Java Community Process (JCP) organisiert. Seitdem hat sich dieser von einem informellen Sun-fokussierten Ablauf zu einem formalisierten Prozess entwickelt, der von Vertretern vieler Gruppen innerhalb der Java-Gemeinde mitgetragen wird. An dem Prozess nehmen mittlerweile über 500 Unternehmen und Einzelpersonen teil. Dazu zählen Branchenriesen wie BEA Systems, Cisco Systems, IBM, Oracle, Sony und SAP, aber auch die Apache Software Foundation, die die Open-Source-Gemeinde vertritt. Laut Onno Kluyt, Leiter des JCP Program Office bei Sun Microsystems, entwickelt sich JCP ähnlich wie Software weiter – indem Produktversionen geplant und ermittelt wird, wie viel Veränderung der Markt verträgt. So sei etwa die Möglichkeit für Open-Source-Entwickler, Java-Standards zu implementieren, eine der zentralen Änderungen bei der Einführung von JCP 2.5 im vergangenen Oktober gewesen. „Wir haben verschiedene Änderungen vorgenommen, um das zu ermöglichen und zu unterstützen“, so Kluyt. „Als Ergebnis sehen wir zunehmend kompatible Implementierungen von solchen Organisationen.“
SAP möchte mit dem Engagement in Technologieforen wie dem JCP ihren Kunden Einblicke in geschäftsrelevante Technologien weitergeben. Im Vordergrund für den Kunden stehen dabei immer die Gesamtbetriebskosten (Total Cost of Ownership, TCO) der SAP-Lösungen. Michael Bechauf, als Vice President bei SAP zuständig für den Bereich derJava-Architektur und -Standards, ist für SAP neuerdings Mitglied des Executive Committee der J2SE/J2EE Platform (Java 2 Standard Edition/Java 2 Enterprise Edition). Das Executive Commitee steuert die Entwicklung der Java-Technologie im JCP. Es ist dafür verantwortlich, Spezifikationen zu genehmigen und Unstimmigkeiten zwischen den Spezifikationen und den zugehörigen Test-Versionen zu beheben.

Ein neues Modell der Zusammenarbeit

Die objektorientierte Programmiersprache Java wurde 1995 veröffentlicht. Bereits zwei Jahre später, 1997, verfügte SAP über ein Java-basiertes Frontend, auf dem alle SAP-Anwendungen lauffähig waren. Der Zielsetzung von SAP, ihre Anwendungen auf allen größeren Betriebssystemen und Datenbanken bereitzustellen, kam der Java-Ansatz „write once, run everywhere“ sehr entgegen. Bechauf: „Der Erfolg von Java ist bemerkenswert – was in Gestalt kleiner Applets innerhalb HTML-basierter Browser begann, hat sich zu einer Strömung entwickelt, die die gesamte Software-Branche erfasst hat. Java ist jedoch mehr als einfach nur eine neue Technologie auf dem Markt. Java brachte die Branche dazu, ein neues Modell der Zusammenarbeit zu praktizieren. Softwareanbieter definieren gemeinsam Standards für die Erstellung und Bereitstellung von Anwendungen. Das geht nur, wenn sich alle Hersteller über alle Betriebssystemplattformen hinweg uneingeschränkt zu offenen Standards bekennen und die jeweils individuelle Anwendung gegen allgemein akzeptierte Application Programm Interfaces (APIs) programmieren.“
Bechauf betont, dass SAP-Kunden die Beteiligung des Unternehmens an der Entwicklung von Java-Standards stark befürworten und von SAP eine Unterstützung von offenen Systemen fordern. Das gilt auch für die Art und Weise, wie Anwendungen entwickelt, bereitgestellt, unterstützt und aktualisiert werden. „SAP implementiert dabei in der Industrie generell akzeptierte und bewährte Verfahren ”, erklärt Bechauf. „Unsere Kunden fordern jedoch auch von uns, dass wir im Rahmen unserer Rolle als „Trusted Advisor“ Standards vorantreiben und unsere Erfahrungen zum Nutzen der gesamten Software-Branche einbringen. SAP kann daher nicht nur passiver Beobachter sein, wenn es um Branchenstandards geht, sondern muss aktiv zu deren Gestaltung beitragen.“ Eine Forderung, der SAP seit 2001 mit der Mitgliedschaft im JCP nachkommt.

Produktivität im Fokus

Heute ist SAP an mehr als 40 Java Specification Requests (JSRs) in so unterschiedlichen Bereichen wie Web-Services, Business Process Management, bei Portalen, Content Management, Java Connectors, XML, Persistenz und Java Virtual Machine Management beteiligt. SAP steht, so Bechauf weiter, permanent mit den anderen Mitgliedern des JCP-Executive Committee in Verbindung, um von eigener Seite Anregungen und Belange einzubringen sowie Prozessverbesserungen bei JCP zu erörtern. Besonders die Komplexität und Produktivität der Anwendungsentwicklung auf J2EE ist hier besonders wichtig für SAP, hebt Bechauf hervor. SAP sei in Hinblick darauf der Ansicht, dass sich Java-Entwickler zu sehr mit Details auf Systemebene befassen müssen, die sie von dem eigentlichen betriebswirtschaftlichen Problem ablenken.
Mit dem Augenmerk von SAP auf die Gesamtbetriebskosten ihrer Lösungen rücken ebenfalls die Themenkreise Interoperabilität, Supportbarkeit und Administrierbarkeit von Java-Systemen ins Zentrum des Interesses. „Mit unseren Erfahrung können wir durch SAP-Beteiligung bei einer Reihe zentraler Initiativen erheblich zur Verbesserung der Java-Plattform beitragen, wenn es um Total Cost of Ownership geht”, sagt Bechauf. In diesem Zusammenhang weist Bechauf darauf hin, dass die J2EE-Plattform nach Ansicht der SAP noch Mängel gerade bei der Supportbarkeit und Entwicklungsproduktivität aufweist. SAP-Systeme könnten daher heute nur mit Erweiterungen zusätzlich zur J2EE-Basis ausgeliefert werden. „Dabei stellen wir in jedem Fall sicher, dass das Design dieser Erweiterungen bestehenden Standards entspricht. SAP verpflichtet sich außerdem, diese Erweiterungen über das JCP zu standardisieren. Dadurch haben SAP-Kunden die Sicherheit, dass ihre Anwendungen in Übereinstimmung mit den neuesten Industriestandards entwickelt und unterstützt werden.“

Werkzeuge für das J2EE Software Lifecycle Management

SAP wird beispielsweise ausgereifte Werkzeuge für das J2EE Software Lifecycle Management und die teambasierte Entwicklung in ihren Produkten ausliefern. Diese sollen im Lauf des Jahres über den JCP standardisiert werden. Darüber hinaus wird SAP laut Bechauf daran mitwirken, eine Enterprise Services Architecture zu definieren, mit der sich hinsichtlich Web-Services echter Nutzen für die Kunden schaffen lässt. Heute verbergen sich hinter Web-Services noch keine Lösungen, sondern bestenfalls eine zukunftsweisende Technologie. Ebenso wie es das Internet Anwendungen ermöglicht hat, sich in neue Bereiche zu entwickeln, werden Web-Services Anwendungen hervorbringen, mit denen sich neue Arten von Geschäftsprozessen unterstützen lassen. „Wir glauben, dass Anwendungen in Zukunft grundlegend auf wohldefinierten Services aufgebaut sein und auf offenen Standards basieren werden“, so Bechauf. „Sie dienen künftig dazu, funktionsübergreifende Geschäftsprozesse zu unterstützen. Deshalb ist eine Beteiligung von SAP bei den Standardisierungsbemühungen von Web-Services sehr wichtig für uns.“
Für Randy Heffner, Analyst bei Forrester Research, ist der JCP insofern einzigartig unter den Standardisierungsgremien, als er eine Referenzimplementierung und einen Kompatibilitäts-Tests fordert. „Damit lässt sich für die verschiedenen Java-Implementierungen einen hohen Grad an Konsistenz gewährleisten“, so Heffner. „Der JCP ist eine komplexe Mischung aus den Interessen der Java-Gemeinde und denen der Software-Anbieter.“ Für Heffner besteht eines der am meisten verbreiteten Missverständnisse zum Thema JCP darin, Sun steuere das Komitee alleine und sei auch Eigentümer der gesamten Java-Technologie. Dem ist jedoch nicht der Fall. Sun benötigte beispielsweise eine Lizenz von TimeSys, um Realtime Java implementieren zu dürfen. Der Grund: TimeSys war bei den Spezifikationen für Realtime Java federführend.

Eine Schwachstelle

Aus Heffners Sicht besitzt der JCP jedoch eine größere Schwachstelle: Es gibt keinen „Chief Architect“ für Java, der all die verschiedenen Initiativen in einer einheitlichen Richtung bündeln könne. „Viele Mitglieder beklagen sich, der JCP habe einfach zu viel um die Ohren – und erzeugt dadurch oft Verwirrung“, erklärt er. Wettbewerber innerhalb des JCP wie etwa BEA Systems, IBM und Oracle haben die Arbeit im JCP in Angriff genommen und Programme sowie Entwicklungsressourcen beigesteuert.
Edward Cobb, Vice President für den Bereich Architecture & Standards, vertritt BEA Systems als Mitglied des JCP-Exekutivkomitees. BEA habe sich, so Cobb, schon lange dafür engagiert, die Java-Standards voranzutreiben und einzuführen, und dies wegen der Mitgliedschaft des Unternehmens an JCP schneller umgesetzt als Andere. „BEA ist was die Unterstützung von Java und die Weiterentwicklung von Java-Standards betrifft eine der am stärksten engagierten Firmen in der Software-Branche“, erklärt Cobb – was darauf zurückzuführen ist, dass der Großteil des Ertrags des Unternehmens Produkten zuzurechnen ist, die auf den Java-Standards basieren.
BEA ist zusammen mit Unternehmen wie Hewlett Packard, IBM, Oracle und SAP im J2SE/J2EE-Executive Committee (Java 2 Standard Edition/Java 2 Enterprise Edition) aktiv. Darüber hinaus ist BEA ebenfalls Mitglied des J2ME-Executive Committee (Java 2 Micro Edition), an dem Firmen wie Nokia und Palm beteiligt sind. „Standards sind wichtig für BEA, weil sie wichtig für unsere Kunden sind. Diese verlangen Standards, und wir glauben, dass unsere Beteiligung zum Wachstum des Marktes beiträgt“, so Cobb. BEA leitet derzeit rund drei bis fünf JSRs und ist an mehr als 20 JSR-Expertengruppen beteiligt. Die Bandbreite reicht von der Anwendungstechnik bis hin zu Core XML-Technologie und der J2EE-Plattform.

Laufende Diskussionen über die Entwicklung

Cobb erklärt, dass derzeit im JCP diskutiert wird, wie der Prozess zur Erstellung von Java-Standards zu gestalten sei. Ein JSR durchläuft mehrere Meilensteine – Spezifikation, Referenzimplementierung und Tests, bevor ein neuer Java-Standard entsteht. „Es ist zwar nicht zulässig, neue Java-Standards auszuliefern, bevor sie genehmigt und vollständig sind. Dennoch ist aus Gründen der Wettbewerbsfähigkeit jedes Unternehmen bestrebt, das Produkt schnellstmöglich auf den Markt zu bringen“, so Cobb.
Auch Mark Thomas, Program Director, Java Technology, IBM e-business Integration Technologies, der IBM im J2SE/J2EE-Executive Committee vertritt, glaubt, dass weitere Veränderungen im Java Community Process dringend notwendig sind. Er schlägt vor, die Zusammenarbeit mit anderen Standard-Initiativen außerhalb des Java Community Process zu verbessern und betont, dass Mitgliedern der Community mehr Mitspracherecht bei der Gestaltung des Prozesses eingeräumt werden muss. Laut Thomas ist für IBM-Kunden die Implementierung von im Entstehen begriffenen Standards wie XML und Web-Services sehr wichtig. „Damit sich effektiv arbeiten lässt erfordern die Standards eine starke Zusammenarbeit zwischen den Softwareanbietern. Darum haben wir darauf gedrängt, die Einführung dieser Technologien durch die Java-Gemeinde voranzutreiben“, erläutert Thomas. Er ergänzt, dass IBM als „Specification Lead“ für den Java Specification Request 109 „Implementing Enterprise Web Services“ fungiert hat, ebenso für JSR 104 (XML Trust Service) und JSR 106 (XML Digital Encryption).
IBM beteiligt sich an über 100 anderen JSRs und liefert, so Thomas, die Spezifikationen für etwa 20 davon. „Die IBM befürwortet den offenen Umgang miteinander innerhalb der Java-Gemeinde. Diese Kultur fördert eine unternehmensübergreifende Zusammenarbeit und verhindert die unangemessene Einflussnahme einzelner Unternehmen oder Unternehmensgruppen“, erklärt Thomas. IBM hatte auch eine Schlüsselrolle bei der Entwicklung der neuesten JCP-Aktualisierungen inne. Laut Thomas strebt IBM auch weiterhin Verbesserungen hinsichtlich neuer offener Standards an und möchte auch dazu beitragen, die Java-Gemeinde bei der Weiterentwicklung der Java-Sprache und Technologien weiterzubringen. Thomas betont, dass Unternehmen, die plattformübergreifende, industrietaugliche Programmierumgebungen benötigen, um so schneller Java-Technologien einführen würden, je stärker diese mit koordinierten, branchenweiten Bemühungen und nicht nur mit einer einzelnen, federführenden Firma in Verbindung gebracht würden.

Der Prozess ist nicht perfekt, aber sehr erfolgreich

Randy Heffner von Forrester schließt mit der Anmerkung, Sun habe sich vor einiger Zeit den Spott von Microsoft zugezogen, da Sun die Kontrolle über Java nicht an ein Standardisierungsgremium abgetreten habe. „Microsoft hatte damals für sich in Anspruch genommen, C# und .NET für ein Standardisierungsgremium freigegeben zu haben“, so Heffner. „In Wirklichkeit jedoch hatte Microsoft weniger als 10 Prozent des .NET-Framework zur Standardisierung zur Verfügung gestellt. Damit hat meiner Ansicht nach .NET keinen Anspruch darauf, als Standard zu gelten – ganz im Gegensatz zu Java. Die Anbieter sind motiviert, neue Aktivitäten über das JCP zu sponsern“, so Heffner. „Der Prozess ist nicht ganz perfekt, funktioniert bei der Entwicklung von Java an verschiedenen Baustellen jedoch sehr erfolgreich.“

Barbara Gengler

Leave a Reply