|
PROJECT CONSULT Dr. Ulrich Kampffmeyer
|
 |
| Archivierte alte Webseite - Datenschutzerklärung, Adressen und Links zu externen Seiten sind vielfach ungültig - Bitte besuchen Sie www.PROJECT-CONSULT.com
Archived old Web Site - Privacy declaration, addresses and links to external web sites may be invalid - Please visit www.PROJECT-CONSULT.com | | | Rufer in der Wüste | | | | | | PROJECT CONSULT Newsletter 20051014
| | | | | SOA, Service Oriented Architecture, auch Serviceorientierte Architektur oder auch dienstorientierte Architektur, ist ein neues Schlagwort, dass zur Zeit Kongresse, Seminare, Artikel und Marketingbroschüren sprießen lässt. Ein neues Schlagwort für altbekannte Konzepte. Erst seit 2004 gibt es vermehrt Buchpublikationen zu SOA, so dass es noch eine Weile dauern wird, bis das Thema im Markt angekommen ist.
| | | | | Eine passende Definition für SOA ist „Eine serviceorientierte Architektur ist ein Konzept für eine Systemarchitektur, in welchem Funktionen in Form von wieder verwendbaren, voneinander unabhängigen und lose gekoppelten Services implementiert werden. Services können unabhängig von zugrunde liegenden Implementierungen über Schnittstellen aufgerufen werden, deren Spezifikationen öffentlich und damit vertrauenswürdig sind. Serviceinteraktion findet über eine dafür vorgesehene Kommunikationsinfrastruktur statt. Mit einer serviceorientierten Architektur werden die Gestaltungsziele der Geschäftsprozessorientierung, der Wandlungsfähigkeit, der Wiederverwendbarkeit und der Unterstützung verteilter Softwaresysteme verbunden.“ Ein hehrer und sehr bekannt klingender Anspruch.
| | | | | Seit Jahrzehnten wird über Dienstearchitekturen in der Informationswissenschaft gesprochen. Ein Dienst ist dabei eine geschlossene Funktionalität, die über Standardschnittstellen angesprochen werden kann, auf einem Server (Rechner), auf mehrere verteilt und mehrfach auf einem Server betrieben werden kann. Also nichts Neues? Früher sprach man von Diensten in einer Middleware. Heute sind es halt Services in einer SOA oder in einem Enterprise-Bus. Die Trennung der Anwendungen im Dienste, ist schon lange ein Desiderat um wild wuchernden, immer komplexeren Applikationen begegnen zu können. Aber wird durch SOA die Komplexität geringer? Dienste müssen harmonisiert werden, die Schnittstellen müssen vorhanden sein und funktionieren, die Services müssen administriert und überwacht werden, und es muss die Transaktionssicherheit über alle beteiligten Dienste in einem Prozess realisiert sein. Setzt man auf dieses neue Konzept, holt man sich zunächst eine weitere IT-Infrastruktur neben den bestehenden Systemen ins Haus. Die Vorteile von SOA erschließen sich erst richtig dann, wenn alle Komponenten und Anwendungen auf ein Dienste¬konzept umgestellt sind. Nur dann funktioniert auch die „Orchestrierung von Services“. Grundidee ist dabei, dass es für jede Funktion nur einmal einen gekapselten Service gibt. Der Dienst wird dann vom „Service Provider“ dem „Service Consumer“ bei einem „Service Request“ bereitgestellt. Hierbei ist es notwendig alle Parameter und Objekte vollständig und interpretierbar zur Verfügung zu stellen. Ähnliche Konzepte haben wir bereits mit intelligenten Business Objects oder CORBA in der Vergangenheit kennengelernt, ohne dass sich diese bisher durchsetzen konnten. Ein weitverbreiteter Irrtum ist, dass SOA sich nur auf Web-Services bezieht. Natürlich sind Web-Services eine mögliche Implementierungs- und Nutzungsform, jedoch kann man auch in anderen Architekturen wie Client/Server (sic!) das gleiche Prinzip nutzen. Aber weil Portale und Webanwendungen ein modernes Thema sind und hier besonders viele architektonische Mängel zu beobachten waren, wird der SOA-Ansatz in diesem Marktsegment zur Zeit favorisiert aufgegriffen. Für die Kommunikation kommen daher auch Protokolle und Standards zum Einsatz, die im Web-Umfeld beheimatet sind. Oft werden für SOA Web Services auf der Basis von Standards wie SOAP, WSDL und UDDI oder Enterprise Java Beans umgesetzt. Diese technischen Umsetzungen werden häufig aus Performance- und Transaktionssicherheitsargumenten negativ bewertet, so ist z.B. SOAP ein sehr „geschwätziges“ Protokoll. Geeignetere Standards gibt es leider noch nicht, so dass SOA vielerorts Vision aber kaum eine Realität ist. Im Prinzip kann aber eine SOA prinzipiell auf jeder dienstbasierten Technologie aufgebaut werden. SOA stellt damit auch eine Alternative zum EAI Enterprise Application Integration Ansatz dar.
| | | | | Warum ist SOA für ECM wichtig?
| | | | | ECM Enterprise Content Management verfolgt von Anfang an den Ansatz Dienste-orientierter Architekturen – nur den Begriff SOA gab es noch nicht. Die drei wesentlichen Ideen von Enterprise Content Management sind a) Abkehr von vertikalen Anwendungen zu einer horizontalen Middleware, b) Kapselung der Funktionalität in Diensten, die über standardisierte Schnittstellen allen Anwendungen und Anwendern gleichermaßen zur Verfügung stehen, und c) Bereitstellung eines übergreifend nutzbaren Speicherortes für alle Daten, Informationen, Content, Records usw. Ein Blick in alte Projektdokumentationen und Strategiekonzepte zeigt, dass PROJECT CONSULT zumindest diesen Ansatz seit Bestehen des Unternehmens verfolgt und beraten hat. Nur die Erfahrung zeigt auch, dass es sehr wenig Anbieter gab und gibt, die solche Architekturansätze unterstützen. Die Verfügbarkeit echter Services ist das derzeitige Problem von SOA. Am ehesten dürfte heute IBM an diesem Konzept dran sein, bei den klassischen ECM-Anbietern vielleicht FileNet und Documentum. Ein Umdenken ist bei den Anbietern gefordert. Standardisierte Dienste und standardisierte Schnittstellen erlauben eine direkte Vergleichbarkeit und eine Austauschbarkeit der Produkte. Dies lag unter dem Gesichtspunkt der „Kundenbindung“ nie im Interesse der Anbieter. Jedoch ist es gerade beim allumfassenden Anspruch von ECM mit Capture, Deliver, Store, Manage und Preserve notwendig, auf diese Strategie zu setzen, da kaum ein Anbieter in der Lage ist, rechtzeitig in gebotener Qualität alle Funktionalität selbst zu programmieren. ECM-Suiten lassen sich nur durch die Kombination geeigneter Dienste anbieten. ECM als Infrastrukturkomponente muss daher auf Dienstekonzepte setzen, egal ob sie sich nun SOA oder anderswie nennen. Angesichts des den Ansprüchen von SOA genügenden Produktangebots, fühlt man sich jedoch als Rufer in der Wüste. Zu lange und zu häufig wurde über neue Architekturen gesprochen ohne dass geeignete Komponenten verfügbar gemacht wurden. Auch SOA wird als leeres Akronym enden, wenn nicht das notwendige Umdenken bei Anbietern und Anwendern erfolgt. (Kff)
| | | |
| | |  |
 |
Seitentitel: Artikel_Diskussion_2005_Rufer, Zitierung: http://www.pc.qumram-demo.ch/portal.asp?SR=775
Zuletzt aktualisiert am: 31.10.2005
| |
CopyRight © 1992-2012 PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH
20251 Hamburg, Breitenfelder Str. 17, Tel.: +49-40-46076220, E-Mail, Rechtshinweis
Optimiert für MS Explorer 5.x, 6.x, 1024x768 Pixel, Cookies(on), JavaScript(on) | | Archivierte alte Webseite - Datenschutzerklärung, Adressen und Links zu externen Seiten sind vielfach ungültig - Bitte besuchen Sie www.PROJECT-CONSULT.com
Archived old Web Site - Privacy declaration, addresses and links to external web sites may be invalid - Please visit www.PROJECT-CONSULT.com |
|
|
|
