Generische Anbindung von Datenhaltungssystemen mit Web Services am Beispiel von SAP R/3

Diplomarbeit

J¨ org Diesinger

Naturwissenschaftlich-Technische Fakulta¨t I der Universit¨at des Saarlandes

November 2004

Hiermit erkl¨ are ich an Eides statt, dass ich die vorliegende Arbeit selbstst¨ andig verfasst und keine anderen als die im Literaturverzeichnis angegebenen Quellen verwendet habe.

Saarbr¨ ucken, 30. November 2004 (J¨org Diesinger)

Inhaltsverzeichnis Vorwort

1

1 Einleitung 1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . .

3 5 7 8

2 Konzepte verteilter Ausfu ¨ hrungsplattformen 2.1 Definitionen . . . . . . . . . . . . . . . . . . . 2.1.1 Verteiltes System . . . . . . . . . . . . 2.1.2 Middleware . . . . . . . . . . . . . . . 2.2 Middleware-Technologien . . . . . . . . . . . 2.2.1 Remote Procedure Call (RPC) . . . . 2.3 Service-oriented architecture (SOA) . . . . . 2.3.1 Anforderungen und Modell . . . . . . 2.3.2 Service Provider . . . . . . . . . . . . 2.3.3 Service Broker . . . . . . . . . . . . . 2.3.4 Service Consumer . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

3 Web Services 3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Web Services architecture (WSA) . . . . . . . . . . . . . . 3.3 Simple Object Access Protocol (SOAP) . . . . . . . . . . 3.3.1 SOAP Nachricht . . . . . . . . . . . . . . . . . . . 3.3.2 Kodierung und Datentypen . . . . . . . . . . . . . 3.3.3 SOAP f¨ ur RPC . . . . . . . . . . . . . . . . . . . . 3.4 Web Services Description Language (WSDL) . . . . . . . 3.5 Universal Description, Discovery and Integration (UDDI) 4 SAP R/3 4.1 Systemarchitektur . . . 4.2 Business Framework . . 4.3 Business-Komponenten . 4.4 Business-Objekte . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . .

. . . . . . . .

. . . .

. . . . . . . . . .

. . . . . . . .

. . . .

. . . . . . . . . .

9 9 9 10 10 10 11 12 12 12 13

. . . . . . . .

15 15 16 16 17 18 20 21 24

. . . .

25 25 26 28 28 i

Inhaltsverzeichnis

4.5

. . . . . . . .

31 32 33 34 36 37 40 41

. . . . . . .

42 42 43 46 46 47 49 49

. . . .

51 51 53 54 55

7 Anforderungen 7.1 Anforderungen an Web Services . . . . . . . . . . . . . . . . . . 7.2 Anforderungen an Generic Web Services . . . . . . . . . . . . .

57 57 59

8 Entwurf von Generic Web Services 8.1 Vorbetrachtungen . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Servlet-basierter Aufbau . . . . . . . . . . . . . . . . . . . . . .

62 62 63

9 Implementierung 9.1 Datenbank-Adapter . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Generierungsprozess . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Web Service Invocation Framework (WSIF) . . . . . . . . . . .

64 64 65 66

10 Einsatzbeispiel 10.1 Generierung . . . . 10.2 Deployment . . . . 10.3 Aufruf . . . . . . . 10.3.1 WSIF . . . 10.3.2 Web Service

67 67 76 77 77 77

4.6 4.7

Business Application Programming Interfaces (BAPIs) 4.5.1 Merkmale von BAPIs . . . . . . . . . . . . . . 4.5.2 Vorteile von BAPIs . . . . . . . . . . . . . . . . 4.5.3 Voraussetzungen f¨ ur den Zugriff auf BAPIs . . 4.5.4 Zugriffsm¨ oglichkeiten . . . . . . . . . . . . . . . 4.5.5 Beispiel: Company.GetList() . . . . . . . . Integrationsdienst ALE (Application Link Enabling) . Remote Function Call (RFC) . . . . . . . . . . . . . .

. . . . . . . .

5 Zugriff auf SAP R/3 mit SAP Java Connector (JCo) 5.1 Technologie des JCo . . . . . . . . . . . . . . . . . . . . 5.2 Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . 5.3 Metadaten von RFMs . . . . . . . . . . . . . . . . . . . 5.3.1 JCO.Repository und JCO.Function . . . . 5.3.2 JCO.ParameterList . . . . . . . . . . . . . . 5.4 Aufruf von RFMs . . . . . . . . . . . . . . . . . . . . . . 5.5 Beispiel: BAPI COMPANY GETLIST . . . . . . . . . . . . 6 Zugriff auf relationale Datenbanken mit 6.1 Technologie der JDBC . . . . . . . . . . 6.2 Verbindungsaufbau . . . . . . . . . . . . 6.3 Metadaten von Relationen . . . . . . . . 6.4 Ausf¨ uhren von SQL-Anweisungen . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

A ABAP Dictionary Datentypen

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

JDBC . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . . . . . .

. . . . . . .

. . . .

. . . . .

. . . . . . . .

. . . . . . .

. . . .

. . . . .

. . . . . . . .

. . . . . . .

. . . .

. . . . .

. . . . .

78 ii

Inhaltsverzeichnis

B CD-ROM

80

C Installationsanleitung C.1 Installation der Komponenten . . . . . . . C.2 Installation von Generic Web Services . . C.3 Aufruf . . . . . . . . . . . . . . . . . . . . C.4 Installation von Datenquellen-Middleware C.5 Integration von Datenquellen-Adaptern .

82 82 84 85 86 86

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Abbildungsverzeichnis

87

Tabellenverzeichnis

88

Literaturverzeichnis

90

iii

