Effective SOA – geht das? Teil 4 von 5: SOA-Konzepte - Mythos oder Realität?

2,489 views

Published on

www.opitz-consulting.com/go/3-5-11

Haben Sie sich schon einmal gefragt, warum man Services in modernen IT-Architekturen kategorisieren sollte? Was genau verbirgt sich hinter der Service-Virtualisierung und welche Rolle nimmt hierbei ein Enterprise Service Bus (ESB) ein? Inwieweit unterstützen derartige Konzepte Unternehmen dabei, der vielzitierten IT-Flexibilität einen Schritt näher zu kommen, oder helfen bei Herausforderungen wie Systemaustausch und Parallelbetrieb?

In einem mehrteiligen Vortragsslot berichteten die OPITZ CONSULTING SOA-Experten Danilo Schmiedel, Hendrik Voigt und Torsten Winterberg im Rahmen der SOA | BPM Integration Days am 13.10.2011 in Düsseldorf von ihren Projekterfahrungen in diesem Umfeld und gingen auf Stolpersteine im Projektalltag ein.

Damit Liebhaber von Live-Demos zu typischen Praxisproblemen ebenfalls auf ihre Kosten kamen, erläuterten und bewerteten die Referenten bewährte Architekturkonzepte und veranschaulichen deren Realisierung mit Produkten der Oracle Fusion Middleware.

In diesem Part ihrer Session führten die Vortragenden die wesentlichen Konzepte für SOA-Architekturen ein und diskutierten ihre Praxistauglichkeit.

--
Möchten Sie die Vorteile von effektiver SOA in Ihrem Unternehmen nutzen? Wir beraten Sie gerne zu Ihren individuellen Anforderungen. Weitere Informationen zu unserem Leistungsangebot im Bereich SOA und System-Integration erhalten Sie auf unserer Website: www.opitz-consulting.com/go/3-5-889

Published in: Technology
  • Be the first to comment

