“Die Übergabe von UDDI an OASIS erhöht die Glaubwürdigkeit und Stabilität des Standards”

Feature | 10. März 2003 von admin 0

Was ist die aktuelle Version des UDDI Business Registry? Woran wurde in der nachfolgenden Version gearbeitet?

von Riegen: Das UDDI Business Registry, das jetzt von IBM, Microsoft, NTT und SAP gemeinsam betrieben wird, basiert auf der UDDI Version 2 und ist seit Juli 2002 produktiv. Es gibt verschiedene Implementierungen der Spezifikation, denen bemerkenswerterweise gemeinsam ist, eine ausführliche Testphase erfolgreich durchlaufen zu haben. Anwender des UDDI Business Registry finden daher überall in dem Verzeichnis dasselbe Programmverhalten vor und können sicher sein, dass Daten reibungslos repliziert werden.

Zu den bedeutendsten neuen Funktionen in UDDI Version 3 gehört eine optimierte Registrierung über mehrere Verzeichnisse hinweg. Auch ist es möglich, publizierte Dateneinheiten digital zu signieren, um deren Authentizität zu gewährleisten, eine Funktion, die von Anwendern häufig gefordert wurde. Die Betreiber des UDDI Business Registry planen derzeit, die Version 3 einzuführen und werden noch in diesem Jahr erste Implementierungen anbieten.

Können Sie Genaueres zu der Strategie sagen, auf der die Gründung des UDDI Specification Technical Committee innerhalb von OASIS beruht?

Clement: Für das UDDI Specification Technical Committee ist es äußerst wichtig, ein Forum anzubieten, in dessen Rahmen UDDI sich weiterhin erfolgreich entwickeln kann. Darüber hinaus ergänzt UDDI andere Bestrebungen von OASIS im Bereich der Web-Services.

Wer wird die Verantwortung für das UDDI-Projekt und die Fortsetzung der technischen Arbeiten an der Spezifikation übernehmen? Wird OASIS UDDI weiterhin für eine Verwendung hinter der Firewall vorantreiben, also weniger in Gestalt öffentlicher Verzeichnisse, die als eine Art “Gelbe Seiten” für Web Services fungieren?

