Aktuelle Ansätze für Web Service basierte Integrationslösungen. Andreas Schmietendorf, Jens Lezius, Evgeni Dimitrov Daniel Reitz, Reiner Dumke

Größe: px
Ab Seite anzeigen:

Download "Aktuelle Ansätze für Web Service basierte Integrationslösungen. Andreas Schmietendorf, Jens Lezius, Evgeni Dimitrov Daniel Reitz, Reiner Dumke"

Transkript

1 Aktuelle Ansätze für Web Service basierte Integrationslösungen Arbeitsgruppe Softwaretechnik Software Measurement Laboratory SMLab Andreas Schmietendorf, Jens Lezius, Evgeni Dimitrov Daniel Reitz, Reiner Dumke Otto-von-Guericke-Universität Magdeburg Fakultät Informatik - Institut für verteilter Systeme Postfach 4120, D Magdeburg Abstrakt Der vorliegende Preprint gibt einen Überblick zu den Möglichkeiten der Web- Service Technologie im Rahmen so genannter Enterprise Application Integration Lösungen (kurz EAI-Lösungen). Nach der Einführung und Motivation wird auf die technologischen Grundlagen von EAI-Lösungen und Web Services eingegangen. In einem weiteren Abschnitt werden mögliche Vorgehensweisen und Architekturansätze zur Implementierung Web Service basierter EAI- Lösungen aufgezeigt. Darüber hinaus werden potentielle Lücken im derzeitigen Konzept der Web Services beschrieben, die zum Teil den Gegenstand aktueller Standardisierungsbemühungen bilden. Um hier einen entsprechenden Einblick zu erhalten werden ausgewählte Standardisierungsansätze im weiteren Verlauf des Kapitels detailliert vorgestellt. Insbesondere wird hier auf einen herstellerübergreifenden Ansatz eingegangen, der die Möglichkeit einer Geschäftsprozesssteuerung auf der Grundlage integrierter Web Services bietet. In diesem Zusammenhang wird ein entsprechendes Beispiel vorgestellt und schrittweise erläutert. Abschließend wird auf weiterführende Ansätze bzw. derzeit noch nicht abgedeckte Themenstellungen eingegangen.

2 Dank Für die technische Aufbereitung des verwendeten BPEL-Beispiels möchten wir uns insbesondere bei Herrn Friedhelm Röhl bedanken. Auch Herrn Lars Gentsch gebührt unser Dank für die Ausarbeitung der theoretischen Grundlagen zu Web Service Technologie. Ebenso geht ein Dank an Herrn Thomas Schlosser und Frau Petra Schmietendorf für die technische Unterstützung bei der Fertigstellung des vorliegenden Preprints.

3 Inhaltsverzeichnis 1 EINFÜHRUNG UND MOTIVATION 7 2 TECHNOLOGISCHE GRUNDLAGEN Grundlagen von EAI-Lösungen Schichtenmodell der Applikationsintegration Integrationslevel Datenaustausch mit XML Dienste von EAI-Lösungen EAI-Produkte Web Service Grundlagen XML - Extensible Markup Language SOAP Simple Object Access Protocol UDDI Universal Description, Discovery and Integration Rollen im Web Service Konzept Entwicklung, Wiederverwendung und Ausführung 19 3 EAI-LÖSUNGEN AUF DER BASIS VON WEB-SERVICES Ausgangssituation Web Services und EAI: Heutige Situation und Trends Unterschiede zwischen traditionellen EAI-Lösungen und Web Services Vorgehensweise zur Implementierung von EAI-Lösungen Überblick zum Vorgehen Phasen eines Integrationsprojektes Architektur einer Web Service basierten EAI-Lösung Service- basierte Architekturen für eine Enterprise Business Integration Web Service Architekturmodelle für Enterprise Integration Beispiel: Web Services für EAI Bedeutung der Web Services für ein Unternehmen Vorteile der Nutzung von Web Services als Integrationsplattform Fachkomponenten im Rahmen von EAI-Lösungen 31 4 EAI-KONFORME STANDARDISIERUNGSANSÄTZE Überblick und aktuelle Situation WS Coordination Integration verschiedener Transaktionsprotokolle WS Transaction Transaktionsmodelle Koordinationsprotokolle für Atomic Transaction (AT) Koordinationsprotokolle für Business Activity (BA) BPEL Business Process Excecution Language for Web Services Aktivitätsdefinition in BPEL Interaktionen mit anderen Partnern Fehlerbehandlung Lifecycle von Services Beziehung zwischen WS-Transaktion und BPEL Vorteile 44

4 4.5 Beispiel einer EAI-Lösung auf Basis BPEL -Spezifikation Entwicklungs- und Laufzeitumgebung Beschreibung des Beispielprozesses Detailbeschreibung der WSDL- und BPEL-Dateien 49 5 AUSBLICK UND ENTWICKLUNGSTENDENZEN Weiterentwicklungen Communities zum Themengebiet 55 6 QUELLENVERZEICHNIS 56

5 Abbildungsverzeichnis Abbildung 1 EAI-Schichtenmodell 9 Abbildung 2: Web Service Architektur (in Anlehnung an IBM und Microsoft) 15 Abbildung 3: Beispiel einer einfachen XML-Dateil 16 Abbildung 4: Zusammenwirken der Komponenten 18 Abbildung 5: Vorgehensweise zur Implementierung einer EAI-Lösung 23 Abbildung 6: Referenzmodell einer Servicebasierten Integrationsarchitektur 26 Abbildung 7: Web Service Architekturmodell für Enterprise Integration 27 Abbildung 8: Beispiel einer Integration auf Grundlage von Web Services 29 Abbildung 9: Ablauf der Registrierung 38 Abbildung 10: Transaktionsverlauf 38 Abbildung 11: WSDL-Beschreibung der verwendeten Services 46 Abbildung 12: Bearbeitung von Prozeßbeschreibungen unter Eclipse 46 Abbildung 13: Laufzeitumgebung für BPEL 47 Abbildung 14: Auflistung der installierten Geschäftsprozesse 48 Abbildung 15: Sequenzdiagramm des Beispielprozesses 49

6 Tabellenverzeichnis Tabelle 1: Primitive BPEL-Aktivitäten 42 Tabelle 2: Strukturierte BPEL-Aktivitäten 42 Listingverzeichnis Listing 1: Definitionen und Namensbereiche 49 Listing 2: Message Definitionen 50 Listing 3: Definitionen der Porttypen 50 Listing 4: Properties und Aliasing 51 Listing 5: Servicelinktype Definitionen 51 Listing 6: Bekanntmachung des Dienstes 51 Listing 7: Definitionen und Namensbereiche 51 Listing 8: Partner-Definitionen 52 Listing 9: Container-Definitionen 52 Listing 10: Definition des Correlation Set 52 Listing 11: einfache und strukturierte Aktivitäten 53 Listing 12: Verzweigungen 53 Listing 13: Versenden des Ergebnisses 53

7 1 Einführung und Motivation Die Geschwindigkeit mit der Leistungen an heutigen Märkten plaziert werden können wird zunehmend zu einem entscheidenden Wettbewerbsfaktor. Die Grundlage dafür sind zum einem effizient gestaltete Geschäftsprozesse die möglichst einen durchgängigen Ablauf notwendiger Aktivitäten gewährleisten und zum anderen darunter liegende Softwaresysteme welche die fachlich begründeten Funktionen dieser Aktivitäten im Rahmen von Softwareanwendungen realisieren. Im Rahmen sowohl strategischer als auch zeitweiser Partnerschaften (dies impliziert auch eine Zusammenarbeit auf Anforderung) erfolgt eine gemeinsame Vermarktung von Produkten, die Integration von Produktions- und Lieferantenbeziehungen, der gemeinsame Zugriff auf Informationen und Services beteiligter Unternehmen sowie der Zugriff auf technische als auch menschliche Ressourcen. Die kommenden Jahre werden dementsprechend durch einen ständigen Wandel von Geschäftsprozessen geprägt sein, welche durch Informationssysteme effizient zu unterstützen sind. Integrationslösungen, welche sowohl unternehmensinterne als auch unternehmensexterne IT-Systeme geschäftsprozeßgetrieben integrieren, spielen in diesem Kontext eine zunehmend wichtigere Rolle. Konnten noch vor einigen Jahren Investitionen durch den bloßen Hinweis auf immer neue Technologien bzw. entsprechende Hypes begründet werden, steht nun das Wirtschaftlichkeitsdenken im Vordergrund. Es gilt Wettbewerbsvorteile durch die Optimierung der vorhandenen IT-Infrastruktur zu erreichen. Dem entsprechend sind erfolgreich eingesetzte Lösungen im Sinne des Investitionsschutzes an neue Bedürfnisse anzupassen, Einsparungspotentiale aufzudecken und vor allem eine geschäftsprozessorientierte Ausrichtung der verwendeten IT-Systeme zu gewährleisten. In diesem Kontext gewinnen Integrationslösungen zunehmend an Bedeutung. Bisher haben sich für deren Realisierung dedizierte Integrationsframeworks, die von Firmen wie z.b. IBM, TIBCO oder auch Vitria bereitgestellt werden, etabliert. Wenngleich diese Systeme einen hohen Reifegrad besitzen und insbesondere in großen Unternehmen seit einigen Jahren erfolgreich eingesetzt werden, implizieren sie auch gravierende Nachteile. Insbesondere dann, wenn mittelständische und kleine Unternehmen Integrationslösungen anstreben, erweisen sich die kommerziellen Integrationsframeworks als kostenintensiv und unflexibel. Darüber hinaus können auf diesen Frameworks aufsetzende Lösungen dem globalen Zusammenwirken von Unternehmen nur schwer folgen, da deren Standardisierung relativ gering ist. Genau an dieser Stelle setzen Web Services an. Ziel ist es, eine einfachere & kostengünstigere Vorgehensweise zur Integration von IT-Systemen anzubieten, als dieses durch dedizierte EAI- Lösungen möglich ist. Noch existiert keine einheitliche Auffassung, was genau unter einem Web Service zu verstehen ist. Sehr allgemein kann von einem softwarebasierten Service gesprochen werden, der über das weltweit verfügbare Internet angeboten wird. Web Services kombinieren dabei die Vorteile der komponentenbasierten Entwicklung, der Internet-Technologie und im zunehmenden Maße auch der Agententechnologie. Im Zusammenhang mit der Verwendung von Web Services werden die folgenden Vorteile erwartet: - Einfacher und kostengünstiger als dedizierte EAI-Frameworks - Breite Akzeptanz innerhalb der Industrie durch hohen Grad an Standardisierung - Synchrones und asynchrones Kommunikationsmodell - Unterstützung des Komponentenparadigma

8 - Einfache Vorgehensweise zur Kommunikation durch Firewalls hindurch - Brücke zwischen heterogenen Technologieansätzen 2 Technologische Grundlagen Im Rahmen dieses Abschnitts wollen wir auf die technologischen Grundlagen von EAI- Lösungen und Web Services basierten Lösungsansätzen näher eingehen. Dazu gehört im Kontext der EAI-Lösungen ein kurzer historischer Abriss über deren Entwicklung, die Vorstellung von involvierten Technologien, Integrationsstrategien und auf dem Markt angebotene Produkte für EAI-Lösungen. Für weiter führende Informationen sei auf den ebenfalls in diesem Jahr erschienen Preprint Nr. 5 verwiesen, der sich ausschließlich mit Bewertungsaspekten im Umfeld von EAI-Lösungen beschäftigt. Im Kontext der Web Services wird geklärt was unter einem Web Services zu verstehen ist und welche grundlegenden Technologien derzeit zum Einsatz kommen. [Reitz 2003] 2.1 Grundlagen von EAI 1 -Lösungen In den fünfziger und sechziger Jahre waren Anwendungen in Unternehmen noch sehr einfach gestrickt, was Funktionalität und Umfang betraf. Eine Zusammenarbeit zwischen den Applikationen war damals nicht notwendig bzw. sinnvoll. Durch Einführung von Festplattenspeichern und Datenbanktechnologien Ende der Sechziger, Anfang der Siebziger, konnten Programmierer direkt auf Informationen zugreifen, ohne den Umweg über sequentielle Datei gehen zu müssen. In dieser Zeit wurde damit begonnen, über die Integration von Unternehmensdaten nachzudenken. In den Achtzigern begann man immer mehr den Wert und die Notwendigkeit von Applikationsintegration zu verstehen. In dieser Zeit entstanden einige der Middlewaretechnologien, die teilweise auch heute noch genutzt werden (DCE-RPC 1982, CORBA 1989). Viele der Anwendungen aus den siebziger Jahren mussten an die neuen Herausforderungen an die IT-Abteilungen der Untenehmen angepasst werden. Durch die Versuche bestehende ältere Systeme zu integrieren, kam allerdings die Neuentwicklung zu kurz. Ein Grossteil der bestehenden Energien wurde darauf ausgerichtet, existierende Applikationen mit immer neuen, benötigten Features auszustatten. Zwei neue Technologien sollten Anfang der neunziger Jahre antreten, um die Probleme der Applikationsintegration zu lösen: Enterprise Ressource Planning (ERP) und Data Warehousing. Beide haben verschiedene Ausrichtungen. ERP integriert die operationalen Aspekte eines Unternehmens und Data Warehousing die anfallenden Daten. Die Weiterentwicklung dieser Technologien und die Entstehung von neuen (z.b. Messageorientierte Middleware Mitte der Neunziger) resultieren in der EAI, wie wir sie heute vorfinden. Dazu gehören beispielsweise Strategien wie das Supply Chain Management (SCM), die Business-to-Business Integration (B2B) sowie die Business Prozess Integration (BPI) Schichtenmodell der Applikationsintegration Eine automatisierte Abbildung der Geschäftsprozesse auf die IV-Struktur eines Unternehmens ist, wie schon festgestellt wurde, nur über die Integration der beteiligten Applikationen 1 Quelle: William Inmon, "A Brief History of Integration." (www.eaijournal.com)

9 möglich. Wie man sich sicher vorstellen kann ist dies, abhängig von der Größe des Unternehmens, ein relativ aufwändiger und kostenintensiver Prozess, da eine große Anzahl von unternehmensspezifischen Einflussfaktoren berücksichtigt werden müssen. Eine einfache Install and Run - Lösung ist somit kaum realisierbar. Um den Umfang und die Komplexität der Aufgaben, die bei EAI-Projekten anfallen, besser verstehen zu können, soll hier ein Schichtenmodell vorgestellt werden, das die Aspekte der Unternehmensintegration aufeinander aufbauenden Teilgebieten zuordnet und notwendige Tätigkeiten entsprechend zuteilt. Abbildung 1 EAI-Schichtenmodell Abbildung 1 zeigt eine Möglichkeit für ein solches EAI-Schichtenmodell. Auf die einzelnen Ebenen soll im Folgenden etwas detaillierter eingegangen werden: Plattform-Integration: Die Plattform-Integration bildet die unterste Ebene des EAI- Schichtenmodells. Auf dieser Stufe ist es notwendig, die zugrunde liegenden Hardund Softwarearchitekturen im heterogenen Unternehmensnetzwerk miteinander zu verbinden. Integration bedeutet hier, die Kommunikation zwischen den Unternehmensapplikationen möglichst effizient und sicher zu ermöglichen. Dazu muss u.a. zwischen verschiedenen Netzwerktypen, Hardwareplattformen und Betriebsystemen, mit eigenen Technologien und Strategien zum Informationsaustausch, vermittelt werden. Ein Beispiel ist hier die Umstellung eines heterogenen Firmennetzwerkes auf des einheitliche und von fast allen Systemen unterstützte TCP/IP-Protokoll. Middleware-Integration: Bei heutigen Unternehmen kann davon ausgegangen werden, dass ein Grossteil der existierenden Applikationen über die schon oben erwähnten Peer-to-Peer Verbindungen direkt miteinander kommunizieren. In diesen

10 Fällen kommt eine so genannte Middleware-Software zum Einsatz, die den Nachrichtenaustausch ermöglicht. Bei der Integration der beteiligten Applikationen und der damit verbundenen Ersetzung der direkten Verbindungen durch Schnittstellen zur EAI-Plattform, müssen diese Middleware-Technologien durch die EAI- Middleware ausgetauscht und die Systeme daran angepasst werden. Ist dies nicht möglich, wird es notwendig, spezielle Adapter, die die Kommunikation ermöglichen, einzusetzen. Typische Middleware-Ansätze sind beispielsweise DCE RCP, COM+/DCOM, CORBA und EJB. Daten-Integration: Eine der Schlüsselaufgaben in EAI-Projekten ist sicherlich die Integration der verschieden applikationsspezifischen Datenbanken zu einer unternehmensweiten Datenbasis, mit zentralisiertem Zugriff über die EAI-Plattform. Dazu ist es notwendig das Unternehmensdaten, inklusive dem jeweiligen Speicherort und dem Datenbankschema, für jede Applikation identifiziert und katalogisiert werden und ein unternehmensweites Metadatenmodell erstellt wird, um gezielt auf die Informationen zugreifen zu können. Soweit möglich, sollten Datenbanken zusammengefasst werden um Redundanzen zu vermeiden und Inkonsistenzen ausschließen zu können. Eine weitere Aufgabe dieser Ebene ist die Einführung eines einheitlichen Datenaustauschformates, für das sich beispielsweise XML (siehe auch Abschnitt 2.1.3) anbieten würde. Applikations-Integration: Auf der Höhe dieser Integrationsebene besteht nur noch eine eher abstrakte Sicht auf die zugrunde liegende IV-Struktur des Unternehmens. Hier besteht die Aufgabe darin, die Daten und Funktionalitäten der Applikationen dem Gesamtsystem zur Verfügung zu stellen. Erleichtert oder erst ermöglicht werden dadurch beispielsweise automatisierte Verbindungen zwischen dem Back-Office und dem Front-Office, B2B Lösungen, ein gemeinsames Nutzer-Interface für alle Applikationen und ein integrierter Web-Auftritt. Die Integration der Applikationen auf dieser Stufe ist die Vorraussetzung für ein integriertes Unternehmen auf Geschäftsprozessebene. Geschäftsprozess-Integration: Hierbei handelt es sich um die höchste Stufe der EAI. Um Geschäftsprozesse integrieren zu können, ist es notwendig, das existierende Geschäftsprozesse identifiziert, kombiniert und automatisiert werden. Dazu gehört die Verknüpfung von Aufgaben, Prozeduren, Organisationen, Informationsströmen und Anwendungen, die an den verschiedenen Geschäftsprozessen beteiligt sind Integrationslevel Anders als die Integrationsschichten, bei denen die Darstellung der Komplexität der Applikationsintegration und die Verteilung der Tätigkeiten im Vordergrund stehen, dienen die EAI-Level zur Festlegung des Umfanges der Integration aus Sicht des Unternehmens. In der Literatur 2 findet man die folgenden drei EAI-Level vor: Data-Level EAI Data-Level EAI ist aufgrund der geringen Kosten und des damit verbundenen geringen Risikos, für viele Firmen der Einstiegspunkt in die Enterprise Application Integration. Integriert wird bei diesem Level auf der Ebene der Datenhaltung (siehe Abschnitt 2.1.1, 2 B. Lublinsky - Achieving the Ultimate EAI Implementation,

11 Daten-Integration) und umgeht damit die Stufe der Applikations-Integration. Eine Anpassung der Zielanwendungen ist in den meisten Fällen nicht notwendig. Für die Data-Level EAI existieren zwei Ansätze. Beim ersten Ansatz werden Daten zwischen Datenbanken, durch die periodische oder ereignisgesteuerte Synchronisierung von Datenbankinhalten, ausgetauscht. Diese Lösung entspricht virtuell der Punkt-zu-Punkt Kommunikation und kann somit in fast allen Fällen eingesetzt werden. Sollen Daten zwischen Datenbanken mit verschiedenen Datenbankmodellen (z.b. relational und objekt-orientiert) ausgetauscht werden, muss man diese transformieren. Der zweite Ansatz geht von einer Föderation der Datenbanken aus. Dabei wird anhand einer Middleware eine Schnittstelle auf ein unternehmensweites, virtuelles Datenmodell geschaffen, unter dem alle Datenbanksysteme, unabhängig vom Hersteller, vom Modell und vom Schema, zusammengefasst werden. Alle Applikationen haben somit einen zentralisierten Zugriff auf alle Unternehmensdaten. Message-Level EAI Auf diesem Level erfolgt der Informationsaustausch zwischen den Applikationen auf der Basis von Nachrichten. Das heißt, dass die Applikationen direkt miteinander kommunizieren können, ohne den Umweg über die Datenbanken nehmen zu müssen, wobei allerdings voraussetzt wird, dass diese Art der Kommunikation von den zu integrierenden Systemen direkt unterstützt werden muss. Der Vorteil liegt hierbei in dem besser zu kontrollierenden Informationsaustausch. Message-Level EAI ist aufwendiger als die Data-Level EAI da die Applikationen mit Mechanismen und Schnittstellen zum Austausch von Nachrichten erweitert werden müssen. Im Gegensatz zu den Punkt-zu-Punkt Verbindungen wird hier der Publish-Subscribe Ansatz verfolgt. Bei einem Business-Event veröffentlicht die auslösende Applikation eine entsprechende Nachricht im Netzwerk. Eine andere Applikation, der Abonnement, holt sich aufgrund einer speziellen Kennzeichnung die Nachricht ab und kann dann damit weiterarbeiten. Der Nachteil bei diesem EAI-Level liegt im höheren Aufwand gegenüber der Data-Level EAI und in der hohen Kopplung der einzelnen Systeme untereinander. Process-Level EAI Bei der Prozess-Level EAI handelt es sich um die Form der Applikations-Integration, wie sie mit diesem Artikel eigentlich dargelegt werden soll. Die Integration erfolgt hier auf Basis von Geschäftsprozessen, wobei die EAI-Middleware als Workflow-Engine fungiert und damit so zu sagen den Mittelpunkt der IV-Struktur des Unternehmens bildet. Alle Unternehmens- Applikationen sind entweder direkt oder über zwischengeschaltete Adapter mit ihr verbunden. Sie hat die Aufgabe Schnittstellen für die existierenden Anwendungen bereitzustellen, den nachrichtenbasierten Informationsaustausch anhand definierter Geschäftsprozesse im System zu routen und die ausgetauschten Daten zwischen applikationsspezifischen Formaten zu transformieren. Es existieren zwei Ansätze für die Implementation der Process-Level EAI: Message Broker und Application Server. Während sich Message Broker rein auf das Routen der Nachrichten beschränken und damit die Geschäftsprozess-Logik in den Anwendungen belassen, verlagern

12 Application Server diese in die EAI-Plattform. Dadurch erhöhen sich noch einmal die Flexibilität, die Erweiterbarkeit und die Skalierbarkeit des Systems, allerdings auch gleichzeitig der Aufwand bei der Umsetzung. Die Geschäftsprozess-Integration ist die am weitesten fortgeschrittene Form der EAI. Sie erlaubt es einem Unternehmen, die Effizienz von Prozessen zu steigern, Kosten zu sparen und auf Kundenbedürfnisse besser zu reagieren. Welches Level aber letztendlich eingesetzt wird, ist von den Bedürfnissen des Unternehmens und den aufzubringenden Kosten abhängig. Gerade bei kleineren Firmen mit einer überschaubaren IV-Struktur und relativ kleinem Budget kann die Integration auf Daten- oder Nachrichtenebene durchaus genügen Datenaustausch mit XML Mit dem Start eines EAI-Projektes in einem Unternehmen muss man sich über ein einheitliches Datenformat Gedanken machen, da ansonsten die ständigen Transformationen zwischen den proprietären Formaten den Aufwand der Entwicklung erhöhen aber auch die Fehleranfälligkeit und die Laufzeit von Transaktionen innerhalb eines EAI-Systems negativ beeinflussen. Als ein de facto Standard für Datenbeschreibungssprachen im EAI-Umfeld hat sich XML (extensible Markup Language) durchgesetzt. Sie ist plattformunabhängig, menschenlesbar und wird von einer großen Anzahl an EAI bezogenen Produkten und Unternehmensapplikationen, mit Import- und Export-Funktionen unterstützt. XML ist an sich, auch wenn es der Name anders impliziert, keine Markup 3 -Language, sondern vielmehr eine Menge von Regeln, um neue Markup-Languages zu erzeugen. Entstanden ist XML als eine vereinfachte Teilmenge der Standard Generalized Markup Language (SGML), welche 1987 von Dr. Charles Goldfarb, Ed Mosher und Ray Lorie aus der GML in einen Industrie-Standard (ISO 8879) überführt wurde. Von ihr stammt beispielsweise auch HTML ab. GML (Generalized Markup Language) wurde ursprünglich entwickelt, um Kennzeichen, beispielsweise für das Layout oder den Font, in Texten für das Verlagswesen zu formalisieren. Heute dienen Markups allgemein dazu, die logische Struktur eines Dokumentes vom Inhalt zu trennen. Diese Struktur wird dazu genutzt, den Zweck der enthaltenen Daten zu beschreiben. Man spricht in diesem Fall auch von Meta-Daten. Eine mit XML definierte Markup-Language besteht aus einer Anzahl von Markup Tags (Kombination aus Wörtern und Sonderzeichen zur Beschreibung des Zwecks der Daten) und einer für die Dokumente spezifischen Baumstruktur. Die Tags und die Baumstruktur (oder Content Model) werden in der DTD- Datei (DTD Document Type Definition) niedergeschrieben. Mehr zum Thema XML findet sich u.a. in [Daconta 2000] Dienste von EAI-Lösungen An eine moderne EAI-Plattform werden eine Menge Anforderungen gestellt. Sie sollte möglichst performant, skalierbar, offen und sicher sein. Sie sollte die Geschäftsprozessintegration genauso unterstützten wie die Business-to-Business Integration und die Integration aller Nutzeroberflächen der beteiligten Applikationen. Des weiteren sollten sie über entsprechende Tools leicht zu administrieren sein, möglichst viele Standard- Applikationen und Hard- und Softwarearchitekturen unterstützen und sie sollte eine spezielle 3 Extensible Markup Language Erweiterbare Textauszeichnungs/Textkennzeichnungs-Sprache

13 Entwicklungsumgebung mitbringen, um eine Anpassungen der IV-Struktur des Unternehmens zu ermöglichen. Welche Dienste muss eine solche EAI-Lösung also anbieten, um die an sie gerichteten Bedürfnisse befriedigen zu können und das unabhängig davon, ob es sich um eine Komplettlösung von einem Anbieter oder um eine Kooperation von mehreren Produkten handelt? Die folgende Liste stellt eine Übersicht über die wichtigsten EAI-Services dar: Plattform- und Protokollmanagement: Dazu gehört die Unterstützung einer Vielzahl von Hard- und Softwareplattformen, Middlewaretechnologien im heterogenen Unternehmensnetzwerk und verschiedener Kommunikationsprotokolle. Synchronous, Asynchronous Support: Je nach Aufgabenstellung kann die Nutzung eines synchronen oder eines asynchronen Datenaustausches sinnvoller sein. Des Weiteren ist es möglich, dass verschiedene Middleware-Lösungen im Unternehmen im Einsatz sind, die nur eine der beiden Strategien unterstützen. Daher sollte eine EAI-Lösung Dienste zur Nutzung des synchronen oder asynchronen Datenaustausches und zur Vermittlung zwischen den beiden Technologien (Bridging) anbieten. Security Management: Eine sehr wesentliche aber auch sehr komplexe und verantwortungsvolle Aufgabe ist das Security Management. Unternehmensdaten sind oftmals sehr sensibel und dürfen daher auf keinen Fall in die falschen Hände geraten. Eine EAI-Lösung hat daher die Aufgabe wirkungsvolle Mechanismen für die Verschlüsselung von Kommunikation und Daten und zur Authentifizierung von Nutzern und Nutzergruppen anzubieten, um spezielle Bereiche und Informationen nur ausgewählten Personen zur Verfügung zu stellen. Daten Transformation und Mapping: Dazu gehören Dienste zur weiter oben schon erwähnten Umwandlung von proprietären Datenformaten in das einheitliche XML-Format, sowie Mechanismen zum Parsen von XML-Dateien und Nachrichten. Ebenso besteht der Bedarf an Mechanismen zur semantischen Anpassung von XML-Dateien. Daten- und Nachrichten-Persistens: Die persistente Speicherung von Daten und Nachrichten in Knotenpunkten von Übertragungseinrichtungen und Servern dient zur Sicherung der Zuverlässigkeit von Kommunikationswegen und zur Wahrung der Konsistenz des Gesamtsystems, beim Ausfall von einzelnen Systemen die an der Übermittlung und Verarbeitung der Daten und Nachrichten beteiligt sind. Sollte es zu einem Ausfall kommen, kann zur Wiederherstellung der Konsistenz, mit Hilfe der gespeicherten Informationen, ein Rollback durchgeführt werden. Transaktionsverwaltung: Operationen auf Datenbankinhalte bestehen grundsätzlich aus einer Anzahl von schreibenden und/oder lesenden Zugriffen. Transaktionen sind Datenbankoperationen, die die ACID Eigenschaften besitzen. ACID steht für: Atomicity (Eine Operation wird entweder vollständig oder gar nicht ausgeführt. Falls eine Operation nicht vollständig ausgeführt wird, müssen alle vorgenommenen Änderungen rückgängig gemacht werden, um die Konsistenz zu wahren.), Consistency (Durch eine Transaktion darf die Konsistenz der Datenbank nicht gefährdet werden, daher müssen nach der entsprechenden Operation Überprüfungen der Integritätsbedingungen vorgenommen werden.),

14 Isolation (Eine Person darf nur auf Daten zugreifen, die von keiner anderen Person bearbeitet werden. Er hat damit einen exklusiven Zugriff.) und Durability (Nach einer erfolgreichen Transaktion müssen die Ergebnisse der Operation persistent in der Datenbank vorliegen. Alle nachfolgenden Operationen beziehen sich damit auf den aktualisierten, konsistenten Inhalt der Datenbasis). Die Transaktionsverwaltung hat die Aufgaben die ACID-Eigenschaften für Transaktionen zu garantieren und eine Abarbeitungsfolge (Scheduling) für Operationen von verschiedenen Nutzern festzulegen. Routing Services: Da in einem integrierten Unternehmen die Applikationen im Idealfall nicht mehr direkt miteinander kommunizieren, hat die EAI-Plattform die Aufgabe die Nachrichten und Informationen, anhand von definierten Geschäftsprozessen, weiterzuleiten. Des Weiteren sollte sie den Anwender bei der Eingabe und Definition dieser Geschäftsprozesse, möglicherweise mit einem grafischen Editor, unterstützen. Load-Balancing: Load-Balancing bedeutet die Aufteilung von Anfragen an gleichwertig Server, um eine möglichst gleichmäßig Lastverteilung und damit minimale Antwortzeiten zu erreichen. Error- und Exception-Handling: Sollte eins der Systeme oder eine Übertragungseinrichtung ausfallen, hat die EAI-Plattform die Aufgabe, betroffene Systeme und Personen (z.b.: den Administrator) zu informieren und wenn möglich, geeignete Gegenmaßnahmen zu ergreifen. Um solche Ausfälle selbständig erkennen zu können, müssen der Zustand und die Konsistenz des Gesamtsystems ständig überwacht werden EAI-Produkte Bei EAI-Plattformen arbeiten oft verschiedene Einzellösungen Hand in Hand. Eine mit der Integration beauftragte IV-Abteilung oder Firma hat hier entweder die Möglichkeit eine am Markt befindliche Komplettlösung von einem Hersteller einzusetzen und die existierende IV- Infrastruktur darauf anzupassen, oder sie verfolgt den so genannten best of breed Ansatz, bei dem mehrere Teillösungen, von verschiedenen Herstellern, die auf das Unternehmen und auf die bestehende Situation am besten zugeschnittenen sind, ausgewählt und kombiniert werden. Der erste Ansatz hat den Vorteil, dass alle Komponenten aus einer Hand kommen und die Zusammenarbeit somit gewährleistet ist. Die Kosten für das Training der Mitarbeiter und für die Integration der Applikationen sind im Gegensatz zum zweiten Ansatz verhältnismäßig gering. Nachteilig dabei ist aber, dass Teilkomponenten, die spezielle Bedürfnisse eines Unternehmens nur eingeschränkt oder gar nicht befriedigen, in den wenigsten Fällen ausgetauscht werden können. Wurde erst einmal eine Plattform ausgewählt, ist man von ihr und den angeboten Leistungen und verwendeten Technologien abhängig. Ein späterer Wechsel auf eine andere Plattform ist mit einem unverhältnismäßig großen Aufwand verbunden. Hinzu kommt noch, dass aufgrund ihrer hohen Spezialisierung, eine Einzellösung eine Aufgabe oft besser erfüllen kann als die Teillösungen einer EAI-Plattform, welche möglichst viele Bereiche abdecken will. Produkte für das EAI-Umfeld kommen typischer Weise aus den folgenden Bereichen: Messageorienteirte Middleware TP Monitore

15 Message Broker Application Server Web-Portal-Software Process- bzw. Workflow-Engine zur Automatisierung der Geschäftsprozesse 2.2 Web Service Grundlagen In Anlehnung an [Heafel 2002] handelt es sich bei Web Services um netzwerkbasierte Applikationen, die ihre im Internet angebotenen Funktionen mittels des WSDL-Protokolls (Web-Service Description Language) beschreiben, für den Informationsaustausch XML- Dokumente (extensible Markup Language) verwenden und für den Aufruf entfernter Methoden bzw. die Datenübertragung das SOAP-Protokoll (Simple Object Access Protocol) nutzen. Typischerweise erfolgt die Übertragung der in XML-Dokumente verpackten Daten und Funktionsaufrufe auf der Basis des http-protokolls, so dass auch durch Firewalls hindurch kommuniziert werden kann. Diese Eigenschaft bietet die Möglichkeit echte B2B 4 - Anwendungen zu entwickeln. Zur Lokalisierung im Internet verfügbarer Web Services werden UDDI-Verzeichnisdienste (Universal Description, Discovery and Integration) verwendet. Zentrale UDDI Verzeichnisse werden z.b. von IBM und Micrsosoft betrieben. Waren klassische EAI-Lösungen an eine primäre Integrationsplattform gebunden, so wird durch die Verwendung der Web Service Basistechnologien eine vollständige technologische Entkopplung der kommunizierenden Systeme erreicht. Einzige Voraussetzung für die technologische Kopplung ist das Vorhandensein einer Internet/Intranet Infrastruktur. Derzeit im Internet angebotene Web Services variieren von einfachen Funktionen, wie z.b. Wetteroder Authentifizierungs-Services, bis hin zu kompletten Geschäftstransaktionen, wie z.b. die Buchung aller benötigten Leistungen im Rahmen eines Reiseportals. BPEL4WS (Business Process Automation) Messaging WS- Security WS- SLA WS-Transaction geplante WS-Standards WS-Coordination WSDL, UDDI, WS-Introspection SOAP (WS Routing, WS Attachment, DIME) verfügbare WS-Standards XML, XML Schema, Encoding Transports Basis- Techniken Abbildung 2: Web Service Architektur (in Anlehnung an IBM und Microsoft) 4 B2B Business to Business

16 In Abbildung 1 kann die durch IBM und Microsoft derzeit propagierte Web Service Architektur nachvollzogen werden. Aus dieser Übersicht wird auch ersichtlich, dass Themenstellungen wie das Messaging, sicherheitsrelevante Aspekte, die Verwendung von Service-Level- Vereinbarungen inklusive der Verrechnung oder auch die Transaktionssicherung noch keinem weltweit anerkannten Standard unterliegen XML - Extensible Markup Language XML ist ähnlich wie HTML eine Datenbeschreibungs- und Strukturierungssprache. XML bietet sehr flexible Möglichkeiten im Kontext der Informationsübertragung, weshalb es eine der wesentlichen Grundlagen zur unternehmensweiten Integration von Anwendungssystemen darstellt. Mit Hilfe von XML strukturierte Funktionen und Daten können über Protokolle, wie z.b. HTTP ausgetauscht werden. Innerhalb der Industrie arbeiten immer mehr Unternehmen mit dieser Sprache um standardisierte Datenformate für den unternehmensinternen, aber auch unternehmensübergreifenden Dokumentenaustausch festzulegen. Im folgenden ein einfaches Beispiel einer XML-Datei. <?xml version="1.0"?> <brief> <adresse typ = an > <name>harry Mustermann</name> <strasse>musterstrasse</strasse> <nummer>1b</nummer> <postleitzahl>12345</postleitzahl> <ort>musterhausen</ort> </adresse> <adresse typ = von > <name>klaus Gustav</name> <strasse>dorfstrasse</strasse> <nummer>33</nummer> <postleitzahl>54321</postleitzahl> <ort>michelbinge</ort> </adresse> <brieftext> Lieber Harry, wie geht es dir... etc. </brieftext> </brief> Abbildung 3: Beispiel einer einfachen XML-Dateil Diese kleine XML-Datei spiegelt den Aufbau eines einfachen Briefes wieder. In der ersten Zeile steht welcher XML-Version diese Datei genügt. Alle Informationen in dieser Datei werden durch so genannte Tags (englisch ausgesprochen) eingeschlossen. Der Tag <brief> zusammen mit dem schließenden Tag </brief> enthält alle Informationen eines Briefes. Es können auch mehrere Briefe in einer Datei zusammengefasst werden. Es wird von wohlgeformt oder Wohlgeformtheit bei XML gesprochen, wenn es zu jedem öffnenden Tag auch einen schließenden Tag gibt. In XML besteht die Möglichkeit in einem Tag ein oder mehrere Attribute zu definieren. Im Tag <adresse> wurde ein Attribut typ definiert welches angibt ob es sich bei der Adresse um die Empfänger- (typ = an ) oder die Absenderadresse (typ = von ) handelt. Der Tag <brieftext> umschließt den eigentlichen Inhalt des Briefes.

17 Bei den Web-Services wird XML für die SOAP-Nachrichten und für die WSDL- Beschreibung verwendet. Allerdings sind hier die Tags und ihre etwaigen Attribute fest vordefiniert. In den entsprechenden Standards des W3C sind diese genau aufgelistet und beschrieben SOAP Simple Object Access Protocol Mittels SOAP erfolgt die Kommunikation (z.b. Methodenaufrufe, Parameter und Ergebnisse) zwischen Web Services. [Knuth 2002] bringt die Bedeutung von SOAP auf eine ganz einfache Formel: SOAP = XML over HTTP. SOAP ermöglicht dabei eine RPC- (Remote Procedure Calls) und eine DOC-orientierte Arbeitsweise. Neben SOAP gab und gibt es noch andere Ansätze z.b. XML-RPC, allerdings scheint sich SOAP jetzt weitestgehend durchgesetzt zu haben nicht zu letzt auch weil Microsoft SOAP-Unterstützung in das.net- Framework integriert hat. Entsprechend [Short 2002] bieten sich die folgenden Vorteile bei der Nutzung des Protokolls: - Programmiersprachenunabhängigkeit, da SOAP keine Programmiersprache oder spezielle API (Application Programmers Interface) vorschreibt. - Transportprotokollunabhängigkeit, zwar beschreibt die SOAP-Spezifikation wie SOAP Nachrichten an HTTP gebunden werden, jedoch handelt es sich bei einer SOAP-Nachricht lediglich um ein XML-Dokument und dieses könnte auch über andere Protokolle übertragen werden (z.b.: SMTP Simple Mail Tranfer Protocol). - SOAP bietet Unabhängigkeit von einer speziellen Objektinfrastruktur, d.h. Middelware- Systeme wie COM+ oder J2EE (Enterprise Java Beans) können so modifiziert werden, dass sie SOAP unterstützen. SOAP ermöglicht eine Interoperabilität zwischen unterschiedlichen Middleware-Ansätzes, weshalb es auch als Bridge zwischen verschiedenen Technologien verwendet werden kann. - Verwendung von bestehenden Industriestandards, d.h. das SOAP auf bestehende Standards wie XML zurückgreift um z.b. Nachrichten zu kodieren. Statt einem eigenen Typensystem verwendet SOAP die in der XML-Schemaspezifikation definierten Typen. Wie schon erwähnt ist SOAP an kein spezielles Transportprotokoll gebunden. - SOAP ermöglicht Plattformunabhängigkeit, d.h. jede Plattform die XML und HTTP verwenden kann, kann auch mit anderen, diese Technologien verwendenden Plattformen, kommunizieren. So kann eine PC-Anwendung mit einer Back-End-Anwendung kommunizieren welche beispielsweise auf einem Großrechner läuft UDDI Universal Description, Discovery and Integration Um im Internet angebotene Web-Services ausfindig machen bedarf es entsprechender Verzeichnisse im Sinne eines Telefonbuches. Bei UDDI handelt es sich um einen zentralen Verzeichnisdienst der für die Veröffentlichung technischer Informationen über Webdienste verwendet wird. UDDI wurde in Kooperation mehrerer großer Unternehmen 5 wie z.b. IBM, Sun, SAP und Microsoft entwickelt. UDDI besteht aus einer Gruppe von Registrierungen und Registratoren. Jede Registrierung enthält eine vollständige Kopie des gesamten UDDI-Verzeichnisses. Das System basiert auf einem Replikationsmodell mit einem einzigen Master. Damit ist jeder registrierte Web- 5 eine vollständige Liste aller an der Entwicklung beteiligter Unternehmen findet sich unter

18 Service von jeder Registrierung aus auffindbar. Ein Registrator 6 bietet Registrierungsdienste für einen Kunden. Innerhalb des UDDI-Verzeichnisses wird jeder Web-Service über einen weltweit eindeutigen Schlüssel identifiziert, dem UDDI-Key. Unter folgenden Adressen ist ein Zugriff auf die UDDI-Registry möglich: und Rollen im Web Service Konzept Service Broker (Registry) Service Description Find WSDL + UDDI Publish WSDL + UDDI Service Requester Web Service Client or another Web Service Bind Service Provider Web Service + Service Description Abbildung 4: Zusammenwirken der Komponenten SOA steht für Service-Orientierte-Archritektur und ist eins der fundamentalen Web-Service- Architektur-Prinzipien. Bei SOA geht es darum, wie die Service-Komponenten beschrieben und organisiert sind, um einen dynamischen und möglichst automatisierten Zugriff bzw. die Suche und Benutzung zu unterstützen. Die drei Hauptakteure bzw. Rollen in diesem Schema sind der Service-Requestor, der Servcie-Broker und der Servcie-Provider. - Der Service-Provider stellt einen Dienst bzw. einen Web-Service zur Verfügung und veröffentlicht/registriert diesen Dienst beim Service-Broker. Er ist also der Dienst- Anbieter. - Der Service-Broker registriert und kategorisiert den veröffentlichten Dienst des Providers. Zusätzlich stellt er Suchdienste oder Funktionen zur Verfügung, um registrierte Dienste zu finden. - Der Service-Requestor ist der Benutzer eines Service. Er sucht beim Service-Broker den von ihm gewünschten Dienst, um diesen dann zu benutzt. In diesem Schema existieren drei Grundoperationen diese lauten: Publish, Find und Bind. - Die Publish-Operation ermöglicht es einem Service-Provider, die Möglichkeiten und die Schnittstelle seines Dienstes beim Service-Broker zu registrieren. 6 Registratoren sind z.b. Microsoft, IBM und SAP

19 - Die Find-Operation ermöglicht es dem Servcie-Requestor beim Service-Broker einen einzelnen Service einer bestimmten Kategorie eines Service-Providers zu finden. - Die Bind-Operation macht es dem Service-Requestor möglich, den Dienst eines Servcie- Providers zu nutzen Entwicklung, Wiederverwendung und Ausführung Wir wollen in diesem Abschnitt kurz auf die allgemeine Vorgehensweise zur Entwicklung, Wiederverwendung und Ausführung von Web Services eingehen. Dabei steht weniger eine konkrete Technologie, wie z.b. Microsoft.net oder die SUN J2EE im Vordergrund, als vielmehr grundsätzliche Sichtweisen auf Web Services. Die Implementierung serviceorientierter Architekturen kann einerseits die Entwicklung eigener Web Services implizieren, andererseits können im Internet verfügbare Web Services im Sinne einer Black Box -Wiederverwendung genutzt werden. Im letzten Fall stehen keine Informationen über den Quellcode des Web Services zur Verfügung. Bei kommerziellen Anwendungen setzt die Verwendung eines solchen Web Services ein hohes Vertrauen in den potentiellen Anbieter voraus. Beide Szenarien sollen im Folgenden kurz erläutert werden, darüber hinaus soll auch auf den Sachverhalt des Wirkbetriebs von Web Services eingegangen werden. Entwicklung eines Web Services Für die Entwicklung eines Web Services ist im ersten Schritt die gewünschte Funktionalität mit Hilfe der genutzten Entwicklungsumgebung zu implementieren. Dabei kann es sich z.b. um Java-Klassen, SUN s EJB-Komponenten, Microsofts COM-Komponenten oder auch Visual Basic Anwendungen handeln. In einem folgenden Schritt gilt es, die durch den Web Service angebotenen Funktionen mit einer entsprechenden Schnittstelle zu versehen. Für diese Aufgabe werden zumeist entsprechende SOAP-Toolkits angeboten. Sie erzeugen auf der einen Seite eine wsdl-datei, diese spezifiziert welche Funktionen durch den Web Service angeboten werden, auf der anderen Seite wird das Binding zwischen der wsdl-schnittstelle und der eigentlichen Implementierung erzeugt. Zur Ausführung des Web Services wird eine entsprechende Runtime-Umgebung benötigt, welche über das http-protokoll eingehende SOAP-Anfragen an die eigentliche Implementierung weiterleitet. Neue Versionen von Web Servern bieten diese Erweiterung (z.b. Apache Tomcat Axis). Verwendung eines vorhandenen Web Services Die seit vielen Jahren verfolgte Zielstellung einer möglichst umfangreichen Wiederverwendung bereits implementierter Software findet durch die Web Service- Technologie eine weitere Optimierung. Da Web Services ihre Funktionen ausschließlich über eine wohl definierte Schnittstelle anbieten, bedarf diese einer exakten Beschreibung. Nur so können interessierte Entwickler diese auch tatsächlich im Rahmen der eigenen Anwendung verwenden. Die derzeit verwendete wsdl-beschreibung berücksichtigt nur den reinen funktionalen Umfang der Schnittstelle, Themen, wie z.b. nicht funktionale Anforderungen oder auch Vor- und Nachbedingungen werden maximal durch textuelle Beschreibungen erfaßt. Eine Übersicht frei zugänglicher Web Services findet sich z.b. unter Am waren dort 332 frei zugängliche Web Services verzeichnet. Die dort angebotenen Web Services beschränken sich zumeist auf sehr einfache Funktionen, wie z.b. die Umrechnung von Währungen. Das Angebot komplexerer fachlicher Funktionen (z.b. Bearbeitung von Kundenbestellungen), die im Kontext zu einem bestimmten Geschäftsprozeß (z.b. Bereitstellungsprozeß konkreter Produkte) stehen, ist derzeit noch sehr eingeschränkt. Weitere Informationen zu dieser Themenstellung finden sich z.b. unter [Schmietendorf 2003b].

20 Ausführung von Web Services Der Wirkbetrieb servicebasierter Lösungen kann mit dem anderer Anwendungen weitgehend verglichen werden, erfordert allerdings die Überführung des System-Management in ein, die Kundenbedürfnisse berücksichtigendes Service-Meanagement. Sofern im Internet angebotene Web Services im Rahmen der Anwendung verwendet werden, liegt die Zuständigkeit für die funktionalen und nichtfunktionalen Eigenschaften beim entsprechenden Anbieter des Web Services. In diesem Fall wird ein entsprechendes Vertragsmodell benötigt, welche die kommerziellen und technischen Rahmenbedingungen fixiert. Die dort zu treffenden Vereinbarungen sollten unter anderem Aussagen über die Kosten, den zu erbringenden Leistungsumfang, die erwartete Qualität, den Umgang mit Störungen oder auch die Vorgehensweise zum Leistungsnachweis bzw. dafür genutzte Messgrößen enthalten (siehe dazu auch [Schmietendorf 2003a]). Dabei kann eine statische und eine dynamische Vorgehensweise unterschieden werden. Während bei statischen Vereinbarungen bereits zum Zeitpunkt der Wirkbetriebsaufnahme funktionale und nichtfunktionale Eigenschaften weitgehend determiniert sind (die Vertragspartner sind bereits bekannt), wird bei einer dynamischen Vorgehensweise erst zum Zeitpunkt der Ausführung ein entsprechender Vertrag quasi on demand abgeschlossen. Insbesondere der zuletzt genannte Ansatz impliziert die Vision um Aufträge konkurrierender Web Services und erlaubt damit sehr dynamische Anwendungen, die sich leicht an neue Situationen (z.b. neue Kooperation von Unternehmen) anpassen können und ihre Nutzerfunktionen in einen wirtschaftlichen Kontext (z.b. Auswahl des günstigsten Mietwagenangebotes an einem konkreten Ort) stellen können. 3 EAI-Lösungen auf der Basis von Web-Services 3.1 Ausgangssituation Im folgenden wollen wir den aktuellen Stand zu Web Services und damit umzusetzenden EAI-Lösungen aufzeigen. Dabei gehen wir auf Unterschiede bzw. Gemeinsamkeiten zwischen traditionellen EAI-Lösungen und Web Services ein Web Services und EAI: Heutige Situation und Trends Web Services sind vom reinen technologischen Standpunkt nicht mit traditionellen EAI- Lösungen gleichzusetzen. Web Services sind primär eine weitere Technologie, welche die Implementierung von EAI ermöglicht und die traditionelle Point-to-Point Kommunikation technologieunabhängig gestalten kann. Durch die Nutzung derzeit verfügbaren Web Services, die eine lose Integration von Applikationen ermöglichen, kann innerhalb eines Unternehmens nur eine Teilmenge der EAI- Anforderungen abgedeckt werden. Denn der EAI-Ansatz stellt einen vollständigen holistischen Ansatz zur semantisch enggekoppelten Integration und Verbindung aller Applikationen und Systemen, die das Unternehmensbusiness unterstützen dar. Web Services, in ihrer aktuellen Form als lose gekoppelten Sammlungen von Diensten, können eher als eine ad hoc Lösung betrachtet werden, die schnell und leicht zu entwickeln ist. Die jetzige Generation von Web Services ermöglicht lediglich eine Integration zwischen Applikationen auf Funktionslevel. Sie sind in ihrer jetzigen Ausprägung nicht transaktionsorientiert und stellen grundlegende "request/response"-funktionalität bereit. Die nächste Generation von Web Services wird insbesondere fachlich begründete Funktionalität (auch Fachkomponenten genannt) berücksichtigen. Aus technologischer Sicht werden diese

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Inauguraldissertation zur Erlangung des akademischen Grades eines Doktors

Mehr

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA Hauptseminar Management von Softwaresystemen Techniken der System-Integration EAI, Middleware, SOA, CORBA Betreuerin: Referent: Ulrike Hammerschall Alexey Krivoborodov Agenda Motivation Arten der Verteilung

Mehr

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

Mehr

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm Web Services Boto Bako Inhaltsverzeichnis 1.Einführung und Motivation...3 2.Verwendete Standards...4 2.1.SOAP...5 2.2.WSDL...6

Mehr

ASPEKTE DES EMPIRISCHEN SOFTWARE ENGINEERING IM UMFELD VON ENTERPRISE APPLICATION INTEGRATION LÖSUNGEN

ASPEKTE DES EMPIRISCHEN SOFTWARE ENGINEERING IM UMFELD VON ENTERPRISE APPLICATION INTEGRATION LÖSUNGEN ASPEKTE DES EMPIRISCHEN SOFTWARE ENGINEERING IM UMFELD VON ENTERPRISE APPLICATION INTEGRATION LÖSUNGEN Daniel Reitz, Andreas Schmietendorf, Reiner Dumke Evgeni Dimitrov, Jens Lezius, Thomas Schlosser Arbeitsgruppe

Mehr

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE PROZESSE INTEGRIEREN leicht gemacht DURCH TransConnect Geschäftsprozesse ableiten mit der Universal Worklist (UWL) Integrationsszenarien effektiver verwalten und transportieren Optimierte Personalverwaltung

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA Im Vortrag werden die Vor- und Nachteile von Geschäftsprozessen in der öffentlichen

Mehr

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION Präambel Die COI GmbH entwickelt seit 1988 moderne, prozessorientierte Lösungen rund um die Themen Archivierung, Dokumentenmanagement und Workflow. Als kompetenter

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application

Mehr

Sun ONE. Sun Open Net Environment. Architektur für Web-Services on Demand. Dr. Rainer Eschrich rainer.eschrich@sun.com

Sun ONE. Sun Open Net Environment. Architektur für Web-Services on Demand. Dr. Rainer Eschrich rainer.eschrich@sun.com Sun ONE Sun Open Net Environment Dr. Rainer Eschrich rainer.eschrich@sun.com Architektur für Web-Services on Demand Sun ONE Vision Wie kann Software dem Kunden helfen? Kostenreduktion: Wie? In dem man

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Vorlesung - Web Services

Vorlesung - Web Services Vorlesung - IVS Arbeitsgruppe Softwaretechnik Abschnitt 3.1.3 Grundlegende Web Service Technologien Seite 1 - Übersicht UDDI WSDL Requester SOAP over HTTP Provider Seite 2 - Übersicht A web service is

Mehr

Einführung in WebServices

Einführung in WebServices Einführung in WebServices Grundlagen und Praxis von WebServices Seminarleiterin: Dipl.-Ing. Mahbouba Gharbi Folie 1 / 34 Zielsetzung und Voraussetzungen Zielsetzung Nutzen von WebServices kennenlernen

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Übersicht zu den Inhalten der Vorlesung) Somemrsemester 2013 1 Ziele und Abgrenzung 2 Allgemeine Lernziele Vermittlung von Basiskenntnissen

Mehr

Web Services mit Java

Web Services mit Java Web Services mit Java Neuentwicklung und Refactoring in der Praxis Torsten Langner new technology Markt+Technik Verlag Inhaltsverzeichnis Vorwort 13 Warum ausgerechnet dieses Buch? 13 An wen richtet sich

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

EAI. Integration. EAI Version 0.9 1

EAI. Integration. EAI Version 0.9 1 EAI Enterprise Application Integration EAI Version 0.9 1 Heterogene Informationssysteme KIS DRG Grouper Stand-alone Anwendung (Windows) PACS Client-Server Anwendung (Java, LINUX, Caché) QM-System Client-Server

Mehr

Leistung schafft Vertrauen

Leistung schafft Vertrauen SOA Hintergrund und Praxis visionäre Praxis oder praxisnahe Vision Toni Gasser Integration Services 27. Oktober 2010 Leistung schafft Vertrauen Private Banking Investment Banking Asset Management Seite

Mehr

Basistechnologien: Web-Services

Basistechnologien: Web-Services Alexander Rudolf Cloud-Computing Seminar Hochschule Mannheim WS0910 1/29 Basistechnologien: Web-Services Alexander Rudolf Hochschule Mannheim Fakultät für Informatik alexander.rudolf@stud.hs-mannheim.de

Mehr

Alireza Salemi, Timo Albert. SGML-basierte Datenaustauschformate. Referenten:

Alireza Salemi, Timo Albert. SGML-basierte Datenaustauschformate. Referenten: SGML-basierte Datenaustauschformate Referenten: Alireza Salemi Timo Albert Gliederung Einleitung XML - Kurzeinführung Web Service-Technologien XML-basierte Austauschformate Spezifische Markup-Languages

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Web Services and Semantic Web - Introduction to Web Services. von Andreas Weiler

Web Services and Semantic Web - Introduction to Web Services. von Andreas Weiler Web Services and Semantic Web - Introduction to Web Services von Andreas Weiler Definitionen Beispiele Technologien Vorteile Kritik Abschlussbeurteilung Fragen? Definition von IBM: Web services are a new

Mehr

E-Business Architekturen

E-Business Architekturen E-Business Architekturen Übersicht zu den Inhalten der Vorlesung Die Inhalte der Vorlesung wurden primär auf Basis der angegebenen Literatur erstellt. Darüber hinaus finden sich vielfältige Beispiele aus

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Java und XML/XML und Java. Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle.

Java und XML/XML und Java. Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle. Java und XML/XML und Java Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle.de XML und Programmiersprachen... Java ist... Programmiersprache

Mehr

Enterprise Application Integration

Enterprise Application Integration 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Wolfgang Keller Enterprise Application Integration Erfahrungen aus

Mehr

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07. Zusicherung von Qualitätskriterien bei WebServices Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.2003 Agenda Verteilte Systeme am am Beispiel Beispiel Aspekte von Verteilung

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

Mehr

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128 ... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA

Mehr

Stand September 2010. TransConnect Die Plattform für skalierbare Anwendungsintegration

Stand September 2010. TransConnect Die Plattform für skalierbare Anwendungsintegration Stand September 2010 TransConnect Die Plattform für skalierbare Anwendungsintegration Herausforderungen für EAI-Lösungen Spezialisierte Anwendungssysteme ERP CRM ecommerce Gesundheitswesen Produktion Herausforderungen

Mehr

Szenarien und Beispiele moderner Integrationslösungen

Szenarien und Beispiele moderner Integrationslösungen http://ks.fernuni-hagen.de/ Szenarien und Beispiele moderner Integrationslösungen Jan Gellweiler 03.12.2007 CampusSource-Workshop in Dortmund Agenda Begriffsbestimmung Integration / Kopplung Integrationslösungen

Mehr

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I Sicherheitsaspekte in Service Orientierten Architekturen Eike Falkenberg Sommersemester 2006 Anwendungen I Agenda SOA? Web Services? Sicherheitsrisiko Web Services Web Services & Sicherheit Sichere SOAs

Mehr

Service Oriented Architectures

Service Oriented Architectures Service Oriented Architectures Einführung in die Integration verschiedener Anwendungssysteme - Problematik und allgemeine Architektur Julia Weisheitel (WI5773) Inhalt Überblick Probleme und Entscheidungen

Mehr

Web Services T-Systems GS Darmstadt

Web Services T-Systems GS Darmstadt T-Systems GS Darmstadt Optional: Präsentationstitel Verfasser, Dr. A. Heck, Projekt, T-Systems weitere Angaben Datum, 23.10.2002, Seite Seite 1 1 Übersicht 1. Unternehmensdarstellung T-Systems 2. Definition

Mehr

Inhalt I. Blick zurück II. Was sind WebServices? III. Rahmenwerk für edienstleistungen IV. Verwendete WebServices

Inhalt I. Blick zurück II. Was sind WebServices? III. Rahmenwerk für edienstleistungen IV. Verwendete WebServices WebServices Applikationen und Services Ralf Günther Consultant HP Services April, 2003 Ralf.Guenther@hp.com DECUS Symposium 2003, Vortrag 2L06 9.04.2003 Inhalt I. Blick zurück II. Was sind WebServices?

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Geschäftsprozessmodellierung essmodellierung mit BPEL

Geschäftsprozessmodellierung essmodellierung mit BPEL Geschäftsprozessmodellierung essmodellierung mit BPEL Autor: Stefan Berntheisel Datum: 8. Januar 2010 Stefan Berntheisel Hochschule RheinMain Fachseminar WS 09/10 Agenda Grundlagen Business Process Execution

Mehr

Java Web Services mit Apache Axis2 Entwickler

Java Web Services mit Apache Axis2 Entwickler Thilo Frotscher, Dapeng Wang, Marc Teufel Java Web Services mit Apache Axis2 Entwickler Vorwort 15 1 Einleitung 25 1.1 Entstehung 26 1.2 Unterstützte Standards 28 1.3 Was beinhaltet Axis2? 29 1.4 Warum

Mehr

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS Piotr Kasprzak Agenda Laufzeitumgebung Java EE (J2EE) Motivation APIs / Technologien JBoss Entwicklungsumgebung Eclipse Ausblick Java EE -

Mehr

SOAP Simple Object Access Protocol

SOAP Simple Object Access Protocol Informatikseminar Tobias Briel Überblick 1. Einführung - was ist? 2. Middlewaretechnologie 3. Aufbau von Nachrichten 4. Vergleiche 5. Beispielanwendung 6. Zusammenfassung 1 Einführung was ist Soap? neue

Mehr

Termin 4: Web Services Computing

Termin 4: Web Services Computing Arbeitsgruppe Übung Netzbasierte Informationssysteme Termin 4: Web Services Computing Prof. Dr. Adrian Paschke Arbeitsgruppe Corporate Semantic Web (AG-CSW) Institut für Informatik, Freie Universität Berlin

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

1. Was bedeutet EAI? 2. Worin liegen die Vorteile? 3. Worin liegen die Nachteile? 4. EAI-Markt

1. Was bedeutet EAI? 2. Worin liegen die Vorteile? 3. Worin liegen die Nachteile? 4. EAI-Markt Referate-Seminar WS 2001/2002 Veranstaltungsort: Giessen Datum: 03. April 2002 Fachbereich: Wirtschaftsinformatik Referentin: Übersicht 2. Worin liegen die Vorteile? 3. Worin liegen die Nachteile? Seite

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Workflow Management: Workflow (1)

Workflow Management: Workflow (1) Workflow Management: Workflow (1) Abgrenzung: Geschäftsprozeß Vorgang (Aktivität) Arbeitsablauf (Workflow) Arbeitsschritt (Work Item) Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut

Mehr

Wrapper und Konnektoren geht die Rechnung auf?

Wrapper und Konnektoren geht die Rechnung auf? Wrapper und Konnektoren geht die Rechnung auf? Klaudia Hergula DaimlerChrysler AG Forschung und Technologie Wissensaustausch / Austauschgruppe (FTK/A) HPC 0516, Epplestr. 225, D-70546 Stuttgart klaudia.hergula@daimlerchrysler.com

Mehr