Vorwort Die Grundidee zur vorliegenden Arbeit entstand bei der T-Systems Nova GmbH, Entwicklungszentrum S¨ ud-West in Saarbr¨ ucken. Der Einsatz von SAP R/3 sowohl innerbetrieblich als auch bei Kundenunternehmen zur Abwicklung relevanter Gesch¨ aftsprozesse verlangte nach einer Technologie, die anderen, typischerweise in der Praxis SAP-fremden Systemwelten Zugriff auf die R/3-intern gehaltenen Daten gew¨ahrt. Vor dem Hintergrund, daß die Verwaltung dieser Rohdaten vorgegebenen und innerhalb der Applikationslogikebene des Systems spezifizierten betriebswirtschaftlichen Gesch¨aftsregeln und -operationen unterliegt, bietet R/3 zur Wahrung der Datenintegrit¨at keine system¨ ubergreifende direkte Schnittstelle zum Datenbanksystem. Die besondere Anforderung lag dabei vor allem bei der einfachen Anwendbarkeit der Technologie in der Praxis, der Plattform- und Programmiersprachenunabh¨ angigkeit sowie einer gr¨oßtm¨oglichen Wiederverwendbarkeit. Zwar konnte auf Grund der von R/3 unterst¨ utzten Kommunikationsschnittstellen auch bisher mit dem System interoperiert werden, allerdings mit hohem Aufwand: In Abh¨ angigkeit von der integrierenden Anwendung mussten ad-hoc“” Implementierungen die Anbindung u ¨ber die jeweils kompatible Schnittstelle zu R/3 realisieren, um Daten integrieren zu k¨onnen. Mit Beginn der Betreuungsphase durch den Lehrstuhl von Prof. Dr.-Ing. Weikum am Max-Planck-Institut f¨ ur Informatik in Saarbr¨ ucken wurde eine darauf aufbauende, verallgemeinernde Aufgabenstellung konkretisiert: Die Erzeugung von Web Services in einem automatisierten generischen Prozess sollte es erm¨ oglichen, individuell definierte Dienste bereitzustellen, die die Daten beliebiger aber jeweils fix spezifizierter Datenhaltungssysteme extrahierbar und modifizierbar und damit flexibel integrierbar machen. Die Ausarbeitung pr¨ asentiert gleichermaßen die notwendigen theoretischen Grundlagen zur Softwarearchitektur von Web Services, deren konkrete Umsetzung in der Praxis wie auch den Entwurf und die Realisierung einer Anwendung zur automatisierten Generierung und Bereitstellung dieser Softwaredienste. Die Implementierung der Prototyp-Applikation Generic Web Services in der Programmiersprache Java liegt dieser Arbeit zusammen mit allen zur Ausf¨ uhrung der vorliegenden Version n¨otigen Softwarekomponenten auf CD-ROM bei.

1

Die Realisierung dieser Diplomarbeit erfolgte in den R¨aumen der TSystems Nova GmbH, die unter anderem einen Zugang zu SAP R/3, erforderliche Softwarekomponenten sowie Know-how im Umgang mit dieser Systemumgebung zur Verf¨ ugung stellten.

2

Kapitel 1

Einleitung Der Entwurf von System- und Anwendungsarchitekturen basiert auf grundlegenden Konzepten. Anwendungen lassen sich prinzipiell drei funktionalen Ebenen zuteilen, die logisch betrachtet u ¨bereinander anzuordnen sind wie Abbildung 1.1 zeigt.

Abbildung 1.1: Die drei Ebenen einer Anwendung

Innerhalb der Datenebene befinden sich die Rohdaten, mit denen die Anwendung arbeitet. Sie werden entweder im Dateisystem gehalten (die Anwendung speichert die Datenebene selbst) oder sie sind, wie in den meisten F¨allen, in angeschlossenen Datenbanksystemen organisiert, die damit die Datenebene repr¨asentieren. Diese auch als Enterprise Information Layer bezeichnete Ebene kann auch Legacy-Systeme oder ERP-Systeme (Enterprise Resource Planning) beinhalten (z.B. SAP R/3). Die Applikationslogikebene enth¨alt die implementierten Anwendungsoperationen auf den Daten der Datenebene. Die Pr¨ asentationsebene stellt das Bindeglied zwischen der Anwendung und dem Benutzer dar. Sie pr¨ asentiert die Anwendung bzw. deren Ausf¨ uhrungsresulte auf irgendeine benutzerverst¨andliche Art. Typische Beispiele sind Webseiten oder anwendungsspezifische graphische Oberfl¨achen (z.B. SAP GUI). In immer st¨ arkerem Maße spielt in der heutigen Zeit die Vernetzung von Rechnern und damit das verteilte Computing eine wichtige Rolle. Das Internet als globales Netzwerk u ¨bernimmt dabei l¨angst nicht mehr nur die Aufgabe der reinen Pr¨ asentation von Informationen und Wissen. Vielmehr r¨ uckt immer

3

