Inhaltsverzeichnis:

1  Einleitung.  1

2  Definition.  2

3  Architektur und Aufbau.  3

3.1  Interne Web Service Architektur.  3

3.2  Externe Web Service Architektur.  4

4  Standard Technologien.  5

4.1  XML: Extensible Markup Language.  5

4.2  SOAP: Simple Object Access Protocol.  6

4.3  WSDL: Web Service Description Language.  7

4.4  UDDI: Universal Description Discovery and Integration.  8

5  Einsatzfelder und Nutzenpotential.  10

5.1  EAI: Enterprise Application Integration.  10

5.2  B2B: Unternehmensübergreifendende Geschäftsprozesse.  11

5.2.1  Sicherheit in der B2B Integration.  11

6  Fazit und Ausblick.  12

7  Abbildungsverzeichnis.  13

8  Literaturverzeichnis  14

1 Einleitung

1 Einleitung

Nahezu alle Bereiche und Aufgaben in modernen Unternehmen zeichnen sich heute durch Unterstützung von hochentwickelten Softwarelösungen aus. Da kaum eine Funktion oder ein Prozess ohne Software Einsatz auskommt, es aber „nicht die eine Softwarelösung gibt, die alle Funktionen eines Unternehmens abdeckt“ ¹ , herrscht in den meisten Unternehmen eine ausgeprägte Koexistenz heterogener Software-Systeme vor. Genau an dieser Stelle entsteht der Wunsch nach umfassender Integration. Diese ermöglicht zunächst die Optimierung der internen Geschäftsprozesse. Darüber hinaus ebnet sie jedoch den Weg zum Abruf des Nutzenpotentials kollaborativer Geschäftsprozesse, welche unter dem Banner einer globalisierten Weltwirtschaft durch Zusammenschlüsse, Kooperationen und Partnerschaften einen immer höheren Stellenwert einnehmen. In Web Services als technologische Infrastruktur liegt nunmehr der Schlüssel sowohl zur unternehmensinternen als auch unternehmensübergreifenden Integration. Zwar wurden auch in der Vergangenheit mit DCOM, CORBA, J2EE respektive Java RMI entsprechende EAI (Enterprise Application Integration) Architekturen geschaffen ² , allen ist jedoch gemeinsam, dass es sich um proprietäre Ansätze handelt, deren Konzepte nicht aufeinander abgestimmt sind. Web Services dagegen sind basierend auf dem De Facto Standard XML „plattformneutral und herstellerunabhängig“ ³ ausgelegt und ermöglichen auf diesem Wege die Integration von Systemen unterschiedlichster Natur. Die vorliegende Arbeit zeigt auf, was genau unter Web Services zu verstehen ist, wie diese aufgebaut sind und welchen konkreten Nutzen sie für Unternehmen stiften können. Das Hauptaugenmerk liegt dabei auf den technologischen Standards, die zur Implementierung und zum Einsatz von Web Services erforderlich sind. Eine Betrachtung des Status Quo gefolgt von einem kurzen Blick auf zu erwartende, zukünftige Tendenzen bilden den Abschluß.

¹ Kossmann, Leymann 2004, S.117

² Vgl. Jeckle 2004

³ Silberberger 2004, S.57

Seite 1

2 Definition

2 Definition

Unter dem Begriff Web Services werden automatisierte Dienste zur Abwicklung von Dienstleistungen und Geschäftsprozessen auf der Basis von standardisierten Internet Technologien bezeichnet. Der Zugriff auf die angebotenen Funktionalitäten erfolgt über eine öffentlich publizierte Schnittstelle. Web Services werden nicht von menschlichen Benutzern angesprochen, sondern die Interaktion erfolgt ausschließlich zwischen Softwarekomponenten, die „automatisiert Daten austauschen und/oder Funktionen auf entfernten Rechner aufrufen“ ⁴ . Die Unabhängigkeit von Systemumgebungen und Programmiersprachen ⁵ gewährleistet dabei die Interoperabilität, d.h. das Zusammenwirken von Web Services und deren barrierenfreie Kommunikation. Dies bedeutet, dass „es zunächst keine Rolle (spielt), welche Endgeräte (PC, Mobiltelefon, PDA, etc.) hierbei eingesetzt werden“. Auf der technischen Ebene haben sich die auf XML aufsetzenden Vokabulare SOAP als Nachrichtenprotokoll und WSDL zur Schnittstellenbeschreibung sowie UDDI als Verzeichnisdienst als allgemein akzeptierte Standards etabliert. Der Nachrichtenaustausch bzw. Datentransport erfolgt mittels Internet Protokollen, vorzugsweise http (Hyper Text Transfer Protocol) bzw. smtp (Simple Mail Protocol). Zur Realisierung von Web Service Architekturen sind jedoch nicht alle in Abbildung 1 dargestellten Kommunikationsstufen erforderlich. 6

Abbildung 1: Der Basis-Web-Service-Stack (nach Kossmann, Leymann 2004)

⁴ Wikipedia (o.V.) 2005

⁵ Vgl. Wikipedia (o.V.) 2005

⁶ Vgl. Jeckle 2004

Seite 2

3 Architektur und Aufbau

3 Architektur und Aufbau

3.1 Interne Web Service Architektur

Die interne Architektur von Web Services basiert auf der Grundidee, eine Web Service Middleware bzw. einen sog. Web Service Message Broker als zusätzliche höhere Schicht oberhalb der bereits existierenden IT spezifischen Applikationsschichten im Unternehmen zu installieren. Der Einsatz erfolgt entweder direkt im Unternehmen oder aber innerhalb des unternehmensweiten LAN (Local Area Network). Dies bedeutet, dass Applikationen durch ihre lose Kopplung nicht mehr direkt miteinander kommunizieren, sondern die gesamte Kommunikation über den Message Broker abgewickelt wird. Diese zentrale Instanz verwaltetet ein Regelwerk, welches exakt festlegt, welche Nachrichten an welche Applikationen adressiert werden müssen. ⁷ Weiterhin wird bestimmt wie Nachrichten aufzubereiten sind, damit eine Verarbeitung seitens der entsprechenden Anwendungen überhaupt möglich ist. Der regelbasierte Ansatz ermöglicht dabei jederzeit die flexible Anpassung von Prozessen. So kann bspw. eine Regel, welche Auftragseingänge an eine dafür vorgesehene Anwendung weiterleitet, derart angepaßt werden, dass bei einem Auftrag eines Premium Kunden eine spezielle Anwendung angesprochen wird, welche eine entsprechende Vorzugsbehandlung einleitet. Für die meisten Unternehmen bildet die innerbetriebliche Integration der heterogenen Systemlandschaft oft den Einstieg in Web Service Technologien. Dabei wird der Integrationsprozess erheblich vereinfacht je mehr Software Anbieter dazu übergehen ihre Lösungen schon vorab in den Grundversionen mit standardisierten Web Service Schnittstellen auszustatten, um so Homogenität auf Anwendungsebene herzustellen. 8

Abbildung 2: Interne Web Service Architektur (nach Kossmann, Leymann 2004)

⁷ Vgl. Kossmann, Leymann 2004 S.118

⁸ Vgl. Alonso, Casati, Kuno, Machiraju 2004 S.135

Seite 3