WebServices und serviceorientierte Architektur


Seminararbeit, 2009
52 Seiten

Leseprobe

Inhaltsverzeichnis

1 Einleitung

2 SOA: Service-Oriented Architecture
2.1 Grundlagen
2.1.1 Überblick
2.1.2 Definition
2.1.3 Abgrenzungen
2.2 Konzepte
2.2.1 Service

3 Web Services
3.1 Grundlagen
3.1.1 Entstehung
3.1.2 Definition
3.2 Protokollstapel
3.3 Technologie
3.3.1 Infrastruktur
3.3.2 SOAP: Simple Object Access Protocol
3.3.3 WSDL: Web Services Description Language
3.3.4 UDDI: Universal Description Discovery and Integration
3.4 Implementierungen
3.4.1 Tabellarischer Überblick
3.4.2 Details
3.5 Service Komposition
3.5.1 Überblick
3.5.2 Web Service Kompositions-Modelle

4 Nachwort
4.1 Zusammenfassung
4.2 Zukunft, Trends und Ausblick

Abbildungsverzeichnis

Abbildung 3-1 Web Service Application Protocol Stack

Abbildung 3-2 Publish-Discover-Bind-Model

Abbildung 3-3 Aufbau einer SOAP-Nachricht

Abbildung 3-4 Aufbau eines SOAP-Envelopes

Abbildung 3-5 Aufbau eines SOAP-Headers

Abbildung 3-6 Aufbau eines SOAP-Body

Abbildung 3-7 Struktur eines WSDL-Dokuments

Abbildung 3-8 WSDL-Wurzelelement

Abbildung 3-9 WSDL abstract part

Abbildung 3-10 WSDL concrete part

Abbildung 3-11 UDDI Struktur

Abbildung 3-12 Aufbau eines businessEntity

Abbildung 3-13 Aufbau eines businessService

Abbildung 3-14 Aufbau eines bindingTemplates

Abbildung 3-15 Aufbau eines tModel

Abbildung 3-16 Aufbau einer publisherAssertion

Abbildung 3-17 Beispiel eines BPEL-Dokumentes

Tabellenverzeichnis

Tabelle 2‑1 Web Service Frameworks

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Diese Seminararbeit beschäftigt sich mit den Themen „serviceorientierte Architekturen“ und „Web Services“. Im SOA-Umfeld sind mit Services Software-Komponenten gemeint, die zu Geschäftsprozessen kombiniert werden können. Wir werden in diesem Kapitel auf das Paradigma der SOA eingehen und in Kapitel 3 die Funktionsweise von Web Services beschreiben.

Hier noch mehr Text.

2 SOA: Service-Oriented Architecture

2.1 Grundlagen

2.1.1 Überblick

1996 erwähnte das Marktforschungsunternehmen Gartner erstmalig den Begriff einer serviceorientierten Architektur in der Research Note SPA-401-068 „Service- Oriented Architecture Scenario“ (23). Der zugrunde liegende Gedanke einer service ortientierten Architektur liegt jedoch nicht in der Technik, wie man vielleicht zu Beginn vermuten mag, sondern vielmehr steht der Geschäftsprozess als Service im Vordergrund: „ The central focus of Service Oriented Architecture is the task or business function getting something done. “ (24). Es geht bei dem Software Design Ansatz also darum, die Dienste von Unternehmen und seinen Mitarbeitern zu organisieren, zu strukturieren und effizient nutzbar zu machen.

In einer SOA können Geschäftsprozesse durch die Zusammenstellung von Services abgebildet werden, wobei die Services (vgl. 2.2.1) mit Hilfe einer standardisierten Darstellungsform beschrieben werden. (24): „The specifics of the interface SHOULD be syntactically represented in a standard referenceable format. These prescribe what information needs to be provided to the service in order to access its capabilities and interpret responses.“.