h¨aufiger beispielsweise unter dem Begriff des E-Business die Abwicklung von Gesch¨ afts- und Handelsbeziehungen in den Vordergrund. Unternehmen nutzen das Internet sowie das innerbetriebliche Intranet als Kommunikationsnetzwerk, um die t¨ aglich anfallenden Gesch¨aftsprozesse dezentral, automatisiert und somit zeit- und kostensparend in allen Funktionsbereichen wie Marketing, Vertrieb, Produktion, Logistik etc. durchzuf¨ uhren. Mit dem Internet ist die Basis f¨ ur ein einheitliches Kommunikationsmedium geschaffen, das als Standard gesetzt und anerkannt ist. Die auf den Schnittstellen aufgesetzten Anwendungsplattformen m¨ ussen dabei allerdings m¨oglichst flexibel sein, was die Integration verschiedener externer Informationssysteme oder Gesch¨ aftsabl¨ aufe und -einheiten in die bestehende IT-Landschaft betrifft. Von dieser Anforderung h¨ angen letztlich die Effizienz und die Akzeptanz des gesamten Systems ab. Nur wenn einzelne Applikationen Daten austauschen k¨onnen, k¨ onnen Erweiterungen und Optimierungen in der Gesch¨aftsprozesskette realisiert werden. Ein Vorteil der Integration von Unternehmens- oder E-Business-Anwendungskomponenten in vorhandene IT-Infrastrukturen ist somit aus betriebswirtschaftlicher Sicht offensichtlich: Prozessoptimierung, Kostensenkung und das Ziel, daraus einen gemeinsamen Mehrwert mit dem vernetzten Partner zu erlangen, sichern die Wettbewerbsf¨ahigkeit. Aus technischer Sicht st¨ oßt die Kopplung auch wenig komplexer Softwarekomponenten auf Grund unvereinbarer Technologien oder fehlender Schnittstellen immer wieder an Grenzen. Der Einsatz von webbasierten, d. h. u ¨ber das Internet bzw. Intranet kommunizierenden Systemarchitekturen ist noch keine hinreichende Voraussetzung f¨ ur die Realisierung von unternehmens¨ ubergreifenden, verteilten Prozessen in einem Rechnerverbund. Existiert hier keine einheitliche oder zumindest klar definierte Struktur bei der Darstellung von Informationen und sind diese nur u ¨ber system- und anbieterspezifische Technologien austauschbar, ist eine Anbindung von Fremdsystemen meist unm¨oglich oder unrentabel. Als Ausgangssituation f¨ ur dieses Szenario betrachte man zun¨achst die typische Architektur eines webbasierten Systems. Die drei Ebenen einer Anwendung k¨ onnen verschiedenen Komponentenschichten (tiers) zugeteilt werden wie Abbildung 1.2 darstellt. Die drei Anwendungsebenen lassen sich dabei wie folgt auf die Komponentenschichten verteilen: Die Datenebene wird durch den Datenserver (tier 4) repr¨asentiert, w¨ ahrend der Applikationsserver (tier 3) die Applikationslogikebene abdeckt. Tier 1 und tier 2 bilden schließlich zusammen die Pr¨asentationsebene. Informationsanfragen, die der Benutzer von einem Client aus in der Regel u uhrung ¨ber einen Browser formuliert, nimmt der Webserver entgegen. Die Ausf¨ der entsprechenden Anwendungslogik u ¨bernehmen innerhalb des Applikationsserver laufende Programme. Dabei stehen notwendige Daten in separat gehaltenen Datenhaltungssystemen zur Verf¨ ugung. Was nun im beispielhaft angef¨ uhrten E-Business-Szenario von Interesse ist, ist die Realisierung der Verteilung der Applikationslogik auf mehrere am 4

1.1. Problemstellung

Abbildung 1.2: 4-Tier-Architektur1 eines webbasierten Systems

Netzwerk beteiligte Rechnersysteme. Erm¨oglicht man die Kommunikation einzelner Anwendungskomponenten untereinander, k¨onnen Gesch¨aftsprozesse hier die Unternehmensgrenzen u ¨berschreiten. Bestehende Business-L¨osungen oder Informationssysteme unterschiedlicher Anbieter k¨onnen integriert werden, und so kann das Unternehmen auf zunehmende Anforderungen flexibel reagieren. Die Motivation f¨ ur den Einsatz verteilter Anwendungsarchitekturen liegt nicht ausschließlich in der Integrierbarkeit existierender (Fremd-)L¨osungen und steht unter dem erw¨ ahnten wirtschaftlichen Gesichtspunkt. Skalierbarkeit und Lastenverteilung sind nur zwei Schlagw¨orter bei der Betrachtung der technischen Aspekte. Abbildung 1.3 zeigt die ver¨anderte Situation in der Anwendungsschicht eines verteilten Systemkonzepts.

Abbildung 1.3: Webbasiertes System mit verteilter Applikationslogik

1.1

Problemstellung

Die Fragestellung und damit die Problematik, die sich im technischen Kontext ergibt, ist, wie die Bereitstellung und Nutzung, d. h. die Kommunikation mit 5

1.1. Problemstellung

den Anwendungen erfolgen kann, die auf Systemen implementiert sind, die sich in der Praxis h¨ aufig durch eine heterogene Hard- und Softwareumgebung auszeichnen. Es m¨ ussen Schnittstellen gegeben sein, die Dienste zum Austausch verteilter Anwendungsobjekte anbieten. Diesbez¨ uglich verf¨ ugbare MiddlewareTechnologien m¨ ussen in der Lage sein, von gegebenen Hard- und Softwarearchitekturen zu abstrahieren, um so plattform- und programmiersprachenunabh¨angig die Kommunikation mit komponentenorientierten Applikationen zu erm¨ oglichen. Hier pr¨ asentieren verschiedene Technologiehersteller L¨osungen. Zum Beispiel stellt Microsoft f¨ ur Windows-Plattformen den DCOM-Standard (Distributed Component Object Model) [5] zur Verf¨ ugung, somit allerdings eine Einschr¨ ankung auf Windows-Systeme. Mit CORBA (Common Object Request Broker Architecture) [6] existiert ein weit verbreiteter Ansatz f¨ ur E-BusinessL¨osungen der Object Management Group (OMG). Dieser wurde von Unternehmen wie IBM und der Sun Microsystems, Inc. weiterentwickelt und stan¨ dardisiert. Der Einsatz von CORBA erm¨oglicht zwar eine Uberschreitung von Betriebssystem- und Programmiersprachengrenzen, Applikationen, die auf diesem Konzept basieren, sind aber dennoch abh¨angig von anbieterspezifischen Implementierungen: Die Schnittstelle zum verteilten Objekt und deren Beschreibung m¨ ussen in den Sprachen spezifiziert und angeboten werden, von denen aus ein Zugriff erw¨ unscht ist2 . An dieser Stelle treten Web Services als Middleware-Konzept in den Vordergrund. Bei der Realisierung von verteilter Anwendungsfunktionalit¨at setzen Web Services auf bereits etablierte plattform- und sprachenunabh¨angige Technologien. Die beispielhaft erl¨ auterten Einschr¨ankungen im Umgang mit vorherrschenden L¨ osungen zur Realisierung verteilter Anwendungsfunktionalit¨at werden von Web Services durch Standardisierungen umgangen. Die Festlegung auf das Kommunikationsprotokoll SOAP, welches Vorschriften f¨ ur die Formatierung auszutauschender Daten zwischen verteilten Anwendungen definiert, stellt dabei die eigentliche Neuerung dar. Ebenso wie SOAP basiert auch die Schnittstellenbeschreibungssprache WSDL f¨ ur Web Services auf XML (eXtensible Markup Language) [17]. Auch ¨ bei der Verwendung des Tr¨ agerprotokolls zur Ubermittlung der Daten wird die Zielsetzung von Web Services deutlich: Offene Internet-Standards wie das u ¨berwiegend eingesetzte HTTP (HyperText Transfer Protocol) [15] sichern eine plattform¨ ubergreifende Kommunikation und eine standardisierte Verf¨ ugbarkeit. Andererseits sind Konzepte wie die der entfernten Methodenaufrufe (Remote Procedure Call ) oder der serviceorientierten Architektur von Web Services keine neue Erfindung. Auf Grund ihres zus¨atzlichen Grades an Plattformund Programmiersprachenunabh¨angigkeit und der breiten Verf¨ ugbarkeit von Webserver-Architekturen scheint mit Web Services allerdings eine verteilte 2

