Standardisierung von Web Services - Integration semantischer und sicherheitsbezogener Aspekte

3

Abstract

In einem verschärften, globalen Wettbewerb ist die Optimierung innerbetrieblicher Geschäftsprozesse eine notwendige, jedoch keine hinreichende Bedingung für die Wettbewerbsfähigkeit eines Unternehmens. Nicht einzelne Unternehmen, sondern virtuelle Wertschöpfungsketten aus kollaborierenden Kunden, Lieferanten und Partnern stehen im Wettbewerb. Die Fähigkeit eines Unternehmens, sich und seine IT-Systeme ad-hoc und möglichst automatisch in diese Wertschöpfungsketten zu integrieren, um am so genannten Collaborative Business teilzunehmen, gewinnt immer stärker an Bedeutung.

Web-Services sind grundsätzlich in der Lage, die hieraus hervorgehenden Anforderungen an IT-Infrastrukturen zu adressieren. Sie haben sich in den letzten drei Jahren vom vielversprechenden Konzept zu einer anwendungsreifen Technologie entwickelt. Diese Entwicklung verläuft evolutorisch aus einem technisch geprägten Umfeld heraus und berührt zunehmend den Anwendungskontext der entsprechenden Services. In diesem Zusammenhang werden Fragen nach der semantischen (d.h. inhaltlichen) Repräsentation und nach der Sicherheit dieser Dienste aufgeworfen, welche die Web-Service-Basisstandards XML, SOAP, WSDL und UDDI alleine nicht zufriedenstellend beantworten können.

Hier kommen ergänzende Standards ins Spiel, die nicht notwendigerweise Web-Service-Standards sein müssen, aber Web-Services bzw. deren Basisstandards um semantische Beschreibungsmöglichkeiten und Sicherheitsmechanismen erweitern können. In diesem Kontext werden semantische Standards wie RDF/RDFS, OWL und Sicherheitsstandards wie XML Encryption, XML Signature u.w. vorgestellt. Anhand von Beispielen wird erläutert, wie diese erweiterten Standards in das Web-Service-Architekturmodell integriert werden können.

Abschließend werden die im Verlauf der Arbeit gewonnen Erkenntnisse auf aktuelle, empirische Untersuchungen zur praktischen Nutzung von Web-Service-Standards bezogen und ein Entwicklungspfad für den Praxiseinsatz von Web- Service-Technologien aufgezeigt.

4

Inhalt

  Abstract  3

Inhalt.....................................................................................................................   4

  Abbildungsverzeichnis  6

  Abkürzungsverzeichnis  7

1  Einführung  9

1.1  Collaborative Business  9

1.2  Zielsetzung und Vorgehensweise  11

2  Grundlagen  14

2.1  Services und Service-orientierte Architekturen  14

2.2  Web-Services  15

2.3  Web-Service Architektur  17

2.4  Einsatzfelder für Web-Services  18

2.4.1  Enterprise Application Integration (EAI)  18

2.4.2  Business-to Business (B2 B) Integration  21

2.5  Standardisierung als Voraussetzung für Collaborative Business  25

2.5.1  Basistechnologie  26

2.5.2  Semantik  27

2.5.3  Sicherheit  28

2.6  Standardisierungsorganisationen  29

3  Web-Service Basisstandards  32

3.1  XML  32

3.1.1  Einordnung  33

3.1.2  XML-Verarbeitung  34

3.1.3  Struktur und Schema  35

5

3.1.4  XML-Funktionsaufrufe  37

3.2  SOAP  38

3.3  WSDL  41

3.4  UDDI  44

4  Integration semantischer Aspekte  51

4.1  Semantische Beschreibungsansätze  51

4.2  EbXML - eine Ergänzung für Web-Services?  53

4.3  Semantic-Web  54

4.3.1  RDF  55

4.3.2  RDFS  57

4.3.3  OWL  59

4.4  Integration von Semantik in die Web-Service Architektur  61

5  Integration von Sicherheitsaspekten  65

5.1  Sicherheit und Web-Services  65

5.2  XML Signature / XML Encryption  67

5.3  Integration von Sicherheitsaspekten in die Web-Service Architektur  70

6  Fazit und Entwicklungspfade  75

6.1  Fazit  75

6.2  Entwicklungspfad für Web-Services  76

  Literatur  80

