Serviceorientierte Architekturen - Benutzer-Homepage
Werbung
Serviceorientierte Architekturen
Serviceorientierte Architekturen
Masterprogramm Informatik
WS 2012/13
28. Januar 2013
1 / 259
Serviceorientierte Architekturen
Inhaltsverzeichnis
1
2
3
4
5
6
7
8
9
10
Programm der Lehrveranstaltung
Literatur
Motivation
SOA - Begriffsdefinition
Lose Kopplung
Enterprise Service Bus
Service-Kategorien und Architekturebenen
Webservices
REST
SOAP-basierte Webservices
WSDL
SOAP
WS-* Erweiterungen
Sicherheit von Webservices
Sicherheitsanforderungen
Zertifikate und PKI-Systeme
2 / 259
Serviceorientierte Architekturen
Programm der Lehrveranstaltung
Themen
Motivation
SOA - Begriffsdefinition
Services
„Enterprise Service Bus“
Service-Kategorien und Architekturebenen
Geschäftsprozessmodellierung
Muster für Nachrichtenaustausch
Sicherheit
Webservices
Modellgetriebene Service-Entwicklung
Java-WS
OSGI
3 / 259
Serviceorientierte Architekturen
Literatur
Literatur
Thomas Erl: Service-Oriented Architecture: Concepts, Technology,
and Design (2005)
Nicolai Josuttis: SOA in der Praxis: System-Design für verteilte
Geschäftsprozesse (2009)
Thomas Erl: SOA - Studentenausgabe: Entwurfsprinzipien für
serviceorientierte Architektur (2010)
Ingo Melzer et al.: Service-orientierte Architekturen mit Web
Services (2007)
Mark D. Hansen: SOA Using Java EE5 Web Services, 2007
4 / 259
Serviceorientierte Architekturen
Motivation
Darwinismus in der globalisierten Wirtschaft
„Weder die stärksten noch die intelligentesten Arten überleben, sondern
nur die, die am schnellsten auf Veränderungen reagieren. „
Ziel der Unternehmensleitung
Flexibilität des Unternehmens
Rolle der IT
Flexibilität der IT ist der wichtigste Faktor für flexible Unternehmen.
5 / 259
Serviceorientierte Architekturen
Motivation
Begriffe
SOA
Service
EAI
ESB
Webservice
6 / 259
Serviceorientierte Architekturen
Motivation
Brainstorming
Services: Beispiele
Legacy-Applikationen
SOA-Infrastruktur
Perfektionismus
SOA-Richtlinien
Redundanz von Daten
Geschäftsprozesse
Komponenten
Heterogenität
Interoperabilität
Eigentümer von Software
Kommunikationsbus
Teams und Rollen
Webservices
Dezentralismus
SOA-Governance
Paradigma
Skalierbarkeit
Lose Kopplung
Message Exchange Pattern
7 / 259
Serviceorientierte Architekturen
Motivation
SOA-Motivation
Herausforderungen
Integration heterogener Anwendungen (EAI)
Flexibilität: Einfache Anpassbarkeit der Geschäftsprozesse
Unternehmenübergreifende Anwendungen (B2B-Integration)
Nutzung externer Anwendungen und Dienstleistungen
(Application Service Provider, „Software as a Service“, „Cloud
Computing“)
8 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
SOA - Begriffsdefinition
Kurzdefinition OASIS:
SOA ist ein Paradigma für die Strukturierung und Nutzung
verteilter Funktionalität, die von unterschiedlichen Besitzern
verantwortet wird.
Ihre Aufgabe: Lesen Sie die Begriffsdefinition im
Informatik-Fachlexikon der GI (Gesellschaft für Informatik)
(siehe http://www.gi-ev.de/service)
9 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
SOA geht Informatiker und Betriebswirte an!
Mit SOA meint man oft: Serviceorientierte IT
„Architektur“ (SOA im engeren Sinne) ist nur Teilaspekt
Architekturmuster SOA: abstraktes Modell für Unternehmensund IT-Architektur
Unternehmensarchitektur: Aufbau des Unternehmens,
Definition der Geschäftsprozesse
SOA als IT-Architektur: Komponentenarchitektur für verteilte
Systeme, Kompositionsprinzip, Services als Komponenten
10 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
Merkmale und Unterschiede zu anderen
Komponentenmodellen?
besondere Unterstützung für die Integration vorhander
Anwendungen (EAI)
besondere Berücksichtigung dezentraler Verabtwortung für die
IT (verschiedene Eigentümer)
prozessorientiert („Geschäftsprozess“)
(Woran ist IT ansonsten orientiert?)
Basis: offene, plattformübergreifende Basistechnologie
(Webservices, . . . )
11 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
Services
Services sind die Komponenten in einer SOA
Rollen: Dienstanbieter (Provider)/ Dienstnutzer (Consumer)
Typische Kommunikationsparadigmen:
asynchron
dokumentenbasiert
Kommunikationspfade: komplex durch Zwischendienste
Beispiele?
12 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
EAI - Enterprise Application Integration
prozessorientierte Integration von Anwendungssystemen in
heterogenen IT-Anwendungsarchitekturen
Unternehmensanwendungen
Betrieblich: ERP, PPS, CRM, HR, Supply-Chain . . .
Technisch: CAD, CAM, CAFM, . . .
Groupware / Kommunikation / Bürosoftware
Sonstige
IT-Organisation: Säulenarchitektur (Silo-Architektur)
Problemfall: Datenaustausch zwischen den Applikationen über
Punkt-zu-Punkt-Anbindung. Flexibilität bei Änderung der
Geschäftsprozesse?
13 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
Detailliertere Begriffsdefinition
SOA ist ein IT-Paradigma, das eine
geschäftsprozessorientierte, anwendungsübergreifende Sicht
auf die IT-Landschaft eines Unternehmens favorisiert.
SOA modelliert Prozesse als Komposition von Diensten.
SOA unterstützt in besonderer Weise die Integration
heterogener, dezentral verwalteter Anwendungen auf der Basis
plattformunabhängiger Standards.
14 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
SOA- und Dienstmerkmale
Ein Dienst ist autonom, d.h. hat eine klar umrissene fachliche
Funktion und ist eigenständig nutzbar
Ein Dienst hat eine formal definierte öffentliche Schnittstelle
und verbirgt seine Implementierung
Ein Dienst ist plattformunabhängig nutzbar
Dienste sind lose gekoppelt
Eine SOA ist grobgranular („wenige“ Dienste)
15 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
Wer sind die „Big Players“ bei SOA?
Produkte
Kommerzielle Hersteller: IBM („Websphere“), BEA/Oracle,
Microsoft („BizTalk“), . . .
Deutschland: SAP (Netweaver), Software AG (Webmethods)
Open-Source-Gemeinschaft: Entwicklung/Weiterentwicklung von
SOA-Werkzeugen (ESBs, BPEL-Tools)
Standards
W3C, OASIS, WS-I
UN/CEFACT (UN Centre for Trade Facilitation and E-Business)
ebXML
OMG: CORBA, (auch UML, MDA ...)
16 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
Verantwortung für Standards und Spezifikationen
W3C – World Wide Web Consortium:
Definiert Standards für WWW-Technologie als SOA-Basis: WWW,
XML, XML Schema, XSLT, SOAP, WSDL usw.
SOA-spezifisch: WS-CDL = Web-Services Choreography Description
Language
OASIS – Organization for the Advantage of Structured
Information
Standards: ebXML, WS-BPEL, WS-Security, UDDI, SAML (Security
Assertions Markup Language), XACML (Extensible Access Control
Markup Language)
17 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
Verantwortung für Standards und Spezifikationen II
WSI – Web Services Interoperability Organization
„Basic Profile“: Empfehlung für eine Zusammenstellung der
WS-Technologien und ihrer Versionen zugunsten einer
unternehmenübergreifenden Interoperabilität
Anwendungsmuster
Beispiel-Implementierungen
18 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
Ergänzung: Begriffe aus dem SOA-Umfeld
EAI, ERP, HR, CRM, Legacysystem, Silo
horizontale/vertikale Architektur
ESB (Business Bus, Integrationsplattform) , „Hub and
Spoke“-Architektur
Orchestrierung, Choreographie
SOA-“Enabling“
19 / 259
Serviceorientierte Architekturen
SOA - Begriffsdefinition
SOA und Schichtenmodelle für verteile Systeme
Komplexität erfordert separate Modellierung mehrerer
Architektur-Aspekte
Klassifikation von Diensten und Bezug zu Geschäftsprozessen
und Applikationen
Modell für den Aufbau und Austausch von Nachrichten
Kooperationsmodell: Rollen, Dienste, Nachrichten
Abstraktionsebenen, Schichtenarchitektur
Ist SOA Alternative zu Schichtenarchitektur?
20 / 259
Serviceorientierte Architekturen
Lose Kopplung
Lose Kopplung
Möglichst geringe Abhängigkeiten zwischen Komponenten
Wozu?
Weniger Programmieraufwand bei Änderungen
Von der Änderung einer Komponente sind andere Komponenten
weniger stark betroffen
Fehlertoleranz
Ausfall einer Komponente wirkt sich nicht so drastisch auf die
anderen Komponenten aus.
Lose Kopplung hat viele Aspekte
Lose Kopplung gibt es nicht umsonst!
21 / 259
Serviceorientierte Architekturen
Lose Kopplung
Aspekte loser Kopplung
enge Kopplung
lose Kopplung
Phys. Verbindung
Punkt-zu-Punkt
über Vermittler
Kommunikationsstil
asynchron
synchron
Datenmodell
komplexe gemeinsame Typen
einfache gemeinsame Typen
Typsystem
streng
schwach
Bindung
statisch
dynamisch
Plattformspezifika
stark
schwach
Interaktionsmuster
Navigation durch komplexe
Objektbäume
datenzentrierte autonome
Nachrichten
Transaktionssicherheit
2-Phasen-Commit
Kompensation
Prozess-Steuerung
zentral
dezentral
Deployment
gleichzeitig
unabhängig
Versionierung
explizite Upgrades
implizite Upgrades
22 / 259
Serviceorientierte Architekturen
Lose Kopplung
Verbindung über Vermittler
Mehr Flexibilität gegenüber Punkt-zu-Punkt-Verbindungen mit
festen Endpunkt-Adressen
Formen der Vermittlung
Vermittler teilt Dienstnutzer vor Kontaktaufnahme Anbieteradresse
mit („Broker“, „Nameservice“, „Portmapper“)
Kommunikation danach Punkt-zu-Punkt
Dienstnutzer verwendet logische Adresse, Endpunkt wird während
des Nachrichtentransports dynamisch bestimmt
Was sind „Endpunktadressen“?
Woher kennt der Vermittler die Endpunktadressen?
Vergleichen Sie die beiden Ansätze: Kosten/Nutzen?
23 / 259
Serviceorientierte Architekturen
Lose Kopplung
Asynchrone Kommunikation
Prinzip entspricht dem Einsatz von Anrufbeantwortern beim
Telefonieren (oder SMS/E-Mail statt Anruf)
Vorteil: Zeitliche Entkopplung
Dienstanbieter zeitlich flexibler bei der Bearbeitung
System robuster bei vorübergehender Nichterreichbarkeit
Nachteile
Mechanismus zur Nachrichtenpufferung nötig (MOM-System
„Message Oriented Middleware“)
Programmierlogik beim Dienstenutzer komplexer:
Synchronisation Antwortdaten, Zustand beim Absenden?, . . .
24 / 259
Serviceorientierte Architekturen
Lose Kopplung
Schwache Typprüfung
Regel: Je früher ein Fehler entdeckt wird, desto besser! (Warum?)
Aber: Typprüfung kostet Zeit
Schnittstellenänderungen in sehr großen Systemen
Schnittstellenänderungen betreffen
Anbieter und Nutzer (immer)
ESB (abhängig vom ESB-Typ)
Konsequenz: Falls ESB von allen Änderungen betroffen ist, ständiger
erheblicher Prüfungsaufwand! (konkret?)
Was wäre wenn ...? Strenge Typprüfung im Internet?
25 / 259
Serviceorientierte Architekturen
Lose Kopplung
Transaktionssicherheit und Kompensation
Reisebuchung: „Flug+Hotel+Mietwagen oder gar nichts!“
Klassisch: 2PC („Two Phase Commit“-Protokoll)
Phase 1: Koordinator veranlasst Änderungen in mehreren Backends
Phase 2: Falls alle Backends die Änderungen bestätigen, schließt
Koordinator die Transaktion ab, sonst Rollback
Langlaufende Transaktionen? Asynchrone Kommunikation?
SOA: Kompensation statt 2PC
Prinzip: Geschäftsprozess läuft nicht nach Plan ⇒ „Plan B“
(Kompensationsaktionen)
erfordert fachliche Modellierung
Reisebuchung: Stornierung, Umbuchungen
26 / 259
Serviceorientierte Architekturen
Enterprise Service Bus
Enterprise Service Bus
Wikipedia
Ein Enterprise Service Bus (ESB) bezeichnet in der
Informationstechnik(IT) ein Architektur-Konzept für verteilte
Computersysteme, welches durch das analoge Design einer
Bus-Architektur moderner Computer motiviert ist und die am weitesten
verbreitete Variante einer Serviceorientierten Architektur darstellt.
Ein ESB stellt einen Unterbau zur Verfügung, der die Zusammenarbeit
von Softwarekomponenten (Services) ermöglicht, die auf verschiedenen
Rechnern und unterschiedlichen Betriebssystemen nebenläufig ausgeführt
werden und der die Kommunikation über einen gemeinsam genutzten
Kommunikationsbus einer Vielzahl von Punkt-Zu-Punkt-Verbindungen
zwischen Anbietern und Nutzern von Softwarediensten vorzieht.
27 / 259
Serviceorientierte Architekturen
Enterprise Service Bus
Aufgaben eines ESB
Interoperabilität
zwischen Dienstenutzer und
Anbieter
Zentrale Aufgabe:
Aufrufbarkeit der Dienste
Konnektivität
Datentransformation
Intelligentes Routing
Sicherheitsmechanismen
Zuverlässigkeitsmechanismen
Dienste-Management
Überwachung, Protokoll,
Debugging
28 / 259
Serviceorientierte Architekturen
Enterprise Service Bus
Verteilter ESB
29 / 259
Serviceorientierte Architekturen
Enterprise Service Bus
Zentrale Aufgabe des ESB: Interoperabilität
Problem: Heterogenität
Plattformen, Protokolle, Middleware, Datenformate
Kommunikationsmuster: Synchrone Aufrufe, asynchrone
Nachrichten, Ereignis-getriebene Kommunikation
Übliche Lösung
Verbindliches einheitliches Zwischenformat für alle Komponenten
Beispiel: Webservices
SOAP als einheitliches Transportprotokoll
SOAP-Anbindung für alle beteiligten
Plattformen/Programmiersprachen
30 / 259
Serviceorientierte Architekturen
Enterprise Service Bus
Verteilter heterogener ESB
31 / 259
Serviceorientierte Architekturen
Enterprise Service Bus
ESB mit Punkt-Zu-Punkt-Verbindungen
32 / 259
Serviceorientierte Architekturen
Enterprise Service Bus
ESB vermittelt Verbindungen
33 / 259
Serviceorientierte Architekturen
Enterprise Service Bus
ESB vermittelt Verbindungen dynamisch
34 / 259
Serviceorientierte Architekturen
Enterprise Service Bus
ESB mit Interceptoren auf Nutzer- und Anbieterseite
35 / 259
Serviceorientierte Architekturen
Service-Kategorien und Architekturebenen
Service-Klassifikation nach Josuttis
Fundamentale SOA
Basis-Services
Basis-Datenservices
Basis-Logik-Services
Föderierte SOA
zusätzlich: Composed-Services
Basis-Services
Composed-Services
Prozess-Services
36 / 259
Serviceorientierte Architekturen
Service-Kategorien und Architekturebenen
Fundamentale SOA (nach Josuttis)
37 / 259
Serviceorientierte Architekturen
Webservices
REST
Die einfachere Alternative: RESTful „Webservices“
REST-Merkmale
REST = Representational State Transfer
Vorbild und technische Basis: WWW
Services bieten Zugriffe auf Web-Ressourcen über URIs
Operationen generisch: HTTP GET, POST, PUT, DELETE
Dienstnutzer ruft Ressorce mit GET ab
erhält Links auf weitere Ressourcen
Beispiel
Webservices von Amazon (http://aws.amazon.com), z.B. der
Bezahldienst FPS, unterstützen REST und SOAP
Mehr:
http://www.ibm.com/developerworks/webservices/library/ws-rest1
38 / 259
Serviceorientierte Architekturen
Webservices
REST
Kriterien für REST-Verwendung
Webservice ist zustandslos
CRUD-Operationen genügen (Create: POST, Read: GET,
Update: PUT, Delete: DELETE)
HTTP-Caching soll zur Effizienzsteigerung verwendet werden
Voraussetzungen: keine dynamisch generierten Daten, meist
nur GET-Aufrufe im Cache
Formaler Kontrakt zur Dienstnutzung nicht nötig
Anbieter spezifizieren Interfaces durch Toolkits für best.
Programmiersprachen
Einfache Integration in Websites wichtig
Webbrowser als Dienstenutzer (Ajax-Zugriff, DWR (Direct
Web Remoting))
39 / 259
Serviceorientierte Architekturen
Webservices
REST
REST-Beispiel: Purchase Order
Neuer Auftrag: Erzeugen mit HTTP POST
POST /restfulwebservice-war/poservice/ HTTP/1.0
Accept: */*
Connection: close
Content-Type: text/xml
Content-Length: 618
Pragma: no-cache
<tns:PurchaseOrderDocument xmlns:tns="urn:PurchaseOrderDocument">
<billTo>
<street>1 Main Street</street>
<city>Beverly Hills</city>
<state>CA</state>
<zipCode>90210</zipCode>
</billTo>
<createDate>2004-03-27T12:21:02.055-05:00</createDate>
<poID>ABC-CO-19282</poID>
<items>
<itemname>Copier Paper</itemname>
<price>10</price>
<quantity>2</quantity>
</items>
40 / 259
Serviceorientierte Architekturen
Webservices
REST
<items>
<itemname>Toner</itemname>
<price>920</price>
<quantity>1</quantity>
</items>
<shipTo>
<street>1 Main Street</street>
<city>Beverly Hills</city>
<state>CA</state>
<zipCode>90210</zipCode>
</shipTo>
</tns:PurchaseOrderDocument>
HTTP-Antwort
HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5
Content-Type: text/xml
Date: Fri, 21 Jul 2006 17:07:15 GMT
Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<ns2:Status xmlns:ns2="urn:Status" xmlns:ns3="urn:PurchaseOrderDocument"
xmlns:ns4="urn:POProcessingFault"><orderid>ABC1153501634787</orderid>
<timestamp>Fri Jul 21 13:07:14 EDT 2006</timestamp></ns2:Status>
41 / 259
Serviceorientierte Architekturen
Webservices
REST
Auftragsdaten lesen: HTTP GET
GET /restfulwebservice-war/poservice/ABC1153501634787 HTTP/1.0
Connection: close
Content-Type: text/xml
HTTP-Antwort
HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5
Content-Type: text/xml
Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<ns3:PurchaseOrderDocument
xmlns:ns3="urn:PurchaseOrderDocument" xmlns:ns2="urn:Status"
xmlns:ns4="urn:POProcessingFault">
<billTo><street>1 Main Street</street><city>Beverly Hills</city>
<state>CA</state><zipCode>90210</zipCode>
</billTo>
<createDate>2006-07-21T13:08:37.505-04:00</createDate>
<items><itemname>Copier Paper</itemname><price>10</price><quantity>2</quantity></items>
<items><itemname>Toner</itemname><price>920</price><quantity>1</quantity></items>
<poID>/ABC1153501634787</poID>
<shipTo><street>1 Main Street</street><city>Beverly Hills</city>
<state>CA</state><zipCode>90210</zipCode>
</shipTo>
</ns3:PurchaseOrderDocument>
42 / 259
Serviceorientierte Architekturen
Webservices
REST
Auftrag löschen: HTTP DELETE
DELETE /restfulwebservice-war/poservice/ABC-CO-19282 HTTP/1.0
Connection: close
Content-Type: text/xml
Content-Length: 0
Pragma: no-cache
HTTP-Antwort
HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5
Content-Type: text/xml
Date: Fri, 21 Jul 2006 17:10:38 GMT
Server: Sun Java System Application Server Platform Edition 9.1
Connection: close
43 / 259
Serviceorientierte Architekturen
Webservices
REST
REST für komplexere Anwendungsfälle
In der Praxis werden auch für komplexe Webservice-Schnittstellen
REST-Zugriffe angeboten:
Services mit beliebigen Operationen
Beispiel: Service, Operationen und Parameter werden im URL
eines HTTP GET-Requests übermittelt
Zustandsabhängige Dienste
Beispiel: Zustandsverwaltung mit Cookies
Beispiel: Amazon Webservices
http://ecs.amazonaws.com/onca/xml
2.?Service=AWSECommerceService
3.&AWSAccessKeyId={YOUR ACCESS KEY ID}
4.&Operation=ItemLookup
5.&ItemId=1933988355
6.&ResponseGroup=Medium,Offers
44 / 259
Serviceorientierte Architekturen
Webservices
SOAP-basierte Webservices
SOAP-basierte Webservices
Auf XML und anderen offenen Standards basierende
Middleware
Kernkomponenten
Nachrichten-System: SOAP, Nutzlast sind XML-Dokumente
Schnittstellenspezifikation: XML Schema und WSDL
(Webservice Description Language)
Verzeichnisdienst: UDDI (Universal Description, Discovery and
Integration)
Erweiterungen: WS-* (Security, Transaction, ...)
Diensteorchestrierung mit WS-BPEL oder anderen
Geschäftsprozess-Definitionssprachen
45 / 259
Serviceorientierte Architekturen
Webservices
SOAP-basierte Webservices
Web-Services als Baukastensystem
Basis
XML-Schema
SOAP
WSDL
Erweiterungen WS-*
Verzeichnisdienst (UDDI, LDAP, . . . )
WS-Security
WS-ReliableMessaging
WS-Trust
WS-Policy
WS-Addressing
WS-Coordination
WS-BPEL
WS-AtomicTransaction
...
46 / 259
Serviceorientierte Architekturen
Webservices
SOAP-basierte Webservices
Nutzungsmodell für Webservices
Jeder Service definiert eine oder mehrere Operationen
Aktivierung einer Operationen durch Dienstnutzer:
Senden einer Nachricht an den Dienstanbieter
Für jede Operation werden festgelegt:
ein Muster für den Nachrichtenaustausch und
die Typen der ausgetauschten Nachrichten
Schnittstellenbeschreibung (Nachrichtentypen, Operationen)
in WSDL, maschinenlesbar und öffentlich verfügbar
Nutzer
rufen die Schnittstellenbeschreibung ab (z.B. via HTTP-GET)
nutzen den Service durch Senden von Nachrichten und
Verarbeiten der Antwortnachrichten gemäß
Schnittstellenbeschreibung
47 / 259
Serviceorientierte Architekturen
Webservices
SOAP-basierte Webservices
Rollen
Dienstanbieter (Service Provider)
Dienstanbieter-Entität (Service Provider Entity)
Dienstanbieter-Agent (Service Provider Agent)
Dienstnutzer
Dienstnutzer-Entität (Service Requestor Entity)
Dienstnutzer-Agent (Service Requestor Agent)
Ein Webservice ist immer ein Dienstanbieter.
Ein Webservice kann als Dienstnutzer agieren!
48 / 259
Serviceorientierte Architekturen
Webservices
WSDL
WSDL - Web Service Description Language
XML-basierte Sprache zur Beschreibung der Schnittstelle eines
Webservice
Aktuelle Version: W3C-Standard WSDL 2.0
http://www.w3.org/TR/wsdl20
Meist wird aber noch Version 1.1 verwendet!
WSDL unterstützt SOAP-basierte, ab 2.0 auch RESTful
Webservices
49 / 259
Serviceorientierte Architekturen
Webservices
WSDL
WSDL-Aufbau
Schnittstellenbeschreibung ist ein XML-Dokument
Wurzelement ist Container für Schema-Definitionen und
WSDL-Definitionen
Version 1.1:
<definitions> ... </definitions>
Version 2.0:
<description> ... </description>
Dem Wurzelelement ist ein URI als Attribut
„targetNamespace“ zugeordnet.
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:description
targetNamespace="http://example.org/TicketAgent.wsdl20"
xmlns:wsdl="http://www.w3.org/ns/wsdl" ...>
50 / 259
Serviceorientierte Architekturen
Webservices
WSDL
WSDL-Aufbau
Die Beschreibung ist zweigeteilt:
Abstrakte Definition
beschreibt die Operationen des Webservice durch die jeweils zu
verwendenden Nachrichtentypen
gibt keine Auskunft darüber, wo und wie ein Diensteanbieter
erreichbar ist
Konkrete Definition
beschreibt, wie und wo der Service erreichbar ist
Service kann über mehrere Transportdienste genutzt werden
51 / 259
Serviceorientierte Architekturen
Webservices
WSDL
Abstrakte Schnittstellenbeschreibung
Die Definitionen bilden eine 4-stufige Hierarchie:
benutzerdefinierte
Typen
verwendet
Definition der
Nachrichten
verwendet
Definition der
Operationen
besteht aus
abstrakte
Schnittstelle
52 / 259
Serviceorientierte Architekturen
Webservices
WSDL
Aufbau der abstrakten Schnittstelle
Typisch:
<types>
...
</types>
<message ...>
<message ...>
...
...
...
</message>
</message>
...
...
...
...
</documentation>
</operation>
</operation>
<interface ...>
<documentation>
<operation ...>
<operation ...>
</interface>
53 / 259
Serviceorientierte Architekturen
Webservices
WSDL
Konkrete Schnittstellenbeschreibung
Webservices sind prinzipiell Transport-unabhängig
Wichtige Transportdienste: HTTP, TCP, SMTP
Die konkrete Schnittstellenbeschreibung definiert
verfügbare Transportdienste
Kommunikations-Endpunkte
WSDL-Style: definiert XML-Syntax, meist
document/literal/wrapped
„binding“-Element: Transportprotokoll und WSDL-Style
„service“-Element: Endpunktliste
„port“-Element: Endpunkt
54 / 259
Serviceorientierte Architekturen
Webservices
WSDL
WDSL-Beispiel - Version 1.1
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="InvoiceProcessing"
targetNamespace="http://www.xmltc.com/railco/transform/wsdl/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:inv="http://www.xmltc.com/railco/invoice/schema/"
xmlns:invs="http://www.xmltc.com/railco/invoiceservice/schema/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.xmltc.com/railco/transform/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<types>
<xsd:schema targetNamespace="http://www.xmltc.com/railco/invoiceservice/schema/">
<xsd:import namespace="http://www.xmltc.com/railco/invoice/schema/"
schemaLocation="Invoice.xsd"/>
<xsd:element name="SubmitInvoiceType">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ContextID" type="xsd:integer"/>
<xsd:element name="InvoiceLocation" type="xsd:string"/>
<xsd:element name="InvoiceDocument" type="inv:InvoiceType"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</types>
55 / 259
Serviceorientierte Architekturen
Webservices
WSDL
WDSL-Beispiel - Version 1.1
<message name="receiveSubmitMessage">
<part name="RequestParameter" element="invs:SubmitInvoiceType"/>
</message>
<portType name="InvoiceProcessingInterface">
<documentation>
Initiates the Invoice Processing process.
Requires either the invoice document location or the document.
</documentation>
<operation name="Submit">
<input message="tns:receiveSubmitMessage"/>
</operation>
</portType>
<binding name="InvoiceProcessingBinding" type="tns:InvoiceProcessingInterface">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="Submit">
<soap:operation soapAction="http://www.xmltc.com/soapaction"/>
<input>
<soap:body use="literal"/>
</input>
</operation>
</binding>
<service name="InvoiceProcessingService">
<port binding="tns:InvoiceProcessingBinding" name="InvoiceProcessingPort">
<soap:address location="http://www.serviceoriented.ws/railco/wsdl/"/>
</port>
</service>
</definitions>
56 / 259
Serviceorientierte Architekturen
Webservices
WSDL
WDSL-Beispiel: Abstrakte Schnittstelle V2.0
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:description
targetNamespace="http://example.org/TicketAgent.wsdl20"
xmlns:xsTicketAgent="http://example.org/TicketAgent.xsd"
xmlns:wsdl="http://www.w3.org/ns/wsdl"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://www.w3.org/ns/wsdl http://www.w3.org/2007/06/wsdl/wsdl20.xsd">
<wsdl:types>
<xs:import schemaLocation="TicketAgent.xsd"
namespace="http://example.org/TicketAgent.xsd" />
</wsdl:types>
<wsdl:interface name="TicketAgent">
<wsdl:operation name="listFlights"
pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="xsTicketAgent:listFlightsRequest"/>
<wsdl:output element="xsTicketAgent:listFlightsResponse"/>
</wsdl:operation>
<wsdl:operation name="reserveFlight"
pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="xsTicketAgent:reserveFlightRequest"/>
<wsdl:output element="xsTicketAgent:reserveFlightResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
57 / 259
Serviceorientierte Architekturen
Webservices
WSDL
WSDL Ausnahmebehandlung
Mit „fault“-Elementen definiert man Nachrichten, die bei
Laufzeitfehlern generiert und verschickt werden
Fehlersemantik i.d.R. programmiersprachenunabhängig
Fehlerbehandlung betrifft Bindung zwischen
Implementierungssprache und Webservice
das Versenden von Fehlernachrichten bei Laufzeitausnahmen
das Werfen von Ausnahmen beim Empfang von
Fehlernachrichten
58 / 259
Serviceorientierte Architekturen
Webservices
WSDL
Fault-Beispiel (WSDL 1.1)
<definitions ...>
<message name="empty"/>
<message name="InsufficientFundsFault">
<part name="balance" type="xsd:int"/>
</message>
<portType name="Bank">
<operation name="throwException">
<input message="tns:empty"/>
<output message="tns:empty"/>
<fault name="fault" message="tns:InsufficientFundFault"/>
</operation>
</portType>
...
</definitions>
59 / 259
Serviceorientierte Architekturen
Webservices
WSDL
Dienstvertrag
Bestandteile des Dienstnutzungsvertrags
WSDL + Schema-Dokumente
Richtlinien (Policies)
Weitere Vereinbarungen
60 / 259
Serviceorientierte Architekturen
Webservices
SOAP
SOAP
Asynchroner Nachrichtenaustausch ist in einer SOA die
grundlegende Operation
=⇒ Leistungsfähiges Nachrichtenkonzept ist von essentieller
Bedeutung für SOA
Anforderungen:
Erweiterbarkeit
Plattformunabhängigkeit
Unterstützung gängiger Kommunikationsmuster
Effizienz?
„nice to have“!
61 / 259
Serviceorientierte Architekturen
Webservices
SOAP
SOAP-Grundlagen
SOAP ist ein „high level“-Transportdienst
kann z.B. mit HTTP oder TCP als „low level“-Transport
kombiniert werden
W3C-Standard, aktuelle Version: 1.2
SOAP-Nachrichten sind XML-Dokumente:
Envelope enthält Header (optional) und Body („Nutzlast“ der
Nachricht)
Nutzlast einer SOAP-Nachricht: anwendungsspezifisch
definiertes XML-Dokument
(→ Synergieeffekte durch Nutzung der XML-Infrastruktur)
62 / 259
Serviceorientierte Architekturen
Webservices
SOAP
Nachrichtenaustauschmuster
SOAP beruht auf Einweg-Versendung von Nachrichten, bzw.
dem Muster „Auftrag-Antwort“.
Komplexere Nachrichten-Austauschmuster werden oberhalb
der SOAP-Ebene implementiert
63 / 259
Serviceorientierte Architekturen
Webservices
SOAP
Beispiel für eine SOAP-Nachricht: Gesamtstruktur
<?xml version=’1.0’ ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
.
.
.
</env:Header>
<env:Body>
.
.
.
</env:Body>
</env:Envelope>
64 / 259
Serviceorientierte Architekturen
Webservices
SOAP
Beispiel für eine SOAP-Nachricht: Header
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger
xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Ake Jogvan Oyvind</n:name>
</n:passenger>
</env:Header>
65 / 259
Serviceorientierte Architekturen
Webservices
SOAP
Beispiel für eine SOAP-Nachricht: Body
<env:Body>
<p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
<p:return> ... </p:return>
</p:itinerary>
<q:lodging
xmlns:q="http://travelcompany.example.org/reservation/hotels">
<q:preference>none</q:preference>
</q:lodging>
</env:Body>
66 / 259
Serviceorientierte Architekturen
Webservices
SOAP
SOAP-Header
SOAP-Header enthalten Metadaten, die die Verarbeitung der
Nachricht beeinflussen
Inhalt und Semantik sind im SOAP-Standard nicht definiert
Die Header sind ein Erweiterungskonzept für SOAP:
Anwendungs-spezifische Erweiterungen
Erweiterungen im Rahmen des WS-*-“Baukastens“
67 / 259
Serviceorientierte Architekturen
Webservices
SOAP
Beispiel für Headernutzung: WS-ReliableMessaging
<soapenv:Envelope>
<soapenv:Header>
<wsa:MessageID> ... </wsa:MessageID>
<wsa:To> ... </wsa:To>
<wsa:Action> ... </wsa:Action>
<wsa:From> ... </wsa:From>
<wsrm:Sequence soapenv:mustUnderstand="1">
<wsu:Identifier>
http://www.ibm.com/guid/a8f7151a091b50a42b38e04437774e11
</wsu:Identifier>
<wsrm:MessageNumber>1</wsrm:MessageNumber>
</wsrm:Sequence>
</soapenv:Header>
<soapenv:Body> ... </soapenv:Body>
</soapenv:Envelope>
Namespaces: wsu=WS-Utilities, wsa=WS-Adressing,
wsrm=WS-ReliableMessaging
68 / 259
Serviceorientierte Architekturen
Webservices
SOAP
WS-ReliableMessaging: Letzte Nachricht einer Sequenz
<soapenv:Envelope>
<soapenv:Header>
<wsa:MessageID> ... </wsa:MessageID>
<wsa:To> ... </wsa:To>
<wsa:Action> ... </wsa:Action>
<wsa:From> ... </wsa:From>
<wsrm:Sequence soapenv:mustUnderstand="1">
<wsu:Identifier>
http://www.ibm.com/guid/a8f7151a091b50a42b38e04437774e11
</wsu:Identifier>
<wsrm:MessageNumber>4</wsrm:MessageNumber>
<wsrm:LastMessage/>
</wsrm:Sequence>
</soapenv:Header>
<soapenv:Body> ... </soapenv:Body>
</soapenv:Envelope>
69 / 259
Serviceorientierte Architekturen
Webservices
SOAP
WS-ReliableMessaging: Bestätigung für partiellen Empfang
einer Sequenz
<soapenv:Envelope>
<soapenv:Header>
<wsa:MessageID> ... </wsa:MessageID>
<wsa:To> ... </wsa:To>
<wsa:Action> ... </wsa:Action>
<wsa:From> ... </wsa:From>
<wsrm:SequenceAcknowledgement>
<wsu:Identifier>
http://www.ibm.com/guid/a8f7151a091b50a42b38e04437774e11
</wsuu:Identifier>
<wsrm:AcknowledgementRange Lower="1" Upper="2"/>
<wsrm:AcknowledgementRange Lower="4" Upper="4"/>
<wsrm:Nack>3</wsrm:Nack>
</wsrm:SequenceAcknowledgement>
</soapenv:Header>
<soapenv:Body> ... </soapenv:Body> (response body)
</soapenv:Envelope>
70 / 259
Serviceorientierte Architekturen
Webservices
SOAP
WS-ReliableMessaging: Bestätigung für kompletten
Empfang einer Sequenz
<soapenv:Envelope>
<soapenv:Header>
<wsa:MessageID> ... </wsa:MessageID>
<wsa:To> ... </wsa:To>
<wsa:Action> ... </wsa:Action>
<wsa:From> ... </wsa:From>
<wsrm:SequenceAcknowledgement>
<wsuu:Identifier>
http://www.ibm.com/guid/a8f7151a091b50a42b38e04437774e11
</wsu:Identifier>
<wsrm:AcknowledgementRange Lower="1" Upper="4"/>
</wsrm:SequenceAcknowledgement>
</soapenv:Header>
<soapenv:Body> ... </soapenv:Body>
</soapenv:Envelope>
71 / 259
Serviceorientierte Architekturen
Webservices
SOAP
SOAP-Fehler / Ausnahmebehandlung
Technische Fehler und Fehler auf Anwendungsebene
Fehlercodes und Fehlermeldungs-Nachrichten
(„fault“-Sektion im Nachrichtenrumpf)
Automatische Rücksendung von Fehlermeldungs-Nachrichten
Kategorien
VersionMismatch
MustUnderstand
DataEncodingUnknown
Sender
Receiver
Sender benutzt falsche SOAP-Version
Verarbeitung eines „Muss-“Headers nicht implementiert
Unbekannte Codierung
Falsches Nachrichtenformat
Server-Problem verhindert Bearbeitung
72 / 259
Serviceorientierte Architekturen
Webservices
SOAP
Beispiel für eine SOAP-Fault-Nachricht
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header/>
<env:Body><env:Fault>
<env:Code><env:Value>env:Sender</env:Value></env:Code>
<env:Reason>
<env:Text xml:lang="en-US">
Message does not have necessary info
</env:Text>
</env:Reason>
<env:Role>http://gizmos.com/order</env:Role>
<env:Detail>
<PO:order xmlns:PO="http://gizmos.com/orders/">
Quantity element does not have a value
</PO:order>
<PO:confirmation xmlns:PO="http://gizmos.com/confirm">
Incomplete address: no zip code
</PO:confirmation>
</env:Detail>
</env:Fault></env:Body>
</env:Envelope>
73 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
Verzeichnisdienste für Web-Services
Verzeichnisdienste erleichtern das Finden von Webservices.
Notwendig, wenn deren Anzahl unüberschaubar wird.
Service-Verzeichnisse im Intranet
Teile einer unternehmensweiten SOA-Infrastruktur
Rollenbasierte Zugriffsrechte zur verteilten Pflege nötig
Einbindung in SOA-Governance-Prozess
Service-Verzeichnisse im Internet
„Gelbe Seiten“-Funktionalität
Basis: Kategorisierung von Diensten
Attributierung von Diensten
Anwendungsdomänen-spezifisch
Suchmöglichkeiten innerhalb einer Kategorie über Attribute
Beispiel: Suche Dienst in der Kategorie „route planner“,
„free=true“ „ AND „germany“ IN „available-regions“
74 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
Standards: WS-Inspection
dezentralisiertes Verzeichnisdienste-Konzept
„leichtgewichtiges“, Anbieter-lokales Verzeichnis am
„Angebotspunkt“:
Anbieter von Webservices stellt auf seiner Webseite Liste von
Links zur Verfügung
zu WSDL-Beschreibungen und/oder
zu UDDI-Verzeichnissen
Grundidee: Anbieter pflegt seine Service-Verzeichnisse!
75 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
UDDI - Universal Description, Discovery, and Integration
Zentralisiert: Wenige Verzeichnisse enthalten Dienste vieler Anbieter
White Pages
Namensregister, sortiert nach Namen
Auflistung der Anbieter mit allen Detailangaben
Yellow Pages
Branchenverzeichnis
Spezifische Suche gemäß verschiedener Taxonomien (Ort,
Dienstart,...)
Klassifiziert die Services anhand internationaler Standards wie
UNSPSC
Green Pages
Informationen über das Geschäftsmodell des Unternehmens
Technische Details zu den angebotenen Web Services
Auskunft über Geschäftsprozesse
76 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
Verzeichnisdienste in der Praxis
Anforderungen für unternehmensweite Verzeichnisdienste und
„Gelbe Seiten“ im Internet sind sehr unterschiedlich
UDDI gilt als gescheitert:
Für unternehmensinterne Verzeichnisse:
zu komplex, Einbindung in Governance-Prozesse schwierig,
fehlende Rollen-Unterstützung
Internet:
Problem: Wer betreibt „das eine“ zentrale Verzeichnis?
Anwender setzen auf leichtgewichtigere Lösungen (LDAP,
Nonstandard-Verzeichnisse)
77 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
Richtlinien: WS-Policy
Formalisierte Zusatzvereinbarungen für Dienstenutzung
Regeln, Einschränkungen, Präferenzen, Zusicherungen
Verarbeitung durch Mensch oder Maschine
Eine Richtlinie bezieht sich auf Richtliniensubjekt:
Dienst
Bindung
Operation
Nachricht
Richtliniendomänen: Sicherheit, Koordination usw.
Richtliniendomäne definiert Basisanforderungen (policy assertion)
Beispiel Sicherheitsrichtlinie: Nachricht muss verschlüsselt sein
Richtliniensprache definiert Konstrukte zur Formulierung komplexer
Richtlinien
78 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
Richtlinien-Terminologie
Jede Richtlinie kann mehrere Richtlinienalternativen vorsehen
Eine Richtlinienalternative ist eine Menge von einzelnen
Richtlinienanforderungen (policy assertions)
Ein Richtlinienausdruck ist eine in XML gemäß WS-Policy
formulierte Richtlinienanforderung
Ein „Policy Attachment“ verknüpft eine
Richtlinienanforderung mit einem Richtliniensubjekt
Näheres:
http://www-128.ibm.com/developerworks/webservices/library/ws-policy.html
79 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
Richtlinien-Beispiele
Eine Operation erfordert Authentifizierung durch
X.509-Zertifikat oder
Benutzername und Passwort
Operation muss in Transaktion eingebunden werden
Dienst (alle Operationen) erfordert Unterstützung von
WS-Security Version 1.1
Die Richtlinie bestimmt Timeout-Werte für die Übermittlung
von Nachrichtensequenzen gemäß WS-ReliableMessaging
Für eine Nachricht wird HTTPS-Transport verlangt
Ein Dienst verlangt UTF-8-Zeichencodierung
80 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
Beispiel eines WSDL-Beschreibung mit Richtlinien
<wsdl:definitions name="StockQuote"
targetNamespace="http://www.fabrikam123.example.com/stock/binding"
xmlns:tns="http://www.fabrikam123.example.com/stock/binding"
xmlns:fab="http://www.fabrikam123.example.com/stock"
xmlns:rmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" >
(02)
<wsp:Policy wsu:Id="RmPolicy" >
(03)
<rmp:RMAssertion>
(04)
<rmp:InactivityTimeout Milliseconds="600000" />
(05)
<rmp:BaseRetransmissionInterval Milliseconds="3000" />
(06)
<rmp:ExponentialBackoff />
(07)
<rmp:AcknowledgementInterval Milliseconds="200" />
(08)
</rmp:RMAssertion>
(09)
</wsp:Policy>
(10)
<wsp:Policy wsu:Id="X509EndpointPolicy" >
(11)
<sp:AsymmetricBinding>
(12)
<wsp:Policy>
<!-- Details omitted for readability -->
(13)
<sp:IncludeTimestamp />
(14)
<sp:OnlySignEntireHeadersAndBody />
(15)
</wsp:Policy>
(16)
</sp:AsymmetricBinding>
(17)
</wsp:Policy>
81 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
(18)
(19)
(20)
(21)
(22)
(23)
(24)
(25)
(26)
(27)
(28)
(29)
(30)
(31)
(32)
(33)
(34)
(35)
(36)
(37)
(38)
(39)
(40)
(41)
(42)
(43)
(44)
(45)
<wsp:Policy wsu:Id="SecureMessagePolicy" >
<sp:SignedParts>
<sp:Body />
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Body />
</sp:EncryptedParts>
</wsp:Policy>
<wsdl:import namespace="http://www.fabrikam123.example.com/stock"
location="http://www.fabrikam123.example.com/stock/stock.wsdl" />
<wsdl:binding name="StockQuoteSoapBinding" type="fab:Quote" >
<wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsp:PolicyReference URI="#RmPolicy" wsdl:required="true" />
<wsp:PolicyReference URI="#X509EndpointPolicy" wsdl:required="true" />
<wsdl:operation name="GetLastTradePrice" >
<wsoap12:operation soapAction=
"http://www.fabrikam123.example.com/stock/Quote/GetLastTradePriceRequest" />
<wsdl:input>
<wsoap12:body use="literal" />
<wsp:PolicyReference URI="#SecureMessagePolicy"
wsdl:required="true" />
</wsdl:input>
<wsdl:output>
<wsoap12:body use="literal" />
<wsp:PolicyReference URI="#SecureMessagePolicy"
wsdl:required="true" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>
82 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
Metadaten-Austausch
83 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
Metadaten-Austausch
Mechanismus zur Erfragen der Metadaten zu einem Dienst
Selektive oder komplette Zusendung von Metadaten:
WSDL (auch über UDDI erfragbar)
zugrunde liegende XSD-Schemata
Richtlinien
Anwendungsbeispiele
Einsicht der Metadaten zur Vorbereitung der ersten Dienstenutzung
Regelmäßige Kontrolle der Metadaten, um Änderungen des
Dienstvertrags durch den Anbieter automatisch entdecken (Merkmal
loser Kopplung)
84 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
Übertragung aller Metadaten
85 / 259
Serviceorientierte Architekturen
WS-* Erweiterungen
Metadaten-Austausch im Fallbeispiel
86 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheit (“Security”) von serviceorientierten Systemen
Problem
Serviceorientierte Systeme ermöglichen den Zugriff auf
unternehmenskritische Informationen und Backend-Systeme über
das Internet.
Firewall-basierte Schutzkonzepte sind dabei nicht wirksam.
Daraus resultieren hohe Sicherheitsrisiken.
Vorgehensweise
Bedrohungen/Angriffsszenarien analysieren
Sicherheitsanforderungen definieren
Sicherheitsarchitektur entwerfen und implementieren
87 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Aspekte einer Sicherheitsarchitektur
Sicherheitsrichtlinien (“Policy”)
Sichere Kommunikationsprotokolle
Netzwerk-Architektur mit Sicherheitsdiensten
Rollenkonzept nach XACML
Policy Enforcement Point (PEP)
Policy Decision Point (PDP)
Policy Information Point (PIP)
PKI-System (Schlüssel- und Zertifikatsverwaltung nach X.509)
Ticket-System (Kerberos)
Single Sign-On System (SAML-basiert, CAS)
88 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Bedrohungen/Angriffsszenarien
Allgemeine Sicherheitsisiken gelten auch für Webservices
unautorisierte Zugriffe
Ausspionieren vertraulicher Daten
„Denial of Service“-Attacken
Malware (Viren, Spyware/Trojaner, Würmer)
89 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Spezifische Sicherheitsrisiken
Webservices sind oft Schnittstellen zu Backend-Systemen,
machen diese von außen angreifbar
Webservices realisieren unternehmenskritische Geschäftsprozesse
→ Vertraulichkeit und Integrität der Daten besonders wichtig
(Besonders kritisch: Schutz vor Industriespionage)
Externe Webservices sind von der Sicherheit her schwer
einzuschätzen, entsprechen ggf. nicht internen Sicherheitsrichtlinien
Firewalls sind kein geeignetes Schutzkonzept
für HTTP-basierte WS-Nutzung meist offen
klassische Zonenkonzepte „unsicher“/DMZ/“sicher“ nicht
hilfreich
90 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Spezifische „Denial of Service“-Attacken
XML-Parser zum Absturz bringen
(z.B. Speichermangel beim DOM-Parser erzeugen)
XML-Schema manipulieren (XML-“Vergiftung“)
Massenhaft nicht gültige XML-Dokumente senden
(erhöhter Bearbeitungsaufwand beim Dienstanbieter)
Manipulation von Dienstverzeichnissen
91 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Sicherheitsanforderungen für Webservices
Identifikation und Authentisierung der Teilnehmer
Integrität der Daten, Schutz gegen Manipulation
Vertraulichkeit der Daten
Verschlüsselung beliebiger Teile von Dokumenten
Autorisierungsmechanismen
Zugriff auf Services
Zugriff auf verschlüsselte Teile von Geschäftsdokumenten
Verbindlichkeit (Nichtabstreitbarkeit der Teilnahme an einer
Transaktion)
Single Sign-On / Weitergabe von Autorisierungsinformation
Ende-zu-Ende Sicherheitskonzepte für komplexe
Nachrichtenpfade
92 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Sicherheitsmerkmale auf verschiedenen Ebenen
IPSec VPN (Virtuelles Privates Netzwerk)
(falls bereits die das Wissen um die Existenz der
Kommunikation sicherheitskritisch ist)
Sicherer Transport: Secure Socket Layer (SSL) / Transport
Level Security (TLS)
Sicherung auf der Nachrichtenebene (XML/SOAP)
Sicherheitsrichtlinien für die Dienstenutzung
Gleichzeitige Realisierung von Sicherheitsmechanismen auf
verschiedenen Kommunikationsschichten ist kein Widerspruch
93 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Transportsicherheit durch SSL/TLS
SSL = „Secure Socket Layer“-Protokoll
TLS = „Transport Layer Security“
Begriff TLS benutzbar
als Weiterentwicklung von SSL oder
als Bezeichnung für neuere SSL-Versionen
Ursprünglich von Netscape entwickeltes Sicherungsprotokoll
Protokoll wird zwischen Transportschicht und Anwendung
„eingeschoben“
SSL wird aus Anwendungssicht wie ein Transportprotokoll
behandelt
SSL wird vom Transportdienst wie ein Anwendungsprotokoll
behandelt
94 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
SSL im Schichtenmodell
95 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
SSL-Anwendungsbeispiele
Verschlüsselung von WWW-Sitzungen
Verschlüsselung von Dateiübertragungen
Verschlüsselung von E-Mail
Authentisierung der Kommunikationspartner
Server-Authentisierung durch Client oder
gegenseitige Authentisierung
mit oder ohne Zertifikatsprüfung
96 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
SSL - Technische Merkmale
Sub-Protokolle
SSL-Record-Protocol definiert Datenformat für die Nachrichten
SSL-Handshake-Protocol definiert
Parameter-Verhandlung beim Sitzungsaufbau
Authentisierung beim Sitzungsaufbau
Generierung und Versendung eines Sitzungsschlüssels
Verschlüsselungsverfahren
Kombination aus asymmetrischen und symmetrischen Verfahren,
sowie Hash-Verfahren zur Dokumentauthentisierung
Beispiele: DES, Triple DES, DSA, KEA, MD5, RSA
97 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
SSL-Verbindungsaufbau
98 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Schema für SSL-Handshake in Java
import
import
import
import
java.security.cert.Certificate;
javax.net.ssl.HttpsURLConnection;
javax.net.ssl.SSLSocket;
javax.net.ssl.SSLSocketFactory;
public class SSLBeispiel {
public static void main(String[] argv) throws Exception {
int port = 443;
String hostname = "googlemail.com";
SSLSocketFactory factory = HttpsURLConnection.getDefaultSSLSocketFactory();
SSLSocket sock = (SSLSocket) factory.createSocket(hostname, port);
sock.startHandshake();
// Zertifikatskette holen
Certificate[] x509Zertifikat = sock.getSession().getPeerCertificates();
System.out.println(x509Zertifikat.length + " Zertifikate gefunden\n\n\n");
for (int i = 0; i < x509Zertifikat.length; i++) {
Certificate zert = x509Zertifikat[i];
System.out.println("Zertifikat:" + (i+1));
System.out.println("Public Key\n" + zert.getPublicKey());
System.out.println("Typ\n " + zert.getType());
}
sock.close();
}
}
99 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Transportsicherheit ist nicht immer ausreichend
In vielen Anwendungsszenarien erfüllt ein sicherer Transportdienst die
Sicherheitsanforderungen nicht.
Problem: Nachrichtenpfade mit intermediären Diensten
Vertraulichkeit: Nur ein Teil der an der Verarbeitung eines
Dokuments beteiligten Dienste soll Zugriff auf vertrauliche Daten
erlangen
Beispiel: In einer Bestellung sind verschlüsselte Kreditkartendaten
enthalten, die nur der Dienst zur Zahlungsabwicklung kennen darf
Nichtabstreitbatkeit: kein Ende-zu-Ende Absenderbeweis
100 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Sonstige Gründe für Sicherheit auf Nachrichtenebene
1
Granularität der Vertraulichkeit zu grob: In manchen Fällen möchte
man Teile einer Nachricht verschlüsseln, während andere Teile für
intermediäre Bearbeitung unverschlüsselt sein müssen
2
Keine Integration des SSL-Handshake in die SOAP-Ebene vorhanden
3
Server-Zertifikate nötig → Zusatzaufwand
4
Laufzeitaufwand durch SSL-Handshake
5
Zertifikatsaustausch vor Dienstenutzung widerspricht der Idee loser
Kopplung
6
Asynchrone Diensteaufrufe nicht möglich
101 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Transport-Sicherheit und intermediäre Dienste
102 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
WS-Security Framework
Framework für Sicherheit auf Nachrichtenebene
Ergänzt Sicherheit auf Transportebene (SSL/TLS)
XML-bezogene Sicherheitsmechanismen
WS-bezogene Sicherheitsmechanismen
Zum Framework gehört der OASIS-Standard WS-Security (IBM,
Microsoft, Verisign).
Er regelt die Nutzung von XML-Sicherheitsmechanismen für SOAP
durch Definition entsprechender SOAP-Header.
103 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
WS-Security Framework: Wichtige Standards
WS-Security
WS-SecurityPolicy
WS-Trust
Extensible Access Control Markup Language (XACML)
XML Key Management (XKMS)
XML-Signature
XML-Encryption
Security Assertion Markup Language (SAML)
WS-I Basic Security Profile
104 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
XML Encryption
Merkmale
Vollständige oder teilweise Verschlüsselung von XML-Dokumenten
Wahl zwischen verschiedenen asymmetrischen oder symmetrischen
Chiffrierverfahren: (Triple-DES-CBC, AES-CBC, RSA)
Verschlüsselung einzelner Elemente mit unterschiedlichen Schlüsseln
möglich
→ selektive Sichtbarkeit entlang komplexer Nachrichtenpfade
Verschlüsselung von Elementinhalten unter Bewahrung der XML-Tags →
partielle Verarbeitung ohne Dechiffrierung
105 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
XML Encryption
Verwendung mit SOAP
Verschlüsselung von SOAP-Nachrichten
Verschlüsselung sensibler Metadaten im Header
Verschlüsselung sensibler Nutzdaten im Body
Verschlüsselung angehängter Binärdaten
Übertragung der Verschlüsselungsparameter in der Nachricht
(Chiffrierverfahren, Initialisierungsparameter)
106 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
XML Encryption
Grundelemente
EncryptedData
EncryptionMethod
CipherData
umschließendes Tag für die Verschlüsselung
Der verwendete Verschlüsselungsalgorithmus
Die verschlüsselten Daten (direkt oder Referenz)
107 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Beispiel: Partielle Verschlüsselung
Verschlüsselung der Kreditkartennummer:
...
<PaymentInfo xmlns=’http://example.org/paymentv2’>
<Name>John Smith</Name>
<CreditCard Limit=’5,000’ Currency=’USD’>
<Number>
<EncryptedData xmlns=’http://www.w3.org/2001/04/xmlenc#’
Type=’http://www.w3.org/2001/04/xmlenc#Content’>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</Number>
<Issuer>Example Bank</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
108 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Elektronische Signatur
Sicherheitsziele
Ersatz für herkömmliche Unterschrift
Verzicht auf verschlüsselte Übertragung möglich (Effizienz!)
Datenintegrität:
Erkennung von Verfälschungen durch Übertragungsfehler oder
Manipulationen
Absenderauthentizität
Nichtabstreitbarkeit des Nachrichtenversands
109 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Elektronische Signatur
Technische Voraussetzungen
Asymmetrische Verschlüsselung („private key“+“public key“)
PKI-System zur Verwaltung von öffentlichen Signaturschlüsseln und
Zertifikaten (z.B. X.509, PGP)
Hash-Verfahren zur Erstellung eines „message digest“
(Prüfsumme des Dokuments)
Alternativ:
Symmetrische Verschlüsselung („secret key“) mit zentraler
Verwaltung der Schlüssel („Kerberos“)
110 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Beispiel für ein Implementierungsschema
(aus Wikipedia)
111 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
XML-Signature - Standard für signierte XML-Dokumente
Merkmale
Unterstützt elektronische Signatur von
XML-Dokumenten
Abschnitten oder
einzelnen Elementen
Bestandteile können mit unterschiedlichen Schlüsseln signiert werden
Signierte Dokumente enthalten ein XML-Element „Signature“ mit
signierten Daten („SignedInfo“)
Angaben zum Signierschlüssel („KeyInfo“)
Signatur („SignatureValue“)
Kanonische XML-Repräsentation erforderlich
Zeichencodierung
„Whitespace“-Zeichen
112 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Signaturvarianten
Bindung der Signatur an die signierten Daten
Eingebettete Signatur („enveloped signature“)
Signatur-Element ist Unterelement des signierten Elements
Einbettende Signatur („enveloping signature“)
Signatur-Element ist Eltern-Element des signierten Elements
Separate Signatur („detached signature“)
Signatur und signierte Daten stehen in separaten Dokumenten
113 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Beispiel-Struktur
Einbettende Signatur
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
...
</SignedInfo>
<KeyInfo>
...
</KeyInfo>
<SignatureValue>
...
</SignatureValue>
</Signature>
114 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Kanonische XML-Repräsentation und Digitale Signatur
(aus Melzer et al.)
115 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Beispiel für XML-Signatur
Einbettende Signatur
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/..."/>
<SignatureMethodAlgorithm="http://www....xmldsig#rsa-sha1"/>
<Reference URI="#PurchaseOrder">
<DigestMethod Algorithm="http://www.w3...xmldsig#sha1"/>
<DigestValue>qZk+nkcGcWq6piVxeFdczQ2J=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
IWijxQjUrcXBYc0ei4QxjWo9Kg8Dep9tlWoT4SdeRT87GH03dgh
</SignatureValue >
<KeyInfo>
<X509Data>
<X509SubjectName>
CN=Smith, STREET=742 P.Av,L=New York, ST=NY, C=US
</X509SubjectName>
</X509Data>
< /KeyInfo>
</Signature>
116 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
SOAP-Security
Merkmale
SOAP-Header zur Nutzung von XML-Sicherheitskonzepten XENC,
XDSIG u.a.
Entlang komplexer Nachrichtenpfade agierende Services benötigen
ggf. spezifische sicherheitsrelevante Metadaten
Ein Security-Header kann einem Aktor zugeordnet werden
Zwischendienste können Security-Header hinzufügen/modifizieren
Security-Token-Elemente im Header repräsentieren für
Verschlüsselung und Signaturen benötigte Zusatzinformation
117 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Security-Token-Kategorien
Security-Token-Kategorien
Username Token – zur Identifikation
X.509 – X.509-Zertifikat
Kerberos – Kerberos Ticket
SAML – SAML Security Assertion
Technische Datentypen für Security Tokens
BinarySecurityToken – Base64-codiertes binäres Token
EncryptedDataToken – Verschlüsselte Information
SecurityTokenReference – Verweis auf Token
SecurityTimestamp – Zeitstempel für Verschlüsselungszwecke
118 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Beispiel für signierte SOAP-Nachricht
Header
<s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope">
<s12:Header>
<wsse:Security
xmlns:wsse="http://schemas.xmlsoap.org/soap/security/2000-12"
s12:actor="http://www.example.com/soapEndpoint"
s12:mustUnderstand="1">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<ds:Reference URI="#Body">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>zA9itX3gfzCeYIYyalslJezGwAg=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
MCpXybqBI2Aa3Yx4IovjN3GgchaMDB3lIF1M6a9+Ngi59MqDwK3LRQ==
</ds:SignatureValue>
</ds:Signature>
</wsse:Security>
</s12:Header>
119 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Body
<s12:Body xmlns:wsse="http://schemas.xmlsoap.org/soap/security/2000-12"
wsse:id="Body">
<ns1:add xmlns:ns1="urn:NumberAdder"
s12:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<number1 xsi:type="xsd:int">1</number1>
<number2 xsi:type="xsd:int">2</number2>
</ns1:add>
</s12:Body>
</s12:Envelope>
120 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
Beispiel für Verwendung von Verschlüsselung und Signatur
<?xml version="1.0" encoding="utf-8"?>
<S11:Envelope ...>
<S11:Header>
<wsse:Security>
<wsu:Timestamp wsu:Id="T0">
<wsu:Created>2001-09-13T08:42:00Z</wsu:Created>
</wsu:Timestamp>
<wsse:BinarySecurityToken
ValueType="http://...#X509v3"
wsu:Id="X509Token"
EncodingType="...#Base64Binary">
MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
</wsse:BinarySecurityToken>
121 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
<xenc:EncryptedKey>
<xenc:EncryptionMethod Algorithm=
"http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier
EncodingType="...#Base64Binary"
ValueType="http://...#X509v3">
MIGfMa0GCSq...
</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...
</xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference URI="#enc1"/>
</xenc:ReferenceList>
</xenc:EncryptedKey>
122 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#T0">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod ...
<ds:DigestValue>LyLsF094hPi4wPU...
</ds:DigestValue>
</ds:Reference>
123 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
<ds:Reference URI="#body">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm=.../>
<ds:DigestValue>LyLsF094hPi4wPU... </ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
Hp1ZkmFZ/2kQLXDJbchm5gK...
</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#X509Token"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</S11:Header>
124 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Sicherheitsanforderungen
<S11:Body wsu:Id="body">
<xenc:EncryptedData
Type="http://www.w3.org/2001/04/xmlenc#Element"
wsu:Id="enc1">
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</S11:Body>
</S11:Envelope>
125 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Zertifikate und PKI-Systeme
Zertifikate und PKI-Systeme
Definition
Ein Zertifikat ist eine nachprüfbare Aussage einer Entität (Person,
Unternehmen, System) über einen Sachverhalt.
§2(3) Deutsches Signaturgesetz
Ein Zertifikat . . . ist eine mit einer digitalen Signatur versehene digitale
Bescheinigung über die Zuordnung eines öffentlichen Signaturschlüssels
zu einer natürlichen Person (Signaturschlüssel-Zertifikat) oder eine
gesonderte digitale Bescheinigung, die unter eindeutiger Bezugnahme auf
ein Signaturschlüssel-Zertifikat weitere Angaben enthält
(Attribut-Zertifikat).
126 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Zertifikate und PKI-Systeme
Public Key Infrastrukturen (PKI)
Funktionen eines PKI-Systems
Registrierung und Authentisierung der Teilnehmer
Verwaltung der öffentlichen Schlüssel
Ausstellung und Verwaltung von Schlüsselzertifikaten
Betrieb eines Online-Diensts zum Zugriff auf Schlüssel und
Zertifikate
127 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Zertifikate und PKI-Systeme
Zertifizierungsautorität (Certificate Authority - CA)
Funktionen
registriert Personen und deren öffentliche Schlüssel
betreibt ständig verfügbaren Online-Dienst zur Prüfung von
öffentlichen Schlüsseln anhand von Zertifikaten
verwaltet „schwarze“ Listen für ungültige Zertifikate
Beispiele
Deutsche Telekom AG
Deutscher Sparkassenverlag GmbH (S-TRUST)
DFN-Verein / DFN PCA (www.cert.dfn.de)
Verisign (www.verisign.com)
128 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Zertifikate und PKI-Systeme
Registrierungsauthorität („Registration Authority“, RA)
(auch „Beglaubigungsdienst“)
Funktion: „out of band“-Aufgaben
Prüfungen bei Erteilung von Schlüsselzertifikaten, z.B.
Prüfung von Lichtbildausweisen
weitergehende Überprüfungen, z.B. durch
Wirtschaftsinformationsdienste wie Schufa usw.
Anlaufstelle für Revozierungen (z.B. bei verloren gegangener
Signatur-Smartcard)
Die RA kann in die CA integriert sein.
129 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Zertifikate und PKI-Systeme
Standard für Zertifikate: ISO X.509
Zertifikatsaufbau (Auszug)
Komponente
Versionsnummer
Seriennummer
Algorithmus-ID
X.500-Name der CA
Gültigkeit
Gegenstand (Subject)
Subject Public Key Info
Signatur der CA
CA-Kennung
Subject Unique ID
Extensions
Beschreibung
1-3
Eindeutig für jede CA
z.B. DSA
z.B. „C=US, O=VeriSign“
Anfangs- und Endzeitpunkt
Benutzername
Algorithmus, Parameter, öff. Schlüssel
eindeutige Kennung inkl. WWW-URL
Art des Zertifikats
Einschränkungen und Bedingungen
130 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Zertifikate und PKI-Systeme
Beispiel für ein Zertifikat
Übersichtsansicht im Webbrowser
131 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Zertifikate und PKI-Systeme
PKCS - Public Key Cryptography Standard
Industriestandard (www.rsa.com)
Algorithmen und Datenformate
RSA-Verschlüsselung
Diffie-Hellman Schlüsselaustausch
DES-Verschlüsselung
Datenformate für X.509-Erweiterungen
Datenformate für geheime Schlüssel
Hardwareschnittstellen
Art und Weise der Schlüsselabspeicherung
Syntax für Zertifikatsabfrage bei CA
132 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Zertifikate und PKI-Systeme
OCSP - Online Certificate Status Protocl – RFC 2560
Merkmale
Industriestandard zur Online-Prüfung von X.509-Zertifikaten
Serverseite (OSCP-Responder)
wird vom Zertifikats-Herausgeber betrieben
prüft in einer Anfrage ein oder mehrere Zertifikate
Antwort digital signiert
Antwort ist: “good” oder “revoked” mit Sperrzeitpunkt
Verwendung in PKI-Systemen und im WWW (z.B. Mozilla
Firefox/Thunderbird)
Problem: War digitale Signatur zum Signierzeitpunkt gültig?
OCSP erlaubt keine Statusabfrage für vergangene Zeitpunkte
Zertifikat könnte zum Zeitpunkt der Signaturerzeugung suspendiert
gewesen sein
133 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Zertifikate und PKI-Systeme
CMP - Certificate Management Protocol
Merkmale
legt Nachrichtenformate für PKI-Management fest, z.B.
Zertifizierungsanforderung und -antwort
Revozierungsanforderung und -antwort
festgelegt in RFC 2510
134 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Zertifikate und PKI-Systeme
Probleme der Zertifikatsverwaltung
Topologie?
Netz des Vertrauens
Hierarchie
Wald
Online- oder Offline-Prüfung eines Zertifikats
Aktualität
Netzlast, Prüfungsdauer
Revozierungsgründe
zertifiziertes Attribut wird ungültig
Signaturschlüssel wird kompromittiert
Schlüssel der CA wird kompromittiert
Revozierungsprobleme
Zeitverzögerung, insbesondere bei Offline-Prüfung
Größe der Revozierungsliste
Partitionierung
inkrementelle Aktualisierungsprotokolle
135 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Identitätsmanagement, Single Sign-On und SAML
SOA und Single Sign-On
Wikipedia:
Eine Einmalanmeldung bzw. Single Sign-On (kurz SSO) bedeutet, dass
ein Benutzer nach einer einmaligen Authentisierung auf alle Rechner und
Dienste, für die er berechtigt ist, zugreifen kann, ohne sich jedes Mal neu
anmelden zu müssen.
Anwendungsszenarien
SSO ermöglicht komfortables Surfen im Web
SSO ermöglicht prozessfähige SOA:
Service-Operationen erfordern Autorisierung
Autorisierung setzt Authentisierung voraus
Automatisierte Prozesse sollen ohne wiederholte interaktive
Authentisierung ablaufen
136 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Identitätsmanagement, Single Sign-On und SAML
Identitätsmanagement: Grundbegriffe
ITU Recommendation X.1252: „Baseline identity management terms and definitions“
Entity (Entität)
„Something that has separate and distinct existence and that can be identified in
context.“ (Person, Organisation, Anwendungsprogramm, . . . )
Identity (Identität)
„A representation of an entity in the form of one or more attributes that allow the
entity or entities to be sufficiently distinguished within context.“
(Name+Geburtsdatum, E-Mail-Adresse, URL)
Authentication (Authentisierung)
„A process to achieve sufficient confidence in the binding between the entity and the
presented identity.“
Aber: Authentisierung ermöglicht nicht notwendigerweise Identifikation der Entität!
137 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Identitätsmanagement, Single Sign-On und SAML
Digitales Subjekt
Eine Entität (Mensch, Organisation) hat digitale Repräsentanten
Digitales Subjekt: Digitaler Repräsentant einer Entität mit Identitätsattributen
hat eindeutigen Bezeichner
Digitale Identität
Assoziation eines digitalen Subjekts mit einer Entität
Sicherheitsdomäne
Bereich mit zentralisiertem Identitätsmanagement
flach oder hierarchisch
Single Sign-On
assoziiert unterschiedliche digitale Subjekte mit derselben Entität
reduziert interaktive Authentisierung
unterstützt Sicherheitsdomänen-übergreifende automatisierte Prozessservices
138 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Identitätsmanagement, Single Sign-On und SAML
Föderation
Gruppe von Systembetreibern, i.d.R. mehrere Unternehmen
kooperatives, domänenübergreifendes Identitätsmanagement
Webbrowser Single Sign-On (Web SSO)
SSO beim „Surfen“
Kontext: Internet, Unternehmen, Föderation
Enterprise SSO (ESSO)
Dezentrale Sicherheitsdomänen
SSO auch für nicht-interaktive Anwendungs-Szenarien (z.B. Webservices)
139 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Identitätsmanagement, Single Sign-On und SAML
Identitätsmanagement
Basisfunktionen
Identitäts-Lebenszyklus: Erzeugung, Modifikation, Suspendierung, Terminierung,
Archivierung von Identitäten
Authentisierungsmechanismen bereitstellen
Verwaltung von kontextrelevanten Attributen
(Rollen, Zugriffrechte, . . . )
Prozessorientierte Funktionen
Geschäftsprozessunterstützung
Zugriff auf Prozesse und Ressourcen kontrollieren
Nichtabstreitbarkeit gewährleisten
Identifikation von Personen ermöglichen oder verhindern
Mitarbeiter-Provisionierung
Single Sign-On, Single Sign-Off, Föderierte Identität
140 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Identitätsmanagement, Single Sign-On und SAML
Identität und Benutzerkonten
141 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
Szenario: Single Sign-On im Portal
142 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
Rollen: Identity Provider und Service Provider
143 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
Was sind „Identitäts-bezogene Informationen?“
144 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
Was sind „Identitäts-bezogene Informationen?“
145 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
Was sind „Identitäts-bezogene Informationen?“
146 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
Was sind „Identitäts-bezogene Informationen?“
147 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
Was sind „Identitäts-bezogene Informationen?“
148 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
Szenario „IdP initiiert SSO“
149 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
Szenario „SP initiiert SSO“
150 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
Szenario „SP initiiert SSO“ mit IdP-Lokalisierung
151 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
SSO und Sicherheitsdomänen
152 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO Szenarien
„Föderierte Identität“
Domänen-übergreifende Verarbeitung von Identitäts-Information:
Verteilte Speicherung und Verwaltung
Dynamischer Austausch
Delegation der Verarbeitung
Mehr als ESSO
Verbund mit kooperierenden Partnern, Verträge
Dynamische IdP-Entdeckung
Hosting-Problematik: Id-Management-Provider?
153 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO und SOA
SSO in einer SOA
(„Prozessfähige SOA“ nach Josuttis)
154 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO und SOA
SSO in einer SOA
(„Prozessfähige SOA“ nach Josuttis)
155 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SSO und SOA
Wozu Identitätsmanagement?
Nutzer
mehr Sicherheit
mehr Komfort
Service Provider
Aufwandsreduktion durch Delegation der Benutzerverwaltung
Bessere Servicequalität
mehr Sicherheit
Föderation
Vollintegriertes föderatives Serviceangebot (Portal, SOA, . . . )
156 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
SAML - Security Assertion Markup Language
Rahmenwerk für Austausch von Sicherheits-Informationen
Verantwortlich: OASIS Security Services TC
seit 2000, aktuelle Version: 2.0, Web: http://saml.xml.org
Ideengeber zu SAML 2.0: Liberty Alliance Project (heute Kantara)
eingebettet in WS-Security, unabhängig davon nutzbar
breite Unterstützung durch Industrie
Info: http://docs.oasis-open.org/security/saml/v2.0
157 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
SAML-Begriffe
Rollen
SAML Authority, Asserting Party (AP): Identity Provider
Relying Party (RP): Service Provider
SAML-Requestor/Responder: Rollen in einer SAML-Konversation
SAML-Assertion
Paket mit Aussagen des Systems (SAML Authority) über ein Subjekt
Authentication Assertion: Subjekt hat sich authentisiert
Attribute Assertion: Subjekt hat (beliebige) Attribute (z.B. Rollen)
Authorization Decision: Entscheidung über Zugriffserlaubnis
Digital signiert, bei Bedarf verschlüsselt
158 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
SAML-Begriffe
Name Identifier
eindeutiger Bezeichner für Subjekt oder AP
Namensräume für Föderationen / Qualifizierte Bezeichner
Authentisierungskontext
Zusatzinformationen über verwendete Authentisierungstechniken
Viele vodefinierte Kontextklassen, z.B. Internetzugriff mit Passwort,
X.509, Kerberos, Mobilfunkzugriff mit PIN, . . .
159 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
SAML-Bausteine
160 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
SAML-Architektur
Quelle: Maler, Drummond: „The Venn of Identity“, IEEE SECURITY & PRIVACY 2008, S. 16ff
161 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
SAML-Profile
162 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
SAML Bindings für alle Anwendungsfälle
Ein Binding standardisiert die Abwicklung einer
SAML-Konversation auf der Transportebene
Problem
SAML-Requestor und SAML-Responder müssen in bestimmten
Anwendungsfällen über Vermittler kommunizieren
Beispiel:
Client kommuniziert mit SP und IdP
SAML-Dialog zwischen SP und IdP muss vom Client vermittelt
werden
„Primitiver“ Client (Webbrowser) hat nur beschränkte
Vermittlungsfähigkeiten!
163 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
Client als Vermittler im SAML-Dialog
164 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
SAML-Konversation zwischen SOAP Webservices
SAML Binding: SOAP über HTTP
SAML-Nachrichten als Rumpf von SOAP-Nachrichten
SAML-Konversation mit einfachem Webbrowser als Vermittler
Problem: Webbrowser als SAML-Vermittler?
Lösungen:
SAML HTTP-Redirect Binding
HTTP-Proxy übernimmt SAML-Anteil
SAML-Konversation mit „aufgemotztem“ Client
„Enhanced Client“: leichtgewichtige SAML-Unterstützung
(Browser-Plugin)
PAOS Binding anstelle von HTTP-Redirect verwendbar
165 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
PAOS Binding (Reverse SOAP)
Quelle: OASIS SAML 2.0 Spezifikation
166 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
HTTP Redirect Binding
Vermittlung des SAML-Dialogs durch Webbrowser
SAML-Nachrichten werden im URL codiert
Client wird über HTTP-Redirects zum SAML Dialogpartner
weitergeleitet
Ende-zu-Ende-Sicherheit nötig!
167 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
HTTP Redirect Binding
Quelle: OASIS SAML 2.0 Spezifikation
168 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
HTTP POST Binding
Vermittlung des SAML-Dialogs durch Webbrowser
SAML-Nachricht ist in verstecktem Formularfeld codiert
Formularübermittlung via HTTP-POST
SAML-Dialogschritte können vor dem Client versteckt werden:
Javascript „onload“-Aktion „submit“
Verwendungsszenarien ähnlich „HTTP Redirect“
169 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
HTTP POST Binding
Quelle: OASIS SAML 2.0 Spezifikation
170 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
Artifact Binding
Probleme
HTTP Redirect: Längenbeschränkung für URLs
HTTP Redirect/POST: Client soll ggf. SAML-Nachricht nicht sehen
Lösung: Kombination mehrerer Bindings
Client vermittelt Referenz auf Nachricht (per Redirect/POST)
Artifact: Die Referenz auf die Nachricht
Nachricht selbst wird ohne Client-Vermittlung kommuniziert:
Artifact Resolution Protocol / SOAP-Binding
171 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
Enhanced Client/Proxy Profile
Quelle: OASIS SAML 2.0 Spezifikation
172 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
Implementierung von SAML
SAML 2.0 ist das weltweit am häufigsten eingesetzte
Föderierungsprotokoll
Kommerzielle Systeme (Auswahl)
Entrust IdentityGuard
IBM Tivoli Federated Identity Manager (TFIM)
Oracle/Sun Java System Federated Access Manager
Microsoft Active Directory Federation Services
Novell Access Manager 3.1
PingFederate
SAP NetWeaver Identity Management
Siemens DirX Access
173 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
Open Source Implementierungen (Auswahl)
OpenSSO (Oracle/Sun)
Lasso - Liberty Alliance Single Sign-On
(Java, Perl, Python and PHP)
OpenSAML (Internet2, für C++ and Java)
Shibboleth (Internet2)
Ping SourceID
ZXID – Open Source IdM for the Masses (C, Perl, PHP, Java)
simpleSAMLphp (für PHP, Shibboleth-kompatibel)
174 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
Beispiel für eine SAML-Assertion
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1" MinorVersion="1"
Issuer="https://idp.example.org/saml" ...>
<saml:Conditions .../>
<saml:AuthorizationDecisionStatement
Decision="Permit"
Resource="https://sp.example.com/confidential_report.html">
<saml:Subject>...</saml:Subject>
<saml:Action>read</saml:Action>
</saml:AuthorizationDecisionStatement>
</saml:Assertion>
175 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
WS-SecurityPolicy
Funktion
Formale Spezifikation der sicherheitstechnischen Anforderungen für die
Nutzung eines Dienstes
Beispiele
Anmelde- und Authentisierungsmöglichkeiten
Anforderungen an Transportsicherheit
Anforderungen an “Ende zu Ende” Nachrichtensicherheit
176 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
Beispiel für Richtlinie mit Sicherheitsanforderungen
X.509-Zertifikat, digitale Signatur und 3DES-Verschlüsselung
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext">
<wsp:All>
<wsse:SecurityToken wsp:Usage="wsp:Required">
<wsse:TokenType>wsse:X509</wsse:TokenType>
</wsse:SecurityToken>
<wsse:Integrity wsp:Usage="wsp:Required">
<wsse:Algorithm Type="wsse:AlgSignature"
URI="http://www.w3.org/2000/09/xmlenc#aes" />
</wsse:Integrity>
<wsse:Confidentiality wsp:Usage="wsp:Required">
<wsse:Algorithm Type="wsse:AlgEncryption"
URI="http://www.w3.org/2001/04/xmlenc#3des-cbc"/>
<MessageParts>
wsp:GetNodesetForNode(wsp:GetBody(.))
</MessageParts>
</wsse:Confidentiality>
</wsp:All>
</wsp:Policy>
177 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
Merkmale eines SOA Sicherheitskonzepts
Intermediäre Sicherheitsdienste
Dienst, der ausgehende Nachrichten signiert und ggf. chiffriert
Dienst für Sicherheitsfunktionen bei eingehenden Nachrichten:
Dechiffrierung, Integritätsprüfung, Absenderauthentisierung,
Berechtigungsprüfung, Erzeugung eines Absende-Nachweises
Vorteile
geschäftsprozessunabhängig und gut wiederverwendbar
Isolation: Policy-Änderungen betreffen nur den Sicherheitsdienst
Sicherheits-Proxy für eingehende Nachrichten könnte sämtliche
Sicherheitsheader vor der Weiterleitung entfernen. Sicherheitsapekte
hinter dem Proxy wären dann völlig versteckt. (Nutzen?)
178 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
SAML
Sicherheitsarchitektur für komplexere Anwendungsfälle
Einbindung von PKI Systemen oder Kerberos
Sicherheitspolicy-Verwaltung
SSO-Systeme
Firewall-Architektur?
Prinzip: vertrauenswürdige Zone vom unsicheren Netz abschotten
durch intermediären Security-Service realisierbar
nicht in allen Anwendungsfällen sinnvoll. Kriterien?
179 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Fazit zur Sicherheit von Webservices
Fazit
Sicherheitskonzepte auf unterschiedlichen Protokollschichten
Auf XML- und WS-Ebene fortgeschrittene Sicherheitskonzepte
für alle Anwendungsfälle
WS-Policy ermöglicht zentrale Verwaltung von
Sicherheitsrichtlinien
Trennung der Sicherheitsaspektevon der Kernfunktionalität
der Geschäftsprozesse
SOAP selbst hat keine („fest verdrahteten“)
Sicherheitskonzepte
180 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Fazit zur Sicherheit von Webservices
Fallbeispiel
TLS hat für alle Geschäftsdokument-Nachrichten folgende
Security-Richtlinie:
Alle Geldbeträge innerhalb der Nachricht sind zu verschlüsseln
Jede Rechnung an TLS mit einem Betrag von über $30000 ist
digital zu signieren
RailCO verwendet in seinem InvoiceSubmission-Dienst
XML Encryption für die Verschlüsselung der Geldbeträge
XML Signature für die digitale Unterschrift
181 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Fazit zur Sicherheit von Webservices
Fallbeispiel: Authentisierung
<Envelope
xmlns="http://www.w3.org/2003/05/soap-envelope">
<Header>
<wsse:Security xmlns:wsse=
"http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:UsernameToken>
<wsse:Username>
rco-3342
</wsse:Username>
<wsse:Password Type="wsse:PasswordDigest">
93292348347
</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</Header>
<Body>
...
</Body>
</Envelope>
182 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Fazit zur Sicherheit von Webservices
Fallbeispiel: Single Sign-On mit SAML
<Envelope ...
<Header>
<wsse:Security xmlns:wsse=
"http://schemas.xmlsoap.org/ws/2002/12/secext">
<saml:Assertion xmlns:saml="..."...>
<saml:Conditions ...>
<saml:AuthorizationDecisionStatement
Decision="Permit"
Resource="http://www.xmltc.com/tls/...">
<saml:Actions>
<saml:Action>
Execute
</saml:Action>
</saml:Actions>
...
</saml:AuthorizationDecisionStatement>
</wsse:Security>
</Header> ...
183 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Fazit zur Sicherheit von Webservices
Fallbeispiel: Geldbeträge mit Verschlüsselung
<InvoiceType>
<Number>
2322
</Number>
<EncryptedData
xmlns="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Element">
<CipherData>
<CipherValue>
R5J7UUI78
</CipherValue>
</CipherData>
</EncryptedData>
<Date>
07.16.05
</Date>
</InvoiceType>
184 / 259
Serviceorientierte Architekturen
Sicherheit von Webservices
Fazit zur Sicherheit von Webservices
Fallbeispiel: Digitale Signatur
<Envelope ...>
<Header>
<wsse:Security xmlns:wsse=
"http://schemas.xmlsoap.org/ws/2002/12/secext">
<Signature Id="RailCo333" xmlns=
"http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm=
"http://www.w3.org/TR/2001/
REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm=
"http://www.w3.org/2000/09/
xmldsig#dsa-sha1"/>
<Reference URI=
"http://www.w3.org/TR/2000/
REC-xhtml1-20000126/">
<DigestMethod Algorithm=
"http://www.w3.org/2000/09/
xmldsig#sha1"/>
<DigestValue>
LLSFK032093548=
</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
9879DFSS3=
</SignatureValue>
<KeyInfo>
...
</KeyInfo>
</Signature>
Serviceorientierte Architekturen
</wsse:Security>
Geschäftsprozessmodellierung
</Header>
<Body>
Terminologie
...invoice document with total exceeding $30,000...
</Body>
</Envelope>
185 / 259
Geschäftsprozessmodellierung: Terminologie
Geschäftsprozessmanagement: Maßnahmen zur Verwaltung
Identifikation der Prozesse
Planung, Modellierung, Implementierung
Dokumentation
Steuerung, Überwachung
Optimierung
Geschäftsprozessmodellierung
Ablauf modellieren
Entscheidungspunkte, Bedingungen und auslösende Ereignisse
Kontext
Ressourcen
186 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Terminologie
Geschäftsprozess vs. Workflow
oft synonym gebraucht
Geschäftsprozess meint dagegen oft eine eher abstrakte,
strategische, kundenbezogene Sicht (Was passiert?)
Workflow meint oft eine eher detaillierte, technische,
dokumentenorientierte Sicht (Wie passiert es?)
187 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Modellierung
Beispiel für ein Ebenenmodell für Geschäftsprozesse
188 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Modellierung
Beispiel für Geschäftsprozessmodell
(aus Josuttis: SOA in der Praxis)
189 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Modellierung
Beispiel für Prozesslandkarte
(aus Wikipedia: Geschäftsprozessmodellierung)
190 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Modellierung
Modelle für Geschäftsprozesse
Ziele der Modellierung
Abstraktion für besseres Verständnis des Prozesses
Modell als Dokumentation
Modell als Basis für die Kommunikation zwischen Betriebswirten
und Informatikern
Modell als Basis für die Implementierung
Ausführbares Modell
191 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Modellierung
Standards für Modellierung (Auswahl)
BPMN – Business Process Modelling Notation: Graphische
Modellierung
BPEL – Business Process Execution Language: Ausführbare
XML-basierte Spezifikationssprache
EPK (EPC) Ereignis-gesteuerte Prozessketten (Event-driven process
chains)/ Teil des ebXML-Standards
UML: Use-Case-Diagramme, Sequenzdiagramme,
Aktivitätsdiagramme
XPDL: XML Process Definition Language
WS-CDL: Webservice Choreography Definition Language
192 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Modellierung
Historie einiger Modellierungsstandards
(aus Wikipedia: BPMN)
193 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPEL
WS-BPEL – Business Process Execution Language
Merkmale
XML-basierter OASIS-Standard: aktuell BPEL 2.0
Grundlage: Orchestrierung von Webservices auf Modellebene
Zentrale Kontrollinstanz steuert alle Aktivitäten
Kompositionsprinzip: Kontrollinstanz ist selbst Webservice
Geschäftsprozesse ausführbar mittels BPEL-Engine
Beteiligte am Prozess sind nur Webservices
keine grafische Notation
Erweiterungen:
BPELJ (Erweiterung zur Einbettung von Java-Code)
BPEL4People (Erweiterung zur Einbeziehung menschlicher
Interaktion)
194 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPEL
BPEL Historie
2002 Urfassung: BPEL4WS 1.0
Zusammenführung und Weiterentwicklung von “Web Services
Flow Language” von IBM und XLANG von Microsoft
2003 Einreichung bei OASIS
2004 Neue Namenskonvention: BPEL4WS wird WS-BPEL
2007 Standardisierungsprozess abgeschlossen: WS-BPEL 2.0
Aktuelle Version
inkompatibel zu Version 1.1
195 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPEL
Beispiele für BPEL-Engines
BPEL Engines
ActiveVOS (proprietär)
Apache ODE (Open Source)
IBM Websphere Process Server (proprietär)
JBoss jBPM (Open Source)
Microsoft BizTalk Server (proprietär)
OW2 Orchestra (Open Source)
Oracle BPEL Process Manager (proprietär)
SAP Exchange Infrastructure (proprietär)
196 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPEL
BPEL Beispiel-Skelett
<process name="TimesheetSubmissionProcess"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
...>
<partnerLinks>
...
Rollen der Services im Prozess
</partnerLinks>
<variables>
<variable name="..." messageType="..."/>
...
</variables>
<sequence>
<receive ... />
Nachricht empfangen
<assign ... />
Daten zwischenspeichern
<invoke ... />
anderen Service aufrufen
...
<reply
... />
Ende der Operation, Antwortnachricht senden
</sequence>
...
</process>
197 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPEL
PartnerLink-Beispiel
</partnerLinks>
<partnerLink name="client"
partnerLinkType="tns:TimesheetSubmissionType"
myRole="TimesheetSubmissionServiceProvider"/>
<partnerLink name="Invoice"
partnerLinkType="inv:InvoiceType"
partnerRole="InvoiceServiceProvider"/>
<partnerLink name="Timesheet"
partnerLinkType="tst:TimesheetType"
partnerRole="TimesheetServiceProvider"/>
<partnerLink name="Employee"
partnerLinkType="emp:EmployeeType"
partnerRole="EmployeeServiceProvider"/>
<partnerLink name="Notification"
partnerLinkType="not:NotificationType"
partnerRole="NotificationServiceProvider"/>
</partnerLinks>
pro Webservice ein PartnerLink
für die Rolle als Serviceprovider: myRole=
für die Rolle als Servicenutzer: partnerRole=
partnerLinkType: Name der abstrakten Schnittstelle im
WSDL-Dokument
198 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPEL
Invoke-Beispiel
<invoke name="ValidateWeeklyHours"
partnerLink="Employee"
portType="emp:EmployeeInterface"
operation="GetWeeklyHoursLimit"
inputVariable="EmployeeHoursRequest"
outputVariable="EmployeeHoursResponse"/>
199 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPEL
Probleme bei der BPEL-Anwendung
XML-Ebene für BWL-Fachexperten ungeeignet
Abbildung von graphischen Modellen (z.B. BPMN) auf BPEL
sehr schwierig
Orchestrierungsansatz erst sinnvoll, wenn schon genügend
viele Services vorhanden sind
Nichtfunktionale Anforderungen (z.B. Security) werden nicht
modelliert
Fehlerbehandlung führt zu sehr komplexen Modellen
200 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
BPMN: Business Process Modelling Language
Merkmale
Grafische Spezifikationssprache zur Modellierung und
Dokumentation von Geschäftsprozessen und Arbeitsabläufen
Brücke zwischen Design und Implementierung
Ergebnis-Diagramm: Business Process Diagramm (BPD)
201 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Historie und Versionen
Historie
2002: erste BPMN-Spezifikation / Stephen White (IBM)
2004: Business Process Management Initiative (BPMI)
veröffentlicht den Standard
2005/2006: Fusion von BPMI und Object Management Group
(OMG)
seit 2006: BPMN als OMG Standard (neben UML, etc.)
Versionen
veraltete Versionen: 1.0 (2004), 1.1 (2008)
Version 1.2 (Mai 2009) wird vielfach noch verwendet
aktuelle Version: 2.0 (Januar 2011)
202 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Beispiel für ein BPMN-Diagramm: Stellenausschreibung
(Thomas Allweyer, BPMN-Buch.de)
203 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Grundelemente
204 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
(ARIS
Express Kollaborationsdiagramm-Beispiel)
205 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Teilnehmer: Pools und Lanes
206 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Aktivitäten
207 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Gateways
208 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
209 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
210 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
211 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
212 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
213 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
214 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Ereignisse
215 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Beispiel: Throwing Event / Catching Event
216 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Verbindende Objekte (Konnektoren)
217 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Sequenzflüsse
218 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Nachrichtenflüsse
219 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Assoziationen
220 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
BPMN
Artefakte: Annotationen, Datenobjekte, Gruppen
221 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Probleme beim Geschäftsprozessmanagement
Verantwortlichkeiten für Prozesse und Prozess-Services
Unternehmensebene
Organisationsstruktur meist nicht prozessorientiert (Wie sonst?)
Geschäftsprozesse oft Organisationseinheits-übergreifend (z.B.
Abteilungs-übergreifend)
Wichtige Kernprozesse manchmal Unternehmens-übergreifend:
Beispiel: Lieferketten („supply-chain management“)
Problem: Wer ist für Geschäftsprozess-Management verantwortlich?
IT-Organisation und Services
IT-Organisation meist nicht serviceorientiert
Prozess- und Composed Services oft Applikations-übergreifend
Prozess-Services oft Unternehmens-übergreifend
Problem: Wer ist für Service-Management verantwortlich?
222 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Geschäftsprozesse und SOA-Architektur
Logisches Architekturmodell
(aus Josuttis: SOA ind der Praxis)
223 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Geschäftsprozesse und SOA-Architektur
Gemischtes Architekturmodell
(aus Josuttis: SOA ind der Praxis)
224 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Geschäftsprozesse und SOA-Architektur
Technisches Architekturmodell
(aus Josuttis: SOA ind der Praxis)
225 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Geschäftsprozesse und SOA-Architektur
Services und Frontends
Services sind passiv
Services werden meist durch Benutzerinteraktion ausgelöst
direkt: Benutzer startet Service mittels Frontend
indirekt: Service delegiert Teilaufgabe an anderen Service
Koexistent verschiedener Frontends (Kanäle)
Thin-Client/Web-Frontends (oft separat für Desktop und mobile
Geräte)
Backoffice-Frontends (klassische Desktop-Applikationen)
Call-Center Smart-Client
Interaktive Schritte eines Service-Aufrufs können über verschiedene
Frontends verteilt sein!
226 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Geschäftsprozesse und SOA-Architektur
Beispiel: Kunde ändert seinen DSL-Vertrag
(Bandbreitenerhöhung)
Typischer Verlauf
Kunde beschafft sich Vertragsstatus und Wechseloptionen
Frontend: Webbrowser-Zugriff auf das Kundencenter des Providers
Composed Service zur Bestimmung der Wechseloptionen auf der
Basis komplexer Geschäftsregeln erforderlich
Call-Center kann bei Problemen die Kontrolle übernehmen
(Auslöser: Kunde ruft an oder via Chat-Funktion im Web-Frontend )
Backoffice-Frontend wird für die Problembehandlung verwendet
227 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Geschäftsprozesse und SOA-Architektur
Call-Center-Frontend
zeigt dem Agenten Kundenansicht und relevante Kundendaten
Zugriff auf alle Kundenoperationen
ggf. Zusatzoperationen verfügbar, z.B.
Freischaltung von zusätzlichen Wechseloptionen
Konfiguration individueller Vertragsmerkmale
Backoffice-Frontend ermöglicht manuellen Eingriff
Einsicht und manuelle Änderung des Vertragsstatus
Manuelle Konfiguration individueller Vertragsmerkmale
Verwaltung der Kommunikationsverlaufs
aufgezeichnete Telefonate
Abruf eingescannter Briefe des Kunden
Kundenkorrespondenz im E-Mail-Archiv
228 / 259
Serviceorientierte Architekturen
Geschäftsprozessmodellierung
Geschäftsprozesse und SOA-Architektur
Mögliche Probleme mit SOA-Frontends
Parallelnutzung mehrerer Frontends: Prozessidentifikation?
Beispiel: Call-Center-Agent benutzt Thin-Client und
Backoffice-Frontend für die Kundendaten
Kundendaten automatisch in das zweite Frontend laden?
Unterschiedliche Identifikations-Schlüssel (z.B. Mailadresse für
Web-Frontend, Kundennummer für Backoffice)
Management zeitgesteuerter Zukunftsaktivitäten
Beispiel: Geschäftsprozess „Vertragskündigung“
Änderung erst zu einem zukünftigen Zeitpunkt wirksam
CRUD-Backend unterstützt nur sofortige Änderungen
Softwarekomponente zur Zeit-gesteuerten Ausführung von
Operationen nötig
Validerung der Daten
Vollständig Validierung im Frontend nicht möglich (Warum?)
Vorvalidierung durch Frontends sinnvoll?
Redundante Validerung in Front- und Backend?
229 / 259
Serviceorientierte Architekturen
Webservices und Java
JAXB
Webservices und Java
JAXB: Java Architecture for XML Binding
Kern: Typ-Mapping zwischen den Typsystemen von Java und der
XML Schema Definition Language
Standard-Mapping
Java-Typ → XML-Schema-Typ
XML-Schema-Typ → Java-Typ
Standard-Mapping durch benutzerdefinierte Zuordnungen
modifizierbar
Mapping ermöglicht automatische Generierung von Java-Klassen
aus Schema-Definitionen und umgekehrt
JAXB ist der Kernbestandteil von JAX-WS
230 / 259
Serviceorientierte Architekturen
Webservices und Java
JAXB
Abweichungen vom Standard-Mapping
Probleme
Java- und XML-Typsysteme komplex und sehr unterschiedlich
Sehr unterschiedliche Basis- und Container-Typen
XML-Restrictions und Extensions kaum auf Java abbildbar
Völlig unterschiedliche Vererbungskonzepte
Einfache Java-Attribute können in XML durch Elemente oder
Attribute repräsentiert werden
231 / 259
Serviceorientierte Architekturen
Webservices und Java
JAXB
JAXB Annotationen
Annotationen für Java und XML
Java→XML-Mapping modifizieren: JAXB-Java-Annotationen
XML→Java-Mapping modifizieren: JAXB-Schema-Annotationen
Einschränkungen der JAXB-Annotationen
Standard-Mapping nur beschränkt modifizierbar. Beispiele:
Umbenennungen von Datenfeldern
XML-Basistyp zum Java-Basistyp zuordnen
Java-Attribut wahlweise auf XML-Unterelement oder XML-Attribut
abbilden
XML-Typ wahlweise auf Java-Klasse oder Java-Interface abbilden
Praxisproblem: Flache Struktur (z.B. Adresse mit einfachen Feldern)
nicht mit komplexer hierarchischer Struktur (z.B. Adresse mit
strukturierter Telefonnummer) assoziierbar
232 / 259
Serviceorientierte Architekturen
Webservices und Java
JAXB
Tools
JAXB („Binding Compiler“)
Schemagenerator erzeugt aus Java-Klasse ein XML-Schema (z.B.
schemagen)
Schemacompiler erzeugt aus XML-Schema Java-Klassen (z.B. xjc)
Basis der Generierung: Standard-Mapping und JAXB-Annotationen
im Quelltext
SoapUI
Testumgebung für SOAP-basierte Webservices
http://www.soapui.org
Open Source
233 / 259
Serviceorientierte Architekturen
Webservices und Java
RESTful Webservices
Webservices und Java
RESTful Webservices
JAX-RS: The Java API for RESTful Web Services
JAX-RS definiert in JSR-311 (Version 1) und JSR-339 (Version 2.0)
Referenzimplementierung: Jersey (Open Source,
http://jersey.java.net)
Webservice-Implementierung: POJO-Klasse/Interface (“Plain Old
Java Object”) mit Annotationen
mit JAXB automatisches Mapping zwischen Java-Klassen und XML
oder JSON
Server: Servlet-Container (z.B. Apache Tomcat)
Java-Client:
Jersey Client-API
Nützliche Bibliothek: Apache HTTP-Client
(http://hc.apache.org/httpcomponents-client-ga/index.html)
234 / 259
Serviceorientierte Architekturen
Webservices und Java
RESTful Webservices
Java-Annotationen für REST (Auswahl)
@PATH(...)
@POST
@GET
@PUT
@DELETE
@Produces(...)
@Consumes(...)
@PathParam(...)
Webservice-URL (relativ zum Basis-URL)
Methode für POST-Request
Methode für GET-Request
Methode für PUT-Request
Methode für DELETE-Request
mögliche MIME-Typen für Antwortnachricht
mögliche MIME-Typen für Request
Zur Injektion von URL-Anteilen in die Parameter
235 / 259
Serviceorientierte Architekturen
Webservices und Java
RESTful Webservices
REST-Beispiel mit Unterstützung verschiedener MIME-Typen
package de.thm.mni.soa.rest.bsp01;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
@Path("/helloworld")
public class HelloWorld {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String plainTextHelloWorld() {
return "Hello, world";
}
@GET
@Produces(MediaType.TEXT_XML)
public String xmlHelloWorld() {
return "<?xml version=\"1.0\"?><hello>Hello, world</hello>";
}
@GET
@Produces(MediaType.TEXT_HTML)
public String htmlHelloWorld() {
return "<html><head><title>Hello, world</title></head>" +
"<body> Hello, world </body></html>";
}
}
236 / 259
Serviceorientierte Architekturen
Webservices und Java
RESTful Webservices
Client-Beispiel
package de.thm.mni.soa.restclient;
import java.net.URI;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.UriBuilder;
import
import
import
import
com.sun.jersey.api.client.Client;
com.sun.jersey.api.client.WebResource;
com.sun.jersey.api.client.config.ClientConfig;
com.sun.jersey.api.client.config.DefaultClientConfig;
public class RestTest {
public static void main(String[] args) {
ClientConfig config = new DefaultClientConfig();
Client client = Client.create(config);
WebResource service = client.resource(getBaseURI());
System.out.println(service.path("rest").path("helloworld").
accept(MediaType.TEXT_XML).get(String.class));
}
private static URI getBaseURI() {
return UriBuilder.
fromUri("http://localhost:8080/de.thm.mni.soa").build();
}
}
237 / 259
Serviceorientierte Architekturen
Webservices und Java
RESTful Webservices
Injektion von Pfadanteilen
...
@Path("/suche/{suchbegriff}")
public class SuchMaschine {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String suche (@PathParam("suchbegriff") String s ) {
return "leider wurde für " + s + " nichts passendes gefunden.
Bitte nicht traurig sein!";
}
}
238 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
JAX-WS
SOAP-basierte Webservices
JAX-WS: The Java API for XML-based Web Services
JAX-WS definiert in JSR-224 (Version 2)
Referenzimplementierung: Metro-Stack (Oracle/Sun), im Java JDK
ab Version 6 integriert
Webservice-Implementierung: POJO-Klasse/Interface (“Plain Old
Java Object”) mit Annotationen
mit JAXB automatisches Mapping zwischen Java-Klassen und XML
Server: Servlet-Container (z.B. Apache Tomcat) oder Java-EE
Application Server
Literatur: Mark Hansen: SOA Using Java Web Services
239 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Java-Annotationen für JAX-WS (Auswahl)
Annotationen im Paket javax.jws:
@WebService
@WebMethod
@WebParam
@WebFault
@WebResult
@SOAPBinding
@OneWay
Klasse implementiert einen Webservice
Methode ist Webservice-Operation
Parameter einer Webservice-Operation
(Exception-)Klasse implementiert SOAP-Fault
Ergebnis einer Webservice-Operation
SOAP Binding
Einweg-Nachricht
240 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Webservice-Beispiel mit optionalen Annotationen
package de.thm.mni.soa.soapws;
import javax.jws.*;
import javax.jws.soap.SOAPBinding;
@WebService(name="simpleComputations")
@SOAPBinding(style = SOAPBinding.Style.RPC)
public class Rechenkuenstler
{
@WebMethod
public Double add (double x, double y)
{ return x+y; }
@WebMethod(operationName="subtract")
public Double differenz (double x, double y)
{ return x-y; }
}
241 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Java-Client
Typische Vorgehensweise bei der Implementierung
WSDL abrufen und Zugriffsklassen dazu implementieren
Tool: “wsimport” generiert die benötigten Klassen
bei Fehlern manuelle Nachbesserung nötig
Client mit Hilfe der benötigten Zugriffsklassen implementieren
Beispiel: Der Geo-IP-Service von www.webservicex.net
wsimport -s src -p de.thm.mni.soa.ws.gen.geoipservice
http://www.webservicex.net/geoipservice.asmx?WSDL
Mit der Option „-s“ werden die Java-Sourcen gespeichert
Mit der Option „-p“ wird das Paket für die generierten Sourcen defineirt
242 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Auszug aus der WSDL-Datei
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:...
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://www.webservicex.net/">
<s:element name="GetGeoIP">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="IPAddress" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetGeoIPResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetGeoIPResult" type="tns:GeoIP" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="GeoIP">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="ReturnCode" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="IP" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="ReturnCodeDetails" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="CountryName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="CountryCode" type="s:string" />
</s:sequence>
</s:complexType>
243 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Von wsimport generiert: GeoIP.java
package de.thm.mni.soa.ws.gen.geoipservice;
import
import
import
import
javax.xml.bind.annotation.XmlAccessType;
javax.xml.bind.annotation.XmlAccessorType;
javax.xml.bind.annotation.XmlElement;
javax.xml.bind.annotation.XmlType;
/**
* <p>Java class for GeoIP complex type.
*
* <p>The following schema fragment specifies the expected content contained within this class.
*
* <pre>
* &lt;complexType name="GeoIP">
*
&lt;complexContent>
*
&lt;restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
*
&lt;sequence>
*
&lt;element name="ReturnCode" type=...
*
&lt;element name="IP" type=...
*
&lt;element name="ReturnCodeDetails" type=...
*
&lt;element name="CountryName" type=...
*
&lt;element name="CountryCode" type=...
*
&lt;/sequence>
*
&lt;/restriction>
*
&lt;/complexContent>
* &lt;/complexType>
* </pre>
*/
244 / 259
...
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
GeoIP.java: Forts.
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "GeoIP", propOrder = {
"returnCode",
"ip",
"returnCodeDetails",
"countryName",
"countryCode"
})
public class GeoIP {
@XmlElement(name = "ReturnCode")
protected int returnCode;
@XmlElement(name = "IP")
protected String ip;
@XmlElement(name = "ReturnCodeDetails")
protected String returnCodeDetails;
@XmlElement(name = "CountryName")
protected String countryName;
@XmlElement(name = "CountryCode")
protected String countryCode;
...
public String getCountryCode() { return countryCode; }
public void setCountryCode(String value) { this.countryCode = value; }
}
245 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Von wsimport generiert: GeoIPService.java
package de.thm.mni.soa.ws.gen.geoipservice;
import
import
import
import
import
import
import
import
java.net.MalformedURLException;
java.net.URL;
java.util.logging.Logger;
javax.xml.namespace.QName;
javax.xml.ws.Service;
javax.xml.ws.WebEndpoint;
javax.xml.ws.WebServiceClient;
javax.xml.ws.WebServiceFeature;
/**
* This class was generated by the JAX-WS RI.
* JAX-WS RI 2.1.6
* Generated source version: 2.1
*
*/
@WebServiceClient(
name = "GeoIPService",
targetNamespace = "http://www.webservicex.net/",
wsdlLocation = "http://www.webservicex.net/geoipservice.asmx?WSDL")
public class GeoIPService extends Service {
...
246 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
GeoIPService.java (Forts.)
public class GeoIPService extends Service {
public GeoIPService(URL wsdlLocation, QName serviceName) {
super(wsdlLocation, serviceName);
}
public GeoIPService() {
super(GEOIPSERVICE_WSDL_LOCATION,
new QName("http://www.webservicex.net/", "GeoIPService"));
}
@WebEndpoint(name = "GeoIPServiceSoap")
public GeoIPServiceSoap getGeoIPServiceSoap() {
return super.getPort(new QName(
"http://www.webservicex.net/",
"GeoIPServiceSoap"), GeoIPServiceSoap.class);
}
...
Client
package de.thm.mni.soa.ws.gen.geoipservice;
public class GeoIPServiceSoapClient {
public static void main( String[] args ) {
GeoIPServiceSoap ipService = new GeoIPService().getGeoIPServiceSoap();
GeoIP geoIP = ipService.getGeoIP( "212.201.18.26" );
System.out.println( "IP="212.201.18.26, Land="+geoIP.getCountryCode());
}
}
247 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
JAXB und JAX-WS
Marshalling
Zu einem Java-Objekt wird ein korrespondierendes XML-Element
erzeugt und serialisiert.
Unmarshalling: Deserialisierung eines XML-Elements und Erzeugung
eines korrespondierenden Java Objekts
Code für Marshalling (Unmarshalling) auf Basis von JAXB
generierbar
Automatisches Marshalling und Unmarshalling ist die Basis des
JAX-WS Laufzeitsystems
248 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Ansätze zur Webservice-Implementierung
„Contract First“ (auch „Top Down“)
WSDL und XML Schemadaten werden zuerst entwickelt
mit ein WS-Tool werden mit Annotationen versehene
Java-Artefakte generiert:
Eine Klasse pro komplexen XML-Typ
Eine Fabrik, die für jeden komplexem Typ die Objekterzeugung
ermöglicht
Ein Endpunkt-Interface
Eine Wrapper-Klasse für den Webservice
Vorteile? Nachteile? Anwendungs-Szenarien?
249 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
„Java First“ (auch „Bottom-Up“)
Vorhandener Java-Code wird (von Hand) mit Annotationen versehen
Mit ein WS-Tool werden Artefakte generiert:
XML-Schema-Dateien
Die WSDL-Datei
Java-Klassen (Endpunkte / Proxy-Klassen für Client)
Automatisches Deployment und Registrierung der Endpunkte
Vorteile? Nachteile? Anwendungs-Szenarien?
250 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Praxisproblem: Nutzung vorhandener Java- und
XML-Definitionen
Beispiel-Szenario
In Java implementierte Software verarbeitet Rechnungen. Komplexe
Klasse „Rechnung“ wird in mehreren Geschäftsprozessen verwendet.
Für elektronischen Austausch von Rechnungen mit einem Kunden
wird ein gemeinsames Rechnungsformat als XML-Schema
verwendet.
Problem: Das Austauschformat passt nicht mit der vorhandenen
Java-Klasse zusammen.
251 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Lösungsansätze bei Typinkompatibilität (alternativ)
1
Falls XML- und Java-Typen sehr ähnlich sind:
Mit JAXB-Annotationen im Java-Code dafür sorgen, dass der
Schemagenerator das vorhandene Schema generiert. Oder:
Mit JAXB-Annotationen im XML-Schema dafür sorgen, dass
der Schemacompiler die vorhandene Java-Klasse generiert.
2
Einen Typadapter in Java programmieren
(kombinierbar mit XML-Annotationen)
3
Einen Typadapter in XSLT programmieren
(kombinierbar mit Java-Annotationen)
4
In Java XMLAdapter -Klasse(n) programmieren. Damit kann das
JAXB-Mapping beliebig modifiziert werden.
Vorteil: Weniger Programmieraufwand, falls für viele Typen
automatisch generierter Code verwendet werden kann.
252 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Java-Typadapter
Konzept
aus Schema Java-Klasse(n)
generieren
Java-Adapter für die Übertragung
der Attribute programmieren
Optional: Mit
Schema-Annotationen die
generierte Java-Klasse besser an
vorhandene Klasse anpassen
Wertung
Nachteil: Für komplexe Typen
umfangreicher Code
Vorteil: Einfache Programmlogik
(get- und set-Methoden)
Beispiel
rechnung.xsd
Rechnung.java
XMLAnnotationen
hinzufügen
rechnung-annotated.xsd
SchemaCompiler
RechnungExt.java
Java-Adapter
253 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
XSLT-Adapter
Konzept
aus Java-Klasse ein Schema
generieren
XSLT-Transformation
Übertragung der XML-Elemente
und -Attribute programmieren
Optional: Java-Klasse mit
Annotationen ergänzen, damit
generiertes XML-Schema besser
zum vorhandenen Schema passt
Beispiel
rechnung.xsd
JAXBAnnotationen
hinzufügen
Rechnung.java
(mit Annotationen)
SchemaGenerator
Wertung
Vorteil: XSLT meist kompakt, für
Experten schnell änderbar
Nachteil: Nur wenige Entwickler
kennen sich mit XSLT gut aus
Rechnung.java
XSLTTransformation
rechnungGen.xsd
254 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Java XMLAdapter -Klassen
XMLAdapter<ValueType,BoundType> definiert eine
bidirektionale Transformation zwischen zwei Java-Klassen :
BoundType definiert die „interne“ Repräsentation, die man
nicht direkt mit eine XML-Typ assoziieren will oder kann
ValueType ist die „externe“ Repräsentation und wird von
JAXB einem XML-Typ zugeordnet
Das Mapping zwischen ValueType und BoundType wird frei
programmiert: Methoden marshal und unmarshal
255 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Verwendung von XMLAdapter-Klassen
Beispiel
Objekt der Klasse Rechnung sollen XML-Elementen gemäß rechung.xsd
zugeordnet werden
Für das Attribut rechnungsadresse gibt es ein Kompatibilitätsproblem:
Intern verwendete Klasse: Adresse inkompatibel mit
XML-Typ: adresse.xsd
Lösung:
Zu adresse.xsd kompatible Java-Klasse generieren: AdresseExtern
Umsetzung zwischen Adresse und AdresseExtern durch
XMLAdapter -Subklasse AdressAdapter
Durch eine Annotation an der Rechnungsadresse
(@XMLJavaTypeAdapter) wird AdressAdapter in das Marshalling
eingebunden.
256 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Komponenten einer Webservice-Middleware
Überblick
Aufrufmechanismen
Server
Client
Subsystem zur Serialisierung und Deserialisierung
Deployment-Subsystem serverseitig
257 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Aufrufmechanismen auf Serverseite
SOAP-Nachricht aus Transportcontainer entnehmen
Handler-Mechanismus für Bearbeitung der SOAP-Header
Ziel-Service bestimmen, WSDL zuordnen, WSDL-Operation
bestimmen
Java-Klasse/-Methode bestimmen (Dispatcher)
Java-Aufruf veranlassen (Parameter vom Serialisierungs-Subsystem)
Returnwert an Serialisierungs-Subsystem übergeben
WSDL-konforme SOAP-Antwortnachricht erzeugen
Antwortnachricht an Transportebene übergeben
258 / 259
Serviceorientierte Architekturen
Webservices und Java
JAX-WS
Deployment-Subsystem
Deployment der Java-Klassen
Mapping zwischen WSDL-Operationen und Java-Methoden
Serialisierungskontext bereitstellen
WSDL veröffentlichen
SOAP-Handler konfigurieren
Endpunkt-Listener konfigurieren
259 / 259