Die Vorteile werden nach (24) deutlich: „The main drivers for SOA-based architectures are to facilitate the manageable growth of large-scale enterprise systems, to facilitate Internet-scale provisioning and use of services and to reduce costs in organization to organization cooperation. It provides a simple scalable paradigm for organizing large networks of systems that require interoperability to realize the value inherent in the individual components. (...) An architect using SOA principles is better equipped, therefore, to develop systems that are scalable, evolvable and manageable. It should be easier to decide how to integrate functionality across ownership boundaries. (...) SOA can also provide a solid foundation for business agility and adaptability.”. Setzen wir die im Zitat gebrachten Anmerkungen nun in den Kontext einer Organisation, die die Konzepte der SOA umgesetzt hat, werden die Vorzüge einer SOA deutlich:

Die Verwaltung und Wartung von großen Software-Anwendungen wird vereinfacht.

Es können Kosten eingespart werden, indem externe Services integriert werden oder bereits existierende Services in anderen Services wiederverwendet werden.

Es bietet eine einfache Skalierbarkeit zur Organisation großer Netzwerke von Systemen. In diesem Falle wird Interoperabilität gefordert, da die Ergebnisse einer Berechnung z.T. von individuellen Komponenten abhängen.

Einfachere Abbildung von neuen Geschäftsmodellen.

Schnelle Adaptierbarkeit von Anwendungen.

Wir wollen in diesem Kapitel das Referenzmodell der serviceorientierten Architektur näher beschreiben. Wir beginnen zuerst damit, das Referenzmodell gegen konkrete Implementierungen wie die der objektorientierten Architektur (2.1.3.1) und Web Services (2.1.3.2) abzugrenzen. Dann beschreiben wir die zentralen Konzepte der SOA: Der Begriff Service, der sich auch in der offiziellen Bezeichnung des Paradigmas wiederfindet, soll klar definiert werden (2.2.1). Hiermit einher gehen die weiteren zum Begriff Service stehenden Konzepte wie z.B. Beschreibung (2.2.1.1), Schnittstelle (2.2.1.2) und Funktionalität (2.2.1.4).

2.1.2 Definition

Laut (24) ist „Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under control of different ownership domains.“.

2.1.3 Abgrenzungen

Bei dem Modell der serviceorientierten Architektur handelt es sich um ein abstraktes Referenzmodell (24). Es wurde von OASIS im Dokument „Reference Model for Service Oriented Architecture 1.0“ (1996) beschrieben, um Zusammenhänge und Beziehungen zwischen den Merkmalen (wie z.B. Interaktion, Sichtbarkeit usw.) innerhalb dieses Paradigmas offen zu legen. Ein Referenzmodell, wie das der SOA, ist nicht direkt an technische Standards oder Implementierungsdetails gebunden, es soll vielmehr ein vertiefendes Verständnis für das Paradigma vermittelt werden und über die Bausteine informieren, aus denen die Architektur besteht. Es ist nicht möglich, SOA als ausführbare Applikation unmittelbar einzusetzen, es gibt jedoch programmatische Umsetzungen des Architektur Paradigmas, die seit der Erwähnung Gartners im Jahre 1996 entwickelt wurden und sich im Einsatz befinden.

Wir wollen an dieser Stelle kurz anreißen, wie sich die Umsetzungen von dem Modell abgrenzen. Wir beginnen zunächst, dies für Objektorientierte Architekturen (2.1.3.1) zu erklären und folgen dann mit der Abgrenzung zu unserem Hauptthema, der Web Services (2.1.3.2).

2.1.3.1 Objektorientierte Architekturen (OOA)

Die Granularität bei einer serviceorientierten Architektur ist größer als bei objektorientierten. Der Ansatz von SOA ist es, eine Aufgabe oder einen Business Prozess zu erledigen, wohingegen der objektorientierte Ansatz tiefer ansetzt und Operationen mit Daten verknüpft: (24) „Unlike Object Oriented Programming paradigms, where the focus is on packaging data with operations, the central focus of Service Oriented Architecture is the task or business function – getting something done.“

