Professionelle Softwareentwicklung und Aufbau komplexer IT-Systeme

Transkript

1 Grundlagen der Informatik Professionelle Softwareentwicklung und Aufbau komplexer IT-Systeme Prof. Dr.-Ing. Thomas Wiedemann HOCHSCHULE FÜR TECHNIK UND WIRTSCHAFT DRESDEN (FH) Fachbereich Informatik/Mathematik Gliederung Allgemeine Softwareentwicklung Aktueller Stand und Probleme Softwareentwicklungsmodelle Modellierung mit UML Aufbau und Administration komplexer IT-Systeme Einsatz von Web Services SOAP Service Orientierte Architekturen Das SOALution-Server-System für die Lehre Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 2 1

2 Allgemeine Situation bei der Softwareentwicklung Nach Statistiken (Quelle Gartner Group) sind im Durchschnitt: ca. 23 % aller Softwareprojekte erfolgreich, ca. 53 % aller Softwareprojekte über Budget und/oder über Zeit und ca. 24 % aller Softwareprojekte abgebrochen. Hauptprobleme: Softwareentwicklung stark geprägt von Fehleinschätzungen bezüglich Zeitbedarf, für die Projektorganisation, Kommunikation und die Programmierdauer selbst im Schnitt produziert ein Programmierer im längerfristigen Durchschnitt: LOC (Lines of Code) pro Arbeitstag laut [Mayr 2005] für Team-geeigneten, dokumentierten, zuverlässigen, test- und wartbaren Code Es gilt folgende Näherungsformel für die optimale Teamgröße: OptimaleMitarbeiterZahl = Wurzel aus ( ProjektdauerInPersonenMonaten ) Bei einem Projekt von 16 Personenmonate, wäre die optimale Teamgröße 4 Personen. Unter diesem Gesichtspunkten ist die Qualitätssicherung und Organisation bei der Softwareentwicklung von entscheidender Bedeutung für den Erfolg! Historisch entstanden verschiedene Modelle zur Organisation der Softwareentwicklung, welche nachfolgend kurz vorgestellt werden sollen... Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 3 Wichtige Software - Qualitätsmerkmale Funktionalität Software muß korrekt und angemessen arbeiten Zuverlässigkeit Software darf nicht so sehr versagen, dass physische oder grosse ökonomische Schäden verursacht werden. Wartbarkeit Software muß anpaßbar an neue Anforderungen sein. Software sollte möglichst plattformunabhängig sein. Effizienz Software muß ökonomischen Gebrauch von Ressourcen des unterliegenden Systems machen. Portabilität Software muß möglichst auf andere Betriebssysteme und Betriebs-systemversionen übertragbar sein Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 4 2

3 Software Qualitätsmerkmale II Benutzerfreundlichkeit Software muß sich nach den Bedürfnissen der Benutzer richten. Die Benutzerschnittstelle muß ergonomisch sein - Anforderungen in der Norm EN ISO 9241 geregelt Aufgabenangemessenheit Selbstbeschreibungsfähigkeit Steuerbarkeit Erwartungskonformität Fehlertoleranz Individualisierbarkeit Lernförderlichkeit Dokumentation muß in allen Detaillierungsgraden ausreichend zur Verfügung stehen. Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 5 Softwareentwicklung nach dem Wasserfallmodell Beim Wasserfallmodell (von etwa 1970) werden iterativ die nachfolgenden Stufen durchlaufen. Der wesentliche Nachteil dieses Modells ist die lineare Struktur, welche nur einfache Rücksprünge erlaubt. Die Benennung der einzelnen Phasen hat sich generell durchgesetzt! Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 6 3

