XML im Bereich EAI und B2B

(1)

XML im Bereich EAI und B2B

Markus Schütze

Universität Kaiserslautern

(2)

0. Inhaltsverzeichnis

ii Anhang B...

II.

i Anhang A...

I.

30 Literatur...

5.

29 Abschluss...

4.

28 Die Rolle von XML - Dialekt SOAP in Web Services...

3.4.3

26 Die Rolle von XML - Dialekten UDDI und WSDL in Web Services...

3.4.2

Was sind Web Services ?... 26 3.4.1

25 Die Rolle von XML in Web Services...

3.4

XML - RPC... 22 3.3

21 mqSeries von IBM...

3.2.3

Der HUB-Spoke-Ansatz... 20 3.2.2

19 Point-to-Point Verbindungen...

3.2.1

19 EAI-System-Ansätze...

3.2

18 Die Rolle von XML in EAI-Systemen...

3.1.3

17 Die verschiedenen Ebenen der Anwendungsintegration...

3.1.2

16 Was ist EAI ?...

3.1

16 Enterprise Application Integration (EAI)...

3.

15 Nachteile von EDI/XML...

2.8

14 Änderung der EDI-Systemstruktur durch XML...

2.7

Vorteile von EDI/XML... 13 2.6

12 XML/EDI...

2.5

EDI-Probleme... 12 2.4

10 Der klassische EDI-Vorgang...

2.3

7 Aufbau einer EDIFACT-Übertragungsdatei...

2.2

6 Der UN/EDIFACT-Standart...

2.1

4 Electronic Data Interchange (EDI)...

2.

3 Einleitung...

1.

2 Inhaltsverzeichnis...

0.

Seite

(3)

1. Einleitung

Diese Seminararbeit befasst sich mit den Möglichkeiten der Kommunikation innerhalb und zwischen Unternehmen. Sie hebt insbesondere die Rolle der Datenbeschreibungssprache XML hervor. Sie erläutert die neuen Anforderungen, Änderungen und Verbesserungen an bestehende Kommunikationstechnologien durch Einsatz dieser doch relativ jungen , noch immer in Entwicklung befindlichen Datenbeschreibungsprache.

Die Bedeutung des Internets und die zunehmende Vernetzung von Rechnern hat für die Wirtschaft immer mehr zugenommen. Wo anfänglich das ‘sich Präsentieren’, die Webpräsenz wichtig war, so rücken jetzt immer mehr Themen in den Vordergrund, die einerseits die Beziehung zwischen Consumern und Unternehmen, das sog.

‘E-Commerce’ betonen andererseits die Kommunikation innerhalb und zwischen Unternehmen, die Aneinanderkopplung bzw. Verzahnung ihrer Geschäftsprozesse und deren Optimierung mit Hilfe der sich immer weiter entwickelnden modernen Kommunikationstechnologien und -protokolle hervorheben.

Besonders das letztgenannte Thema ermöglicht es den Unternehmungen und Organisationen effizient und flexibel auf sich ändernde Marktbedingungen zu reagieren und so Kosten einzusparen und ökonomisch zu handeln.

Im Wesentlichen unterscheidet man beim e-business vier Kategorien :

y

B2C (Business-to-Consumer) ,

Handel zwischen Unternehmen und Endkunden, der im Wesentlichen geprägt ist durch Online-Shopping bzw. den Verkauf von Waren an den Endverbraucher.

y

B2E (Business-to-Employe)

Unternehmensinterne Kommunikation, Informationsaustausch aller in der Unternehmung beteiligten Personen zwecks besserer Zusammenarbeit. (Stichwort: Intranet)

y

B2B (Business-to-Business)

Verkauf von Gütern und Waren eines Unternehmens an andere Unternehmen. Dieses beginnt mit dem Beschaffungsprozess von Rohmaterialien und halbfertigen Gütern um eigene Güter und Waren zu produzieren, die man wieder weiterverkauft.

y

B2A (Business-to-Administration)

Informationsaustausch zwischen Unternehmung und staatlichen Organisationen z.B.: Zoll

Um E-Business, im Wesentlichen B2C und B2B, erfolgreich durchzuführen, d.h. Geld zu verdienen, benötigt man Geschäftsprozesse, die sich durch hohe Geschwindigkeit und Flexibilität auszeichnen. Dieses erreicht man durch Informationsflüsse ohne Zeitverzögerungen. Was wiederum bedeutet, dass die unterstützende Informationstechnologie immer weiter integriert werden muss. Auf der einen Seite müssen Datenformate entwickelt werden, die einen einfachen und effizienten Austausch von Geschäftsdokumenten z.B. Rechnungen, Bestellungen, Preislisten etc. ermöglichen. Hier wurden Erfahrungen auf dem Gebiet des Electronic Data

(4)

Interchange (EDI) gemacht, das sich aber nur in einem geringen Maß in der geschäftlichen Welt erfolgreich etabliert hat. Meistens wird EDI nur von grossen Unternehmen betrieben und u.U. dadurch kleineren Unternehmungen aufgezwungen. (siehe Kapitel 2) Gleichzeitig müssen diese Datenformate beherrschbar bleiben, das bedeutet, sie müssen einigermaßen lesbar für den Anwender sein, damit der sensible Datenaustausch zwischen den beteiligten Partnern einsehbar bleibt. Dieses kann man unter Einsatz der XML-Technologie hervorragend verwirklichen.

Auf der anderen Seite kann intra- und interbetriebliche Kommunikation nicht nur aus reinem Austausch von Daten über vorher wohldefinierte Schnittstellen bestehen, die den Einsatz solcher EDI-Systeme schwierig und teuer machen können.

Effektive Kommunikation zum Zweck der ökonomischen Verzahnung unterschiedlicher Geschäftsprozesse zwischen und innerhalb von Unternehmungen kann auch durch die Interoperabilität von unterschiedlichen Anwendungen und damit zwischen Geschäftsprozessen realisiert werden. Einzige Vorraussetzung ist, dass diese Anwendungen eine Schnittstelle zum Versand und Empfang von Daten haben. Enterprise Application Integration (EAI) stellt Technologien bereit , die den reibungslosen und effizienten Datenaustausch zwischen diesen Anwendungen ermöglicht. EAI schafft somit die Vorraussetzung einem oder mehreren Unternehmen eine Infrastruktur aufzubauen, die durch den zunehmenden ‘E-Business’ veränderten Integrationsanspruch gerecht wird.

Auch in diesem Bereich kann XML eine bedeutende Rolle spielen, wie es im dritten Kapitel dieser Arbeit aufgezeigt wird.

2. Electronic Data Interchange (EDI)

"Unter EDI (Abkürzung für engl.: electronic data interchange) versteht man den elektronischen Datenaustausch über Geschäftstransaktionen (Bestellungen, Rechnungen, Überweisungen, Warenerklärungen usw.) zwischen Betrieben. Die Daten werden in Form von strukturierten, nach vereinbarten Regeln formatierten Nachrichten übertragen. Dadurch ist es dem Empfänger möglich, die Daten direkt in seinen Anwendungsprogrammen weiterzuverarbeiten (Durchgängigkeit der Daten)"

[Hansen 1996]

"Die Übermittlung dieser strukturierten Daten mittels festgelegter Nachrichtenstandards von einer Computeranwendung in die andere und zwar auf elektronischer Weise erfolgt mit einem Minimum an menschlichen Eingriffen."

[Kölner Centrale für Coorganisation (CCG)]

EDI ermöglicht es vorher strukturierte Geschäftsdaten zwischen zwei oder mehreren Computersystemen auszutauschen, so dass diese von den beteiligten Systemen automatisch weiterverarbeitet werden können. Unter strukturierten Daten versteht man z.B.: digitalisierte Informationen, die in Formularen eintragbar, verarbeitbar und änderbar sind. Dieses sind meistens Daten aus dem Investition und Finanzwesen, z.B. Rechnungen, Buchungen, Lieferscheine, Zahlungsaufträge aber auch z.B. Zolldokumente.

(5)

Bedingt durch die zunehmende Europäisierung ist EDI auch in zunehmenden Maße immer mehr relevant für Institutionen und staatliche Behörden. Electronic Data Interchange ist keine neue Technologie, sondern wird seit nun mehr als ca. 20 Jahren praktiziert. Vorreiter der Idee ‘Elektronischer Dokumentenaustausch’ waren hauptsächlich Vertreter der amerikanischen Bekleidungsindustrien sowie große bedeutende Handelsketten. In unseren europäischen Breitengraden waren es die Automobilindustrie und das Finanzwesen, die frühzeitig den Nutzen einer automatisierten Dokumentübermittlung erkannten. EDI war für sie ein Mittel folgende Ziele zu erreichen :

y