Bei der OOA sind die Methoden „das Eigentum“ eines Objektes, die Methoden werden zu einem gegebenen Datenobjekt erklärt. Bei Services steht nicht die Existenz von Methoden oder der Zugriff darauf im Vordergrund, der Blick ist auf den durchzuführenden Prozess fixiert, der von einem Service angeboten wird.

Um ein Objekt in OOA verwenden zu können, muss eine Instanz aus einer entsprechenden Klasse erzeugt werden, wohingegen bei der Interaktion mit einem Service dieser einfach existiert.

Um die Unterschiede zwischen den zwei Modellen festzustellen, begründet dies (24): „SOA provides a more viable basis for large scale systems because it is a better fit to the way human activity itself is managed – by delegation.“

Delegation erlaubt es, die Entscheidungskompetenzen ganz oder in Teilen an untergeordnete Stellen weiterzugeben. Das Prinzip der SOA folgt diesem Weg und überträgt die Arbeiten eines durchzuführenden Prozesses an darunterliegende, spezialisierte Services. Diese Services führen die Aufgaben vollständig durch oder erhalten eine Teilaufgabe, die sie dann lösen. Durch diesen Ansatz können Probleme in größeren Klassen zusammengefasst werden.

2.1.3.2 Web Services

(23) beschreibt die Beziehung zwischen SOA und Web Services als „zwei komplementäre Talente“: „Simply speaking, any software that uses the standards Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP) or Universal Description, Discovery and Integration (UDDI) is a Web service.“

Die Implementierung einer standardisierten Schnittstellenbeschreibung durch WSDL verbindet das Modell und die konkrete Umsetzung, sie eignen sich also prinzipiell für den Aufbau einer SOA: (23) „Web services' WSDL is an SOA-suitable interface definition standard: this is where Web services and SOA fundamentally connect.“. (23) „Web services are about technology specifications, whereas SOA is a software design principle.“. In der offiziellen Beschreibung des Referenzmodells wird gesagt, dass (24) „Web Service are too solution specific to be part of a reference model.“

Ein weiterer Aspekt der SOA ist die Möglichkeit der Wiederauffindbarkeit (vgl. 3.3.4) von Services, was in der konkreten Umsetzung der Web Services durch einen Verzeichnisdienst mit dem Namen Universal Description, Discovery and Integration (UDDI) ermöglicht wird.

In Web Services orientiert sich die Kreation neuer Anwendungen an den entsprechenden Geschäftsprozessen. Durch die Komposition eines neuen Web Services, also der Verknüpfung verschiedener Web Services zu einer neuen in sich geschlossenen Anwendung, können Teilprobleme in einer größeren Klasse zu einem neuen Prozess zusammengefasst werden. Die Teilaufgaben werden dann, wie im SOA Paradigma beschrieben, an die einzelnen spezialisierten Web Services deligiert.

2.2 Konzepte

2.2.1 Service

In (25) wird Service definiert als "the action of helping or doing work for someone".

Nach (24) sind es auch die folgenden Eigenschaften, die mit dem Begriff in Verbindung gebracht werden:

Die Fähigkeit für jemand anders eine Arbeit durchzuführen

Die Spezifikation der Arbeit für andere anzubieten

Das Angebot für andere eine Arbeit durchzuführen

In (24) heißt es: „In SOA, services are the mechanism by which needs and capabilities are brought together.“, etwas genauer wird Service etwas später beschrieben als „A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service
description.“.

Ein Service wird von einem Service Anbieter (Service Provider) im Regelfall für einen Service Konsumenten (Service Consumer) angeboten. Die Implementierung bleibt typischerweise vor dem Service Konsumenten verborgen, bis auf die Informationen und das Verhalten, die über die Service Schnittstelle (Service Interface) angeboten werden. Die Konsequenz eines Aufrufs (invocation) ist die Realisierung eines oder mehrerer „Real World Effects“, die durch die gesendete Information als Antwort zur Anfrage oder einer Änderung bereits bestehender Informationen charakterisiert wird. (24, Zeilen 303-317)

