Civil Engineering Reference
In-Depth Information
eine strikte Abstraktionsschicht dar, die sämtliche Aspekte der Serviceimplementierung
nach außen verbirgt. Daher sind SOA Services autonom und plattformunabhängig, die
Implementierung kann in unterschiedlichen Sprachen bzw. auf verschiedenen Plattformen
realisiert werden. Die Services befinden sich in einem zentralen Servicepool und kön-
nen über einen so genannten Service Bus, auch Enterprise Service Bus, ESB genannt,
von verschiedenen Anwendungssystemen gemeinsam parallel genutzt und darüber hinaus
durch eine Servicekomposition zu beliebig komplexen Gesamtsystemen kombiniert wer-
den. Diese, auch als Orchestration bezeichnete Kombination von verschiedenen verteilten
Services aus oft unterschiedlichen administrativen Domänen ist ein wesentliches Merk-
mal einer serviceorientierten Architektur. Mit dem SOA Konzept lässt sich somit eine
unternehmensübergreifende, lose Koppelung unterschiedlicher Fachanwendungen unter
dem projektweiten Einsatz bewährter, wiederverwendbarer und weitgehend redundanz-
freier Softwarekomponenten erreichen.
Es ist bei der Einführung einer SOA Architektur jedoch nicht zielführend, sämtliche
Funktionalitäten aller bestehenden Anwendungssysteme komplett in Services zu zerlegen.
Dieser Aufwand würde in keinem Verhältnis zum Nutzen stehen. Vielmehr werden im
Rahmen einer partiellen SOA nur solche Services aus den Anwendungssystemen heraus-
gezogen und in einen zentralen Servicepool ausgelagert, bei denen eine Kernfunktionalität
unbedingt zentral implementiert und verfügbar sein muss, weil sie bspw. so kompliziert
oder wichtig ist, dass sie überall exakt gleich ablaufen muss, z. B. bei komplexen Berech-
nungen oder sicherheitsrelevanten Buchungen [
12
].
Damit eine Kollaborationsplattform für alle Baubeteiligten gleichermaßen offensteht,
muss sie auf Normen und allgemeinen Standards aufbauen. Die Realisierung von SOA
Szenarien in verteilten Anwendungen erfolgt typischerweise auf der Basis von Webser-
vices, deren Schnittstellen auf XML Basis implementiert sind, wobei die einzelnen Ser-
vices zustandslos und robust sind. Ob die Services als Grid Services [
13
] oder Cloud Ser-
vices [
14
] laufen, spielt nur eine untergeordnete Rolle. Für die wesentlichen Elemente
einer SOA Architektur, bestehend aus Services, Dienstverzeichnis, Servicebus und Ap-
plication Frontend, werden allgemein eingeführte Protokolle und Standards verwendet,
wie SOAP, WSDL und UDDI [
32
], die vom W3C in einer eigenen Arbeitsgruppe betreut
werden [
15
]. Zusätzlich fasst diese Architektur wichtige grundsätzliche Ansätze der Soft-
wareentwicklung zusammen, wie z. B. Datenkapselung und Information Hiding [
16
].
Eng mit der SOA Idee verknüpft sind Anwendungen für die Geschäftsprozessmodel-
lierung und die automatisierte Ausführung von Workflows, da Webservicedienste so kon-
zipiert werden können, dass sie sich zu Dienstleistungsketten bzw. Geschäftsprozessen
zusammenfügen lassen. Prozesse können über Standards wie Business Process Mode-
ling Notation, BPMN [
17
] oder Business Process Execution Language, BPEL, [
18
] be-
schrieben werden. Diese Prozesse können in Services gekapselt werden. Dabei kann die
Granularität der Services gröber oder feiner sein, wichtig dabei ist, dass ein Service eine
funktional abgegrenzte, fachlich autarke Funktionalität zur Verfügung stellt. Eine zu feine
Granularität bildet oft keine fachliche logische Sinndeutung eines Service, während eine
zu grobe Granularität eine zu abstrakte Zielsetzung formuliert. Je grobgranularer Funktio-