6

  Abbildungsverzeichnis  

  Bild 1 : Grundlage Service-orientierter Architekturen Barr2003 , S. 20  15

  Bild 2 : Web-Service Architektur Barr2003 , S. 23  17

  Bild 3 : Manuelle Prozessintegration im Unternehmen  19

  Bild 4 : Konventionelle EAI-Integrationsarchitektur AlCa2004 ,S 78  20

  Bild 5 : EAI-Integration über Web-Services (SOAP)  21

  Bild 6 : Manuelle Prozessintegration im B2 B-Umfeld  22

  Bild 7 : Konventionelle B2 B-Integrationsarchitektur AlCa2004 , S. 129  23

  Bild 8 : B2 B-Integration über Web-Services  24

  Bild 9 : Dimensionen der Web-Service Standardisierung  26

  Bild 10 : Web-Service Schichtenmodell Knut2002 , S 97  32

  Bild 11 : XML-Sprachkonzept Weit2001 S. 19  33

  Bild 12 : Komplexität und Funktionalität von Beschreibungssprachen  34

  Bild 13 : Struktur eines einfachen XML-Dokuments  35

  Bild 14 : Referenzierung einer externen DTD aus einem XML-Dokument  36

  Bild 15 : XML-RPC  38

  Bild 16 : Aufbau einer SOAP-Nachricht  39

  Bild 17 : SOAP-Nachricht im RPC-Style (Request / Response)  40

  Bild 18 : SOAP-Nachricht im Document-Style (Request / Response)  40

  Bild 19 : Beispiel einer Service Description in WSDL  42

  Bild 20 : Interaktionsverhalten von Web-Services  43

  Bild 21 : Elemente und Zusammenhänge einer WSDL-Beschreibung  44

  Bild 22 : UDDI org Struktur  45

  Bild 23 : UDDI-Inquiry und Response des API  48

  Bild 24 : UDDI-Datenmodell  50

  Bild 25 : Der Weg zu Semantic Web-Services Jeck2004a, S. 55  54

  Bild 26 : Graphische Notation von RDF-Tripeln  56

  Bild 27 : n-ärer Graph eines Statements  56

  Bild 28 : RDF-Tripel  57

  Bild 29 : RDF / XML-Notation  57

  Bild 30 : RDFS / XML-Notation  58

  Bild 31 : RDF / XML-Notation für eine einfache OWL-Ontologie  61

  Bild 32 : Point-to Point- vs. End-to End-Sicherheit  67

  Bild 33 : Ebenen der Web-Service Sicherheit  67

  Bild 34 : Teilverschlüsseltes XML-Dokument (Element Encryption)  68

  Bild 35 : XML Signature mit Message Digest  70

  Bild 36 : SOAP-Nachricht mit signierter Payload  72

  Bild 37 : Portfolio / Evolutionspfad für Web-Services  78

7

Abkürzungsverzeichnis

AG ALE API AuthML B2B B2C BPSS Bspw. Bzw. CRM D.h. DAML DARPA DCOM Distributed Component Object Model DOM Document Object Model DTD Document Type Definition EAI EAN eBusiness ebXML Electronic Business XML ECMA European Computer Manufacturer Association EDI Electronic Data Interchange eMail Electronic Mail ERP ERP II HTML Hypertext Markup Language HTTP HTTPS I.d.R. In der Regel IETF INCITS ISO / OSI IT JCP MRP NAICS OAGIS OASIS Organization for the Advancement of Structured Information OIL OWL OWL DL OWL-S OWL-Services PKI RDF RDFS RPC Remote Procedure Call RSS RDF Site Summary

8

S2ML SAML SAX SCM SGML SMTP SOAP SOAP-SEC SOX Schema for Object Oriented XML SSL STMP TCP / IP TSL

U.w. UBR UDDI UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business UNSPSC Universal Standard Products and Services Classification URI URL W3C WSDL WS-I WS-Security XACML eXtensible Access Control Markup Language XDR XKMS XML Extensible Markup Language XSD XML Schema Description Z.B. Zum Beispiel

9

1 Einführung

Hinter dem Begriff Web-Service steckt weit mehr, als hinter den üblichen Floskeln, Akronymen und Schlagwörtern, welche die IT-Branche mit unverhohlener Euphorie proklamiert. Web-Services sind kein Selbstzweck, sondern adressieren grundsätzliche Anforderungen an IT-Infrastrukturen in einer hochgradig arbeitsteiligen und gleichzeitig wettbewerbsintensiven, globalen Wirtschaft.