Konsistente und beschleunigte zwischenbetriebliche Workflows

y

Vermeidung wiederholter Datenerfassung, Medienbrüche

y

Intensivierung von Partnerbetreuung, Kommunikation

y

Wettbewerbsvorteile durch schnellere Reaktion

y

Kosteneinsparungen (z.B.: Abbau von Lagerbeständen via JiT)

y

Reduzierung von Verwaltungskosten

y

Verbesserte Lagerkontrolle

y

Verbesserung des Kundenservice

y

Unternehmenssicherung

y

Erhaltung der Wettbewerbsfähigkeit

Da sich EDI nicht aus einer Quelle entwickelte, sondern seinen Ursprung in verschiedenen Branchen hatte , wurden viele verschiedene branchenspezifische Standards entwickelt, die untereinander inkompatibel waren.

Auch wurde EDI nur von grösseren Unternehmen betrieben, da eine Einführung eines EDI-Systems hohe finanzielle Anschaffungen zur Folge hatte. So wurden unter anderem kleinere Firmen von grösseren Unternehmen dazu gedrängt EDI-Systeme einzusetzen, was für diese einen erheblichen Eingriff in Geschäfts- und Prozessabläufe darstellte. Noch heute widersetzen sich kleinere Firmen gegen den Einsatz von EDI, was zur Folge hat, dass sich die klassische Idee ‘EDI’ nicht so durchsetzte wie damals angenommen. Nach Schätzungen nutzen lediglich 5-10% der Unternehmen, für die der Einsatz von EDI vorteilhaft wäre, bereits heute das Potential dieser Technologie - und dies oft primär aufgrund des Drucks ihrer Geschäftspartner.

Auch die angesprochene Standardvielfalt tat ihr übriges. So war es z.B. nicht ohne weiteres möglich Dokumente aus der Automobilindustrie ins Finanzwesen zu transferieren und umgekehrt. Eine Auflistung existierender Standards liefert uns auszugsweise folgende Tabelle:

Trade Data Communication Standard

Trade Data Communication Standard TRADACOMS

Electronic Data Interchange Forum for Companies Computer- und Elektroindustrie

EDIFICE

Standardregeln einheitlicher Datenaustauschsysteme Konsumgüterindustrie

SEDAS

Conseil Europ´een de Federations del’Industrie Chemique

Chemische Industrie CEFIC

Kurzbeschreibung Branche

Bezeichnung

(6)

Verband der Automobilindustrie Automobilindustrie

VDA

Organization for Data Exchange by Teletransmissions in Europe Automobilindustrie

ODETTE

Society for Worldwide Interbank Financial Telecom

Finanzgewerbe SWIFT

Reinsurance and Inscurance Net Versicherungen

RINET

Diese Standards erfreuen sich noch heute eines grossen Rückhaltes und werden zum Teil noch weiterentwickelt, obwohl es schon Standards gibt, die umfangreicher und umfassender sind.

So entwickelten die Vereinten Nationen einen global gültigen, branchenüberbrückenden Standard : UN/EDIFACT. Ihm gegenüber steht der amerikanische X12 Standard der zwar branchenübergreifend ist, aber nur nationale Bedeutung erlangt hat.

2.1 Der UN/EDIFACT-Standard

Der EDIFACT-Standard ist sehr komplex bedingt durch seine branchenüberbrückende und globale Gültigkeit, so dass er allein sehr schwer zu handhaben ist. Deswegen wurden Subsets gebildet, die ihn für gewisse Anwendungsbereiche handhabbarer machen, untereinander aber trotzdem kompatibel bleiben. So sind EDIFACT-Subsets wohldefinierte Untermengen des EDIFACT Standards.

Auch wurden obengenannte Standards in den EDIFACT Standard übernommen, sind aber zum Teil keine echten Untermengen, da sie teilweise eine ganz andere Syntax und Semantik verfolgen. ‘Richtige’ Subsets des UN/EDIFACT Standards sind der aus der Automobilbranche stammende ODETTE-Standard oder der EANCOM-Standard, mit dem man über 200 Geschäftsvorfälle behandeln kann.

Der EDIFACT-Standard gliedert die Geschäftsvorfälle in Messages oder Nachrichten.

Ein kleiner Auszug dieser Nachrichtentypen liefert uns folgende Tabelle:

ANTRAG AUF ARBEITSERLAUBNIS WKGRRE

BESCHEID ÜBER ARBEITSERLAUBNIS WKGRDC

MÜLLENTSORGUNGS-INFORMATION WASDIS

ABFAHRT DES SCHIFFES VESDEP

....

BESTELLANTWORT ORDRSP

BESTELLUNG ORDERS

...

NACHRICHT FÜR DEN LADUNGS-/GÜTERUMSCHLAG UND -TRANSPORT HANMOV

ALLGEMEINE STATISTISCHE NACHRICHT GESMES

ALLGEMEINE NACHRICHT GENRAL

BANKKONTOAUSZUG FINSTA

MULTIPLER INTERBANK-ZAHLUNGSAUFTRAG FINPAY

STORNO-NACHRICHT FINCAN

...

AUTORISIERUNGS-NACHRICHT AUTHOR

ANWENDUNGSFEHLER- UND BESTÄTIGUNGS-NACHRICHT APERAK

Beschreibung Message

Ein komplettes Verzeichnis aller Messagetypen findet man unter http://www.unece.org/trade/untdid/welcome.htm. Oder unter http://www.edifactory.de/edifact/D01A/msglist.html.

(7)

2.2 Aufbau einer EDIFACT Übertragungsdatei

Im folgenden wird der Aufbau einer Message beschrieben, wobei aber zu beachten ist, dass diese Arbeit nur einen Einblick in das EDIFACT-Format liefert, da sonst der Rahmen dieses Seminars gesprengt wird.

Die EDIFACT-Syntaxregeln, zusammengefasst in Message Implementation Guides sogenannten MIG’s definieren den Aufbau der jeweiligen Message. Der Aufbau einer Message ist auch in der Norm ISO9735 festgelegt. Dort wird beschrieben wie zu verschickende Daten in einzelne Segmente zusammengefasst werden.

Diese werden zu Nachrichten zusammengefasst, die zusammen in einer Übertragungsdatei gekapselt werden. In dieser Übertragungsdatei werden die einzelnen Nachrichtentypen nach Typ ihres Geschäftsvorganges gegliedert und sortiert. Zur Veranschaulichung sei auf folgende Grafik verwiesen, in der die einzelnen Syntaxeinheiten detailliert beschrieben sind:

EDIFACT-Datei

Nachrichtengruppe 1: Bestellungen Bestellung 1

Bestellung 2 ....

Bestellung n //Nachrichtengruppe1

Nachrichtengruppe 2 : Rechnungen Rechnung 1

Rechnung 2 ...

Rechnung n //Nachrichtengruppe 2 Anfang Datei

Ende Datei

Am Anfang jeder EDIFACT -Übertragungsdatei sind Steuersegmente (z.B. UNH, UNT etc.) definiert, die standardübergreifend für alle Nachrichten gelten.

Somit sieht der Aufbau einer EDIFACT-Nachricht s gemäß der oben genannten ISO-Norm wie folgt aus:

(8)

Service String Advice Interchange Header Functional Group Header Message Header

User Data Segments Message Trailer

Functional Group Trailer Interchange Trailer

EDIFACT Abkürzung

UNA UNB UNG UNH

UNT UNE UNZ

optional optional

optional zwingend zwingend zwingend zwingend wie erfordert

Wobei die einzelnen Abkürzungen für einzelne Messagsegmente folgende Bedeutung haben.

Kennzeichnet das Ende einer EDIFACT-Übertragungsdatei und enthält die Anzahl der übertragenen

Nachrichten und die Referenzennummer des UNB.

Interchange Trailer (Servicesegment) UNZ

Beendet eine funktionale Messagegruppem spezifiziert Nachrichtenmenge und spezifiziert funktionale Gruppenreferenz

Functional Group Trailer

UNE

Ist das letzte Segment jeder EDIFACT-Nachricht und enthält die Anzahl der Segmente der Nachricht

und die selbe Nachrichtenreferenznummer wie das UNH.

Message Trailer (Servicesegment) UNT

Steht am Beginn jeder EDIFACT-Nachricht und enthält Angaben zum Nachrichtentyp, dem verwendeten

Standard, etc.

Message Header (Servicesegment) UNH

Steht am Beginn jeder EDIFACT-Übertragungsdatei und enthält Angaben zum verwendeten Zeichensatz,

Nachrichtensender und Empfänger,

eine eindeutige Referenzennummer und weitere Angaben.

Interchange Header (Servicesegment) UNB

Definiert und spezifiziert eine funktionale Messagegruppe Functional Group

Header UNG

