Neue Produktivität durch Web Services RPC, WSDL und SOAP

Neue Produktivität durch Web Services
RPC, WSDL und SOAP
Neue Technologien im Internet – Seminar WS 2003 / 2004
Hendrik Jander
Thomas Puhl
Friedrich-Schiller-Universität Jena
Institut für Informatik
Motivation
?
Wie kommt meine
Applikation an die
Google-Ergebnisse ???
Nimm doch die GoogleWeb Services !!!
!
Inhalt
† Verteilte Systeme
„ RPC
„ Middleware
† Web Services
„ SOAP
„ WSDL
„ UDDI
† Implementierung .NET & Sun ONE
† Zusammenfassung & Ausblick
Verteilte Systeme
†
†
†
†
†
Ressourcen/Anwendungen kommunizieren über Netzwerk
Motivation: gemeinsame, effiziente Ressourcennutzung
Probleme
„ Heterogenität (Prozessorarchitektur, OS)
„ Nebenläufigkeit
„ getrennte Speicher
Eigenschaften
„ lose Kopplung der Systemkomponenten
„ Datenaustausch nur durch Nachrichtenversand möglich
„ Dynamik
„ Fehlertoleranz durch Redundanz erreichbar
Interaktion der Anwendungen soll transparent erfolgen
Æ RPC
Verteilte Systeme - RPC
†
Remote Procedure Call
†
†
Prozedur auf entferntem Rechner ausgeführt
Stub bildet Signatur der entfernten Prozedur lokal ab
„ verhält sich wie lokale Prozedur
„ gewährleistet Transparenz für Anwender
†
Probleme
„ unterschiedliche Datendarstellung der Systeme
„ Time-Out
„ Call-by-Value vs. Call-by-Reference
Verteilte Systeme - RPC
Client
†
†
Stub
Betriebssystem/
Laufzeitumgebung
Client−
prozess
Betriebssystem/
Laufzeitumgebung
Server
Skeleton
Stub/Skeleton
„ Konvertierung der Datenformate
„ Nachrichtenerzeugung
„ Marshalling/Unmarshalling der Parameter
OS/Laufzeitumgebung
„ Kommunikation mit Remote-Host
„ Übertragung der Nachrichten
Server−
prozess
Middleware
†
Softwarekomponenten zur Realisierung von verteilten Systemen
„ kapselt (O)RPC – Prinzip
†
†
zwischen Netzwerk - und Anwendungsschicht
gewährleistet Orts – und Verteilungstransparenz
†
Kombination aus Standards und Laufzeitumgebung
„ Standards: Serialisierung & Transport
„ Laufzeitumgebung: Umsetzung der standardisierten
Kommunikation
†
bei verteilten Objektsystemen: Objektverwaltung notwendig
Middleware - Lösungen
†
†
†
†
CORBA – Common Object Request Broker Architecture
„ Standard von OMG spezifiziert
„ herstellerunabhängig
„ sprach – und plattformunabhängig
Java RMI – Remote Method Invocation
„ inhärent plattformunabhängig
„ Nur für Java – Komponenten
DCOM – Distributed Component Object Model
„ Weiterentwicklung von COM für Netzwerke
Keine Lösung konnte sich vollständig durchsetzen
„ wegen Sprach-, Plattform-, Herstellerabhängigkeit
Æ Web Service sind neuester Ansatz zu Realisierung von MW
Inhalt
† Verteilte Systeme
„ RPC
„ Middleware
† Web Services
„ SOAP
„ WSDL
„ UDDI
† Implementierung .NET & Sun ONE
† Zusammenfassung & Ausblick
Web Services
†
Softwarekomponente stellt Funktionalität über
Standardinternetprotokolle zur Verfügung
†
historisch aus den Erfahrungen und Protokollen des
verteilten Programmierens entstanden
†
Nutzung etablierter und standardisierter Internetstandards
„ W3C, OASIS, IETF
†
XML–basiert
†
W3C schlägt Web Service–Architektur vor
Web Services Architektur
Base Technologies: XML, DTD, Schema
Komposition von
Geschäftsprozessen
Processes
Discovery, Aggregation, Choreography ...
Security
Messages
SOAP Extensions
Reliability, Correlation, Transactions, ...
Generierung der Stubs
Management
Descriptions
Web−Service Description (WSDL)
Nachrichtenaustausch
SOAP
Communications
HTTP, SMTP, FTP, ...
Transport
SOAP
† Simple Object Access Protocol
† XML-basiertes Protokoll zum Verpacken von Nachrichten
† ermöglicht Austausch typisierter Daten in verteiltem Umfeld
† Austausch unabhängig von Betriebssystem und
Programmiersprache
† ursprünglich 1998 von Microsoft entwickelt
† Entwicklung seit 2000 durch W3C koordiniert
† liegt heute in Version 1.2 vor
SOAP - Nachrichtenaufbau
† SOAP-Nachricht ist einfaches XML-Dokument
Envelope
Header
Header Block
Body
Fault
† Envelope definiert Umschlag, der
Nachricht beinhaltet
† Header gestattet Informationen
zu übertragen, die nicht direkt mit
Inhalt verknüpft sind
† Body enthält eigentliche Nachricht
† Header und Body können bel.
wohlgeformten XML-Code enthalten
† auftretende Fehler werden durch Fault-Elemente beschrieben
† bel. Codierungsstile können zur Codierung der Daten verwendet
werden
SOAP - Nachrichtenaufbau
<SOAP:Envelope
xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope">
<SOAP:Header>
<ns1:headerBlock1 xmlns:ns1="http://www.example.org/ns1">
...
</ns1:headerBlock1>
<ns2:headerBlock2 xmlns:ns2="http://www.example.org/ns2">
...
</ns2:headerBlock2>
</SOAP:Header>
<SOAP:Body>
<xyz:message xmlns:xyz="http://www.xyz.net">
...
</xyz:message>
</SOAP:Body>
</SOAP:Envelope>
SOAP - Verarbeitung
† Nachrichtenversand erfolgt entlang SOAP-Nodes im
Nachrichtenpfad (Message Path)
Absender
"initial sender"
Empfänger
"ultimate receiver"
"intermediary"
"intermediary"
† Absender = initial sender, Empfänger = ultimate receiver,
(optionale) zwischengeschaltete Knoten = intermediary
† intermediary fügen Transaktion weitere Funktionalitäten hinzu
† keine Standardmethode zur Pfadkonstruktion definiert !!!
SOAP - Verarbeitung
† Nachricht durchläuft nacheinander alle Knoten
† Knoten untersuchen, verändern und/oder löschen Headerblöcke
oder fügen neue hinzu
† Fault wird erzeugt, falls Fehler bei Verarbeitung auftritt
† optionale Attribute beschreiben Headerblöcke
„ role: bestimmt Rolle, die Block „spielt“ Æ durch Knoten
bearbeitet, die gegebene Rolle unterstützen/verstehen
„ mustUnderstand: gibt an, ob Block durch Knoten verarbeitet
werden muß
„ relay: gibt an, ob Block bei Nichtverarbeitung an nächsten
Knoten weitergeleitet werden muß
SOAP - Verarbeitung
<Envelope>
<Header>
<firstBlock role="http://www.w3.org/2003/05/soapenvelope/role/next">
...
</firstBlock>
<secondBlock role="http://www.example.org/log"
mustUnderstand="true">
...
</secondBlock>
<thirdBlock relay="true">
...
</thirdBlock>
</Header>
<Body>...</Body>
</Envelope>
SOAP - Kommunikationsmuster
† Kommunikationsmuster (Message Exchange Patterns)
„ Beschreibt Ablauf der Kommunikation zweier Partner,
„ Beziehung der ausgetauschten Nachrichten zueinander und
„ reguläres und irreguläres Ende der Interaktion
† verschiedene Muster durch Standard definiert; es lassen sich aber
beliebige Muster definieren
† Request/Response-Muster
„ besteht aus zwei SOAP-Nachrichten (Anfrage & Antwort)
† Response-Muster
„ besteht ebenfalls aus zwei Nachrichten, wobei aber nur die
Antwort als SOAP-Nachricht verpackt wird
SOAP - RPC
† SOAP bietet Möglichkeit für XML-basierten RPC (SOAP-RPC)
† Anfrage & Antwort werden als SOAP-Nachrichten versendet,
deren Format gewissen Vorgaben folgt
† Anfrage:
„ XML-Konstrukt, dessen Wurzelement der Name der
aufzurufenden Funktion ist
„ darin sind alle Aufrufparameter enthalten
† Antwort:
„ Name der Wurzelelements besteht aus Name der Funktion +
Zusatz „Response“ (per Konvention)
„ enthält alle Rückgabewerte
SOAP - RPC
<Envelope>
<Body>
<doSpellingSuggestion>
<key>00000000000000000000000000000000</key>
<phrase>britney speers</phrase>
</doSpellingSuggestion>
</Body>
</Envelope>
<Envelope>
<Body>
<doSpellingSuggestionResponse>
<return>britney spears</return>
</doSpellingSuggestionResponse>
</Body>
</Envelope>
SOAP - Transport
† SOAP setzt auf Netzwerk- und Transportschichten auf
Æ flexibel bzgl. Ort und Art des Einsatzes
† HTTP, HTTPS, FTP, TCP, SMTP, POP3, Jabber, ...
POST /search/beta2 HTTP/1.1
Host: api.google.com
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: ???
SOAPAction: "urn:GoogleSearch#doSpellingSuggestion"
<?xml version="1.0" ?>
<SOAP:Envelope xmlns:SOAP="...">
...
</SOAP:Envelope>
WSDL
†
Web Service Description Language
†
WSDL zur Generierung der Stubs
†
†
Teilaspekte werden getrennt standardisiert
die 3 Teile des Standards:
„ Core Language
(Strukturierungselemente der Sprache)
„ Message Exchange Patterns
(Kardinalität & Sequenz der Nachrichten)
„ Bindings
(Serialisierung und Transport )
WSDL - Dokumentstruktur
definitions
types
interface
operation
input
output
infault
outfault
operation
input
output
infault
outfault
endpoint
„ öffnet und definiert Namensräume
† Unterscheidung zwischen abstrakten
und konkreten Elementen
binding
service
† definitions ist das Wurzelelement
† konkrete Elemente referenzieren jeweils
abstrakte Elemente
WSDL - Types
†
†
†
definiert die im Dokument verwendeten Typen
i.d.R. Nutzung von XML Schema Definition (XSD)
primitive oder komplexe Datentypen möglich
<types>
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:GoogleSearch">
<xsd:complexType name="GoogleSearchResult">
<xsd:all>
<xsd:element name="estimateIsExact"
type="xsd:boolean"/>
...
</xsd:all>
</xsd:complexType>
</xsd:schema>
</types>
WSDL - Interface
†
†
†
†
†
beschreibt abstrakt die Schnittstelle des Web Service
definiert Menge von Operationen
Operationen sind Mengen von Nachrichten
Nachrichten werden per XML Schema definiert
Vererbung ist möglich
<interface name="GoogleSearch">
<operation name="doGoogleSearch"
pattern="http://www.w3.org/2003/11/wsdl/in-out">
<input message="ns:doGoogleSearch"
messageReference="A" />
<output message="ns:doGoogleSearchResponse"
messageReference="B" />
</operation>
...
</interface>
WSDL - Binding
†
†
†
definieren Transport - und Serialisierungsdetails
referenzieren ein Interface
sind Container für Elemente der Binding Spezifikation
<binding name=„GoogleSearchBinding" interface=„GoogleSearch">
...
<operation name=„doGoogleSearch">
...
<input messageReference="A">...</input>
<output messageReference="B">...</output>
</operation>
...
</binding>
WSDL – Service
†
†
definiert mögliche Adressen eines Services
endpoint Elemente spezifizieren jeweils eine Adresse
„
beinhaltet Elemente aus der Binding-Spezifikation
<service name="GoogleSearchService" interface="GoogleSearch">
<endpoint name="GoogleSearchEndPoint"
binding="GoogleSearchBinding">
...
</endpoint>
...
</service>
WSDL - Kommunikationsmuster
†
†
†
†
†
Kommunikationsmuster (Message Exchange Pattern)
definieren Kardinalität und Sequenz der ausgetauschten
Nachrichten
In-Only, Robust In-Only, In-Out, In-Multi-Out, Out-Only,
Robust Out-Only, Out-In, Asynchronous Out-In, Out-Multi-In
Rollen der Nachrichten werden durch Großbuchstaben (A, B, …)
bezeichnet
Möglichkeiten der verwendeten Protokolle müssen beachtet
werden
WSDL – Binding Spezifikation
†
†
†
†
erweitern Standard
„ Details zu Transport
„ Codierung der Parameter
notwendig, um Stubs zu generieren
werden vom W3C für SOAP und HTTP exemplarisch definiert
andere möglich (z.B. Apache Group für EJB´s, Java Klassen ...)
Æ Clientbibliotheken müssen Bindings unterstützen
WSDL - Binding
<binding name="GoogleSearchBinding" type="ns:GoogleSearchPort">
<soap:binding transport="URI:http" style="rpc" />
<operation name="doGetCachedPage">
<soap:operation soapAction="urn:GoogleSearchAction" />
<input>
<soap:body namespace="urn:GoogleSearch"
encodingStyle="URI:encoding" />
</input>
<output>...</output>
</operation>
</binding>
<service name="GoogleSearchService">
<endpoint name="GoogleSearchEndPoint"
binding="s0:GoogleSearchBinding">
<soap:address
location="http://api.google.com/search/beta2" />
</endpoint>
</service>
UDDI
† Universal Description, Discovery and Integration
† Klassifizieren, Katalogisieren und Verwalten von Daten und
Metadaten über Dienste
† ermöglicht Auffinden von Diensten nach bestimmten Kriterien
„ anhand allgemeiner, abstrakter Schnittstellenbeschreibung
„ nach Geschäftskategorien
„ Suche mittels Schlüsselworten
† UDDI nicht ausschließlich für Web Services nutzbar !!!
† entstand aus Initiative von IBM, Microsoft, SAP, Oracle u.a.
† heute durch OASIS koordiniert (UDDIv3)
UDDI - Datenstrukturen
† Standard definiert nur logische Komponenten (keine Impl.)
† vier Basisstrukturen, die als XML-Dokumente gespeichert werden
UDDI−Registry
businessEntity
businessService
bindingTemplate
tModel
Adresse des
Web−Service
† unterteilt in
„ allg. Unternehmens- und Servicedaten
„ technische Daten zu den Web Services
Spezifikation
des Models
UDDI - Datenstrukturen
† businessEntity enthält Unternehmens- und Web ServiceBeschreibung
„ Name und Beschreibung des Unternehmens
„ Anschrift, Kontaktinformationen, ...
† businessService repräsentiert logische Gruppierung von Web
Services eines Unternehmens
„ keine technische Informationen zu Service !!!
„ Name, Beschreibung und genereller Zweck des Services
„ Einordnung in Geschäftskategorien
UDDI - Datenstrukturen
† bindingTemplate beinhaltet technische Informationen
„ beinhaltet Lage und evt. weitere Metadaten des Services
„ für einen Service lassen sich mehrere Templates erstellen
† tModel repräsentiert eindeutige Spezifikation
„ kann beliebige Spezifikation, Protokoll, Namensraum, ... sein
Æ nicht zwangsläufig an WSDL-Dokument gebunden !!!
„ besitzen eindeutigen Schlüssel und verweisen auf Dokumente,
die Model spezifizieren
† Templates verweisen auf alle Models, die Service beschreiben
Æ z.B. WSDL-Dokument, verwendete Transportprotokolle, ...
UDDI - Datenstrukturen
<businessService>
...
<bindingTemplates>
...
<bindingTemplate>
<accessPoint urlType="http">...</accessPoint>
<tModelnstanceDetails>
<tModelnstanceInfo tModelKey="...">
...
</tModelnstanceInfo>
...
</tModelnstanceDetails>
...
</bindingTemplate>
...
</bindingTemplates>
</businessService>
UDDI - Informationsarten
† UDDI-Registry enthält drei Arten von Informationen
† White Pages (businessEntity)
„ Informationen über Unternehmen selbst
† Yellow Pages (businessService)
„ entsprechen Branchenbuch
„ beschreiben Dienste nach Geschäftskategorien
† Green Pages (bindingTemplate & tModel)
„ technische Informationen zu Diensten
UDDI - Nutzung
† UDDI definiert verschiedene SOAP-basierte APIs zur
Kommunikation mit Registries
Æ UDDI-Registry ist Sammlung von Web Services zum
Veröffentlichen und Auffinden von Web Services
† Publisher API
„ für Dienst-Anbieter
„ Methoden zum Registrieren und Verwalten von Diensten
† Inquiry API
„ für Dienst-Nutzer
„ Auffinden von Diensten nach bestimmten Suchkriterien
Zusammenwirken
UDDI−Registry
V
n
er
de
öf
in
fe
/F
nt
en
lic
ch
he
n
Su
WSDL
Web−Service
Anbieter
Binden
Web−Service
Nutzer
Bindung
† zwei mögliche Szenarien
† statische Bindung
„ geschieht zur Entwicklungszeit
„ Stub wird fest codiert und in Applikation eingebunden
† dynamische Bindung
„ zur Laufzeit
„ Service wird von Applikation gesucht (via UDDI)
„ Stub wird automatisch aus Beschreibung erzeugt und
eingebunden
„ wird als Standardverfahren für Web Services angesehen
Anwendungen
† B2B – Business to Business
„ WS geeignet für Maschine-zu-Maschine Kommunikation
„ komplexe Geschäftsprozesse aus Web Services
† Enterprise Application Integration
„ Investitionsschutz für große Unternehmen
„ Wrapper Web Service um Altanwendung
† Application Service Providing
„ Trennung der Applikations – und Präsenattionsebene
„ Kunde erhält nur Präsentationsclient
„ Logik und Daten auf dem Server
Inhalt
† Verteilte Systeme
„ RPC
„ Middleware
† Web Services
„ SOAP
„ WSDL
„ UDDI
† Implementierung .NET & Sun ONE
† Zusammenfassung & Ausblick
Implementierungen – .NET
† Microsofts neue Produktstrategie
„ neue Architektur für Windowsplattformen– und Bibliotheken
„ besonderer Wert wurde auf XML und Web Services gelegt
„ interpreter-basierter Ansatz
„ Interpreter: CLR (Common Language Runtime)
„ Format: MSIL ( MS Intermediate Language)
† Besonderheit:
„ Alle Microsoft Entwicklungssprachen können genutzt werden
„ z.B.: VB, C++, JScript, C#
Implementierungen – .NET
Serviceerstellung mit .NET in C#
using System.Web;
using System.Web.Services;
namespace helloWS {
public class MyService : System.Web.Services.WebService {
[WebMethod]
public string HelloWorld() {
return "Hello World";
}
}
}
Implementierungen – .NET
mit wsdl.exe generierter C# - Stub
public class GoogleSearchService :
System.Web.Services.Protocols.SoapHttpClientProtocol {
public GoogleSearchService() {
this.Url = "http://api.google.com/search/beta2";
}
[System.Web.Services.Protocols.SoapRpcMethodAttribute(
"urn:GoogleSearchAction", ResponseNamespace="urn:GoogleSearch")]
[return:
System.Xml.Serialization.SoapElementAttribute("return")]
public String doSpellingSuggestion(
string key, string phrase) {
object[] results = this.Invoke(
"doSpellingSuggestion", new object[] {key, phrase});
return ((String)(results[0]));
}
}
Implementierungen – .NET
Aufruf des Stubs
public class MyServiceClient{
public MyServiceClient(){
GoogleSearchService myGoogleProxy =
new GoogleSearchService();
myGoogleProxy.doSpellingSuggestion(
"00000000000000000000000000000000",
"suchstring");
}
static void Main() {
MyServiceClient mysc = new MyServiceClient();
}
}
Implementierungen – Sun ONE
† Sun Open Net Environment
† Sun‘s Antwort auf .NET
† basiert vollständig auf Java
† Sammlung von Werkzeugen und Bibliotheken
„ Sun ONE Web- und Applicationserver, Sun One Studio
„ J2SE + J2EE
„ JAXP, JAXB, JAX-RPC, SAAJ, JAXR
Implementierungen – Sun ONE
Serviceerstellung mit Sun‘s WS Developer Pack
package helloworld;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface HelloWorld extends Remote {
public String helloWorld() throws RemoteException;
}
package helloworld;
public class HelloWorldImpl implements HelloWorld {
public String helloWorld() {
return "Hello World!";
}
}
Implementierungen – Sun ONE
JAX-RPC-basierter Client (Ausschnitt)
ServiceFactory sf = ServiceFactory.newInstance();
Service s = sf.createService(
new URL("http://api.google.com/GoogleSearch.wsdl"),
new QName("urn:GoogleSearch", "GoogleSearchService"));
Call c = s.createCall(
new QName("urn:GoogleSearch", "GoogleSearchPort"),
"doSpellingSuggestion");
Object o = c.invoke(new Object[] {key, phrase});
System.out.println(o);
Inhalt
† Verteilte Systeme
„ RPC
„ Middleware
† Web Services
„ SOAP
„ WSDL
„ UDDI
† Implementierung .NET & Sun ONE
† Zusammenfassung & Ausblick
Zusammenfassung & Ausblick
† Plattform-, Sprach-, Herstellerunabhängig
Æ interoperabel
† ABER: langsam aufgrund XML-Basierung
† Kernstandards (SOAP, WSDL, UDDI) von Industrie anerkannt und
zahlreiche Implementierungen vorhanden
† neue Erweiterungen in Ausblick
„ Sicherheit & Authentifizierung, Choreographie, Routing, ...
Gefahr durch Vielfalt und Konkurrenz neuer Standards und
Implementierungen (z.B. Microsoft, BEA vs. IBM, SAP, HP)
Æ Verlust der Interoperabilität
Fragen ?