Das praktische Einsatzspektrum von Web-Services wird entscheidend durch ihre Interoperabilität beeinflusst, die wiederum von der Verfügbarkeit gemeinsamer Konventionen und Standards abhängt. Die folgende Einführung verdeutlicht diese Perspektive und erläutert Aufgabenstellung und Zielsetzung der Arbeit.

1.1 Collaborative Business

In den letzten Jahrzehnten hat sich der Wettbewerb in nahezu allen Branchen auf nationaler wie internationaler Ebene zunehmend verschärft. Kein Unternehmen kann sich ineffiziente Geschäftsprozesse leisten, denn unzufriedene Kunden und hohe Kosten lassen sich auf Dauer auch durch hervorragende Produkte und Dienstleistungen nicht kompensieren. Viele Unternehmen sahen und sehen sich deshalb gezwungen, die eigene Wettbewerbsfähigkeit nachhaltig zu steigern, um im Wettbewerb zu bestehen.

Seit Ende der 70er Jahre stand deshalb die Optimierung innerbetrieblicher Prozesse und Informationsflüsse im Rahmen von MRP- (Material Resource Planning) und später dann ERP- (Enterprise Resource Planning) Projekten im Fokus vieler Unternehmen.

Heute setzt sich zunehmend die Erkenntnis durch, dass die Optimierung unternehmensinterner Prozesse zwar eine notwendige, jedoch keine hinreichende Voraussetzung für die Wettbewerbsfähigkeit eines Unternehmens ist. In einer vernetzten, hochgradig arbeitsteiligen Wirtschaft stehen eben nicht mehr einzelne Unternehmen im Wettbewerb, sondern komplette Wertschöpfungsketten aus Kunden, Zulieferern und Partnern. „Die Bildung von zwischenbetrieblichen Kooperationen wird für die beteiligten Akteure immer häufiger zum Instrument

10

der Verbesserung ihrer Wettbewerbsposition in einer globalen Weltwirtschaft“ [BuKö00, S. V].

EDI (Electronic Data Interchange) stellt zwar seit nahezu 30 Jahren einen Standard für die überbetriebliche, elektronische Geschäftsabwicklung zur Verfügung, der in vielen Fällen zu signifikanten Prozessoptimierungen beigetragen hat. Aufgrund der hohen Implementierungskosten und divergierender Standards hat sich EDI allerdings nur als Koppelung zwischen großen Firmen und bei stabilen, auf Dauer ausgelegten Geschäftsbeziehungen etablieren können [Hack2004, S. 1ff]. Virtuelle Wertschöpfungsketten sind jedoch weder auf große Firmen beschränkt, noch notwendigerweise von längerer Dauer.

Dieser Erkenntnis tragen verschiedene, neuere Begriffe und Konzepte, wie ERP II (Enterprise Resource Planning 2nd Generation) [Gart00] oder Collaborative Business [Wett2003] Rechnung. Beiden Konzepten ist gemein, dass sie die Kooperationsfähigkeit von Unternehmen, d.h. die Fähigkeit zur Integration in unternehmensübergreifende Geschäftsprozesse, als wettbewerbskritischen Faktor definieren und das Internet als geeignetes Kommunikations- und Koordinationsinstrument betrachten. Hieraus ergeben sich neue Anforderungen an die Konzeption und Integration der diese Prozesse unterstützenden IT-Systeme.

Klassische ERP-Systeme, wie das mittlerweile über zehn Jahre alte SAP R/3 des Walldorfer Softwareherstellers SAP, sind monolithische Anwendungssysteme. Sie sind aus einem Guss und enthalten eine Vielzahl von Funktionalitäten, ungeachtet dessen, ob ein bestimmtes Unternehmen diese überhaupt benötigt. Schnittstellen zu externen Systemen existieren häufig nur auf Datenbank- und Quellcode-Ebene oder müssen fallweise in aufwändigen Integrationsprojekten implementiert werden.

Für eine unternehmensinterne Integration, die i.d.R. auf eine längere Dauer ausgelegt ist, können die daraus resultierenden Aufwände noch toleriert werden. Eine fallweise und automatisierte ad-hoc-Koppelung im Rahmen von unternehmensübergreifenden Geschäftsprozessen ist jedoch nicht möglich.

Kollaborative Geschäftsprozesse fordern Service-orientierte Architekturen mit modularen Softwarekomponenten, die ihre Funktionalitäten als Services gekapselt über standardisierte Technologien und Schnittstellen zur Verfügung

11