CORBA verwendet hier die sogenannte Interface Definition Language (CORBA IDL), vgl. [23, 6]. Sie ist an die Programmiersprache C++ angelehnt.

6

1.2. Zielsetzung

Ausf¨ uhrungstechnologie gefunden, die eine L¨osung der Problematik verspricht.

1.2

Zielsetzung

Ziel dieser Arbeit ist es, Web Services einzusetzen, um die Anbindung von Datenhaltungssystemen zu implementieren und damit im verteilten System transparent anzubieten. Die Kommunikation mit Datenservern u ¨ber spezifi¨ sche propriet¨ are Middleware wird im Web Service gekapselt. Uber definierte Schnittstellen werden die Daten innerhalb der Applikationsschicht zugreifbar und integrierbar gemacht. Die Architektur in Abbildung 1.4 veranschaulicht das Konzept.

Abbildung 1.4: Webbasiertes System mit Web Services zur verteilten Datenserveranbindung

Unter Ausnutzung der gegebenen Standardisierung der Komponenten soll eine generische Erzeugung der Web Services realisiert werden: Die Spezifizierung von Schnittstelle und Schnittstellenbeschreibung (WSDL), die den Web Service identifizieren, m¨ ussen ebenso generisch realisiert werden wie dessen Implementierung, die schließlich im Applikationsserver zugreifbar wird. Die Aufgabe der Web Service Implementierungen soll es sein, Methoden im verteilten System zur Verf¨ ugung zu stellen, die – je nach erfolgtem Generierungsprozess – eine Selektion oder Manipulation auf Daten eines Datenhaltungssystems ausf¨ uhren und somit diese Funktionalit¨ at im Ready-to-use“-Format anbieten und ver” breiten k¨ onnen. In der Realisierung werden in Abh¨angigkeit des Anbieters eines Datenhaltungssystems (ORACLE, MySQL, Microsoft SQL Server, SAP R/3, etc.) spezifische Middleware-Implementierungen den Zugriff innerhalb des Web Service u ussen dann daf¨ ur sorgen, die Da¨bernehmen. Generische Datenstrukturen m¨ ten systemkonform zu halten, d. h. vorgegebene Datenschemata und -relationen m¨ ussen vom Web Service gewahrt werden, um die Datenintegrit¨at im System zu erhalten. Gleichzeitig k¨ onnen u ¨ber diese Datenstrukturen Methodenparamter definiert werden, um eine Spezifizierung der zu selektierenden oder manipulierenden Daten im Datenhaltungssystem zu erm¨oglichen. Wie noch zu erl¨autern 7

1.3. Gliederung der Arbeit

sein wird, dienen die Metadaten der jeweiligen Datenquelle dazu, diese Strukturen zu erzeugen. Es sei an dieser Stelle explizit darauf hingewiesen, dass die im Rahmen dieser Arbeit betrachteten Datenhaltungssysteme auf dem relationalen Datenmodell beruhen. Auch die 3-Tier-Architektur des SAP R/3 nutzt auf Datenebene relationale Datenbanksysteme (vgl. 4.1). Zus¨ atzlich zur Generierung der eigentlichen Web Service Komponenten muss die M¨ oglichkeit zur Erzeugung einer passenden Client-Anwendung gegeben sein. Ziel ist es, nicht nur einen Client auf Programmierebene, sondern auch im Sinne einer graphischen Benutzeroberfl¨ache umzusetzen. Die Realisierung des Generierungsprozesses erfolgt innerhalb der Implementierung des Projektes Generic Web Services.

1.3

Gliederung der Arbeit

Die Kapitel 2 und 3 der vorliegenden Arbeit dienen der Einf¨ uhrung in die Thematik der Web Services: Kapitel 2 gibt eine Definition f¨ ur verteilte Systeme und stellt das allgemeine Konzept des Remote Procedure Call zum Zugriff auf Anwendungen sowie die grundlegende Architektur von Middleware-L¨osungen im verteilten System vor. In Kapitel 3 werden diese Aspekte aufgegriffen und in ihrer speziellen Auspr¨ agung im Kontext der Web Services als Middleware ¨ dargestellt. Dabei wird insbesondere auf die Spezifikation des Ubertragungsprotokolles SOAP sowie der Schnittstellenbeschreibungssprache WSDL von Web Services eingegangen. Kapitel 4 f¨ uhrt grundlegend in das SAP R/3-System ein. Angefangen bei der Systemarchitekur werden die bedeutenden Softwarekonzepte unter Betrachtung des sogenannten Business Framework erl¨autert. Von besonderem Interesse sind hier spezielle Schnittstellen, die R/3 bietet und letztlich diese Arbeit motiviert haben. Kapitel 5 und 6 befassen sich mit speziellen Middleware-Technologien, einerseits f¨ ur die Anbindung an ein SAP R/3-System, andererseits f¨ ur die Anbindung von relationalen Datenbanksystemen. Beide Ans¨atze basieren auf Java und werden in der Verwendung ihrer wichtigsten Funktionalit¨aten beschrieben. Mit Kapitel 7 beginnt der Einstieg in die Webapplikation Generic Web Services. Hier werden zun¨ achst die grundlegenden Anforderungen beschrieben, die an Web Services bez¨ uglich ihrer Architektur zu stellen sind. Weiterhin werden Forderungen an Generic Web Services gestellt, was die konkrete Auspr¨agung bzw. Implementierung der zu generierenden Web Services angeht. Der allgemeine Entwurf der Applikation