Eine feste Stringfolge, die in der Übertragungsdatei verwendete Trennzeichen definiert.

Service String Advice

(Servicesegment) UNA

Nutzung Name

Tag

Am deutlichsten wird jedoch die Struktur einer Message an einem Beispiel.

(9)

UNA:+,? 'UNB+UNOA:2+FHPEDAL+HUBERGMBH+990802:1557+

9908021557'UNH+INVOIC0001+INVOIC:D:96A:UN'BGM+380+

9908001+9'DTM+3:19990802:102'RFF+ON:O0010001'DTM+4 :19999715:102'NAD+SE++Fahrradhandel Pedal++Waginge rstr. 5+München++81549'NAD+BY++Huber GmbH++Obstgas se 2+München++81549'LIN+1++4711.001'IMD+F++:::Fahr rad, Damen'QTY+47:1:PCE'MOA+66:750'PRI+AAA:750'LIN +2++4711.002'IMD+F++:::Luftpumpe, Stand-'QTY+47:1:

PCE'MOA+66:19,9'PRI+AAA:19,9'LIN+3++4711.003'IMD+F ++:::Ersatzventil'QTY+47:3:PCE'MOA+66:7,5'PRI+AAA:

2,5'UNS+S'MOA+79:777,4'MOA+124:124,38'MOA+128:901, 78'TAX+7+VAT+++:::16+S'UNT+28+INVOIC0001'UNZ+1+990 8021557'

Hier werden zuerst das Datenelementtrennzeichen (+), das Dezimalkommazeichen (,), sowie das Releasezeichen(?) der Nachricht definiert. Nach einem reservierten Freizeichen wird dann das Segementtrennzeichen (‘) festgelegt. Danach wird die Nachricht, ähnlich wie bei einem Briefumschlag -eingeleitet durch ein UNB+UNOA- mit Sender (FHPEDAL) und Empfänger (HUBER GmbH) versehen. Dann bekommt die Nachricht einen Datum/Zeitstempel (02.08.99:1557-> 990802:1557) und eine von der Senderfirma festgelegten Nachrichtenreferenznummer (9908021557). Das erste Segment der Nachricht wird mit einem abschließenden Hochkomma (‘) geschlossen. Das nächste Segment, eingeleitet durch ein ‘UNH’, legt den EDIFACT Nachrichtentyp (hier INVOIC) und Nachrichtenversion fest (hier D.96A). Dieses kennzeichnet die verschickte Nachricht als Rechnung, deren Aufbau gemäß UND.93A-Standard erfolgt. Im nächsten Segment werden die benutzerdefinierten Daten vermerkt, die sich aber strikt an den Standart halten müssen. Zuerst werden, eingeleitet durch das Flag ‘BGM’ Informationen wie Rechnungsnummer übermittelt. Auch wird hier gekennzeichnet, ob es sich bei diesem übermittelten Dokument um ein Original oder eine Kopie handelt. Die ‘9’

am Ende des BGM Segmentes weist dieses Beispiel als Original aus. Dann kommen Rechnungsdatum und Bestellinformationssegmente, in denen wiederum Bestelldatum, Artikelnummer, Mengenbezeichnung und Preis codiert sind, wie es die Message Implementation Guides vorschreiben. So ist ein Datumssegment DTM in der betreffenden MIB wie folgt definiert:

Das Segment DTM besteht aus der Gruppe 507 mit 3 Feldern , wobei das Feld mit der Bezeichnung 2005 eingetragen werden muss (zu sehen am M in Spalte 2 der letzten Zeile) und die Felder 2380 und 2379 eingetragen werden können (zu sehen am C) bzw. deren Einsatz empfehlenswert ist (R). Gleichzeitig werden

(10)

Datenformate der Felder festgelegt. So darf das Feld 2005 aus 3 alphanumerischen (an) Zeichen bestehen. Das Feld 2380 aus 35 alphanumerischen Zeichen und das Feld 2379 wiederum aus 3 Zeichen derselben Art. Wobei das erste und das letzte Feld Codes beinhalten die erstens Aussagen über Art des Datums machen (3 = Rechnungsdatum, 4 = Bestelldatum etc..) und zweitens die Datumscodierung im Feld 2380 festlegen.

So liefert DTM+3:19990802:102 die Information, dass die Rechnung vom 02.08.1999 ist. Dieses Datum wird nach CCYYMMDD (Jahrhundert-Jahundert-Jahr-Jahr-Monat-Monat-Tag-Tag) kodiert, was das letzte Feld durch den Code 102 festlegt.

Wer weitere Informationen über den Aufbau von EDIFACT-Nachrichten sucht, sei auf die Message

Implementation Guides der UN, zu finden unter

http://http://www.unece.org/etrades/download/downmain.htm#edifactverwiesen.

Wie werden und wann werden aber nun solche EDI-Austauschdateien aus Rechnungsformularen erstellt ? Die Antwort darauf liefert uns das nächste Teilkapitel.

2.3 Der klassische EDI-Vorgang

Den klassischen EDI-Dokumentaustauschvorgang zweier Unternehmungen kann man sich am besten wie folgt vorstellen :

Unternehmen A Unternehmen B

Anwendung

z.B.: Rechnungserstellung

Rechnung bzw.

Inhouse Daten

Rechnung bzw.

Inhouse Daten

EDIFACT- EDIFACT-

Austauschdatei Austauschdatei

EDI EDI

Konverter Konverter

digitales Medium Netzdienste, DFÜ, TCP, X.400 Mailbox

Anwendung z.B.: Rechnungsprüfung

FLATFILE

Der EDI-Dokumentaustauschprozess lässt sich grundsätzlich in zwei Teilprozesse aufteilen:

1.

Konvertierungsprozess

2.

Übermittlungsprozess

Der Konvertierungsprozess übersetzt die anfallenden auszutauschenden Daten von einem unternehmensinternen Format (Inhouse - Daten) in das oben beschreibende EDIFACT-Format (FLATFILE) und umgekehrt. Hierzu

(11)

bedarf es eines Konverters. Dieser ist ein Teil des EDI-Systems , das sowohl die Konvertierung der Daten als auch die Kommunikation vollautomatisch abwickelt. Damit die EDIFACT-Daten von der Anwendung des Kommunikationspartners (Unternehmen B) ebenfalls automatisch weiterverarbeitet werden können , muss auch bei ihm ein EDI System installiert sein, das die übertragenen EDIFACT-Daten als FLATFILE wieder in ein für ihn verarbeitbares Inhouseformat automatisch umwandelt und an die weiterverarbeitende Applikation weiterreicht Diese Möglichkeit der automatisierten Weiterverarbeitung ermöglicht den Datenimport in betriebswirtschaftliche Anwendungen, wobei es im Regelfall keine Rolle spielt, welches Anwendungsprogramm gerade benutzt wird.

Beim Übermittlungsprozess werden die EDIFACT-Daten als Flatfile von dem Unternehmen A an das Unternehmen B bzw. an mehrere Kommunikationspartner übermittelt. In der Praxis kommen meistens zwei Arten der Übermittlung zustande :

y

Direkte Kommunikation

y

Entkoppelte Kommunikation über Mailboxsysteme.

Unter direkter Kommunikation versteht man die Einrichtung einer direkten Kommunikationsverbindung (Point-to-Point) zwischen Sender und Empfänger. Dieses wird gerade bei der Verarbeitung von zeitkritischen Daten praktiziert, weshalb sie zum Beispiel in der Automobilindustrie genutzt wird. Dazu wurde das Übertragungsprotokoll ODETTE File-Transfer-Protokoll (OFTP) entwickelt, das eine sichere und schnelle Punkt zu Punkt Verbindung ermöglicht.

Bei der entkoppelten Kommunikation werden Sende- und Empfangsvorgang der Daten durch die Verwendung eines Mailboxsystems (Store-and-Foreward) entkoppelt. Dies hat den Vorteil, dass keine permanente Verbindung zu den Kommunikationspartner aufrechterhalten werden muss, sondern die Daten lediglich in bestimmten Zeitabständen in die Mailbox der Empfängerseite bzw. eine eine eigene Mailbox, die für ihn eingerichtet wurde, platziert werden.

Dieses ermöglicht den gleichzeitigen Versand der Daten an mehrere Empfänger und Einsparung von Kommunikationskosten. Zur Übermittlung der Daten wird standardmäßig das X.400-Protokoll angewendet. Für dieses Protokoll bietet zum Beispiel u.a. die Telekom mit der Telebox 400 , einem Teildienst von