Clement: Die technischen Aktivitäten werden vom UDDI Specification Technical Committee (http://oasis-open.org/committees/uddi-spec/) gesteuert. Die ursprünglichen Mitglieder der UDDI Working Group sind weiterhin an diesen Aktivitäten beteiligt. UDDI ist für Anwendungen innerhalb und außerhalb von Unternehmen ausgelegt, und UDDI Version 2 unterstützt heute bereits beides.

Tom Bellwood

Tom Bellwood

Bellwood: Das OASIS UDDI Specification Technical Committee ist für die Weiterführung der technischen Arbeiten an der Spezifikation zuständig. Die UDDI-Spezifikation ist nicht an eine bestimmte Installationsumgebung gebunden. In Version 3 der Spezifikation sind Leistungsmerkmale enthalten, die den Nutzen von UDDI in öffentlichen und privaten Umgebungen beträchtlich erhöhen. So lässt sich beispielsweise mit den neu hinzugekommenen digitalen XML-Signaturen die Authentizität der Daten im Verzeichnis feststellen. Zudem machen es die Identifikations- und Subskriptionsfunktionen einfacher, Daten in verschiedenen UDDI-Verzeichnissen gemeinsam zu nutzen. Auch hier gilt die Aussage sowohl für öffentliche, als auch für private Verzeichnisse. Die Arbeitsgruppe wird darüber hinaus weiter daran arbeiten, dass die Kompatibilität mit anderen Spezifikationen gewährleistet bleibt.

Durch die Öffnung von Verzeichnissen für Publishers, Subscribers und Peers wird die Frage der Zugangsberechtigung für Datensätze zu einem wichtigen Thema. Wie wird das durch die UDDI-Spezifikation abgedeckt?

Bellwood: Autorisierungs- und Authentifizierungsmodelle für Publishers wurden bisher als außerhalb des Rahmens der UDDI-Spezifikation betrachtet, insbesondere deshalb, weil es zahlreiche derartige Schemata gibt und somit die jeweils individuell bevorzugte Lösung in Implementierungen verwendet werden kann. Zwar ist mit Version 3 der UDDI-Spezifikation die Möglichkeit hinzugekommen, dass Implementierungen selbst bei Anfragefunktionen eine Authentifizierung verlangen können, jedoch bleibt UDDI neutral hinsichtlich der Mechanismen, die diese Funktion übernehmen.

Wie wollen SAP und die UDDI-Gründungsmitglieder durch die Zusammenarbeit mit OASIS den Verbreitungsgrad der Technologie ausweiten?

von Riegen: OASIS ist die ideale Plattform für eine internationale und branchenübergreifende Initiative, mit dem Ziel, die UDDI-Spezifikation um bewährte Geschäftsverfahren für verschiedene Anwenderkreise zu erweitern. Die enge Zusammenarbeit mit relevanten Gruppen aus W3C und WS-I ermöglicht eine enge Integration von UDDI in die allgemeine Web-Services-Infrastruktur.

Und wie lauten die Ziele des Standardisierungsgremiums?

Clement: Nachdem die Beteiligung an UDDI über die Gründungsmitglieder hinaus ausgeweitet ist, haben auch das UDDI Specification TC und die OASIS Member Section das Ziel, den Verbreitungsgrad und die Akzeptanz von UDDI zu erhöhen. Dazu werden sowohl Best Practices (http://www.oasis-open.org/committees/uddi-spec/bps.shtml) ) als auch Technical Notes (http://www.oasis-open.org/committees/uddi-spec/tns.shtml) veröffentlicht. Zum anderen sind Partnerschaften mit wichtigen Web-Service-Komponenten – etwa mit WS-Security – eminent wichtig.

Bellwood: Die Übergabe von UDDI an OASIS erhöht auch dessen Glaubwürdigkeit und Stabilität. Eine größere Beteiligung der Industrie ist eine gute Sache. Die Zugehörigkeit zu OASIS erleichtert es außerdem, UDDI auf einem aktuellen Stand zu halten.

Wann wird UDDI Ihrer Meinung nach bei den Kunden Wirkung zeigen?

Bellwood: Das ist bereits der Fall. In nur wenigen Jahren ist UDDI zu einer wichtigen Infrastrukturkomponente in Web-Service-Architekturen und den Werkzeugen größerer Anbieter geworden. UDDI ist allerdings nur ein Teil des Puzzles. Viele weitere Teile wie etwa WS-Security werden zurzeit zusammengesetzt, um das Wachstum von Web-Services zu unterstützen. Je ausgereifter sie sind, desto rascher werden sie sich durchsetzen bis sie zum Mainstream zählen. Ich denke, dass dies in den kommenden ein bis zwei Jahren der Fall sein wird.

von Riegen: Manche Kunden verwenden bereits interne UDDI-Verzeichnisse, um die Web-Services zu strukturieren, die sie in ihrer heterogenen Systemlandschaft bereitstellen. Andere wiederum entwickeln einen UDDI-Prototypen in einer halbprivaten Umgebung, etwa für firmeninterne Zwecke oder eine “geschlossene Gesellschaft” von Geschäftspartnern. Die Flexibilität von UDDI erlaubt eine Anpassung an die jeweiligen Anforderungen eines Nutzerkreises – nur so lassen sich die Integrationskosten senken und echter Wert schaffen. Ich persönlich erwarte, dass uns die nächsten zwölf Monate einige “Best Practices” aufzeigen und Erfahrungen aus Implementierungen in verschiedenen Branchen liefern werden. Allerdings sollten die Kunden nicht warten, bis ihre Mitbewerber bereits praktische Erfahrungen gesammelt und damit einen Vorsprung gewonnen haben.

Die Sicht der SAP auf die Zukunft von UDDI

Wie sieht die Strategie von SAP bezüglich UDDI aus?

von Riegen: UDDI ist ein wesentlicher Baustein der allgemeinen Web-Services-Architektur, daher versteht es sich fast von selbst, dass UDDI direkt von SAP NetWeaver unterstützt wird. SAP-Kunden können daher eine nahtlose Verbindung zu einem beliebigen UDDI-Verzeichnis herstellen, um mit dem SAP Web Application Server entwickelte Web-Services zu publizieren oder externe Web-Services zu integrieren. Mit dem SAP Web Application Server lässt sich ausserdem ein eigenes UDDI-Verzeichnis bereitstellen.

Welche Rolle spielt UDDI im Hinblick auf die mySAP Business Suite und insbesondere auf die Web-Services, die von SAP geliefert werden?

von Riegen: SAP hat umfangreiche Erfahrungen mit der Entwicklung unternehmensübergreifender Geschäftsprozesse und Anwendungsschnittstellen, die die technische Basis für solche Geschäftsprozesse bilden. Es ist daher nahe liegend, diese Schnittstellen auf der Basis bekannter Internetstandards wie SOAP und HTTP als Web-Services zur Verfügung zu stellen. Die Integration von SAP-Lösungen wie etwa mySAP CRM oder mySAP SRM mit UDDI-Verzeichnissen wird SAP-Kunden in die Lage versetzen, ihre unternehmensübergreifenden Geschäftsprozesse basierend auf der Registrierung und anschließenden Auffindung SAP-basierter Web-Services reibungsloser einführen zu können.

Wie wollen die mehr als 200 Mitglieder des früheren UDDI.org-Projekts zur Standardisierung der UDDI-Unterstützung in einer wachsenden Anzahl von Softwarewerkzeugen und -anwendungen beitragen?

von Riegen: Viele Werkzeuge und Anwendungen enthalten bereits heute irgendeine Art von Verzeichnis. Manche benötigen ein Handelspartnerverzeichnis, andere mehr Informationen über ihre “elektronischen Fähigkeiten”. Den UDDI-Ansatz, Informationen über Web-Services und deren Merkmale mit Informationen über ihre Anbieter zu kombinieren – all dies zugänglich über offene Internetstandards – haben bereits viele Softwareanbieter übernommen. Er wird sich in der Branche zum gängigen Mechanismus für Web-Service-Registrierungen entwickeln. Die Frage ist nicht, ob sich UDDI durchsetzt, sondern wie man es an die Anforderungen verschiedener Anwendergruppen individuell anpassen kann.

Wie wird die SAP in Verbindung mit dem Einstieg bei UDDI den Übergang von Integrationstechnologien zu den gemeinsamen Business-to-Business-Prozessen gewährleisten, die auf diesen Technologien basieren?

von Riegen: Zwei der wichtigsten Anforderungen bei der Entwicklung von SAP NetWeaver waren die Bereitstellung einer nativen Web-Service-Infrastruktur und der Schutz der Investitionen unserer Kunden in bestehende SAP-Integrationstechnologien. Da wir SAP-Standardschnittstellen wie EJBs, BAPIs oder IDocs als Web-Services zur Verfügung stellen, können unsere Kunden sofort Web-Service-Projekte in Angriff nehmen.

Oftmals sind die Geschäftsbeziehungen zwischen Unternehmen hochgradig individuell ausgeprägt. Als Folge ist auch die Integrationsinfrastruktur dementsprechend stark dezentralisiert. Wie kann in Hinblick darauf eine Mitarbeit aller Beteiligten sichergestellt werden?

von Riegen: Das ist eine gute Frage, die uns direkt zur Rolle von UDDI in heterogenen Landschaften von Geschäftspartnern und deren Systemen führt. Meiner Meinung nach sind zwei Dinge für den Erfolg von UDDI entscheidend. Erstens müssen die Anbieter von Werkzeugen und Technologie für die Systemintegration sich auf UDDI als Basis für den Austausch von Metadaten über Web-Services und deren Anbieter einigen. Das bedeutet jedoch nicht, dass jedes Werkzeug ein vollständig ausgeprägtes UDDI-Verzeichnis sein muss, das jedes einzelne API unterstützt. Bestehende Werkzeuge können UDDI-fähig gemacht werden, indem eine weitere Schicht um die vorhandenen APIs gelegt wird.

Zweitens muss UDDI auch andere Services beschreiben können, da es sich bei den Schnittstellen, die in den heutigen Systemlandschaften bereitgestellt werden, nicht nur um Web-Services handelt. Glücklicherweise erfüllen die Datenstrukturen und die Anpassbarkeit von UDDI diese Anforderungen. Bei Bedarf lassen sich damit beispielsweise CORBA-basierte Objekte oder EDI-basierte Transaktionen beschreiben und publizieren.

Leave a Reply