4 Softwareentwicklung mit dem Böhmschen Spiralmodell statt einfacher linearer Vorgehensweise mehrfache zyklische Wiederholungen mit ansteigendem Niveau durch frühe Prototypen geringere Gefahr von Fehlentwicklungen Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 7 Softwareentwicklung - Extreme Programing (XP) XP ist eine agile iterative Vorgehensweise mit leichtgewichtiger Methodologie und wenig Dokumentation und Overhead. User Stories: Die Anforderungen werden in User Stories erfasst. User Stories beschreiben GUIs, Funktionalitäten und Testszenarien. On-site Customer: Ein kompetenter Vertreter des Kunden ist während der gesamten Entwicklungszeit bei den Entwicklern anwesend (schwierig). Pair Programming: An den Entwicklungsrechnern sitzen jeweils zwei Entwickler und entwickeln gemeinsam. Testing: Vor der Entwicklung eines Moduls werden automatisierbare Testfälle (Unit Tests) programmiert. Simple Design: Es werden keine unnötigen Features implementiert. Small Releases: Es werden häufige Iterationen durchgeführt mit lauffähigen Programmen als Ergebnis, welche der Kunde begutachtet. Refactoring: Der Sourcecode wird eher früh restrukturiert. Continuous Integration: Von verschiedenen Teammitgliedern produzierter Code wird sehr häufig zusammengeführt. Collective Ownership: Der entwickelte Sourcecode gehört dem gesamten Team, jeder ist für jeden Code verantwortlich. Die Teams rotieren zyklisch. Coding Standards: Es werden Konventionen zum Aufbau des Codes erstellt, um Lesbarkeit zu erleichtern. Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 8 4