T-BusinessMail so ein Mailboxsystem an. (zu finden unter :

http://www.telekom.de/dtag/ipl1/cda/level2_a/0,,11471,00.html)

Konvertierungs- und Übermittlungsprozess werden zu einem vollautomatisierten Gesamtprozess konkateniert.

Die Umkonvertierung von einem Inhouse Format in das EDIFACT Format liefert den Vorteil, dass es weltweit gültig ist. Würde man die Umkonvertierung sein lassen , und statt dessen die Inhouse Fileformate verschicken, so würde der Informationsaustausch zwischen verschiedenen Unternehmen zu einem nicht lösbaren Problem werden.

Aber auch so existieren schon negative Faktoren die im nachfolgenden zur Verdeutlichung kurz aufgezählt werden.

(12)

2.4 EDI-Probleme

Wie man insbesondere im Kapitel 2.2 erahnen kann, sind die heutzutage gängigen EDI-Formate ziemlich starre Regelwerke, die sich eng an definierte Geschäftsprozesse anlehnen, um damit möglichst viele Geschäftsvorgänge abzudecken. Aus diesem Grund ist EDIFACT ein ziemlich komplexes Regelwerk, das von einer zentralisierten Kommission weiterentwickelt werden muss. Es ist nicht möglich neue Geschäftsprozesse zu implementieren, die nötig sind , um z.B.: neue Geschäftsvorfälle zu modellieren, die mit dem Einzug des E-Commerce in die Unternehmenswelt immer häufiger auftreten. Auch sind die meisten EDI-Lösungen plattformabhängig, was eine Einführung bzw. Erneuerung von EDI sehr teuer macht. Dies ist ein Grund, warum grössere Unternehmen EDI häufiger benutzen und den ‘kleineren’ Firmen dieses aufzwingen. Die Fähigkeit EDI einzusetzen ist manchmal sogar ein Faktor, der eher wettbewerbshindernd wirkt.

Es wäre vorteilhafter ein weniger starres EDI Format zu entwickeln, das sich leicht , ohne den vorher erwähnten langwierigen Standardisierungsprozess anpassen lässt, und zusätzlich über das World Wide Web genutzt werden kann, um Kommunikationskosten zu reduzieren.

Genau diese Idee greift Electronic Data Interchange in Verbindung mit der Metadatenbeschreibungssprache XML auf.

2.5 XML/EDI

In der Industrie gibt es bereits zahlreiche Maßnahmen zur Einführung von XML, u. a.:

y

Commerce XML (cXML)

ein vom Unternehmen ARIBA geschaffener Standart für den Austausch von Geschäftsnachrichten.

Weltweite Verbreitung, aber überwiegend in Amerika. Framework für den Austausch von Produktkatalogen, Geschäftstransaktionen und komplexe Dokumente. Definiert direkte Kommunikation der Beschaffungsysteme über das Web. Wird heute von einem unabhängigen Konsortium weitergepflegt (www.cxml.org)

y

XML based CommonBusiness Library (xCBL)

von Commerce One initialisiert, Ermöglicht Austausch strukturierter Daten über das Web (Rechnungen, Bestellungen, Produktdaten), definiert aber nicht wie Nachrichten transportiert werden.

y

RosettaNet

XML-Framework, das auf Initiative von mehr als 40 Unternehmen der IT entwickelt wurde legt neben Nachrichtenformaten auch Richtlinien fest über Abläufe und Regeln von Transaktionen. Strebt Angleichung der Geschäftsprozesse in der IT an.

y

Electronic Catalog XML

von Requisite Technology angeboten, Hauptanwendungsgebiet von ecXML liegt im Austausch von Kataloginhalten und Katalogstrukturen, liefert Metadatenstruktur, um verschiedene Formate miteinander zu verbinden.

(13)

y

Open Catalog Format (OCF)

offener Standard für die Beschreibung von Produktkatalogen. Repräsentation, Speicherung und Abbildung von Produktinformationen. offener, allgemeiner Standard.

y

Produkt Data Markup Language

Format für den Austausch von Produktinformationen zwischen kommerziellen Systemen

Neben diesen Formaten ist XML/EDI ein interessanter Ansatz um kostengünstig die EDI-Idee zu verwirklichen und so einer grossen Menge an Unternehmen, Organisationen und Firmen zukommen zu lassen.

Die Vorteile von XML prädestinieren es für den Einsatz von Electronic Data Interchange. Diese sind :

y

Aufgrund der Gliederung nach Inhalt ist eine sinnvolle Suche innerhalb des XML-Dokuments nach bestimmten Elementen oder Elementen mit bestimmten Eigenschaften möglich.

y

Ein XML-Dokument kann durch die Verwendung von Stylesheets in unterschiedlichen Formaten oder Ansichten dargestellt und universell eingesetzt werden.

y

XML-Dokumente können leicht durch (unterschiedliche) Programme ausgewertet werden.

y

XML-Dokumente sind menschenlesbar.

y

Anhand von DTDs kann ein Validieren der Dokumente vorgenommen werden.

y

DTD’s beschreiben Syntax und Semantik. XML-Dokumente sind selbsterklärend.

y

Durch das Document Object Model (DOM) wird der Zugriff auf die Elemente der XML-Dokumente beschrieben. Mit dieser einheitlichen Schnittstelle wird die Programmierung von XML-Applikationen vereinfacht und damit kostengünstiger. Das unterschiedliche Format von Dokumenten ist kein so großes Hindernis mehr beim Datenaustausch und die Dokumente sind sehr flexibel einsetzbar.

Deshalb ist es sinnvoll die XML-Technologie mit EDI zu XML/EDI zu verbinden.

XML/EDI liefert gegenüber klassischem EDI folgende Vorteile

.

2.6 Vorteile von EDI/XML

y

XML/EDI ist kompatibel zu klassischem EDI.

y

Durch Anbieten von Schnittstellen zu klassischem EDI sind bestehende schon finanzierte EDI-Systeme weiternutzbar.

y

Es ist offenen Standards unterworfen, und kann somit leicht weiterentwickelt werden.

y

Daten und Regeln, die den Aufbau der Daten beschreiben, sind eng miteinander verknüpft. Die XML/EDI-Dokumente sind somit selbsterklärend.

y

Es unterstützt globale Repositorys, in denen global DTD’s und z.B.: Elementbeschreibungen abrufbar sind. (sowohl für den Menschen als auch maschinell.)

y

Es erlaubt einfache Erweiterung bestehender Anwendungen.

y

Besteht nicht nur aus den Daten und den Beschreibungen, sondern liefert im Paket Konverter-, Worklow und Prozessmanangmentutilities dazu, was wiederum eine einfache Anpassung der Dokumente an Geschäftsvorfälle und -prozesse erlaubt.

y

Es ermöglicht Interaktive Transaktionen im World Wide Web.

y

browserfähig.

y

Es ist einfacher und günstiger zu implementieren als klassisches EDI.

(14)

2.7 Änderung der EDI-Systemstruktur durch XML

Wie funktioniert aber nun XML/EDI?

XML/EDI ist ein Verbund von verschiedenen Technologien:

y

XML

y

EDI-Standards

y

Templates

y

Agenten

y

Repositories

Die Metadatenbeschreibungssprache XML dient dazu die auszutauschenden Daten zu strukturieren. Jedes Element des Dokumentes kann problemlos über das DOM angesprochen werden und man kann gleichzeitig beim Extrahieren der Daten ihre Beschreibung bekommen. Durch Einsatz von XML-Parsern kann man die Korrektheit der hergeleiteten Dokumente nachweisen. In EDI-Standarts (z.B.: EDIFACT -MIBS) sind Geschäftsvorfälle beschrieben. Es ist sinnvoll, vorhandene, langwierig getestete Standards weiter zunutzen, anstatt sie neu zu entwickeln. Sie müssen nur an die neue Technologie angepasst werden. Templates definieren Regeln zur Verarbeitung von Daten, hierzu gehören DTD’s, die die Daten strukturieren und beschreiben, wie sie zu analysieren sind. Gleichzeitig beinhalten Templates auch Vorschriften wie die Daten anzuzeigen sind. Dies wird mit Hilfe von XSL (Extensible Style Language) verwirklicht. Auch kann ein XML Dokument Informationen beinhalten, die die Verarbeitung der Daten vorschreiben. Die Daten werden damit selbsterklärend. Agenten führen von den Templates definierte Aktionen aus. Sie bestimmen die Ansichtsweise der übermittelten Informationen. Beispielsweise Java-Applet’s , welche z.B. die Darstellungsinformationen der XSL Datei auslesen und die in einer XML überlieferten anzeigen. In Repositories werden alle benötigten Informationen z.B.

zur Wiederverwendung gespeichert und global zur Verfügung gestellt. Hierzu gehören DTD’S, XSL’s und andere wichtige Informationen. Der Sinn und Zweck dieser Bibliotheken liegt darin, dass Agenten benötigte Informationen durch sie abrufen können, die diese zur Verarbeitung von Information oder Dokumenten brauchen. Auch auf die oben genannten EDI-Prozesse hat XML/EDI Auswirkungen. So kann man sich den Austausch von Dokumenten wie folgt vorstellen :

(15)

Quelle: www.ecin.de

Gleichzeitig zeigt dieses Beispiel auch auf, wie man klassisches EDI mit der XML Technologie zusammenschliessen kann.

Unternehmen A benutzt noch die ältere EDIFACT-Schnittstelle zum Austausch. (Funktionsweise siehe Kapitel 2.3) Unter Nutzung der klassischen X.400 Schnittstelle, schickt es seine Daten an einen XML/EDI Server.

Dieser ist in der Lage mit Hilfe von Repositories und den Agenten aus der EDIFACT Datei, eine XML/EDI- Datei zu generieren und zu verifizieren. Mit seinen Vorteilen. Dort werden auch die Daten verschlüsselt, so dass sie, wenn sie zum Beispiel über TCP/IP verschickt werden, von Dritten nicht eingesehen werden können.

Danach erfolgt das Routing an die betroffenen Geschäftspartner (Unternehmen B) . Die Anzeige und die Bearbeitung der Daten beim Empfänger erfolgt in einem Browser, der mit Hilfe von Applets eine komfortable Arbeitsweise ermöglicht. Die Bearbeitung mit Hilfe einer Browser/Applet-Kombination eröffnet u.a. auch den Vorteil, dass der Empfänger der EDI-Daten nicht unbedingt ein EDI System besitzen muss. Er ist aber an diese Lösung nicht gebunden, sondern kann auch ein eigenes EDI System zur Bearbeitung benutzen, da die XML/EDI Daten leicht in seine eigenes INHOUSE-Format umgewandelt werden können. (Serverseitig oder auf der Clientseite (Unternehmen B))

Die vom Unternehmen B in XML generierte Antwort wird wieder an den XML Server zurückgesandt, der diese in EDIFACT Daten umwandelt und an den Sender zurücksendet. Sematik- und Syntaxüberprüfung erfolgt ebenfalls auf dem Server.

Wer sich für die Konvertierung von EDI auf XML interessiert sei auf das im Anhang Teil A angefügte Beispiel verwiesen, das exemplarisch eine mögliche Konvertierung von EDIFACT Daten in XML aufzeigt. Mit dem aufgezeigten Wissen aus Kapitel 2.2 sollte ein Vergleich leicht möglich sein.

2.8 Nachteile von EDI/XML

Beim Beispiel im Anhang wird womöglich auch ein gravierendes Problem bei der Ausführung von EDI mit Hilfe von XML deutlich. Die generierten XML Datei und deren Zusatzdateien beinhalten 6 bis 10 mal mehr

(16)

Metadaten als die Ausgangs-UN/EDIFACT-Datei. Das Verhältnis von Nutz- zu Strukturierungsinformation ist wesentlich schlechter. Es werden also somit höhere Anforderungen an die unterliegende Kommunikationsschicht gestellt. Was zu Problemen der Antwortzeiten führen kann, wenn der Verbindungsdurchsatz zu gering gewählt wird.

3. Enterprise Application Integration

3.1 Was ist EAI ?

Definition:

„Enterprise Application Integration (EAI) kombiniert die Technologien und Prozesse, die es ermöglichen, dass unterschiedliche Anwendungen eines und verschiedener Unternehmen Geschäftsvorfallinformationen in Daten und Contexten austauschen können, die sie alle verstehen können.”

„Enterprise Application Integration macht es sich zur Aufgabe, dass unabhängig voneinander entwickelte Anwendungen sich verständigen können.”

„Enterprise Application Integration ermöglicht uneingeschränktes Verteilen von Daten und Geschäftsprozessen unter jeglichen zusammengeschlossenen Anwendungen und Datenquellen in einem Unternehmen.”

Diese drei Definitionen beschreiben das Wesen von EAI ziemlich genau. EAI ermöglicht es, dass sich unterschiedlichste Applikationen untereinander Daten austauschen können ohne vorher mit großen Aufwand an die Anforderungen, die der Bereich der Kommunikation erfordert, angepasst zu werden. Die einzige Vorraussetzung, die diese miteinander kommunizierenden Anwendungen erfüllen müssen, ist eine Möglichkeit bzw. Schnittstelle bereitzustellen, die überhaupt Kommunikation erst zulässt. Enterprise Anwendungs Integration hat es sich zur Hauptaufgabe gemacht, unterschiedlichste Anwendungen in einer heterogenen Systemumgebung zu vereinen. Dazu vereinigt EAI folgende Eigenschaften :

y

EAI ist nicht nur der Aufwand Datenformate umzuwandeln und Geschäftsprozessinformationen verschiedenen Anwendungen zukommen zu lassen, EAI ist vielmehr auch das Abbilden und die Lifeintegration von Geschäftsprozessen durch beliebige Kombination von Geschäftsapplikationen auf die Kommunikationsinfrastruktur eines oder mehrerer Unternehmen.

y

EAI ist keine ‘Instant’-Lösung, sondern speziell auf die Belange spezifischer Geschäftsprozesse zugeschnitten. EAI ist kein statisches System, es ist dynamisch an sich ändernde Anforderungen anpassbar, und zeichnet sich durch eine ausgezeichnete Erweiterbarkeit aus.

y

EAI bildet den 'Klebstoff' der die unterschiedlichsten Protokolle, Software und Hardware miteinander verbindet und mit Hilfe dieser Bausteine Geschäftsprozessmodelle nachbildet und automatisiert. Unternehmungen, die ein funktionierendes, leistungsfähiges EAI-System betreiben,

(17)

können somit bessere Effizienz ihrer Geschäftsprozesse und bessere ökonomische Handlungsfähigkeit erreichen.

3.1.2 Die verschiedenen Ebenen der Anwendungsintegration

Anwendungsintegration ist nicht gleich Anwendungsintegration. Im Bereich der EAI gibt es verschiedene Ebenen, um Anwendungsintegration zu erreichen.

Es gibt drei Integrationsstufen, die gleichzeitig die Leistungsfähigkeit von EAI-Systeme beschreiben:

1.

Anwendungsintegration auf Datenebene

2.

Anwendungsintegration auf Objektebene

3.

Anwendungsintegration auf Prozessebene

Bei der Anwendungsintegration auf Datenebene wird der Austausch von Informationen hauptsächlich als das Verfügbarmachen von Daten gesehen. Bei den meisten Unternehmungen ist Anwendungsintegration auf Datenebene der Einstiegspunkt ins Feld der EAI. Datenbasiertes EAI ermöglicht den Austausch von Daten zwischen Anwendungen. Unterstützt wird EAI dadurch durch Middlewaresysteme. Es existieren viele Datenintegrationstools, die einen Einstieg in EAI relativ günstig machen und Zugriff auf Datenbasen ohne Abänderung von Programmcode ermöglichen. XML spielt hier mit allen seinen Vorteilen eine große Rolle, da es einen flexiblen Austausch von strukturierten Daten ermöglicht.

Bei der Anwendungsintegration auf Objektebene wird versucht Daten und Gegenstände von Geschäftsvorfällen auf Objekte abzubilden. Diese Objekte kapseln Daten und definieren gleichzeitig Methoden auf ihnen.

(vergleiche objektorientierte Programmierung). Sinn und Zweck dieser Ebene ist es die spezifischen in einem bestimmten Format vorhandenen Daten unter Einhaltung der korrekten Semantik in ein anderes, dem Zielsystem verständlichen Format umzuwandeln. Auch hier eignet sich der Einsatz von XML hervorragend und wird auch benutzt , um zu übertragene Objekte zu definieren. (siehe Enterprise Application Integration with Java und XML , JP Morgenthal Kapitel 9) Diese werden in Messages gekapselt und mit Hilfe der EAI-Middleware über spezielle Messagebehandlungsroutinen (CORBA, mqSeries, XML-RPC, SOAP, etc) verschickt. Gleichzeitig erfordert diese Art der Datenbehandlung spezielle Anpassungen an den Anwendungsschnittstellen der zu integrierenden Applikationen. Bei der Anwendungsintegration auf Prozessebene werden inner- und interunternehmerische Geschäftsprozesse unterstützt und existierende Anwendungen in einen Processflow integriert. Im Laufe dieser Prozessausführung werden wiederum Objekte generiert verschickt und weiterverarbeitet. EAI-Middleware dient hier nicht zur reinen Messageverarbeitung, sondern zusätzlich als eine

‘Workflowengine’ , die Prozessvorgänge innerhalb und zwischen Unternehmen vorschreibt und unterstützt.

Diese Interationsstufe ist höchste der zu erreichenden Integration, da sie existierende eigentlich unvereinbare Anwendungen in ein zusammenhängendes System von Geschäftsprozessen integriert.

Diese Ausarbeitung wird hauptsächlich Aspekte der Anwendungsintegration auf Objektebene erläutern, und im folgendem die verschiedenen Konzepte (XML, XML-RPC, Message Queue) diskutieren, die diese Ebene der Integration realisieren.

(18)

3.1.3 Die Rolle von XML in EAI-Systemen

Da die Integration von Applikationen im Bereich EAI durch Austausch von Information auf Basis von Daten , Definition von Objekten und Kapselung dieser in Messages erfolgt. Ist es wichtig eine gemeinsame Informationsmodellierung zu finden , damit alle beteiligten Systeme sich untereinander verständigen können.

Mit XML wurde eine ausgezeichnete Lösung gefunden dieses zu bewerkstelligen, da sich Xml anbietet, jegliche Datenstrukturen strukturiert zu modellieren. XML bietet insofern ausgezeichnete Möglichkeiten eine Abbildung von komplexeren Datenstrukturen auf XML-Dokumente zu definieren, sowie deren Umkehrung. Somit entwickelt sich XML durch die massive Unterstützung von industriellen Grössen (z.B.: IBM, Microsoft, HP etc.) zu einem wichtigen Hilfsmittel, den Datenaustausch mit Hilfe von Middleware zwischen den unterschiedlich spezifizierten Schnittstellen unterschiedlichster Anwendungen zu realisieren.

So kann zum Beispiel das anwendungsinterne Objekt Angestellter leicht in XML transformiert werden. (siehe Abbildung 3.1.3.1 )

Kunde ID = 1

Vorname = 'Hermann' nachname = 'Müller' Adresse = Dawnstreet .4 Telefon = 0642/366226

<KUNDE>

<VORNAME>Hermann</VORNAME>

<NACHNAME>Müller</NACHNAME>

<ADRESSE>Dawnstreet 4</ADRESSE>

</KUNDE>

Die Umwandlung von anwendungspezifischen Daten erfolgt mit Hilfe sogenannter Konnektoren, die Informationstrukturen in XML-Nutzdaten transformieren. Diese Konnektoren, müssen vom jeweiligen Anwendungshersteller bereitgestellt werden, damit die Anwendung mit dem EAI-System kommunizieren kann.

Diese Nutzdaten können vom EAI-System durch Integrationsserver weiterverarbeitet werden. So kann das System mit Hilfe von XLST ein XML-Datendokumentformat in ein anderes XML-Datenformat umwandeln.

Desweiteren können diese XML Nutzdaten wiederum einfach in andere XML-Dokumente gekapselt werden, und so können hilfreiche Zusatzinformationen selbständig vom EAI System hinzugefügt werden. So kann das EAI-System iterativ von Netzwerkknoten zu Netzwerkknoten zusätzliche Informationen hinzufügen, die zum Beispiel Routinganweisungen beinhalten, oder ergänzende Informationen die für den eigentlichen Empfängerkonten bzw. Empfangsanwendung zur Interpretation wichtig sind.

(19)

So kann unser obiges Beispiel in Zusammenspiel mit einer Bestellannahmeapplikation durch Informationen z.B.: für eine Rechnungstelle oder/und für den Versand ergänzt werden.

<?xml version =”1.0”?>

<KUNDE>

<NAME>Müller</NAME>

</KUNDE>

</SHIPTO>

<KUNDE>

<NAME>Müller</NAME>

</KUNDE>

</BILLTO>

<LINE_ITEMS>

<LINE>

<BESCHREIBUNG>NVIDIA Geforce FX</BESCHREIBUNG>

</LINE>

</LINE_ITEMS>

</INVOICE>

Neben den hier vorgestellten Möglichkeiten, gibt es weitere verschiedene Einsatzmöglichkten von XML in EAI, die Erklärung dieser würde den Rahmen dieser Ausarbeitung sprengen.

3.2 EAI-System-Ansätze

Da Anwendungsintegration nicht nur aus Anpassungen von softwaretechnischer Sicht geschehen , sondern auf Basis von geeigneter Hardware, stellt sich die Frage, wie EAI-System in der Realität strukturell aussehen, bzw.

die einzelnen Komponenten verbunden sind.

Gleichzeitig wird durch die Visualisierung von verschiedenen Ansätzen deutlich, welche positiven Auswirkungen ein EAI-System auf eine firmeninterne heterogene Soft- und Hardwarelandschaft hat und man bekommt ein besseres Gefühl, wie die einzelnen Komponenten des Systems zur Zusammenarbeit bewegt werden

.

3.2.1 Point-to-Point Verbindungen

Ein negatives Beispiel einer gewachsenen Systemlandschaft bildet ein System, dessen Informationsflüsse durch Punkt-zu-Punkt-Verbindungen (engl. Point-to-Point) geschehen. Das Resultat einer solchen Kommunikationsstruktur ist mit ansteigender Kommunikationspartneranzahl sehr schnell unübersichtlich und nur sehr schwer bzw. unmöglich zu beherrschen, da bei n Kommunikationsteilnehmer n*(n-1) = n^2-n Schnittstellen zu verwalten sind.

(20)

CRM

B2B

HOST

DB

Lager

3.2.2 HUB-Spoke- Ansatz

Ein beliebter Ansatz die Kommunikation in einem EAI-Konstrukt zu verwirklichen, ist der HUB-Spoke Ansatz.

Man versucht der Schnittstellenexplosion das P2P-Ansatzes zu entkommen, indem man die Kommunikation über geeignete Middleware ablaufen lässt. Diese Integrationserver haben für jede Teilkomponente eine entsprechende Schnittstelle und wandeln, wie schon erwähnt, mit Hilfe der Konnektoren, anwendungspezifische Daten in ein EAI-systeminternes Datenformat um und je nach Erfordernis wieder in spezifische Datenformate zurück.

Gleichzeitig sind sie ‘Ansprechpartner’ für vom Unternehmen ausgelagerte oder systemfremde Kommunikationssysteme. XML dient auch als Daten- und Objektaustauschformat.

Durch diesen Ansatz sinkt die Schnittstellenanzahl auf 2n Konnektoren.

EAI- Middleware

(Integrationsserver, SOAP-Broker, Router)

Konnektor A Konnektor B Konnektor C

Konnektor D Konnektor E Konnektor F

KonnektorG

KonnektorH

Schnittstelle A Schnittstelle B Schnittstelle C

Schnittstelle E Schnittstelle F

SchnittstelleG

SchnittstelleH

Schnittstelle D

Unternehmen B

Anwendung A Anwendung B Anwendung C

Anwendung D Anwendung E Anwendung F

Anwendung G Anwendung H

XML/SOAP

XML/WSFL

XML

HTML XML

XML XML

z.B.: Datenbank

z.B.: Browser

Der Datenaustausch zwischen den einzelnen Anwendungen

(21)

So ist IBM mqSeries - Architektur ein Vertreter der HUB-und Spokearchitektur, und erweitert diese.

3.2.3 mqSeries von IBM

Die Integrationsplattform mqSeries von IBM implementiert die Kommunikation über zwei verschiedene Ansätze. Einmal die Kommunikation über MessageQueues , andererseits stellen die mqSeries Publish-Subscriberdienste zur Verfügung. Beide Ansätze werden hier kurz erklärt.

MqSeries offiziell ‘WebSphere MQ family’ genannt besteht aus 5 Teilkomponenten :

y

Websphere MQ

y

Websphere MQ Everyplace

y

Websphere Adapters

y

Websphere MQ Integrator Broker

y

MqSeries Workflow

Die Komponente ‘Websphere MQ’ realisiert Basisnachrichtenvermittlungsfunktionen, wie Message-Queue-Funktionalität, das im nachfolgendem erörtert wird. Die Komponente ‘Websphere MQ Integrator Broker’ baut wie alle übrigen Komponenten auf der Basiskomponente auf, und erweitert die Basisfunktionalität um Publish-Subscriberdienste und höhere Routing-Mechanismen, die auch im Nachfolgenden erörtert werden. ‘MqSeries Workflow’ ist ein ‘Business-management-Flow’-System, dass der mqSeries Famile ermöglicht Geschäftsprozesse zu modellieren und diese zu integrieren. ‘WebSphere Adapters’ stellen Konnektoren bereit, die es der Websphere MQ Family ermöglichen, die Kommunikation zwischen unterschiedlichsten Anwendungen bereitzustellen. ‘Websphere MQ Everyplace’ ermöglicht die Anbindung von ‘mobilen’ -Systemen, die z.B. über Remoteverbindungen in das EAI-System eingebunden werden können. Das Message-Queue-Prinzip beruht auf der Idee der indirekten Kommunikation. Zwei Teilsysteme kommunizieren dabei indirekt asynchron über eine MessageQueue. Diese Queue dienst als Puffer und unterstützt Transaktionsmanagment. So wird garantiert , dass keine Transaktionen verlorengehen, sondern solange in der Queue gespeichert werden, bis ein Kommunikationpartner die in die Queue gestellte Nachricht auch konsumiert. Diese Art der Kommunikation bietet neben den ACID Eigenschaften, weitere Vorteile. So kann man grössere Flexibilität im Systemdesign erreichen , da Queues, one-to-one, one-to-many und many-to-many Kommunikation einfach realisieren. Desweiteren können Anwendungen im laufenden Betrieb runtergefahren und bei Bedarf wieder gestartet werden, ohne das Datenverlust und laufende Transaktionen unterbrochen werden müssen. Dieses bedeutet Ressourcenoptimierung. Netzwerk-Handling kann vor den Anwendungen versteckt werden, das Message-Queuesystem verwaltet die Queues und verwaltet die Kommunikationsprotokolle, die nötig sind, um in das System integrierte Anwendungen anzusprechen. Dadurch können sich wiederum Anwendungsentwickler auf die eigentliche Geschäftslogik der Anwendungen konzentrieren. Bei mqSeries von IBM kommunizieren zwei Anwendungen jeweils durch zwei unidirektionale Queues miteinander. Die eine verwaltet Anfragen vom Sender an den Empfänger, die andere wiederum

(22)

Antworten des Empfängers an den Sender. Die grösse der Messages kann variabel bestimmt werden. Die Publish-/Subscriberfunktionalität ist schnell erörtert. Der mqSeries-Server verwaltet Informationen darüber, welche Anwendung mit welcher kommuniziert. So tragen sich Anwendungen in eine Liste ein, die sie dazu berechtigt, Daten einer anderen Anwendung zu empfangen. Produziert diese Anwendung nun Informationen, so werden diese automatisch an alle anderen beteiligten , in diese Subscriberliste eingetragenen Anwendungen verschickt, ähnlichen einem Newsgroupsystems. Der größte Nutzen der mqSeries bleibt aber die konforme Transaktionsverwaltung. Es werden nicht einzelne Teilnachrichten gequeued, sondern gesamte Transaktionen.

Dieses sollte nochmals betont werden. Die mq-Series Famile unterstützt einmal das Versenden der Nachrichten im XML Format. Dadurch wird dem MessageQueuing-Prinzip, die Vorteile (universelle Austauschbarkeit der Datenformate, etc.) dieser Technologie ermöglicht, gleichzeitig ermöglicht der mqSeries - Dienst die Transformation von proprietären, textbasierten Nachrichtenformate in XML und wieder zurück. Auch dient die mq-Series als Transformationsdienst zwischen den unterschiedlichen XML-NAchrichtentyopen, die in einem EAI-System verwendet werden können. Auch ist die behandlung von SOAP Messages vorgesehen. So kann Sie die SOAP -Nachrichten an verschiedene Anwendungsschnittstellen verschicken, so dass nicht unbedingt HTTP als Grundlage für den Versand von SOAP-Messages dienen muss.

3.3 XML-RPC

Durch XML können Remote-Procedure-Calls, das auführen Client fremder Methoden und Funktionen, die ein Server bereitstellt.

Dieses wird mit Hilfe von XML-RPC’s verwirklicht.

Eine XML-RPC-Message ist ein HTTP-POST-Request. Der Körper dieses Requestes ist in XML spezifiziert.

Ein durch den Request angesprochener Server führt eine Methode aus, und gibt deren Ergebnis in XML formatiert über HTTP wieder zurück. Ein Request kann wie folgt aussehen :

POST /RPC2 HTTP/1.0

User-Agent: Frontier/5.1.2 (WinNT) Host: betty.userland.com

Content-Type: text/xml Content-length: 181

<?xml version="1.0"?>

<methodName>examples.getStateName</methodName>

<param>

</param>

</params>

</methodCall>

Hierbei wird in dem Tag <methodCall> der Aufruf einer Methode namens getStateName initiiert, die ein einziger Parameter vom Typ32Bit-Integer mit einem Wert von ‘4’ übergeben.

<methodCall> muss einen Methodennamen besitzen (<methodName>) und mindestens einen Parameter (<param>). Desweitern müssen User-Agent und der Host genannt werden, sowie zur Länge des Content und der ContentType auf text/xml gesetzt werden. RPC-XML definiert einfache Datentypen wie und Objektstrukturen, die nötig sind Daten auszutauschen, die für den Aufruf der spezifischen Remotemethode wichtig sind und Rückgabeparametertypen definieren.

(23)

Die Antwort vom Server wird wie folgt übermittelt:

HTTP/1.1 200 OK Connection: close Content-Length: 158 Content-Type: text/xml

Date: Fri, 17 Jul 1998 19:55:08 GMT Server: UserLand Frontier/5.1.2-WinNT

<?xml version="1.0"?>

<param>

<value><string>South Dakota</string></value>

</param>

</params>

</methodResponse>

Hier wird gekapselt durch den Tag <methodResponse> die Antwort auf vorherigen RPC-Call gegeben. Sie besteht aus einem Parameter vom Typ String, der den von der RPC-Methode examples.getState(4) ermittelten Wert ‘South Dakota’ zurückliefet. Die erste Zeile des Headers der response informiert den Host über gelingen (200 OK) oder Nichtgelingen des RPC-Calls. Weiterhin können in der Responsenachricht , im Falle eines Fehlers, Informationen, die entsprechenden Fehlerrückgabewerte der RPC-Methode vermerkt werden.

Hierzu ein Beispiel :

<fault>

<value>

<name>faultCode</name>

</member>

<name>faultString</name>

<value><string>Too many parameters.</string></value>

</member>

</struct>

</value>

</fault>

</methodResponse>

XML spezifiziert, folgende Datengrundtypen, die wiederum durch das Tag <struct> zu beliebig komplexeren Datentypen zusammengesetzt werden können.

(24)

eW91IGNhbid0IHJlYWQgdGhpcyE=

base64-encoded binary

19980717T14:08:55 date/time

<dateTime.iso8601>

-12.214 double-precision signed

floating point number

hello world ASCII string

1 0 (false) or 1 (true)

-12 four-byte signed integer

Example Type

Tag

Zu beachten ist das ein Scalar jeweils durch ein zusätzliches <value>-Tag gekapselt wird. (siehe Bsp.) Eine vollständige Spezifikation von XML-RPC findet man unter http://www.xmlrpc.com/spec Ein zusammengesetzter Datentyp mit <struct> wird wie folgt gebildet :

<name>lowerBound</name>

</member>

<name>upperBound</name>

</member>

</struct>

Wobei die einzelnen Werte der einzelnen Elemente jeweils durch das <member>-Tag gekapselt werden. Das man wiederum durch ein <name-Tag bennenen kann>. <struct>-Strukturen können wiederum andere Struct Elemente beinhalten. XML-RPC bildet auch Arrays auf XML ab

:

<array>

<data>

<value><string>Egypt</string></value>

</data>

</array>

Ein wesentlicher Unterschied zum <struct>-Sprachmittel ist die Nichtbenennung der einzelnen Arrayelemente.

Der Nachteil von XML-RPC’s ist, dass der beteiligten Applikation die Adresse des RPC-Servers, Methoden , deren Überparameter und Rückgabewerte bekannt sein müssen. Dieses erfordert bei einer Veränderung der

‘System-Umwelt’ empfindliche Eingriffe, in die Programmlogik. Eine elegantere Lösung sollen hier, die später erläuterten WebServices bieten. (siehe Kapitel 3.4 ff)

(25)

3.4 Die Rolle von XML in Web Services - UDDI - SOAP - WSDL

Es gibt viele unterschiedliche Definitionen, die versuchen das Wesen von der Technologie ‘Web Services’ zu charakterisieren.

„Web services are selfdescribing applications that can discover and engage other Web applications to complete complex tasks over the Internet. „ [SUN]

„A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols.”

[W3C]

http://www.w3.org/TR/2002/WD-ws-arch-20021114/#intro

Nach Definition sind Web Service sind physisch entkoppelte Softwarekomponenten, die eine Möglichkeit bereitstellen über Netzwerkprotokolle logisch zusammenzuarbeiten, um ein von einem Endbenutzer gewünschtes Ergebnis zu berechnen. In diesem Process greifen diese Softwarekomponenten auf Standards zurück, die ihre Beschreibung und Zusammenarbeit definieren und unterstützen. Diese Standards stützen zum überwiegenden Teil auf die verfügbaren Techniken, die die Datenbeschreibungssparache XML bietet.

3.4.1 Was sind Web Services ?

In UDDI (Universal Discovery und Description Initiative) , SOAP (Simple Object Acess Protocol) und WSDL (Web Services Descripton Language) sind die Repräsentationen dieser Standards. Wie funktionieren Web Services und welche Rolle spielen die Standards UDDI, SOAP und WSDL? Diese Antwort soll folgende Abbildung liefern, die das Web Service Prinzip vereinfacht darstellt :

Service Requester

Service Provider Discovery

Agencies

Service Description UDDI

Client- Application

Service

Service Description WSDL SOAP

Find P

ublish

Interact

SOAP-Client Process

SOAP-Server Process HTTP

HTTP H

TTP

SO AP

Der Anbieter eines Service (Service Provider) stellt bei sich eine im XML-Dialekt WSDL spezifizierte Beschreibung und Spezifikation seines Web Service Angebots/Dienst öffentlich zur Verfügung. In dieser Beschreibung sind Datenformate und Messageaustauschformate spezifiziert, die zwischen Service Requester und

(26)

Service Provider gemäß dem Protokoll SOAP ausgetauscht werden. Gleichzeitig veröffentlicht der Service Provider sein Serviceangebot bei einer oder mehreren Discovery Agencies, indem er eine UDDI-Service Description in eine Registry einträgt. In dieser Description stehen Informationen , die den angebotenen Dienst (Suchdienst, etc.) kurz beschreiben, den Anbieter charakterisieren, sowie Zugriffsinformationen beinhalten, die beschreiben, wo die genauere WSDL - Beschreibung des Dienstes beim Serviceanbieter zu finden ist (zum Beispiel durch eine URL).

Der Service Requester, dessen Anwendung einen bestimmten Fremddienst nutzen will, wendet sich nun zuerst an die oder eine Discovery Agency, und bekommt von ihr entsprechende Informationen über Anbieter und Dienstaccess übermittelt, die ihm ermöglichen bei diesem Anbieter den gewünschten Dienst anzusprechen. Der Informationsaustausch zwischen Service-Requester und Discovery Agency (UDDI-Registry) kann entweder über ein HTTP-Frontend oder -im Falle einer applikationsbasierten Nachfrage über das SOAP-Protokoll erfolgen.

Hat der Service-Requester entsprechende Informationen bekommen, nutzt er diese , um vom Service-Provider (Dienstanbieter) die genaue, in WSDL spezifizierte, Dienstbeschreibung zu bekommen. Diese schreibt dem Service - Requester vor wie der Informationsaustausch über SOAP erfolgt. Die WSDL Spezifikation spezifiziert Schnittstellen und Datenformate, sowie Form der SOAP - Nachrichten, über die die Kommunikation zwischen Service-Requester-Client und Service-Requester-Dienst erfolgt. Die Kommunikation zwischen Applicationsclient, auf der Requester Seite, und Dienstprozess, auf der Providerseite, erfolgt ebenfalls über das SOAP-Protokoll. Der Client schickt nun benötigte Dienstaufrufe an den vom Service Provider zur Verfügung gestellten Dienst, in dem zuvor ermittelten Übertragunsprotokoll. Diese SOAP Nachrichten werden nun über HTTP z.B. an einen SOAP Server des Providers geschickt, der sie analysiert und entsprechende Dienstaufrufe generiert, um seinen Dienst anzusprechen. Der Dienst berechnet darauf das Ergebnis der Anfrage und schickt diese wiederum an den SOAP Server, der es wieder in eine SOAP-Message umwandelt und zurück an den Service-Requester-Client schickt, der mit Hilfe eines SOAP-Clientprozesses diese Auswerten kann. Die Kommunikation zwischen Service Requester und Service-Provider wird erst dadurch erfolgreich, da sie sich über ein zuvor bekanntgegebenes Protokoll ‘unterhalten’.

3.4.2 Die Rolle vom XML-Dialekten UDDI und WSDL in Web Services

Da es in der Vergangenheit kein adäquates Mittel gab, herauszufinden, welche Organisation oder Unternehmung, welche Dienste zur Verfügung stellen, geschweige denn standardisierte Beschreibungen dieser zu ermitteln , wurde UDDI eingeführt. Das UDDI-Protokoll untersteht einem Consortium, das sich darum kümmert, UDDI einheitlich zu gestalten. Dieses Consortium heißt Organization for the Advancement of Structured Information Standards (OASIS), und wird durch viele industrielle Größen unterstützt, wie z.B.: IBM, Microsoft.. Eine vollständige Liste aller Mitglieder findet man unter http://www.oasis-open.org/about/

Zur Zeit ist das UDDI-Protokoll bei Version 3 angekommen.

UDDI sind Dienste , die es Unternehmen ermöglichen, genau dieses zu tun. Das bedeutet, dass UDDI, sowohl Möglichkeiten liefert Beschreibungen der Dienste einfach zu publizieren, als auch eine standardisierte Speicherung dieser definiert. Eine UDDI Registry enthält somit Informationen über

(27)

y

Firmennnamen und Kontaktdetails, den Webseitennamen und identifizierende Nummern. (White Pages)

y

Kategorisierungen von Unternehmungen. (Yellow Pages)

y

Technische Daten über die Services. (Green Pages)

Diese Informationen werden mit Hilfe von XML.Dokumenten strukturiert, z.B.:

<serviceDetail generic="1.0" operator="Microsoft Corporation"

truncated="false" xmlns="urn:uddi-org:api">

<businessService businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"

serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1">

<name>UDDI Web Services</name>

<description xml:lang="en">UDDI SOAP/XML message-based programmatic web service interfaces.</description>

<bindingTemplate bindingKey="313C2BF0-021D-405C-8149-25FD969F7F0B"

serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1">

<description xml:lang="en">Production UDDI server, Publishing interface</description>

<accessPoint URLType="https">https://uddi.microsoft.com/publish</accessPoint>

<description xml:lang="en">UDDI SOAP Publication Interface</description>

</tModelInstanceInfo>

</tModelInstanceDetails>

</bindingTemplate>

...

</serviceDetail>

In diesem Dokument werden unterschiedliche Dienste beschrieben und die URL deren Accesspoints gekennzeichnet z.B.:

<accessPoint URLType="https">https://uddi.microsoft.com/publish</accessPoint>

Anhand dieses Beispiel kann man leicht erkennen, das UDDI eher für toolunterstützte Anfragen konzipiert ist.

Hat man einen Accesspoint gefunden, kann man unter der Angegebenen URL die genaue Spezifikation in WDSL herunterladen . (z.B. Der Dienst ^Test ^UDDI ^server, ^Publishing ^interface, am Port :

https://test.uddi.microsoft.com/publish)

Eine WSDL -Datei, die den Service beschreibt, Datenaustauschformate und Messageaufbau spezifiziert...

Eine WSDL-Datei ist im Prinzip auch eine XML Datei, in ihr werden Dienstmerkmale (<documentation>) beschrieben und Datenformatspezifikationen importiert (durch <definitions...> ):

In der WSDL-Datei werden Messagetypen des Dienstes definiert und deren Datentypen festgelegt :

...

</message>

...

Sowie den Nachrichtentypen eine Funktion zugeordnet und Ausgabe und Eingabeformate spezifiziert.

(28)

...

</operation>

...

Als auch die Definition von SOAP-Austauschnachrichten und deren Bindung an vorher definierte Operationen :

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />

<soap:operation soapAction="add_publisherAssertions" style="document" />

<soap:body use="literal" parts="body" namespace="urn:uddi-org:api_v2" />

</input>

</operation>

Die komplette WSDL_XML_Datei findet man im Anhang B.

3.4.3 Die Rolle vom XML-Dialekt SOAP in Web Services

Eine weitere XML Prozessbeschreibungssprache wurde mit Simple Object Access Protocol

(SOAP) entwickelt, deren Weiterentwicklung unter Aufsicht des W3C steht. Sinn und Zweck dieser Beschreibungssprache ist es Integration auf Prozessebene zu verwirklichen, indem sie ermöglicht Nachrichten zu kapseln, die zwischen Anwendungen und Einzelsystem im EAI-Gesamtsystem ausgetauscht werden.

Dadurch verwirklicht SOAP Information Hiding Prinzipien, die existentiell für den Aufbau eines EAI-Systems sind. SOAP kann im Zusammenspiel mit sog. SOAP-Routern als Wrapper dienen, der zwischen verschiedenen anderen Kommunikationssprachen vermittelt (z.B.: CORBA, EJB, Cobol , COM).

Eine SOAP-Nachricht ist wie folgt aufgebaut.

POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn SOAPAction: "Some-URI"

<SOAP-ENV:Envelope

Xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

<SOAP-ENV:Header>

<t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">

5

</t:Transaction>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<m:GetLastTradePrice xmlns:m="Some-URI">

</m:GetLastTradePrice>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>