Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Integration verteilter Dienste in die Anwendungslandschaft der OEV (ESB)

No description
by

Sebastian Mohr

on 17 January 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Integration verteilter Dienste in die Anwendungslandschaft der OEV (ESB)

Enterprise Service Bus Integration verteilter Dienste in die Anwendungslandschaft der OEV Anforderungen an
"Enterprise Applications" Enterprise Service Bus "...ist ein Architekturstil der Integration, der die Kommunikation über einen gemeinsam genutzten Kommunikationsbus einer Vielzahl von Punkt-Zu-Punkt-Verbindungen zwischen Anbietern und Nutzern von Softwarediensten vorzieht" Hauptaufgaben eines ESB Beispiel ESB & OEV Derzeitige Einsatzgebiete innerhalb
der OEV-Projekte Grundkonzept Die Message besteht aus einem:
- Header
- Body (Payload)
- ggfs. Properties
- ExceptionPayload
- ggfs. Attachments (z.B. bei Emails) Message Channel transportiert die Message zu ihren/ihrem Empfängern/Empfänger. Durch Routing, einem Filter oder Transformation können die Message beim Transport durch den Message Channel beeinflusst werden Routing Das Bestimmen des Empfängers einer Nachricht ist die zentrale Funktionalität eines ESB! Bearbeitung von Verträgen 1 - Eine externe Anwendung stellt Vertragsdaten eines Zeitraums per SOAP/Webservice zur Verfügung
2 - File Poller: Liest die Datensätze ein, splittet diese auf, tranformiert sie in ein standardisiertes Format und legt sie auf eine JMS-Queue
3 - Parallel kommen aus einem anderen System ebenfalls Verträge die bereits per Messaging angeliefert werden. Diese Dateien werden von einer Message Bridge entgegen genommen, in das einheitliche Format umgewandelt und in dieselbe JMS-Queue gelegt.
4 - Kreditprüfung über Webservice eines externen Anbieters.
5 - Ergebnis der Kreditprüfung wird über einen Content Enrichter dem Vertrag hinzugefügt.
6 - Abhängig von dem Ergebnis der Kreditprüfung wird der Vertrag über einen content-bases-Message Router zu unterschiedlichen Systemen geroutet. Pipeline Content Base Routing Dispatcher Einsatzgebiete innerhalb der VAM-Architektur Die Prozess-Schicht ruft den ESB auf, um Services (z.B. Betreuersuche) aufzurufen. Der ESB kennt diesen Service und weiß, wie und wo dieser aufgerufen werden kann. Der ESB wird momentan mit VAM-Anwendung ausgeliefert und ist fester Bestandteil des Pakets. Wenn der ESB jedoch strategisch eingesetzt werden soll (z.B. im Rahmen einer konsequenten Ausrichtung auf eine SOA-Architektur), kann er ESB auch eigenständig als Infrastruktur-Komponente betrieben werden. Bisher keine Ausnutzung des gesamten Potenzials: Intelligente Routing-Mechanismen/Regeln, Transformierung etc.
nicht alle Services (z.B. externe Webservices) sind über den ESB angeschlossen) ESB-Prototyp innerhalb des Projekts "Neues Vertriebssystem" Anforderungsanalyse an das ESB Framework
Mögliche ESB Frameworks und Machbarkeitsstudien auf Basis der Anforderungen Mule ESB & JBossESB Implementierung eines Prototyps
OSPlus Integration (IKK)
Versionierung von SOAP-Webservices
Deployment Mule ESB & JBossESB auf JBoss Applikation Server
Performance-Tests & Refactoring Einzusehen unter Confluence
"Neues Vertriebssystem" - Reiter "ESB" Rule Engine
Kann innerhalb des ESB integriert sein (z.B. Drools) Intelligentes Routing bis hin zu kompletten Prozessabläufen (Auslagerung in eigene Workflow-Systeme (BPEL-Engines etc.)) Zentrale Sammelstelle für GeschäftsregelnTrennung von Logik und AnwendungenRegeln sind lesbarer als CodeNicht-Techniker können Regeln schreiben Komplexe Probleme lassen sich oft besser in Regeln beschreiben als in SourceCode rule “Yellow star”
when
$u : User ( positiveFeedbacks > 10 );
then
$u.setUserLevel ( “yellow_star” );
end Beispielregel: „Wenn das Mitglied über 10 positive
Bewertungspunkte besitzt, erhält es einen gelben Stern" Wann ist eine Rule Engine sinnvoll? wenn man ein komplexes Problem lösen muss
wenn man für das Problem Regeln formulieren kann und jede Regel >3 Bedingungen hat
wenn sich die Regeln wahrscheinlich mit der Zeit verändern
wenn die Wartung der Regeln garantiert ist
wenn Performance nicht alles ist (dies bedeutet nicht, dass Rule Engines langsam sind!)
wenn man (Geschäfts-)Logik von der Anwendung trennen muss Transformation Inhaltstransformation:
Werte und Formatsänderungen
Content-Enricher

