Mehr Interoperabilität mit SOA
Mehr Interoperabilität mit SOA
Mit einer breiten Etablierung von Standards für verteilte Anwendungen (allen voran CORBA, DCOM, EJB und RMI) und der komponentenorientierten Softwareentwicklung (z.B.. COM, J2EE) wurden diese Visionen implementiert. Allerdings geschah dies oftmals in Abhängigkeit einer Plattform, die den oben erwähnten Triebkräften Wartbarkeit, Interoperabilität und Wiederverwendbarkeit entgegenwirkte.
SOA als Allheilmittel?
Die Service Oriented Architecture (SOA) ist ein Konzept für eine Systemarchitektur, bei dem die Bereitstellung fachlicher Funktionalitäten in Form von Diensten (Services) erfolgt. Dabei ist ein wesentliches Ziel die Kapselung von Daten durch einen solchen Dienst. Auf diese Weise werden Redundanzen verringert und die Flexibilität der Systeme erhöht. Ausserdem sollen mit SOA Businessprozess adäquat umgesetzt werden und zwar so, dass analog zu den sich ständig ändernden Business-Anforderungen auch die Software und der implementierte Prozess flexibel sind. Dies bedeutet, dass die Software selbst den Veränderungen standhalten beziehungsweise folgen kann.
Von der technischen Warte aus betrachtet wird ein System, welches aus eigenständigen Diensten besteht, als serviceorientiertes System bezeichnet. Im Wesentlichen sind es vier Merkmale, die ein solches SOA-System ausmachen:
1. Policy-basiert: Die Nutzung eines Dienstes ist an klar vorgegebene Voraussetzungen gebunden. Hierzu gehört beispielsweise eine Authentifizierung als Aufrufkonvention einer SOA-Komponente.
2. Explizite Grenzen: Es muss definiert sein, was innerhalb und was ausserhalb einer Komponente ist, und wann diese Grenzen überschritten werden. Die Interna der einen Komponente dürfen keinen Einfluss auf andere Komponenten haben.
3. Autonomie: Eine Komponente verwaltet die genutzten Daten eigenständig und bestimmt ausserdem die eigene Lebenszeit und Aktivität - interne Zustände sind absolut autark.
4. Austausch von Verträgen: Die Kommunikation mit der Aussenwelt wird ebenfalls definiert. Die Schnittstellen werden durch geeignete Dokumente beschrieben, die auch automatisiert zwischen SOA-Komponenten ausgetauscht werden können.
Die Service Oriented Architecture (SOA) ist ein Konzept für eine Systemarchitektur, bei dem die Bereitstellung fachlicher Funktionalitäten in Form von Diensten (Services) erfolgt. Dabei ist ein wesentliches Ziel die Kapselung von Daten durch einen solchen Dienst. Auf diese Weise werden Redundanzen verringert und die Flexibilität der Systeme erhöht. Ausserdem sollen mit SOA Businessprozess adäquat umgesetzt werden und zwar so, dass analog zu den sich ständig ändernden Business-Anforderungen auch die Software und der implementierte Prozess flexibel sind. Dies bedeutet, dass die Software selbst den Veränderungen standhalten beziehungsweise folgen kann.
Von der technischen Warte aus betrachtet wird ein System, welches aus eigenständigen Diensten besteht, als serviceorientiertes System bezeichnet. Im Wesentlichen sind es vier Merkmale, die ein solches SOA-System ausmachen:
1. Policy-basiert: Die Nutzung eines Dienstes ist an klar vorgegebene Voraussetzungen gebunden. Hierzu gehört beispielsweise eine Authentifizierung als Aufrufkonvention einer SOA-Komponente.
2. Explizite Grenzen: Es muss definiert sein, was innerhalb und was ausserhalb einer Komponente ist, und wann diese Grenzen überschritten werden. Die Interna der einen Komponente dürfen keinen Einfluss auf andere Komponenten haben.
3. Autonomie: Eine Komponente verwaltet die genutzten Daten eigenständig und bestimmt ausserdem die eigene Lebenszeit und Aktivität - interne Zustände sind absolut autark.
4. Austausch von Verträgen: Die Kommunikation mit der Aussenwelt wird ebenfalls definiert. Die Schnittstellen werden durch geeignete Dokumente beschrieben, die auch automatisiert zwischen SOA-Komponenten ausgetauscht werden können.
Bessere Interoperabilität
Im Gegensatz zum Business-Bus bei EAI, dient bei SOA der so genannte Service-Bus als Integrationsplattform. Dienste auf diesem Bus folgen alle den gegebenen Standards, erfüllen vorhandene Policies und passen sich der vorherrschenden Infrastruktur an. All diese Dinge - inklusive des Service-Bus - kennen wir jedoch bereits aus der Vergangenheit. Es sind Methoden und Technologien, die uns bei der Planung und Umsetzung von Softwarelösungen, besonders denjenigen mit verteilten Architekturen, schon immer beschäftigt haben. SOA bietet einen allgemeinen Lösungsansatz. Es ist kein Produkt, das man kaufen kann, und es ist auch kein Mäntelchen, das ich meiner Software anziehen kann. SOA ist eher als Prozess oder auch Vorgehensweise zu verstehen.
Im Gegensatz zum Business-Bus bei EAI, dient bei SOA der so genannte Service-Bus als Integrationsplattform. Dienste auf diesem Bus folgen alle den gegebenen Standards, erfüllen vorhandene Policies und passen sich der vorherrschenden Infrastruktur an. All diese Dinge - inklusive des Service-Bus - kennen wir jedoch bereits aus der Vergangenheit. Es sind Methoden und Technologien, die uns bei der Planung und Umsetzung von Softwarelösungen, besonders denjenigen mit verteilten Architekturen, schon immer beschäftigt haben. SOA bietet einen allgemeinen Lösungsansatz. Es ist kein Produkt, das man kaufen kann, und es ist auch kein Mäntelchen, das ich meiner Software anziehen kann. SOA ist eher als Prozess oder auch Vorgehensweise zu verstehen.