2.2.1.1 Service-Beschreibung (service description)

Die Beschreibung beinhaltet die Informationen, die benötigt werden, um einen Service zu bedienen. Es gibt hierbei keine Standards, wie eine „richtige“ Beschreibung zu erfolgen hat, denn dies hängt von verschiedenen Faktoren ab wie z.B. dem eingebundenen Kontext und den Akteuren, die mit dem Service arbeiten.

Die Beschreibung soll die Interaktion und die Funktionalität des Service erklären, so können Konsumenten bei einer sehr detaillierten Beschreibung abwägen, ob der Service ihren Anforderungen entspricht und ggf. nach alternativen Angeboten suchen.

2.2.1.2 Service-Schnittstelle (service interface)

Mit Hilfe der Service-Schnittstelle wird festgelegt, wie die Interaktion mit dem Service erfolgen kann. Die Schnittstelle beinhaltet eine Spezifikation über eingesetzte Protokolle und Kommandos. Zusätzlich gibt die Spezifikation Aufschluss über Informationen, die ausgetauscht werden können und mögliche „Real World Effekte“, die durch bestimmte Aktionen ausgelöst werden.

2.2.1.3 Service-Verfügbarkeit (service reachability)

Verfügbarkeit ergibt sich laut (24) aus einer Beziehung zwschen Service Anbieter und Service Konsument. Hierzu gehört eine hinreichende Service Beschreibung durch den Anbieter, in der beschrieben wird, wie der Service erfolgreich ausgeführt werden kann. Hierzu können Metaangaben über Standort, unterstützte und benötigte Protokolle sinnvoll sein. Zusätzlich sollten dynamische Informationen des Service Anbieters die Verfügbarkeit anzeigen (z.B. nicht verfügbar durch Wartung o.ä.). Wenn eine solche Kommunikation nicht existieren würde, würde der Konsument lediglich feststellen, das der Dienst nicht erreichbar ist. Laut (24) ist der Service dann nicht sichtbar für den Konsumenten.

Die Verfügbarkeit ist eine notwendige Vorbedingung für die Interaktion, sowohl Konsument als auch Anbieter müssen in der Lage sein, miteinander zu kommunizieren.

2.2.1.4 Service-Funktionalität (service functionality)

In der Service-Funktionalität wird wie in der Service-Beschreibung eine für den Menschen lesbare Beschreibung angeboten. Mögliche Bestandteile sind z.B. technische Voraussetzungen für den Einsatz des Services. Darüber hinaus können aber auch Limitierungen oder Anforderungen für die Ausführung definiert werden (so kann ein Service für den Bezug von Bargeld durch die in der Funktionalität definierte Festlegung einen Bezug von Geld verhindern, wenn der Konsument z.B. mehr Geld abheben möchte, als für einen Tag zulässig ist.)

2.2.1.5 Service-Richtlinien (service policy)

In den Richtlinien werden Angaben zu den Bereichen Sicherheit, Privatsphäre, Servicequalität, Öffnungszeiten usw. gemacht. Diese Richtlinien sollte vom Service Anbieter geschrieben werden, der den Service veröffentlichen. Eine mögliche Richtlinie ist z.B. die Erklärung, dass alle Nachrichten verschlüsselt werden.

3 Web Services

3.1 Grundlagen

3.1.1 Entstehung

Ende des Jahres 2000 tauchte ein neuer Modebegriff in der Softwareindustrie und der entsprechenden Presse auf, der (wie bei Corba oder anderen Technologien) die Lösung aller Integrationsprobleme versprach, der Begriff der „Web Services“.

3.1.2 Definition

