Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

27.02.2006

Acht Missverständnisse über Service-orientierte Architekturen

Der Integrationsexperte David Linthicum nimmt zu acht gängigen Thesen Stellung, die über Service-orientierte Architekturen (SOAs) im Umlauf sind.

David Linthicum

Die Ideen und Bücher von David Linthicum haben Technikkonzepte wie Enterprise Application Integration (EAI), B-to-B-Anwendungsintegration sowie Service-orientierte Architektur (SOA) beeinflusst. Linthicum ist derzeit Chief Executive Officer von Bridgewerx, zuvor hatte er die Position eines Chief Technolgy Officer bei Unternehmen wie Grand Central, Mercator und Saga inne. Am 4. April wird er als Gastredner auf dem "Business Integration Forum" in Frankfurt am Main zu hören sein.

Service-orientierte Architekturen sind ein neues Konzept.

Nicht ganz. Seit es Computer in Unternehmen gibt, suchen wir nach Lösungen und Techniken, die funktionales Verhalten, also Services, teilen helfen. Remote Procedure Calls waren der erste echte Versuch, solch eine Architektur zu schaffen. Dann folgten die Interprozesskommunikation (IPC) und schließlich verteilte Objekte auf der Basis des Component Object Model (COM) und der Common Object Request Broker Architecture (Corba). Web-Services sind zwar ein neuer Versuch der Standardisierung, arbeiten aber letztlich so ähnlich wie traditionelle verteilte Objekte.

Man braucht Web- Services, um eine SOA zu bauen.

Nein! Web-Services sind zwar bei weitem der bevorzugte Standard, um eine SOA zu erstellen und einzuführen, es können aber auch andere Standardtechniken wie Corba, COM und J2EE sein. Man kann sogar eigenentwickelte Technik nehmen. Bei SOAs dreht sich alles um das Teilen und Verwalten der Services sowie der Prozesse und Orchestrierungen, die auf diesen Services aufsetzen. Welche Technik Sie verwenden, sollte davon abhängen, was Sie brauchen.

Wenn ich einen Enterprise Service Bus (ESB) kaufe, habe ich eine SOA.

Nicht ganz. ESBs sind eine sehr mächtige Technik, mit der sich über Web-Services-Schnittstellen Informationen zwischen den Anwendungen bewegen lassen. Geht es aber darum, eine bestimmte Dienstequalität zu etablieren oder das Verhalten von Anwendungen zu teilen, sind sie weniger geeignet. ESBs sind Teil einer SOA, liefern aber keine "SOA-in-a-Box".

SOAs sind von Natur aus hochskalierbar.

Keineswegs. SOAs sind Konzepte, deren Skalierbarkeit von der verwendeten Technik und Architektur abhängt. Werden Services beispielsweise zu feingranular entworfen, bereitet die Skalierbarkeit der Lösung vermutlich bald Probleme. Anwender müssen daher zuerst die SOA richtig entwerfen, die Eigenschaften ihrer Bestandteile verstehen und die passende Technik und Entwicklungsplattform finden.

Der Aufbau einer SOA lässt sich immer rechtfertigen.

Ein Business Case für SOAs ist schnell gefunden, weil sie Unternehmen Geld zu sparen versprechen, indem sich vorhandene Software (als Service) wiederverwenden und IT-Lösungen flexibler an neue Geschäftsanforderungen anpassen lassen. Doch vor dem Design und der Umsetzung einer SOA sollte stets eine Bestandsaufnahme erfolgen. Nicht immer werden Unternehmen dabei zu dem Schluss gelangen, dass sie mit einer SOA Geld sparen können. Allerdings sollten sie Vorteile wie agilere Prozesse und die Chance, schneller auf Marktveränderungen zu reagieren, nicht übersehen.

Beim Aufbau sollte man sich für einen einzigen Anbieter entscheiden.

Viele warnen davor, Produkte diverser Hersteller einzusetzen, weil es zu Inkompatibilitäten kommen könnte. Allerdings gibt es bisher kaum einen Anbieter, der eine End-to-End-Lösung für die Entwicklung und den Einsatz der meisten SOAs vorzeigen kann. Es bleibt also nichts anderes übrig, als mögliche Probleme durch Proof of Concepts in einer frühen Projektphase aufzudecken.

Man wählt eine Technik, einen Anbieter und macht von dort aus weiter.

Bloß nicht! Zunächst müssen die Anforderungen stehen und klar sein, welches Problem man zu Beginn angehen will. Der Anwender muss sich um Semantiken, Sicherheitsaspekte, die Integrität der Lösung kümmern, vorhandene Services kennen und wissen, welche er noch zusätzlich erstellen muss. Weiter muss er bestimmen, wie er die Services zu einer Lösung orchestrieren möchte und wie sich diese an veränderte Geschäftsbedingungen anpassen lässt. Erst dann kommt die Technik, und sie sollte getestet werden, bevor der Scheck unterschrieben ist!

Eine SOA macht andere EAI-Technik überflüssig.

Nein. Obwohl SOAs die Anwendungsintegration erleichtern, wird man auch künftig nicht ohne Basistechniken für Transformationen, Routing, Prozessintegration oder Adapter auskommen. Sie bilden einen Teil einer SOA, sind aber nicht von Anfang an in ihr enthalten.