8

Kapitel 2

Konzepte verteilter Ausfu ¨ hrungsplattformen Die in diesem Kapitel betrachteten Konzepte sollen keineswegs eine vollst¨andige Bearbeitung des Themenkomplexes Verteilte Systeme“ darstellen, sondern ” lediglich in die im Hinblick auf eine Einordnung der Technologie Web Services notwendigen Zusammenh¨ ange einf¨ uhren.

2.1

Definitionen

2.1.1

Verteiltes System

Bis in die 80iger Jahre liefen Computeranwendungen zentralisiert auf einem System. Mit der Entwicklung und zunehmenden Popularit¨at von Datenbanken und Netzwerken entstanden die mit heutiger Terminologie bezeichneten 2-Tier- bzw. Zwei-Schicht-Anwendungen. Zu der Zeit etablierte sich der Begriff der Client/Server-Systeme“. Anwendungen wurden zerlegt in einen Ap” plikationsclient und einen Datenbankserver [23]. Die fortschreitende technische Entwicklung erlaubte unter anderem eine mehr und mehr zunehmende Vernetzung und somit immer gr¨ oßere Rechnerverbundsysteme, so dass schließlich dazu u ¨bergegangen wurde, einzelne am Verbund beteiligte Systeme mit ihren Anwendungen nach außen transparent zu halten, d. h. bei Ausf¨ uhrung eines Programmes war f¨ ur den Benutzer nicht mehr nachvollziehbar, wo Systemressourcen und wie viele davon in Anspruch genommen wurden. Der Begriff der verteilten Systeme“ kam auf. ” In der einschl¨ agigen Literatur findet sich diesbez¨ uglich beispielsweise die Definition von Tanenbaum [13]: A distributed system is a collection of independent computers that ” appear to the users of the system as a single computer.“ Im Bereich der Softwareumgebung mußten offene Standards geschaffen werden, um es zu erm¨ oglichen, Anwendungen auf entfernten autonomen Sy9

2.2. Middleware-Technologien

stemen dynamisch zu integrieren. Mit der damaligen Version des Distributed Computing Environment-Standards (DCE) der Open Software Foundation (OSF)1 , einem low-level Request/Response-Modell, wurden von der Sun Microsystems, Inc. und Microsoft entfernte Prozeduraufrufe (Remote Procedure Call, RPC) realisiert [2]. Das Prinzip von RPC bildet auch aus heutiger objektorientierter Sicht die Grundlage f¨ ur Middleware-Technologien. RPC wird in diesem Kontext in Abschnitt 2.2.1 untersucht.

2.1.2

Middleware

Als Middleware bezeichnet man Dienste, die verteilte Anwendungen integrieren, die Systemplattform mit einzelnen Applikationen verbinden oder die Integration von Softwareanwendungen untereinander herstellen. Die Middleware-Ebene ist eine Sammlung verschiedener Technologien und Plattformen zum objektorientierten, direkten Datenaustausch zwischen verschiedenen Applikationen. Middleware konvertiert die Informationen mehrerer Softwaretypen und befindet sich in der Regel zwischen einer Anwendung und • einem Betriebssystem, • einem Netzwerkbetriebssystem oder • einem Datenbankmanagementsystem.

2.2

Middleware-Technologien

In [13] wird zwischen vier verschiedenen Middleware-Auspr¨agungen unterschieden. Dies sind insbesondere RPC, welches im Folgenden genauer zu beschreiben sein wird, sowie datenzugriffsorientierte Middleware, nachrichtenorientierte Middleware und objektorientierte Middleware. Da die letzten drei genannten Typen f¨ ur diese Ausarbeitung keine wesentliche Rolle spielen, werden sie nicht weiter betrachtet2 .

2.2.1

Remote Procedure Call (RPC)

Der Mechanismus des Remote Procedure Call macht es innerhalb verteilter Architekturen m¨ oglich, Anwendungen auf entfernten Rechnern u ¨ber ein Netzwerk-Protokoll aufzurufen, wobei mit der Entwicklung der objektorientierten Programmiersprachen in den 90er Jahren das Konzept modifiziert werden 1

heute als Open Group bekannt Datenzugriffsorientierte Middleware ist nach Kategorisierung in [13] im Kontext von f¨ oderierten Datenbanken zu sehen. Insofern f¨ allt der in dieser Arbeit implementierte DatenbankAdapter zur Anbindung relationaler Datenbanksysteme nicht in diese Kategorie. 2

10

2.3. Service-oriented architecture (SOA)

mußte. Es gilt nunmehr die Anforderung, Objekte client- und serverseitig u ¨ber Protokolle zu referenzieren (ORPC) und deren Methoden aufzurufen. Aufrufende Objekte m¨ ussen vom Client f¨ ur den Transport protokollkonform serialisiert und vom Server zu einem programmiersprachenkonformen Objekt deserialisiert werden, so daß ein aufgerufenes Objekt (Endpoint) initiiert werden kann. Entfernte und lokale Methodenaufrufe unterscheiden sich dabei prinzipiell nicht. Das grundlegende Prinzip von RPC-implementierenden Architekturen besteht darin, die Verteilung durch Stellvertreterobjekte“ (Stubs und Skele” tons) zu abstrahieren und so vor den Kommunikationspartnern zu verbergen. Das verteilte Serverobjekt wird von seinem Skeleton durch eine Schnittstelle beschrieben, die das Stub-Objekt clientseitig implementiert und somit das Serverobjekt lokal repr¨ asentiert.