stellen. Einerseits sollen so ohne substantielle Schnittstellen- und Integrationsaufwände unternehmensinterne IT-Systeme gekoppelt werden. Andererseits soll die Kommunikation mit externen Systemen von Geschäftspartnern hergestellt und so Unternehmen möglichst automatisiert zu virtuellen Wertschöpfungsketten kombiniert werden. Auf diesen Überlegungen basiert das Konzept der Web-Services.

Web-Services haben sich in den letzten Jahren vom vielversprechenden Konzept zu einer mittlerweile anwendungsreifen Integrationstechnologie entwickelt. Dennoch ist die Realität noch weit entfernt von der Vision lose gekoppelter, virtueller Wertschöpfungsketten. Viele Unternehmen arbeiten zwar an Web-Service-Projekten, in der unternehmensübergreifenden Geschäftsabwicklung haben sich Web-Services jedoch noch nicht durchsetzen können, wenn auch die Zahl der B2B- (Business to Business) Implementierungen relativ und absolut zunimmt [Cant2003].

Ein wichtiger Grund für die noch geringe, jedoch wachsende Zahl der unternehmensübergreifenden Web-Service Projekte ist die noch nicht abgeschlossene, aber stetig voran schreitende Standardisierung von Web-Service-Spezifikationen.

Wenn Standards fehlen, müssen die Konventionen, denen die Kommunikation folgen soll, von Fall zu Fall neu verhandelt werden, was eine automatisierte Koppelung unmöglich macht. Nur wenn Standards definiert sind, kann die unternehmensübergreifende Kommunikation formalisiert und elektronisch abgebildet werden.

1.2 Zielsetzung und Vorgehensweise

Die Standardisierung von Web-Services ist zwar mittlerweile fortgeschritten, dennoch existieren eine Reihe von Standardisierungslücken, welche die Diffusion von Web-Services gerade in der unternehmensübergreifenden Geschäftsprozessabwicklung bislang behindern.

Zielsetzung dieser Arbeit ist es, anhand der vorgestellten Web-Service-Basisstandards XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language) und UDDI (Universal Description, Discovery, and Integration), Defizite bezüglich der semantischen Repräsentation, sowie der Berücksichtigung von Sicherheitsas-

12

pekten aufzuzeigen. Diese Defizite können mit weiteren Standards (Co-Standards) und Spezifikationen kompensiert werden. Die Arbeit geht insbesondere darauf ein, wie semantische und sicherheitsbezogene Standards in die Web-Service-Architektur integriert werden können.

Nach dieser Einführung wird im zweiten Kapitel erläutert, was sich hinter dem Begriff Web-Service verbirgt. Anhand des Web-Service-Architekturmodells wird aufgezeigt, wie Web-Services interagieren und welche Einsatzfelder sie für die inner- und überbetriebliche Integration von IT-Systemen erschließen. Dabei wird deutlich, dass die Standardisierung von technischen, semantischen und sicherheitsbezogenen Aspekten die grundlegende Voraussetzung für die Diffusion von Web-Services in der Praxis, insbesondere im Collaborative Business ist. Die Herausbildung und formale Proklamation von Standards erfolgt i.d.R. durch Standardisierungsorganisationen wie dem W3C oder OASIS, die ebenso vorgestellt werden.

Das dritte Kapitel widmet sich der Vorstellung der Web-Service-Basisstandards. Hierbei wird herausgearbeitet, dass diese Standards technische Aspekte, sozusagen die Mechanik von Web-Services, sehr umfassend beschreiben. Semantische und sicherheitsbezogene Fragestellungen können mit diesen Standards alleine nicht adäquat repräsentiert werden. Welche weiteren Standards sich hierfür anbieten und wie diese in die Web-Service-Architektur integriert werden können, zeigen die folgenden zwei Kapitel.

Semantische Aspekte lassen sich durch Metadaten und Ontologien beschreiben. Existierende Ontologien wie UNSPSC (Universal Standard Products and Services Classification) und eCl@ss, oder Frameworks wie RosettaNet und ebXML (electronic business XML), berücksichtigen zwar semantische Aspekte in der unternehmensübergreifenden Kommunikation, sind aus verschiedenen Gründen jedoch nicht zur Integration in das Web-Service-Architekturmodell geeignet. Dahingegen stellen die vorgestellten Technologien der Semantic Web Initiative des W3C (World Wide Web Consortium), namentlich RDF (Resource Description Framework) / RDFS (RDF Schema) und OWL (Web Ontology Language) eine gangbare Möglichkeit dar, Web-Services um semantische Inhalte zu ergänzen. Wie RDF und OWL in die Web-Service-Architektur integriert werden können, wird anhand von verschiedenen Ansätzen und Beispielen erläutert.

