PROJECT CONSULT ECM DRT DMS KM ILM
Logo PROJECT CONSULT - Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH  
 Contentmanager - Magazin
 Tipps für die DMS-Einführung
 Bereits bei der Auswahl der Dokumenten M
 Contentmanager - Magazin
 Relevante AdWords-Anzeigen mit Platzhalt
 Mit Platzhaltern können Werbetreibende i
 XING - Information & Documen
 [DE] Jobangebot: IT-Spezialist / IT-Proj
 Sehr geehrte Damen und Herren, mein Name
 XING - Information & Documen
 [DE] Jobangebot: IT-Spezialist / IT-Proj
 Sehr geehrte Damen und Herren, mein Name
Home  Englisch  Newsletter  Intern Hilfe  Kontakt  Impressum  Rechtshinweis 
  Detailsuche
PROJECT CONSULT Dr. Ulrich Kampffmeyer
Unternehmen
  Vision
  Grundsätze
  Leistungen
  Methoden
  Qualität
  Mitgliedschaft
  Slide-Show
  Mitarbeiter
  Auszeichnungen
  Unternehmensinfo
  Adresse
  AGB
Beratungsangebot
  Fachberatung
  Coaching
  Projekt-Management
  Workshops
  Anfrage
Seminarangebot
  Seminare
  Vorträge
  Seminartermine
  Handouts
  Anmeldung
Projekte
  Branchen
  Lösungen
Karriere
  Perspektive
  Stellenangebot
  Stellenmarkt
  Markt-Regeln
Presse
  Pressemitteilung
  Interview
  Artikelangebot
  Autorenrechte
  Akkreditierung
Website
  Sitemap
  Site-Info
  Aktualisierte Seiten
Impressum
Online-Publikationen
BIT Computer Zeitung
contentmanager.de ComputerWoche
documanager.de Document Management Magazine
DOKmagazin ECM Guide
E-Doc eGovernment Computing
Elektronische Steuerprüfung Information Week
IT-Business IT-Daily
IT Fokus KM World
Kommune21 MiD
MOS nfd
searchstorage.de silicon.de
Speicherguide Wissensmanagement
Google Werbung
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
Service Oriented Architecture
Abstract
Service Oriented Architecture
Geschäftsprozesse und Dienste
Anbieter und Konsument
Begriffe im SOA Umfeld
Zusammenfassung
von Christoph Jeggle
Top
Abstract
SOA, die Service Oriented Architecture, ist in der IT-Welt in aller Munde. Häufig wird sie nur als neue Technik betrachtet und nicht als das, was sie tatsächlich ist, ein Denkmuster, ein Paradigma. Jeder, der sich mit SOA beschäftigt, sollte sich dessen bewusst sein, um die Möglichkeiten von SOA zu entdecken. Dieser Artikel versucht als Beginn einer kleinen Reihe von Artikeln zum Thema SOA ein grundlegendes Verständnis für dieses Thema zu vermitteln.
Top
Service Oriented Architecture
SOA kann man nicht kaufen. Nun mag mancher einwenden, dass SOA doch im Markt angeboten wird, sogar jeder Softwareanbieter, der etwas auf sich und sein Produkt hält, für dieses mit SOA wirbt. Viele Produkte und auch Dienstleistungen schmücken sich mit der Bezeichnung SOA als Garant für Modernität und Zukunftssicherheit. Gibt es SOA also doch zu kaufen?
SOA kann man nicht kaufen, weil SOA keine fertige Lösung, keine technische Schnittstelle, sondern ein Paradigma, ein Denkmuster ist. Und Denkmuster kann man nicht kaufen, sondern nur anwenden.
Dieses Paradigma geht vom Begriff des Service, des Dienstes aus. Da möglicherweise viele, die diesen Artikel lesen, einen technischen Hintergrund haben, sei an dieser Stelle darauf hingewiesen, dass Service nicht sofort eine bestimmte technische Implementierung wie zum Beispiel Web Service meint. Wesentlich ist, dass ein solcher Dienst eine genau abgegrenzte, nicht zu komplexe Aufgabe umfasst, die genau definiert und beschrieben werden kann.
Top
Geschäftsprozesse und Dienste
Dieses Verständnis des Service wird nun verbunden mit einem erweiterten Verständnis von Geschäftsprozessen. Während eine klassische Beschreibung eines Geschäftsprozesses von dem Bild der Wertschöpfungskette ausgeht, in dem einem wie immer gearteten Produkt durch aufeinander folgende Verarbeitungsschritte Wert hinzugefügt wird, wird immer mehr deutlich, dass dieses einfache Modell in vielen Fällen nicht mehr der Komplexität heutiger Wirtschaft entspricht. Erweiterte Modelle gehen von einem Netzwerk von Beziehungen zu Kunden und Lieferanten aus, die untereinander Dienste anbieten oder anfordern. Dieses Netzwerk von Beziehungen bildet den Geschäftsprozess.
Dieses Verständnis von Geschäftsprozess als Netzwerk von angebotenen und in Anspruch genommenen Diensten gilt nicht nur für Geschäftsprozesse außerhalb des Unternehmens. Es kann auch auf die Prozesse innerhalb eines Unternehmens übertragen werden. Die einzelnen Abteilungen und Gruppen innerhalb des Unternehmens agieren dabei als Kunden für bzw. Lieferanten von Leistungen.
Genau hiermit sind die beiden wesentlichen Bestandteile von SOA beschrieben: der Prozess und der Dienst. Beide bilden den theoretischen Unterbau einer Service Oriented Architecture.
So geht es bei SOA in erster Linie also nicht um einen neuen technischen Standard oder eine neue Schnittstellentechnik. Bei SOA geht es um Geschäftsprozesse und die Dienste, die diesen Prozess abbilden.
Geschäftsprozesse in modernen Unternehmen sind heute nicht mehr denkbar ohne Informationstechnologie. SOA schlägt die Brücke vom Prozess zur IT. Die Service Oriented Architecture geht der Fragestellung nach, wie Geschäftsprozesse in der IT abgebildet werden können.
Diese Abbildung erfolgt dadurch, dass die Dienste, die für einen Geschäftsprozess erforderlich sind, von der IT bereitgestellt werden. Unter Diensten werden dabei Komponenten verstanden, die untereinander lose verbunden sind. Lose verbunden heißt dabei, dass die Komponenten nicht unlösbar voneinander abhängig sind, sondern durch andere Komponenten ersetzt werden können, die den gleichen Dienst anbieten. Die Steuerung des Geschäftsprozesses selbst erfolgt nicht durch die Komponenten oder anders gesagt Services/Dienste, sondern diese stellen nur die definierte Funktionalität zur Verfügung und sind nur für ihre eigenen Daten verantwortlich. Die nur lockere Verbindung der Dienste und die Kapselung der Daten, die für einen Dienst benötigt werden, stellen weitere wesentliche Merkmale von SOA dar. Die Dienste sind nur soweit miteinander verbunden, wie es notwendig ist für die Inanspruchnahme eines Dienstes durch einen anderen. Keiner der Dienste besitzt eine feste Verbindung zu einem anderen Dienst. SOA ist damit nicht vergleichbar mit Softwareanwendungen, die aus mehreren Komponenten bestehen und durch fest kodierte gegenseitige Aufrufe miteinander verbunden sind.
Top
Anbieter und Konsument
Aus der Sicht des Geschäftsprozesses stellt der Dienst ein Angebot dar, das möglicherweise konkurrierend zu anderen Diensten am "Markt" vorhanden ist und verwendet werden kann. Aus Sicht des Dienstes stellt der Geschäftsprozess den Konsumenten dar, der einen Dienst benötigt und den auswählt, der verfügbar ist und den Anforderungen entspricht.
Dieses Verhältnis von Anbieter (service provider) und Konsument (service consumer) ist auch eines der grundlegenden Elemente des OASIS Reference Models for Service Oriented Architecture 1.0 [1], mit dem ein Framework für SOA außerhalb jeder technischen Implementierung definiert wird. Dieses Framework fügt dem Modell des service providers und consumers noch die Begriffe policy und contract hinzu. Damit wird unterstrichen, dass das Verhältnis zwischen consumer und provider von einer genauen Spezifikation des Services einschließlich der allgemeinen Bedingungen und Einschränkungen, die für ihren Einsatz gelten, (policy) und der gegenseitigen Vereinbarung, unter welchen Bedingungen der Service genutzt werden kann (contract), abhängt.
Wie werden nun die Dienste, die, wie wir gesehen haben, nur locker miteinander verbunden sind, zu einem Gesamtsystem integriert? Der einfachste Weg besteht darin, dass die Anwendungen, die den Geschäftsprozess in der IT darstellen, die Dienste dann aufrufen, wenn sie benötigt werden. Für überschaubare Systeme mit einer geringen Zahl von Anwendungen ist das sicherlich möglich und bietet auch den Vorteil, dass die Dienste ausgetauscht werden können, ohne dass die Anwendung selbst davon berührt wird, sofern der neue Dienst sich genau an die Anforderungen hält, die an den Dienst gestellt werden.
Damit ist aber höchstens eine Teilmenge der Möglichkeiten einer SOA ausgenutzt worden. Da SOA ein Paradigma ist, das sich am Geschäftsprozess orientiert, ist es nur zu sinnvoll, dass dieser Geschäftsprozess selbst Bestandteil der SOA ist.
Damit kommen wir zu den Begriffen der Orchestrierung und Choreografie. Zu einer vollständigen SOA gehören Komponenten, die definieren, für welche Aufgabe welcher Dienst verwendet wird, und die Prozesssteuerung übernehmen, damit die Dienste in der richtigen Abfolge und unter den richtigen Bedingungen aufgerufen werden.
Top
Begriffe im SOA Umfeld
Vor diesem Hintergrund sollen nun einige Begriffe erläutert werden, die im Umfeld von SOA immer wieder genannt werden und häufig eher zur Verwirrung als zur Klärung beitragen.
Begriffe wie Enterprise Service Bus (ESB), Enterprise Application Integration (EAI) beschreiben, wie der Aufruf von Services durchgeführt werden kann. Dabei ist EAI mehr technisch ausgerichtet auf die Lösung der Fragestellung, wie Anwendungen bzw. Dienste mit unterschiedlichen Schnittstellen aufgerufen werden können. ESB ist dagegen stärker auf die Abbildung von Prozessen durch Dienste ausgerichtet.
Web Services und die damit zusammenhängenden Begriffe SOAP, Universal Description, Discovery and Integration (UDDI), Web Services Description Language (WSDL) sind dagegen eine spezifische Implementation, die für SOA verwendet werden kann. Diese Begriffe sind keinesfalls gleichbedeutend mit SOA, und Systeme, die Web Services verwenden, sind auch nicht unbedingt eine Implementierung einer Service Oriented Architecture.
Dennoch zeigt die Implementierung von SOA durch die Web Services, welche Elemente wichtig sind. SOAP ist die auf XML beruhende Schnittstelle zu den Diensten. Dabei wird per XML sowohl der Funktionsaufruf als auch die dazu gehörenden Daten übergeben und die Antwort des Dienstes zurückgegeben. UDDI und WSDL sind die Implementierung der Registrierung von Diensten im Sinne einer Bekanntmachung des Angebotes, um beim Bild des Anbieters und des Konsumenten zu bleiben. Dabei wird zu einen die Plattform geschaffen, in der solche Angebote abgegeben werden können, zum anderen aber auch festgelegt, wie das Angebot beschrieben werden soll.
Es fehlt aber noch die Komponente der Prozesssteuerung. In diesen Bereich gehören Begriffe wie Business Process Management (BPM), Business Process Execution Language (BPEL), Business Process Modeling Notation (BPMN). Während BPM ein allgemeiner Oberbegriff ist, stellen die beiden anderen Begriffe konkrete Möglichkeiten der grafischen (BPMN) bzw. XML-basierenden (BPEL) Darstellung von Prozessen dar.
Top
Zusammenfassung
SOA kann man nicht kaufen. SOA muss angewendet werden. Das ist zugleich die Stärke und das Risiko von SOA. Es ist kein technischer Standard, der in dem Moment der Standardisierung bereits technisch überholt ist, und damit keine kurzlebige Modeerscheinung. Vielleicht wird der Begriff der Service Oriented Architecture nach einiger Zeit nicht mehr modern sein und durch einen anderen ersetzt werden. Aber das Paradigma der SOA selbst, Geschäftsprozesse eng mit der Informationstechnologie zu verknüpfen und diese als notwendiges und wichtiges Mittel zur Ausführung der Prozesse zu sehen und nicht als Selbstzweck, wird für die Informationstechnologie, die den Kinderschuhen der alleinigen Technikorientierung entwächst, bleiben. Vielleicht ändert sich das Etikett, aber das Paradigma entwickelt sich weiter.
Zugleich ist die Tatsache, das SOA nicht einfach zu kaufen ist, auch die Schwäche in vielen SOA Projekten, in denen SOA-fähige Produkte eingekauft werden, in der Hoffnung so eine Service Oriented Architecture implementieren zu können, ohne dass die Geschäftsprozesse sorgfältig definiert und mit den vorhandenen oder neuen Anwendungen implementiert werden. SOA ist zunächst keine Frage der Technik und keine Aufgabe für IT-Spezialisten, sondern zu aller erst eine Aufgabe der Fachabteilungen.
Link
[1] OASIS Reference Models for Service Oriented Architecture 1.0 vom
2. August 2006
www.oasis-open.org
Rechtshinweis
© CopyRight PROJECT CONSULT 2007
Autorenrechte Christoph Jeggle