Abbildung 2.1: RPC mit Stub und Skeleton

Das Client-Objekt ruft die Methode lokal in seinem Stub auf. Gem¨aß der verwendeten RPC-basierten Middleware erfolgt zun¨achst das als Marshalling bezeichnete Verpacken“ der Anfrage zum Methodenaufruf zusammen mit der ” Serialisierung des Stub-Objektes sowie zu u ¨bergebender Parameter. Das serverseitige Skeleton-Objekt f¨ uhrt ein Unmarshalling und Deserialisieren aus und ruft die Methode auf dem vom Stub referenzierten Server-Objekt auf. Der R¨ uckgabenwert der Methode wird schließlich an den Client zu¨ uckgesendet. Um Verwirrungen zu vermeiden sei noch erw¨ahnt, daß die CORBA- und DCOM-Architekturen, die dieses Prinzip implementieren, an dieser Stelle unterschiedliche Bezeichnungen verwenden: Die hier verwendeten Namen Stub“ ” und Skeleton“ entsprechen der CORBA-Terminologie. Unter DCOM werden ” sie als Proxy“ und Stub“ bezeichnet. ” ”

2.3

Service-oriented architecture (SOA)

Die M¨ oglichkeit, Softwarekomponenten in einem verteilten System als Dienste anzubieten, die u ¨ber das Netzwerk abgerufen werden k¨onnen, zum Beispiel durch RPC-Mechanismen, stellt zus¨atzliche Anforderungen an die Architektur der zugrunde liegenden Middleware-Technologien.

11

2.3. Service-oriented architecture (SOA)

2.3.1

Anforderungen und Modell

Serviceorientierte Architekturen (SOA) zeichnen sich dadurch aus, daß sie auf Basis einer Menge von m¨ oglichst unabh¨angigen Formaten und Protokollen Dienste gem¨ aß folgenden Anforderungen anbieten k¨onnen: • Es erfolgt eine strikte Trennung der Schnittstellenmodellierung und der Implementierung der Applikationslogik. Durch diese lose Kopplung kann einerseits die Komplexit¨ at der Logik dadurch verborgen bleiben, dass lediglich eine sehr kleine Anzahl an Zugriffsmethoden f¨ ur bestimmte Funktionalit¨ aten bereitgestellt werden, andererseits beeinflussen interne Modifikationen nicht zwangsl¨ aufig den verteilten Zugriff. • Das dynamische Auffinden von Diensten bzw. Schnittstellen bereitgestellter Applikationslogik kann auf Grund von spezifischen Beschreibungen erm¨ oglicht werden. • Eine einfache Integration und ein Austausch der Dienste in bestehenden Umgebungen resultiert aus einer losen Kopplung sowie der Verwendung von plattform- und programmiersprachenunabhngigen Protokollen (Wiederverwendbarkeit). Auf dieser Grundlage kann eine Definition einer serviceorientierten Architektur wie der in [1] gegeben werden: An architecture that uses a distributed, discovery-based execution ” environment to expose and manage a collection of service-oriented software assets.“ Abbildung 2.2 [12] visualisiert das Anforderungskonzept, das entsprechend u origen Operationen spezifiziert werden kann. ¨ber drei Rollen und zugeh¨

2.3.2

Service Provider

Der Service Provider tr¨ agt die Implementierung des Dienstes und legt die Funktionalit¨ at fest, die innerhalb der Architektur o¨ffentlich gemacht wird. Die entsprechenden Schnittstellen werden u ¨ber IDL (Interface Definition Language), einer architektureigenen Beschreibungssprache, abgebildet, dem Service Broker zur Verf¨ ugung gestellt und registriert.

2.3.3

Service Broker

Der Service Broker verwaltet als zentral zugreifbare Einheit die Informationen der ver¨ offentlichten Dienste. Dazu geh¨oren gleichermaßen semantische Beschreibungen, Informationen u ¨ber die Erreichbarkeit des Service Provider sowie

12

2.3. Service-oriented architecture (SOA)

Abbildung 2.2: Service-oriented architecture (SOA)

die Spezifizierung des Zugriffsmechanismus (zum Beispiel RPC). Als Repository dient der Broker gleichzeitig dem Service Consumer, indem er registrierte Dienste klassifizieren und so auf Suchanfragen der Consumer reagieren und entsprechende Informationen liefern kann.

2.3.4

Service Consumer

Der Service Consumer ist der Nutzer der Dienste. Er erh¨alt vom Service Broker u ¨ber die Interaktion suchen alle notwendigen Informationen, um einen Dienst zu lokalisieren und zu binden: Die detaillierte Auskunft, die die Schnittstellenbeschreibung u ¨ber den Dienst gibt, wird vom Consumer genutzt, um eine Ausf¨ uhrungsanfrage einschließlich der erforderlichen Parameter zu erzeugen und an den Provider zu senden. Das vorgestellte Modell stellt eine Standard-Architektur f¨ ur verteilte Systeme dar. Die herstellerspezifischen Protokolle, Schnittstellenbeschreibungssprachen, RPC-Implementierungen, etc. sind jedoch vielf¨altig. Um einen Ein¨ blick zu erlangen, wird in Tabelle 2.1 eine Ubersicht u ¨ber bekannte SOAImplementierungen und deren Formate gegeben3 . Von Standardisierung und Plattformunabh¨ angigkeit kann demnach nicht die Rede sein.

3

Es werden lediglich die Abk¨ urzungen der genannten Technologien erl¨ autert. Auf eine detaillierte Beschreibung kann verzichtet werden.

13

2.3. Service-oriented architecture (SOA)

Java RMI1

CORBA

DCE

Web Services

Java RMI

CORBA RMI

RPC

JAX-RPC, .NET, . . .

Serialized Java

CDR2

NDR3

XML

Stream

GIOP4

PDU5

SOAP

JRMP6

IIOP7

RPC CO8

HTTP, SMTP, . . .

InterfaceBeschreibung

Java Interface

CORBA IDL

DCE IDL

WSDL

AuffindMechanismus

Java Registry

COS naming9

CDS10

UDDI

AufrufMechanismus DatenFormat ¨ UbertragungsFormat ¨ UbertragungsProtokoll

Tabelle 2.1: Beispiele f¨ ur SOA Formate und Protokolle

An dieser Stelle treten Web Services in den Vordergrund: Die Realisierung dieser Internet-Middleware“ mit ihren XML-basierter Komponenten ” erm¨ oglicht nicht zuletzt eine herstellerunabh¨angige serviceorientierte Architektur. Applikationen k¨ onnen flexibel und nach offenen Standards komponentenweise von Grund auf (bottom-up) entwickelt und integriert werden. Speziell im B2B-Umfeld ist es von Interesse, zeit- und kostenkritische Entwicklungen und Modifikationen auf die Wiederverwendung verf¨ ugbarer Dienste mit existierenden Basistechnologien zu reduzieren. Das Konzept der SOA aus der Sicht von Web Services bildet daher die Grundlage f¨ ur die Umsetzung der Aufgabenstellung dieser Arbeit. Das folgende Kapitel behandelt ausf¨ uhrlich die charakteristischen Technologiespezifikationen.

1

Java Remote Method Invocation Common Data Representation 3 Network Data Representation 4 General Inter-ORB Protocol 5 Protocol Data Units 6 Java Remote Method Protocol 7 Internet Inter-ORB Protocol 8 Remote Procedure Call Connect-Oriented protocol 9 CORBA Object Services naming 10 Cell Directory Service 2

14

Kapitel 3

Web Services 3.1

Definition

Der Begriff Web Service“ umschreibt eine Technologie, die die Interaktion ” zweier Systeme u ¨ber ein Netzwerk erm¨oglicht. Dabei bedient sie sich typischerweise des Internet-Protokolls HTTP bei der Daten¨ ubertragung und st¨ utzt ihre Kommunikationssprache und ¨ offentlichen Schnittstellendefinitionen auf die Beschreibungssprache XML. Das World Wide Web Consortium (W3C) gibt mit Beginn der Entwicklung einer Referenz-Architektur die folgende Definition eines Web Service[19]: A Web Service is a software application identified by a URI, whose ” interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via Internetbased protocols.“ Web Services implementieren jedoch keine Client/Server-Architektur im Sinne einer direkten Interaktion mit einem Benutzer wie zum Beispiel das Zusammenspiel von Webserver und Webseite verstanden werden kann. Web Services bieten keine graphische Benutzeroberfl¨ache. Die Kommunikation umfasst den Austausch von Applikationslogik, Daten und Prozessen mit anderen Anwendungen u ¨ber eine Programmschnittstelle. Programme stellen somit die Kommunikationspartner auf beiden Seiten dar. Stattdessen k¨onnen Web Service Clients u ugung ¨ber ein GUI initiiert und vom Web Service Provider zur Verf¨ gestellte Funktionalit¨ at integriert und dem Benutzer visuell dargeboten werden. Praktisch umgesetzt wird dieser Ansatz im Kontext der vorliegenden Aufgabenstellung: Der Prozess der Generierung der Web Services beinhaltet gleichermaßen ein webbasiertes Frontend, Web Service Invocation Framework (WSIF) genannt (siehe Kapitel 9.3).

15

3.2. Web Services architecture (WSA)

3.2

Web Services architecture (WSA)

Das Grundkonzept der serviceorientierten Architektur wurde bereits in 2.3 vorgestellt. Web Sevices implementieren diese Architektur mit Hilfe dreier XMLbasierter Formate: • Simple Object Access Protocol (SOAP) • Web Services Description Language (WSDL) • Universal Description, Discovery and Integration (UDDI) Betrachtet man diese im Kontext von Web Services eingesetzten Technologien kann die Abbildung 2.2 zu einer Web Services Architektur (WSA) konkretisiert werden [12]:

Abbildung 3.1: Web Services architecture (WSA)

3.3

Simple Object Access Protocol (SOAP)

Das Simple Object Access Protocol (SOAP) wird in der Spezifikation 1.1 als ein einfacher Mechanismus f¨ ur den Austausch strukturierter und typisierter ” Informationen zwischen Rechnern in einer dezentralen verteilten Umgebung auf Basis von XML“ beschrieben [16]. Eine andere Definition nennt SOAP ein XML-/HTTP-basiertes Protokoll f¨ ur den plattformunabh¨angigen Zugriff ” auf Dienste, Objekte und Server“. Die Entwicklung von SOAP wurde 1998 von Microsoft und anderen Firmen begonnen. Im gleichen Jahr hat sich aus einer fr¨ uhen Version der Spezifikation das Protokoll XML-RPC [21] abgespalten. Eine erste Version von SOAP hat Microsoft dann im November 1999 u ¨ber die Internet Engineering Task Force (IETF) ver¨ offentlicht, woraufhin sich Firmen wie IBM, SAP AG und andere der 16

3.3. Simple Object Access Protocol (SOAP)

Entwicklungsgruppe um Microsoft anschlossen. Im Mai 2000 wurde die SOAP Spezifikation in der Version 1.1 beim World Wide Web Consortium (W3C) eingereicht. Aufgrund seiner breiten Unterst¨ utzung in der Softwareindustrie ist SOAP 1.1 aber als De-facto-Standard zu bezeichnen. In diesem Abschnitt werden zun¨achst die bedeutendsten Aspekte der SOAP Spezifikation herausgearbeitet. Der Begriff Web Services“ und dazu” geh¨orige Technologien, vor allem die f¨ ur SOAP oft verwendete Schnittstellenbeschreibungssprache WSDL, werden im Anschluss daran kurz vorgestellt. Aus Komplexit¨ atsgr¨ unden m¨ ussen viele Details der Spezifikationen vorenthalten bleiben.

3.3.1

SOAP Nachricht

Die SOAP Spezifikation definiert eine XML Grammatik, mit der strukturierte und typisierte Informationen zu einer Nachricht zusammengefasst werden k¨onnen. Eine SOAP Nachricht ist ein XML-Dokument, auch Umschlag (Envelope) genannt, das einen optionalen Kopfinformations-Teil (Header ) und den eigentlichen Inhaltsteil (Body) enth¨alt. Listing 3.1 zeigt den grunds¨atzlichen Aufbau einer SOAP-Nachricht.



Listing 3.1: Aufbau einer SOAP Nachricht Der SOAP Envelope geh¨ort zum XML Namespace1 "http://schemas.xmlsoap.org/ soap/envelope/". Der Body als eigentlicher Nutzdaten-Teil einer SOAP Nachricht muss genau einmal im SOAP Envelope vorkommen und zwar als direktes Kind-Element des Envelope. Der Body wiederum kann beliebig viele direkte Kind-Elemente enthalten, die sogenannten Body-Elemente. 1

XML Namespace ist ein W3C-Standard f¨ ur Namensr¨ aume in XML Dokumenten zur Vermeidung von Namenskollisionen. Namensr¨ aume werden durch einen Uniform Resource Identifier (URI) gekennzeichnet, k¨ onnen in XML-Dokumenten u ¨ber das Attribut xmlns eingef¨ uhrt werden und erhalten dabei einen Kurznamen (z. B. xmlns:meinns="http://meine.firma.org/meinns"). Namen k¨ onnen qualifiziert verwendet werden, indem der lokale Teil – durch einen Doppelpunkt abgetrennt – von einem Namensraum-Pr¨ afix erg¨ anzt wird (z. B. meinns:einname). Ein solcher namensraumqualifizierter Name wird auch als QName bezeichnet.

17

3.3. Simple Object Access Protocol (SOAP)

3.3.2

Kodierung und Datentypen

Die Kodierung der in den Body-Elementen u ¨bertragenen Daten kann mit dem Attribut encodingStyle f¨ ur jedes Body-Element einzeln festgelegt werden. Die Angabe des encodingStyle-Attributes im EnvelopeElement legt eine Standard-Kodierung fest, die verwendet wird, falls in den Kind-Elementen keine eigene Kodierung festgelegt wurde. Die SOAP Spezifikation schl¨ agt eine Kodierung vor, die u ¨ber den Namensraum "http://schemas.xmlsoap.org/soap/encoding/" verwendet werden kann. Sie basiert auf einem einfachen Typsystem, das die wichtigsten Typen g¨angiger Programmiersprachen abdeckt. Das Typsystem unterscheidet einfache und zusammengesetzte Datentypen. Die SOAP Spezifikation u ¨bernimmt als einfache Datentypen die Datentypen von XML Schema [18]. Das sind unter anderem: • int : Integer-Wert • float : Fließkommawert • string : Zeichenkette • enumerations Mengen zul¨assiger Werte • array of bytes Bin¨ ardaten Da in XML die Daten vollst¨ andig im Klartext erscheinen, wird ein XMLDokument unn¨ otig aufgebl¨ aht, wenn derselbe Wert mehrfach vorkommt. Deshalb kann Elementen u ¨ber das optionale Attribut id ein Identifikator zugewiesen werden. Geschieht dies wie im folgenden Beispiel bei einem String-Element, k¨onnen andere String-Elemente u ¨ber das Attribut href auf den String des ersten Elements verweisen: Mustermann

Die Elemente name bzw. suchname in diesem Beispiel werden auch als Zugriffselemente (accessor ) f¨ ur den String Mustermann bezeichnet. Zu Datenelementen in einer SOAP Nachricht kann der Typ explizit angegeben werden. Dies geschieht u ¨ber das Attribut xsi:type aus dem Namensraum "http://www.w3.org/2001/XMLSchema-instance", der u ¨blicherweise mit xsi bezeichnet wird. Der Datentyp selbst kann direkt aus XML Schema [18] entnommen werden, der Namensraum lautet dann "http://www.w3.org/2001/XMLSchema" (die u ¨bliche Kurzbezeichnung lautet xsd). Die SOAP Datentypen sehen aber einige Besonderheiten vor. So sind z. B. die oben beschriebenen String-Referenzen mit den Attributen id und href nicht in der XML Schema Definition enthalten. Sollen die Besonderheiten genutzt werden, ist der Namensraum 18

3.3. Simple Object Access Protocol (SOAP)

"http://schemas.xmlsoap.org/soap/encoding/" zu verwenden (die u ¨bliche Kurzbezeichnung lautet SOAP-ENC). Das folgende Beispiel zeigt die explizite Angabe des Elementtyps unter der Annahme, dass die Namensr¨aume xsd, xsi und SOAP-ENC an fr¨ uherer Stelle in der SOAP Nachricht eingef¨ uhrt wurden. Diese Annahme gelte in allen folgenden Beispielen dieses Abschnitts. Mustermann

Auf die explizite Angabe des Datentyps kann verzichtet werden, wenn sich der Typ aus einer Schema-Beschreibung (z. B. einem WSDL-Dokument, siehe Abschnitt 3.4) ergibt. Viele Programmiersprachen sehen universelle Datentypen vor, deren Instanzen die Werte von verschiedenen Typen annehmen k¨onnen (in CORBA z. B. der Typ any). SOAP unterst¨ utzt solche universellen Datentypen mit den sogenannten polymorphen Zugriffselementen (polymorphic accessors). Instanzen dieses universellen Datentyps m¨ ussen ihren Typ immer explizit angeben. Neben den einfachen Datentypen unterst¨ utzt SOAP auch die folgenden zusammengesetzten Datentypen: • struct : entspricht den aus Programmiersprachen bekannten Strukturen bzw. Records. Die Namen der Zugriffselemente dienen als einzige Unterscheidung zwischen den Attributen. Die Reihenfolge ist also nicht relevant. struct-Typen sind durch ein eigenes Schema in einem eigenen Namensraum zu definieren. Ein Beispiel f¨ ur eine Instanz des structTyps ist Adresse: