Enterprise Application Integration Integrationsarchitekturen

Enterprise Application Integration
Integrationsarchitekturen
Prof. Dr. Christian Pape
Inhalt
ƒ Busarchitekturen
à Allgemein
à Message Queue
à CORBA
ƒ Hub and Spoke
ƒ Dienst-orientiert
Integrationsarchitekturen
4-2
Ebenen der Integration / Horizontal
Webshop
SAP R/3 Kern
Funktionen
Bestellungen
erzeugen
ƒ Verschiedene Aufrufparadigmen
à Remote Procedure Call (Web Services, DCE RPC)
à Verteilte Objekte (CORBA, JRMI, COM+)
à Message Queue meist mit XML Nachrichten
ƒ Davon Busarchitekturen
à CORBA, Message Queue
Integrationsarchitekturen
4-3
Busarchitektur
ƒ Hardwarearchitektur (Von-Neumann-Architektur)
ƒ Bus ist verantwortlich für
à
à
à
à
Adressierung angeschlossener Komponenten
Übertragung Daten von einer Komponente zu einer anderen
Ausnahmebehandlungen (Unterbrechungen)
Erfüllung weitere Rahmenbedingungen (z.B.
Echtzeitanforderungen)
Tastatur
GraKa
I/O
RAM
Daten/Adress-Bus
Integrationsarchitekturen
4-4
Busarchitektur
ƒ Vorteile dieses erfolgreichen Konzepts
à Komponenten leicht austauschbar (z.B. eines anderen
Hersteller)
à Neue Komponenten leicht hinzuzufügen (kann sofort mit
anderen Komponenten kommunzieren)
ƒ Reiner Transportmechanismus
à Bus nicht verantwortlich für Interpretation der Daten
(Semantik)
Tastatur
GraKa
I/O
RAM
Daten/Adress-Bus
Integrationsarchitekturen
4-5
Busarchitektur
ƒ In der Softwarearchitektur
ƒ Bus ist verantwortlich für (Änderungen fett)
à
à
à
à
Adressierung angeschlossener Systeme / Funktionen
Übertragung Daten von einem System zu einem anderen
Ausnahmebehandlungen
Erfüllung weitere Rahmenbedingungen (z.B. garantierte
Übermittlung der Daten)
ERP
System
CRM
System
Webshop
CMS
Bus
Integrationsarchitekturen
4-6
Busarchitektur
ƒ Adressierung angeschlossener Systeme / Funktionen
à IP Adresse der Systeme, ggf. Portnummer
à Weitere Daten abhängig von Bus Technologie
- MQ: Queuename für Übertragungskanal, Topic dem Nachricht
zugeordnet wird (Thema)
- CORBA: Referenz auf Dienst (symbolischer Name)
ƒ Übertragung Daten von einem System zu anderen
à Protokoll oberhalb TCP / IP
ƒ Ausnahmebehandlungen
ƒ Erfüllung weitere Rahmenbedingungen (z.B.
garantierte Übermittlung der Daten)
à MQ: Persistenz der Daten (asynchrone Kommunikation)
à CORBA: Rückmeldung an aufrufendes System (synchrone
Kommunikation)
à Transaktionen, Authentisierung
Integrationsarchitekturen
4-7
Inhalt
ƒ Busarchitekturen
à Allgemein
à Message Queue
à CORBA
ƒ Entwurfsmuster
à Nachrichten-orientierte Integration
Integrationsarchitekturen
4-8
Busarchitektur / Message Queue (MQ)
ƒ Message Queue
à Infrastruktur, um Nachrichten (Daten) zwischen Systemen
auszutauschen
à Primär asynchrone Datenübermittlung
à Keine Funktionsaufrufe, keine verteilten Komponenten
ƒ Synchrone Übermittlung durch Rückantwort als
weitere Nachricht möglich
ƒ Verschiedenste Anbieter
à IBM, MS, Vitria, Tipco (hochverfügbare, skalierbare, highperformance Systeme)
à Viele weitere Hersteller
ƒ MQ Lösung wird auf eigene Rechner installiert und
konfiguriert
à Middleware zur Datenübertragung
Integrationsarchitekturen
4-9
Busarchitektur / MQ
ƒ Nachrichtentypen einer Queue
à Text
à Objekte
à Binäre Daten
ƒ Bei Integration unterschiedlicher Systeme
à Textnachrichten verwenden
à XML als Beschreibungsformat für Daten hat sich durchgesetzt
ƒ Vorteile XML
à XML löst einige allgemeine Problem bei Verarbeitung von
Textnachrichten (Zeichencodierung, Strukturierung und Parsen der
Dokumente, …)
à Text praktisch von jeder Technologie leicht verarbeitbar
à Von Menschen lesbar und leicht änderbar (manuelle
Ausnahmebehandlung)
à Viele existierende Werkzeuge für Verarbeitung von XML
Dokumenten
Integrationsarchitekturen
4-10
Busarchitektur / MQ
ERP
System
XML
CRM
System
Webshop
CMS
MQ
ƒ
Verschiedene Transportmöglichkeiten
à
à
ƒ
ƒ
Punkt-zu-Punkt: Eine Queue von ERP zum Webshop
Publish-Subscriber: Eine Queue von ERP zu allen Systemen, die an Nachricht
interessiert sind
In jedem Fall
à
à
à
Nachricht muss entworfen werden (DTD, W3C Schema + semantische Informationen)
Nachricht muss von Quellsystem erzeugt werden
Nachricht muss von allen empfangenen Systemen eingelesen werden
à
Habe für Teile ihrer Daten XML Formate und Schnittstellen zum Senden/Emfpangen
der Daten
XML Formate produktabhängig: Entwicklungsaufwand, um mindestens eines der
Systeme zu erweiterten
„Standard“-Produkte
à
Integrationsarchitekturen
4-11
Busarchitektur / MQ
ERP
System
CRM
System
Webshop
CMS
XML
MQ
ƒ Empfangen einer Nachricht (teilweise Konfiguration)
ƒ Syntax prüfen (durch XML Parser)
ƒ Einlesen und Daten verarbeiten
à Programmieren oder spezielle Integrationswerkzeuge verwenden
Integrationsarchitekturen
4-12
Busarchitektur / MQ
ERP
System
CRM
System
XML
ƒ
ƒ
ƒ
ƒ
Webshop
CMS
MQ
Im Extremfall keine der Systeme hat eine für den Anwendungszweck nutzbare,
vorhandene XML Schnittstelle
Quellsystem
à
XML Nachricht erzeugen und versenden
à
XML Nachrichten einlesen und verarbeiten
à
Sind vorhandenen XML Formate / Schnittstellen überhaupt nutzbar für
Anwendungszweck
Frühe Validierung im Projekt durch z.B. Prototyp
Nicht auf Hersteller- oder Verkäuferaussagen verlassen
Zielsysteme
Wichtig für Entwurf des Systems
à
à
Integrationsarchitekturen
4-13
Busarchitektur / MQ - JMS
ƒ
ƒ
Java Message Service (JMS)
à
à
à
API für Anbindung Javaprogramme an Message Queue Lösungen
Implementierung der API vom Hersteller
MQ Implementierung verbindlicher Teil von J2EE seit Version 1.3
à
à
Mit herstellerabhängigen Werkzeugen (Teil J2EE Appl. Server)
Bei J2EE SDK „j2eeadmin -addJmsDestination queue_name queue“
„j2eeadmin -addJmsFactory jndi_name queue“
Zugriff via symbolischen Namens mit Java Naming and Directory
Interface (JNDI)
Erzeugung / Konfiguration Queues
à
[Abb. http://java.sun.com/products/jms/tutorial/1_3_1-fcs/doc/basics.html ]
Integrationsarchitekturen
4-14
Busarchitektur / JBoss
ƒ
ƒ
ƒ
ƒ
ƒ
JBoss Open Source J2EE
Server (www.jboss.org)
Herunterladen, Entpacken,
JAVA_HOME auf JDK 1.4+
setzen, bin/startup.bat (.sh)
ausführen:
C:\Programme\JBoss\jboss4.0.1sp1\bin\run.bat
Administrationsclient:
http://localhost:8080/jmxconsole
ConnectionFactory und
einige Queues vordefiniert
Konfiguriert via XML:
C:\Programme\JBoss\jboss4.0.1sp1\server\default\depl
oy\jms\jms-ds.xml
Integrationsarchitekturen
4-15
Busarchitektur / JBoss
Queues
ConnectionFactory
Integrationsarchitekturen
4-16
Busarchitektur / MQ - JMS
ƒ Connection Factories
à Kapselt Zugriff auf eine MQ Implementierung eines
Hersteller. In J2EE Server zu konfigurieren (IP-Adresse,
Port, User/Passwort, JMS Implementierung, …)
à Analog DataSource Konfiguration für EJB bei JDBC
ƒ Connections
à Virtuelle Verbindung zu MQ Implementierung eines
Herstellers zur Erzeugung von Sessions
ƒ Destinations
à Dies sind die Queues und Topics (für Publish-Subscriber)
ƒ Sessions
à Einzelner Thread um Nachrichten zu erzeugen / zu
konsumieren
à Message Producers, Message Consumers, Message
Listeners´, Message Selectors
Integrationsarchitekturen
4-17
Busarchitektur / MQ - JMS
J2EE
Appl.
Queue JNDI Referenz: „queue/products“
ConnectionFactory JNDI Referenz: „ibm/mq“
In Service
Locator impl.
Context ctx = new InitialContext();
ConnectionFactory cf = (ConnectionFactory)
ctx.lookup(“ibm/mq");
Queue queue = (Queue) ctx.lookup(“queue/products");
Connection connection = cf.createConnection();
QueueSession session = connection.createQueueSession(true, 0);
QueueSender sender = session.createSender(queue);
TextMessage message = session.createTextMessage();
String xmlMessage = // hier erzeugen
message.setText(xmlMessage);
Transaktion verwenden
queueSender.send(message);
connection.close();
Integrationsarchitekturen
4-18
Busarchitektur / MQ
ƒ Nachrichten-orientierte Integration mit
Message Queue
à Häufige Probleme und deren Lösungen als
Entwurfsmuster
à Voraussichtlich drei Vorlesungswochen
à Gregor Hohpe, Bobby Woolf: Enterprise
Application Patterns, Addison-Wesley
Integrationsarchitekturen
4-19
Inhalt
ƒ Busarchitekturen
à Allgemein
à Message Queue
à CORBA
ƒ Entwurfsmuster
à Nachrichten-orientierte Integration
Integrationsarchitekturen
4-20
Busarchitektur / CORBA
ƒ Common Object Request Broker Architecture
ƒ Focus: Höchstmögliche Kompatibilität bei Funktionsaufrufe
zwischen verschiedenen Technologien
ƒ Standard der OMG
à Einzelne Standards wie GIOP (Corba Protokoll), IIOP
(Implementierung on GIOP via TCP / IP), Transaktionen, …
à Zusammenfassung vieler Standards unter Namen CORBA CORBA
1.0 (1991) Praktisch nur IDL
à Derzeit CORBA 3.0+
ƒ Anbieter abhängig von Zielplattform
à
à
à
à
IONA Orbix: C, C++, VB/COM
Borland: .NET
Teil von CORBA integraler Bestandteil von J2EE und J2ME
Open Source Implementierungen: JacORB (Benutzt von JBoss,
JOnAS)
Integrationsarchitekturen
4-21
Busarchitektur / CORBA
ƒ IDL (Interface Description Language)
à Spezifikationssprache, um Dienste (Funktionen) zu
beschreiben (analog UML Klassendiagramm)
à Syntax ähnlich C++
à Implementierung kann nicht damit angegeben werden
ƒ CORBA 1.0
à Abbildung IDL auf unterschiedliche Programmiersprachen
à IDL <-> C, IDL <-> C++, IDL <-> COBOL
à Später: Protokoll, Auffinden von Diensten, Transaktionen, …
ƒ CORBA 2.2: erster umfassender portabler Standard
à Dienstimplementierungen unabhängig von
Herstellerspezifischen Besonderheiten: Dienstregistrierung
via Portable Object Adapter (POA).
ƒ CORBA 2.3: Java <-> IDL
Integrationsarchitekturen
4-22
Busarchitektur / MQ
ERP
System
CRM
System
Webshop
CMS
Methodenaufruf
ORB (Object Request Broker)
ƒ ORB ist verantwortlich für
à Auffinden eines Objekts (IDL Implementierung)
à Objektimplementierung für Aufruf vorbereiten
ƒ Aufrufender Client
à Hat keine Kenntnisse, wo Objektimplementierung
sich befinden: ORB vermittelt z.B.
Verbindungsdaten wie IP Adresse, Portnummer.
Integrationsarchitekturen
4-23
Busarchitektur / MQ
ERP
System
CRM
System
Webshop
CMS
Methodenaufruf
ORB (Object Request Broker)
ƒ Immer Punkt-zu-Punkt Verbindung
ƒ Dienst / Objekt ist mit IDL spezifiziert
à Typen, Datenstrukturen, Methoden, Parameter
ƒ Compiler: z.B. idl2java, idl2cpp
à Erzeugt alle Java Klassen, die notwendig sind, um
verteiltes Objekt zu benutzen
Integrationsarchitekturen
4-24
Busarchitektur / MQ
ERP
System
CRM
System
Webshop
CMS
Methodenaufruf
ORB (Object Request Broker)
ƒ Client Stummel (stubs)
ƒ Server Skelett (skeleton)
Integrationsarchitekturen
4-25
Busarchitektur / CORBA
ƒ Ab JDK 1.2
à
à
à
à
à
à
Ein bisschen CORBA ist Teil von Java
JDK 1.2 besitzt Eigenschaften eines ORB
idl2java Compiler
Implementierungen für IIOP, POA, …
Keine echte Alternative zu anderen ORB Implementierungen
Ausreichend, um Java CORBA Clients zu erstellen
ƒ Java Tutorial mit HelloWorld Beispiel
à http://java.sun.com/docs/books/tutorial/idl/index.html
J2ME
Appl.
J2ME
Appl.
Jeweils drei
unabhängige JVM
ORB von J2ME
Integrationsarchitekturen
4-26
Busarchitektur / CORBA
ƒ Hello Client
à Holt Verweis auf ein Hello Server Objekt
à Ruft Methode sayHello() auf
ƒ Hello Server
à Implementierung sayHello(), um „Hello World“ an
Client zurückzugeben
Integrationsarchitekturen
4-27
CORBA / Arbeitsschritte
1.
Spezifikation des zu implementierenden Dienstes
schreiben (CORBA IDL)
2. Für Client / Server die CORBA Stummel und
Skelette erzeugen
3. Server Skelett ausfüllen (HelloServant)
4. Server Objekte beim ORB registrieren
(HelloServer)
5. Client Klasse implementieren, die Server Objekte
verwendet (Hello Client)
6. ORB starten, HelloServer starten, HelloClient
starten
Graue Teile nur notwendig, wenn CORBA Dienst auch
implementiert werden soll
Integrationsarchitekturen
4-28
CORBA / 1. Schritt Dienst spezifizieren
Namespace /
Package
Analog
Java Interface
module HelloApp {
interface Hello {
string sayHello();
};
};
Hello.idl
ƒ Syntax IDL ähnlich C++
à elementare Datentypen wie string
à enum, typedef, struct, union
à interface: Klasse mit Methodendekl.
- attribute: Deklariert Attribut via getter und setter
Methode
Integrationsarchitekturen
4-29
CORBA / 2. Java Klassen erzeugen
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
idlj erzeugt fünf Dateien (bis JDK 1.4, ab 1.5 andere)
_HelloImplBase.java
à Abstrakte Klasse, die das serverseitiges Gerüst (Skelett) für den
CORBA Dienst bereitstellt. Die Klasse HelloServant.java muss die
fehlenden Methoden implementieren.
_HelloStub.java
à Stummel (Stub) für Client-seitige Hello.java Implementierung
(Proxy für ServeR)
HelloOperations.java
à Java Interface mit den Methoden von von interface Hello
Hello.java
à Java Interface für das IDL interface Hello
HelloHelper.java
à Enthält Hilfsfunktionen, z.B. Casten der CORBA Objektreferenzen
zu den richtigen Java Typen
HelloHolder.java
à Enthält eine Instanz vom Typ Hello. Stellt Operationen für out und
inout Parameter zur Verfügung (nicht so leicht habbildbar wie in
C++)
Integrationsarchitekturen
4-30
CORBA / 2. Java Klassen erzeugen
Kommandozeile:
idlj -fall -oldImplBase Hello.idl
Erzeugt auch Server Skelette
PATH Variablen muss
<project default="compile-idl"> <java_installatin>/bin enthalten
<target name="compile-idl">
<exec executable="idlj">
<arg value="-fall"/>
<arg value="-oldImplBase"/>
<arg value="Hello.idl"/>
</exec>
</target>
</project>
Ant Skript zum Erzeugen
der Java Klassen aus der IDL
Integrationsarchitekturen
4-31
CORBA / 3. Server Gerüst ausfüllen
public class HelloServant extends _HelloImplBase {
public String sayHello() {
System.out.println("sayHello aufgerufen");
return "Hello";
}
}
ƒ Alle abstrakten Methoden von _HelloImplBase implementieren
Integrationsarchitekturen
4-32
CORBA / 4. HelloServant registrieren
ORB orb = ORB.init(args, null);
HelloServant helloRef = new HelloServant();
orb.connect(helloRef);
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef =NamingContextHelper.narrow(objRef);
NameComponent nc = new NameComponent("Hello", "");
NameComponent path[] = {nc};
ncRef.rebind(path, helloRef);
// Wait for invocations from clients
java.lang.Object sync = new java.lang.Object();
synchronized(sync){
sync.wait();
In main von HelloServer.java
}
ƒ
HelloServant ausführen
à
à
ORB Singleton der JVM wird erzeugt (orbd muss vorher gestartet werden)
Objekt registriert
Integrationsarchitekturen
4-33
CORBA / 5. Client Programm erstellen
public class HelloClient {
try {
ORB orb = ORB.init(args, null);
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
NameComponent nc = new NameComponent("Hello", "");
NameComponent path[] = {nc};
Hello helloRef = HelloHelper.narrow(ncRef.resolve(path));
String hello = helloRef.sayHello();
System.out.println(hello);
} catch(Exception e) {
System.out.println("ERROR : " + e);
e.printStackTrace(System.out);
}
}
Integrationsarchitekturen
4-34
CORBA / 6. Schritt
ƒ ORB von Java starten
à orbd.exe
ƒ HelloServer starten
à Verbindet sich mit ORB (auf gleicher Maschine)
ƒ HelloClient starten
à Verbindet sich mit ORB (auf gleicher Maschine)
à Ruft sayHello() von HelloServer auf
ƒ ORB orb = ORB.init(args, null);
à Kann mit Argumenten so konfiguriert werden, dass ORB auf
separaten Rechner ausgeführt wird
à Kann so konfiguriert werden, das nicht Java ORB, sondern
ein anderer verwendet wird
à HelloServer, HelloClient ebenfalls auf anderen Rechnern
Integrationsarchitekturen
4-35
Busarchitektur
ƒ CORBA, MQ sind unvermeidlich
Busarchitekturen
ƒ Mit folgenden Technologien können
Busarchitekturen gebaut werden
à Web Services, wenn
Dienstregistrierungsmechanismen verwendet
werden
à FTP für Nachrichtenaustausch über Dateiserver
(Server IP für Adressierung, Dateiverzeichnis für
„Queue“), Authentisierung User/Password
à HTTP mit URL für Adressierung, HTTP
Authentisierung
à Letzten drei ohne Transaktionen
Integrationsarchitekturen
4-36
Busarchitekturen und EAI?
EAI soll folgendes Problem lösen (siehe ersten Folien)
2.
Wege suchen, alte Anwendung weiter zu verwenden, statt sie
zu ersetzen
ƒ
ƒ
EAI Produkte und Methoden einsetzten, um Technologie Hürden
zu überwinden
Alte Anwendung schrittweise modernisieren
Internetbanking
?
Geldautomaten
Alte
Banklösung
ƒAnwendungsfelder EAI
àMulti-Channel-Architekturen
àApplikation-zu-Applikation Kommunikation
àGeschäftsprozessintegration
Integrationsarchitekturen
4-37
Busarchitekturen und EAI?
Lösung
ƒ
à
à
à
-
Busarchitektur als Middleware wählen
Genau eine Bus Technologie verwenden
Auswahl Bus Technologie:
Diejenige, die an die die meisten Anwendungen gekoppelt
werden können (Aufrufparadigma, Technische Anbindung,
Know-how in der Firma, usw.)
Internetbanking
Geldautomaten
BUS
Integrationsarchitekturen
Alte
Banklösung
4-38
Busarchitekturen und EAI?
Realität in grossen Firmen
ƒ
à
à
Mehr als eine Middleware für Integration (Swisscom: MQ,
CORBA, Web Services, COM+, EJB, …) im Einsatz
Ursprüngliche Integrations-Problem nicht (mehr) gelöst
Neues Problem
ƒ
à
Integration über verschiedene Middleware nötig
ƒAnwendungsfelder EAI für Bus-Technologie
àMulti-Channel-Architekturen
àApplikation-zu-Applikation Kommunikation
ƒKein Anwendungsfeld für
àGeschäftsprozessintegration
Integrationsarchitekturen
4-39
CORBA
ƒ Übung
à ServiceLocator für HelloServant
implementieren
à BusinessDelegate, um alle CORBA
Exceptions „loszuwerden“ und die
Funktionen des HelloServant Proxy zu
kapseln sowie Java Namenskonventionen
zu beachten
à Beispiele am PC ausprobieren
Integrationsarchitekturen
4-40
Inhalt
ƒ Busarchitekturen
à Allgemein
à Message Queue
à CORBA
ƒ Hub and Spoke
ƒ Dienst-orientiert (SOA)
Integrationsarchitekturen
4-41
Hub and Spoke
ƒ Busarchitektur
à Infrastruktur für Datentransport (Methodenaufrufe)
zwischen beteiligten Systemen
à Bus hat höchstens rein technische
Funktionalitäten
- Lastausgleich, Transaktionen, Authentisierung, …
ƒ Funktionale Integrationsprobleme können mit
Busarchitektur nicht direkt gelöst werden
à Inkompatible Datenformate
à Routing von Nachrichten in Abhängigkeit des
Inhalts
à Unterschiedliches Verteilen von Nachrichten
hinsichtlich Verarbeitungsstatus (Workflow)
Integrationsarchitekturen
4-42
Hub and Spoke
ƒ
ƒ
Begriff aus Transportwesen
à
à
à
Hub (Nabe), Spoke (Speiche)
Sternförmige Anordnung von Wegen statt Punkt-zu-Punkt Verbindungen
Grund: Kostenersparnis in der Logistik
à
à
Hub: Zentraler internationaler Flughafen
Spoke: Fluglinie von dezentralen Flughafen zu einem zentralen Flughafen
Flugverkehr (einer Fluggesellschaft)
Punkt-zu-Punkt
Sternförmig
Flughafen
Frankfurt
Paderborn/
Lippstadt
Baden
Airport
Bern
Integrationsarchitekturen
4-43
Hub and Spoke
ƒ Belieferung von Supermärkten
à Oft direkt von Hersteller zum Supermarkt
à Wal Mart
- Zentrallager beliefert von Hersteller
- Supermärkte von Zentrallager beliefert
Wal Mart
Ettlingen
Barilla
Zentrallager
Wal Mart
KA
Nestle
Wal Mart
Landau
Integrationsarchitekturen
4-44
Hub and Spoke
ƒ Andere Beispiele
à SNCF
- Hub: Paris
- Spokes: Bahnhöfe anderer Großstädte
à Post
- Hub: zentrales Frachtzentrum
- Spokes: regionalen Poststellen
à Netzwerktopologie
- Hub: Switch, Router
- Spokes: Netzknoten (Netzwerkkarte eines Rechners)
à Telekommunikation
- Hub: Vermittlungsanlagen
- Spokes: Endgeräte
Integrationsarchitekturen
4-45
Unterschied Hub and Spoke – Bus?
Integrationsarchitekturen
4-46
Hub and Spoke
ƒ EAI
à Hub: zentrale Integrationsplattform
à Spokes: zu integrierenden Applikationen / Middleware
ƒ Haupteinsatz
à Technologieüberbrückung
à Workflow, Geschäftsprozess Integration
CRM
System
ERP
System
Webshop
CMS
Hub
MQ
CORBA
Integrationsarchitekturen
4-47
Hub and Spoke
ƒ Hub and Spoke Funktionalitäten
à Überwachung des Datenverkehrs (Logging, Monitoring)
à Trennung von technischer Anbindung (Konnektoren) von
Geschäftsregeln
à Zentrale Abbildung der Geschäftsregeln / Workflows
à Oft visuelle Werkzeuge für Abbildung unterschiedlicher
Datenformate und Definition der Workflows
ƒ Gefahr von Flaschenhals größer als bei Bussystemen
Hub
Geschäftsregeln
Monitoring
Konnektoren
Konvertierungsregeln
/ internes
Format
Systeme
MQ
A
CORBA
B
Integrationsarchitekturen
4-48
Hub and Spoke / Beispiel MS BizTalk
ƒ BizTalk Server 2004
ƒ Angestrebtes internes Format
à XML Schema für Dokumentbeschreibung
à XSLT für Transformationen
ƒ Grafische Editoren
à Definition von Geschäftsregeln
à XML Schema
à XSLT Transformationen
ƒ Werkzeuge eingebettet in Visual Studio .NET
[BizTalk Server 2004 Architecture, White Paper (von BizTalk
Server Home Page)]
Integrationsarchitekturen
4-49
Hub and Spoke / Beispiel MS BizTalk
ƒ Abbildung zwischen zwei XML Formaten (XSLT
dahinter)
ƒ Unabhängig davon wie und womit Daten geliefert
wurden
Integrationsarchitekturen
4-50
Hub and Spoke / Beispiel MS BizTalk
ƒ Workflow Definition
à Aktivitäten (ein Transformation) als Knoten
Integrationsarchitekturen
4-51
Hub and Spoke / Beispiel MS BizTalk
ƒ BizTalk Server
à Gut geeignet wenn Daten in XML vorliegen
à Web Services, XML Datentransport, Konnektor zu
Herstellerprodukt (z.B. SAP R/3, Datenbank) oder Produkt
zur Konvertierung der Daten (CORBA zu XML, wenn es so
etwas gibt)
à Ansonsten: Transformation mit .NET programmieren.
ƒ Vorteil Hub and Spoke
à Bei vielen einfachen Integrationsproblemen keine
Programmierung notwendig
à Zentrale Geschäftsregeln zur Steuerung der Prozesse
à Zentrale Überwachung
Integrationsarchitekturen
4-52
Hub and Spoke / Andere Hersteller
ƒ IBM
à WebSphere Business Integration Server
à Analoge Funktionalität
à Integration mit WSAD (analog zu Visual Studio .NET), siehe
nächste Folie
à Basiert auf IBM WebSphere Application Server (J2EE
Server)
ƒ Tipco
à ActiveEnterprise
ƒ Vitria
à BusinessWare
ƒ Trend
à Keine reiner Middleware mehr, sonder zusätzlichen
Integrationsprodukten
Integrationsarchitekturen
4-53
[ WebSphere Business Integration, Server Foundation V5.1, Handbook ]
Integrationsarchitekturen
4-54
Inhalt
ƒ Busarchitekturen
à Allgemein
à Message Queue
à CORBA
ƒ Hub and Spoke
ƒ Dienst-orientiert (SOA)
Integrationsarchitekturen
4-55
Dienst-orientierte Architektur
ƒ Service oriented architecture (SOA)
ƒ Dienst
à Sammlung zusammengehöriger Geschäftsfunktionen
à Umfang ein oder mehrere Anwendungsfälle
ƒ Beispiel
à Kundendienst: Kunden suchen, anlegen, ändern,
Informationen über Kunden abfragen (Adressen, offene
Rechnungen, usw.)
à Produktdienst: Produkte suchen, in Warenkorb legen,
bestellen
ƒ Hauptpfeiler der Architektur
à Dienstverzeichnis (Welche Dienste gibt es?)
à Dienstimplementierung (Wo befindet sich der Dienst?)
à Dienstbeschreibung (Wie kann ein Dienst benutzt werden?)
Integrationsarchitekturen
4-56
Dienst-orientierte Architektur
Abstrakte logische Architektur
Dienstnehmer
(Client)
3. Dienst
verwenden
2. Dienst
suchen
Dienstimplementierung
1. Dienst(beschreibung)
registrieren
Dienstverzeichnis
Dienst
beschreibung
Integrationsarchitekturen
4-57
Dienst-orientierte Architektur
ƒ Technische Implementierungen
à CORBA
- IDL (Interface Definition Language): Dienstbeschreibung
- ORB (Object Request Broker): Dienstverzeichnis
à Web Services
- WSDL (Web Service Description Language):
Dienstbeschreibung
- UDDI (Universal Description, Discovery and Integration):
Dienstverzeichnis
ƒ Unterschiede
à ORB vermittelt immer auch die Dienstimplementierung, CORBA
praktisch auf Intranet beschränkt, nur synchrone Aufrufe, objektorientiert, IDL lesbar
à Suche von Diensten bei Web Services mächtiger (z.B.
Mehrsprachigkeit), Web Services für WWW entworfen, synchrone
und asynchrone Aufrufe, nicht objekt-orientiert, WSDL unleserlich
Integrationsarchitekturen
4-58
WSDL (Typen)
<types>
<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema
targetNamespace=http://greath.example.com/2004/schemas/resSvc.xsd
xmlns="http://greath.example.com/2004/schemas/resSvc.xsd">
<xs:element name="checkAvailability" type="tCheckAvailability"/>
<xs:complexType name="tCheckAvailability">
<xs:sequence>
<xs:element name="checkInDate" type="xs:date"/>
<xs:element name="checkOutDate" type="xs:date"/>
<xs:element name="roomType" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:element name="checkAvailabilityResponse" type="xs:double"/>
<xs:element name="invalidDataError" type="xs:string"/>
</xs:schema>
</types>
Integrationsarchitekturen
4-59
WSDL (Dienst)
<interface name = "reservationInterface" >
<fault name = "invalidDataFault" element = "ghns:invalidDataError"/>
<operation name="opCheckAvailability“
pattern="http://www.w3.org/2004/03/wsdl/in-out" >
<input messageLabel="In" element="ghns:checkAvailability" />
<output messageLabel="Out" element="ghns:checkAvailabilityResponse" />
<outfault ref="tns:invalidDataFault" messageLabel="Out"/>
</operation>
</interface>
Integrationsarchitekturen
4-60
Dienst-orientierte Architektur
ƒ
ƒ
Web Services (Microsoft, jetzt W3C + OASIS + andere)
Ursprüngliche Idee: B2B Integration über WWW:
à
à
à
à
ƒ
Heute
à
à
ƒ
Elektronhandwerksbetrieb sucht „besten“ Anbieter für Kabel und bestellt wie
Web Services oder Prüfen und Abbuchen von Kreditkarten
Dienstverzeichnis-Anbieter kommerziell (Firma gegründet)
Kommunikationstechnologie basierend auf Standards des WWW wie XML,
HTTP entwickeln
Kooperation mit IBM und andere Firma (ex. nicht mehr), Erfolgreiche
Vermarktung seitens MS mit .NET
Web Services löst COM+ ab, wird bei .NET als zentraler RPC
Mechanismus verwendet
Seit J2EE 1.4 Web Services Teil von Servlet + EJB Spezifikation
Schwächen bisher
à
à
à
à
Im Gegensatz zu, z.B. CORBA noch nicht ausgereift (OO Merkmale fehlen
im Standard, sind in .NET auf bestimmte Weise implementiert)
Keine Standards für Transaktionen
Dienste werden in der Praxis nicht spezifiziert (wie bei CORBA notwendig),
sondern implementiert, WSDL wird aus Implementierung generiert: Folge
höhere Inkompatibilität zwischen unterschiedlichen Plattformen
Zu viele verschiedene Standardisierungsorganisationen (statt nur einer)
Integrationsarchitekturen
4-61
Dienst-orientierte Architektur
ƒ SOA und EAI
ƒ Applikation zu Applikation Integration
à Wie bei anderen Kommunikationstechnologien
à Vorteil: Eine Standardkommunikationstechnologie
ƒ Integration Geschäftsprozesse
à Zusätzlich mit Hub and Spoke bei Web Services + MQ
(wenn alles auf XML basiert)
ƒ Eigentlicher Nutzen einer SOA
à Unternehmen muss seine Dienste logisch ordnen, benennen
und zugänglich machen: Wenn dies nicht gelingt, scheitert
Versuch EAI mit SOA
à Technologische Implementierung nebensächlich (könnte
auch COM+ oder EJB sein, wichtig ist ein allgemeiner
Standard)
Integrationsarchitekturen
4-62
Architekturen
ƒ Tendenz
à Nachrichten-orientierte Architekturen (MQ) setzen
sich als Transportmedium durch
à Hub and Spoke immer öfter in Unternehmen zur
Steuerung der Prozesse eingesetzt
à Web Services „in“ (mit noch geringer Verbreitung
in Mitteleuropa)
ƒ Bei allen XML als Basis
Integrationsarchitekturen
4-63