13

Web-Service-Basisstandards alleine sind nicht in der Lage, alle Anforderungen an sichere Web-Services zu erfüllen. SOAP kann zwar über tiefer liegende Schichten wie HTTP (Hypertext Transport Protocol) bzw. SSL (Secure Socket Layer) die Sicherheit während der Übertragung gewährleisten, nicht jedoch nach Abbau der SOAP-Kommunikation. Eine Möglichkeit, Sicherheit über die SOAP-Verbindung hinaus und damit auf Nachrichtenebene zu garantieren, erschließt sich mit den W3C-Standards XML Signature und XML Encryption. Da XML Encryption und XML Signature im Gegensatz zu SOAP keine dedizierten Web-Service-Standards sind, stellt sich dann die Frage, wie sie in die Web-Service-Architektur eingebunden werden können. Die Antwort auf diese Frage wird anhand von verschiedenen Ansätzen beispielhaft erläutert.

Das sechste und abschließende Kapitel fasst die Ergebnisse dieser Arbeit zusammen und zeigt anhand empirischer Untersuchungen zum Einsatz von Web-Services in der Praxis den aktuellen und zukünftig möglichen Entwicklungspfad für Web-Services auf. Hierbei wird deutlich, dass sich Unternehmen den Herausforderungen dieser neuen Technologie sukzessive stellen, indem sie Web-Services zuerst unternehmensintern einsetzen und danach auf die unternehmensübergreifende Kommunikation mit Zulieferern, Kunden und Partnern ausdehnen.

14

2 Grundlagen

Als Basis für die weitere Ausarbeitung werden zunächst Begrifflichkeiten, Funktionsweisen und Einsatzmöglichkeiten von Web-Services dargestellt, um dann die für die weitere Betrachtung relevanten Standardisierungsbereiche herauszuarbeiten.

2.1 Services und Service-orientierte Architekturen

Kollaborative Geschäftsprozesse erfordern Service-orientierte Architekturen aus modularen Softwarekomponenten, die ihre Funktionalitäten als Services gekapselt über standardisierte Technologien und Schnittstellen zur Verfügung stellen.

Grundlegend für Service-orientierte Architekturen ist das Verständnis des Service-Begriffs. Services in Service-orientierten Architekturen lassen sich nicht mit dem Dienstleistungsbegriff der wörtlichen Übersetzung beschreiben. Vielmehr sind solche Services exakt definierte, gekapselte und eigenständige Funktionalitäten. “A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.” [Barr2003, S. 19]

Services kommunizieren, um eine bestimmte Aufgabenstellung, die z.B. die Abwicklung eines Geschäftsprozesses umfasst, zu lösen. Service-orientierte Architekturen können als Konglomerat von miteinander kommunizierenden Services interpretiert werden. “A service orientated architecture is essentially a collection of services. These services communicate with each other.” [Barr2003, S. 19]

Voraussetzung für die Konzeption und Implementierung von Services ist die Zerlegung der jeweiligen Anwendungslogik in einzelne, atomare Funktionen. Die Verteilung der Anwendungslogik auf unterschiedliche Services bedingt eine intensive Kommunikation zwischen den an einem Geschäftsprozess beteiligten Services. Nur wenn die beteiligten Services dieselbe Sprache sprechen, d.h. interoperabel sind, ist gewährleistet, dass die Kommunikation der Dienste reibungslos verlaufen kann. Voraussetzung hierfür sind standardisierte Schnittstellen, die eine stark formalisierte Kommunikation erzwingen.

15

Die Kommunikation kann vom simplen Datentransfer bis hin zur komplexen Koordination von zwei oder mehr Services im Rahmen einer umfangreichen Geschäftsprozessabwicklung reichen. Ähnlich dem konventionellen Client-Server-Modell übernimmt während der Kommunikation ein Service die Rolle des Service-Providers, der andere die des Service-Requestors. Der Service-Requestor, sozusagen der Client, baut eine Kommunikationsverbindung auf und sendet eine Anfrage an den Service-Provider. Dieser verarbeitet die Anfrage und sendet eine Antwort zurück an den Service-Requestor.

Bild 1: Grundlage Service-orientierter Architekturen [Barr2003, S. 20]