Der Begriff Web Services fällt heutzutage immer häufiger auf Webseiten von Dienstanbietern oder auch in Produktpräsentationen, ohne das dem interessierten Leser immer direkt klar ist, was sich im Detail dahinter verbirgt. So existieren Definitionen wie „Web Services sind Softwarebausteine, die Programme, die auf unterschiedlichen Netzwerkrechnern laufen, über das Internet zu einer Anwendung miteinander verknüpfen.“ (26). Derartige, allgemein gehaltene Beschreibungen lassen ausreichenden Interpretationsspielraum, dass die Implementierung beliebig sein kann und so z.B. auch ein CGI-Script oder ein Online-Formular als Web Service Anwendung findet. In dieser Seminararbeit verwenden wir die Definition des W3C Konsortiums:

„A Web Service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.“ (27)

3.2 Protokollstapel

Die folgende Grafik zeigt eine mögliche Darstellungsweise des Protokollstacks von Web Services. Auf der Grafik sind sieben Ebenen zu sehen, die von unten nach oben gelesen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-1 Web Service Application Protocol Stack

Quelle: (28)

Diese sieben Ebenen werden nun in drei unterschiedliche Bereiche untergliedert (29), die wir kurz erwähnen wollen. Eine technische Spezifikation der Standards SOAP, WSDL und UDDI erfolgt in diesem Kapitel.

3.2.1.1 Bereich 1: Die Standards

Dieser Bereich besteht aus den Ebenen 1 und 2, den Netzwerk Transport Protokollen und der Meta Sprache XML. Beide Layer beinhalten wohldefinierte und akzeptierte Standards und Protokolle, die übergreifend im Internet genutzt werden (wie z.B. http oder XML).

3.2.1.2 Bereich 2: Entwickelnde Standards

In diesem Bereich werden die Ebenen 3, 4 und 5 angesprochen und beschreiben somit die in verschiedenen Literatur-Quellen als Standards für die Implementierung von Web Services definierte Standards, Protokolle und Technologien SOAP, WSDL und UDDI. Das Zusammenspiel wird im

Publish-Discover-Bind-Model (3.3.1.1) näher beschrieben.

3.2.1.3 Bereich 3: Neu entstehende Standards

Das obere Level beschreibt vorgeschlagene Standards großer Firmen wie Microsoft oder IBM. Die hier beschriebenen neuen Konzepte sind z.T. weniger gut dokumentiert.

3.3 Technologie

Viele heute im Einsatz befindliche Web Service-Architekturen zeichnen sich durch die drei Merkmale Anbieter (service provider), Konsument (service requester) und Verzeichnis (service registry) aus. Mit diesen Informationen lassen sich bereits die minimalen Anforderungen ableiten, die für die Implementierung von Web Services in einer Infrastruktur erforderlich sind: einen Weg zu kommunizieren (SOAP), eine Möglichkeit, Services zu beschreiben (WSDL) und diese im Anschluss bekannt zu machen (UDDI). Folgende Standards bilden so das Herzstück der Web Service-Architektur (30):

Simple Object Access Protocol (SOAP) ist ein Kommunikationsprotokoll für Web Services, dessen Hauptaufgabe darin liegt, einen standardisierten Weg für die Kodierung verschiedener Protokolle und Interaktionen mit Hilfe von XML Dokumenten anzubieten. Diese können dann unkompliziert über das Internet ausgetauscht werden.

Web Service Description Language (WSDL) dient der Spezifikation des Web Services mit seinen öffentlich zur Verfügung stehenden Methoden, Daten und Datentypen, Schnittstellenbeschreibungen und angebotenen Kommunikationsprotokollen im XML-Format.

Universal Description Discovery and Integration (UDDI) wird von Anbietern eingesetzt, um Services öffentlich in einem Verzeichnis anzumelden und so zu veröffentlichen. Konsumenten nutzen diese Schnittstelle für die Suche nach konkret benötigten Services.

In diesem Kapitel wollen wir die Bausteine im Detail spezifizieren und die Zusammenhänge der Elemente beschreiben. Hierfür gehen wir im ersten Schritt auf die minimale Infrastruktur (3.3.1) für Web Services ein und diskutieren anschließend das Netwerkprotokoll SOAP (3.3.2) zur Übertragung von Nachrichten. Mit der Spezifikation der Beschreibungssprache WSDL (3.3.3) und dem Verzeichnisdienst UDDI (3.3.4) schließen wir das Kapitel ab.

