Schnittstellen: Das A&O für Enterprise Application Integration

Transkript

1 Schnittstellen: Das A&O für Enterprise Application Integration Andres Koch dipl. El. Ing. HTL / M. Math Object Engineering GmbH, Uitikon-Waldegg, Schweiz akoch@objeng.ch Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 1/35 Schnittstellen: Das A&O für Enterprise Application Integration Einleitung Architektur Kommunikation Middleware Schnittstellen Praxis-Beispiele Zusammenfassung Inhalt Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 2/35

2 Enterprise Application Integration Einführung An erster Stelle steht die IT-Architektur inklusive Organisation, Normierung und der Festlegung der zu verwendenden Technologien. Der Blueprint der Fahrtwege und Anschlüsse ist vorrangig. EAI-Blueprint ist vergleichbar mit dem unternehmensweiten Datenmodell! Mit jeder neuen Technologie-Welle (Hype) ändert nur das Rollmaterial und eventuell die Fahrgeschwindigkeit. Somit steht die Technologie an zweiter Stelle Technologien sollten auf Industriestandards basieren und nicht proprietären Tools folgen. Sich auf die Technologie zu konzentrieren birgt Risiken, welche später teuer zu stehen kommen. EAI und Legacy gehen Hand in Hand (typisch für Hostanwendungen). Integration von bestehenden Anwendungen als WEBs erfordert ebenso EAI-Disziplin. Also viel Organisation und eine harte Doktrin ist nötig, wenn auch Pragmatik nicht fehlen darf. Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 3/35 Architektur: Unerwünschte EAI-Architektur A A-D Interface D B-D Interface A-B Interface A-C Interface C-D Interface B B-C Interface C Eine individuelle Schnittstelle zwischen jedem spaar ist unerwünscht und aufwendig. Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 4/35

3 Architektur: Generelle Bus -Architektur Allgemeine Struktur Adapter LU6.2 Adapter CORBA Individuelle Struktur EAI-Kommunikations-Middleware z.b XML Adapter JMS Naming Sockets Adapter Gemeinsame Komponenten so gut wie möglich generisch halten. Meldungsstrukturen normieren (Standard-Header, Individueller Body) Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 5/35 Architektur: Multi-Tier-Architektur Clients / Browser B2B WEB-Kommunikations-Layer (http) WEB WEB SOAP Controllers EAI-Kommunikations-Middleware Backend Applications Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 6/35

4 Kommunikation: Drei Ebenen OSI-Layer Application A Protocol Application B 7 Application & s Application Protocol Application & s 6 5 End to End Data Exchange Facility Programm Protocol End to End Data Exchange Facility Transport Provider Transport Protocol Transport Provider Physical Network Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 7/35 Kommunikation: (A2A) Application to Application Application Application s Data Exchange Facility Transport Provider Application Application s Data Exchange Facility Transport Provider Network Facility Data Exchange Facility Conversational RPC s SNA APPC OSI Sockets CORBA/IIOP SUN/ONC JMS MQSeries Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 8/35

5 Kommunikation: asynchron oder synchron? gross komplex Systemgrösse und Komplexität Aktivitätsdauer Peer-to-Peer Client/Server ASYNCHRON klein einfach Hardware (CPU) SYNCHRON Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 9/35 Generell: Möglichst standardisierte Technologien benutzen Proprietäre Werkzeuge schränken ein Middleware: Überblick Es muss nicht immer das Neueste sein, Altbewährtes ist oft besser und nicht zu unterschätzen. Mögliche Varianten A2A: CORBA basierte Middleware: CORBA ist tot, es lebe CORBA CORBA (IIOP): Sprachen-, System- und Hersteller-übergreifend (Interoperabilität) JMS-basierte Systeme basieren auf verschiedenen Messaging-Systemen, sind aber ohne dazutun auf Java beschränkt. Socket-Kommunikation funktioniert fast immer, ist aber sehr low level. Mögliche Varianten B2B: SOAP (HTTP basiert) SMTP nicht unterschätzen wenn verschlüsselte Meldungen verwendet werden. Meldungsstrukturen auf XML fördern die Flexibilität aber im schlechten Fall auch das Normierungs-Kopfweh Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 10/35

6 Middleware: CORBA s Object Request Broker IIOP* NETZ register Server s aktivieren Object Operation ansprechen IIOP Object Request Broker Schnittstellen in IDL definiert Clients IOR verlangen Operation ansprechen *IIOP ab CORBA 2.0 Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 11/35 Middleware: Messaging Process Queue Queue Process Recliner 1 Queue Process Queue Routing Manager Communication Network Routing Manager Queue Rechner 2 Rechner n Queue Routing Manager Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 12/35

