|
|
 |
F A C H B E I T R A G Java-Standards: Mit der Verabschiedung des JSR 170 beginnt in der Content Management-Branche eine neue Ära
Ein Content Infrastructure-Markt wird entstehen
Mit der endgültigen Verabschiedung des Java-Standards "JSR 170" (Java Specification Request 170), der den einheitlichen API-Standard für den Zugriff auf Content Repositories definiert, werden die Spielkarten in der Content Management-Branche ab Juni 2003 neu gemischt. Content Management System-Player, die sich Java-konform geben wollen, müssen in Zukunft mit ihrem Repository dieses neue API unterstützen. Dies kostet Zeit, Mühe und viel Geld. Man braucht kein Hellseher zu sein, um vorherzusagen, dass viele CMS-Hersteller ganz auf die Entwicklung eigener Repositories verzichten und diese auf dem Markt von Anbietern hinzukaufen werden, die bereits ein JSR 170-konformes Repository besitzen. Zukünftige Entwicklungsgelder auf dem CM-Markt fließen also nicht mehr in die Entwicklung von unterschiedlichsten APIs oder gänzlich neuer Repositories, sondern sie werden investiert, um die Features der Applikation "Content Management" weiter zu entwickeln. Die Impulse, die von dieser Entwicklung ausgehen, werden dazu führen, dass in der IT-Branche ab Sommer 2003 ein neuer Markt entsteht, der Markt für Content Infrastructure.
Es war David Nüscheler, CTO von Day, der schon im Sommer des letzten Jahres den Finger in die offene Wunde legte. Die Content Management-Branche stehe am Scheideweg, befand der CTO. Wenn die Branche sich jetzt nicht entschließen könne, endlich einen einheitlichen API-Standard (API = Application Programming Interface) für Content Repositories zu schaffen, werde sie kaum in der Lage sein, die zukünftigen Aufgaben, die auf die Branche zukommen, ohne Probleme zu bewältigen.
So gibt es zwar in der Content Management-Industrie eine ganze Anzahl von Spezifikationen, die sich auf Protokollebene mit dem Austausch von Content beschäftigen (z.B. ICE, WebDAV etc.), die speziellen Anforderungen von Content Repositories werden aber auf API-Ebene bislang von keinem einzigen Standard adressiert.
Vor welchen Umwälzungen die Content Management-Branche steht, die mit mehr als 150 aktiven Herstellern von Content Management-Systemen bislang fröhlichen Wildwuchs feiern durfte, machten jüngst Einschätzungen von Gartner Group, Forrester Research und Meta Group deutlich: Den Content Management-Systemen, die vielfach bislang nur zur Pflege bzw. Erstellung von Websites konzipiert waren, steht ein Paradigmenwechsel bevor. Die Analysten prognostizierten schon ab dem Jahr 2003 ein zunehmendes Zusammenwachsen von Content Management-Werkzeugen und Portalen mit den Inhalten von Standardapplikationen und Legacy Content. „Unified Content“ heißt das Schlagwort, das dem „Enterprise Content Management“ zunehmend eine strategische Rolle als Infrastruktursoftware zuweist. Nur: Ohne einen einheitlichen Standard im Content Repository-Bereich auf API-Ebene, ist dies kaum zu machen.
Es ist schon merkwürdig: Die noch junge Content Management-Branche, die wie kaum ein andere Branche in der IT den Siegeszug des Internets und damit verbunden von Web-Applikationen widerspiegelt, zeigte sich bislang nur in einem Feature wirklich homogen: dem Fehlen eines industriellen Standards auf API-Ebene.
Wo liegt das Problem?
Web-Applikationen wie Websites, Portale, Shops oder Kataloge interagieren mit Content. Dieser wird in so genannten Content Repositories gehalten und mit einem Content Management-System gemanagt. Content Repositories wiederum sind in der Regel Bestandteil eines Content Management-Systems; d.h. bis heute gibt es keine separaten Content Repositories. Da jeder CMS-Hersteller wiederum sein eigenes Repository-API verwendet, steht die E-Business-Branche bislang vor einem großen Dilemma: Applikationen können nicht so einfach ausgetauscht werden (wie z.B. bei einer SQL-konformen Datenbank), die Integratoren sind gezwungen, diverse APIs zu beherrschen und Applikationsentwickler wie z.B. Portal-Hersteller müssen ihre Produkte an die unterschiedlichsten APIs anpassen. Auch für die Kunden ist diese Situation nicht unbedingt befriedigend: Wer sich einmal auf ein Content Management-System festgelegt hat, kommt so leicht nicht mehr davon weg.
Nüschelers Anregung, einen einheitlichen API-Standard für den Content-Zugriff innerhalb einer J2EE-Umgebung zu schaffen, fand daher in der Branche rasche Zustimmung. Innerhalb kurzer Zeit formierte sich unter Führung von Day (David Nüscheler bekleidet den so genannten Specification Lead) eine Expertengruppe, die sich gemeinsam die Definition einer implementationsunabhängigen Standard-API für den Zugriff auf Content Repositories in Java 2 zum Ziel setzte. Das Java Community Process-Komittee genehmigte den neuen Java Specification Request (JSR), der die Nummer 170 erhielt.
Das Feld derer, die ein Interesse an einer Standardisierung eines APIs für den Content-Zugriff haben, ist bunt. Die Expertengruppe des JSR 170 lässt sich grob unterteilen in Hersteller bzw. Anbieter von Content Management-Systemen (Day, Interwoven, Vignette, Mediasurface, Documentum), in reine Repository-Anbieter (Software AG, SAP, Oracle IBM), in Integratoren (Hewlett Packard, Venetica, Softlab), in Hersteller von Content-bezogenen Applikationen (Art Technology Group, BEA, SAP, Broadvision) und in Anbieter von Applikations-Servern (BEA, IBM, Oracle, Silverstream, Sun).
Was soll nun geschehen?
Das neue Standard-API wird – wenn immer möglich – existierende Java-Standards, die zum Teil auch auf Content Repositories anwendbar sind, einbinden. Nichtsdestotrotz wird die JSR 170-Spezifikation einen völlig neuen API-Standard darstellen, der speziell auf Content Repositories zugeschnitten ist.
Technologisch bewegt sich der JSR 170-Standard auf zwei Ebenen. Während Level 1 vor allem den Zugriff auf Content Repositories auf Content-Element-Ebene regelt (enthält grundlegende Features für den Lese-/Schreibzugriff und hierarchische Operationen) und technologisch gesehen eher trivial erscheint, bildet Level 2 mit umfassenden Repository-Funktionalitäten die Basis für ein Content Management-System. Level 2 erlaubt auch komplexen Applikationen den Datenaustausch mit dem Standard-API und stellt die Definition für zukünftige, ausgereifte Repository-Entwicklungen dar. Level 2 legt unter anderem den Schwerpunkt auf:den Lese-/Schreibzugriff: Hier geht es um eine bi-direktionale Interaktion von Content-Elementen. Geprüft wird nicht nur das Prozedere auf Dokumentenebene, sondern ebenfalls auf der so genannten "Eigenschaften"-Ebene, wobei der Austausch von Content stets als Operation bzw. Dienst gesehen wird, die bzw. der wechselseitig zwischen dem System und Content Repository stattfindet;die Versionierung: Ziel ist die transparente Versionskontrolle innerhalb des gesamten Content Repository. Der Vorteil: Auf unterschiedliche im Content Repository abgelegte Versionen eines Contents könnte nicht nur leicht zugegriffen werden, die Versionen wären auch problemlos zu modifizieren (bzw. zu synchronisieren);
die Volltextsuche und Filterung: Es ist ohne Frage ein Vorteil, wenn der gesamte, nicht-binäre Inhalt eines Repository mit einer Volltext-Suchmaschine, die die genaue bzw. die Sub-string-Suchmethode beherrscht, angezeigt werden könnte. Daher soll standardisiert werden, auf welche Weise Inhaltsabfragen (Volltext-Abfrage oder parametrische Abfrage) generiert werden. Auch hier sollen natürlich Standard-Abfragesprachen bei einer Entscheidung berücksichtigt werden;
die Objekt-Klassen: Ziel ist es, Dokumenttypen und Profile so zu definieren, das Beschränkungen möglich sind, innerhalb deren sich ein Applikationsentwickler auf bestimmte Content-Objekttypen per der Programmierung konzentrieren kann; und
Transaktionsfähigkeit.
Ferner wird eine Standardisierung im Umgang mit binären und textbasierten sowie mit strukturierten, semi- und unstrukturierten Daten geprüft, die Zugangskontrolle zum Content Repository, das Event-Monitoring, Namespaces und Standard Properties, Linking, Locking und Concurrency.
Der Zeitrahmen, den sich die JSR 170-Expertengruppe für die Definition des Standard-APIs gesetzt hat, ist eng. Der Einreichung des so genannten Community-Entwurfs noch im August/September dieses Jahres, soll die Verabschiedung dieses Entwurfs durch die Expertengruppe im September dieses Jahres folgen. Anschließend wird das Resultat der Öffentlichkeit (Java-Gemeinde) zur Diskussion freigegeben (Dezember 2002 bis Februar 2002). Im April 2003 soll ein konsolidierter Entwurf zur Verabschiedung bereitstehen. Im Juni 2003 soll schließlich das Final Release des Standard-APIs freigegeben werden.
Der JSR 170 ist die Antwort auf die signifikante Herausforderung, vor der heute Entwickler stehen, die mit Content Management-Systemen zu tun haben, nämlich eine Unmenge von APIs verwenden zu müssen. "Es ist unser Ziel", so erklärte Roy Fielding, Chief Scientist bei Day, "dass sich die Hersteller von Content Management-Systemen auf ein einziges API einigen, mit dem man Zugang zu in Java 2 geschriebenen Content Repositories erhält, anstatt eine Vielzahl proprietärer Schnittstellen berücksichtigen zu müssen." Außerdem enthält der JSR 170 weitere Normierungen, die speziell auf den Portal- und Personalisierungsmarkt zielen. Man darf getrost sagen, dass der JSR 170 für diese Industrie eine Schlüsselrolle einnimmt. "Ein standardisiertes Content Repository-API vereinfacht in jeder Hinsicht die Implementation von Portalen, da der Zugriff auf die unterschiedlichsten Content-Quellen und Applikationen ohne großen Aufwand möglich sein wird", erklärt Fielding.
Rob Perry, Analyst der Yankee Group, weist zwar darauf hin, dass die positiven Auswirkungen eines standardisierten API nicht von heute auf morgen sichtbar sein werden, dennoch ist auch er davon überzeugt, dass mit der Verabschiedung eines standardisierten Content Repository-API der grundlegende Schritt getan sei, die Integration zwischen Content Management-Systemen und Content Management-Applikationen entscheidend zu erleichtern. Vorteile sieht Perry nicht nur für die kleineren CMS-Hersteller, die nun leichter auf eine größere Anzahl von Content-Quellen zugreifen können, sondern auch für die Branchengrößen, die nun eine wesentlich tiefere Integration ihrer Applikationen erreichen werden.
Andererseits zeigt sich schon jetzt, dass die Content Management-Branche vor einem großen Richtungswandel steht. "Ein standardisiertes Content Repository-API bietet die Chance für jeden CMS-Hersteller, ohne großen Programmieraufwand auf die unterschiedlichsten Repositories zugreifen zu können", erläutert Nüscheler. "Allerdings ist eines auch klar: Diejenigen unter den CMS-Herstellern, die diesen Standard nicht berücksichtigen, werden über kurz oder lang vom Markt verschwinden. Denn hat die Java Community einmal einen Standard definiert, muss dieser auch in den Produkten berücksichtigt werden. Hier entsteht der Druck schon allein seitens der Anwender/Kunden, die schon aus Gründen der Investitionssicherheit auf Standards bestehen." Das Damokles-Schwert, das über der Content Management-Branche hängt, heißt dementsprechend Marktbereinigung.
Generell gesehen wird in der Content Management-Branche der Wettbewerb nach Verabschiedung eines API-Standards sicherlich härter, da die Content Management-Systeme, wenn sie standardisierte Content Repository-APIs benutzen, vom Kunden leichter austauschbar sein werden. Gekonnter Datenzugriff auf ein Content Repository ist nach dem Juni 2003 kein Grals-Wissen mehr. Die Folge: Die Content Management-Systeme treten bezüglich ihrer Funktionalität in eine härtere Konkurrenz zueinander. Dass hier Day einen Vorsprung haben wird, vermutet wohl Tony Byrne vom Online-Magazin CMSWatch nicht zu unrecht. Zwar gibt der CMS-Hersteller als Initiator des JSR 170 durchaus elementares Wissen preis, dafür profitiert das Unternehmen aber von einem anerkannten API-Standard, da die gesamte Architektur des "Virtuellen Repository" der Day-Software "Communiqué" auf die Art der Interoperabilität, wie sie im JSR 170 beschrieben wird, aufbaut.
Spannend wird die Verabschiedung des JSR 170 jedoch allemal: Da Content Management-Größen wie z.B. Interwoven und Vignette ebenfalls mit an Bord der JSR 170-Exekutive sind, vermutet Byrne, der auch der Expertengruppe des JSR 170 angehört, dass eine einvernehmliche Einigung auf einen gemeinsam angestrebten Standard noch ein hartes Stück Arbeit darstellt. Denn: Welcher CMS-Hersteller möchte schon große Teile seines Single Repository neu schreiben müssen – andererseits führt für viele CMS-Hersteller kein Weg daran vorbei.
Man braucht kein Hellseher zu sein, um zu erahnen, dass die sich Content Management-Branche im Zuge der Standardisierung völlig neu definieren muss. Die Frage, die sich für die Branche stellt: Hat es für den einzelnen CMS-Hersteller überhaupt einen Sinn, auf Basis der JSR 170-Referenzimplementierung ein eigenes Content Repository zu entwickeln (was viel Zeit, Arbeit und Geld kostet) oder ist es nicht weitaus vernünftiger, die Entwicklungsressourcen in die Pflege der eigentlichen Applikation "Content Management" zu stecken und das Content Repository gewissermaßen auf dem "freien Markt" hinzuzukaufen bzw. zu lizenzieren?
Man kann prognostizieren, dass wir auf dem Content Management-Markt eine ähnliche Entwicklung wie im Datenbankmarkt erleben werden: Das Content Repository wird lizenziert wie quasi eine Datenbank von Oracle, IBM oder Microsoft. Entscheidend ist für den Endanwender die Applikation, die auf der Datenbank zw. dem Content Repository sitzt, d.h. ein ERP-System wie SAP oder ein Content Management-System vom Hersteller XY. Das bedeutet auch, dass die IT-Industrie in Kürze die Geburt eines neuen Marktes erleben wird: nämlich einen Markt für Content-Infrastruktur.
Bilder:
Grafik: JSR 170-Schedule (http://jcr.day.com/playground/en/schedule.html )
BU: Im Juni 2003 soll schließlich das Final Release des Standard-APIs freigegeben werden.
((Kasten))
Vom Vorschlag zum Standard – Wie die Java-Gemeinde neue Java-Spezifikationen beschließt
Der Java Community Process (JCP) ist eine offene Organisation aktiver Mitglieder aus der Industrie sowie der allgemeinen Öffentlichkeit, die für die Weiterentwicklung der Java-Technologie zuständig ist (insgesamt mehr als 400 Unternehmen gehören der Java Community an). Diese Organisation leitet die Entwicklung und Verabschiedung von technischen Spezifikationen von Java. Der JCP wird von einem Exekutivausschuss geleitet, dessen Mitglieder von der Community gewählt werden und der 16 Mitglieder umfasst (zur Zeit gehören ihm Apache, Apple, BEA, Borland, Caldera, Cisco, Fujitsu, Hewlett-Packard, IBM, IONA, Doug Lea, Macromedia, Nokia, Oracle und Sun an). Lediglich Sun Microsystems ist ständiges Mitglied. Dieser Prozess soll dazu beitragen, die Stabilität und plattformübergreifende Kompatibilität auf globaler Ebene sicherzustellen und zugleich den Bestand an Spezifikationen für die Plattform zu erweitern.
Eine Spezifikation, der so genannte "Java Specification Request" (JSR) ist die eigentliche Beschreibung vorgeschlagener und endgültig angenommener Spezifikationen für die Java-Plattform. Der Exekutivausschuss stimmt über die Annahme von Vorschlägen und endgültigen Spezifikationen ab. Ein Mitglied der Java Community kann einen Specification Request einreichen und wählt einen so genannten "Spec Lead", der für alle Aspekte des Antrages zuständig ist. Der Spec Lead bildet daraufhin mittels Einladung und Aufnahmeantrag eine Expertengruppe, der aktive Mitglieder der Java Community angehören.
Durch Bildung einer Expertengruppe soll gewährleistet sein, dass der endgültige Vorschlag von aktiven Branchenmitgliedern mit dem Zielausgearbeitet wurde, eine durchdachte, auf breite Akzeptanz stoßende und nützliche Spezifikation zu entwickeln. (Martin Arndt)
((Kasten))
JSR 170-Expertengruppe
Apache Software Foundation
Art Technology Group (ATG)
BEA Systems
Broadvision
Day
Documentum
Fujitsu
Hewlett-Packard
IBM
Intalio
Interwoven
Mediasurface
Oracle
Rational Software
SAP
SAS Institute
Silverstream
Software AG
Stellent
Sun
Venetica
Vignette
|
|