3.3.1 Infrastruktur

Die Infrastruktur von Web Services lässt sich wie folgt beschreiben. Im ersten Schritt ist es notwendig, eine geläufige Syntax anzuwenden, die für alle Spezifikationen Anwendung finden kann. Mit der Auszeichnungssprache XML (Extensible Markup Language) werden diese Anforderungen erfüllt, denn damit ist die Darstellung hierarchisch strukturierter Datensätze in Form von Textdaten möglich. Außerdem kann XML plattformübergreifend eingesetzt werden.

Im nächsten Schritt sind Mechanismen erforderlich, damit Remote-Anwendungen untereinander interagieren können. Hierunter fallen ein geläufiges Datenformat für die auszutauschenden Nachrichten, eine Vereinbarung über erlaubte Interaktionen, spezifiziert über ein Protokoll und Definitionen für den Nachrichtenaustausch über verschiedene Transportprotokolle. Für diesen Einsatzzweck wurde das Netzwerkprotokoll SOAP entwickelt, um Dokumente (im Format XML) von einer Quelle zu einem Ziel zu transportieren. Es nutzt das XML-Format zur Repräsentation der Daten und erlaubt die Durchführung von entfernten Prozeduraufrufen. Die Verbindung kann über die Protokolle TCP/IP (Transission Control Protocol, Internet Protocol), HTTP oder SMTP (Simple Mail Transport Protocol) erfolgen. Ein Web Service sendet oder empfängt SOAP-Nachrichten und führt abhängig von der Spezifikation eine Folgeaktion aus (z.B. sendet ein Konsument eine SOAP-Nachricht an den Anbieter und wünscht Auskunft über die Verfügbarkeit eines Produktes. Diese Anfrage wird vom Web Service verarbeitet und die Antwort mit Hilfe einer SOAP-Nachricht an den Empfänger quittiert).

Damit ein Web Service auch genutzt werden kann, ist eine Beschreibung der Schnittstelle (interface) notwendig, nur so können später Aufrufe ausgelöst werden. Mit Hilfe der Metasprache WSDL werden angebotene Funktionen mit möglichen Parameterbelegungen, Daten, Datentypen und Austauschprotokolle eines Web Services beschrieben, die Syntax ist hierbei XML.

Nachdem die Web Services definiert sind und aufgerufen werden können, fehlt in der Infrastruktur noch ein Verzeichnisdienst. Über diesen können interessierte Anwender oder auch Software-Anwendungen (für die dynamische Erkennung) nach Web Services suchen, die sie benötigen, und Informationen dazu anzeigen lassen. Um einen übergreifenden und global skalierbaren Zugriff auf Web Services zu ermöglichen, bietet sich die Standardisierung des Directories an, was mit Hilfe des UDDI Projektes und den damit zur Verfügung gestellten Schnittstellen ermöglicht wird. (30)

[...]

Ende der Leseprobe aus 52 Seiten

Details

Titel
WebServices und serviceorientierte Architektur
Hochschule
FernUniversität Hagen
Autoren
Jahr
2009
Seiten
52
Katalognummer
V206818
ISBN (eBook)
9783656338482
ISBN (Buch)
9783656339595
Dateigröße
647 KB
Sprache
Deutsch
Anmerkungen
Diese Seminararbeit beschäftigt sich mit den Themen „serviceorientierte Architekturen“ und „Web Services“.
Schlagworte
Web Service, serviceorientierte Architektur, SOA, WSDL, SOAP, UDDI
Arbeit zitieren
Timo Müller (Autor)Jobst Planz (Autor), 2009, WebServices und serviceorientierte Architektur, München, GRIN Verlag, https://www.grin.com/document/206818

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: WebServices und serviceorientierte Architektur


Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden