Nicolai Josuttis SOA in der Praxis System-Design für verteilte Geschäftsprozesse dpunkt.verlag ISBN-10: 3898644766 ISBN-13: 978-3898644761

 

Dieses Glossar ist eine gepflegte Version des SOA-Glossars des Buchs "SOA in der Praxis" von Nicolai Josuttis.

DiesesGlossar kann verwendet werden, sofern die dazugehörige Quelle (Buch oder die originale Web-Seite http://soa-in-der-praxis.de/soa-glossar.html) angegeben wird.

2PC (Two-Phase-Commit)
Ein Ansatz für konsistente Änderungen auf verschiedenen Systemen. In einer ersten Phase werden alle Backends um eine Zustimmung für eine oder mehrere geplante Änderungen gebeten. Nach Zustimmung aller werden diese Änderungen in einer zweiten Phase überall durchgeführt. Im Zuge der Umsetzung der Prinzipien der losen Kopplung wird bei SOA statt 2PC typischerweise Kompensation verwendet.

Activity
Siehe Aktivität

Agent
Ein Synonym für Beteiligter aus dem Umfeld von Web-Services, also ein Oberbegriff für Anbieter oder Nutzer.

Aktivität (engl.: activity)
Einer der möglichen Begriffe für einen Schritt in einem Geschäftsprozess. Im Kontext von SOA wird eine Aktivität typischerweise als Service implementiert.

Anbieter (engl.: provider)
Bezeichnung für ein System oder eine Komponente, die einen Service bereitstellt, der durch einen Nutzer aufgerufen werden kann.

Architektur
Nach BassClementsKazman03 besteht die Architektur eines IT-Systems aus der Struktur bzw. den Strukturen dieses Systems. Dazu gehören (Hardware- und) Software-Komponenten, die nach außen sichtbaren Eigenschaften dieser Komponenten und deren Beziehungen untereinander.

Asynchrone Kommunikation
Eine Art der Kommunikation, bei der zwischen dem Senden und dem Empfang des Inhalts einer Nachricht ein messbares Zeitintervall besteht. Nachrichtenorientierte Middleware wird typischerweise auf Basis dieses Konzepts implementiert, indem Nachrichten-Puffer (Message-Queues) eingeführt werden, die Nachrichten, die von einem System versendet werden, (persistent) puffern, bis sie den empfangenden Systemen zugestellt werden können.
Asynchrone Kommunikation ist eine Form von loser Kopplung, da sie die Anforderung vermeidet, dass Sender und Empfänger beide gleichzeitig verfügbar sein müssen.

Asynchrones Request/Response
Alternative Bezeichnung für das Message-Exchange-Pattern Request/Callback.

Aufgabe (engl.: task)
Möglicher Begriff für einen Schritt eines Geschäftsprozesses. Im Kontext von SOA wird eine Aufgabe typischerweise als Service implementiert.

Backend
Ein System, das die Daten und/oder Geschäftsregeln einer spezifischen Domäne verwaltet. Ein Backend spielt eine bestimmte fachliche Rolle in einer Systemlandschaft und/oder hat eine fachliche Verantwortung. In SOA wird ein Backend typischerweise durch Basis-Services gekapselt.

Basis-Service
Bezeichnung für Services, die eine grundlegende fachliche Funktionalität eines einzelnen Backends bereitstellen. Diese Services sind typischerweise die ersten, die man verwendet, um Implementierungsdetails eines spezifischen Backends zu kapseln.
Es gibt zwei Arten von Basis-Services: Basis-Daten-Services lesen und/oder schreiben Daten. Basis-Logik-Services bilden Geschäftsregeln ab.
Basis-Services bilden den Ausgangspunkt zur Komposition höherwertiger Services, wie Composed-Services und Prozess-Services.

Beteiligter (engl.: participant)
Oberbegriff für Anbieter und Nutzer. In der Terminologie von Web-Services wird dafür auch Agent verwendet.

BPEL
Business Process Execution Language. Eine XML-basierte Sprache, mit der man Services zu Composed-Services oder Prozess-Services orchestrieren kann. Die resultierenden Services sind Web-Services.
IDEs ermöglichen es, diese Services über ein grafisches User-Interface zu spezifizieren und als BPEL-Dateien zu speichern. BPEL-Engines dienen dann dazu, diese Dateien zur Laufzeit als Service-Implementierungen zu interpretieren und somit die entsprechenden Geschäftsprozesse ablaufen zu lassen.

BPM
Siehe Geschäftsprozessmanagement und Geschäftsprozessmodellierung.

BPMN
Business Process Modeling Notation. Eine grafische Notation für Geschäftsprozesse, die von der OMG gepflegt wird.

Bus
Ein abstraktes Software-Pattern (Muster) für den Datenaustausch zwischen unterschiedlichen Systemen. Im Gegensatz zum Hub-and-Spoke-Pattern wird eine dezentrale Föderation von Komponenten verwendet, die alle einem gemeinsamen Protokoll und dazugehörigen Richtlinien folgen, um Nachrichten zu senden, weiterzuleiten oder zu empfangen.

Business Process
Siehe Geschäftsprozess

Business Process Execution Language
Siehe BPEL

Business Process Management
Siehe Geschäftsprozessmanagement

Business Process Modeling
Siehe Geschäftsprozessmodellierung

Business Process Modeling Notation
Siehe BPMN

Choreografie
Eine Form der Aggregation von Services zu Geschäftsprozessen. Im Gegensatz zur Orchestrierung komponiert Choreografie keinen neuen Service, der Kontrolle über den gesamten Prozess hat, sondern definiert Regeln und Richtlinien, damit verschiedene Services zusammen einen Geschäftsprozess bilden können. Jeder daran beteiligte Service-Kontext sieht allerdings nur einen Ausschnitt und trägt nur einen Teil zum gesamten Prozess bei.

CMMI
Capability Maturity Model Integration. Ein Ansatz zur Kategorisierung und Verbesserung der Entwicklungsprozesse für Produkte und Software. CMMI ist eine Erweiterung von SW-CMM (früher nur unter dem Namen CMM bekannt), was sich speziell mit den Aspekten der Softwareentwicklung beschäftigt. Teil dieses Ansatzes ist eine Kategorisierung des Reifegrades des Entwicklungsprozesses einer Organisation in unterschiedliche Stufen ("initial", "gemanagt", "definiert", "quantitativ gemanagt" und "optimierend").

Compensation
Siehe Kompensation

Composed-Service
Bezeichnung für Services, die aus Basis-Services und/oder anderen Composed-Services komponiert sind. Im Gegensatz zu Prozess-Services handelt es sich um "Micro-Flows", die zumindest aus fachlicher Sicht zustandslos sind.

Consumer
Siehe Nutzer

Contract
Siehe Vertrag

CORBA
Common Object Request Broker Architecture. Ein OMG-Standard für den Zugriff auf Objekte fremder Plattformen. Obwohl die initiale Absicht von CORBA eine Umsetzung des Konzepts verteilter Objekte war, kann CORBA auch als SOA-Infrastruktur verwendet werden, indem man sich auf das Konzept "Objects by Value" (OBV) beschränkt.

Domain-Specific Language
Siehe domänenspezifische Sprache

Domäne (engl.: domain)
Ein definierter fachlicher Bereich oder Geltungsbereich, der eine bestimmte Rolle spielt und/oder eine bestimmte Verantwortung übernimmt. Im Kontext von SOA kann es sich um eine Organisation, eine Firma, eine Geschäftseinheit, eine Abteilung, ein Team, ein System oder eine Komponente handeln.

Domämenspezifische Sprache (DSL) (engl.: domain-specific language)
Eine spezifische grafische oder textuelle Notation für ein Metamodell. Sie ermöglicht es, die Eigenschaften eines konkreten Modells in einer präzisen, kompakten, lesbaren und vollständigen Form zu spezifizieren.

EAI
Enterprise-Application-Integration (manchmal auch nur "Enterprise-Integration" oder EI genannt). Ein Ansatz zur Integration verteilter Systeme durch eine gemeinsame Infrastruktur (Middleware und/oder Protokoll). Bei diesem Ansatz benutzt jedes System einen Adapter für die gemeinsame Infrastruktur, anstatt eine individuelle Verbindung mit jedem System aufzubauen. Die Infrastruktur mag dabei einen Bus- oder einen Hub-and-Spoke-Ansatz haben.
SOA kann man als Erweiterung von EAI betrachten, wobei EAI sich um den technischen Aspekt der Interoperabilität kümmert. Eine EAI-Plattform kann deshalb auch als ein (wesentlicher Teil eines) Enterprise-Service-Bus (ESB) dienen.

EDA
Siehe ereignisgesteuerte Architektur

Enterprise-Application-Integration
Siehe EAI

Enterprise-Service-Bus (ESB)
Die Infrastruktur einer SOA-Landschaft, die die Interoperabilität der Services ermöglicht. Die Kernaufgaben bestehen darin, Konnektivität zu schaffen, Daten zwischen verschiedenen Plattformen zu transformieren, Nachrichten (intelligent) zu routen und nicht zuletzt Möglichkeiten zum Überwachen, Protokollieren und Debuggen zu schaffen. Darüber hinaus kann es höherwertige Dienstleistungen geben, die sich um Sicherheitsaspekte und Zuverlässigkeit kümmern, Services verwalten oder sogar Geschäftsprozesse komponieren. Es gibt allerdings unterschiedliche Auffassungen darüber, ob ein Werkzeug zur Komposition von Services Teil eines ESB ist oder nur eine der Plattformen ist, die ein ESB integriert.
Hersteller tendieren dazu, einen ESB als etwas zu definieren, das man als Produkt kaufen kann (und muss). Es kann sich allerdings auch nur um ein Konzept bzw. Protokoll handeln, dessen Einhaltung und Nutzung zu Interoperabilität führt, ohne dass man ein spezifisches Stück Hard- oder Software kaufen muss (Web-Services stellen inhärent ein derartiges Protokoll dar).
Ein ESB kann heterogen sein und unterschiedliche Middleware- und Kommunikations-Technologien nutzen.
Man kann EAI-Lösungen als (Teil eines) ESB betrachten.

EPK
Siehe ereignisgesteuerte Prozesskette

Ereignis (engl.: event)
Eine Benachrichtigung, die von einem Sender (Anbieter) zu einer mehr oder weniger bekannten Menge von Empfängern (Nutzern) gesendet wird. Typischerweise müssen Empfänger für den Empfang von Ereignissen registriert werden. Dies kann prinzipiell zur Entwicklungszeit, zur Startzeit oder zur Laufzeit erfolgen.
Man kann Ereignisse als Teil des Publish/Subscribe-Message-Exchange-Pattern und ereignisgesteuerte Architekturen deshalb als Teil oder Erweiterung von SOA betrachten.

Ereignisgesteuerte Architektur (EDA) (engl.: event-driven architecture)
Ein Softwarearchitektur-Pattern für die Erzeugung, Registrierung, Konsumierung und Verarbeitung von Ereignissen.
Manchmal wird EDA als Erweiterung oder Ergänzung von SOA und manchmal als Teil davon betrachtet. Im letzten Fall kann man Ereignisse als spezielle Form von Nachrichten ansehen, die im Rahmen spezieller Message-Exchange-Pattern vom Anbieter an den oder die Nutzer gesendet werden.

Ereignisgesteuerte Prozesskette (EPK) (engl.: event-driven process chain, EPC)
Eine grafische Notation für Geschäftsprozesse, die vor allem bei ARIS und SAP verwendet wird.

ESB
Siehe Enterprise-Service-Bus

Event
Siehe Ereignis

Event-Driven Architecture
Siehe ereignisgesteuerte Architektur

Fire-and-Forget
Alternativer Name für Nachrichten eines One-Way-Message-Exchange-Pattern, bei dem eine Nachricht geschickt wird, ohne dass eine Antwort erwartet wird.

Frontend
Ein System, das Geschäftsprozesse startet, indem es die entsprechenden Services aufruft. Ein Frontend agiert also als Service-Nutzer. Es kann sich um ein System mit Bedienoberfläche (menschlicher Interaktion) oder um ein Batch-Programm handeln.

Geschäftsprozess (engl.: business process)
Eine strukturierte Beschreibung der notwendigen Aktivitäten oder Aufgaben zur Erfüllung einer bestimmten fachlichen Aufgabe. Die Aktivitäten oder Aufgaben können manuelle Schritte (menschliche Interaktion) oder automatisierte Schritte (IT-Schritte) sein.
Geschäftsprozesse können verwaltet werden (siehe Geschäftsprozessmanagement) und mit Hilfe von Modellierungsnotationen wie BPMN oder EPK oder Ausführungssprachen wie BPEL implementiert werden.
Manchmal wird zwischen Geschäftsprozessen und Workflows insofern unterschieden, als Geschäftsprozesse eher beschreiben, was passieren muss, während Workflows sich eher darum kümmern, wie Aktivitäten oder Aufgaben ausgeführt werden müssen.

Geschäftsprozessmanagement (GPM) (engl.: business process management, BPM)
Oberbegriff für alle Aktivitäten zur systematischen Verwaltung von Geschäftsprozessen. Dazu gehört in der Regel die Planung, Implementierung, Dokumentation, Auswertung und Verbesserung von Geschäftsprozessen sowie die Geschäftsprozessmodellierung.

Geschäftsprozessmodellierung (GPM) (engl.: business process modeling, BPM)
Nach BloombergSchmelzer06 versteht man unter Geschäftsprozessmodellierung "eine Menge von Praktiken oder Maßnahmen, die Unternehmen durchführen können, um alle Aspekte eines Geschäftsprozesses darstellen oder beschreiben zu können. Dazu gehören der Ablauf (englisch: flow), Kontroll- und Entscheidungspunkte, Trigger und Bedingungen für den Aufruf von Aktivitäten, der Kontext, in dem eine Aktivität stattfindet, und die dazugehörigen Ressourcen".

Governance
Wörtlich übersetzt: "Steuerung". In SOA wird der Begriff zur Beschreibung aller Maßnahmen verwendet, die dafür sorgen, dass in Bezug auf SOA das Richtige getan wird. Was das bedeutet, dafür gibt es große Interpretationsspielräume. Es sind aber auf jeden Fall die Themen Prozesse, Werkzeuge und Richtlinien involviert.

GPM
Siehe Geschäftsprozessmanagement und Geschäftsprozessmodellierung.

HTTP
Hypertext Transfer Protocol. Das Basisprotokoll des Internets (World-Wide-Web). In der sicheren Variante (wenn mit SSL verschlüsselt wird) wird es HTTPS genannt.

Hub-and-Spoke
Ein abstraktes Software-Pattern (Muster) für den Datenaustausch zwischen unterschiedlichen Systemen. Im Gegensatz zum Bus-Pattern werden eine oder mehrere zentrale Komponenten ("Hubs") verwendet, die die gesamte Kommunikation zwischen Sendern und Empfängern koordinieren.

IDE
Integrated development environment. Ein (zumeist grafisches) Werkzeug zur Entwicklung spezifischer Software für oder in einer bestimmten Umgebung.

Idempotenz (engl.: idempotency)
In SOA beschreibt Idempotenz die Fähigkeit von Services, mit dem Sachverhalt umzugehen, dass ein und dieselbe Nachricht unter Umständen mehrfach ausgeliefert wird. Erneute Zustellungen sollten also zu keinen anderen Ergebnissen als einmalige Zustellungen führen.
In unzuverlässigen Netzwerken oder Protokollen (wie HTTP) ist diese Eigenschaft wichtig, wenn bei fehlender Bestätigung für die Zustellung einer Nachricht eine erneute Zustellung (Retry) versucht wird.
Services können fachlich oder technisch idempotent sein bzw. gemacht werden.

Interoperabilität
Die Fähigkeit unterschiedlicher Systeme, miteinander zu kommunizieren. Interoperabilität zwischen unterschiedlichen Plattformen und Programmiersprachen ist ein wesentliches Ziel von SOA.
Man beachte, dass Standards nicht notwendigerweise zu Interoperabilität führen. Aus diesem Grund gibt es im Umfeld von Web-Services eine spezielle Organisation, WS-I, die Profiles definiert, die dafür sorgen sollen, dass Standards zu Interoperabilität führen.

JMS
Java Message Service. Das Standard-API von Java für nachrichtenorientierte Middleware (MOM). Da es sich dabei nur um einen API-Standard handelt, führt die Verwendung von JMS zur Portabilität (zur Möglichkeit, die Middleware unter Beibehaltung der Schnittstellen zu wechseln), aber nicht zu Interoperabilität (die gleichzeitige Verwendung unterschiedlicher JMS-Implementierungen).

Kompensation (engl.: compensation)
Ein Ansatz für konsistente Änderungen auf verschiedenen Systemen. Im Gegensatz zu 2PC finden bei Kompensation die Änderungen nicht auf allen Backends gleichzeitig statt. Stattdessen führt man die Änderungen sequenziell oder parallel durch und definiert/implementiert "kompensierende" Änderungen ("Stornierungen"), die dann aufgerufen werden, wenn nicht alle Änderungen auf allen Backends erfolgreich sind. Die Konsequenz dieses Ansatzes ist eine losere Kopplung zwischen den Systemen; dafür muss man aber die Kompensierungen explizit ausprogrammieren.
BPEL bietet direkte Unterstützung für Kompensation.

Lose Kopplung (engl.: loose coupling)
Das Konzept, Abhängigkeiten zwischen Systemen zu reduzieren. Es gibt dabei unterschiedliche Möglichkeiten, eine (zu) enge Bindung zwischen Systemen zu reduzieren, z.B. unterschiedliche Objektmodelle, asynchrone Kommunikation oder die Verwendung von Kompensation statt 2PC zur Sicherstellung übergreifender Konsistenz.
In der Regel führt lose Kopplung zu mehr Komplexität. Aus diesem Grund sollte man in einer konkreten SOA das richtige Maß an loser Kopplung mit Bedacht festlegen.

MDSD (engl.: model-driven software development)
Modellgetriebene Softwareentwicklung. Ein Ansatz, bei dem aus einem abstrakten Modell schematischer Code und andere Artefakte (andere Modelle) erzeugt werden. Der generierte Code für unterschiedliche Modelle hat prinzipiell zwar den gleichen Aufbau, unterscheidet sich aber in konkreten Details wie in den verwendeten Datentypen.
Im Kontext von SOA kann man darunter auch "modellgetriebene Service-Entwicklung" verstehen.

Message
Siehe Nachricht

Message-Exchange-Pattern (MEP)
Die Definition der genauen Abfolge der ausgetauschten Nachrichten im Rahmen eines Service-Aufrufs. Dabei werden Reihenfolge, Richtung und Anzahl dieser Nachrichten betrachtet.
Die wichtigsten MEPs sind One-Way, Request/Response und Request/Callback (asynchrones Request/Response).
Das Request/Response-MEP definiert zum Beispiel, dass ein Nutzer als Anfrage eine Nachricht sendet und auf die Antwort wartet, die vom Anbieter dazu verschickt werden muss.

Message-oriented middleware (MOM)
Siehe nachrichtenorientierte Middleware

Metamodell
Eine (formale) Beschreibung eines Modells. Es beschreibt die Regeln, die den möglichen Aufbau dazugehöriger Modelle festlegen. Ein Metamodell spezifiziert also die formale Struktur und die Elemente eines Modells.

Modell
Eine (formale) Abstraktion. In SOA dient ein Modell typischerweise zur Spezifikation von Services. Mit Hilfe von MDSD kann man daraus dann unterschiedlichen Code und andere Artefakte generieren.
Die Struktur eines Modells wird typischerweise in einem Metamodell beschrieben. Für die Modelle gibt es in der Regel eine oder mehrere spezifische grafische oder textuelle Notationen, die man auch domänenspezifische Sprache (DSL) nennt.

Model-Driven Software/Service Development
Siehe MDSD

Nachricht (engl.: message)
Ein Paket von Daten, das im Rahmen eines Service-Aufrufs zwischen den beteiligten Systemen ausgetauscht wird. Message-Exchange-Patterns definieren dabei die genaue Abfolge von Nachrichten, die im Rahmen eines Aufrufs ausgetauscht werden (können).

Nachrichtenorientierte Middleware (engl.: message-oriented middleware, MOM)
Eine Kommunikationsinfrastruktur auf Basis der asynchronen Kommunikation. Beispiele dafür sind WebSphere-MQ (früher MQ-Series) von IBM, MSMQ von Microsoft, Tibco Rendevous, SonicMQ und JMS.

Nutzer (engl.: consumer)
Allgemeine Bezeichnung für ein System, das einen Service aufruft (eine Dienstleistung konsumiert), der von einem Anbieter zur Verfügung gestellt wird. Eine andere Bezeichnung für diese Rolle ist (Service-)Aufrufer (Requestor).

OASIS
Organization for the Advancement of Structured Information Standards. Ein internationales gemeinnütziges IT-Konsortium für die Entwicklung, Konsolidierung und Adaption von E-Business- und Web-Services-Standards. Siehe http://www.oasis-open.org.

OMG
Object Management Group. Ein internationales, gemeinnütziges IT-Konsortium zur Entwicklung von Standards für die Integration von Unternehmen. Zu den Standards der OMG gehören UML, MDA und BPMN. Siehe http://www.omg.org.

One-Way
Ein Message-Exchange-Pattern, bei dem bei einem Service-Aufruf eine Nachricht vom Nutzer an den Anbieter gesendet wird, ohne dass auf eine Antwort gewartet wird. Ein alternativer Name ist Fire-and-Forget.

Orchestrierung
Eine Form der Aggregation von Services zu höherwertigen Services und Geschäftsprozessen. Im Gegensatz zur Choreografie werden Services zu einem neuen Service komponiert, der dann die zentrale Steuerung des gesamten Ablaufs übernimmt.
Bei Web-Services dient BPEL als Standard für die Orchestrierung. Dafür werden Entwicklungswerkzeuge und Laufzeitumgebungen ("Engines") angeboten.

Participant
Siehe Beteiligter

Policy
Siehe Richtlinie

Profile
Im Kontext von SOA und vor allem Web-Services ist ein Profile eine Menge von Festlegungen für ein oder mehrere Standards mit dem Ziel, für diese Standards Interoperabilität sicherzustellen. Zu den Festlegungen können Versionsdefinitionen, Einschränkungen, Ergänzungen bisher offener Punkte, Richtlinien und Konventionen gehören.
Die meisten Profiles werden vom WS-I spezifiziert.

Provider
Siehe Anbieter

Prozess
Eine strukturierte Menge von Schritten (Aktivitäten oder Aufgaben), um ein Problem zu lösen oder ein Ziel zu erreichen.
In SOA existieren unterschiedliche Prozesse: Das eigentliche Ziel besteht darin, Geschäftsprozesse zu implementieren. Zusätzlich benötigt man Prozesse, um Lösungen und Services zu realisieren und zu verwalten (Lebenszyklen usw.). Auf Metaebene existiert außerdem der Prozess zur Einführung und Steuerung (Governance) von SOA.

Prozess-Service
Ein Service, der einen langlaufenden Workflow oder Geschäftsprozess repräsentiert. Aus fachlicher Sicht repräsentiert ein derartiger Service einen "Makro-Flow", also eine langlaufende Folge von Aktivitäten (Services), die unterbrechbar ist.
Im Gegensatz zu Basis-Services und Composed-Services haben diese Services in der Regel einen Zustand, der über mehrere Aufrufe/Zugriffe von außen erhalten bleibt.

Publish/Subscribe
Ein Message-Exchange-Pattern, bei dem ein Nutzer sich registriert (englisch: subscribe), um eine Benachrichtigung durch einen Anbieter zu bekommen, wenn eine bestimmte Bedingung erfüllt ist oder sich eine bestimmte Änderung ergibt.
Die Registrierung kann zur Entwicklungs-, Start- oder Laufzeit erfolgen. Wenn der Anbieter den Nutzer nicht kennt und/oder akzeptieren muss, ist dies die Basis für ereignisgesteuerte Architektur (EDA), bei der die Benachrichtigung ein Ereignis ist.

Registry
Registries verwalten Services aus technischer Sicht (im Gegensatz zu Repositories, die Services aus fachlicher Sicht verwalten).
Registries sollten also alle technischen Details verwalten, die für das Betreiben einer Service-Landschaft notwendig sind. Dazu gehören neben Signaturen zum Beispiel auch Deployment-Informationen. Meistens wird eine Registry als Teil der Infrastruktur (des ESB) betrachtet.

Repository
Repositories verwalten Services aus fachlicher Sicht (im Gegensatz zu Registries, die Services aus technischer Sicht verwalten). Dazu gehören Schnittstellen, Verträge, Service-Level-Agreements, Abhängigkeiten und alles, was für die Analyse und das Design von Geschäftsprozessen notwendig ist. Im Gegensatz zu einer Registry sollte diese Beschreibung unabhängig von technischen Details und infrastrukturspezifischen Aspekten sein. Ein Repository sollte also von einem Wechsel der Infrastruktur (des ESB) nicht betroffen sein.

Request
Eine Nachricht, die von einem Nutzer in den meisten Message-Exchange-Patterns initial versendet wird (siehe Request/Response und Request/Callback).
Manchmal wird dieser Begriff auch als Synonym für einen Service-Aufruf verwendet.

Request/Callback
Ein Message-Exchange-Pattern, bei dem ein Nutzer im Rahmen eines Service-Aufrufs eine Anfrage-Nachricht (Request) sendet, auf deren Antwort (Response) er aber nicht blockierend wartet. Stattdessen wird eine Callback-Funktion definiert, die dann aufgerufen wird, wenn die Antwort des Anbieters später eintrifft.
Request/Callback wird manchmal auch asynchrones Request/Response genannt.

Requestor
Alternativer Begriff für Nutzer (vor allem im Umfeld von Web-Services verwendet).

Request/Response
Ein Message-Exchange-Pattern, bei dem ein Nutzer als Service-Aufruf (Request) eine Nachricht an den Anbieter sendet und eine Antwort (Response) erwartet.
Typischerweise wartet der Nutzer dabei blockierend, bis die Antwort-Nachricht eintrifft. Manchmal kann man aber auch warten, ohne zu blockieren. Insofern kann man zwischen synchronem und asynchronem Request/Response unterscheiden. Letzteres wird auch Request/Callback genannt.

Response
Eine Nachricht, die von einem Anbieter als Antwort auf eine Anfrage (Request) versendet wird (siehe Request/Response).

Richtlinie (engl.: policy)
Eine allgemeine Regel oder Empfehlung. In SOA haben Richtlinien einen Einfluss auf die Infrastruktur (ESB), die Anbieter und die Nutzer. Eine Richtlinie mag zwingend sein (wie zum Beispiel eine Namenskonvention) oder ein Ziel verkörpern (wie zum Beispiel die maximale Anzahl von in Betrieb befindlichen Versionen eines Service).

Service
Die IT-Umsetzung einer für sich selbst stehenden fachlichen Funktionalität.
Technisch besteht ein Service aus einer oder mehreren Operationen, die Nachrichten verwenden, um Daten zwischen einem Anbieter und einem Nutzer auszutauschen. Dabei startet der Nutzer typischerweise mit einem Service-Aufruf, um vom Anbieter Informationen oder Daten zu bekommen oder den Zustand des Systems, das der Anbieter repräsentiert, zu verändern.
Services können unterschiedliche Eigenschaften (Attribute) haben und in unterschiedliche Kategorien eingeteilt werden. Die wichtigste Kategorisierung unterteilt Services in Basis-Services, Composed-Services und Prozess-Services.
Ein Service wird typischerweise durch eine Schnittstelle beschrieben. Die vollständige Beschreibung inklusive Semantik wird auch "wohldefinierte Schnittstelle" genannt. Zusammen mit den nichtfunktionalen Anforderungen an einen Service werden diese Daten in Verträgen formuliert, die jeweils zwischen einem konkreten Anbieter und einem konkreten Nutzer geschlossen werden.

Service-Level-Agreement (SLA)
Eine formale ausgehandelte Vereinbarung zwischen zwei Parteien über die Qualität einer angebotenen Dienstleistung. Dazu wird das gemeinsame Verständnis in Bezug auf Wichtigkeit, Verantwortlichkeit, Verfügbarkeit und Performance festgehalten. Auch Kosten und Strafen können festgelegt werden.
Im Kontext von SOA sind diese Parteien typischerweise ein Anbieter und ein Nutzer eines Service. Die wichtigsten Vereinbarungen betreffen in der Regel die Verfügbarkeit (z.B. "7x24"), die Antwortzeit (z.B. "80% < 0,5 Sekunden") und den Durchsatz (z.B. "max. 10.000 Aufrufe pro Stunde").
Ein SLA ist typischerweise Bestandteil eines Vertrags.

Service-orientierte Architektur (SOA)
Es gibt viele Definitionen zu SOA. Manche spezifizieren nur, dass es ein Ansatz für Architekturen ist, bei dem die Schnittstellen Services sind. Gemeinhin (und nach meinem Verständnis) ist SOA aber ein architekturelles Paradigma/Denkmuster für den Umgang mit Geschäftsprozessen, die in einer großen, verteilten und heterogenen Systemlandschaft implementiert und betrieben werden, wobei die einzelnen Systeme unterschiedliche Eigentümer haben.
Die entscheidenden Konzepte von SOA sind Services, Interoperabilität und lose Kopplung. Die wesentlichen Zutaten sind eine Infrastruktur (der ESB), Architektur-Entscheidungen und Prozesse. Entscheidende Erfolgsfaktoren sind Verständnis, Steuerung (Governance), Management-Unterstützung und Hausaufgaben.
Man beachte, dass Web-Services kein Synonym für SOA ist. Web-Services sind eine mögliche Art und Weise, die Infrastrukturaspekte von SOA zu implementieren.

SOAP
SOAP ist das Basisprotokoll von Web-Services. In einem XML-basierten Format wird festgelegt, wie eine ausgetauschte Nachricht mit Header und Body aussieht.
Früher war SOAP eine Abkürzung für "Simple Object Access Protocol", da SOAP aber weder einfach war noch für Objektzugriffe diente, steht der Begriff heutzutage für sich selbst.
Das Protokoll ermöglicht unterschiedliche Arten des konkreten Nachrichtenaustauschs. Das derzeit verbreitetste SOAP-Format ist "document/literal wrapped".

Softwarearchitektur
Siehe Architektur

SSL
Ein Verschlüsselungsprotokoll für das Internet-Protokoll HTTP. Dessen Anwendung bei HTTP nennt man HTTPS.

Task
Siehe Aufgabe

Two-Phase-Commit
Siehe 2PC

UBR
Die "UDDI Business Registry" wurde im Jahre 2000 als weltweites Zentralregister (eine Registry) für öffentliche Web-Services ins Leben gerufen. Die Idee funktionierte allerdings nicht, sodass das UBR 2006 wieder außer Betrieb genommen wurde.

UDDI
"Universal Description, Discovery, and Integration". Ein Web-Services-Standard für Registries. Initial für ein weltweites Zentralregister für Services (die "UDDI Business Registry" oder UBR) entworfen, dient es nun als eine von vielen Möglichkeiten zur technischen Verwaltung und Vermittlung von Web-Services.

Vertrag (engl.: contract)
Die vollständige Beschreibung einer Service-Schnittstelle zwischen einem spezifischen Anbieter und einem spezifischen Nutzer. Er umfasst neben der technischen Schnittstelle (Signatur) die semantischen Eigenschaften und nichtfunktionale Attribute wie Service-Level-Agreements.
Mitunter wird ein Vertrag auch "wohldefinierte Schnittstelle" genannt.

W3C
World Wide Web Consortium. Ein internationales Konsortium für die Entwicklung von Standards für das Internet (World-Wide-Web), das inzwischen auch einige SOA-Standards wie XML und SOAP verwaltet. Siehe http://www.w3.org/.

Web-Services
Eine Menge von Standards, die eine Möglichkeit darstellen, die Infrastrukturaspekte einer SOA-Landschaft zu implementieren.
Angefangen mit den Kern-Standards XML, HTTP, WSDL, SOAP und UDDI gehören inzwischen über 60 Standards und Profiles dazu, die von unterschiedlichen Organisationen wie W3C, OASIS und WS-I gepflegt werden.

Workflow
Ähnlich wie ein Geschäftsprozess beschreibt ein Workflow Aktivitäten oder Aufgaben zur Lösung eines Problems oder Erreichung eines bestimmten Ziels.
Manchmal wird zwischen Workflows und Geschäftsprozessen insofern unterschieden, als Geschäftsprozesse eher beschreiben, was passieren muss, während Workflows sich eher darum kümmern, wie Aktivitäten oder Aufgaben ausgeführt werden müssen.

WS
Generelle Abkürzung für Web-Services. Dient auch als gemeinsames Präfix von Web-Services-Standards.

WSDL
Web-Services Description Language. Eine XML-basierte Sprache zur Beschreibung der technischen Aspekte von Service-Schnittstellen. Es handelt sich um einen Web-Services-Standard, der aber auch für andere Infrastrukturen verwendet werden kann.

WS-I
Web-Services Interoperability Organization. Eine offene Industrieorganisation, die Profiles zu Web-Services-Standards verabschiedet, um Interoperabilität sicherzustellen. Siehe http://www.ws-i.org/.

XML
eXtensible Markup Language. Eine (prinzipiell) lesbare allgemeine Notation zur Beschreibung und zum Austausch von Daten. Spezifische XML-Formate können durch eine XML-Schema-Definition definiert und dagegen validiert werden.

XML-Schema-Definition (XSD)
Eine Sprache zur Beschreibung der Regelungen, denen ein korrespondierendes XML-Dokument genügen muss, um gültig/valide zu sein. Dazu gehört eine Menge von Basisdatentypen.

Disclaimer: Very often there are conflicting definitions of a SOA term available. In doubt this glossary uses therefore the meaning that fits best in my opinion and correspondes with how the terminology is used inside "SOA in Practice". See [WS-Glossary] for another glossary of the Web Services community.

For updates and feedback please send an email to soa-glossar@josuttis.de (if you click on it to reply, you have to replace "_AT_" by "@"). Note however that I get a lot of emails so that I might not be able to answer immediately. In addition, we have the problem of spamming. For this reason, please use a proper subject, use plain text, and keep the size of the email below 100kB. If you don't get an answer after a certain period of time, you might try it again (with different wording) to make sure the email was not caught by a spam filter.

You are visitor no: