Post on 11-Aug-2019
transcript
Generische Anbindung von Datenhaltungssystemen
mit Web Services
am Beispiel von SAP R/3
Diplomarbeit
Jorg Diesinger
Naturwissenschaftlich-Technische Fakultat I
der Universitat des Saarlandes
November 2004
Hiermit erklare ich an Eides statt, dass ich die vorliegende Arbeit
selbststandig verfasst und keine anderen als die im Literaturverzeichnis an-
gegebenen Quellen verwendet habe.
Saarbrucken, 30. November 2004
(Jorg Diesinger)
Inhaltsverzeichnis
Vorwort 1
1 Einleitung 3
1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . 8
2 Konzepte verteilter Ausfuhrungsplattformen 9
2.1 Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Verteiltes System . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Middleware-Technologien . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Remote Procedure Call (RPC) . . . . . . . . . . . . . . 10
2.3 Service-oriented architecture (SOA) . . . . . . . . . . . . . . . 11
2.3.1 Anforderungen und Modell . . . . . . . . . . . . . . . . 12
2.3.2 Service Provider . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3 Service Broker . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4 Service Consumer . . . . . . . . . . . . . . . . . . . . . 13
3 Web Services 15
3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Web Services architecture (WSA) . . . . . . . . . . . . . . . . . 16
3.3 Simple Object Access Protocol (SOAP) . . . . . . . . . . . . . 16
3.3.1 SOAP Nachricht . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 Kodierung und Datentypen . . . . . . . . . . . . . . . . 18
3.3.3 SOAP fur RPC . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Web Services Description Language (WSDL) . . . . . . . . . . 21
3.5 Universal Description, Discovery and Integration (UDDI) . . . 24
4 SAP R/3 25
4.1 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Business Framework . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Business-Komponenten . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Business-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . 28
i
Inhaltsverzeichnis
4.5 Business Application Programming Interfaces (BAPIs) . . . . . 31
4.5.1 Merkmale von BAPIs . . . . . . . . . . . . . . . . . . . 32
4.5.2 Vorteile von BAPIs . . . . . . . . . . . . . . . . . . . . . 33
4.5.3 Voraussetzungen fur den Zugriff auf BAPIs . . . . . . . 34
4.5.4 Zugriffsmoglichkeiten . . . . . . . . . . . . . . . . . . . . 36
4.5.5 Beispiel: Company.GetList() . . . . . . . . . . . . . 37
4.6 Integrationsdienst ALE (Application Link Enabling) . . . . . . 40
4.7 Remote Function Call (RFC) . . . . . . . . . . . . . . . . . . . 41
5 Zugriff auf SAP R/3 mit SAP Java Connector (JCo) 42
5.1 Technologie des JCo . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 Metadaten von RFMs . . . . . . . . . . . . . . . . . . . . . . . 46
5.3.1 JCO.Repository und JCO.Function . . . . . . . . 46
5.3.2 JCO.ParameterList . . . . . . . . . . . . . . . . . . 47
5.4 Aufruf von RFMs . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5 Beispiel: BAPI COMPANY GETLIST . . . . . . . . . . . . . . . . 49
6 Zugriff auf relationale Datenbanken mit JDBC 51
6.1 Technologie der JDBC . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3 Metadaten von Relationen . . . . . . . . . . . . . . . . . . . . . 54
6.4 Ausfuhren von SQL-Anweisungen . . . . . . . . . . . . . . . . . 55
7 Anforderungen 57
7.1 Anforderungen an Web Services . . . . . . . . . . . . . . . . . . 57
7.2 Anforderungen an Generic Web Services . . . . . . . . . . . . . 59
8 Entwurf von Generic Web Services 62
8.1 Vorbetrachtungen . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.2 Servlet-basierter Aufbau . . . . . . . . . . . . . . . . . . . . . . 63
9 Implementierung 64
9.1 Datenbank-Adapter . . . . . . . . . . . . . . . . . . . . . . . . 64
9.2 Generierungsprozess . . . . . . . . . . . . . . . . . . . . . . . . 65
9.3 Web Service Invocation Framework (WSIF) . . . . . . . . . . . 66
10 Einsatzbeispiel 67
10.1 Generierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
10.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.3 Aufruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.3.1 WSIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.3.2 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . 77
A ABAP Dictionary Datentypen 78
ii
Inhaltsverzeichnis
B CD-ROM 80
C Installationsanleitung 82
C.1 Installation der Komponenten . . . . . . . . . . . . . . . . . . . 82
C.2 Installation von Generic Web Services . . . . . . . . . . . . . . 84
C.3 Aufruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
C.4 Installation von Datenquellen-Middleware . . . . . . . . . . . . 86
C.5 Integration von Datenquellen-Adaptern . . . . . . . . . . . . . 86
Abbildungsverzeichnis 87
Tabellenverzeichnis 88
Literaturverzeichnis 90
iii
Vorwort
Die Grundidee zur vorliegenden Arbeit entstand bei der T-Systems Nova
GmbH, Entwicklungszentrum Sud-West in Saarbrucken. Der Einsatz von SAP
R/3 sowohl innerbetrieblich als auch bei Kundenunternehmen zur Abwick-
lung relevanter Geschaftsprozesse verlangte nach einer Technologie, die ande-
ren, typischerweise in der Praxis SAP-fremden Systemwelten Zugriff auf die
R/3-intern gehaltenen Daten gewahrt. Vor dem Hintergrund, daß die Ver-
waltung dieser Rohdaten vorgegebenen und innerhalb der Applikationslogi-
kebene des Systems spezifizierten betriebswirtschaftlichen Geschaftsregeln und
-operationen unterliegt, bietet R/3 zur Wahrung der Datenintegritat keine sy-
stemubergreifende direkte Schnittstelle zum Datenbanksystem.
Die besondere Anforderung lag dabei vor allem bei der einfachen Anwend-
barkeit der Technologie in der Praxis, der Plattform- und Programmierspra-
chenunabhangigkeit sowie einer großtmoglichen Wiederverwendbarkeit. Zwar
konnte auf Grund der von R/3 unterstutzten Kommunikationsschnittstellen
auch bisher mit dem System interoperiert werden, allerdings mit hohem Auf-
wand: In Abhangigkeit von der integrierenden Anwendung mussten”ad-hoc“-
Implementierungen die Anbindung uber die jeweils kompatible Schnittstelle zu
R/3 realisieren, um Daten integrieren zu konnen.
Mit Beginn der Betreuungsphase durch den Lehrstuhl von Prof. Dr.-Ing.
Weikum am Max-Planck-Institut fur Informatik in Saarbrucken wurde eine
darauf aufbauende, verallgemeinernde Aufgabenstellung konkretisiert: Die Er-
zeugung von Web Services in einem automatisierten generischen Prozess sollte
es ermoglichen, individuell definierte Dienste bereitzustellen, die die Daten be-
liebiger aber jeweils fix spezifizierter Datenhaltungssysteme extrahierbar und
modifizierbar und damit flexibel integrierbar machen.
Die Ausarbeitung prasentiert gleichermaßen die notwendigen theoretischen
Grundlagen zur Softwarearchitektur von Web Services, deren konkrete Umset-
zung 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 Ausfuhrung der vorliegenden Version notigen Softwarekomponenten auf
CD-ROM bei.
1
Die Realisierung dieser Diplomarbeit erfolgte in den Raumen der T-
Systems Nova GmbH, die unter anderem einen Zugang zu SAP R/3, erfor-
derliche Softwarekomponenten sowie Know-how im Umgang mit dieser Syste-
mumgebung zur Verfugung stellten.
2
Kapitel 1
Einleitung
Der Entwurf von System- und Anwendungsarchitekturen basiert auf grundle-
genden Konzepten. Anwendungen lassen sich prinzipiell drei funktionalen Ebe-
nen zuteilen, die logisch betrachtet ubereinander anzuordnen sind wie Abbil-
dung 1.1 zeigt.
Abbildung 1.1: Die drei Ebenen einer Anwendung
Innerhalb der Datenebene befinden sich die Rohdaten, mit denen die Anwen-
dung arbeitet. Sie werden entweder im Dateisystem gehalten (die Anwendung
speichert die Datenebene selbst) oder sie sind, wie in den meisten Fallen, in
angeschlossenen Datenbanksystemen organisiert, die damit die Datenebene re-
prasentieren. 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 enthalt die implementierten Anwendungsope-
rationen auf den Daten der Datenebene.
Die Prasentationsebene stellt das Bindeglied zwischen der Anwendung und
dem Benutzer dar. Sie prasentiert die Anwendung bzw. deren Ausfuhrungsre-
sulte auf irgendeine benutzerverstandliche Art. Typische Beispiele sind Web-
seiten oder anwendungsspezifische graphische Oberflachen (z.B. SAP GUI).
In immer starkerem Maße spielt in der heutigen Zeit die Vernetzung von
Rechnern und damit das verteilte Computing eine wichtige Rolle. Das Inter-
net als globales Netzwerk ubernimmt dabei langst nicht mehr nur die Aufgabe
der reinen Prasentation von Informationen und Wissen. Vielmehr ruckt immer
3
haufiger beispielsweise unter dem Begriff des E-Business die Abwicklung von
Geschafts- und Handelsbeziehungen in den Vordergrund. Unternehmen nut-
zen das Internet sowie das innerbetriebliche Intranet als Kommunikationsnetz-
werk, um die taglich anfallenden Geschaftsprozesse dezentral, automatisiert
und somit zeit- und kostensparend in allen Funktionsbereichen wie Marketing,
Vertrieb, Produktion, Logistik etc. durchzufuhren.
Mit dem Internet ist die Basis fur ein einheitliches Kommunikationsmedi-
um geschaffen, das als Standard gesetzt und anerkannt ist. Die auf den Schnitt-
stellen aufgesetzten Anwendungsplattformen mussen dabei allerdings moglichst
flexibel sein, was die Integration verschiedener externer Informationssysteme
oder Geschaftsablaufe und -einheiten in die bestehende IT-Landschaft betrifft.
Von dieser Anforderung hangen letztlich die Effizienz und die Akzeptanz des
gesamten Systems ab. Nur wenn einzelne Applikationen Daten austauschen
konnen, konnen Erweiterungen und Optimierungen in der Geschaftsprozes-
skette realisiert werden. Ein Vorteil der Integration von Unternehmens- oder
E-Business-Anwendungskomponenten in vorhandene IT-Infrastrukturen ist so-
mit aus betriebswirtschaftlicher Sicht offensichtlich: Prozessoptimierung, Ko-
stensenkung und das Ziel, daraus einen gemeinsamen Mehrwert mit dem ver-
netzten Partner zu erlangen, sichern die Wettbewerbsfahigkeit. Aus technischer
Sicht stoßt die Kopplung auch wenig komplexer Softwarekomponenten auf
Grund unvereinbarer Technologien oder fehlender Schnittstellen immer wie-
der an Grenzen. Der Einsatz von webbasierten, d. h. uber das Internet bzw.
Intranet kommunizierenden Systemarchitekturen ist noch keine hinreichende
Voraussetzung fur die Realisierung von unternehmensubergreifenden, verteil-
ten Prozessen in einem Rechnerverbund. Existiert hier keine einheitliche oder
zumindest klar definierte Struktur bei der Darstellung von Informationen und
sind diese nur uber system- und anbieterspezifische Technologien austauschbar,
ist eine Anbindung von Fremdsystemen meist unmoglich oder unrentabel.
Als Ausgangssituation fur dieses Szenario betrachte man zunachst die ty-
pische Architektur eines webbasierten Systems. Die drei Ebenen einer Anwen-
dung konnen verschiedenen Komponentenschichten (tiers) zugeteilt werden wie
Abbildung 1.2 darstellt.
Die drei Anwendungsebenen lassen sich dabei wie folgt auf die Komponen-
tenschichten verteilen: Die Datenebene wird durch den Datenserver (tier 4) re-
prasentiert, wahrend der Applikationsserver (tier 3) die Applikationslogikebene
abdeckt. Tier 1 und tier 2 bilden schließlich zusammen die Prasentationsebene.
Informationsanfragen, die der Benutzer von einem Client aus in der Regel
uber einen Browser formuliert, nimmt der Webserver entgegen. Die Ausfuhrung
der entsprechenden Anwendungslogik ubernehmen innerhalb des Applikations-
server laufende Programme. Dabei stehen notwendige Daten in separat gehal-
tenen Datenhaltungssystemen zur Verfugung.
Was nun im beispielhaft angefuhrten 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. Ermoglicht man die Kommunikation ein-
zelner Anwendungskomponenten untereinander, konnen Geschaftsprozesse hier
die Unternehmensgrenzen uberschreiten. Bestehende Business-Losungen oder
Informationssysteme unterschiedlicher Anbieter konnen integriert werden, und
so kann das Unternehmen auf zunehmende Anforderungen flexibel reagieren.
Die Motivation fur den Einsatz verteilter Anwendungsarchitekturen liegt
nicht ausschließlich in der Integrierbarkeit existierender (Fremd-)Losungen und
steht unter dem erwahnten wirtschaftlichen Gesichtspunkt. Skalierbarkeit und
Lastenverteilung sind nur zwei Schlagworter bei der Betrachtung der techni-
schen Aspekte. Abbildung 1.3 zeigt die veranderte Situation in der Anwen-
dungsschicht 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 haufig durch eine heterogene Hard- und Softwareumgebung aus-
zeichnen. Es mussen Schnittstellen gegeben sein, die Dienste zum Austausch
verteilter Anwendungsobjekte anbieten. Diesbezuglich verfugbare Middleware-
Technologien mussen in der Lage sein, von gegebenen Hard- und Softwarear-
chitekturen zu abstrahieren, um so plattform- und programmiersprachenun-
abhangig die Kommunikation mit komponentenorientierten Applikationen zu
ermoglichen.
Hier prasentieren verschiedene Technologiehersteller Losungen. Zum Bei-
spiel stellt Microsoft fur Windows-Plattformen den DCOM-Standard (Distri-
buted Component Object Model) [5] zur Verfugung, somit allerdings eine Ein-
schrankung auf Windows-Systeme. Mit CORBA (Common Object Request
Broker Architecture) [6] existiert ein weit verbreiteter Ansatz fur E-Business-
Losungen der Object Management Group (OMG). Dieser wurde von Unter-
nehmen wie IBM und der Sun Microsystems, Inc. weiterentwickelt und stan-
dardisiert. Der Einsatz von CORBA ermoglicht zwar eine Uberschreitung von
Betriebssystem- und Programmiersprachengrenzen, Applikationen, die auf die-
sem Konzept basieren, sind aber dennoch abhangig von anbieterspezifischen
Implementierungen: Die Schnittstelle zum verteilten Objekt und deren Be-
schreibung mussen in den Sprachen spezifiziert und angeboten werden, von
denen aus ein Zugriff erwunscht ist2.
An dieser Stelle treten Web Services als Middleware-Konzept in den Vor-
dergrund. Bei der Realisierung von verteilter Anwendungsfunktionalitat setzen
Web Services auf bereits etablierte plattform- und sprachenunabhangige Tech-
nologien. Die beispielhaft erlauterten Einschrankungen im Umgang mit vor-
herrschenden Losungen zur Realisierung verteilter Anwendungsfunktionalitat
werden von Web Services durch Standardisierungen umgangen. Die Festlegung
auf das Kommunikationsprotokoll SOAP, welches Vorschriften fur die Forma-
tierung auszutauschender Daten zwischen verteilten Anwendungen definiert,
stellt dabei die eigentliche Neuerung dar.
Ebenso wie SOAP basiert auch die Schnittstellenbeschreibungssprache
WSDL fur Web Services auf XML (eXtensible Markup Language) [17]. Auch
bei der Verwendung des Tragerprotokolls zur Ubermittlung der Daten wird
die Zielsetzung von Web Services deutlich: Offene Internet-Standards wie das
uberwiegend eingesetzte HTTP (HyperText Transfer Protocol) [15] sichern ei-
ne plattformubergreifende Kommunikation und eine standardisierte Verfugbar-
keit. Andererseits sind Konzepte wie die der entfernten Methodenaufrufe (Re-
mote Procedure Call) oder der serviceorientierten Architektur von Web Ser-
vices keine neue Erfindung. Auf Grund ihres zusatzlichen Grades an Plattform-
und Programmiersprachenunabhangigkeit und der breiten Verfugbarkeit von
Webserver-Architekturen scheint mit Web Services allerdings eine verteilte
2CORBA verwendet hier die sogenannte Interface Definition Language (CORBA IDL),
vgl. [23, 6]. Sie ist an die Programmiersprache C++ angelehnt.
6
1.2. Zielsetzung
Ausfuhrungstechnologie gefunden, die eine Losung 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 uber spezifi-
sche proprietare 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 ei-
ne generische Erzeugung der Web Services realisiert werden: Die Spezifizierung
von Schnittstelle und Schnittstellenbeschreibung (WSDL), die den Web Service
identifizieren, mussen ebenso generisch realisiert werden wie dessen Implemen-
tierung, die schließlich im Applikationsserver zugreifbar wird. Die Aufgabe der
Web Service Implementierungen soll es sein, Methoden im verteilten System
zur Verfugung zu stellen, die – je nach erfolgtem Generierungsprozess – eine
Selektion oder Manipulation auf Daten eines Datenhaltungssystems ausfuhren
und somit diese Funktionalitat im”Ready-to-use“-Format anbieten und ver-
breiten konnen.
In der Realisierung werden in Abhangigkeit des Anbieters eines Datenhal-
tungssystems (ORACLE, MySQL, Microsoft SQL Server, SAP R/3, etc.) spe-
zifische Middleware-Implementierungen den Zugriff innerhalb des Web Service
ubernehmen. Generische Datenstrukturen mussen dann dafur sorgen, die Da-
ten systemkonform zu halten, d. h. vorgegebene Datenschemata und -relationen
mussen vom Web Service gewahrt werden, um die Datenintegritat im System zu
erhalten. Gleichzeitig konnen uber diese Datenstrukturen Methodenparamter
definiert werden, um eine Spezifizierung der zu selektierenden oder manipulie-
renden Daten im Datenhaltungssystem zu ermoglichen. Wie noch zu erlautern
7
1.3. Gliederung der Arbeit
sein wird, dienen die Metadaten der jeweiligen Datenquelle dazu, diese Struk-
turen zu erzeugen.
Es sei an dieser Stelle explizit darauf hingewiesen, dass die im Rahmen die-
ser Arbeit betrachteten Datenhaltungssysteme auf dem relationalen Datenmo-
dell beruhen. Auch die 3-Tier-Architektur des SAP R/3 nutzt auf Datenebene
relationale Datenbanksysteme (vgl. 4.1).
Zusatzlich zur Generierung der eigentlichen Web Service Komponenten
muss die Moglichkeit zur Erzeugung einer passenden Client-Anwendung gege-
ben sein. Ziel ist es, nicht nur einen Client auf Programmierebene, sondern
auch im Sinne einer graphischen Benutzeroberflache umzusetzen.
Die Realisierung des Generierungsprozesses erfolgt innerhalb der Imple-
mentierung des Projektes Generic Web Services.
1.3 Gliederung der Arbeit
Die Kapitel 2 und 3 der vorliegenden Arbeit dienen der Einfuhrung in die The-
matik der Web Services: Kapitel 2 gibt eine Definition fur verteilte Systeme
und stellt das allgemeine Konzept des Remote Procedure Call zum Zugriff auf
Anwendungen sowie die grundlegende Architektur von Middleware-Losungen
im verteilten System vor. In Kapitel 3 werden diese Aspekte aufgegriffen und
in ihrer speziellen Auspragung im Kontext der Web Services als Middleware
dargestellt. Dabei wird insbesondere auf die Spezifikation des Ubertragungspro-
tokolles SOAP sowie der Schnittstellenbeschreibungssprache WSDL von Web
Services eingegangen.
Kapitel 4 fuhrt grundlegend in das SAP R/3-System ein. Angefangen bei
der Systemarchitekur werden die bedeutenden Softwarekonzepte unter Be-
trachtung des sogenannten Business Framework erlautert. 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, ei-
nerseits fur die Anbindung an ein SAP R/3-System, andererseits fur die An-
bindung von relationalen Datenbanksystemen. Beide Ansatze basieren auf Java
und werden in der Verwendung ihrer wichtigsten Funktionalitaten beschrieben.
Mit Kapitel 7 beginnt der Einstieg in die Webapplikation Generic Web Ser-
vices. Hier werden zunachst die grundlegenden Anforderungen beschrieben, die
an Web Services bezuglich ihrer Architektur zu stellen sind. Weiterhin werden
Forderungen an Generic Web Services gestellt, was die konkrete Auspragung
bzw. Implementierung der zu generierenden Web Services angeht.
Der allgemeine Entwurf der Applikation
8
Kapitel 2
Konzepte verteilter
Ausfuhrungsplattformen
Die in diesem Kapitel betrachteten Konzepte sollen keineswegs eine vollstandi-
ge Bearbeitung des Themenkomplexes”Verteilte Systeme“ darstellen, sondern
lediglich in die im Hinblick auf eine Einordnung der Technologie Web Services
notwendigen Zusammenhange einfuhren.
2.1 Definitionen
2.1.1 Verteiltes System
Bis in die 80iger Jahre liefen Computeranwendungen zentralisiert auf einem
System. Mit der Entwicklung und zunehmenden Popularitat von Datenban-
ken und Netzwerken entstanden die mit heutiger Terminologie bezeichneten
2-Tier- bzw. Zwei-Schicht-Anwendungen. Zu der Zeit etablierte sich der Be-
griff 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 Ver-
netzung und somit immer großere Rechnerverbundsysteme, so dass schließlich
dazu ubergegangen wurde, einzelne am Verbund beteiligte Systeme mit ihren
Anwendungen nach außen transparent zu halten, d. h. bei Ausfuhrung eines
Programmes war fur den Benutzer nicht mehr nachvollziehbar, wo Systemres-
sourcen und wie viele davon in Anspruch genommen wurden. Der Begriff der
”verteilten Systeme“ kam auf.
In der einschlagigen Literatur findet sich diesbezuglich beispielsweise die Defi-
nition 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 ermoglichen, Anwendungen auf entfernten autonomen Sy-
9
2.2. Middleware-Technologien
stemen dynamisch zu integrieren. Mit der damaligen Version des Distribu-
ted Computing Environment-Standards (DCE) der Open Software Foundation
(OSF)1, einem low-level Request/Response-Modell, wurden von der Sun Mi-
crosystems, Inc. und Microsoft entfernte Prozeduraufrufe (Remote Procedure
Call, RPC) realisiert [2].
Das Prinzip von RPC bildet auch aus heutiger objektorientierter Sicht
die Grundlage fur 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 integrie-
ren, die Systemplattform mit einzelnen Applikationen verbinden oder die In-
tegration von Softwareanwendungen untereinander herstellen.
Die Middleware-Ebene ist eine Sammlung verschiedener Technologien und
Plattformen zum objektorientierten, direkten Datenaustausch zwischen ver-
schiedenen Applikationen.
Middleware konvertiert die Informationen mehrerer Softwaretypen und be-
findet 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-Auspragungen unterschie-
den. Dies sind insbesondere RPC, welches im Folgenden genauer zu beschrei-
ben sein wird, sowie datenzugriffsorientierte Middleware, nachrichtenorientierte
Middleware und objektorientierte Middleware. Da die letzten drei genannten
Typen fur 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 verteil-
ter Architekturen moglich, Anwendungen auf entfernten Rechnern uber ein
Netzwerk-Protokoll aufzurufen, wobei mit der Entwicklung der objektorientier-
ten Programmiersprachen in den 90er Jahren das Konzept modifiziert werden
1heute als Open Group bekannt2Datenzugriffsorientierte Middleware ist nach Kategorisierung in [13] im Kontext von fode-
rierten Datenbanken zu sehen. Insofern fallt der in dieser Arbeit implementierte Datenbank-
Adapter zur Anbindung relationaler Datenbanksysteme nicht in diese Kategorie.
10
2.3. Service-oriented architecture (SOA)
mußte. Es gilt nunmehr die Anforderung, Objekte client- und serverseitig uber
Protokolle zu referenzieren (ORPC) und deren Methoden aufzurufen. Aufrufen-
de Objekte mussen vom Client fur 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 reprasentiert.
Abbildung 2.1: RPC mit Stub und Skeleton
Das Client-Objekt ruft die Methode lokal in seinem Stub auf. Gemaß der ver-
wendeten RPC-basierten Middleware erfolgt zunachst das als Marshalling be-
zeichnete”Verpacken“ der Anfrage zum Methodenaufruf zusammen mit der
Serialisierung des Stub-Objektes sowie zu ubergebender Parameter. Das server-
seitige Skeleton-Objekt fuhrt ein Unmarshalling und Deserialisieren aus und
ruft die Methode auf dem vom Stub referenzierten Server-Objekt auf. Der
Ruckgabenwert der Methode wird schließlich an den Client zuuckgesendet.
Um Verwirrungen zu vermeiden sei noch erwahnt, daß die CORBA- und
DCOM-Architekturen, die dieses Prinzip implementieren, an dieser Stelle un-
terschiedliche 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 Moglichkeit, Softwarekomponenten in einem verteilten System als Dienste
anzubieten, die uber das Netzwerk abgerufen werden konnen, zum Beispiel
durch RPC-Mechanismen, stellt zusatzliche 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 moglichst unabhangigen Formaten und Protokollen
Dienste gemaß folgenden Anforderungen anbieten konnen:
• Es erfolgt eine strikte Trennung der Schnittstellenmodellierung und der
Implementierung der Applikationslogik. Durch diese lose Kopplung kann
einerseits die Komplexitat der Logik dadurch verborgen bleiben, dass le-
diglich eine sehr kleine Anzahl an Zugriffsmethoden fur bestimmte Funk-
tionalitaten bereitgestellt werden, andererseits beeinflussen interne Mo-
difikationen nicht zwangslaufig den verteilten Zugriff.
• Das dynamische Auffinden von Diensten bzw. Schnittstellen bereitgestell-
ter Applikationslogik kann auf Grund von spezifischen Beschreibungen
ermoglicht 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 (Wie-
derverwendbarkeit).
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
uber drei Rollen und zugehorigen Operationen spezifiziert werden kann.
2.3.2 Service Provider
Der Service Provider tragt die Implementierung des Dienstes und legt die Funk-
tionalitat fest, die innerhalb der Architektur offentlich gemacht wird. Die ent-
sprechenden Schnittstellen werden uber IDL (Interface Definition Language),
einer architektureigenen Beschreibungssprache, abgebildet, dem Service Broker
zur Verfugung gestellt und registriert.
2.3.3 Service Broker
Der Service Broker verwaltet als zentral zugreifbare Einheit die Informatio-
nen der veroffentlichten Dienste. Dazu gehoren gleichermaßen semantische Be-
schreibungen, Informationen uber 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 Reposi-
tory 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 erhalt vom Service
Broker uber die Interaktion suchen alle notwendigen Informationen, um
einen Dienst zu lokalisieren und zu binden: Die detaillierte Auskunft, die die
Schnittstellenbeschreibung uber den Dienst gibt, wird vom Consumer genutzt,
um eine Ausfuhrungsanfrage einschließlich der erforderlichen Parameter zu
erzeugen und an den Provider zu senden.
Das vorgestellte Modell stellt eine Standard-Architektur fur verteilte Sy-
steme dar. Die herstellerspezifischen Protokolle, Schnittstellenbeschreibungs-
sprachen, RPC-Implementierungen, etc. sind jedoch vielfaltig. Um einen Ein-
blick zu erlangen, wird in Tabelle 2.1 eine Ubersicht uber bekannte SOA-
Implementierungen und deren Formate gegeben3. Von Standardisierung und
Plattformunabhangigkeit kann demnach nicht die Rede sein.
3Es werden lediglich die Abkurzungen der genannten Technologien erlautert. Auf eine
detaillierte Beschreibung kann verzichtet werden.
13
2.3. Service-oriented architecture (SOA)
Java RMI1 CORBA DCE Web Services
Aufruf-
MechanismusJava RMI CORBA RMI RPC JAX-RPC, .NET, . . .
Daten-
FormatSerialized Java CDR2 NDR3 XML
Ubertragungs-
FormatStream GIOP4 PDU5 SOAP
Ubertragungs-
ProtokollJRMP6 IIOP7 RPC CO8 HTTP, SMTP, . . .
Interface-
BeschreibungJava Interface CORBA IDL DCE IDL WSDL
Auffind-
MechanismusJava Registry COS naming9 CDS10 UDDI
Tabelle 2.1: Beispiele fur SOA Formate und Protokolle
An dieser Stelle treten Web Services in den Vordergrund: Die Realisie-
rung dieser”Internet-Middleware“ mit ihren XML-basierter Komponenten
ermoglicht nicht zuletzt eine herstellerunabhangige serviceorientierte Architek-
tur. Applikationen konnen flexibel und nach offenen Standards komponenten-
weise 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 verfugbarer Dienste mit existieren-
den Basistechnologien zu reduzieren. Das Konzept der SOA aus der Sicht von
Web Services bildet daher die Grundlage fur die Umsetzung der Aufgabenstel-
lung dieser Arbeit. Das folgende Kapitel behandelt ausfuhrlich die charakteri-
stischen Technologiespezifikationen.
1Java Remote Method Invocation2Common Data Representation3Network Data Representation4General Inter-ORB Protocol5Protocol Data Units6Java Remote Method Protocol7Internet Inter-ORB Protocol8Remote Procedure Call Connect-Oriented protocol9CORBA Object Services naming
10Cell Directory Service
14
Kapitel 3
Web Services
3.1 Definition
Der Begriff”Web Service“ umschreibt eine Technologie, die die Interaktion
zweier Systeme uber ein Netzwerk ermoglicht. Dabei bedient sie sich typischer-
weise des Internet-Protokolls HTTP bei der Datenubertragung und stutzt ihre
Kommunikationssprache und offentlichen Schnittstellendefinitionen auf die Be-
schreibungssprache XML. Das World Wide Web Consortium (W3C) gibt mit
Beginn der Entwicklung einer Referenz-Architektur die folgende Definition ei-
nes 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 Internet-
based protocols.“
Web Services implementieren jedoch keine Client/Server-Architektur im Sinne
einer direkten Interaktion mit einem Benutzer wie zum Beispiel das Zusam-
menspiel von Webserver und Webseite verstanden werden kann. Web Services
bieten keine graphische Benutzeroberflache. Die Kommunikation umfasst den
Austausch von Applikationslogik, Daten und Prozessen mit anderen Anwen-
dungen uber eine Programmschnittstelle. Programme stellen somit die Kom-
munikationspartner auf beiden Seiten dar. Stattdessen konnen Web Service
Clients uber ein GUI initiiert und vom Web Service Provider zur Verfugung
gestellte Funktionalitat integriert und dem Benutzer visuell dargeboten werden.
Praktisch umgesetzt wird dieser Ansatz im Kontext der vorliegenden Aufga-
benstellung: Der Prozess der Generierung der Web Services beinhaltet gleicher-
maß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 vor-
gestellt. Web Sevices implementieren diese Architektur mit Hilfe dreier XML-
basierter 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 Tech-
nologien 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 fur 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 fur den plattformunabhangigen 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 fruhen Version der Spezifikation
das Protokoll XML-RPC [21] abgespalten. Eine erste Version von SOAP hat
Microsoft dann im November 1999 uber die Internet Engineering Task Force
(IETF) veroffentlicht, 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 Unterstutzung in der Softwareindustrie
ist SOAP 1.1 aber als De-facto-Standard zu bezeichnen.
In diesem Abschnitt werden zunachst die bedeutendsten Aspekte der
SOAP Spezifikation herausgearbeitet. Der Begriff”Web Services“ und dazu-
gehorige Technologien, vor allem die fur SOAP oft verwendete Schnittstellen-
beschreibungssprache WSDL, werden im Anschluss daran kurz vorgestellt.
Aus Komplexitatsgrunden mussen viele Details der Spezifikationen vorent-
halten bleiben.
3.3.1 SOAP Nachricht
Die SOAP Spezifikation definiert eine XML Grammatik, mit der strukturier-
te und typisierte Informationen zu einer Nachricht zusammengefasst werden
konnen. Eine SOAP Nachricht ist ein XML-Dokument, auch Umschlag (Enve-
lope) genannt, das einen optionalen Kopfinformations-Teil (Header) und den
eigentlichen Inhaltsteil (Body) enthalt. Listing 3.1 zeigt den grundsatzlichen
Aufbau einer SOAP-Nachricht.
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP:Header>
</SOAP:Header>
<SOAP:Body>
</SOAP:Body>
</SOAP:Envelope>
Listing 3.1: Aufbau einer SOAP Nachricht
Der SOAP Envelope gehort 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.
1XML Namespace ist ein W3C-Standard fur Namensraume in XML Dokumen-
ten zur Vermeidung von Namenskollisionen. Namensraume werden durch einen Uni-
form Resource Identifier (URI) gekennzeichnet, konnen in XML-Dokumenten uber
das Attribut xmlns eingefuhrt werden und erhalten dabei einen Kurznamen (z. B.
xmlns:meinns="http://meine.firma.org/meinns"). Namen konnen qualifiziert ver-
wendet werden, indem der lokale Teil – durch einen Doppelpunkt abgetrennt – von ei-
nem Namensraum-Prafix erganzt wird (z. B. meinns:einname). Ein solcher namensraum-
qualifizierter 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 ubertragenen Daten kann mit
dem Attribut encodingStyle fur jedes Body-Element einzeln festge-
legt werden. Die Angabe des encodingStyle-Attributes im Envelope-
Element legt eine Standard-Kodierung fest, die verwendet wird, falls in
den Kind-Elementen keine eigene Kodierung festgelegt wurde. Die SOAP
Spezifikation schlagt eine Kodierung vor, die uber den Namensraum
"http://schemas.xmlsoap.org/soap/encoding/" verwendet werden
kann. Sie basiert auf einem einfachen Typsystem, das die wichtigsten Typen
gangiger Programmiersprachen abdeckt.
Das Typsystem unterscheidet einfache und zusammengesetzte Datentypen.
Die SOAP Spezifikation ubernimmt als einfache Datentypen die Datentypen
von XML Schema [18]. Das sind unter anderem:
• int : Integer-Wert
• float : Fließkommawert
• string : Zeichenkette
• enumerations Mengen zulassiger Werte
• array of bytes Binardaten
Da in XML die Daten vollstandig im Klartext erscheinen, wird ein XML-
Dokument unnotig aufgeblaht, wenn derselbe Wert mehrfach vorkommt. Des-
halb kann Elementen uber das optionale Attribut id ein Identifikator zugewie-
sen werden. Geschieht dies wie im folgenden Beispiel bei einem String-Element,
konnen andere String-Elemente uber das Attribut href auf den String des ersten
Elements verweisen:
<name id="String-0">Mustermann</name><suchname href="#String-0"/>
Die Elemente name bzw. suchname in diesem Beispiel werden auch als
Zugriffselemente (accessor) fur den String Mustermann bezeichnet.
Zu Datenelementen in einer SOAP Nachricht kann der Typ explizit
angegeben werden. Dies geschieht uber das Attribut xsi:type aus dem
Namensraum "http://www.w3.org/2001/XMLSchema-instance", der
ublicherweise mit xsi bezeichnet wird. Der Datentyp selbst kann di-
rekt aus XML Schema [18] entnommen werden, der Namensraum lau-
tet dann "http://www.w3.org/2001/XMLSchema" (die ubliche Kurz-
bezeichnung lautet xsd). Die SOAP Datentypen sehen aber einige Be-
sonderheiten 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
ubliche Kurzbezeichnung lautet SOAP-ENC). Das folgende Beispiel zeigt die
explizite Angabe des Elementtyps unter der Annahme, dass die Namensraume
xsd, xsi und SOAP-ENC an fruherer Stelle in der SOAP Nachricht eingefuhrt
wurden. Diese Annahme gelte in allen folgenden Beispielen dieses Abschnitts.
<name id="String-0" xsi:type="SOAP-ENC:string">Mustermann</name>
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 In-
stanzen die Werte von verschiedenen Typen annehmen konnen (in CORBA
z.B. der Typ any). SOAP unterstutzt solche universellen Datentypen mit den
sogenannten polymorphen Zugriffselementen (polymorphic accessors). Instan-
zen dieses universellen Datentyps mussen ihren Typ immer explizit angeben.
Neben den einfachen Datentypen unterstutzt SOAP auch die folgenden
zusammengesetzten Datentypen:
• struct : entspricht den aus Programmiersprachen bekannten Struktu-
ren 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 fur eine Instanz des struct-
Typs ist Adresse:
<beispiel:musteradresse xsi:type="beispiel:Addresse"xmlns:beispiel="http://schema.adresse.de/adresseschema>
<strasse xsi:type="xsd:string">Talweg</strasse><hausnr xsi:type="xsd:string">12</hausnr><ort xsi:type="xsd:string">Saarbrcken</ort>
</beispiel:musteradresse>
• array : entspricht den aus Programmiersprachen bekannten Feldern
bzw. Arrays. Hier haben alle Zugriffselemente den gleichen Namen; die
Unterscheidung der einzelnen Elemente erfolgt ausschließlich uber die
Position, an der sie genannt werden. Der Typ fur SOAP Felder lau-
tet SOAP-ENC:array. Der Typ der Feld-Elemente ist in der Variable
SOAP-ENC:arrayType anzugeben und kann z. B. xsd:int[2] lau-
ten fur ein zweielementiges Feld des Grundtyps xsd:int. SOAP bietet
auch eine Unterstutzung fur nur teilweise ubermittelte oder nur teilweise
belegte Felder.
• Mischformen : SOAP unterstutzt auch Mischformen, in denen die Ele-
mente zwar uber ihren Namen referenziert werden wie in einer Struktur,
aber einzelne Elemente mehrfach auftauchen konnen wie in einem Feld.
19
3.3. Simple Object Access Protocol (SOAP)
Die verschiedenen zusammengesetzten Datentypen konnen ineinander ver-
schachtelt werden, beispielsweise in einem Feld uber einem struct-Typ oder
in mehrdimensionalen Feldern. Auch bei zusammengesetzten Datentypen sind
Referenzen mit den Attributen id und href zulassig.
Werden in SOAP Nachrichten einzelne Elemente weggelassen, kann dies
entweder einen Standard-Wert implizieren oder, dass der Wert unbekannt ist
(null-Wert). Die SOAP Spezifikation uberlasst dies dem einzelnen Anwen-
dungskontext.
3.3.3 SOAP fur RPC
Eine der erklartermaßen wichtigsten Anwendungen von SOAP ist die Verwen-
dung fur den entfernten Prozedur- bzw. Methodenaufruf RPC. Das Verfahren
basiert auf dem Anfrage-Antwort-Mechanismus. Der Unterschied liegt in erster
Linie in veranderten Nutzdaten: Statt dem Austausch von allgemeinen Doku-
menten werden in der Anfrage serialisierte Parameter ubermittelt, um damit
eine entfernte Methode aufzurufen. Als Antwort wird das serialisierte Ergebnis
zuruckgesendet (Abschnitt 2.2.1).
Der Methodenaufruf wird wie folgt mit einer SOAP Nachricht ubertragen:
• Der Aufruf wird als Struktur im SOAP Body modelliert. Die Struktur
tragt den Namen der Methode. Jeder in- und in/out-Parameter wird
Element dieser Struktur. Name und Typ des Elementes mussen mit dem
Namen und dem Typ des Methodenparameters ubereinstimmen. Die Pa-
rameter sind in der gleichen Reihenfolge aufzufuhren wie in der Metho-
densignatur vorgesehen.
• Zusatzinformationen, die zur Verarbeitung notig sind, die aber nicht zu
den Methodenparametern gehoren, konnen als SOAP Header Elemente
aufgefuhrt werden. Ein Beispiel hierfur waren etwa Transaktionsnum-
mern, die typischerweise nicht zu einer Methodensignatur gehoren und
von einer Infrastrukturkomponente (dem Transaktionsmanager) verar-
beitet werden statt von der Anwendung selbst.
Das Methodenergebnis wird ebenfalls mittels einer SOAP Nachricht unter
Berucksichtigung der folgenden Festlegungen ubertragen:
• Auch das Ergebnis wird als Struktur im SOAP Body modelliert. Jeder
out- und in/out-Parameter wird Element dieser Struktur. Wieder mussen
Name und Typ ubereinstimmen. Als erstes Element ist das Methodener-
gebnis beliebig benannt aufzufuhren, es folgen die Parameter in derselben
Reihenfolge wie in der Methodensignatur.
• Tritt bei der Bearbeitung der Methode ein Fehler auf, ist statt der Er-
gebnisstruktur das SOAP Fault Element zu verwenden. Außerdem ist die
20
3.4. Web Services Description Language (WSDL)
Fehlerbehandlung des Transportprotokolls zusatzlich zu verwenden (z. B.
Verwendung eines HTTP Fehlercodes in der HTTP Response).
3.4 Web Services Description Language (WSDL)
Damit der effektive Zugriff auf Web Services moglich ist, benotigt ein Client
eine moglichst exakte Beschreibung, welche Informationen ein SOAP Request
enthalten muss und wie die SOAP Nachrichten aussehen, die er vom Web Ser-
vice zuruckerhalten wird. Eine Sprache fur solche Beschreibungen ist die Web
Services Description Language (WSDL) [20]. WSDL wurde von den Firmen
Microsoft und IBM gemeinsam entwickelt und als Version 1.1 im Marz 2001
an das W3C ubermittelt.
Die Spezifikation klassifiziert WSDL als eine XML Grammatik zur Be-
schreibung von Netzwerkdiensten. Dabei werden die Dienste als Netzwerkkno-
ten betrachtet, die Nachrichten mit anderen Knoten austauschen konnen. Das
Hauptaugenmerk liegt auf SOAP Diensten. WSDL schließt aber auch andere
Protokolle nicht aus.
WSDL Dokumente konnen als Vertrag zwischen Client und Server uber die
Details der gemeinsamen Kommunikation aufgefasst werden. Es handelt sich
also um eine Schnittstellenbeschreibungssprache (Interface Definition Langua-
ge, IDL).
WSDL sieht folgende abstrakte Definitionen vor:
• Types : Definition eigener Datentypen, z. B. Strukturen.
• Messages : Definition von Nachrichtentypen, also Klassen von Nachrich-
ten.
• Port Types : Ein Port Type ist eine Menge abstrakter Operationen. Je
Operation werden mehrere Messages zu Eingabe-, Ausgabe- und Fehler-
nachrichten zusammengesetzt und so Operationssignaturen beschrieben.
Ein Port Type ist eine abstrakte Definition, die noch nicht festlegt, mit wel-
chem Protokoll (z. B. SOAP) die Ubertragung der Nachrichten erfolgt und wie
einzelne Parameter dieses Protokolls zu wahlen sind (z. B. das Transportproto-
koll HTTP). Diese Festlegung kann fur jeden Port Type mit einem sogenannten
Binding geschehen. Je Port Types sind auch mehrere unterschiedliche Bindings
zulassig.
Ein Binding wird in WSDL durch das Element binding be-
schrieben, mit den Attributen name, das den Namen festlegt, sowie
type, das auf den Port Type verweist. Ein Binding muss genau ein
Nachrichtenaustausch-Protokoll festlegen. Im Falle von SOAP geschieht
dies mit dem leeren Kindelement soap:binding aus dem Namensraum
21
3.4. Web Services Description Language (WSDL)
soap="http://schemas.xmlsoap.org/wsdl/soap/". Mit dem Attri-
but transport von soap:binding kann das Transportprotokoll festgelegt
werden (z. B. "http://schemas.xmlsoap.org/soap/http").
<binding ... >
<soap:binding>
<operation ... >
<soap:operation .../>
<input><soap:body .../>
<soap:header ...> ... </soap:header></input>
<output><soap:body .../>
<soap:header ...> ... </soap:header></output>
</operation>
</binding>
Listing 3.2: Struktur des WSDL Elementes binding
Abbildung 3.2 zeigt die Struktur des WSDL Elements binding und sei-
ner Kindelemente. Jede Operation wird durch ein Kindelement operation
beschrieben, dessen Attribut name mit dem Namen der entsprechenden Ope-
ration des Port Type ubereinstimmen muss. Ein operation Element besteht
wiederum aus folgenden Kindelementen:
• soap:operation Ein leeres Element zur Festlegung weiterer SOAP-
spezifischer Attribute, z. B. des HTTP-Headers SOAPAction.
• input Innerhalb dieses Elementes wird festgelegt, wie zu dem im Port
Type festgelegten Eingangsnachrichtentyp eine konkrete SOAP Nachricht
gewonnen werden kann. Diese SOAP-spezifische Festlegungen werden mit
Hilfe der Kindelemente soap:body und soap:header getroffen.
• output Analog zu input, nur auf die Ausgangsnachricht bezogen.
Das Binding konkretisiert also den abstrakten Port Type im Hinblick auf
die Details der Datenubermittlung. Damit diese Informationen nicht nur fur
einen einzigen konkreten Server verwendet werden konnen, darf das Binding
noch keine Adressinformationen enthalten. Dies ist dem sogenannten Port vor-
behalten, der ein Binding mit einer konkreten Adresse verknupft. Mehrere
Ports konnen dann zu einem Service gruppiert werden.
22
3.4. Web Services Description Language (WSDL)
Das konkrete Beispiel einer WSDL Datei in Listing 3.3 ist fur das Verstand-
nis hilfreich. Die Nachrichtentypen getPreisRequest als Eingabenachrich-
tentyp und getPreisResponse als Ausgabenachrichtentyp ergeben zusam-
men die Operation getPreis. Diese Operation ist die einzige Operation des
KatalogPortType. Mit dem KatalogBinding wird der Port Type kon-
kretisiert. Der KatalogPort beinhaltet schließlich auch Adressinformationen
und ist der einzige Port im KatalogService. Damit ist ein konkreter Dienst
vollstandig beschrieben.
In dem Listing sind die Querverweise innerhalb der WSDL Definition farbig
markiert.
<?xml version="1.0" encoding="UTF-8"?><definitions name="Katalog"
targetNamespace="http://beispiel.org/Katalog"xmlns:myns="http://beispiel.org/Katalog"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns="http://schemas.xmlsoap.org/wsdl/">
<types></types>
<message name="getPreisRequest"><part name="artikelnummer" type="xsd:int"/><part name="waehrung" type="xsd:string"/>
</message>
<message name="getPreisResponse"><part name="result" type="xsd:int"/>
</message>
<portType name="KatalogPortType"><operation name="getPreis">
<input message="myns:getPreisRequest"/><output message="myns:getPreisResponse"/>
</operation></portType>
<binding name="KatalogBinding" type="myns:KatalogPortType"><soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/><operation name="getPreis">
<soap:operation soapAction="http://beispiel.org/Katalog" style="rpc"/><input>
<soap:body use="encoded" namespace="http://beispiel.org/Katalog"encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<input><output>
<soap:body use="encoded" namespace="http://beispiel.org/Katalog"encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<output><operation>
<binding>
<service name="KatalogService"><documentation>Ein Beispiel-Service</documentation><port name="KatalogPort" binding="myns:KatalogBinding">
<soap:address location="http://ein.host.beispiel.org/soapservlet/Katalog"/></port>
</service></definitions>
Listing 3.3: Beispiel einer WSDL Definitionsdatei
23
3.5. Universal Description, Discovery and Integration (UDDI)
3.5 Universal Description, Discovery and Integrati-
on (UDDI)
Einen Verzeichnisdienst fur Web Services hat ein Industriekonsortium unter
Fuhrung der Firmen IBM, Microsoft und Ariba mit der Universal Description,
Discovery and Integration Spezifikation (UDDI, dt.: Universelle Beschreibung,
Auffindung und Integration) vorgelegt.
UDDI spezifiziert ein Datenmodell zur Beschreibung von Anbietern und
Web Services sowie eine auf SOAP aufbauende Programmierschnittstelle zur
Abfrage und Veroffentlichung solcher Daten. Das Verzeichnis wird dezentral
von mehreren Anbietern gepflegt, mit einer automatischen Replikation der ein-
zelnen Datenbanken. Dies ist vergleichbar mit dem Verfahren beim DNS (Do-
main Name Service), einem im Internet eingesetzten Dienst zur Auflosung von
Hostnamen in IP-Adressen.
UDDI unterstutzt drei wichtige Nutzungsarten:
•”White Pages“ : Sie enthalten Informationen uber Firmen inkl. Na-
men, Kontaktinformationen und einer Klartextbeschreibung und sind
vergleichbar mit einem Telefonbuch)
•”Yellow Pages“ : Sie tragen Informationen uber Tatigkeitsfelder, d. h.
Branchen, Produkte und regionale Tatigkeitsfelder und sind vergleichbar
mit den gelben Seiten eines Telefonbuches.
•”Green Pages“ : Sie liefern Informationen uber E-Business Dienste,
insbesondere Web Services. Es werden dabei verschiedene Abstraktions-
grade unterschieden, die funktionelle Ebene, die technische Ebene und
die Implementierungsebene.
Der UDDI fallt im Rahmen der Diplomarbeit keine wesentliche Bedeutung
zu, so dass keine detailliertere Betrachtung vorgenommen wird. Stattdessen
wird auf [14] verwiesen.
24
Kapitel 4
SAP R/3
Die SAP AG stellt mit SAP R/3 den wohl wichtigsten Vertreter betriebswirt-
schaftlicher Standard-Software. SAP R/3 bietet branchenneutrale Losungen
fur Bereiche wie Logistik und Personalwirtschaft, die individuellen Kundenan-
forderungen angepasst werden kann1.
Auf Grund der daraus resultierenden enormen Komplexitat und Vielfalt
an unterstutzten Technologien kann im Rahmen dieses Kapitels lediglich ein
Einblick in das System gegeben werden. Es werden grundlegende Kenntnisse
uber die Architektur des Basis-Systems sowie das R/3-Business Framework
vermittelt, die fur Thematik der Arbeit von Bedeutung sind.
Die Ausfuhrungen stutzen sich auf Informationen der SAP Bibliothek, die
als Online-Dokumentation [8] umfangreiche Erlauterungen zu allen SAP R/3-
Komponenten bietet.
4.1 Systemarchitektur
Das SAP R/3-System ist ein mehrstufiges Client/Server-System. Es basiert
auf einer dreigeteilten Softwarearchitektur, wobei jeder Anwendungsebene ei-
ne eigene Komponentenschicht zugeteilt ist, so dass eine Trennung in Prasen-
tationsschicht (Frontend-Client), Applikationsschicht (Applikationsserver) und
Datenbankserver (Backend) erfolgt. Die einzelnen Softwarekomponenten fun-
gieren je nach Schicht als Client oder Server fur die Komponenten der anderen
Schichten.
Ein zentrales Datenbanksystem, das alle Daten des R/3-Systems verwal-
tet, bildet die Datenbankschicht. SAP stellt kein eigenes Datenbanksystem fur
R/3 zur Verfugung und unterstutzt infolgedessen Fremdsysteme verschiedener
Hersteller, z. B. ORACLE, Microsoft SQL Server oder DB2.
Die Datenbank enthalt nicht nur die betriebswirtschaftlichen Daten der
Anwendungsprogramme, sondern ist die zentrale Datenablage fur das gesamte
1Nachdem das R/3-System um internetbasierte Funktionalitaten und Technologien erwei-
tert wurde, wird es unter dem Namen”mySAP“ vermarktet.
25
4.2. Business Framework
R/3-System. Insbesondere enthalt die Datenbank auch Steuerungsdaten, die
das Verhalten des R/3-Systems festlegen. Diese in einem speziellen Teil der
Datenbank gehaltenen Komponenten werden als R/3-Repository bezeichnet.
Die Softwarekomponenten des R/3-Systems auf Applikationsebene be-
stehen aus einem oder mehreren Applikationsservern, die eine Anzahl von
Diensten fur den Betrieb zur Verfugung stellen. Die sich durch den Einsatz
von verteilten Ausfuhrungsplattformen ergebenden Vorteile sind auch fur R/3
relevant. Die Moglichkeit der Verteilung der Dienste gewahrt eine anforde-
rungsgemaße Konfiguration der Einzelsysteme. Eine hohe Skalierbarkeit der
Applikationsserver sorgt fur eine flexible Organisation des Systemkomplexes.
In der Praxis werden daher mehrere Applikationsserver auf jeweils separaten
Rechnern aufgesetzt, um zudem die lokal auftretende Systemlast zu reduzieren
und kurze Antwortzeiten zu ermoglichen. Alle Applikationsserver eines R/3-
Systems bilden zusammen die Applikationsschicht der Architektur.
Die Prasentationsschicht bilden in R/3 die Komponenten der SAP-eigenen
graphischen Oberflache SAP GUI (Graphical User Interface). Sie stellen die
Schnittstelle zu den Benutzern dar.
Die komponentenorientierte Entwicklung von Anwendungen ist eine der Grund-
voraussetzungen dafur, mit SAP R/3 ein offenes System zu realisieren. Zusam-
men mit Standards fur Kommunikationsschnittstellen wird das Zusammenspiel
und die Portierbarkeit von Funktionalitaten und Daten auch auf Fremdsysteme
ermoglicht. Diese Umsetzung fuhrt zur Architektur des Business Framework.
4.2 Business Framework
Das SAP R/3-Business Framework setzt eine Strukturierung der R/3-
Anwendungsfunktionalitaten in einzelne Softwarekomponenten (Business-
Komponenten) und Objektmodelle um. Diese Einfuhrung von”Black-
Box-Ansatzen“, d. h. die Modularisierung und Schnittstellenbildung tragt
wesentlich zur Komplexitatsreduzierung des Gesamtsystems bei und ermoglicht
es, Komponenten beliebig untereinander sowie mit kompatiblen Modellen
von Kunden und Partnern zu koppeln, so dass eine Interaktion mit externen
Anwendungen stattfinden kann.
Die wichtigen Bestandteile der Business Framework Architektur sind:
• Business-Komponenten
Die Business-Komponenten sind eigenstandige funktionelle Einheiten,
die sich aus Business-Objekten zusammensetzen. Geschaftsprozesse wer-
den entweder innerhalb einer Business-Komponente implementiert oder
erstrecken sich uber mehrere Komponenten (verteilte Geschaftsprozes-
se). Beispielsweise sind der Business-Komponente Human Resources
26
4.2. Business Framework
unter anderem die Business-Objekte Employee (Mitarbeiter) und
Applicant (Bewerber) untergeordnet (Tabelle 4.1).
• Business-Objekte
Business-Objekte sind die Grundlage der objektorientierten Struk-
turierung des R/3-Systems. Sie kapseln die betriebswirtschaftlichen
Daten und Funktionalitaten und helfen, Geschaftsobjekte in SAP R/3
programmtechnisch abzubilden. Sie sind mit Klassen einer objektorien-
tierten Programmiersprache zu vergleichen.
SAP Business-Komponente SAP Business-Objekt
SAP HR Employee (Mitarbeiter)
(Human Resources) Applicant (Bewerber)
SAP FI Company (Unternehmen)
(Financials) Debtor (Debitor)
Vendor (Lieferant)
SAP LO Material (Material)
(Logistics) MaterialBOM (Materialstuckliste)
MaterialGroup (Warengruppe)
ProductCatalog (Produktkatalog)
SalesOrder (Kundenauftrag)
PurchaseOrder (Bestellung)
PurchaseRequisition (Bestellanforderung)
Tabelle 4.1: Beispiele fur SAP Business-Komponenten und ihre Objekte
• Business Application Programming Interfaces (BAPIs)
BAPI s ermoglichen als Programmierschnittstelle an den Business-
Objekten den objektorientierten Zugriff auf das R/3-System. Zusammen
mit den Business-Objekten definieren und dokumentieren die BAPIs den
Schnittstellenstandard auf betriebswirtschaftlicher Ebene.
• Integrationsdienst ALE (Application Link Enabling)
Voraussetzung fur die technische Integration verteilter Geschaftsprozesse
ist, die Daten kontrolliert austauschen und konsistent halten zu konnen.
Diese Aufgabe ubernimmt das Verteilungsmodell des Application Link
Enabling, das fur eine systemubergreifende Verteilung von Business-
Objekten zwischen SAP Systemen einerseits und zwischen SAP Systemen
und Fremdsystemen andererseits sorgt.
27
4.3. Business-Komponenten
• Kommunikationsdienste
Kommunikationsdienste sind Kommunikationstechnologien wie beispiels-
weise der Remote Function Call (RFC), einer SAP-eigenen Implementie-
rung des RPC-Protokolls, der DCOM-Standard von Microsoft oder COR-
BA, die das Business Framework verwendet, um auf BAPIs zuzugreifen.
Die nachfolgenden Abschnitte behandeln die Architekturkomponenten im Ein-
zelnen.
4.3 Business-Komponenten
Die SAP Business-Komponenten implementieren spezifische Funktionen auf
betriebswirtschaftlichen Daten. Dabei reprasentieren sie diese Funktionalitaten
uber die zugehorigen Business-Objekte und fassen sie als logische Gruppe zu-
sammen. Das Modell der Business-Komponenten und -Objekte erlaubt die
Entkopplung der technischen Realisierung und der betriebswirtschaftlichen
Geschaftslogik, was bedeutet, dass eine komponenteninterne Anderung der Im-
plementierung von Geschaftsregeln und -prozessen oder die Einfuhrung neuer
Technologien innerhalb von R/3 keinen Einfluß auf die Ausfuhrbarkeit der An-
wendungen hat, die diese Business-Komponente nutzen.
4.4 Business-Objekte
Die SAP Business-Objekte werden dazu verwendet, betriebswirtschaftliche
Sachverhalte der realen Welt im SAP R/3-System abzubilden und vor allem
zu handhaben. Business-Objekte reprasentieren sowohl konkrete oder abstrak-
te Gegenstande als auch Tatigkeiten oder Ablaufe. Beispiele sind Bestellungen,
Vertrage, Kunden oder Telefonanrufe.
Die Business-Objekte beinhalten sowohl die Funktionalitaten (Objektme-
thoden) als auch die Daten (Objektattribute) dieser Sachverhalte, kapseln je-
doch die Datenstrukturen und Funktionsimplementierungen und verbergen auf
diese Weise ihre Komplexitat. Dies entspricht dem Grundgedanken der Objek-
torientierung.
Um diese Kapselung zu erreichen, bestehen die SAP Business-Objekte aus
mehreren Schichten, wie in der Abbildung 4.1 dargestellt ist.
• Kern
Der Kern ist die innerste Schicht des SAP Business-Objektes und stellt
die eigentlichen Daten.
• Integritatsschicht
28
4.4. Business-Objekte
Abbildung 4.1: Schichten eines SAP Business-Objektes
Die zweite Schicht, die Integritatsschicht, beinhaltet die betriebswirt-
schaftliche Logik des Objektes. Sie umfasst Geschaftsregeln zur konsisten-
ten Integrierung der Objektdaten sowie Einschrankungen (Constraints)
auf Werten, die fur die Business-Objektattribute moglicherweise gelten.
• Schnittstellenschicht
Die dritte Schicht beschreibt die erlaubten Zugriffsmoglichkeiten auf das
Business-Objekt. Sie definiert somit die Schnittstelle des Objektes nach
außen und wird daher als Schnittstellenschicht bezeichnet. Hier sind die
Zugriffsmethoden (BAPIs) anzusiedeln.
• Zugriffsschicht
Die vierte und außerste Schicht eines Business-Objektes ist die Zugriffs-
schicht. Sie definiert die Middlewaretechnologien, mit denen ein externer
Zugriff auf die Objektdaten moglich ist.
Wie die Abbildung zeigt, trennt die Schnittstellenschicht die Daten eines
Business-Objektes von den Anwendungen und Technologien, mit denen auf
diese Daten zugegriffen wird. Nach außen ist dadurch nur eine Schnittstelle
von klar definierten Methoden sichtbar, uber die Anwendungen auf die Daten
des Business-Objektes zugreifen konnen. Daher genugen dem Anwendungspro-
grammierer Informationen uber diese Methoden, um das Business-Objekt nut-
zen zu konnen. Kenntnisse uber die SAP-spezifischen Implementierungsdetails
sind nicht erforderlich.
An dieser Stelle soll bei Business-Objekten nun unterschieden werden zwi-
schen den Business-Objekttypen oder -Objektklassen und der Instanz eines
Business-Objektes. Wahrend Objekttypen Beschreibungen eines Objektes sind
und diese definieren, bezeichnen Objektinstanzen eine spezifische zur Laufzeit
erzeugte und mit konkreten Daten versehene Instanz seines Objekttyps. So
29
4.4. Business-Objekte
gehoren beispielsweise die Mitarbeiter in einem Unternehmen alle zum Ob-
jekttyp Employee. Der Mitarbeiter mit dem Namen Meier und der Mitarbei-
ternummer 0815 stellt eine Instanz dieses Objekttyps dar.
Anwendungsentwickler definieren bei der objektorientierten Programmie-
rung die Objekttypen, die von ihren Programmen verwendet werden sollen. Zur
Laufzeit greift das Anwendungsprogramm dann auf die spezifischen Instanzen
der definierten Objekttypen zu. Die Instanz eines Business-Objektes stellt nur
die Merkmale und Methoden zur Verfugung, die fur ihren Objekttyp definiert
wurden. Die Business-Objekte definieren sich anhand folgender Eigenschaften:
• Objekttyp
Der Objekttyp beschreibt die allgemeinen Beschaffenheiten, Eigenschaf-
ten und Gemeinsamkeiten jeder einzelnen Objektinstanz.
• Schlusselfelder
Die Schlusselfelder eines Objekttyps bestimmen die Struktur eines Kenn-
zeichnungsschlussels, der einer Anwendung einen eindeutigen Zugriff
auf eine spezifische Instanz des Objekttyps gewahrt. Ein Beispiel stellt
das Schlusselfeld Employee.Number des Objekttyps Employee dar.
Schlusselfelder sind mit Primarschlusseln relationaler Datenbanktabellen
vergleichbar.
• Methoden
Eine Methode ist eine Operation, die auf einem Business-Objekt aus-
gefuhrt werden kann und den Zugriff auf Objektdaten ermoglicht. Eine
Methode ist durch einen Namen und eine Reihe von Parametern und
Ausnahmen definiert, die zur Nutzung der Methode vom aufrufenden
Programm geliefert werden. BAPIs sind Beispiele fur derartige Metho-
den.
• Attribute
Ein Attribut enthalt Daten eines Business-Objektes und beschreibt ein
bestimmtes Objektmerkmal. Employee.Name ist beispielsweise ein At-
tribut des Objekttyps Employee.
Der allgemein geltende Hauptvorteil dieser objektorientierten Technologie ist
die Wiederverwendbarkeit von Softwarekomponenten, die in diesem Fall durch
die Ableitung neuer Objekttypen von vorhandenen Objekttypen erzielt wird.
Wenn ein Objekttyp aus einem vorhandenen generiert wird, wird der neue Ob-
jekttyp als Subtyp (oder Subklasse) und der vorhandene Objekttyp als uber-
geordneter Typ (oder Supertyp oder Superklasse) bezeichnet. Der Objekttyp
Employee ist beispielsweise ein Subtyp, der vom ubergeordneten Typ Person
abgeleitet wurde.
30
4.5. Business Application Programming Interfaces (BAPIs)
Ein Subtyp erbt alle Eigenschaften und Methoden, die fur den uberge-
ordneten Typ gultig sind, von dem der Subtyp abgeleitet wurde. Der Subtyp
kann jedoch auch uber zusatzliche Eigenschaften und Methoden verfugen oder
die Methoden, die er vom ubergeordneten Typ geerbt hat, mit einem ande-
ren Verhalten implementieren. Diese Gegebenheit ist unter dem Begriff des
Polymorphismus bekannt.
4.5 Business Application Programming Interfaces
(BAPIs)
In den vorangehenden Abschnitten dieses Kapitels wurde beschrieben, wie
innerhalb des SAP Business Framework die betriebswirtschaftlichen Daten
und Prozesse des R/3-Systems objektorientiert reprasentiert werden konnen.
Den zielsetzenden Bestandteil dieses Konzeptes stellen die BAPIs (Business
Application Programming Interfaces) dar, die es letztlich ermoglichen, diese
Business-Objekte im verteilten System zuganglich zu machen (Abbildung 4.1
zeigte bereits diesen Sachverhalt). Sie werden nun genauer spezifiziert und cha-
rakterisiert.
Zweck der BAPIs ist es, den Zugriff auf SAP Funktionalitat uber offizielle,
stabile und dialogfreie Schnittstellen zu ermoglichen. Diese Schnittstellen sollen
sowohl von anderen SAP Komponenten als auch von externen Anwendungen,
die von Kunden oder Partnerunternehmen entwickelt werden, benutzt werden
konnen.
BAPIs werden als API-Methoden von SAP Business-Objekttypen defi-
niert. Diese Objekttypen werden dazu verwendet, eine objektbasierte Kom-
munikation zwischen Komponenten zu realisieren. Durch die Business-Objekte
und ihre BAPIs wird es somit moglich, die Vorteile der Objektorientierung in
der zentralen Informationsverarbeitung von Unternehmen zu nutzen. So wird
beispielsweise die Wiederverwendung bestehender Funktionen und Daten, eine
reibungslose technische Interoperabilitat und ein flexibler Einsatz von Fremd-
komponenten moglich.
Implementiert sind BAPIs in R/3 als Funktionsbausteine, d. h. als Pro-
zeduren in der SAP-eigenen Programmiersprache ABAP (Advanced Business
Application Programming). Jeder Funktionsbaustein, der einem BAPI zugrun-
de liegt, wird als Methode den Business-Objekttypen eindeutig zugeordnet. Als
zentrale Einheit sorgt das Business Object Repository (BOR) fur die Verwal-
tung und die Verfugbarkeit dieser Informationen. Mit Hilfe dieser objektorien-
tierten Schnittstellen konnen andere Komponenten somit direkt auf die Anwen-
dungsschicht eines SAP R/3-Systems zugreifen, ohne Implementierungsdetails
kennen zu mussen.
Vervollstandigt wird dieses Integrationsszenrio mittels des Integrations-
dienstes ALE in Abschnitt 4.6.
31
4.5. Business Application Programming Interfaces (BAPIs)
4.5.1 Merkmale von BAPIs
Bei der Betrachtung der BAPIs und der Realisierung der Implementierungen
lassen sich einige charakteristische Merkmale erkennen:
• Namenskonvention
Ein BAPI wird durch den Namen des betreffenden Business-Objekttyps
gefolgt von dem Namen des BAPI selbst vollstandig identifiziert.
Der Name eines BAPI beschreibt die Funktion, die es am Business-
Objekt ausfuhrt. Beispielsweise lautet die vollstandige Indentifizie-
rung des BAPI ExistenceCheck() am Business-Objekt Company
Company.ExistenceCheck().
• Standardisierte BAPIs
Es existieren standardisierte BAPIs, die fur einen Großteil der Business-
Objekttypen implementiert werden konnen. Diese BAPIs stellen gewis-
se Grundfunktionen bereit. Sie erhalten an allen Business-Objekten den
gleichen Namen und werden nach bestimmten Designvorgaben imple-
mentiert. So erlaubt z. B. das BAPI GetList() das Auflisten aller
existierender Instanzen eines Business-Objekttyps und findet etwa in
Company.GetList() und Material.GetList() Anwendung.
• Instanzabhangige und -unabhangige BAPIs
BAPIs konnen nach ihrer Abhangigkeit von Instanzen eines Objekt-
typs unterschieden werden. Instanzabhangige BAPIs (Instanzmetho-
den) beziehen sich auf eine konkrete Instanz eines Business-Objekttyps
(z. B. Company.GetDetail()), wahrend Klassenmethoden instanzu-
nabhangig sind (z. B. Company.GetList()).
• Datenbankkonsistenz
Ein BAPI kann eine Instanz eines Objektes erstellen oder die Daten ei-
nes Objektes verandern. Derartige Anderungen hinterlassen immer einen
konsistenten Datenbankzustand. Alle Datenbankanderungen werden ent-
weder vollstandig oder uberhaupt nicht ausgefuhrt.
• Keine Dialogorientierung
BAPIs liefern keine Bildschirmdialoge vom R/3-System an die aufru-
fende Anwendung zuruck. SAP R/3 bietet allerdings der Moglichkeit,
den systeminternen Aufruf von Funktionsbausteinen uber eine SAP GUI-
Komponente zu visualisieren. Basierend auf dem Function Builder, der
in R/3 die Verwaltung der Funktionsbausteine ubernimmt, steht eine in-
tegrierte Test- und Entwicklungsumgebung mit Benutzeroberflache zur
Verfugung. Funktionsbausteine, die BAPIs zugrunde liegen, konnen hier
auf konkreten Parametern ausgefuhrt und Ruckgabewerte eingesehen
32
4.5. Business Application Programming Interfaces (BAPIs)
werden. Abschnitt 4.5.5 zeigt entsprechende GUI-Dialoge an einem Bei-
spiel eines Funktionsbausteins.
• Berechtigungen
Jede Benutzerinteraktion mit einem R/3-System setzt entsprechende Be-
rechtigungen voraus. Die Benutzer der Anwendung, die BAPIs ausfuhrt,
mussen uber die notwendigen Berechtigungen in den R/3-Stammdaten
verfugen, um den BAPI Aufruf zu ermoglichen. Jeder auf Grund un-
zureichender Berechtigungen fehlgeschlagene Ausfuhrungsversuch eines
BAPI wird der aufrufenden Anwendung gemeldet.
• Attribute von Business-Objekten
Der Zugriff auf die Attribute (Daten) eines Business-Objektes erfolgt
uber die BAPI Schnittstelle selbst. Ein Beispiel hierfur ist die Zugriffs-
methode GetDetail().
4.5.2 Vorteile von BAPIs
Die folgenden Punkte fassen die Vorteile zusammen, die sich aus der Einfuhrung
und Nutzung der BAPIs als Zugriffsmethoden auf die SAP Business-Objekte
ergeben.
• Betriebswirtschaftlicher Standard
Die Business-Objekttypen und ihre BAPIs bilden den Standard fur die
betriebswirtschaftlichen Inhalte des R/3-Systems und ermoglichen die In-
tegration von R/3 und anderer Softwarekomponenten auf betriebswirt-
schaftlicher Ebene.
• Konformitat mit Standards
Eine Initiative der SAP AG mit Kunden, Partnern und fuhrenden Nor-
menorganisationen ist verantwortlich fur die Entwicklung der BAPIs.
Als Zielsetzung bildete sich die Entwicklung eines Kommunikationsstan-
dards zwischen betriebswirtschaftlichen Systemen heraus. Die Business-
Objekte von SAP sind konform mit den Spezifikationen und Richtlinien
der Open Applications Group (OAG) [7].
• Stabilitat und Abwartskompatibilitat
Die Schnittstellen eines BAPI bleiben nach der Einfuhrung und Freigabe
durch SAP langfristig stabil. Anwendungen werden somit von Anderun-
gen der zugrunde liegenden R/3-Software und -Daten nicht beeinflusst.
Erweiterungen von BAPIs konnen durch Hinzufugen weiterer Parameter
realisiert werden, ohne die Stabilitat vorhandener Anwendungen zu be-
eintrachtigen. Neue Anwendungen konnen dagegen von der neuen Funk-
tionalitat profitieren.
33
4.5. Business Application Programming Interfaces (BAPIs)
• Objektorientierung
Die Architektur der SAP Business-Objekte und BAPIs als Schnittstellen-
methoden folgen den Prinzipien der Objektorientierung. BAPIs konnen
mit Hilfe objektorientierter Schnittstellentechnologien aufgerufen werden
und ermoglichen auf diese Weise die freie Interaktion der Softwarekom-
ponenten von SAP und anderen Anbietern.
• Offenheit
Der Zugriff auf BAPIs kann von allen Plattformen erfolgen, die das SAP
Protokoll RFC unterstutzen.
4.5.3 Voraussetzungen fur den Zugriff auf BAPIs
Um die BAPI Schnittstellen fur den Zugriff auf SAP Business-Objekte zu nut-
zen, mussen neben dem Namen des BAPI Informationen uber die Methodenpa-
rameter vorliegen, um einen Aufruf aus einem Anwendungsprogramm realisie-
ren und Ruckgabewerte verarbeiten zu konnen. Dabei muss einerseits zwischen
verschiedenen Parametertypen differenziert und andererseits eine Betrachtung
der zugrunde liegenden Datentypen erfolgen.
ABAP Datentypen
Datentypen in ABAP unterteilen sich in elementare und komplexe Typen.
Komplexe Datentypen werden nach Strukturen und Tabellen differenziert.
• Elementare Datentypen
Elementare Typen (auch Felder genannt) sind sogenannte in R/3”einge-
baute“ Datentypen und atomar in dem Sinn, dass sie nicht aus anderen
Typen zusammengesetzt sind (Abbildung 4.2 (a)).
• Strukturen
Strukturen (oder Feldleisten) sind eine Folge beliebiger elementarer oder
auch komplexer Datentypen. Strukturen konnen somit beliebige Kom-
ponenten enthalten, weshalb sie zusatzlich in geschachtelte und nicht-
geschachtelte sowie flache und tiefe Strukturen (Abbildung 4.2 (b) und
(e)) unterteilt werden.
• Tabellen
Tabellen bestehen aus einer Folge von Zeilen gleichen Datentyps. Ihr Zei-
lentyp kann ein beliebiger elementarer (Abbildung 4.2 (c)) oder wiederum
komplexer Datentyp sein (Abbildung 4.2 (d)). Tabellen werden immer
dann eingesetzt, wenn mehrfache Daten einer festen Struktur program-
mintern verwendet werden.
34
4.5. Business Application Programming Interfaces (BAPIs)
Abbildung 4.2: (a) elementarer ABAP Datentyp (b) nicht-geschachtelte,
flache Struktur (c) Tabelle mit elementarem Datentyp (d) Tabelle mit
nicht-geschachtelter Struktur (”echte“ Tabelle) (e) tiefe Struktur
ABAP Datentypen werden im sogenannten ABAP Dictionary als benutzerdefi-
nierte ABAP Dictionary Datentypen (auch Datenobjekte genannt) verwaltet.
Sie liefern die Sicht des Benutzers auf die Daten, d. h. das Datenformat an
der Benutzeroberflache, wahrend der ABAP Datentyp die Datenobjekte be-
schreibt. Beispielsweise wird der ABAP Dictionary Datentyp CHAR n auf den
elementaren ABAP Datentyp C der Lange n abgebildet.
BAPI Parameter
BAPIs verwenden in der Regel bis zu drei der Parametertypen:
• Importparameter
Die Parameter, die der Methode beim Aufruf ubergeben werden, werden
als Importparameter bezeichnet. Sie sind entweder elementaren Daten-
typs oder in Auspragung als Struktur. Ein BAPI kann auch ohne Im-
portparameter sein.
• Exportparameter
Exportparameter definieren die an die aufrufende Anwendung zuuckge-
lieferten Parameter und konnen ebenfalls von elementarem oder Struk-
turtyp sein. Ein BAPI muss mindestens den standardisierten Exportpa-
rameter RETURN besitzen, der Statusmeldungen oder aufgetretene Fehler
dokumentiert. Dieser kann allerdings als Tabellenparameter ausgepragt
sein.
• Tabellenparameter
Tabellenparameter sind optional einsetzbar. Sie konnen dazu verwen-
det werden, eine beliebige Anzahl von Parametern derselben Struktur
in Form einer Tabelle zu ubergeben oder zuruckzuliefern. Tabellenpara-
35
4.5. Business Application Programming Interfaces (BAPIs)
meter sind somit als Import- und Exportparameter nutzbar. Ein Tabel-
lenparameter kann nicht aus elementaren Datentypen bestehen.
Diese prinzipiellen Kenntnisse uber die BAPI Parameter und deren Datentypen
sind fur die Programmierung der Methodenaufrufe notwendig. Als Metadaten
von Funktionsbausteinen werden sie in Kapitel 5 verfugbar gemacht.
4.5.4 Zugriffsmoglichkeiten
Basierend auf der Trennung der Definition eines BAPI als Methode auf einem
Business-Objekt von seiner tatsachlichen Implementierung als Funktionsbau-
stein ergeben sich zwei unterschiedliche technologische Ansatze, um auf BAPIs
zuzugreifen.
Abbildung 4.3: Zugriff auf BAPIs
• Objektorientierter Zugriff
Wie Abbildung 4.3 darstellt, erfolgt der objektorientierte Aufruf des BA-
PI uber das Business Object Repository. Das BOR stellt die entspre-
chenden Metadaten der Methode zur Verfugung und liefert Instanzen
der zugehorigen Objekttypen auf denen das BAPI schließlich ausgefuhrt
wird.
Der objektorientierte Zugriff ist uber zahlreiche Programmierplatt-
formen moglich. Beispielsweise wird eine BAPI C++- und Java-
Klassenbibliothek angeboten ebenso wie ein SAP DCOM Component
Connector2 und mit ObjectBridge eine CORBAR-basierte Middleware.
• Funktionsorientierter Zugriff
2Der SAP DCOM Component Connector ist ein von Microsoft und der SAP AG ge-
meinsam entwickelter Adapter zur Integration von SAP Business-Objekten und Microsoft
COM-Objekten. Weitere Informationen finden sich in der SAP Bibliothek [8] zur DCOM
Connector Architektur und unter [5].
36
4.5. Business Application Programming Interfaces (BAPIs)
Ahnlich zum objektorientierten Ansatz erfolgt der funktionsorientierte
Zugriff auf ein BAPI. Die Aufgabe des BOR ubernimmt bezuglich der
Funktionsbausteine der Function Builder, und die Client-Aufrufe werden
gemaß dem RFC-Protokoll an den gewunschten Funktionsbaustein im
R/3-System weitergeleitet.
Grundvoraussetzung fur das Gelingen eines RFC-Zugriffs auf einen Funk-
tionsbaustein ist, dass dieser in R/3 explizit als”remotefahig“ gekenn-
zeichnet ist.
Im Rahmen dieser Arbeit wird ausschließlich das Modell des funktionsorientier-
ten, also RFC-basierten Zugriffs auf die BAPIs angewendet. Es soll sowohl eine
moglichst plattform- und betriebssystemunabhangige Middleware verwendet
werden als auch eine weitestgehend einfach zu nutzende und dennoch perfor-
mante Technologie zum Einsatz kommen, so dass letztlich mit dem SAP Java
Connector (JCo) gearbeitet wird, der in Kapitel 5 mit seinen Moglichkeiten
vorgestellt wird.
4.5.5 Beispiel: Company.GetList()
Zur Veranschaulichung einer BAPI Schnittstellenmethode und deren Parame-
ter gewahrt dieser Abschnitt basierend auf dem entsprechenden BAPI Funkti-
onsbaustein anhand von Screenshots des SAP GUI einen Einblick in die Bild-
schirmdialoge des Function Builder.
Als Beispiel dient das standardisierte und instanzunabhangige BAPI
GetList() auf dem Business Objekt Company. Der zugehorige Funktions-
baustein BAPI COMPANY GETLIST ist uber den Function Builder auszuwahlen
und anzuzeigen.
37
4.5. Business Application Programming Interfaces (BAPIs)
Abbildung 4.4: SAP Function Builder
In nachfolgenden Abbildungen zeigt die GUI des Function Builder die Import-,
Export- und Tabellenparameter des Funktionsbausteins.
Abbildung 4.5: Importparameter BAPI COMPANY GETLIST
38
4.5. Business Application Programming Interfaces (BAPIs)
Abbildung 4.6: Exportparameter BAPI COMPANY GETLIST
Abbildung 4.7: Tabellenparameter BAPI COMPANY GETLIST
BAPI COMPANY GETLIST besitzt keine Importparameter. Der standardisierte
Parameter mit Namen RETURN ist der einzige Exportparameter. Der Tabel-
lenparameter COMPANY LIST wird schließlich als Exportparameter dienen und
die Liste aller Unternehmen, d. h. aller im R/3-System verfugbaren Instanzen
des Objekttyps Company zuruckliefern. Die Attribute der Objektinstanzen, die
exportiert werden, definieren sich auf Grund der Struktur, die dem Tabellentyp
BAPI0014 1 von COMPANY LIST zugrunde liegt (Abbildung 4.7, blaue Mar-
kierung). Abbildung 4.8 zeigt deren beiden Attribute COMPANY und NAME1
dar.
Abbildung 4.8: Struktur des Tabellenparameter BAPI COMPANY GETLIST
Da keine Importparameter zu fullen sind, kann der Funktionsbaustein ohne
Benutzereingabe ausgefuhrt werden und folgende Ruckgabewerte liefern:
39
4.6. Integrationsdienst ALE (Application Link Enabling)
Abbildung 4.9: Ausgabe BAPI COMPANY GETLIST
4.6 Integrationsdienst ALE (Application Link
Enabling)
Das Konzept des Application Link Enabling (ALE) bildet die Grundlage fur
die Interaktion im objektorientierten Ansatz des SAP Business Framework.
ALE bezeichnet eine nachrichtenorientierte Middlewarearchitektur, welche die
Verteilung der betriebswirtschaftlichen Prozesse und Funktionen in einer SAP
Umgebung ubernimmt.
Hierbei beschreibt das logische ALE-Verteilungsmodell innerhalb seiner
Konfiguration, welche Anwendungen auf welchen Systemen laufen und wel-
che Business-Objekttypen die Anwendungen untereinander austauschen bzw.
welche BAPIs aufgerufen werden konnen.
Das Design samtlicher, im Rahmen des Business Framework relevanter
Sachverhalte, erfolgt szenariengetrieben, d. h. Integrationsszenarien beschrei-
ben, wie und welche Komponenten, Business-Objekttypen und BAPIs zusam-
menspielen (Abbildung 4.10). Das Verteilungsmodell des ALE sorgt fur die
Integration, indem es die Szenarien definiert und damit auf semantischer Ebe-
ne die Synchronisation von Geschaftsprozessen sicherstellt.
40
4.7. Remote Function Call (RFC)
Abbildung 4.10: ALE Integrationsszenario
4.7 Remote Function Call (RFC)
Unter einem Remote Function Call (RFC) wird ein”entfernter Funktionsauf-
ruf“ verstanden. RFC kann als eine SAP-Variante des Remote Procedure Call
(RPC) angesehen werden. Bei RFC handelt sich dabei um den Aufruf eines als
remotefahig gekennzeichneten Funktionsbausteins, der sich auf demselben oder
einem entfernten System befinden kann. Obwohl die Moglichkeit besteht, einen
Funktionsbaustein auch lokal uber RFC aufzurufen, verfolgt der Grundgedan-
ke des RFC vor allem Aufrufe aus verschiedenen (externen), typischerweise
heterogenen Systemen. Das RFC-Schnittstellenprotokoll erlaubt also Funkti-
onsaufrufe zwischen zwei SAP Systemen (auch R/2 und R/3) oder zwischen
einem SAP System und einem nicht-SAP System. Es ubernimmt dabei die
Kommunikationssteuerung, die Parameterubergabe und die Fehlerbehandlung.
Echtzeit-Kommunikation mit sRFC (synchronous RFC)
Die in diesem Kapitel beschriebenen Kommunikationsszenarien des ent-
fernten Aufrufs eines BAPIs uber dessen remotefahigen Funktionsbaustein,
folgen der synchronen Ubertragungsform der Daten und werden als sRFC
(synchronous RFC ) bezeichnet. Dies setzt voraus, dass das gerufene Sy-
stem, der RFC-Server, erreichbar ist. Der aufrufende Client ist in seinem
Programmablauf blockiert, solange die Server-Antwort aussteht.
41
Kapitel 5
Zugriff auf SAP R/3 mit SAP
Java Connector (JCo)
In Kapitel 4 wurde das SAP R/3-System mit seinem Business Framework vor-
gestellt. Wahrend dort mit RFC eine grundlegende Technologie beschrieben
wurde, um auf R/3-Anwendungsfunktionalitaten und somit schließlich auf die
betriebswirtschaftlichen Objektdaten zuzugreifen, behandelt dieses Kapitel die
praktische Anwendung dieser Technologie mit Hilfe der SAP Java Middleware
JCo.
Der JCo bietet grundsatzlich die Moglichkeit, sowohl von Java-
Programmen auf R/3-interne ABAP-Komponenten und -Programme zuzugrei-
fen (inbound call) als auch den Aufruf von Java-Applikationen mit ABAP
(outbound call) zu realisieren. Auf Grund der Zielsetzung dieser Arbeit ist hier
lediglich das Szenario des inbound call von Interesse.
Als Informationsquellen dienten das JCo-Tutorial [9] sowie die API-
Dokumentation der eingesetzten Version 1.1.03, die dem von SAP zur
Verfugung gestellten JCo-Paket beiliegen.
Anstelle der Terminologie BAPI wird von nun an aus bereits dargelegten
Grunden der Begriff des Funktionsbausteins verwendet.
5.1 Technologie des JCo
Der SAP Java Connector (JCo) ermoglicht dem Programmierer, remotefahige
SAP Funktionsbausteine (Remote Function Modules, RFMs) von einem exter-
nen SAP-fremden System aus uber die Programmiersprache Java aufzurufen
(Client-Programmierung), ohne direkt auf die API des RFC-Protokolls zugrei-
fen zu mussen. Die RFC API beinhaltet eine Reihe von Funktionen in der
Programmiersprache C, die mit der Entwicklung der RFC-Klassenbibliothek in
C++-Klassen gekapselt wurden. Der JCo setzt auf dieser Bibliothek auf und
kann somit als objektorientierte Schicht uber der RFC API gesehen werden.
Abbildung 5.1 schematisiert die Technologiearchitektur.
42
5.2. Verbindungsaufbau
Gemaß [9] ist der JCo die beste Wahl fur die Entwicklung von Java-
Applikationen mit R/3-Funktionalitat. Basierend auf dem Java Native Inter-
face (JNI) realisiert JCo eine einfach zu nutzende und performante Middleware
fur das RFC-Protokoll. Er ist fur viele gangige Betriebssystemplattformen wie
Windows, Linux, Solaris, IBM-AIX, HP-UX etc. verfugbar.
Abbildung 5.1: SAP Java Connector Architektur
Ebenso wie in [9] kann auch im Rahmen der Aufgabenstellung dieser Arbeit
die Behandlung der SAP-Client-Programmierung auf die synchrone Kommu-
nikation (sRFC) beschrankt werden.
Aus programmiertechnischer Sicht bereitet die import-Anweisung
import com.sap.mw.jco.*;
auf die Verwendung aller JCo-Klassen vor.
5.2 Verbindungsaufbau
Der JCo unterstutzt zwei Programmiermodelle fur den Verbindungsaufbau zu
SAP R/3-Systemen:
• Direkte Verbindungen (direct connections)
Direkte Verbindungen konnen beliebig viele hergestellt werden. Sie blei-
ben solange geoffnet bis sie explizit vom Anwendungsprogrammierer ge-
schlossen werden.
• Verbindungspools (connection pools)
Ein Verbindungspool definiert eine spezifizierte Menge von verfugbaren
Verbindungen, die dem Pool entnommen und genutzt werden konnen. Die
43
5.2. Verbindungsaufbau
Anzahl der gleichzeitig zu verwendeten Verbindungen ist somit durch den
Pool beschrankt. Das Offnen und Schließen der jeweiligen Verbindungen
wird von einem Pool-Manager gesteuert.
Um ubermaßigen Overhead auf Seiten des R/3 zu vermeiden, der durch
das Einloggen auf dem System entsteht, sollten insbesondere Webapplika-
tionen Verbindungspools einsetzen. Die Anzahl der parallel bestehenden
Verbindungen wird auf einem fixen Maß gehalten. Zusatzlich wird haufigem
Neuaufbau von Verbindungen dadurch entgegengewirkt, dass diese uber die
Ausfuhrungszeit einer Applikation hinaus offen gehalten werden und bei
Bedarf ohne Neuanmeldung am System zur Verfugung stehen.
Eine Verbindung zu einem SAP R/3-System wird vom SAP Java Connector
uber eine Objektinstanz der Klasse JCO.Client reprasentiert.
JCO.Client client;
Je nach gewahlter Verbindungsart gemaß obiger Modelle werden diese unter-
schiedlich erzeugt.
Direkte Verbindungen
Fur eine direkte Verbindung mit einem R/3-System liefert die statische
Methode createClient der Klasse JCO in Abhangigkeit verschiedener
Verbindungsparameter ein JCO.Client-Objekt.
client = JCO.createClient("001", // SAP Client Nummer"<user>", // Benutzername"<password>", // Kennwort"DE", // Sprache"<host>", // Name des Applikationsservers/IP-Adresse"00"); // Systemnummer
Der JCo bietet mehrere uberladene Versionen dieser Methode an. Diese konnen
der JCo API-Dokumentation entnommen werden. An dieser Stelle soll noch die
Moglichkeit aufgezeigt werden, die Verbindungsparameter als Objekt der Java
Standard-Klasse java.utils.Properties zu ubergeben. Listing 5.1 zeigt
den zughorigen Programmcode.
Properties props = new Properties();
props.setProperty("jco.client.client", "001");props.setProperty("jco.client.user", "<user>");props.setProperty("jco.client.passwd", "<password>");props.setProperty("jco.client.lang", "DE");props.setProperty("jco.client.host", "<host>");props.setProperty("jco.client.sysnr", "00");
44
5.2. Verbindungsaufbau
client = JCO.createClient(props);
Listing 5.1: JCO.Client-Objekt zur direkten Verbindung mit R/3
Die Erzeugung des JCO.Client-Objekts offnet allerdings noch keine Ver-
bindung zum SAP R/3-System. Dies ubernimmt dessen connect-Methode.
Das Schließen der Verbindung veranlasst letztlich ein Aufruf der Methode
disconnect.
try {client.connect();
/* Aufrufen von SAP Funktionen (RFMs) */}catch (Exception ex) {
System.out.println("Verbindung kann nicht hergestellt werden.");}finally {
client.disconnect();}
Verbindungspools
Ein Verbindungspool des JCo wird durch seinen Namen identifiziert
und ist innerhalb der Java Virtual Machine (JVM) fur Anwendungen global
zuganglich. Alle Verbindungen in einem Pool basieren auf denselben Werten
der Verbindungsparameter, verwenden also die gleichen System-, Benutzer-
und Client-Informationen. Es konnen beliebig viele Pools angelegt werden.
JCO.addClientPool("BeispielPool",10,"001","<user>","<passwort>","DE","<host>","00");
Analog zur direkten Verbindungsart liefert auch bei Verwendung von Verbin-
dungspools die Klasse JCO uber eine statische Methode das JCO.Client-
Objekt in Abhangigkeit des eindeutigen Namen des Pools.
try {client = JCO.getClient("BeispielPool");
/* Aufrufen von SAP Funktionen (RFMs) */}catch (Exception ex) {
System.out.println("Verbindungspool existiert nicht oder maximaleAnzahl offener Verbindungen ist erreicht.");
}
45
5.3. Metadaten von RFMs
finally {JCO.releaseClient(client);
}
Listing 5.2: JCO.Client-Objekt aus R/3-Verbindungspool
Die getClient-Methode liefert entweder eine bestehende offene Verbindung
zuruck oder offnet eine neue, falls deren maximale Anzahl noch nicht erreicht
ist (der”BeispielPool“ erlaubt 10 offene Verbindungen).
Im Unterschied zu direkten Verbindungen werden die Verbindungen aus
Verbindungspools nicht explizit geschlossen, sondern uber die statische JCO-
Methode releaseClient in den Pool”zuruckgelegt“ und damit zur er-
neuten Verwendung freigegeben. Der Pool-Manager ubernimmt implizit die
Aufgabe der Verwaltung der angelegten Pools sowie die Kontrolle uber den
Verbindungsauf- und abbau auf JCO.Client-Objekten. Nachfolgendes Li-
sting 5.3 zeigt Beispiele, den Pool-Manager zu nutzen und zu konfigurieren.
// JCo Pool-Manager ObjektJCO.PoolManager manager = JCO.getClientPoolManager();
// "Uberpr"ufung auf existierenden VerbindungspoolJCO.Pool pool = manager.getPool("BeispielPool");if (pool == null) {
// ...}
// Zeitspanne bis zum Schlieen einer ungenutzten offenen Verbindung// default-Wert: 600000 ms = 10 minmanager.setConnectionTimeout(600000);
Listing 5.3: JCO.PoolManager
5.3 Metadaten von RFMs
5.3.1 JCO.Repository und JCO.Function
Das SAP Repository enthalt als zentrale Verwaltungseinheit aller R/3-
Systemdaten unter anderem die Metainformationen zu den systemweit
verfugbaren RFMs. Die Klasse JCO.Repository implementiert dieses Re-
pository und macht auf Basis einer konkreten R/3-Verbindung JCO.Client
client die Metadaten eines bestimmten RFM dynamisch aus dem R/3-
Repository zur Laufzeit abrufbar:
JCO.Repository repository =new JCO.Repository("BeispielRepository", client);
try {IFunctionTemplate ft =
repository.getFunctionTemplate("BeispielRFM");
46
5.3. Metadaten von RFMs
JCO.Function function = ft.getFunction();}catch (Exception ex) {
System.out.println("Der Funktionsbaustein ist nicht vorhanden.");}
Listing 5.4: RFM als JCO.Function-Objekt
RFMs werden von dem JCo als Objekte der Klasse JCO.Function reprasen-
tiert. Das JCo Repository liefert uber die Methode getFunctionTemplate
eine”Funktionsvorlage“, die alle Metadaten und Parameter des RFM kapselt.
Der JCo ruft diese Informationen lediglich einmal ab und cached sie dann aus
Performancegrunden. Das JCO.Function-Objekt wird aus der Funktionsvor-
lage erzeugt und tragt die aktuellen Parameter, die fur die Ausfuhrung des
RFM erforderlich sind. Die Beziehung zwischen einer Funktionsvorlage und ei-
ner Funktion innerhalb des JCo ist vergleichbar mit der einer Klasse und eines
Objektes in Java.
5.3.2 JCO.ParameterList
Die Klasse JCO.Function stellt die drei Methoden
• getImportParameterList(),
• getExportParameterList() und
• getTableParameterList()
zum Zugriff auf eine Liste der jeweiligen Parametertypen eines RFM zur
Verfugung. Die einzelnen Parameterobjekte dieser JCO.ParameterList-
Instanzen sind gemaß ihrem Datentyp und Namen zuganglich: Erinnert man
sich an die moglichen ABAP Datentypen aus Kapitel 4, Abschnitt 4.5.3, kom-
men fur Import- und Exportparameter Felder und Strukturen in Betracht,
wahrend Tabellenparameter den Tabellentyp auspragen1. Der JCo bildet diese
Datentypen uber entsprechende Klassenobjekte ab:
• getField(String name) bzw. getField(int i) liefert ein Ob-
jekt vom Typ JCO.Field,
• getStructure(String name) bzw. getStructure(int i) ein
Objekt vom Typ JCO.Structure und
• getTable(String name) bzw. getTable(int i) ein Objekt der
Klasse JCO.Table,
1Obwohl SAP R/3 ab Release Version 4.6C die beliebige Schachtelung komplexer Da-
tentypen unterstutzt, nutzen BAPIs diese Moglichkeit nicht [9]. Stattdessen werden lediglich
nicht-geschachtelte, flache Strukturen sowie”echte“ Tabellen verwendet (vgl. Abbildung 4.2).
47
5.3. Metadaten von RFMs
wobei name den Namen des Parameter bzw. i den Positionsindex des Para-
meter innerhalb der Parameterliste bezeichnet.
Strukturen und Tabellen sind aus Feldern zusammengesetzte ABAP Dic-
tionary Datentypen und lassen sich damit letztlich, wie der Feldtyp selbst,
auf einen elementaren ABAP Datentyp zuruckfuhren2. Daher bietet der JCo
Getter- und Setter-Methoden auf den JCO.Field-Objekten an, die die Feld-
inhalte gemaß einer Konvertierungstabelle fur elementare ABAP Datentypen
und Java Datentypen liefern und setzen. Das Type-Mapping (Tabelle 5.1) wird
in Tabelle 5.2 den JCo Zugriffsmethoden gegenubergestellt.
Elementarer Beschreibung Java Datentyp JCo Typ-Konstante
ABAP Typ
b 1-Byte Integer int JCO.TYPE INT1
s 2-Byte Integer int JCO.TYPE INT2
l 4-Byte Integer int JCO.TYPE INT
C Zeichen String JCO.TYPE CHAR
N Numerisches Zeichen String JCO.TYPE NUM
P BCD (Binary Coded Decimal) BigDecimal JCO.TYPE BCD
D Datum Date JCO.TYPE DATE
T Zeit Date JCO.TYPE TIME
F Fließkommazahl double JCO.TYPE FLOAT
X Raw Data byte[ ] JCO.TYPE BYTE
g Zeichenkette (variable Lange) String JCO.TYPE STRING
y Raw Data (variable Lange) byte[ ] JCO.TYPE XSTRING
Tabelle 5.1: Mapping von ABAP Datentypen und Java Datentypen
JCo Typ-Konstante JCo Zugriffsmethoden
Getter-Methoden Setter-Methoden
JCO.TYPE INT1 int getInt() void setValue(int i)
JCO.TYPE INT2 int getInt() void setValue(int i)
JCO.TYPE INT int getInt() void setValue(int i)
JCO.TYPE CHAR String getString() void setValue(String s)
JCO.TYPE NUM String getString() void setValue(String s)
JCO.TYPE BCD BigDecimal getBigDecimal() void setValue(Object o)
JCO.TYPE DATE Date getDate() void setValue(Object o)
JCO.TYPE TIME Date getTime() void setValue(Object o)
JCO.TYPE FLOAT double getDouble() void setValue(double d)
JCO.TYPE BYTE byte[ ] getByteArray() void setValue(byte[ ] b)
JCO.TYPE STRING String getString() void setValue(String s)
JCO.TYPE XSTRING byte[ ] getByteArray() void setValue(byte[ ] b)
Tabelle 5.2: Java Datentypen und JCo Zugriffsmethoden
2Es wird daran erinnert, dass ein Unterschied besteht zwischen ABAP Dictionary Daten-
typen oder Datenobjekten und ABAP Datentypen (vgl. Abschnitt 4.5.3).
48
5.4. Aufruf von RFMs
5.4 Aufruf von RFMs
Der Aufruf der Remote-Funktionsbausteine erfolgt, nachdem alle erforderlichen
Importparameter uber die JCo Setter-Methoden derer Felder gefullt wurden.
Es ist dabei nicht zwingend notwendig, alle Felder mit Werten zu belegen.
Die Implementierung des BAPI im Funktionsbaustein in R/3 ubernimmt zur
Laufzeit die Uberprufung der Importdaten und liefert gegebenenfalls Status-
meldungen uber den RETURN-Parameter an den Client zuruck.
Die Problematik ist hierbei allerdings, dass die JCo API die Funktionalitat zur
Abfrage der Mussfelder von Importparametern nicht unterstutzt. Dies wird
bei der spateren benutzergesteuerten Definition der Web Service Methoden
von Bedeutung sein.
Prinzipiell geschieht der Aufruf des RFM uber das R/3-Verbindungsobjekt
JCO.Client und der JCo RFM Instanz wie folgt:
try {client.execute(function);
}catch {
System.out.println("Fehler beim Aufruf des RFM.");}
Listing 5.5: RFM Aufruf
5.5 Beispiel: BAPI COMPANY GETLIST
Der Funktionsbaustein aus Abschnitt 4.5.5 wird auch in diesem Kapitel als
Grundlage dienen, die hier behandelte Thematik an einem konkreten RFM
zusammenzufassen. Die Paramter konnen anhand der Abbildungen in Kapitel
4 nachvollzogen werden.
BAPI COMPANY GETLIST als RFM besitzt keine Importparameter. Der
Tabellenparameter COMPANY LIST referenziert als”echte“ Tabelle die Felder
COMPANY und NAME1 in seinen Zeilen. Die Felder sind vom ABAP Dictionary
Datentyp CHAR und werden somit nach Tabelle A in den elementaren ABAP
Typ C konvertiert und von JCo in Java als String behandelt (siehe Tabelle
5.1).
Der Aufruf des RFM und das Auslesen der Felder des Tabellenparameter er-
geben sich mit JCo nach folgendem Listing 5.6:
import com.sap.mw.jco.*;
try {// Verbindung erstellenJCO.Client client =
JCO.createClient("020","TNO100124","******",
49
5.5. Beispiel: BAPI COMPANY GETLIST
"DE","164.23.5.154","20");
// Verbindung ffnenclient.connect();
// Repository erzeugenJCO.Repository repository =
new JCO.Repository("de.tsystems.ws.sap.repository", client);
// Funktionsbaustein einlesenJCO.Function function =
repository.getFunctionTemplate("BAPI_COMPANY_GETLIST").getFunction();
// Funktionsbaustein aufrufenconn.execute(function);
// Tabelle einlesenJCO.Table table = function.getTableParameterList().getTable("
COMPANY_LIST");
// Tabellenzeilen durchlaufenfor (int i = 0; i < table.getNumRows(); i++) {
table.setRow(i); // Cursor auf Zeile setzenSystem.out.println(table.getString("NAME1") + ’\t’ +
table.getString("COMPANY"));}
client.disconnect(); // Verbindung trennen}catch (Exception ex) {
ex.printStackTrace();}
Listing 5.6: JCo und BAPI COMPANY GETLIST
Die Ausgabe des Programms beinhaltet schließlich die zur Abbildung 4.9
identische Datenliste des SAP Function Builder.
50
Kapitel 6
Zugriff auf relationale
Datenbanken mit JDBC
Dieses Kapitel behandelt in Analogie zum SAP Java Connector fur den Zugriff
auf R/3-Systeme die JDBC-Schnittstelle als Moglichkeit fur den Zugriff auf
relationale Datenbanksysteme.
JDBC ist eine Datenbankschnittstelle der Sun Microsystems, Inc., die un-
abhangig von einem konkreten Datenbanksystem wie beispielsweise ORACLE
ist. Die damit einhergehende Moglichkeit zur Portierung auf andere Daten-
banksysteme stellt zusammen mit der Tatsache, als Java-basierte Technologie
plattformunabhangig zu arbeiten, ein wesentlicher Vorteil dar. Zudem rechtfer-
tig die aufwandsarme und einfache Programmierung mit JDBC deren Einsatz,
nicht zuletzt im Rahmen der vorliegenden Aufgabenstellung dieser Arbeit.
Die API-Spezifikation fur JDBC [11] wurde von JavaSoft im Marz 1996
als vorlaufige Version 0.50 vorgestellt. Sie liegt nunmehr in der Version 3.0 vor
und wird mit Sun’s Java Development Kit (JDK) Version 1.4 ausgeliefert.
Die Moglichkeiten der JDBC werden nachfolgend nur insoweit angefuhrt,
wie sie in der Implementierung der erzeugten Web Services dieser Arbeit ge-
nutzt werden. Grundkenntnisse zum Modell und zur Anfragesprache Structured
Query Language (SQL) von relationalen Datenbanksystemen werden voraus-
gesetzt, da eine Einfuhrung den Rahmen dieser Arbeit sprengen wurde. Als
Literaturhinweise sind beispielsweise [4] oder [22] zu nennnen.
6.1 Technologie der JDBC
Die Java Database Connectivity ist in den Standardklassen des JDK seit Ver-
sion 1.1 enthalten. Die Klassen und Interfaces der JDBC API befinden sich
in den Paketen java.sql und javax.sql. Sie definieren lediglich den Zu-
griffsmechanismus, die Methoden, durch welche man aus Java auf relationale
Datenbanken zugreifen kann.
Die Arbeit wird beim Datenbankzugriff vom sogenannten JDBC-Treiber
51
6.1. Technologie der JDBC
durchgefuhrt, der die JDBC-Schnittstellenmethoden datenbankspezifisch im-
plementiert.
Die Verwaltung der Treiber in der Java Laufzeitumgebung wird vom
JDBC-Treibermanager ubernommen. Wenn man eine Verbindung zu einem
konkreten Datenbanksystem aufbauen will, muss man den zugehorigen Trei-
ber zunachst beim Treibermanager registrieren. In einer Anwendung kann man
prinzipiell beliebig viele Treiber beim Treibermanager anmelden. Beim Verbin-
dungsaufbau zu einer Datenbank wird anschließend vom Treibermanager der
benotigte Treiber angefordert. Wenn der Treiber dem Treibermanager bekannt
ist, wird er initialisiert und fur die Durchfuhrung der Datenbankzugriffe ver-
wendet.
Die Gesamtarchitektur von JDBC zeigt nachfolgende Abbildung 6.1.
Abbildung 6.1: JDBC Architektur
Als die wichtigsten Klassen und Interfaces bei der Programmierung mit JDBC
sind zu nennen:
• DriverManager
Die Klasse ist – wie bereits beschrieben – fur die Verwaltung der daten-
bankspezifischen JDBC-Treiber zustandig und ist im java.sql-Paket
direkt implementiert.
Stattdessen sind die Implementierungen der folgenden Interfaces der
JDBC API abhangig vom Datenbanksystem und somit Teil der JDBC-
Treiber:
• Connection
Eine Verbindung zu einer Datenbank wird durch die Implementierungs-
klasse Connection reprasentiert. Sie wird fur die Ausfuhrung von
52
6.2. Verbindungsaufbau
SQL-Anweisungen und den Zugriff auf die Metadaten in der Datenbank
benotigt.
• DatabaseMetaData
Der Zugriff auf das Data Dictionary1 erfolgt uber die vom JDBC-Treiber
implementierte Klasse DatabaseMetaData.
• Statement
Statement stellt die Basisklasse fur die Ausfuhrung von SQL-
Anweisungen dar. Mit ihr konnen beliebige, als String vorliegende SQL-
Anweisungen an das Datenbanksystem geschickt werden.
• PreparedStatement
Ein prepared statement definiert eine SQL-Anweisung, in denen Platz-
halter (≫?≪) fur Parameter gesetzt werden. Um dieselbe Anweisung
mehrmals mit wechselnden Parametern auszufuhren, konnen diese Platz-
halter mit Werten belegt werden. In JDBC steht dazu das Interface
PreparedStatement zur Verfugung.
• ResultSet
ResultSet stellt eine Ergebnismenge einer SQL-Abfrage (Query) dar.
6.2 Verbindungsaufbau
Bevor eine Verbindung zu einer Datenbank uber den JDBC-Treiber erfolgen
kann, muss dieser innerhalb des Treibermanagers registriert sein. Um dies zu
erreichen, wird die JDBC-Treiberklasse uber den ClassLoader der Java Lauf-
zeitumgebung geladen. Die JDBC-Spezifikation verlangt, dass der Treiber sich
daraufhin selbst durch einen statischen Initialisierungsteil beim Treibermana-
ger registriert.
String driverName = "oracle.jdbc.OracleDriver"; // vollqualifizierterKlassenname
Class.forName(driverName); // Klasse laden und Registrierung initiieren
Schließlich kann basierend auf gultigen Verbindungsdaten eine Verbindung zum
Datenbanksystem uber den Treibermanager erfolgen, der bei Erfolg das Ver-
bindungsobjekt Connection zuruckliefert:
String host = "<host>"; // Name des Datenbankservers/IP-AdresseString port = "<port>"; // PortnummerString sid = "<sid>"; // Systemnummer
1Das Data Dictionary beschreibt den Zustand einer Datenbank, enthalt also die Metada-
ten.
53
6.3. Metadaten von Relationen
String url = "jdbc:oracle:thin:@" + host + ":" + port + ":" + sid
Connection conn = DriverManager.getConnection(url, "<user>", "<passwort>");
Listing 6.1: Connection-Objekt der JDBC-Verbindung
Eine weitere Moglichkeit, eine Datenbankverbindung aufzubauen bzw. ein
gultiges Connection-Objekt zu erhalten, besteht auch bei JDBC durch
Connection Pooling. Diese Technik der Wiederverwendung physischer Daten-
bankverbindungen wird auch von der JCo Middleware angeboten und wurde
dort bereits beschrieben (siehe Kapitel 5, Abschnitt 5.2).
6.3 Metadaten von Relationen
Basierend auf dem Connection-Verbindungsobjekt konnen Metainformatio-
nen uber die angeschlossene Datenbank abgefragt werden.
DatabaseMetaData dbmeta = conn.getMetaData();
Listing 6.2: DatabaseMetaData-Objekt der JDBC-Verbindung
Auf Grund der Vielzahl der zur Verfugung gestellten Metadaten wird an dieser
Stelle wiederum eine Auswahl derjenigen getroffen, die fur die Web Service
Generierung relevant sind:
• getTables(...)
Die Methode liefert eine Auflistung der in der Datenbank enthaltenen
Relationen (Tabellen) in Form eines ResultSet.
• getColumns(...)
Die Methode liefert eine Auflistung der in einer Tabelle enthaltenen At-
tribute (Tabellenspalten) in Form eines ResultSet. Von Interesse sind
hier insbesondere die Datentypen der Attribute. Analog zur JCo Middle-
ware existiert auch in der JDBC Spezifikation [11] ein Mapping auf Java
Datentypen wie in Tabelle 6.1.
• getPrimaryKeys(...)
Die Methode liefert eine Auflistung der Attribute einer Tabelle, die als
Primarschlussel dienen, in Form eines ResultSet.
• getExportedKeys(...)
Die Methode liefert eine Auflistung der Fremdschlussel-Attribute, die die
Primarschlussel-Attribute der gegebenen Tabelle referenzieren.
54
6.4. Ausfuhren von SQL-Anweisungen
JDBC Typ Java Typ
CHAR String
VARCHAR String
LONGVARCHAR String
NUMERIC java.math.BigDecimal
DECIMAL java.math.BigDecimal
BIT boolean
BOOLEAN boolean
TINYINT byte
SMALLINT short
INTEGER int
BIGINT long
REAL float
FLOAT double
DOUBLE double
BINARY byte[ ]
VARBINARY byte[ ]
LONGVARBINARY byte[ ]
DATE java.sql.Date
TIME java.sql.Time
TIMESTAMP java.sql.Timestamp
CLOB Clob
BLOB Blob
ARRAY Array
STRUCT Struct
REF Ref
Tabelle 6.1: Mapping von JDBC Datentypen und Java Datentypen
• getImportedKeys(...)
Die Methode liefert eine Auflistung der Primarschlussel-Attribute, auf
die sich die Fremdschlussel-Attribute der gegebenen Tabelle beziehen.
6.4 Ausfuhren von SQL-Anweisungen
Wenn eine Verbindung zur Datenbank hergestellt ist, konnen uber das
Connection-Objekt dieser Verbindung SQL-Anweisungen ausgefuhrt werden.
In diesem Zusammenhang muss zwischen der Ausfuhrung von”dynamischem
SQL“, basierend auf der Implementierung des Interface Statement, und”vor-
bereitetem SQL“ auf PreparedStatement-Objekten unterschieden werden.
Im Kontext dieser Arbeit werden SQL-Anweisungen uber prepared state-
ments generiert, so dass die Klasse Statement hier keine weitere Beachtung
findet. Die Methoden verhalten sich ahnlich, variieren lediglich leicht in ihrer
Signatur und konnen gegebenenfalls der API [11] entnommen werden.
55
6.4. Ausfuhren von SQL-Anweisungen
Anweisungen auf PreparedStatement-Objekten
Zunachst wird eine Instanz der Klasse PreparedStatement benotigt.
Connection conn;String sql;
PreparedStatement stmt = conn.prepareStatement(sql);stmt.setObject(i, o);
stmt.execute();
Listing 6.3: PreparedStatement Ausf”uhrung
Die Methode setObject(int i, Object o) setzt den Wert i-ten Para-
meter des prepared statement vor der Anweisungsausfuhrung. Dabei wird das
Objekt o implizit auf den nach Tabelle 6.1 entsprechenden JDBC Datentyp
gemappt.
Die Methode execute() auf dem PreparedStatement-Objekt fuhrt
die Anweisung aus.
Eine analoge Vorgehensweise ergibt sich fur die Ausfuhrung einer SQL-Abfrage
SELECT.
56
Kapitel 7
Anforderungen
Gemaß der Zielsetzung aus Einleitung 1.2 soll Generic Web Services dazu
dienen, Web Services in einem automatischen Generierungsprozess zu erstellen,
die auf den zuvor spezifizierten Daten eines beliebigen Datenhaltungssystems
operieren.
Generic Web Services hat nun die Aufgabe, diesen Generierungsprozess zu
implementieren. Dabei werden verschiedene Anforderungen gestellt. Einerseits
gelten diese Anforderungen bezuglich der Komponenten, die ein Web Service
grundsatzlich bieten muss. Ebenso wie die WSA (Web Service Architecture,
siehe Abschnitt 3.2) gibt auch das RPC-Protokoll Vorgaben was die Notwen-
digkeit von Softwarekomponenten betrifft (vgl. Abschnitt 2.2.1). Beispielsweise
ist hier an Schnittstellenbeschreibung oder Client/Server-Stub zu denken. So-
mit sind also die Typen der Komponenten der Web Services eindeutig definiert.
Andererseits beziehen sich die Anforderungen auf den Generierungspro-
zess, d. h. auf die spezifischen Auspragungen der jeweiligen Web Service Kom-
ponenten. Methodensignaturen als Schnittstelle mussen z. B. festgelegt werden
und letztlich naturlich auch die eigentliche Implementierung der Funktionalitat
dieser Methoden.
Die Tatsache, dass die Auspragung der Daten in dem Datenhaltungssystem
nicht vordefiniert ist und die Art der Operation auf den Daten unspezifisch
ist, muss Generic Web Services diese Informationen dynamisch sammeln und
darauf basierend den an den Web Service gestellten Anforderungen gerecht
werden.
Es gilt nun hauptsachlich, diese Anforderungen im Detail zu definieren,
um sie im Generierungsprozess umsetzen zu konnen.
7.1 Anforderungen an Web Services
Die Anforderungen an die Implementierung der Web Services kann unterteilt
werden bezuglich der serverseitigen und der clientseitigen Softwarekomponen-
ten.
57
7.1. Anforderungen an Web Services
Serverseitige Komponenten
Auf Serverseite erfolgt die eigentliche Ausfuhrung des Softwaredienstes,
der als Web Service im verteilten System angeboten wird. Hierzu sind die
folgenden Komponenten bereitzustellen:
• Web Service Implementierung
Die eigentliche Implementierung des Web Service muss eine eigenstandig
lauffahige Softwarekomponente sein, die eine spezifische Funktionalitat
bietet. Im Rahmen der Aufgabenstellung dieser Arbeit lasst sich diese
Funktionalitat generell beschreiben als
– Zugriff auf SAP R/3-Systeme
Die Softwarekomponente greift auf ein SAP R/3-System zu, um
R/3-Anwendungen auf konkreten Daten auszufuhren.
– Zugriff auf relationale Datenbanksysteme
Die Softwarekomponente greift auf eine Datenbank zu, um eine Da-
tenselektion konkreter Datenbankinhalte zu realisieren oder die Da-
tenmanipulation in definierter Form durchzufuhren.
• Web Service Schnittstelle (Interface)
Damit die Softwarekomponente als Web Service zugreifbar ist, muss eine
Schnittstelle nach außen gegeben sein.
• Web Service Beschreibung (WSDL)
Um im Sinne der Web Service Architektur den Aufruf des implementier-
ten Dienstes zu ermoglichen, muss eine Beschreibung seiner Schnittstel-
le in Form der WSDL verfugbar sein. Die WSDL-Beschreibung sichert
damit das Lokalisieren des Web Service im verteilten System einerseits
und die vollstandige Spezifizierung seiner Schnittstelle bezuglich Ein- und
Ausgabeparametern, Datentypen der Ubergabe- und Ruckgabewerte und
Signatur der Schnittstellenmethode andererseits.
• RPC-Skeleton
Zur Realisierung einer RPC-basierten Kommunikation mit dem Web Ser-
vice muss auf Serverseite ein RPC-Skeleton-Objekt zur Verfugung stehen,
das den Web Service lokal anspricht.
Clientseitige Komponenten
Der Web Service Client ist lediglich fur den Aufruf von Interesse. Zu-
sammen mit der Vorderung nach einer RPC-Kommunikation ergeben sich im
Einzelnen:
58
7.2. Anforderungen an Generic Web Services
• Web Service Client
Um den Web Service aufrufen zu konnen, muss eine Clientkomponente
implementiert sein.
• Web Service Invocation Framework (WSIF)
Der Web Service Client bietet in der Regel keine graphische Oberflache
an, von der aus der Nutzer des Dienstes den Aufruf absetzen kann.
Gewohnlich erfolgt die Integration des Dienstes auf Programmierebe-
ne, um die Funktionalitat fur weitere Implementierungen verwenden zu
konnen. An dieser Stelle besteht nun aber die Anforderung, ein Frontend
(GUI) zur Verfugung zu stellen, das die Eingabe der dienstspezifischen
Parameter erlaubt und gleichzeitig die Ruckgabewerte des Web Service
dem Benutzer visualisiert. Dies ist im Rahmen der vorliegenden Arbeit
nur teilweise moglich: Je nach Datentyp der Ubergabeparameter ist eine
Tastatureingabe nicht moglich. Beispielsweise kann es sich um ein Objekt
der Klasse java.lang.Byte[] handeln, das nicht textuell als String
eingetippt werden kann.
• RPC-Stub
Letztlich fordert auch die Clientseite zur Kommunikation uber RPC ein
lokales”Stellvertreterobjekt“ der Web Service Schnittstelle.
7.2 Anforderungen an Generic Web Services
Prinzipiell lassen sich die an die Applikation Generic Web Services zu stellen-
den Anforderungen analog zu Abschnitt 7.1 in client- und serverseitige trennen.
Da hier jedoch die Benutzerinteraktion eine wichtige Rolle spielt, soll im Fol-
genden in Anlehnung an das Ebenen- und Schichtenmodell (siehe Abschnitt
1) von Anforderungen an die Prasentations- und Applikationskomponente ge-
sprochen werden.
Prasentationskomponente
Die Prasentationskomponente ist dafur verantwortlich, samtliche generischen
Informationen im Rahmen der Web Service Generierung mit dem Anwender
abzustimmen. Im Einzelnen definieren sich diese benutzerspezifischen Daten
wie folgt:
• Datenbank-Adapter
Der Benutzer muss als Grundlage fur den Zugriff auf ein Datenhaltungs-
system (SAP R/3 oder relationales Datenbanksystem) die gewunschte
Datenbank-Adapterklasse auswahlen.
59
7.2. Anforderungen an Generic Web Services
• Verbindungsdaten
Auf Basis der ausgewahlten Adapterklasse mussen die entsprechenden
Verbindungsdaten der Applikation Generic Web Services mitgeteilt wer-
den.
• Metadaten
Die Darstellung der prasentierten Metadaten, die Generic Web Services
uber die Verbindung aus der Datenquelle extrahiert hat, erfordert vom
Anwender die Auswahl, welche dieser Metadaten als Datentypen fur die
Ubergabeparameter der Web Service Methode dienen sollen.
• package-Deklaration
Die zu generierenden Dateien werden in das benutzerdefinierte package-
Verzeichnis erstellt und Java Klassen mit entsprechender package-
Deklaration im Generierungsprozess compiliert.
• Web Service Name
Der Name des erzeugten Web Service ist benutzerdefiniert.
• Web Service Endpoint
Der Web Service Endpoint definiert in WSDL die Adresse, unter der der
generierte Web Service aufgerufen werden kann.
• Web Service Methoden
Der Benutzer muss auf Grundlage der ausgewahlten Metadaten die
Schnittstellenmethoden des Web Service definieren. Der Methodenna-
me muss ubergeben werden, ebenso wie Datentypen der Ruckgabe- und
Ubergabeparameter der Methode. Der Anwender muss selbst definieren
konnen, wieviele Methoden mit welchen Signaturen generiert werden.
Zusatzlich muss bei der Verwendung von nicht-SAP Adapterklassen defi-
niert werden konnen, welche Datenmanipulation die Web Service Imple-
mentierung auf den Daten ausfuhrt.
• Zusatzliche benutzerspezifischen Informationen
– RPC-Skeleton
Der Benutzer legt fest, ob eine RPC-Skeleton-Klasse generiert wird
oder nicht.
– Web Service Deployment Descriptor (WSDD)
Der Benutzer legt fest, ob eine WSDD-Datei fur das Deployment
und/oder das Undeployment des Web Service generiert werden soll.
– SOAP-Logger
Der Benutzer kann optional die Generierung eines SOAP-Loggers
60
7.2. Anforderungen an Generic Web Services
veranlassen. Dieser dokumentiert bei Aufruf des Web Service die
gesendeten und empfangenen SOAP Nachrichten.
– Web Service Invocation Framework (WSIF)
Die Verfugbarkeit des WSIF stellt zwar einserseits eine Anforderung
an den Web Service Client dar, andererseits ist es dem Benutzer
uberlassen, davon Gebrauch zu machen.
• Download
Letztlich muss der Anwender die von Generic Web Services generierten
Dateien auf seinen lokalen Rechner downloaden konnen.
Applikationskomponente
Die Anforderungen an die Applikationskomponente von Generic Web
Services sind in vier Punkten zu nennen:
• Datenbank-Adapter
Generic Web Services muss dynamisch bei Programmstart nach vorhan-
denen Datenbank-Adapterklassen suchen und somit dem Benutzer die
Auswahl ermoglichen.
• Datenhaltung
Generic Web Services muss uber Datenstrukturen verfugen, die es er-
lauben, die obigen Benutzerdaten wahrend der gesamten Zeit der Benut-
zerinteraktion zu sammeln, damit sie bei Start des Generierungsprozesses
verfugbar sind.
• Generierungsprozess
Generic Web Services generiert in eigenstandigem Ablauf alle notwen-
digen und eventuell optional vom Benutzer gewunschten Web Service
Komponenten.
• Web Service (Un-)Deployment
Die Applikation muss die Moglichkeit bieten, ein automatisches Deployen
der erzeugten Web Services durchzufuhren.
61
Kapitel 8
Entwurf von Generic Web
Services
Die technische Umsetzung der im vorherigen Kapitel beschriebenen Anforde-
rungen, d. h. die Implementierung von Generic Web Services erfordert einer-
seits die Wahl einer geeigneten Technologie, die es erlaubt, uber eine graphi-
sche Oberflache die Benutzerinteraktion zu ermoglichen und andererseits einige
Softwarekomponenten, die den eigentlichen Web Service Generierungsprozess
unterstutzen. Dies fuhrt zunachst zu Abschnitt 8.1.
8.1 Vorbetrachtungen
Wahl der Technologie
Dass bei der Wahl einer Technologie zur Realisierung von Generic Web
Services lediglich Java Konzepte in Betracht kommen, liegt auf der Hand.
Die Tatsache, dass es bei der praktischen Nutzung von Generic Web Services
nicht zwingend gegeben sein muss, dass der Rechner, der die Anwendung
ausfuhrt und den Web Service generiert auch gleichzeitig der Rechner ist,
auf dem dieser Dienst dann in einer SOAP Engine verfugbar ist, legt nahe,
die Benutzerfuhrung uber dynamisch erzeugte HTML-Seiten umzusetzen. Die
Wahl fiel letztlich auf die Java Servlet-Technologie.
Zudem bietet der Einsatz von Servlets programmiertechnische Vorteile. Ein
einzelner Generierungsworkflow wird an ein HttpSession-Objekt gebunden,
so dass temporar benotigte Daten uber die Benutzer-Session gespeichert wer-
den konnen.
Art der Benutzerfuhrung
Um dem Anwender eine klare und moglichst intuitiv verstandliche Vor-
gehensweise fur die Generierung von Web Services zu bieten, bietet es sich
62
8.2. Servlet-basierter Aufbau
an, eine Art”Wizard“ zu realisieren, d. h. die Moglichkeit einer schrittweisen
Durchfuhrung samtlicher erforderlichen Eingaben und Konfigurationen zu
ermoglichen.
8.2 Servlet-basierter Aufbau
Im Ganzen umfasst Generic Web Services die Realisierung einer Architektur
mit vier Java Servlets, die von einem statischen HTML-Framework aus aufge-
rufen werden. Im Einzelnen handelt es sich um:
• GenerateWebServicesServlet : Das Servlet beinhaltet den eigentli-
chen Generierungsprozess der Web Services.
• DeployWebServicesServlet : Das Servlet deployed einen Web Service,
der als jar-Datei vorliegt in einer per URL definierten Axis Umgebung.
• ShowWebServicesServlet : Das Servlet greift auf eine beliebige Axis
Installation zu und liest die darin deployten Web Services aus.
• RegisterWebServicesServlet : Das Servlet deutet die Web Service
Komponente UDDI an. Da eine UDDI Anbindung nicht im Rahmen der
Arbeit zu betrachten ist, leistet das Servlet keine Funktionalitat. Dennoch
ist das Grundgerust vorhanden.
Jedes dieser Servlets implementiert das Interface-Servlet IServlet, wel-
ches Zugriffsmethoden auf die jeweils zugehorigen IServletRequest- und
IServletResponse-Implementierungen bietet.
63
Kapitel 9
Implementierung
9.1 Datenbank-Adapter
Eine wichtige Komponente von Generic Web Services stellt der Datenbank-
Adapter dar.
Es besteht die Anforderung, eine weitestgehend modulare und auf Interfa-
ces basierende Programmstruktur zu schaffen, so dass zukunftig die Moglichkeit
gegeben ist, auf einfache Weise weitere Datenhaltungssysteme zu integrieren.
Ein Datenbank-Adapter beruht auf einer Implementierung des Interface
IConnect, das folgende Methoden bietet:
• setConnectData(Properties p) : setzt die Verbindungsdaten des
Properties-Objektes in eine Instanz von ConnectData.
• getConnectData() : liefert die ConnectData-Instanz.
• open() : offnet eine Datenbank-Verbindung und gibt das Verbindungs-
objekt als Object zuruck.
• close() : schließt die Verbindung zur Datenbank.
• getMetadataImplClass() : gibt die Klasse zuruck, die die Metadaten
der Datenquelle ausliest.
• hasQueryTypes() : spezifiziert, ob die angeschlossene Datenbank
SELECT-, UPDATE-, INSERT- und DELETE-Anfragen unterstutzt.
Dabei sorgt die Klasse ConnectData fur die Speicherung der relevanten
Verbindungsdaten.
Die vorliegende Version von Generic Web Services beinhaltet bereits drei
Implementierungen einer Adapterklassen, zur Anbindung von SAP R/3, MyS-
QL und ORACLE. Die Beziehung der Klassen untereinander zeigt die folgende
Abbildung 9.1 in UML-Notation:
64
9.2. Generierungsprozess
Abbildung 9.1: Schnittstellen der Datenbank-Adapterklassen
9.2 Generierungsprozess
Die Generierung der Web Service Komponenten erfolgt mit Unterstutzung der
SOAP Implementierung Axis der Apache Software Foundation. Dieses Paket
liefert neben einer Java SOAP Engine verschiedene andere Werkzeuge und
Klassen, die das automatische Erzeugen von Web Service Komponenten er-
laubt.
Bekannte Vertreter sind sicherlich Java2WSDL und WSDL2Java. Aller-
dings erfullten die von diesen Klassen generierten Web Service Geruste in vie-
len Details nicht die Anforderungen. Beispielsweise hat eine Manipulation der
Web Service Methodenparameternamen in keinster Weise Einfluß auf die Be-
zeichnung der Parameter innerhalb der WSDL. Da die WSDL allerdings die
65
9.3. Web Service Invocation Framework (WSIF)
korrekte Methodensignatur beschreiben soll, konnte alleine aus diesem Grund
nicht auf Java2WSDL zuruckgegriffen werden.
9.3 Web Service Invocation Framework (WSIF)
Das WSIF implementiert den Web Service Client. Der Begriff”Framework“
heisst in diesem Zusammenhang, dass ein HTML-Frontend den Aufruf des
Web Service Client ubernimmt.
66
Kapitel 10
Einsatzbeispiel
Um das Generic Web Services Frontend im praktischen Einsatz vorzustellen,
wird es in diesem Kapitel darum gehen, fur den bereits bekannten Funktions-
baustein BAPI COMPANY GETLIST die notwendigen Schritte von der Gene-
rierung des Web Service, uber das Deployen bis hin zum Aufruf darzustellen.
Gegebenenfalls konnen die Parameter des RFM in Kapitel 4, Abschnitt 4.5.5
uber die Dialog-Abbildungen des SAP Systems in Erinnerung gerufen werden.
Es werden die wichtigsten GUI-Elemente und Funktionalitaten am Beispiel
erlautert. Die nicht explizit erwahnten sind dagegen intuitiv verstandlich.
10.1 Generierung
Zunachst wird der Web Service generiert, der den Aufruf von
BAPI COMPANY GETLIST uber JCo implementiert.
67
10.1. Generierung
Auswahl der Datenbank-Adapterklasse
Generic Web Services stellt beim Aufruf alle verfugbaren Adapterklassen
zur Auswahl wie in Abbildung 10.1 zu sehen ist.
Abbildung 10.1: Dialog: Auswahl der Datenbank-Adapterklasse
68
10.1. Generierung
Eingabe der Verbindungsdaten
Mit der Wahl der Adapterklasse werden entsprechend ihrer Implementierung
Verbindungsdaten benotigt. Dazu gehort auch – wie im Falle eines SAP
R/3-Systems – der Name des zu nutzenden Funktionsbausteins. Abbildung
10.2 stellt die zugehorige Oberflache dar.
Abbildung 10.2: Dialog: Pflege der Verbindungsdaten
69
10.1. Generierung
Auswahl der Metadaten
Nach erfolgreicher Anmeldung an dem System werden die Metadaten des
Funktionsbausteins ausgelesen und gemaß der Abbildung 10.3 dargestellt.
Abbildung 10.3: Dialog: Auswahl der Metadaten
Der Tabellenkopf (rote Markierung) definiert die ausgelesenen RFM
Parameter-Metadaten:
• Structure : stellt alle Parameter als Baumstruktur dar. Ein top-level
Knoten des Baumes reprasentiert einen Parameter mit seinem Namen,
unabhangig von seinem Datentyp. Ist dieser Parameter vom ABAP Dic-
tionary Datentyp Struktur oder Tabelle, besitzt er Kindelemente,
namlich seine Felder, die ebenfalls uber ihre Namen dargestellt sind. Die
Namen sind editierbar, da sie letztlich die Signatur der Web Service Me-
thode mitbestimmen und somit in den Schnittstellenbeschreibungen wie-
derzufinden sind.
• Parameter/Return : kennzeichnet den Parameter als Ubergabe-
oder Ruckgabeparameter. Im Falle eines Tabellenparametertyps
(COMPANY LIST) ist beides moglich. Die Eigenschaft wird auf die Kind-
knoten vererbt.
• Type : bezeichnet den ABAP Dictionary Datentyp des Parameter.
• Parameter/Return Array Type : definiert den zugehorigen Type als
Array Typ, d. h. wird der Parameter als Ubergabeparameter verwendet,
70
10.1. Generierung
ist ein Array dieser Objekte zu ubergeben. Analog dazu wird ein Array-
Objekt von der Methode zuruckgeliefert, wenn die entsprechende Konfi-
guration vorgenommen wurde. Die Eigenschaft ist nicht auf die Kindele-
mente ubertragbar.
Wurden alle fur die Methode gewunschten Parameter ausgewahlt und konfigu-
riert, geht es im nachsten Schritt um die Konfiguration des Web Service.
71
10.1. Generierung
Generelle Eigenschaften
Zu den grundlegenden Konfigurationen des Web Service gehoren sein Name,
die Spezifizierung des Endpoint, also die URL unter der der Dienst erreichbar
ist.
72
10.1. Generierung
Spezielle Funktionalitaten
Hier kann auf verschiedene Arten in den Generierungsprozess eingegriffen wer-
den. So kann beispielsweise die Erzeugung der Stub-Objekte unterbunden wer-
den. Andererseits kann explizit verlangt werden, Web Service Deployment Des-
criptoren oder einen Logging-Mechanismus der SOAP Nachrichten zu erzeugen.
Der WSIF kann ebenfalls optional zu- oder abgeschaltet werden.
73
10.1. Generierung
Web Service Methoden
Auf Basis der Metadaten werden hier die Methodensignaturen der Web Services
benutzerabhangig definiert. Es konnen beliebig viele Methoden mit beliebigen
Parametern (abhangig von der vorherigen Auswahl) definiert werden.
74
10.1. Generierung
Download
Der generierten Klassen und Dateien werden hier – in zwei Packages verpackt
– auf den Client (evtl. zum Deployen) gedownloaded. Zum einen ist dies die
Serverseite des Web Service, zum anderen der Client mit dem servletbasierten
WSIF.
75
10.2. Deployment
10.2 Deployment
Hier kann ein bestimmter Web Service als jar-Paket upgeloaded und als Web
Service in Axis deployed werden.
76
Anhang A
ABAP Dictionary Datentypen
Die Tabelle A beschreibt die Konvertierung von elementaren ABAP Dictionary
Datentypen in elementare ABAP Datentypen. Dabei bezeichnet n die Zahl der
Stellen und m die Zahl der Nachkommastellen des Feldes im ABAP Dictionary.
Die elementaren ABAP Datentypen konnen Tabelle 5.1 entnommen werden.
ABAP Dictionary Typ Beschreibung ABAP Typ
ACCP Buchungsperiode im Format JJJJ.MM N(6)
CHAR n String der Lange n C(n)
CLNT Mandant C(3)
CUKY Wahrungsschlussel C(5)
CURR n,m Wahrungsfeld P((n+1)/2) DECIMAL m
DATS Datum D(8)
DEC n,m Rechen- oder Betragsfeld P((n+1)/2) DECIMAL m
FLTP Fließkommazahl F(8)
INT1 1-Byte-Integer, X(1)
Zahlbereich 0 bis 255
INT2 2-Byte-Integer, X(2)
Zahlbereich -32767 bis 32767
INT4 4-Byte-Integer, X(4)
Zahlbereich -2177483647 bis 2177483647
LANG Sprachenschlussel C(1)
LCHR n Zeichenkette beliebiger Lange n, C(n)
mindestens 256 Zeichen
LRAW n Bytefolge beliebiger Lange n, X(n)
mindestens 256 Bytes
NUMC n Ziffernfolge der Lange n N(n)
PREC Genauigkeit eines QUAN Feldes X(2)
QUAN n,m Menge, entspricht DEC P((n+1)/2) DECIMAL m
RAW n Byte-Folge der Lange n X(n)
RAWSTRING Byte-Folge variabler Lange XSTRING
STRING Zeichenkette variabler Lange STRING
78
TIMS Zeit im Format HH.MM.SS T(6)
UNIT n Einheitenschlussel C(n)
VARC n Zeichenkette variabler Lange C(N)
Tabelle A.1: Mapping von ABAP Dictionary Datentypen und ABAP
Datentypen
79
Anhang B
CD-ROM
Die beiliegende CD-ROM enthalt alle erforderlichen Softwarekomponenten zur
Ausfuhrung von Generic Web Services, d. h. zur Generierung von Java Web
Services und deren Bereitstellung (Deployment) unter Microsoft Windows, so-
wie zur Weiterentwicklung der Projektimplementierung. Im Einzelnen sind ent-
halten:
• Im Hauptverzeichnis gibt die HTML-Datei index.htm diese Ubersicht
uber den Inhalt der CD-ROM. Das Dokument installation.pdf
enthalt die Installationsanleitung zu Generic Web Services aus Anhang
C.
• \apps Das Verzeichnis beinhaltet Installationsroutinen bzw. Projektver-
zeichnisse der Open Source Anwendungen im zip-Format, die die We-
bapplikation Generic Web Services benotigt:
– axis-1 1-src.zip
Die SOAP-Implementierung Axis der Apache Software Foundation
einschließlich des Java-Quellcodes.
– commons-fileupload-1.0.zip
Ein Package aus dem Jakarta Commons Projekt der Apache Softwa-
re Foundation. Es bietet eine API zur Realisierung von File-Uploads
fur Webapplikationen.
– j2sdk-1 4 2 03-windows-i586-p.exe
Das Java 2 Software Development Kit (JDK) der Sun Microsystems,
Inc. in der Standard Edition Version.
– jakarta-tomcat-5.0.16.zip
Der Web Application Server Tomcat der Apache Software Founda-
tion.
– xalan-j 2 6 0-bin.zip
80
Die Apache XSLT-Implementierung zur Transformation von XML-
Dokumenten in andere (XML-)Dokumente in Java.
– xerces-j-bin.2.6.2.zip
Die Apache Implementierung eines XML-Parsers in Java.
Zusatzlich sind die Pakete juddi-0.9rc3.zip,
ruddi-1.0-bin-max.zip und uddi4j-bin-2 0 2.zip ent-
halten, die Open Source Java-APIs zum Zugriff auf (offentliche)
UDDI-Registrierungen bieten.
• \doc Hier liegt die API-Dokumentation zu Generic Web Services im
HTML-Format.
• \installed Das enthaltene jakarta-tomcat-5.0.16 -Verzeichnis reprasen-
tiert eine Tomcat-Installation mit integrierten Axis- und Generic Web
Services-Applikationen und allen erforderlichen jar-Dateien.
• \jdbc jco Die in der vorliegenden Version von Generic Web Ser-
vices implementierten Adapter zur Anbindung externer Datenquel-
len erfordern die in diesem Verzeichnis vorhandenen Middleware-
Implementierungsklassen1.
• \source Das Verzeichnis enthalt die Java-Quellcodedateien zu Generic
Web Services.
1Die vorhandene Installation der Datenquellen, die uber diese Klassen angesprochen wer-
den, wird vorausgesetzt.
81
Anhang C
Installationsanleitung
C.1 Installation der Komponenten
Als Webapplikation auf Basis der Java Servlet-Technologie setzt die
Ausfuhrung der Projektimplementierung Generic Web Services die Installation
einiger Softwarekomponenten voraus. In erster Linie sind ein Web Application
Server bzw. Servlet-Container sowie ein Java Development Kit erforderlich. Die
Installationsanleitung beschreibt die Bereitstellung aller notwendigen, bereits
wahrend der Entwicklungsphase verwendeten Open Source Produkte sowie die
Installation und den Aufruf von Generic Web Services und deren Kompo-
nentenanwendungen unter Microsoft Windows. Diese Produkte liegen in den
jeweils getesteten Versionen auf der CD-ROM vor. Bei Einsatz variierender
Produkt-Versionen kann der Installationsverlauf abweichen. Die Verwendung
anderer, gleichartiger, frei verfugbarer oder auch kommerzieller Produkte wird
hier nicht betrachtet1.
Java 2 SDK 1.4.2 03
Die Implementierung von Generic Web Services erfolgte auf Basis des
Java 2 SDK Version 1.4.2 03. Eine weiterfuhrende Entwicklung setzt somit
diese oder eine unter http://java.sun.com frei erhaltliche aktualisierte
Version voraus.
Auch die Ausfuhrung von Generic Web Services bzw. deren Komponenten-
applikationen macht die Installation des Java 2 SDK zwingend notwendig.
Die im nachsten Abschnitt beschriebene Installation des Applikationsservers
erfordert zudem die Definition einer Umgebungsvariablen unter Windows:
1Denkbar ist beispielsweise der Einsatz eines JBoss Application Server oder IBM Web-
Sphere als Alternativen zu dem verwendeten Tomcat Web Application Server der Apache
Software Foundation.
82
C.1. Installation der Komponenten
JAVA HOME
mit Wert
%J2SDK PATH%.
Apache Tomcat 5.0.16
Die in \apps vorliegende Version des Applikationsservers Tomcat erfordert
lediglich ein Entpacken der zip-Datei in ein beliebiges Verzeichnis, nachfol-
gend mit %TOMCAT HOME% bezeichnet. Die Dateien startup.bat und
shutdown.bat in %TOMCAT HOME%\bin ubernehmen den Start- bzw.
Stoppvorgang des Tomcat-Servers.
Optional kann auch das Verzeichnis jakarta-tomcat-5.0.16 aus \installed
kopiert werden. %TOMCAT HOME% ergibt sich entsprechend.
Sollte der Tomcat Standard-Port %TOMCAT PORT% 8080 in Konflikt
stehen mit bestehenden Installationen (beispielsweise einer ORACLE
Datenbank, deren Standard-Installationsroutine der Version 9i einen
HTTP-Server auf Port 8080 installiert), kann dieser uber der Datei %TOM-
CAT HOME%\conf\server.xml umkonfiguriert werden.
Im Hinblick auf die Axis-Installation muss darauf geachtet werden, dass unter
%TOMCAT HOME%\common\lib die Java-Library activation.jar vor-
handen ist. Einigen Tomcat-Versionen liegt diese (und andere hier allerdings
nicht benotigte) standardmaßig nicht bei.
In jedem Fall verlangt Tomcat die Umgebungsvariable %JAVA HOME%.
Apache Axis 1.1
Das Paket axis-1 1.zip enthalt nach Entpacken unter
%AXIS HOME%\webapps das Verzeichnis axis. Dieses wird als Webapplikati-
on in die bestehende Tomcat-Installation nach %TOMCAT HOME%\webapps
kopiert.
Wurde die Tomcat-Installation aus \installed verwendet, ist Axis bereits
enthalten.
Zusatzlich mussen folgende Klassenpfade (%CLASSPATH% -Variable) als
Umgebungsvariable in Windows gesetzt werden:
• %AXIS HOME%\lib\axis.jar
• %AXIS HOME%\lib\axis-ant.jar
• %AXIS HOME%\lib\commons-discovery.jar
• %AXIS HOME%\lib\commons-logging.jar
• %AXIS HOME%\lib\jaxrpc.jar
83
C.2. Installation von Generic Web Services
• %AXIS HOME%\lib\log4j-1.2.8.jar
• %AXIS HOME%\lib\saaj.jar
• %AXIS HOME%\lib\wsdl4j.jar
• %PATH%\xercesImpl.jar2
(in xerces-j-bin.2.6.2.zip)
• %PATH%\xmlParserAPIs.jar2
(in xalan-j 2 6 0-bin.zip oder xerces-j-bin.2.6.2.zip)
Es ist darauf zu achten, eine Tomcat-Version 4.1.x oder hoher zu verwenden.
Andere Servlet-Container konnen eingesetzt werden, wenn sie mindestens Ver-
sion 2.2 der Servlet-API implementieren.
Zur Generierung von Web Services, d. h. zur Ausfuhrung der entsprechenden
Komponentenapplikation von Generic Web Services, ist die Installation von
Axis allerdings nicht zwingend erforderlich, da die hierzu benotigten Axis-
Bibliotheken innerhalb der Projektstruktur von Generic Web Services bereit-
gestellt sind.
C.2 Installation von Generic Web Services
Die unter \installed gelieferte Tomcat-Installation enthalt unter webapps die
Applikation Generic Web Services in gleichnamigem Verzeichnis. Alle erfor-
derlichen jar- und class-Dateien sind innerhalb der ublichen Verzeichnis-
struktur fur Webapplikationen abgelegt:
Abbildung C.1: Verzeichnisstruktur von Generic Web Services
Daruber hinaus sind unter images und scripts Graphiken und Skripte hin-
terlegt, die von HTML-Seiten referenziert werden. Das in WEB-INF\scripts
liegende XSL-Stylesheet wird von der Java-Applikation zur Generierungslauf-
zeit eingelesen. Die Verzeichnishierarchien sind somit beizubehalten.
Das Deployen der Webapplikation in einer bestehenden Tomcat-Umgebung er-
folgt durch Kopieren der Ordnerstruktur GenericWebServices in das entspre-
chende webapps-Verzeichnis.
2%PATH% bezeichnet den absoluten Dateisystempfad.
84
C.3. Aufruf
C.3 Aufruf
Es sei %TOMCAT HOST% die IP-Adresse des Rechners mit aktueller Tomcat-
Installation. Dann ist unter der URL
http://%TOMCAT HOST%:%TOMCAT PORT%/GenericWebServices
ein HTML-Framework zum Aufruf der einzelnen Servlets von Ge-
neric Web Services verfugbar. Sollen diese direkt aufgerufen werden
(beispielsweise aus einer anderen Webapplikation heraus), wird obi-
ge URL durch den zugehorigen Inhalt des Elementes <url-pattern>
in %TOMCAT HOME%\webapps\GenericWebServices\WEB-INF\web.xml
erganzt, standardmaßig konfiguriert mit
• /servlet/GenerateWebServicesServlet,
• /servlet/DeployWebServicesServlet,
• /servlet/ShowWebServicesServlet,
• /servlet/RegisterWebServicesServlet.
Zusatzlich muss dann die Ausgabe der Konsolenmitteilungen im vordefinierten
HTML-Frame unterbunden oder angepasst werden. Hierzu ist in genannter
XML-Datei web.xml (Web Application Deployment Descriptor) der unter
Listing C.1 dargestellte Bereich auszukommentieren bzw. zu modifizieren.
<context-param><param-name>HTML_CONSOLE_FRAME</param-name><param-value>top.frames[1]</param-value><description>Specifies the HTML frame name for output messages
</description></context-param>
Listing C.1: web.xml von Generic Web Services
Der Elementinhalt von <param-value> spezifiziert das HTML-Frame-Objekt
top.frames[1]. Soll die Ausgabe von Informationen zum Generierungspro-
zess zur Laufzeit verhindert werden, ist das Elternelement <context-param>
zu entfernen.
Hinweis zum verwendeten Browser: Sowohl die statisch abgelegten als
auch die serverseitig dynamisch erzeugten Webseiten enthalten neben reinem
HTML-Code auch clientseitig auszufuhrendes Javascript zur Darstellung sowie
zur Realisierung von Benutzereingaben. Erstellt und getestet wurden Design
und korrekte Funktionalitat der Seiten mit dem Microsoft Internet Explorer ab
Version 5.5. Altere Produktversionen oder Browser anderer Hersteller wurden
nicht berucksichtigt.
85
C.4. Installation von Datenquellen-Middleware
C.4 Installation von Datenquellen-Middleware
Voraussetzung fur die Nutzung von integrierten Datenquellen-Adapterklassen
in Generic Web Services (siehe C.5) ist die Verfugbarkeit der datenserverspe-
zifischen Middleware. Diese ist fur alle gangigen Datenbanksysteme (und auch
fur das SAP R/3-System) als jar-Archiv erhaltlich.
SAP Java Connector (JCo)
Das Paket jco-ntintel-1.1.03.zip beinhaltet die verwendet Versi-
on 1.1.03 des Java Connectors fur SAP. Die relevante Windows-Library
librfc32.dll ist in das System32 -Verzeichnis der vorliegenden Windows-
Installation zu kopieren.
Das Archiv jCO.jar stellt die fur Java erforderliche Klas-
senbibliothek. Sie ist Generic Web Services unter %TOM-
CAT HOME%\webapps\GenericWebServices\WEB-INF\lib zur Verfugung
zu stellen3.
Fur zukunftige Entwicklungen liegt JCo zusatzlich in der neueren Version 2.0.5
auf der CD-ROM vor. Die Installation erfolgt analog. Lediglich die Klassenbi-
bliothek tragt hier den Namen sapjco.jar.
JDBC-kompatible Konnektoren
Implementierungen der JDBC API fur relationale Datenbanksysteme
sind analog zur Bereitstellung des SAP JCo in dem lib-Verzeichnis der
Projektstruktur von Generic Web Services als jar-Archiv zu hinterlegen3.
Gemaß den bereits integrierten Adapterklassen (vgl.
C.5) sind die zugehorigen JDBC-Implementierungen
mysql-connector-java-3.0.10-stable-bin.jar und ojdbc14.jar
sowie JCo mit jCO.jar in Generic Web Services vorinstalliert.
C.5 Integration von Datenquellen-Adaptern
Die vorliegende Version von Generic Web Services beinhaltet Java-
Adapterklassen fur die Anbindung einer MySQL- und ORACLE-Datenbank
sowie eines SAP R/3-Systems. Um andere JDBC-kompatible Datenquellen zu
nutzen, mussen entsprechende Adapterklassen implementiert und eingebunden
werden.
Die Erstellung einer Adapterklasse basiert auf dem Java-Interface
de.tsystem.diplom.connect.IConnect, welches implementiert werden
muss. Sie erfasst die erforderlichen Verbindungsdaten und -charakteristika und
3Das Einbinden von Klassenbibliotheken als jar erfordert den Neustart des Tomcat-
Servers.
86
C.5. Integration von Datenquellen-Adaptern
stellt diese dem Generierungsprozess bereit. Informationen uber die Signatur
der Interface-Methoden liefert die in \doc verfugbare API-Dokumentation.
Die Integration einer Implementierungsklasse in Generic Web Services erfolgt
durch Kopieren in das Verzeichnis WEB-INF\classes. Es ist darauf zu achten,
eine dem Package der Adapterklasse entsprechende Verzeichnisstruktur zu
verwenden, die ggf. angelegt werden muss. Zusatzlich erforderliche JDBC-
Treiberklassen sind als jar-Archiv unter WEB-INF\lib abzulegen (siehe C.4).
Die Webapplikation Generic Web Services identifiziert im Rahmen eines
Generierungsprozesses eines Web Services die eingebundenen Implementie-
rungsklassen innerhalb ihres Klassenpfades zur Laufzeit und ermoglicht uber
einen Auswahldialog die Verwendung der Adapter.
87
Abbildungsverzeichnis
1.1 Die drei Ebenen einer Anwendung . . . . . . . . . . . . . . . . 3
1.2 4-Tier-Architektur eines webbasierten Systems . . . . . . . . . 5
1.3 Webbasiertes System mit verteilter Applikationslogik . . . . . . 5
1.4 Webbasiertes System mit Web Services zur verteilten Datenser-
veranbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 RPC mit Stub und Skeleton . . . . . . . . . . . . . . . . . . . . 11
2.2 Service-oriented architecture (SOA) . . . . . . . . . . . . . . . 13
3.1 Web Services architecture (WSA) . . . . . . . . . . . . . . . . . 16
4.1 Schichten eines SAP Business-Objektes . . . . . . . . . . . . . . 29
4.2 ABAP Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Zugriff auf BAPIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 SAP Function Builder . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Importparameter BAPI COMPANY GETLIST . . . . . . . . . . . 38
4.6 Exportparameter BAPI COMPANY GETLIST . . . . . . . . . . . 39
4.7 Tabellenparameter BAPI COMPANY GETLIST . . . . . . . . . . 39
4.8 Struktur des Tabellenparameter BAPI COMPANY GETLIST . . 39
4.9 Ausgabe BAPI COMPANY GETLIST . . . . . . . . . . . . . . . . 40
4.10 ALE Integrationsszenario . . . . . . . . . . . . . . . . . . . . . 41
5.1 SAP Java Connector Architektur . . . . . . . . . . . . . . . . . 43
6.1 JDBC Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.1 Schnittstellen der Datenbank-Adapterklassen . . . . . . . . . . 65
10.1 Dialog: Auswahl der Datenbank-Adapterklasse . . . . . . . . . 68
10.2 Dialog: Pflege der Verbindungsdaten . . . . . . . . . . . . . . . 69
10.3 Dialog: Auswahl der Metadaten . . . . . . . . . . . . . . . . . . 70
C.1 Verzeichnisstruktur von Generic Web Services . . . . . . . . . 84
88
Tabellenverzeichnis
2.1 Beispiele fur SOA Formate und Protokolle . . . . . . . . . . . . 14
4.1 Beispiele fur SAP Business-Komponenten und ihre Objekte . . 27
5.1 Mapping von ABAP Datentypen und Java Datentypen . . . . . 48
5.2 Java Datentypen und JCo Zugriffsmethoden . . . . . . . . . . . 48
6.1 Mapping von JDBC Datentypen und Java Datentypen . . . . . 55
A.1 Mapping von ABAP Dictionary Datentypen und ABAP Daten-
typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
89
Literaturverzeichnis
[1] CHAPPELL, David A.; Jewell, Tyler: Java Web Services. O’Reilly, 2002.
[2] GISOLFI, Dan: Web services architect, Part 3: Is Web services the rein-
carnation of CORBA? developerWorks, IBMs resource for developers,
2001.
URL: http://www-106.ibm.com/developerworks/webservices/library/ws-
arc3/ [Abruf: 21.09.2004]
[3] IRANI, Romin; BASHA, S. Jeelani: AXIS – Next Generation Java SOAP.
Wrox Press, Mai 2002.
[4] KEMPER, A.; EICKLER, A.: Datenbanksysteme – Eine Einfuhrung. R.
Oldenbourg Verlag, 2. Auflage, 1997.
[5] Microsoft Corporation: COM: Component Object Model Technologies.
URL: http://www.microsoft.com/com/tech/DCOM.asp [Abruf:
29.10.2004]
[6] Object Management Group (OMG): CORBA.
URL: http://www.corba.org [Abruf: 21.09.2004]
[7] Open Applications Group (OAG): SAP AG and Open Applications Group
Announce BAPI Compliance with Open Applications Group Specificati-
ons. 1997.
URL: http://www.openapplications.org/news/pr-info/970825.htm [Ab-
ruf: 28.11.2004]
[8] SAP AG: SAP Help Portal.
URL: http://help.sap.com [Abruf: 16.11.2004]
[9] SCHUESSLER, Thomas G.: Developing Applications with the”SAP Java
Connector (JCo)“. Version 0.8.1. ARAsoft GmbH, 2002.
[10] SCHUESSLER, Thomas G.: Tips and Tricks for SAP Java Connector
(JCo) Client Programming. In: SAP Professional Journal. Ausgabe Janu-
ar/Februar 2004.
90
Literaturverzeichnis
[11] Sun Microsystems, Inc: JDBC Technology.
URL: http://java.sun.com/products/jdbc [Abruf: 28.11.2004]
[12] Systinet Corporation: Introduction to Web Services Architecture. 2002.
[13] TANENBAUM, A. S.; VAN STEEN, M.: Distributed Systems. Prentice
Hall, 2002.
[14] UDDI.org: UDDI.
URL: http://www.uddi.org
[15] World Wide Web Consortium (W3C): HTTP – Hypertext Transfer Pro-
tocol
URL: http://www.w3c.org/Protocols/ [Abruf: 21.09.2004]
[16] World Wide Web Consortium (W3C): Simple Object Access Protocol
(SOAP) 1.1. W3C Note 08 May 2000.
URL: http://www.w3c.org/TR/2000/NOTE-SOAP-20000508/ [Abruf:
21.09.2004]
[17] World Wide Web Consortium (W3C): Extensible Markup Language
(XML).
URL: http://www.w3c.org/XML/ [Abruf: 21.09.2004]
[18] World Wide Web Consortium (W3C): XML Schema.
URL: http://www.w3.org/XML/Schema [Abruf: 21.09.2004]
[19] World Wide Web Consortium (W3C): Web Service Architecture Require-
ments. W3C Working Draft 29 April 2002.
URL: http://www.w3.org/TR/2002/WD-wsa-reqs-20020429 [Abruf:
27.09.2004]
[20] World Wide Web Consortium (W3C): Web Services Description Language
(WSDL) 1.1. W3C Note 15 March 2001.
URL: http://www.w3.org/TR/wsdl [Abruf: 27.09.2004]
[21] Winer, Dave: XML-RPC Specification. Juni 1999.
URL: http://www.xmlrpc.com/spec [Abruf: 01.10.2004]
[22] WEIKUM, G.: Datenbanksysteme. Universitat des Saarlandes, 1998. –
Skript zur Vorlesung.
[23] WUTKA, Mark: J2EE Developer’s Guide. Markt+Technik Verlag, 2002.
91