7 Middleware: JMS-Architektur JMS Application Client (Java) JMS API JNDI JMS Provider Client Lib JMS Application Client (Java) JMS API JNDI JMS Provider Client Lib Communication Network JMS Provider z.b. IBus, MQ/Series.. Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 13/35 Middleware: Simple Object Access Protocol XML Consumer SOAP Interface Application SOAP http TCP/IP s oder RPC B2B Server SOAP Interface Appl Stark im Trend Speziell für Business to Business Kommunikation Kommunikation quasi normiert, Meldungstrukturen sind frei Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 14/35

8 Middleware: WebServer, Servlets und EAI Clients / Browser WebServer (z.b. Apache) JDBC-Zugriff SQL/DB RMI/IIOP RMI- HMTL Pages Java Servlets CORBA/IIOP CORBA- JMS- Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 15/35 Schnittstellen: Generell Programm to an interface, not an implementation (Gamma etal) Architektur und Schnittstellen gehören zusammen. Verteilte en benötigen Schnittstellen Schnittstellen tendieren in der Regel komplex zu werden. Oft wird über die Technologie (u.a) mehr diskutiert, als über das Design von Schnittstellen nachgedacht wird. Das Design von Schnittstellen von Anwendungen haben oft Mängel, welche sich erst nach geraumer Zeit zeigen. CORBA-IDL anzuwenden und daraus Client und Serverseite zu implementieren ist einfaches Handwerk. Verifikation von Schnittstellen ist wichtig und spart später unnötigen Aufwand. Changemanagement gehört zur grossen Herausforderung für verteilte Systeme und somit für EAI. Schnittstellen-Aenderung wirken sich praktisch immer auf Client- und - Seite aus. Schnittstellen welche die Implementation zeigen, werden zum Pferdefuss beim weiteren Ausbau Das Erfolgsrezept bei Schnittstellen liegt in Einfachheit Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 16/35

9 Schnittstellen zwischen en A B Schnittstelle s-protokoll (7) Middleware-Protokoll (5,6) Schnittstelle s-meldungen Middleware-Protokoll ist weitgehend normiert (IIOP, JMS u.a.) Das s-protokoll ist aber frei definierbar und erfordert individuelle Anpassungen. smeldungen in XML verhindern häufige Anpassung der Schnittstelle. Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 17/35 Schnittstellen: Entwurf Den Schnittstellen von Modulen sollte in der Entwurfsphase genügend Aufmerksamkeit und Sorgfalt gewidmet werden. Eine Schnittstelle, die während der Entwurfsphase ändert, ist vertretbar, dies nach deren Inbetriebnahme zu tun kann fatal sein. Schnittstellen dürfen nur erweitert werden, dass eine Aufwärtskompatibilität sichergestellt ist. Meldungsformate entsprechen den Schnittstellen im meldungsorientierten Paradigma (Formate in XML) Prozedur-, Funktions- oder Methoden-Aufrufe einer Komponente entsprechen den Schnittstellen im objektorientierten oder prozeduralen Paradigma (RPC). Die Abfolge der Benutzung der Schnittstellen entspricht dem Protokoll auf höherer Ebene (s-protokoll). Mit der CORBA-Interface Definition Language (CORBA-IDL) Schnittstellen können definiert werden, die unabhängig von der in der Implementation verwendeten Programmier-Sprache ist. Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 18/35

10 Wenige Schnittstellen Schnittstellen: Meyer s Entwurfs-Kriterien Jedes Modul sollte mit möglichst wenigen andern Modulen kommunizieren. Beschränkte Gesamtzahl der Kommunikations-Kanäle zwischen Modulen: Anzahl der Operationen (in interfaces) in Grenzen halten Schmale Schnittstellen (Lose Kopplung) Wenn zwei Module überhaupt kommunizieren, sollten sie so wenig Information wie möglich austauschen. Anzahl der Parameter der Operationen beschränken (<=5) Ref: Bertrand Meyer Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 19/35 Beim Erstellen Schnittstelle so generisch wie möglich halten Schnittstellen: Changemanagement Keine zu hohe Granularität wählen (Netzwerkzugriff) Nur den unmittelbaren und bekannten Bedarf abdecken. (If-Use Cases) Spätere Erweiterungen ist leichter möglich Einfachheit ist auch hier der Schlüssel zum Erfolg. Beim Aendern & Erweitern Wenn eine Schnittstelle erweitert wird, dann: neue Strukturen einfügen, statt bestehende ändern neue Operationen, statt bestehende ändern durch Vererbung erweitern, damit bestehende Schnittstellen beibehalten werden können Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 20/35

11 Schnittstellen: Flexibilität vs. Performance Performance Flexibilität und Performance schliessen sich fast gegenseitig aus Man braucht beides und muss optimieren Netzwerk-Calls müssen berücksichtigt werden für Performance Verarbeitungszeit muss berücksichtigt werden (Millionen von Elementen) Kardinalität in den Dutzenden kann vernachlässigt werden, aber im Bereich von Tausenden oder Millionen wird ihr System ruiniert. Flexibilität Verwendung von NamedValue oder XML-Strukturen Unbegrenzte Listen (sequences in CORBA-IDL) Schnittstellen Trennung nach Bereich Mischen zwischen schnellen und flexiblen Mechanismen XML kombiniert mit CORBA für die Zukunft als flexible Lösung Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 21/35 Schnittstellen: IDL-Schnittstelle die IDeaLe Schnittstelle Die Schnittstelle wird einmal definiert genau einmal und ändert während des ganzen Lebenszyklus des Systems nie mehr dies entspricht nicht der Realität und ist nicht voraussehbar. Einfluss einer Schnittstellen-Veränderung Regel: Client und Server müssen in der Regel beide mit der neuen IDL-Definitionen neu erstellt (generiert, konstruiert, built ) werden (Build-Time Effect) Entweder Client oder Server muss nicht neu erstellt werden (Runtime-Effect) Wenn immer Sie eine ausgebreitete Schnittstellen-Definition ändern, denken Sie an die Möglichkeit, dass irgendwo da draussen ein (oder viele) Client- mit einer älteren Version existiert und operativ ist. Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 22/35

12 Praxis: s-integration en migrieren Schnittstellen bilden Komponenten vermitteln und nutzen Komponenten verbinden Komponenten neu bilden EAI-Kommunikations-Bus Komponenten verbinden Wrapping ist sowohl für Legacy-Migration wie auch für EAI ein bewährtes Prinzip. Ideen, Kreativität und Pragmatik ist hier gefragt. Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 23/35 Praxis: Wrapping Schnittstelle zum ORB via externe C++ - Prozeduren Konvertierte Legacy- Aufruf von Proceduren Schnittstellenteil zu externen Prozeduren Aufruf der von externen Funktionen Aufruf von Funktionen der von aussen Object Request Broker s in gleicher oder anderen Sprachen s Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 24/35

13 Praxis: EAI als Teil von Legacy-Ablösung Mainframe (MVS/IMS) WAN TCP/IP SNA/LU0 (tunneled) Virtuelle S/1 Maschine DI 2.0 Asynchron LAN TCP/IP PCs mit VT220 Emulation asynchron,telnet PCs mit Win 95 GUI-Frontend Dezentraler Server (RS6000 RISC, UNIX) CORBA Middleware (ORBIX) Terminalsubsysteme wurde durch PCs mit der üblichen graphischen Oberfläche abgelöst. Die Hostapplikation wurde durch eine CORBA-konforme Schnittstelle für beliebige en zugänglich gemacht. Terminals verschwinden nach der Einführungsphase des GUI Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 25/35 Praxis: EAI als Teil von Legacy-Ablösung Mainframe (MVS/IMS) WAN TCP/IP Dezentraler Server (RS6000 RISC, UNIX) LAN TCP/IP PCs mit Win/NT GUI-Frontend CORBA Middleware (ORBIX) DI V3.x CORBA Middleware (ORBIX) Schnittstelle zu den Client-PCs identisch mit vorangehender Phase CORBA als Middleware bis hinauf zum Mainframe mit hoher Performanceverbesserung Assembler- und PL/1-Programme auf Zwischenserver eliminiert Host-Transaktionsprogramme bleiben weitgehend unverändert. Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 26/35