2.2 Web-Services

Eine Möglichkeit zur Implementierung Service-orientierter Architekturen sind Web-Services. Was sich genau hinter diesem Begriff verbirgt und wie er im Kontext der nachstehenden Arbeit zu interpretieren ist, soll im folgenden dargestellt werden.

Eine sehr allgemeine und generische Auslegung beschreibt Web-Services als Anwendungen, auf die andere Anwendungen über das Internet zugreifen können: „Web services, in the general meaning of the term, are services offered by one application to other applications via the World Wide Web“ [Sun2003].

Unter Berücksichtigung des oben (Kap. 2.1) definierten Service-Begriffs sind Web-Services exakt definierte, gekapselte und eigenständige Funktionalitäten, die über das Internet bzw. über standardisierte Internettechnologien bereitgestellt werden. Diese Definition deckt sich weitgehend mit der des UDDI Konsortiums. „Web-Services are self-contained, modular business applications that have open, Internet-oriented, standards-based interfaces” [UDD2001a, S.1].

Implementierungsnäher beschreibt eine Definition der Web Services Architecture Working Group des W3C Web-Services: „A Web-Service is a software system identified by a URI (Uniform Ressource Identifier), whose public interfaces and bindings are defined and described using XML. Its definition can be discovered

16

by other software systems. These systems may then interact with the Web-Service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols” [W3C2004a].

Hieraus lassen sich bereits konkrete Details ableiten, z.B. die Verwendung der Metasprache XML und von Standard-Internetprotokollen. Die Definition enthält darüber hinaus konkrete Hinweise zur Funktionsweise und lmplementierung von Web-Services. Sie werden definiert (defined), beschrieben (described), identifiziert (identified) und interagieren (interact).

Mit zunehmender Anwendungsreife und Herausbildung erster Standards kann diese Definition weiter ausdifferenziert werden. Demnach ist ein Web-Service “a custom end-to-end application that interoperates with other commercial and custom software through a family of XML interfaces (like SOAP, UDDI and WSDL) to perform useful business functions” [Lati2003].

Ähnlich, jedoch detaillierter, stellt sich die folgende Definition dar. “The term Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available” [Webo2004].

Hier wird konkret festgelegt, wozu welche Standards bei der Implementierung von Web-Services herangezogen werden:

1. Web-Services werden in der Metasprache XML definiert.

2. Web-Services interagieren über das Standardprotokoll SOAP.

3. Web-Services und ihre Schnittstellen werden über WSDL beschrieben.

4. Web-Services werden über den globalen Verzeichnisdienst UDDI registriert und identifiziert.

„SOAP, WSDL and UDDI are nowadays the core of Web services“ [AlCa2004, S.151]. Wie diese, im folgenden als Web-Service-Basisstandards bezeichneten Standards im Rahmen des Web-Service-Architekturmodells zusammenarbeiten, stellt das folgende Kapitel dar.

17

2.3 Web-Service-Architektur

Die Funktionalität des Web-Services wird als definierte und beschriebene Schnittstelle angeboten, die einen bestimmten Input verlangt und (gegebenenfalls) eine entsprechende Information als Ausgabe zurückliefert. Die hinter dem Web-Service liegende, technische Komponente ist nicht maßgeblich, allein die Kompatibilität des Web-Service bzw. dessen Schnittstelle ist entscheidend. Die Beschreibung der Schnittstelle wird in der XML-basierten Schnittstellenbeschreibungssprache WSDL vorgenommen.

Über diese Schnittstelle kann der Web-Service durch einen entfernten Funktionsaufruf angesprochen werden. Der entsprechende Funktionsaufruf wird durch das SOAP Protokoll realisiert. SOAP ist ein XML-basiertes Protokoll, das es, ähnlich konventionellen Remote Procedure Calls (RPCs), ermöglicht, Funktionsaufrufe auf entfernten Servern durchzuführen. Als Transportschicht wird dabei meist HTTP (Hypertext Transport Protocol) genutzt. SOAP wird deshalb oft als XML over HTTP bezeichnet, der eigentliche Funktionsaufruf als XML-RPC.

Zur Publikation der Web-Service-Beschreibung wird der globale, branchenübergreifende Verzeichnisdienst UDDI, selbst wiederum ein Web-Service, herangezogen. Das Zusammenwirken dieser Spezifikationen wird im Web-Service-Architekturmodell deutlich.

Bild 2: Web-Service-Architektur [Barr2003, S. 23]