Effective SOA – geht das? Teil 4 von 5: SOA-Konzepte - Mythos oder Realität?

  1. 1. D. Schmiedel; H. Voigt; T. Winterberg OPITZ CONSULTING GmbHEffective SOA – geht das?Teil 4 von 5: SOA-Konzepte - Mythos oder Realität?Düsseldorf, den 13.10.2011
  2. 2. Vorschlag für ein Service-Design
  3. 3. Geschäftsprozesse Web Reservation Process Syste Partner A mA Rolle BGeschäftsprozesse und Benutzungs-Kanäle Frontends GUI: Partner A Standard GUI for car selection © Hajo Normann (HP Enterprise Services) | SOA & BPM Architect | Oracle ACE Kontextspezifische findFilteredCarsAndPrices (Partner A) findCarsAndPrices (Std.) BAS Business Activity Beispiel WCS_1: FleetManagement Services (BAS) findCars findCars calcPrices AndPrices Services und Systeme Orchestrierungs-Engine Business Entity FleetInformation PricingEngine Services Director CRM System Car Rental System Rule Engine
  4. 4. Geschäftsprozesse System A Rolle BGeschäftsprozesse und Prozess- manager 4 Min. im Durchschnitt Im Januar wurden in © Hajo Normann (HP Enterprise Services) | SOA & BPM Architect | Oracle ACE Frontends 12 Min. maximal Analysiert München 12.000 Autos Kennzahle erfolgreich vermittelt Aktivität „Auto säubern“ n und (Durchschnitts- dauert am längsten (37 verbessert dauer: 4,2h) Min.) Prozess Fachmonitoring über Kennzahlen Prozessmgmt. Benutzungs-Kanäle GUI: Partner A Standard GUI for car selection Kontextspezifische findFilteredCarsAndPrices findCarsAndPrices (Std.) BAS (Partner A)Services und Systeme Business Activity FleetManagement Services (BAS) Business Entity PricingEngine FleetInformation Services (BES) Director CRM System Car Rental System Rule Engine
  5. 5. Neubau des Rental Car Process
  6. 6. Message Exchange Pattern &Lose Kopplung
  7. 7. Synchrone Kommunikation
  8. 8. Asynchrone Kommunikation (1)
  9. 9. Asynchrone Kommunikation (2)
  10. 10. Broadcast
  11. 11. Kopplungsstufen Kopplungsstufen (degrees of coupling) legen konkrete Eigenschaften der Kopplung entlang der Kopplungsdimensionen fest. • Von Architekten unternehmensspezifisch zu entwerfen • Möglichst wenige Kopplungsstufen verwenden Abhängigkeit der Verfügbarkeit Vertrauen WissenKopplung- Kommunikation übe TX Validierung DB Gemein-stufen r same ES Datentypen B1. eng synch nei Ja nein emeinsam Fachlich n2. mittel synch ja Nein ja Getrennt Technisch3. lose async ja Nein ja Getrennt Technisch4. extrem lose Event Ja Nein ja Getrennt Technisch
  12. 12. Ideale Kopplungsarchitektur• In der idealen Kopplungs- architektur wird jeder Kopplung zwischen Komponenten eine angemessene Kopplungsstufe zugewiesen.• Architekt legt ideale Kopplungsarchitektur unternehmensspezifisch fest: • z.B. Komponenten werden immer lose gekoppel.t • Domänenübergreifende Kommunikation erfolgt mit loser Kopplung. • Prozesskomponenten kommunizieren über mittlere oder lose Kopplun.g
  13. 13. Enterprise Service Bus• Technisches Rückgrat einer SOA• Aufgaben eines ESBs • Konnektivität herstellen • Daten transformieren • Routen • Mit Sicherheitsaspekten umgehen • Mit Aspekten der Zuverlässigkeit umgehen • Möglichkeiten zum Überwachen, Protokollieren und Debuggen bereitstellen
  14. 14. Virtualisierung und lose Kopplung
  15. 15. Virtualisierung und lose Kopplung
  16. 16. Virtualisierung und lose Kopplung
  17. 17. Virtualisierung und lose Kopplung
  18. 18. Kanonisches Datenmodell
  19. 19. Geschäfts- Web Reservation prozesse ProcessGeschäftsprozesse und Frontends Partner System A A Rolle B Benutzungs- © Hajo Normann (HP Enterprise Services) | SOA & BPM Architect | Oracle ACE Director GUI: Partner A Standard GUI for car selection Kanäle Kontext findFilteredCarsAndPrices (Partner A) findCarsAndPrices (Std.) spezifische BAS Business Activity Beispiel WCS_1: FleetManagement Services (BAS) findCarsAndPrices Business Entity ServicesServices und Systeme (BES) PricingEngine Spezifische- Kanonische FleetInformation Daten Daten Adapter Transformation CRM System Car Rental System Rule Engine
  20. 20. SchnittstellenänderungKanonisches Datenmodell – BeispielOhne kanonisches Datenmodell Mit kanonischem Datenmodell Berliner „Schrippe“ Berliner „Wie nennt man bei euch ein kleines Weizengebäck?“ Kanonisches ? Datenmodell Ahh! Schrippe ↔ Brötchen ↔ Semmel Bayer „Semmel“ Bayer
  21. 21. SchnittstellenänderungKanonisches Datenmodell – weitere Beispiele ISO, EN, DIN Codes  DE (ISO-3166 Alpha-2) vs. DEU (ISO-3166 Alpha-3) vs. GER (IOC) Größendimensionen in ERP-Systemen  Artikelnummer und Artikelgröße: MS Axapta vs. SAP ERP vs. Oracle sBS Objektidentifizierung, Vereinigung  Name ↔ Name1 und Name2 ↔ Vorname und Nachname Re-Strukturierung  (Customer  Order) vs. (Order  Customer) Kanonisches Datenmodell System A Konfliktlösung  varchar(20) vs. varchar(64) vs. Integer System System B C
  22. 22. Kanonisches Datenmodell OntologieDatenstruktur in Kanonisches Obermenge XSD Datenmodell valider Instanzen Technische Krücke
  23. 23. SOA für Portal / Webshop-Integration Domäne B2B Lager Bestellung Lieferant <<ERP>> <<Webshop>>Verkauf Standardsoftware Standardsoftware Käufer <<Webshop>> Individualentwicklung RechnungHersteller
  24. 24. SchnittstellenänderungVirtualisierung und lose Kopplung – Beispiel Backend Virtualisierung Middleware Virtualisierung Frontend Backend Frontend <<Webservice>> <<Webservice>> erp_in_xxx shopA_out_xxx <<Middleware>> <<Webshop>> <<ERP>> Oracle StandardsoftwareStandardsoftware SOA Suite 11g A <<Webservice>> <<Webservice>> erp_out_xxx shopA_in_xxx
  25. 25. SchnittstellenänderungVirtualisierung und lose Kopplung – Diskussion Backend Virtualisierung Middleware Virtualisierung Frontend Backend Frontend <<Webservice>> <<FTP Adapter>> <<Webservice>> erp_in_xxx_v2 erp_in_xxx shopB_out_xxx shopA_out_xxx <<Middleware>> <<Webshop>> <<ERP>> Oracle Individualentwicklung StandardsoftwareStandardsoftware SOA Suite 11g B A <<Webservice>> <<FTP Adapter>> <<Webservice>> erp_out_xxx_v2 erp_out_xxx shopB_in_xxx shopA_in_xxx Erweiterbarkeit √ Virtualisierung  Entkopplung Anpassbarkeit √  Hervorragende Wartbarkeit
  26. 26. Integration von Systemen – Beispiel:1. ERP aktualisiert eine Artikeldefinition Backend Virtualisierung Middleware Virtualisierung Frontend Backend Frontend <<Webservice>> <<FTP Adapter>> erp_in_xxx xxx_out_ftp <<Middleware>> <<Webshop>> <<ERP>> Oracle StandardsoftwareStandardsoftware SOA Suite 11g A <<Webservice>> <<FTP Adapter>> erp_out_xxx xxx_in_ftp
  27. 27. Integration von Systemen – Beispiel2. Middleware routet zum richtigen Shop Backend Virtualisierung Middleware Virtualisierung Frontend Backend Frontend <<Webservice>> <<FTP Adapter>> erp_in_xxx xxx_out_ftp <<Middleware>> <<Webshop>> <<ERP>> Oracle StandardsoftwareStandardsoftware SOA Suite 11g A <<Webservice>> <<FTP Adapter>> erp_out_xxx xxx_in_ftp
  28. 28. Integration von Systemen – Beispiel3. SOA Suite übermittelt die Artikeldefinition Backend Virtualisierung Middleware Virtualisierung Frontend Backend Frontend <<Webservice>> <<FTP Adapter>> <<Webservice>> erp_in_xxx shopA_out_xxx xxx_out_ftp <<Middleware>> <<Webshop>> <<ERP>> Oracle StandardsoftwareStandardsoftware SOA Suite 11g A <<Webservice>> <<FTP Adapter>> erp_out_xxx xxx_in_ftp
  29. 29. Integration von Systemen – Beispiel Zusammenfassung Backend Virtualisierung Middleware Virtualisierung Frontend Backend Frontend <<Webservice>> <<FTP Adapter>> erp_in_xxx xxx_out_ftp <<Middleware>> <<ERP>> <<Webshop>> Oracle Standardsoftware Individualentwicklung SOA Suite 11g <<Webservice>> <<FTP Adapter>> erp_out_xxx xxx_in_ftp1. ERP aktualisiert 2. Middleware routet 3. SOA Suite übermittelt eine Artikeldefinition zum richtigen Shop die Artikeldefinition
  30. 30. menschliche Interaktionen,Business Rules, Fehlerhandling, …
  31. 31. Fehlerhandling Fachliche Fehler • z. B. Kunde nicht gefunden, fachlich fehlerhafte Eingabe, …. • Fachliche Fehler sind Bestandteil der Business Logik • Normalerweise kein Logging, Monitoring und Alerting • Transport mit soap:fault • Anzeige an der Benutzeroberfläche Technische Fehler • Behandlung technischer Fehler gehört nicht in die Businesslogik • Fehlerhandling für technische Fehler umständlich und redundant • Fehlerhandling für technische Fehler vereinheitlichen • Sollten gelog‘d werden • Evtl. Alerting an Administrator notwendig (Ticket, Email, etc.)
  32. 32. Fragen und Antworten
  33. 33. Ansprechpartner bei OCTorsten Winterberg, Director Strategy & InnovationHead of Competence Center SOA, Oracle Ace DirectorOPITZ CONSULTING GmbHTorsten.Winterberg@opitz-consulting.comMobil +49 173 54 79 302Dr. Hendrik Voigt, Senior ConsultantOPITZ CONSULTING Gummersbach GmbHHendrik.Voigt@opitz-consulting.comTelefon +49 2261 6001 – 1181Mobil +49 173 7279028Danilo Schmiedel, Senior ConsultantOPITZ CONSULTING Berlin GmbHDanilo.Schmiedel@opitz-consulting.comTelefon +49 30 6298889 - 1632Mobil +49 173 7279001

×