Protokolltransformation (Unterstützt offene Kommunikationsstandards (z.B. SOAP, Webservices)) Routing-Arten: content-based
rule-/policy-based
statische Routen
Korrelation Bus Mit "Bus" bezeichnet man ein Untersystem, das Daten zwischen Teilen des Systems überträgt. Er ersetzt das komplizierte Netz der direkten physischen Kopplungen in einer Anwendungslandschaft durch eine Kommunikationsinfrastruktur, die gemeinsam durch alle Dienstanbieter und Dienstnutzer verwendet wird. 2. physische Kopplungen der Logikintegration auf der Ebene der Geschäftsfunktionen einer Anwendung (--> ESB) 1. physische Kopplungen der Präsentationsintegration auf der Ebene von Benutzerschnittstellen (z.B. in Portalen und in Rich Clients) 3. physische Kopplungen der Datenintegration auf der Ebene des direkten Zugriffs auf persistente Daten (ESBs stellen ein Lösungsmuster dar, um direkte physische Kopplungen auf der Datenebene zu verhindern.) Zentrales Element innerhalb des ESBs ist die Nachricht (Message). Ein Auftrag oder Aufruf von außen an einer Schnittstelle wird in eine Nachricht verpackt.

Die Nachricht läuft dann durch den ESB.

An einer anderen Schnittstelle kann die Nachricht dann wieder zu einer Interaktion mit einem weiteren System führen Messaging Typen der Kommunikation Synchrone Kommunikation
Direkte Kommunikation zwischen Applikation
Request/Reply
Sender blockiert, bis Antwort eintrifft
Realisierung z.B. über zwei Warteschlangen Message Passing Message Queueing Asynchron
Punkt zu Punkt
Indirekte Kommunikation über eine Nachrichtenqueue Broadcasting Nachricht wird an alle erreichbaren Sender verschickt Publish & Subscribe Asynchron
Broadcast-Kommunikation
Publisher: veröffentlichen Nachrichten
Subscriber: abonnieren bestimmte Themen Skalierbarkeit & Performance
Vielzahl heterogener Systeme
Verteilte Systeme Arten der Kopplung Vorteile Kritik ggfs. Performance-Einbußen
Die Namenskomponenten Enterprise und Service würden wörtlich genommen, so dass Unternehmen Gefahr liefen, überdimensionierte und zu generische Infrastruktur einzuführen, für die es zum Zeitpunkt der Realisierung keine ausreichenden Geschäftsbedürfnisse gebe. Reduktion der Komplexität in den Frontend-Applikationen
Kurze Entwicklungszeit für die Integration von Daten und Services
Kurze Einarbeitungszeit für Service-Integratoren
Modularer Aufbau der Architektur ermöglicht rasche Anpassung an neue Rahmenbedingungen
Einfaches Definieren zur Orchestrierung von Services
Durch zentrale Routing-Komponente können Aufrufe von bestimmten Services geloggt (und ggfs. abgerechnet werden)
Schon vorhandene Adapter und APIs erleichtern die Umsetzung Ein Enterprise Service Bus allein generiert insofern keinen Geschäftsnutzen als er in fachlich motivierten IT-Lösungen immer nur Mittel und nicht Zweck ist.

Indirekt kann der Einsatz eines Enterprise Service Bus Geschäftsnutzen erzeugen, weil er dazu beitragen kann, die Anwendungslandschaft eines Unternehmens kosteneffizienter und agiler zu gestalten: kaum Punkt-zu-Punkt-Verbindungen
keine bilaterale Adapter (Code-Redundanz)
keine komplizierten Netze von Kopplungen ESB
Full transcript