5 Softwareentwicklung mit XP Verfahrensweise beim Extreme Programming : Quelle: Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 9 OO-Modellierung mit UML -Unified Modeling Language UML (Unified Modeling Language) ist ein Standard der OMG ( UML ist keine Methode, sondern definiert eine Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die Geschäftsprozessmodellierung und für die objektorientierte Softwareentwicklung. Um UML erfolgreich zu nutzen, ist es notwendig eine passende Methode zu entwickeln, die die UML unterstützt. Die UML wird seit 1998 als Standard angesehen. Entwickelt wurde die UML von Grady Boch, Ivar Jacobsen und Jim Rumbaugh von RATIONAL ROSE SOFTWARE. Viele führende Unternehmen der Computerbranche (Microsoft, Oracle, Hewlett- Packard,...) wirkten aktiv an der Entwicklung mit und unterstützen die UML. Die Modellierung erfolgt mit 13 verschiedenen UML-Diagrammtypen. Es werden nachfolgend die wichtigsten Typen vorgestellt. Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 10 5

6 UML - Anwendungsfall- (Use-Case-) - Diagramm stellt die Beziehungen zwischen Akteuren und Anwendungsfällen dar. Es zeigt das äußerlich erkennbare Systemverhalten aus der Sicht eines Anwenders. Notation: Anwendungsfälle werden durch Ellipsen die den Namen des Anwendungsfalles tragen und einer Menge von beteiligten Objekten (Akteuren) dargestellt. Die Anwendungsfälle und Akteure (Strichmännchen) sind durch Linien miteinander verbunden. Die Systemgrenze wird durch einen Rahmen symbolisiert. Quelle: Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 11 UML Aktivitäts- (Activity) - Diagramm Aktivitätsdiagramme beschreiben Ablaufmöglichkeiten, die aus einzelnen Aktivitäten (Schritten) bestehen. Durch Zustandsübergänge (Transitionen) erfolgt die Aktivierung von Aktivitäten (jede Aktivität beginnt mit einer eingehenden Transition und hat eine oder mehrere ausgehende Transitionen.) Es sind Verzweigungen, Zusammenführung, Splittings (Fork -> Generierung paralleler Prozesse), Synchronisationen und Signalübermittlungen möglich. Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 12 6

7 UML - Sequenzdiagramm (Sequence Diagram) Sequenzdiagramme zeigen den genauen zeitlichen Ablauf einer Reihe von Nachrichten (Methodenaufrufen) zwischen bestimmten Objekten in einer zeitlich begrenzten Situation. Dabei kann auch das Erzeugen und Entfernen von Objekten enthalten sein. Die Zeitlinie verläuft senkrecht von oben nach unten, die Objekte werden durch senkrechte Lebenslinien beschrieben und die gesendeten Nachrichten waagerecht entsprechend ihres zeitlichen Auftretens eingetragen.. Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 13 UML - Klassendiagramm (Class Diagram) Das Klassendiagramm Diagramm beschreibt analog zur OO eine Menge von Objekten, in der die Eigenschaften (Attribute), Operationen und die Semantik der Objekte definiert werden. Mit speziellen Schlüsselwörtern können Meta- Klassen, Schnittstellen-Klassen und abstrakte Klassen dargestellt werden. << Metaklasse >> Klassenname Klassenname { abstrakt } grafische Darstellung der Vererbung die Eigenschaften der Oberklasse werden an die zugehörige Unterklasse vererbt. Quelle: Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 14 7

8 Anwendungsentwicklung auf der Basis von UML -> MDA MDA (Model Driven Architecture) ist ein Standard der OMG ( und definiert eine Vorgehensweise beim Softwareentwicklungsprozess unter Verwendung von UML. MDA basiert auf UML in der Version 2.0 (Unified Modeling Language) - veröffentlicht 2005 Die UML-Metadaten der OO-Modelle werden in Meta-Object Facilities gespeichert und können per XMI (XML Metadata Interchange) mit anderen UML- oder MDA-Tools ausgetauscht und erlaubt eine Automatisierung der Softwareerstellung. Die Modellierung der fachlichen Geschäftsprozesse ist von der Modellierung der technischen Realisierung getrennt. Die späte Wahl bzw. der spätere Wechsel der verwendeten technischen Plattform (z.b. Java EE,.NET) ist möglich. Bewährte Design Patterns, Best Practices und wiederverwendbare Komponenten werden unterstützt. MDA ist mit etablierten Entwicklungsprozessen und Vorgehensmodellen vereinbar (z.b. XP, RUP, Agile Modeling,..) Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 15 Softwareentwicklung mit Web Services Bisher existierende Browser-Technologien für Webanwendungen sind ausgerichtet auf Bedienung oder Anwendung durch Menschen die verwendeten Technologien und Protokolle können zwar prinzipiell auch durch Programme verwendet werden, dies erfordert jedoch einen relativ hohen Aufwand (Simulation eines Bedienvorganges -> Posten eines Formulars -> Extraktion der Ergebnisdaten aus der Ergebnis-HTML-Seite bei altem Problem der fehlenden Content- Kodierung von HTML-Inhalten) bereits vorhandene Technologien für verteilte Softwareanwendungen (CORBA / COM) haben (und werden) sich in der Breite NICHT durchsetzen können ein neuer Ansatz zur Realisierung verteilter Anwendungen erscheint notwendig Web Services als Überbegriff für webbasierte Informationsdienste Potentiale von Web Services : direkte Kopplung von Softwareanwendungen über Web Services erlaubt Datenaustausch über IT- und Firmengrenzen hinweg viele verteilte Informationsprozesse könnten besser automatisiert werden : Anfragen und Buchungen von Reisen (Hotels, Flugtickets, Mietwagen) Anfragen und Verhandeln von Angeboten und Bestellungen (drastische Rationalisierung im Einkauf möglich!!!) Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 16 8

9 Allgemeine Anforderungen an Web Services als Client treten Programme oder komplexe IT-Systeme auf Client-Applikation Internet Server Web Service Anforderungen (mit Hinweis zur aktuellen Lösung) 1. Vereinbarungen zum Transport der Daten (XML -> SOAP ) 2. Kodierung der Daten (XML -> SOAP ) 3. Protokoll zum Zugriff auf Web Service (HTTP -> SOAP ) 4. eindeutige Beschreibung eines Web Services (-> WSDL) 5. Firmenübergreifendes Suchen und Verwalten von Web Services (-> UDDI - siehe ) Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 17 SOAP Grundkonzeption SOAP steht für Simple Object Access Protocol ist zur Beschreibung von Eingangsdaten und Ergebnisdaten von Webservices und zur Übertragung derselben konzipiert basiert auf XML und kann mit XML-Werkzeugen generiert und analysiert werden Historie: erstmals vorgestellt 1999 Hauptinitiatoren: Microsoft, IBM, W3C aktuelle Version: 1.2 Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 18 9

10 SOAP Grundgerüst SOAP-Nachrichten bestehen aus einem Gesamtumschlag (Container) kodiert durch Tag <Envelope> den Kerninformationen im Tagbereich <Body> (muß existieren) Zusatzinformation in <Header> und Fehlernachrichten über Tag <Fault> Das resultierende SOAP-Grundgerüst : <message: Envelope xmlns: message= www. w3. org/ 2001/ 12/ soap- envelope message: encodingstyle= www. w3. org/ 2001/ 12/ soap- encoding > <message: Header>... </ message: Header> <message: Body> <message: Fault>... <message: Fault> </ message: Body> </ message: Envelope> Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 19 SOAP-Headerinformationen der SOAP-Header definiert Rahmenbedingungen und Verarbeitungshinweise das actor-attribut gibt einen Verarbeitungshinweis an (hier..checkin) Das mustunderstand-attribut definiert, ob der Partner den Tag kennen und verstehen (=verarbeiten) können muß <message: Header> <info: country xmlns: info= www. europa. org/ country/ > <info: id actor= www. europa. org/ country/ checkin/ > GE- NRW </ info: id> <info: language message: mustunderstand=" 1"> GE</ info: language> <info: currency message: mustunderstand=" 0"> EURO</ info: currency> </ message: Header> Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 20 10

11 SOAP-Body der SOAP-Body kodiert die eigentlichen Daten im Beispiel fragt der Client dem Server "Einhaendler" nach dem Preis eines Artikels als Namespace (=xmlns) wird der Namespace des Händlers verwendet <message: Body> <preis: PreisAuskunft xmlns: preis= http// www. einhaendler. de/ preise/ > <preis: Artikel> NOKIA 8210</ preis: Artikel> <preis: Artikel> SINUS 710K</ preis: Artikel> </ preis: PreisAuskunft> <message: Body> Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 21 SOAP-Antwort und Fehlerinformationen die Antwort wird ebenfalls wieder als XML-Nachricht kodiert Fehlerinformationen können als Code oder im Klartext (Problem Sprachabhängigkeit -> deshalb Sprachangabe bei Request) zurückgegeben werden <message: Body> <message: Body xmlns: response= http// preise/ > <response: PreisAuskunftAntwort > <response: Artikel> NOKIA 8210</response: Artikel> <response: Preis>239</response: Preis> </response: PreisAuskunftAntwort> <message: Fault> <faultcode> message: Artikel</faultcode> <faultstring> Unbekannter Artikel</faultstring> <detail> Der von ihnen angegebene Artikel SINUS 710K ist uns nicht bekannt </detail> </message: Fault> </message: Body> Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 22 11

12 Transport von SOAP-Nachrichten Übertragung von SOAP-Nachrichten über alle Internetprotokolle : am Häufigsten über http Port 80 (zur Umgehung von Firewalls) auch Versand über SMTP/POP3/IMAP FTP prinzipiell ebenfalls möglich (größere Dateien für Batchverarbeitung?) HTTP/ OK Connection: close Content- Type: application/ soap; charset= utf- 8 Date : Tue, 28 May : 28: 03 GMT <?xml version= 1.0?> <message: Envelope xmlns: message= www. w3. org/ 2001/ 12/ soap- envelope message: encodingstyle= www. w3. org/ 2001/ 12/ soapencoding > <message: Body xmlns: response= http// www. einhaendler. de/ preise/ > <response: PreisAuskunftAntwort > <response: Preis> 239</ response: Preis> </ response: PreisAuskunftAntwort>... </ message: Body> </ message: Envelope> Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 23 SOAP-Tools Standardimplementierung für Apache-Webserver mit : Apache oder Tomcat-Webserver XML-Parser Xerces (ebenfalls von Apache-Group) SOAP-Engine Axis : Java-Implementierung der W3C Empfehlung zu SOAP basierend auf Apache SOAP 3.0 (komplett überarbeitet mit höherer Perf.) unterstützt die Web Service Description Language (WSDL- siehe hinten) automat. Generierung von Java-Clients durch Verarbeitung der WSDL- Datei nicht nur Versendung über HTTP, sondern auch FTP etc. Weitere Tools von bekannten Herstellern, insbesondere Software AG mit Tamino XML-Datenbank IBM Websphere-Entwicklungsumgebung Microsoft -.NET-Framework mit SOAP-Modulen Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 24 12

13 SOAP-Bewertung Alle Vor- und Nachteile der XML-Basis : trotz großer Flexibilität noch relativ gut beherrschbar gut lesbar, aber relativ umfangreiche Dateien breites Angebot an XML-Werkzeugen (XML-DB, freie Parser) Gute Unterstützung durch die meisten Programmiersprachen (fertige Java- und C++-Bibliotheken) Noch offen sind Sicherheitsfragen (z.z. lösbar durch SSL oder andere Kryptografieprotokolle) Probleme der Zugriffsberechtigung (ebenfalls lösbar über bereits existierende Protokolle, z.b. https o.ä.) Ausblick: sehr gute Perspektive infolge breiter Unterstützung durch alle wichtigen IT-Firmen SOAP oder Nachfolgeprotokolle dürften zum Industriestandard werden Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 25 Beschreibung von Web-Services Verfügbare Web Services werden beschrieben durch die Web Service Description Language (WDSL) WSDL definiert : die Nachrichten, welche ausgetauscht werden, wie sie ausgetauscht werden, wo der Service zu erreichen ist und mit welchem Protokoll. Bestandteile einer WSDL-Definition sind: Datentypdefinitionen für den Datenaustausch (<types>) Nachrichtendefinitionen (<message>) Porttypes zur Beschreibung der abstrakten Kommunikationsart zwischen den Partnern (One-way, Request-response, Solicitresponse, Notification) Bindings zur konkreten Definition des Austauschprotokolls (<bindings>) Services zur Zusammenfassung von mehreren Ports (<services>) Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 26 13

14 WSDL-Beispiel zu Datentypen und Messages <?xml version="1.0"?> <definitions name="stockquote" targetnamespace=" <types><schema targetnamespace=" xmlns=" <element name="tradepricerequest"> <complextype> <all><element name="tickersymbol" type="string"/></all> </complextype> </element> <element name="tradeprice"> <complextype> <all> <element name="price" type="float"/> </all> </complextype> </element> </schema> </types> <message name="getlasttradepriceinput"> <part name="body" element="xsdl:tradepricerequest"/></message> <message name="getlasttradepriceoutput"> <part name="body" element="xsdl:tradeprice"/></message> Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 27 UDDI Verfügbare Webservices werden verwaltet durch : Universal Description, Discovery and Integration (UDDI) Entwicklungsbeginn September 2000 Begründer : Microsoft, Ariba, IBM etc. (heute über 200 Firmen) UDDI-Überblick eine Programmers-API spezifiziert ca. 30 Methoden zum Beschreiben, Suchen und Publizieren von Web-Services Kommunikation komplett über SOAP-Nachrichten UDDI-Operationen sind sehr einfach gehalten: Keine logischen Operatoren Keine kombinierten Anfragen Rudimentäre Infrastruktur Entwickler gehen von einer Integration in intelligentere Systeme aus Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 28 14

15 UDDI-Infrastruktur Ziel ist Schaffung eines unabhängigen Firmen- und Diensteverzeichnisses : Gegenwärtig 3 Teile: 1. white pages - mit Adresse, Kontaktinformationen und Ansprechpartnern 2. yellow pages mit einer Einordnung des Unternehmens nach einheitlichen Richtlinien gemäß Geschäftsbereich 3. green pages mit technischen Informationen über die angebotenen Dienstleistungen und Verweisen zu genauen Spezifikationen angebotener Web Services oder anderen Informationsquellen, soweit erforderlich UDDI-Geschäftsverzeichnis ist logisch zentralisiert, aber physikalisch verteilt auf verschiedene Knotenpunkte, die sich ständig gegenseitig auf dem Laufenden halten. soll jederzeit für jeden frei zugänglich sein. gegenwärtig zwei Knotenpunkte, betrieben von Microsoft und IBM Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 29 Motivation für Service-Orientierte-Architekturen Aktuelle Hauptprobleme komplexer Softwaresystem : - durch historische Entwicklung sehr heterogene Struktur der Hard- und Software (im Bankgewerbe bis zu 30 Jahre alte Software + HW-Reste) - Definition wesentlicher Parameter (z.b. Art der Bearbeitung eines Kundenauftrages als Funktion der Bestellhöhe) INNERHALB der Softwarepakete und damit zentral schlecht zu warten - bei Übernahmen oder Fusionen müssen verschiedene Systeme miteinander gekoppelt werden, meist Schnittstellenexplosion ( n*(n-1) -Schnittstellen bei n Systemen) System 2 System 1 System 3 System 4 System 5 Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 30 15

16 Typische Probleme bei der Änderung bestehender Systeme Die 3 Todsünden : eine Anwendung macht einen spezifischen Funktionsaufruf zu einer anderen Anwendung über ganz konkrete Parameter (bei einem Wechsel zu einer anderen, ähnlichen App. wird diese Funktion anders definiert sein ) Datentransformationen zu und von anderen Apps oder zum Bus sind innerhalb der aufrufenden Anwendungen kodiert Prozesslogik ist innerhalb der Anwendungen kodiert, d.h. das Routing ist mit der eigenen Logik meist untrennbar verbunden Anwendungen kennen die Details von anderen Anwendungen sie machen Annahmen sie sind fest gekoppelt ihre Granularität ist zu hoch Anwendungen wissen, wann sie andere Anwendungen aufrufen (fest kodiertes Prozessverhalten) Es gibt auch bei den Bussen und Hubs keine globalen Standards, sondern nur meist Lieferantenspezifische Quasistandards (nach IBM, Oracle, Microsoft etc.) Fazit: Das Hauptproblem ist die (zu) FESTE Kopplung der Systeme! Ausweg : Lockere und flexiblere Kopplung der Systeme! Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 31 Probleme mit Punkt zu Punkt-Verbindungen Application 1 Application 2 Application 3 Application 4 Application 5 Application 6 Applikation 7 Application 8 In General : 10 applications require 90 connections Quadratisches Wachstum der Schnittstellen (Spaghettisystem) 10 Systeme = 90 Schnittstellen 50 Systeme = 2450 Schnittstellen 100 Systeme = 9900 Schnittstellen (= nicht beherrschbar) Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 32 16

17 Bisherige Integrationsansätze II 2. Hub & Spoke Kopplungen Alle Anwendungen sind verbunden über zentralen Server (Hub). Es ist ein zentrales Austauschformat definiert, in welche alle speziellen Formate transformiert werden müssen. Die Verteilung (das Routing) der Daten wird durch spezielle Regeln und/oder Algorithmen auf dem zentralen Server definiert. System 1 System 2 Zentraler Server (Hub) System 3 System 4 Vorteile geringe Anzahl (linear zur Anzahl Systeme) relativ lose Kopplung Nachteile Starke Abhängigkeit vom Hub (Kapazität, Ausfall?, Performance, Formate) Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 33 Bisherige Integrationsansätze - Message-Bus 3. Message-Bus-Architektur (auch Publish/Subscribe -Architektur) Alle Systeme sind in Reihe mit einem Kommunikationsbus verbunden und tauschen mit diesem direkt Daten aus. Jede Anwendung muss einen entsprechenden Adapter bereitstellen. System 1 System 2 Adapter Adapter Message-Bus Adapter Adapter System 3 System 4 Vorteile relativ störsicher gut skalierbar, auch durch Aufteilung / Bus- Segmentierung Nachteile Für jeden konkreten Bus müssen die jeweiligen Adapter programmiert werden und sind meist nur für diesen passfähig Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 34 17

18 Service-Orientierte-Architekturen Zur Behebung dieser Probleme wird derzeit der Begriff SOA - Service Oriented Architecture stark diskutiert! SOA ist kein Produkt oder Standard sondern ein Konzept : Aufbau komplexer Systeme durch autarke, lose koppelbare und austauschbare Services (Web-Services) Schnelle (Um-)Konfiguration des Ablaufs von Geschäftsprozessen durch externe Beschreibung der Logik Einbeziehung auch alter Software durch Wrapper (Hüllen für Software) Ziele: Deutlichere Verbesserung der Agilität und Flexibilität aller Prozesse! Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 35 Alternativer Lösungsansatz mit SOA Behebung der Probleme durch folgende Maßnahmen Lösung lose gekoppelte Dienste! anstelle stark gekoppelter Objekte, Komponenten und Anwendungen SOA-Komponente Kopplung mit Enterprise-Service- Bus (ESB) grobe Granularität Prozess-Orientierung Ablauflogik aus der Businesslogik herausnehmen feiner Granularität Funktions-Orientierung sie in der Businesslogik zu implementieren grobgranulare Services SOA-Prozesse Service- Orchestrierung im ESB) standardisierte Dokumentstrukturen Produkt und Busspezifischer Dokumente Kanonische Dokumente Konfiguration Programmierung Mapping und Orchestrierung durch ESB-Tools Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 36 18

19 Aufbau von Service-Orientierte-Architekturen SOA Webservice - Ochestration with Rule- Interpeter Webservice 1 Webservice 2 Webservice 3 XML XML Enterprise Service Bus XML XML Webservice 4 Webservice 4 Webservice 4 (Wrapper) (Wrapper) (Wrapper) Application Application Application BPEL/ BPMN Process descriptions Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 37 Übergang zu einer SOA Typisches Beispiel: Einkaufsprozess mit zusätzlicher Genehmigung durch Chef bei einem Einkaufswert > x ( x: Firma : , Uni : 100!) Bisher : Prozesslogik ist innerhalb der Services kodiert Bestellantrag (x>1000) S Genehmigung S Lösung: Services werden von außerhalb orchestriert! Bestellantrag D1 BA SOA ESB (x<=1000) (y=ok) Genehmigung D1 GN D1(x>1000) S D2 S D1(x<=1000) Bestellung Bestellung D1 B D2(y=ok) Physische Adressen Transformatoren Quelle der Grafiken : SOCON Inc. Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 38 19

20 Service Contract Definition SOA - Services SOA - Services sind grob granular (coarse grainded) lose gekoppelt über Messagebus (Message Oriented Infrastructure) verbunden durch Vereinbarung von Schemas und Verträge (und nicht über konkrete Funktionen und Datentypen) The ABC of Services Address Binding - Contract Service Endpoint Address Binding Service Implementation Service Description Quelle der Grafiken : SOCON Inc. Beschreibung Policy (Security Protocol, QoS) Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 39 SOA - Kanonische Dokumente und Adapter Der Datenaustausch wird im ESB über universelle Zwischenformate realisiert sog. Kanonische Dokumente + Adapter im ESB Zentrales Glossar System ID System Name IT Architektur Man. IT FIN Account Nr. Amount Description SYS ID Service VFBK RT Fin.Syst.Nr. Reliabiliy SYS Name FC Nr. Appl.ID Budget Maintenance Time Beschr. System ID Reliability Maintenance Time Account Nr. Glossar Variable ITAR MFIN FB SLM System Name Account Nr. System ID Account System ID SYS ID Appl. ID SYS Nr. Anw. Nr. Description SYS Canonical System Name Name Account Nr. FC Nr. Fin.Syst.Nr. Anw. Name XML Document Amount Budget Betrag Description Beschr. Zweck Description Account System ID System ID System Name Maintenance Time Service Reliabiliy VFBK Verfügbarkeit Reliability Maintenance Time RT Wartungszeit Zweck Betrag Anw. Nr. Wartungszeit SYS Nr. Anw. Name Verfügbarkeit FB SLM Quelle der Grafiken : SOCON Inc. Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 40 20

21 SOA - Kanonische Dokumente und Adapter Über entsprechende Translatoren (teilweise als Mappingtools vom ESB bereitgestellt) werden die spez. Dokumente in kanonische Dokumente gewandelt. Die Steuerung erfolgt im ESB und wird durch eine spezielle Beschreibungssprache (BPEL) innerhalb einer Service-Flow-Engine (=Regelinterpreter) konfiguriert! Kanonische Dokumente K1 und K2 Publisher Bestellantrag Enterprise K1 Service K2 Bus D1 Translator Service Flow Engine Prozess Modell BA X(K1)>1000 GN S ID(GN) OD(GN) ID(B)) S X(K1)<=1000) x(k1)>1000) (x(k1)<=1000) v (y(k2)=ok) Y(K2)=ok) Genehmigung Publisher & Subscriber Quelle der Grafiken : SOCON Inc. ID(X): Input Dokument OD(X): Output Dokument Bestellung Subscriber B Standard Prozess-Beschreibung mit BPEL BPEL4WS - Business Process Execution Language (BPEL) Process BPEL Description Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 41 Prozessmodellierung mit BPEL Umsetzung des Beispiels mit BPEL Bestellantrag S (x>1000) (x<=1000) Genehmigung S (y=ok) Bestellung BPEL mit Standard-Support von großen Herstellern beschreibt im XML Format: - den Ablauf der Anwendungen - Typen von verteilten Daten - wie Partner eingebunden werden - Handhabung von Fehlern - Beziehungen - Handhabung von Ereignissen Quelle der Grafiken : SOCON Inc. partnerlinks definieren involvierte Partner sequence, switch - Prozessfluss invoke Service Aufruf Weitere Sprachelemente: reply while pick wait empty throw terminate compensate Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 42 21