14 Praxis: EAI als Teil von Legacy-Ablösung Desktop (PC/Windows/95) s Frontend MFC-Framework (MS VC++) DIF/ORB-Client CORBA-Middleware Logische Schnittstelle nach aussen. Fremdapplikation DI Datainterface- Navigation Tables TCP/IP tunneled SNA/LU0 SNA/LU0 ROUTER UNIX-IPC-Queue Virtual Series/1+RPS Handler HIM TAM TIM LOG APM1 APM2 Meldungs* Repository RS6000/AIX Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 27/35 Praxis: EAI als Teil von Legacy-Ablösung Desktop (PC/WinNT) Applications Frontend MFC-Framework (MS VC++) DIF/ORB-Client CORBA-Middleware Logical interface to the outside Fremdapplikation Navigation Tables IBM 93xx / MVS OE IMS IMS Gateway (CORBA-) CORBA-Middleware DI Datainterface- V3.x Transactioncontrol Tables RS6000/AIX Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 28/35

15 Praxis: B2B über Internet Internet-Benuzter Mobile-Benutzer Standort: Zürich WEBServer SW-Haus OE INTERNET Commerce Agent SkiData Gateway SMS Gateway Diagnostic Standort: Zürich CORBA (IIOP) Standort: Luzern WEBServer Skigate-Controll SW SkiData Agent Standort: Graubünden Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 29/35 Praxis: EAI- Extremfall PL/1- Structure Files IIOP Development& Test Environment PL1Conv System Test Environment or Deployment VTRCompiler Code Source IIOP VTRAdmin Developer IIOP Structure Info Structure Info Source & Code IIOP MSRepository IIOP Context (Persistence) * Code-Export für Produktion Code VTRCode Code während Testphase IMSCom DITCore VTREngine RS6000 / AIX IDL Java C++ IIOP APP-GUI Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 30/35

16 Praxis: Migration von Schnittstellen Client_1 Client_2 Client_3 IFAB_Proxy entfällt nach Übergangszeit IF_A IF_B GenericAB_IF Diagnostic AB_Adapter IF_A (old) A_ imsraw IMSGateway (Orbix) IF_B (old) B- IMS Zusammenführung alter Schnittstellen und Migration auf eine generische Schnittstelle (Notaktion zur Bewältigung alter Design-Sünden) Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 31/35 Praxis: Diagnose zur Laufzeit OUDiagnostic User Interface Client Client TCP/IP-IIOP AppIF a1 AppIF a2 DIAGIF AppIF b1 AppIF b1 DIAGIF AppIF c1 AppIF c1 DIAGIF Application A Application B Application C Jede hat identische Diagnostik-Schnittstelle. Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 32/35

17 Zusammenfassung Schnittstellen sind in der Realisation (ausprogrammiert) um Faktoren komplexer, als es die Schnittstellen-Definition erkennen lässt. Schnittstellen-Design muss durch die Architektur vorgegeben sein. Auch wenn CORBA-IDL-Sprache sehr umfangreich ist, muss man trotzdem nicht alle Möglichkeiten davon nützen (Weniger ist oft mehr). Performance wiedersetzt sich in der Regel Flexibilität Nachträgliches Ändern von Schnittstellen, kann zu broken Code führen. Aufteilen und Vererben von Schnittstellen bringt Design-Flexibilität. Generische Schnittstellen erfordern teils aufwendige Interpretationen auf Client wie -Seite bieten aber Flexibilität. XML kann wesentlich zur Flexibilität beitragen š Paradigma Die IDeaLe Schnittstelle existiert nicht, kann aber angestrebt werden. Diagnose zur Laufzeit ist ein sehr wichtiger Aspekt für den Betrieb von verteilten en. Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 33/35 Schlussfolgerung EAI hat in erster Linie mit IT-Architektur und Organisation und erst an zweiter Stelle mit Technologie zu tun. Architektur aus einer Hand erweist sich als vorteilhaft Gutes Teamwork und gute Kommunikation auf menschlicher Ebene ist für den Erfolg von EAI-Projekten unabdingbar. Technologie ersetzt auch bei EAI weder den guten Projektleiter noch den kreativen Software Ingenieur. EAI braucht etwas Mut, Kreativität und Pragmatik, ohne dabei Systematik und Professionalismus zu vergessen. EAI und IT-Architektur ist wie Qualitätssicherung ein fortwährender Prozess. Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 34/35

18 Schnittstellen: Das A&O für Enterprise Application Integration Fragen? Andres Koch dipl. El. Ing. HTL / M. Math Object Engineering GmbH, Uitikon-Waldegg, Schweiz akoch@objeng.ch Copyright 2002 by Object Engineering GmbH, 8142 Uitikon, Switzerland 35/35