Rechtshinweis
Autorenrechte
Zum Download sind ausschließlich die Beiträge in der Rubrik Download vorgesehen. Als PDF bereitgestellte Beiträge enthalten auch die zugehörigen Grafiken.
Download

Top
Seitentitel: Artikel_SOA, Zitierung: http://www.pc.qumram-demo.ch/portal.asp?SR=864
Zuletzt aktualisiert am: 26.2.2008
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
News
  Newsletter
  Newsletter Inhaltsverzeichnis
  Newsletter PDF-Ausgaben
  Newsletter Portal
  Newsletter Probeabo
  Branchen-News
  In der Diskussion
  Zitate
  Veranstaltungen
  Termine
Wissen
  Was ist...
  Archiv
  Artikel
  Pressespiegel
  Bücher
  Studien
  Literatur
  Standards
  Code of Practice
  Rechtsfragen
  Links
  Download
Markt
  Kategorie
  Alle
  PLZ
  Marktübersichten
  Produktvergleich
  Eintrag
  Regeln
Foren
  CDIA+ Forum
  CMS-Forum
  DMS-Forum
  ECMguide
  Speicherguide
  XING-Forum
Spezial-Seiten
  CDIA+
  MoReq
Web Partner
AIIM Europe AIIM International
Benchpark BIT
BITKOM BrainGuide
Coextant CompetenceSite
CompTIA contentmanager.de
DLM-Network DMS Akademie
DMS Expo documanager.de
doxtop.com ECM WORLD
Electronic Office Elektronische Steuerprüfung
GDPdU-Portal GoodNews!
Kossow & Jeggle Results Open Directory Project
Optimila password
Plattform Wissensmanagement silicon.de
SoFind Wikipedia
Wissensmanagement XING
AMAZON
  Dokumenten-Technologien
  Dokumenten-Management
  E-Learning & E-Term
  Enterprise Content Management