22 Modellierung von Geschäftsprozessen Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 43 SOA Zusammenfassung und Bewertung Vorteile von SOA Bessere, schnellere und flexiblere Integration, Prozess Orientiert Häufigere Wiederverwendung von composite Services Einbindung von Legacy Systemen durch Wrapping (Hülle um Std.-Software) Standardisierte, Prozess Orientierte Daten Representation Standardisierte Business Prozess Representation (ggf. austauschbar oder abstimmbar über Firmengrenzen -> Supply Chain Management) Transformation der IT vom Kostenfaktor zum strategischen Asset Zusammenrücken der Fach- und IT Bereiche -> Schaffung agiler Unternehmen Nachteile und offene Fragen teilweise erheblicher Aufwand der Umstellung (allerdings ROI < 1..2 Jahre) SOA ist kein Standard/konkrete Technologie, sondern ein Konzept! Die konkreten Eigenschaften sind (noch) stark von Lieferanten des ESB abhängig (noch) Performanceprobleme durch XML-Datenaustausch Firmen-spez. ESB doch wieder nicht kompatibel BPEL (noch) keine gute Unterstützung von Adhoc-Prozessen und Human- Interactions (aber in Entwicklung) Fazit : SOA (oder Nachfolger) dürften die entscheidende Technologien der nächsten Jahre im Bereich komplexer IT-Architekturen sein! {Beobachten und Testen!} Grundlagen der Informatik Teil 3 - Prof. T.Wiedemann - HTW Dresden - Folie 44 22