Oliver Olbrich Das ebxml Projekt Entstand 1999 in einer gemeinsamen Initiative von OASIS (Organisation for the Advancement of Structured Information Standards) und UN/CEAFACT (United Nations Center for

Mehr

Web Service Entwicklung mit Java. Sven Lindow

Web Service Entwicklung mit Java. Sven Lindow Web Service Entwicklung mit Java Sven Lindow 22.11.2006 Agenda Einleitung SOAP, REST, WSDL, UDDI Web Services mit Java JWSDP JAX-RPC, JAX-WS 2.0 AXIS, AXIS2 Web Services nutzen Google, Ebay Web Services

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SO A Fraunhofer-Institut für Softwareund Systemtechnik ISST Dr. Ulrich Springer Dr. Bernhard Holtkamp Dortmund, 20.01.2009

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

SOA mit.net: Vom Geschäftsprozess zur Lösung

SOA mit.net: Vom Geschäftsprozess zur Lösung SOA mit.net: Vom Geschäftsprozess zur Lösung Manfred Steyer Aktuelles Buch.Net 4.0 Update ISBN 978-3866454439 http://tinyurl.com/net4update 1 Kontakt [www] www.softwarearchitekt.at [mail] Manfred.Steyer@SoftwareArchitekt.at

Mehr

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A POIS-Praktikum 2007 Prozessimplementierung, RosettaNet PIPs 3A Manuel Blechschmidt, David Foerster, Michael Leben, Mike Nagora, Jonas Rogge, Paul Römer Gliederung 2 Einleitung Was war unsere Aufgabe? Was

Mehr

XML in der betrieblichen Praxis

XML in der betrieblichen Praxis Klaus Turowski, Klement J. Fellner (Hrsg.) XML in der betrieblichen Praxis Standards, Möglichkeiten, Praxisbeispiele Ги dpunkt.verlag Inhaltsverzeichnis 1 XML/EDI-Standardisierung: Ein Überblick 1 1.1

Mehr

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa Dr. Stefan Pietschmann, PF Service-Oriented Enterprise Applications, T-Systems MMS Dresden, 22.10.2013 About US PF42 Service-oriented enterprise

Mehr

Klausur Verteilte Systeme Was versteht man unter verteilte Systeme

Klausur Verteilte Systeme Was versteht man unter verteilte Systeme Was versteht man unter verteilte Systeme Ein Verteiltes System ist ein System in dem Hardware- und Softwarekomponenten, die sich auf miteinander vernetzten Computern befinden miteinander kommunizieren

Mehr

OSS/J als Basis für Enterprise Application Integration

OSS/J als Basis für Enterprise Application Integration OSS/J als Basis für Enterprise Application Integration Geschäftsprozessgesteuerte EAI im Telekommunikationsbereich r A business of PwC Agenda OSS-Architekturen als Integrationsherausforderung OSS/J als

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

VS11 Slide 1. Verteilte Systeme. Vorlesung 11 Sebastian Iwanowski FH Wedel

VS11 Slide 1. Verteilte Systeme. Vorlesung 11 Sebastian Iwanowski FH Wedel VS11 Slide 1 Verteilte Systeme Vorlesung 11 Sebastian Iwanowski FH Wedel VS11 Slide 2 Verteilte Systeme 1. Innovative Beispiele aus der Praxis 2. Allgemeine Anforderungen und Techniken verteilter Systeme

Mehr

Block Web-Dienste. Beispiel: ohne Browser. ohne Browser. Beispiel: Definition

Block Web-Dienste. Beispiel: ohne Browser. ohne Browser. Beispiel: Definition Block Web-Dienste Web-Dienste Klaus Schild, 2004 1 heutige Vorlesung Was sind Web-Dienste (Web Services)? diensteorientierte Architekturen Was ist SOAP, WSDL und UDDI? Entfernte Prozeduraufrufe (RPCs)

Mehr

E-Business Architekturen

E-Business Architekturen E-Business Architekturen Übung 3b Entwicklung eigener Service-Angebote 01.03.2015 Prof. Dr. Andreas Schmietendorf 1 Ziele der Übung Möglichkeiten zur Serviceimplementierung (ggf. auch Cloud) Umgang mit

Mehr

Von 0 auf SOA in 10 Schritten. Stefan Tilkov innoq stefan.tilkov@innoq.com

Von 0 auf SOA in 10 Schritten. Stefan Tilkov innoq stefan.tilkov@innoq.com Von 0 auf SOA in 10 Schritten Stefan Tilkov innoq stefan.tilkov@innoq.com 1 Stefan Tilkov Geschäftsführer und Principal Consultant, innoq Deutschland GmbH Fokus auf SOA, Web-Services, REST SOA-Editor InfoQ.com

Mehr

Enterprise Application Integration. Sascha M. Köhler Software Architekt

Enterprise Application Integration. Sascha M. Köhler Software Architekt Sascha M. Köhler Software Architekt Agenda 2 01 Herausforderungen unserer Kunden 02 Lösungsdefinition 03 PROFI Angebot 04 Zusammenfassung Der IT-Gemüsegarten ITK Systeme sind auf Grund von Funktionen &

Mehr

Quo vadis, OPC? - von Data Access bis Unified Architecture - Dipl.-Ing. (BA) Erik Hennig Dresden, 25.10.2007

Quo vadis, OPC? - von Data Access bis Unified Architecture - Dipl.-Ing. (BA) Erik Hennig Dresden, 25.10.2007 Informatik» Angewandte Informatik» Technische Informationssysteme Quo vadis, OPC? - von Data Access bis Unified Architecture - Dipl.-Ing. (BA) Erik Hennig Dresden, 25.10.2007 Gliederung Einführung Was

Mehr

Koordination Kommunikation Bahn. KoKoBahn. Projektpartner. Laufzeit. Travemünder Datenverbund GmbH, Lübeck. dbh Logistics IT AG, Bremen

Koordination Kommunikation Bahn. KoKoBahn. Projektpartner. Laufzeit. Travemünder Datenverbund GmbH, Lübeck. dbh Logistics IT AG, Bremen Koordination Kommunikation Bahn KoKoBahn Berlin, 09. / 10. Dezember 2010 Projektpartner Travemünder Datenverbund GmbH, Lübeck dbh Logistics IT AG, Bremen Laufzeit 01.06.2008 31.05.2011 Die Komplexität

Mehr

Verteilte Datenbank- und Informationssysteme

Verteilte Datenbank- und Informationssysteme Verteilte Datenbank- und Informationssysteme Vorlesung im Wintersemester 2013/14 (Einführungsveranstaltung) Prof. Dr. Andreas Schmietendorf 1 Inhaltliche Orientierung Prof. Dr. Andreas Schmietendorf 2

Mehr

R016 Beilage 5: SOA-Glossar

R016 Beilage 5: SOA-Glossar Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB R016 Beilage 5: SOA-Glossar Ausgabedatum: 2015-02-25 Version: 2.01 Status: Genehmigt Ersetzt: 2.0 Verbindlichkeit: Weisung

Mehr

Organisation und Systeme SOA: Erstellung von Templates für WebService Consumer und Provider in Java

Organisation und Systeme SOA: Erstellung von Templates für WebService Consumer und Provider in Java SOA: Erstellung von Templates für WebService Consumer und Provider in Java Entwicklung von Java WebService Provider- und Consumer-Bibliotheken zur Standardisierung der Karmann WebService Landschaft. Konzeption

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant

<Insert Picture Here> Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant Oracle Business Process Analysis Suite Gert Schüßler Principal Sales Consultant 1 Geschäftsprozesse Zerlegung am Beispiel Kreditvergabe Antrag aufnehmen Antrag erfassen Schufa Kunden

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Web Services. 1. Quelle. Brian Connel The Seven Pillars of Web Services Management. Erschienen September 2002 im eai Journal

Web Services. 1. Quelle. Brian Connel The Seven Pillars of Web Services Management. Erschienen September 2002 im eai Journal Web Services - Brian Connel: The Seven Pillars of Web Services Management - IBM: IBM Strategy for management of the WebServices infrastrucutre Seminarvortrag von Lukasz Kidawski im Rahmen der Lehrveranstaltung

Mehr

Informationen zu fachlichen und technischen Aspekten der Koordinations- und Kommunikationsplattform KoKoBahn

Informationen zu fachlichen und technischen Aspekten der Koordinations- und Kommunikationsplattform KoKoBahn Informationen zu fachlichen und technischen Aspekten der Koordinations- und Kommunikationsplattform KoKoBahn ISETEC II KoKoBahn Seite 1 KoKoBahn Hafenübergreifende Koordinations- und Kommunikationsplattform

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Erfahrungsbericht zu JBoss SOA Platform 6 Tech Talk 2013, 17. Oktober 2013, Bern

Erfahrungsbericht zu JBoss SOA Platform 6 Tech Talk 2013, 17. Oktober 2013, Bern Erfahrungsbericht zu JBoss SOA Platform 6 Tech Talk 2013, 17. Oktober 2013, Bern Daniel Tschan Technischer Leiter Michael Zaugg Software-Ingenieur Motivation Puzzle Through 2016, companies will continue

Mehr

DCOM und.net. B. Sc. Tobias Buchloh. Seminar Software-Entwurf Fachgebiet Software Engineering, Institut für Angewandte Informatik Universität Hannover

DCOM und.net. B. Sc. Tobias Buchloh. Seminar Software-Entwurf Fachgebiet Software Engineering, Institut für Angewandte Informatik Universität Hannover DCOM und.net B. Sc. Tobias Buchloh Seminar Software-Entwurf Fachgebiet Software Engineering, Institut für Angewandte Informatik Universität Hannover 2004-12-21 Gliederung Motivation Einordnung (D)COM.NET

Mehr

XML-RPC, SOAP und Web Services. Jörn Clausen joern@techfak.uni-bielefeld.de

XML-RPC, SOAP und Web Services. Jörn Clausen joern@techfak.uni-bielefeld.de XML-RPC, SOAP und Web Services Jörn Clausen joern@techfak.uni-bielefeld.de Übersicht Was ist RPC? Was hat XML mit RPC zu tun? Was sind XML-RPC und SOAP? Was sind Web Services? Wird das die Welt retten?

Mehr

Verteilte Systeme - 1. Übung

Verteilte Systeme - 1. Übung Verteilte Systeme - 1. Übung Dr. Jens Brandt Sommersemester 2011 1. Rechnerverbünde Kommunikationsverbund: Beispiele: E-Mail (SMTP, POP/IMAP), Instant Messaging (XMPP, IRC, ICQ,...), Newsgroups (NNTP)

Mehr

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr

16.4 Wiederverwendung von COTS-Produkten

16.4 Wiederverwendung von COTS-Produkten 16.4 Wiederverwendung von COTS-Produkten COTS = commercial of the shelf im Handel erhältliche Software-Produkte Anpassung für Kunden ohne Änderung am Quellcode Quellcode in der Regel nicht einsehbar (Ausnahme

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Frank Kargl Torsten Illmann Michael Weber Verteilte Systeme Universität Ulm {frank.kargl torsten.illmann weber} @informatik.uni-ulm.de

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Integration von Unternehmenssoftware Microsoft Dynamics NAV

Integration von Unternehmenssoftware Microsoft Dynamics NAV Integration von Unternehmenssoftware Microsoft Dynamics NAV INHALT Integration von Unternehmenssoftware Microsoft Dynamics NAV (EAI): Ihre Möglichkeiten und Vorteile........................ [3] EAI mit

Mehr