Integration Engineering mit Microsoft BizTalk Server 2010

Größe: px
Ab Seite anzeigen:

Download "Integration Engineering mit Microsoft BizTalk Server 2010"

Transkript

1 Integration Engineering mit Microsoft BizTalk Server 2010 Ausarbeitung und Projektdokumentation im Studiengang Application Architectures / Master of Science an der Fakultät Wirtschaftsinformatik der Hochschule Furtwangen University vorgelegt von: Florian Kalisch und Denis Radjenovic Vorlesung : Integration Engineering Betreuer : Herr Prof. Dr. Martin Buchheit eingereicht am : 17. Juli 2011 / Sommersemester 2011

2

3 I Zusammenfassung Die vorliegende Arbeit zielt darauf ab, ein gründliches Verständnis für das Thema Integration Engineering mit dem BizTalk Server 2010 zu liefern. Beginnend mit einer kurzen Einleitung, welche die Notwendigkeit des Integration Engineering unterstreicht, wird das Beispielprojekt Loan Broker vorgestellt, das mit dem BizTalk Server 2010 im Rahmen eines praktischen Semesterprojekts umgesetzt wurde. Die Arbeit fokusiert drei Hauptteile. Im ersten Teil sollen Grundlagen bezüglich des Themas Integration Engineering vermittelt werden. Die Architektur und die Funktionalität des BizTalk Server bilden den zweiten groÿen Teil. Der dritte Teil dokumentiert die praktische Umsetzung des Loan Broker und die dabei gemachten Erfahrungen mit dem Einsatz des BizTalk Server Abschlieÿend werden die während der Umsetzungsphase erkannten Stärken und Schwächen des BizTalk Server zusammengefasst.

4 II Inhaltsverzeichnis Inhaltsverzeichnis Abkürzungsverzeichnis Abbildungsverzeichnis II IV VI 1 Einleitung Zielsetzung und Aufbau Projektbeschreibung - Der Loan Broker Warum BizTalk Server 2010? Grundlagen Der Hub-and-Spoke Ansatz Enterprise Service Bus Charakterisierung nach Chappell Charakterisierung nach Forrester Microsoft BizTalk Server vs ESB ESB Toolkit als Erweiterung Microsoft BizTalk Server Architektur des Microsoft BizTalk Server Messaging und Orchestration Weitere Komponenten Entwicklungswerkzeuge Schema Editor Mapping Editor Pipeline Designer Orchestration Designer Diverse Wizards BizTalk Server Administration Console Der Loan Broker mit BizTalk Der Installationsprozess Architektur des Loan Broker Umsetzung mit Microsoft BizTalk A - Der Web Client B - Das Credit Bureau C - Die Banken D - Der Loan Broker

5 III I. Kreditbüroanfrage II. Kreditanfrage an die Banken III. Antworten der Kreditanfrage bearbeiten IV. an den Kunden senden Aufgetretene Probleme Verbesserungsvorschläge Zusammenfassung und Fazit Literaturverzeichnis

6 IV Abkürzungsverzeichnis BAM Business Activity Monitoring BPEL Business Process Execution Language BRE Business Rule Engine BTF BizTalk Framework CBR Content Based Router CIO Chief Information Ocer COM Component Object Model CSV Comma Separated Values DCOM Distributed Component Object Model EAI Enterprise Application Integration EDIFACT Electronic Data Interchange For Administration, Commerce and Transport EIP Enterprise Integration Patterns ESB Enterprise Service Bus JCA Java EE Connector Architecture JMS Java Message Service MOM Message Oriented Middleware REST Representational State Transfer SCHUFA Schutzgemeinschaft für allgemeine Kreditsicherung SMTP Simple Mail Transfer Protocol SOA Service Oriented Architecture SSN Social Security Number URL Uniform Resource Locator WCF Windows Communication Foundation

7 V WS-BPEL Webservices-BPEL WSDL Web Services Description Language XML Extensible Markup Language XPath XML Path Language XSD XML Schema Denition XSLT Extensible StyleSheet Language Transformation XQuery XML Query Language

8 VI Abbildungsverzeichnis Abbildung 1 Das Loan Broker Szenario Abbildung 2 BizTalk Server - Architektur Abbildung 3 Datenuss einer Nachricht im BizTalk Server Abbildung 4 Schema Editor Abbildung 5 Mapping Werkzeug Abbildung 6 Orchestration Designer mit Shapes Abbildung 7 BizTalk Server Administration Console Abbildung 8 Eine erfolgreiche BizTalk Server Installation Abbildung 9 Finale Architektur Abbildung 10 Finale unterteilte Architektur Abbildung 11 Der Web Client / Kreditanfrage Abbildung 12 Der Web Client / Kreditangebot Abbildung 13 Die Credit Bureau Orchstration Abbildung 14 Erzeuge Message CreditBureauReply Abbildung 15 Bereich Kreditbüroanfrage Abbildung 16 Erstelle Kreditbüroanfrage Abbildung 17 Gesamtansicht Banken Abbildung 18 Detailansicht der Bank Abbildung 19 Denition der Regeln Abbildung 20 Erzeuge BankRequest Abbildung 21 Bereich Antwort Kreditanfrage Abbildung 22 Erzeuge LoanQuoteReply Abbildung 23 Bereich Abbildung 24 Erzeuge LoanBrokerMail Abbildung 25 Antwort

9 1 Einleitung 1 1 Einleitung In den 80er und 90er Jahren entstanden in vielen Unternehmen IT-Landschaften, die sehr stark durch heterogene Insellösungen, bestehend aus zugekauften und selbst erstellten Anwendungen, geprägt waren. In verschiedenen Bereichen der Unternehmen wurden zu unterschiedlichen Zeiten und auf diversen Plattformen Softwarelösungen etabliert, um Geschäftsprozesse abzubilden. Dieser inhomogene Ansatz führte dazu, dass kaum ein Unternehmen eine Software-Landschaft betreibt in welcher alle wesentlichen Applikationen ineinander greifen. Anfang dieses Jahrhunderts sahen sich Unternehmen mit der Notwendigkeit konfrontiert, ihre Geschäftsprozesse ezient und jederzeit ausführen zu können. Getrieben durch Internettechnologien, E-Commerce und die damit verbundene Globalisierung der Märkte, sowie dem gestiegenen Wettbewerbsdruck, welcher Flexiblisierungs- und Rationalisierungsbestrebungen fordert, entstand die Herausforderung, Prozesse rasch an geänderte Rahmenbedingungen anzupassen und neue Prozesse in kurzer Zeit zu etablieren. Eine weitere Herausforderung stellt die unternehmensinterne und -externe Integration heterogener bereichsspezischer Anwendungen dar. Hierfür haben sich in der jüngeren IT-Geschichte mehrere Konzepte und Technologien einen Namen gemacht. Enterprise Application Integration (EAI), Service Oriented Architecture (SOA) und der Enterprise Service Bus (ESB) haben sich zum Ziel gesetzt, die oben beschriebenen Probleme in Angri zu nehmen. Dabei geben diese Konzepte keine explizite Lösung in Form von starren Regeln vor, sondern bieten eher eine Sammlung von Grundideen zur Lösung an, wobei diese Ideen je nach Sichtweise interpretierbar sind. Dies hat auch verschiedene Softwarehersteller auf den Plan gerufen, die mit Ihren Anwendungen versuchen eine praktische Umsetzung der Konzepte zu ermöglichen. 1 2 Microsoft bietet mit dem BizTalk Server eine Software an, die Unternehmen dabei unterstützen soll ihre unterschiedlichen Anwendungen zu verbinden und ihnen erlaubt, Informationen untereinander auszutauschen. Dabei liegt der Fokus nicht nur auf den internen Unternehmensanwendungen, sondern auch auf unternehmensübergreifenden Anwendungen, z.b. durch Web Services. Der BizTalk Server kann schon auf ein lange Versionsgeschichte zurückblicken. Die erste Version, der BizTalk Server 2001, kam im Jahr 2000 auf den Mark. Die aktuelle siebte Version ist der BizTalk Server [Her05] 2 [Win11]

10 1 Einleitung Zielsetzung und Aufbau Diese Ausarbeitung entstand im Rahmen der Vorlesung Intergraion Engineering und hat zum Ziel, den BizTalk Server 2010 als Integrationsplattfrom vorzustellen. Hierfür untergliedert sich das vorliegende Dokument in drei Kernbereiche. Das zweite Kapitel umfasst den ersten Kernbereich und dient zur Vermittlung Grundlagen. Der bereits erwähnte Begri ESB soll näher erläutert und in einen gemeinsamen Kontext mit dem Microsoft BizTalk Server gebracht werden. Das dritte Kapitel soll den BizTalk Server 2010 als ein konkretes Softwareprodukt vorstellen, welches die Konzepte zur Realisierung von Integraion Engineering innerhalb eines Unternehmens mit Werkzeugen unterstützt. Kernpunkte in diesem zweiten Bereich sind die Analyse der Architektur, die Funktionsweise und die Entwicklungsumgebung des BizTalk Server. Im vierten Kapitel wird die Umsetzung eines Beispielprojekts mit dem BizTalk Server 2010 dokumentiert. Dieser dritte Kernbereich beschreibt die Entwicklungsphasen von der technischen Konzeption mit Integration Patterns bis hin zur Implementierung mit dem BizTalk Server Die Vorstellung des Projekts soll im nächsten Unterkapitel erfolgen. 1.2 Projektbeschreibung - Der Loan Broker Ein Loan Broker, zu deutsch Kreditvermittler, hat sich zur Aufgabe gemacht, Kreditanfragen von Kunden (Customer) an Banken weiterzuleiten. Doch bevor bei den Banken nach einem Kredit angefragt werden kann, ist die Prüfung der Kreditwürdigkeit des Kunden notwendig. Um diese Informationen zu erhalten, fragt der Kreditvermittler bei einem Credit Bureau - in Deutschland entspricht das der Schutzgemeinschaft für allgemeine Kreditsicherung (SCHUFA) - an. Die erhaltenen Informationen und die eigentliche Kreditanfrage werden dann an die Banken übermittelt. Die Banken überprüfen diese Anfrage und entscheiden, ob sie den Kredit gewähren wollen oder nicht. Je nach Entscheidung werden ein Kreditangebot, eine Absage oder auch keine Antwort an den Kreditvermittler zurückgeschickt. Im nächsten Schritt erfolgt eine Auswertung aller abgegebenen Angebote, und die Ermittlung des besten Angebots. Dieses Angebot erhält dann der Kunde. In Abblidung 1 auf der nächsten Seite ist das oben beschriebene Ablaufszenario zur Verdeutlichung noch einmal grasch skizziert. 3 [vgl. HT04, S. 3]

11 1 Einleitung 3 Abbildung 1: Das Loan Broker Szenario Warum BizTalk Server 2010? Die Wahl den BizTalk Sever 2010 als Intergationsplattform zu verwenden stand für die Autoren von vornherein fest. Als Gründe hierfür sind die vorhande Expertise, die beide Autoren im Umgang mit Microsoft Produkten mitbringen und das Interesse den BizTalk Server näher kennen zu lernen, zu nennen. Ein weiterer wichtiger Aspekt war die den Autoren bekannte Möglichkeit, mit dem BizTalk Server, Prozesse grasch gestalten zu können, ohne dass überwiegend Quellcode geschrieben werden muss. Dieser Ansatz wird als zukunftsweisend empfunden, da sich Integration Engineering nicht zwangsläug nur an Entwickler richten sollte, sondern auch an Systemintegratoren ohne tiefere Programmierkenntnisse.

12 2 Grundlagen 4 2 Grundlagen 2.1 Der Hub-and-Spoke Ansatz Als eine der ersten Integrationsarchitekturen, welche die unexible Handhabung der Point-to-Point Integration überwunden haben, sind Systeme, die auf einer Hub-and-Spoke Architektur basieren, zu nennen. Die Merkmale dieser Architektur sind: 4 ˆ Es gibt einen zentralisierten Hub, der Anfragen von mehreren Applikationen entgegen nimmt, welche wiederum als Spokes mit dem Hub verbunden sind. ˆ Die Spokes sind mit dem Hub über Konnektoren verbunden, die auf existierenden Systemen erstellt und bereitgestellt werden. ˆ Das aktuelle System nach Möglichkeit nicht verändern zu müssen, ist eine der Hauptintentionen von Hub-and-Spoke Architekturen. ˆ Innerhalb des Hubs existieren Möglichkeiten für: Nachrichtentransformation Nachrichtenvalidierung Nachrichtenrouting Asynchrone Nachrichtenauslieferung ˆ Weitere Merkmale für auf Hub-and-Spoke basierende EAI Produkte sind monolithische, teure und auf propritäten Standards basierende Systeme. Als eine Architektur mit einem zentralisierten Hub sind diese Systeme mit dem Problem konfrontiert, dass es einen Single-Point-Of-Failure gibt, so dass bei Ausfall eines zentralen Hubs keine Nachricht mehr verarbeitet werden kann. Trotz dem Versuch, dieses Problem durch Clustering zu überwinden, konnten Architekturen dieser Art keinen groÿen Zuspruch nden, da die Systeme sehr komplex und schwer zu warten waren. 2.2 Enterprise Service Bus Während die Beliebtheit der Hub-and-Spoke Architektur, welche die bisher gängigste Architektur zur EAI darstellte, immer stärker abnimmt, setzten immer 4 [Bak05]

13 2 Grundlagen 5 mehr Architekten und Chief Information Ocer (CIO) auf die SOA und ihre infrastruktuelle Ausprägung, den ESB. 5 Der ESB teilt das Schicksal mit den Anfängen der Web Services und vor ein paar Jahren mit den Service orientierten Architekturen. Es wusste zwar jeder Fachmann, was ein Web-Service und zeitlich später was eine SOA ist, aber es konnte keiner eine richtige Denition dafür geben. Analog hierzu kann heutzutage ein ESB noch nicht genau deniert werden. Es können lediglich die verschiedenen Facetten betrachtet werden. 6 Zur Unterscheidung von EAI und ESB lassen sich grundlegend zwei Hauptunterschiede nden Der erste adressiert den Wandel von einem Hub-And-Spoke Modell in EAI Produkten hin zu einem auf einem Bus basierenden Modell in ESB Produkten. Das Hub-and-Spoke Modell, welches als ein Nachfolger von Point-to- Point angesehen werden kann, stellt eine zentralisierte Architektur dar, bei welcher jeglicher Datenaustausch durch einen Hub oder Broker vorgenommen wird. Die Bus Architektur auf der anderen Seite benutzt eine verteilte Architektur, bei welcher die ESB Funktionalität durch mehrere physikalisch getrennte Funktionseinheiten implementiert werden kann. 2. Der zweite Unterschied zeigt sich in der Benutzung von oenen Standards. Während EAI Produkte hauptsächlich auf proprietären Technologien für die Umsetzung von Messaging Funktionalität und Transformationslogik setzen, so basieren ESB Produkte auf oenen Standards wie Java Message Service (JMS), Java EE Connector Architecture (JCA) und Web Service Standards. Die Untersuchung der Facetten eines ESB wurde bereits von verschiedenen Personen beziehungsweise Institutionen vorgenommen, von welchen nachfolgend zwei dargestellt werden sollen Charakterisierung nach Chappell Die umfangreichste Charakterisierung stammt von David A. Chappell 8, welche Steen Hiekel in seiner Diplomarbeit 9 zusammenfasst. Die folgende Auistung ist angelehnt an Hiekel. 5 [Bak05] 6 [Mel10, S. 22] 7 [RD08, S. 4] 8 [Cha04] 9 [Hie07, vgl. S ]

14 2 Grundlagen 6 1. Durchdringung und Durchgängigkeit: Der ESB kann den Kern eines durchgängigen Netzwerks bilden, welches sich innerhalb eines Unternehmens über Abteilungs- und Geschäftsbereichsgrenzen hinweg strecken kann, jedoch auch Unternehmensübergreifend eine Vernetzung ermöglicht. Er bietet die Fähigkeit, sich nahezu jeder Integrationsumgebung anzupassen und ermöglicht Anwendungen sich exibel in den Bus einzuklinken und andere Anwendungen und Dienste zum Zweck des Datenaustauschs zu nden. Neben Web Services, welche den integralen Bestandteil bilden, können auch andere Protokolle, Nachrichtenumgebungen oder auch Third-Party Adapter Verwendung nden. 2. Standardbasierte Integration: Dies stellt das zentrale Konzept eines ESB dar. Der wichtigste Standard in diesem Bereich ist die Extensible Markup Language (XML) als Datenformat. Als Beschreibungssprachen zur Datentransformation sollten beispielsweise Extensible StyleSheet Language Transformation (XSLT), XML Path Language (XPath) oder XML Query Language (XQuery) verwendet werden. Im Bereich der Web Services spielt die Web Services Description Language (WSDL) als Beschreibungssprache, SOAP als Protokoll und Webservices-BPEL (WS-BPEL) als entsprechende Orchestrierungssprache eine erhebliche Rolle. Des weiteren sollten Java- Standards wie JMS oder JCA, als auch Microsoft-Standards wie Component Object Model (COM) bzw. Distributed Component Object Model (DCOM) und.net unterstützt werden. 3. Hoch verteilte Integration und wählbares Deployment: Diensten muss es möglich sein, über eine hoch verteile Art und Weise zu Interagieren. 4. Verteilte Datentransformation: Aufgrund der unterschiedlichen Datenformate der Anwendungen, als auch Services, welche mit einem ESB verbunden sein könnnen, ist es eine der Kernaufgaben eines ESB, Transformationsdienste zur Verfügung zu stellen, welche für die Transformation des Datenformats von hoch verteilten Anwendungen sorgen. 5. Erweiterbarkeit durch überlagerte Services: Damit unterschiedlichste Integrationsprojekte unterstützt werden können, muss ein ESB überlagerte Services unterstützen. 6. Ereignissteuerung: Services werden als abstrakte Endknoten angesehen, welche auf (asynchrone) Ereignisse reagieren. Das Erreichen einer Nachricht an einem diser Endknoten führt zum Auslösen eines Ereignisses und zur Weiterverarbeitung der Nachricht.

15 2 Grundlagen 7 7. Prozessunterstützung: Die Prozesssteuerung innerhalb eines ESB kann mittels Metadten oder Sprachen wie WS-BPEL geschehen. Die Herausforderung hierbei besteht darin, eine hochverteilte Geschäftsprozessorchestrierung ohne zentrale Steuerungs- oder Ausführungskomponente zu realisieren. Als Steuerung kann hier zum Beispiel intelligentes Routing von Nachrichten angesehen werden, welches die Nachricht anhand ihres Inhalts weiterleitet (Content Based Router (CBR)). 8. Sicherheit und Zuverläsigkeit: Der Aspekt der Sicherheit bezieht sich auf die Absicherung zwischen der Applikation, dem ESB, sowie zwischen den ESB Knoten selbst. Dies wird dadurch ermöglicht, dass die Verbindungen zwischen den Knoten Firewall fähig sind. Auÿerdem wird auf die Konzepte der Authentikation und Autorisierung gesetzt. Die Zuverlässigkeit kann mittels einer hochleistungsfähigen Message Oriented Middleware (MOM) erreicht werden. 9. Autonome aber föderierte Umgebung: Ein ESB unterstützt lokale Autonomie auf der Ebene einer Abteilung oder Geschäftseinheit, ist aber dennoch in der Lage, sich in eine gröÿere Integrationsumgebung einzugliedern. 10. Entfernte Konguration und Management: Es ist nicht immer sinnvoll für ein Unternehmen an allen IT-Standorten auch IT-Personal zu beschäftigen. Trotzdem ist die Notwendigkeit gegeben, diese durch einen ESB miteinander zu verbinden. Dies kann anhand einer Integrationsvorlage geschehen, welche an die zu verwaltenden Geschäftseinheiten ausgeliefert und dort angepasst wird. Diese Vorlage umfasst beispielsweise die Aspekte Schnittstellen, Routing sowie Sicherheitsvorageben. 11. XML als Grundlage: Ein ESB kann einen Vorteil daraus gewinnen, wenn er XML als nativen Datentyp benutzt, da das Datenformat ein ideales Fundament zur Datenrepräsentation darstellt. So können Daten verschiedener Quellen zu neuen Daten kombiniert und Nachrichten erweitert, beziehungsweise transformiert werden. 12. Durchsatz in Echtzeit: Ein ESB liefert das Fundament für den zeitnahen Einblick in live Geschäftsdaten. 13. Operationale Überwachung: Eine wichtige Eigenschaft eines ESB ist die Möglichkeit, einen Einblick in den Zustand sowie Fortschritt von Geschäftsprozessen zu erhalten. Die Verwendung von XML als nativen Datentypen erweist sich in diesem Zusammenhang erneut als sehr hilfreich, da es

16 2 Grundlagen 8 einerseits textbasiert und damit leicht einzusehen ist, andererseits aber auch einen normierten Dateiaufbau besitzt und dadurch von anderen Diensten leicht ausgewertet werden kann. Die Funktionalität, die hierdurch addressiert wird, ist in dem Bereich des Business Activity Monitoring (BAM) angesiedelt. 14. Inkrementelle Anpassung: Die Fähigkeit der inkrementellen Anpassung ist eine der primären Eigenschaften, welche einen ESB von anderen Integrationsansätzen unterscheidet. Jedes individuelle Projekt kann einem viel gröÿeren Integrationsnetzwerk hinzugefügt werden, welches von überall auf dem Bus entfernt verwaltet werden kann Charakterisierung nach Forrester Weiterhin existiert auch eine Charakterisierung durch Vollmer / Gilplin (Forrester) 10, welche die Kernbereiche eines ESB wie folgt beschreiben: 1. Unterstützung für viele Protokolle: Ein ESB muss eine groÿe Bandbreite an Kommunikationsmöglichkeiten (wie Representational State Transfer (REST), SOAP, Windows Communication Foundation (WCF), JMS, etc.) unterstützen, um einerseits neuen Business Anforderungen gerecht zu werden, andererseits aber auch um die Integration von Third-Party und Altsystemen zu unterstützen. 2. Protokollkonvertierung: Ebenso wichtig wie die Unterstützung einer Vielzahl an Protokollen, so ist es auch erforderlich, dass eine Anfrage in Form eines Protokolls in eine Anfrage in Form eines anderen Protokolls umgewandelt werden kann. 3. Datentransformation und datenbasiertes Routing: Ein ESB muss die Möglichkeit besitzen, Daten von einem Datenformat in ein anderes zu transformieren, sowie diese Daten mit neuen Informationen anzureichern bzw. auf Grundlage dieser Daten Routingentscheidungen zu treen. 4. Unterstützung von vielen Verbindungsmöglichkeiten: Ein ESB muss die Möglichkeit bieten, sich mit Datenbank- und Messagingsystemen verbinden zu können, sowie mit Verwaltungstools und anderen Infrastrukturkomponenten einer bestehenden Unternehmensinfrastruktur. 5. Unterstützung zusammengesetzter Dienste durch leichtgewichtige Orchestration Ein ESB sollte das Verbinden von mehreren Diensten 10 [Ful09]

17 2 Grundlagen 9 zu einem gröÿeren, zusammengesetzten, Dienst unterstützen, wobei sich der ESB um die Verwaltung des Prozessusses zwischen den Komponenten kümmert. Die Bezeichnung leichtgewichtig steht im Kontrast zu einer auf Business Process Execution Language (BPEL) basierenden Orchestration. 6. Unterstützung verschiedenster Datenaustauschformate: Viele verschiedene Branchen haben Datenaustauschformate deniert, von denen die neuesten XML basiert sind. Ein ESB sollte mit diesen direkt zusammenarbeiten können. 7. Integrierte Sicherheitsfunktionalitäten: Ein ESB vereinfacht das Bereitstellen von Diensten für die unterschiedlichsten Gemeinschaften durch Authentizierung und Autorisierung. 8. Einen umfassenden Mechanismus zur Fehlerbehandlung: Ein ESB bietet einen einheitlichen Mechanismus um Fehler zu identizieren, zu verwalten und zu überwachen. 9. Unterstützung für synchrone und asynchrone Operationen: Ein ESB muss mit Anfragen und Operationen auf synchrone und asynchrone Weise umgehen können. 10. Hochverfügbare und skalierbare Infrastruktur: Ein ESB ist in der Lage Software- oder Hardewareclustering zu verwenden, um eine Hochverfügbarkeit zu erreichen. Weiterhin hat ein ESB die Möglichkeit Skalierbarkeit anzubieten. 11. Verfügbarkeit einer Vielzahl an Optionen in oben genannten Kategorien: Als eine Integrationsplattform muss ein ESB eine groÿe Anzahl an Optionen bieten. In jeder der oben genannten Kategorien nimmt die Liste der Optionen, welche die meisten Produkte unterstützen, zu. 12. Erweiterbarkeit: Während es für einen ESB enorm wichtig ist, eine Vielzahl an Möglichkeiten in jedem Bereich anzubieten, so ist es eventuell noch viel wichtiger, dass ein ESB seinen Kunden die Voraussetzung bietet, neue Funktionalitäten selbst hinzuzufügen. Beispielsweise die Unterstützung für neue Protokolle oder die Kommunikation mit einem Altsystem über ein selbsterstelltes Messaging System.

18 2 Grundlagen Microsoft BizTalk Server vs ESB Die Firma Microsoft bietet kein Produkt an, welches direkt den Titel ESB trägt, da sie der Meinung sind, dass sie viele der Funktionalitäten, welche für einen ESB charakteristisch sind, bereits mit bestehenden Produkten abdecken können. Dazu zählen einerseits der Microsoft BizTalk Server - eine Integrationsplattform mit Geschäftsprozessunterstützung - sowie die WCF, welche für die Serviceunterstützung sorgt. Betrachtet man die Historie des BizTalk Servers, so ist er ursprünglich der Huband-Spoke Architektur zuzuordnen. Die begründet sich vor allem darin, dass ein Hauptmerkmal der Hub-and-Spoke Architekturen auf der Verwendung von propritäten Standards liegt (vgl. Kapitel 2.1). BizTalk 2000 und 2002 setzte sehr stark auf das sogenannte BizTalk Framework (BTF), welches einen XML-Dialekt und eine SOAP Erweiterung einführte, welche propritär für den BizTalk waren. Dies änderte sich erst mit der Version 2004, welche starken Gebrauch von oenen Standards machte. 11 Zieht man einen Vergleich des BizTalk Servers mit den Charakteristika nach Chappell (vgl. 2.2), so sind die Anforderungen für einen ESB beim BizTalk nicht komplett erfüllt, da Chappell sehr starken Wert auf einen leichtgewichtigen Service-Container legt ESB Toolkit als Erweiterung Kapitel 2.3 führte bereits vor Augen, dass eine pure BizTalk-Installation noch nicht als ein ESB angesehen werden kann. Microsoft stellt seinen Kunden jedoch eine Erweiterung kostenlos zur Verfügung, welche den BizTalk zu einem ESB erweitern soll. Mit BizTalk 2006 wurde zusätzlich die ESB Guidance zur Verfügung gestellt, welche in ESB Toolkit umbenannt wurde und aktuell in der Version 2.1 bereit steht. Nachfolgend seien die wichtigsten Funktionalitäten dieses Toolkits aufgelistet 13 : ˆ Endpunktaundung zur Laufzeit und Virtualisierung - Ein Dienstnutzer muss den Standort des Dienstanbieters und die Endpunktinformationen nicht kennen. Ein neuer oder geänderter Dienstanbieter kann dem ESB hinzugefügt werden, ohne die Dienstnutzer zu unterbrechen. ˆ Lose gekoppelte Dienstkomposition - Der Dienstanbieter und der 11 [Bak05] 12 [Hie07] 13 [Mic11]

19 2 Grundlagen 11 Dienstnutzer müssen nicht über die Art und Weise der Dienstinteraktion bescheid wissen. ˆ Dynamische Nachrichtentransformation und Übersetzung - Die Abbildungsdenition zwischen individuellen Nachrichtenstrukturen sowie die Übersetzung von Nachrichtensemantiken kann zur Laufzeit erfolgen. ˆ Dynamisches routing - Das Routing kann inhaltsbezogen, kontextbezogen oder basierend auf einer sogenannten Itinerary 14 zur Laufzeit erfolgen. ˆ Zentralisiertes Fehlermanagement - Ein Framework zum Fehlermanagement, Dienste als auch Infrastrukturelemente machen es möglich, dass fehlerhafte Nachrichten repariert oder oder neu erstellt werden können. ˆ Dienstgüte - Eine asynchrone Publish und Subscribe Engine ermöglicht verschiedene Ebenen der Dienstverfügbarkeit und bietet Hochverfügbarkeit, Skalierbarkeit und Nachrichtenablaufverfolgung an. ˆ Protokolltransformation - Dienstanbietern und Dienstnutzern wird die Möglichkeit erönet, mittels unterschiedlicher Protokolle zu interagieren. Beispielsweise kann ein Dienstanbieter eine Anfrage per Web Service senden, welche dann im Senden einer Message per Message Queing (z.b. JMS) resultiert. ˆ Erweiterbarkeit - Einführung von mehreren Erweiterungspunkten zur Erweiterung von Funktionen für wie Endpunktermittlung, Message Routing und zusätzlichen BizTalk Adaptern zur Entwurfs- und Laufzeit. Dieses Erweiterungspaket lässt den BizTalk zu einem ESB heranwachsen. Die Konformität zu der Forrester - Charakterisierung (vgl. Kapitel 2.2.2) ist gegeben, was auch aus dem nachfolgenden Zitat 15 hervorgeht. Microsoft bietet seinen BizTalk Kunden starke ESB Kern- Funktionalitäten. Windows zentrierte Kunden mit existierenden BizTalk Implementierungen werden herausnden, dass Microsofts ESB Angebot ein Produkt mit starken ESB Fähigkeiten ist und - als angenehme und willkommene Überraschung - starke Fähigkeiten zur Integration mit Services auf anderen Plattformen bietet. Microsofts hauptsächliche Herausforderung besteht darin, dass sie die ESB Lösung überwiegend in Werzeugkastenform zur Verfügung stellen - 14 engl. Itinerary; dt. Reiseroute 15 [Ful09]

20 2 Grundlagen 12 frei zugängliche ESB-Guidance Informationen und Software, die der Kunde händisch auf eine vorhandene BizTalk Installation mit WCF hinzufügen muss. Diese ESB-Guidance enthält eine volle Referenzimplementation eines funktionierenden ESB. Jedoch müssen sowohl Entwicklungs-, als auch Applikationscode, XML Artefakte direkt manipulieren, da kein grascher Editor zur Verfügung steht. Da dieses Zitat aus dem Jahr 2009 sich auf eine ältere Version des Toolkits bezieht, kann durch die aktuelle Version 2.1 des ESB Toolkits der genannte Kritikpunkt des fehlenden visuellen Editors entkräftet werden, denn mittlerweile steht sehr wohl eine grasche Umgebung dafür bereit.

21 3 Microsoft BizTalk Server Microsoft BizTalk Server 2010 Dieser Abschnitt behandelt die technischen Aspekte des BizTalk Servers Dabei soll die grobe Architektur und die einzelnen Module und Komponenten, sowie die Werkzeuge, die der BizTalk Server zur Verfügung stellt, näher vorgestellt werden. Da eine tiefgründige Betrachtung des BizTalk Servers 2010 den Rahmen dieser Ausarbeitung sprengen würde, soll hier nur auf die Funktionsweise des BizTalk Servers eingegangen werden, um ein grundlegendes Verständnis zu erreichen. 3.1 Architektur des Microsoft BizTalk Server 2010 Der Microsoft BizTalk Server 2010 wurde als Intermediär zwischen Anwendungen konstruiert, was sich in dessen nachrichtenbasierter Architektur widerspiegelt. Die BizTalk Server Architektur, wie in Abbildung 2 dargestellt ist benötigt eine Windows Plattform ab Windows Vista SP2, und setzt zudem das.net Framework ab der Version 4.0 voraus. Abbildung 2: BizTalk Server - Architektur 16 Die Kernfunktionalität des BizTalk Servers ist die Bereitstellung einer Messaging- Infrastruktur zum nachrichtenbasierten Datenaustausch zwischen den angebundenen Anwendungen, wodurch sich einheitliche Geschäftsprozesse realisieren lassen. In der Abblidung 2 lässt sich erkennen, dass der BizTalk Server eine funktionspezische Schichtenarchitektur von fünf Teilschichten aufweist. Die jeweilige Funktion der einzelnen Schichten und ihr Zusammenspiel soll in den nachfolgenden Kapiteln näher beschrieben werden. 16 [vgl. Her05, S. 5]

22 3 Microsoft BizTalk Server Messaging und Orchestration Das Messaging ist eine der Kernfunktionalitäten des BizTalk Server. Wie bereits erwähnt, ist die wesentliche Aufgabe des BizTalk Server Nachrichten (Messages) von Anwendungen zu empfangen, diese eventuell zu verarbeiten und an andere Anwendungen weiter zu senden. In Abbildung 3 ist der Fluss einer Nachricht (Message) dargestellt. Abbildung 3: Datenuss einer Nachricht im BizTalk Server 17 Für das Messaging kommen die unteren drei Schichten der BizTalk Architektur zum Einsatz. Die Transport Adapter Schicht besteht aus Empfangs- (Receive Adapter) und Sendeadaptern (Send Adapter), die verschiedene Transportprotokolle (z.b. SOAP, HTTP, FTP, SMTP u.a.), den Zugri auf Datenbanken über SQL und die Verbindung zu Line of Business Systemen, wie z.b. SAP, unterstützen. Durch sogenannte Ports kann auf die Transport Adapter Schicht von auÿen zugegrien werden. Diese Ports dienen als Schnittstelle für Anwendungen zur Interaktion mit dem BizTalk Server. Jeder Port wird für eine Anwendung und Aufgabe (Ein- oder Ausgabe von Messages) spezisch deniert. Eine durch einen Receive Adapter eingegangene Message wird dann an die nächsthöhere Schicht, die Message Pipeline, weitergeleitet. In dieser Schicht erfolgt die Konvertierung eines speziellen Datenformats einer Anwendung in eine XML Datei (z.b. Comma Sepa- 17 [vgl. Win11, S. 15]

23 3 Microsoft BizTalk Server rated Values (CSV) zu XML), da der BizTalk Server intern nur XML-Dokumente verarbeitet. Die Message Pipeline ist auch für die Umwandlung des internen Biz- Talk XML-Dokuments zu einem Ausgabedatenformat (z.b. XML zu Electronic Data Interchange For Administration, Commerce and Transport (EDIFACT)) für eine empfangende Anwendung zuständig. Neben schon vorgefertigten Pipelines bietet der BizTalk Server die Möglichkeit eigene Pipelines zu denieren. Nach dem die Umwandlung einer Nachricht in das XML-Format abgeschlossen ist, wird die Message in einer Microsoft SQL-Server-Datenbank - der Message Box - abgelegt. Man spricht hier auch vom publishen einer Message. Die Message Box dient als zentrale Schicht, von der aus Messages weiterverarbeitet werden können und sorgt für die Transaktionssicherheit bzw. Konsistenz der Zustände zwischen den angebundenen Systemen. Eine Orchestration oder mehrere Orchestrationen stellen einen Geschäftsprozess dar und bildet somit eine weiter Kernfunktionalität des BizTalk Severs. Mit Orchestrationen lassen sich Ablauogiken für einzelne Geschäftsprozesse erstellen. In ihr werden Reihenfolgen für den Zugri auf verschiedene Systeme und Verzweigungen im Prozess festgelegt. Jede Orchestation ist ein Subscriber bei der Message Box und gibt dort bekannt welche Messages übermittelt werden sollen. Die Subscription der Orchestration in der Message Box dient als Kriterium nach der die Messages geltert werden. Solche Kriterien können z.b. die Art, spezielle Eigenschaften oder Inhalte der Nachricht sein. Nach der Verarbeitung einer Message durch eine Orchestrierung, wird das Ergebnis in Form einer neuen Message in die Message Box geschrieben. Die Nachrichtenverarbeitung innerhalb des BizTalk Servers ist symmetrisch aufgebaut. So gehen Messages von einer Orchestrierung über die Message Box bis hin zur Zielanwendung, den umgekehrten Weg wie beim Empfangen von Nachrichten. Die zu sendende Message wird aus der Message Box zu einer Send Pipeline geschickt. Dort wird das XML-Dokument in ein anwendungspezisches Datenformat konvertiert und über einen passenden Send Adapter durch einen Send Port zur Endanwendung gesendet Weitere Komponenten Neben dem Messaging und der Orchestration, bietet der BizTalk Server noch weitere erwähnenswerte Komponenten an. Da diese Komponenten bei der Umsetzung des Loan Broker nicht zum Einsatz kamen, sollen die einzelnen Module hier nur kurz vorgestellt werden ˆ Business Rule Engine : Im Gegensatz zu Orchestrationen deren Ablauflogik sich nur selten ändert, dient die Business Rule Engine (BRE) zur

24 3 Microsoft BizTalk Server Denition von Regeln innerhalb einer Orchestration die sehr kurzen Änderungszyklen unterworfen sind. Durch die BRE wird die Steuerung der Ablauogik von der eigentlichen Ablauogik getrennt (z.b. erfüllt eine Kreditanfrage die vorausgesetzten Regeln einer Bank). ˆ Business Acitvity Monitoring : Hier werden permanent Daten aus laufenden Geschäftsprozessen gesammelt und in einer Datenbank abegelgt. Die Nutzer dieser Geschäftsprozesse können dann über eine Web-Anwendung, dem sogenannten BAM -Portal, den momentanen Zustand dieser Prozesse abrufen. ˆ EDI-Services : Seit BizTalk Server 2009 ist eine EDI Komplettlösung in das System integriert. Die EDI Services bieten eine einfache Möglichkeit den UN/EDIFACT Standard (United Nations Electronic Data Interchange For Administration, Commerce and Transport) in ein XML-Format zu konvertieren, was ohne solche Hilfsmittel sehr aufwendig sein kann. 3.2 Entwicklungswerkzeuge Die Entwicklung von BizTalk Server 2010 Anwendungen erfolgt innerhalb der Entwicklungsumgebung Visual Studio 2010 Professional Edition oder Ultimate. Bei der Installation des BizTalk Servers wird das Visual Studio um folgende BizTalk-Spezische Werkzeuge erweitert: ˆ Schema Editor ˆ Mapping Editor ˆ Pipeline Designer ˆ Orchestration Designer ˆ Diverse Wizards In der Regel bestehen BizTalk Anwendungen aus XML Schema Denition (XSD) Schemas, XSLT-Mappings, Pipelines und Orchestrations, die mit den oben genannten Werkzeugen komfortabel erstellt und erweitert werden können Schema Editor Damit eingehende Nachrichten vom BizTalk Server verarbeitet werden können, muss bekannt sein, welche Daten in welchem Datentyp (z.b. int, string) in der Nachricht enthalten sind. Das gleiche gilt auch für ausgehende Nachrichten. Mit

25 3 Microsoft BizTalk Server dem Schema Editor werden XSD Schemas erstellt und bearbeitet. Unterstützt werden Datenformate wie Flat-Files (z.b. CSV), EDIFACT, SWIFT und weitere. Abbildung 4: Schema Editor Mapping Editor Bei Integrationsprojekten ist es oft notwendig, Nachrichten von einem Schema in eine anderes zu überführen. Der Mapping Editor dient dem Entwickler dazu Datenstrukturen intuitiv umzuformen. Es kann vorkommen, dass Werte nicht 1:1 von einem Schema in ein anderes übernommen werden können, da eventuell die Datentypen nicht übereinstimmen oder Daten aus einem Schema erst berechnet werden müssen und das Ergebnis dann als ein neues Datum im anderen Schema eingefügt werden muss. Für solche Sonderfälle bietet der Mapping Editor sogenannte Functoids, die von einfachen Konvertierungen und Berechnungen bis hin zur Einbettung von C# Code eine Vielzahl von Funktionen bieten Pipeline Designer In Kapitel wurde erwähnt, dass es Möglich ist eigene Pipelines zu denieren. Dazu kann ein Entwickler den Pipeline Designer verwenden. Grundsätzlich gibt es Receive und Send Pipelines. Der BizTalk Server bringt von Haus aus schon eine Fülle von Pipelines mit, so dass für die Umsetzung des Loan Broker Beispiels keine neue Pipeline erstellt werden musste.

26 3 Microsoft BizTalk Server Abbildung 5: Mapping Werkzeug Orchestration Designer Der Orchestration Desigener ermöglicht es dem Entwickler mit einem graschen Werkzeug die Ablauogik eines Geschäftsprozesses zu modellieren. Somit fällt die häug komplexe und zeitintensive Entwicklung einer Orchestration mit einer konventionellen Programmiersprache fast vollständig weg. Es gibt trotzdem die Möglichkeit eigenen Quellcode oder externe.net Assemblys innerhalb einer Orchestration zu verwenden. Für das Modellieren stellt der Orchestration Designer verschiedene Shapes zur Verfügung, die per Drag and Drop zu einem Gesamtprozess kombiniert werden können. Abbildung 6: Orchestration Designer mit Shapes

27 3 Microsoft BizTalk Server Diverse Wizards Neben den oben erwähnten Design Werkzeugen bietet der BizTalk Server innerhalb der Visual Studio Umgebung noch weitere kleine Wizards an, welche das Erstellen von diversen BizTalk Anwendungsfunktionen erleichtert. Hier sollen nur die Wizards erwähnt werden, die auch für die Umsetzung des Beispielprojekts zum Einsatz kamen. ˆ BizTalk Web Services Publishing Wizard: Dieser Wizard dient dazu eine Orchestration über den Microsoft Internet Information Server als SOAP konformen Web Service zu publizieren. ˆ Add Service Reference: Mit diesem Wizard ist es möglich, beliebige SOAP konforme Web Services innerhalb einer Orchestration zu nutzen. Der eingebundene Web Service muss dafür noch an einen Port gemappt werden. ˆ Port Conguration Wizard: Hiermit ist es möglich Inbound und Outbound Ports innerhalb einer Orchestration zu erstellen und zu kongurieren. 3.3 BizTalk Server Administration Console Die BizTalk Server Administration Console ist das primäre Management Werkzeug für den BizTak Server. Die Console bietet eine grasche Oberäche um veröentlichte BizTalk Anwendungen zu installieren, kongurieren und zu betreiben. Zudem stellt es Tools für die Fehlerbehandlung, die während der Laufzeit von BizTalk Anwendungen auftreten können, zur Verfügung. Eine komplette BizTalk Anwendung ist kein monolithisches Programm, sondern besteht aus vielen kleineren Einheiten. Jede dieser Einheiten ist separat unter der BizTalk Server Administation Console kongurierbar. Dazu zählen ˆ Orchestration: Die Orchestration, die mit dem Orchetration Designer entwickelt wurden, können hier gestartet oder gestoppt werden. Nur gestartete Orchetrationen können verwendet werden. ˆ Send Ports: Ein Send Port ist ein BizTalk Objekt, das ausgehende Nachrichten durch eine Pipeline an ein bestimmtes Ziel sendet. Auch diese Send Ports können gestartet und gestoppt werden. ˆ Receive Ports: Ein Receive Port ist eine logische Ansammlung von ähnlichen Receive Locations.

28 3 Microsoft BizTalk Server ˆ Receive Locations: Recieve Locations sind Adressen, an die eingehende Nachrichten durch eine Pipeline zur Weiterverarbeitung innerhalb des Biz- Talks Servers gesendet werden können (z.b. die Adresse eines Web Service). ˆ Schemas: Hier werden alle Schemas, die innerhalb einer BizTalk Anwendung verwendet werden, aufgelistet. ˆ Maps: In den Maps werden alle Transformationen aufgelistet, die mit dem Mapping Werkzeug erstellt wurden. ˆ Resources: In den Resources sind alle verwendeten.net Assemblys aufgelistet. Jede Orchstration ist eine Assembly. Es können aber auch externe.net Assemblys eingebunden sein. Abbildung 7: BizTalk Server Administration Console

29 4 Der Loan Broker mit BizTalk Der Loan Broker mit BizTalk 2010 In diesem Kapitel soll auf die konkrete Umsetzung des Loan Broker Beispiels mit dem BizTalk Server 2010 eingegangen werden. Beginnend mit dem Installationsprozess der benötigten Softwarepakete, werden in weiteren Unterkapiteln das nale Konzept der Loan Broker Anwendung und Schritt für Schritt die endgültige Umsetzung vorgestellt. 4.1 Der Installationsprozess Die Installation des BizTalk Server 2010 verlief weitestgehend problemlos. Dies ist vor allem der sehr guten Installationsanleitung zu verdanken, die Microsoft kostenlos für verschiede Windows-Plattformen zu Verfügung stellt. Verwendet wurde der frei erhältliche BizTalk Server Developer Edition. Der BizTalk Server wurde auf zwei unabhängigen Systemen installiert. Als Plattformen kamen jeweils ein Windows Server 2008 R2, welcher auf der virtuellen Maschine VMWare-Player Version 3 von VMWare installiert wurde und ein nativ installiertes Windows 7 Professional zum Einsatz. Beide Systeme sind 64 Bit Umgebungen, so wie die verwendete Software. Zudem wurde entschieden auf der Windows Server 2008 R2 Plattform eine komplett deutsche Installation durchzuführen, wohingegen auf dem Windows 7 Professional System die komplette Software in englische Sprache installiert wurde. Der BizTalk Server ist keine eigenständige Software, sondern seine Funktionalität hängt von weiteren Produkten aus dem Hause Microsoft ab. So werden folgende weitere Produkte für eine erfolgreiche Installation benötigt: ˆ Internet Information Server (IIS) ab Version 6.1 ˆ.NET Framework 4 ˆ Microsoft Excel 2010 oder 2007 (für Business Activity Monitoring) ˆ Visual Studio 2010 (Professional oder Ultimate) für die Entwicklung ˆ Microsoft SQL-Server 2008 R2 SP1 ˆ SQL-Server 2005 Notication Services ˆ BizTalk Server Developer Edition Folgende Regeln sind bei der Installation dringend zu beachten:

30 4 Der Loan Broker mit BizTalk ˆ Die Softwarepakete müssen in der Reihenfolge wie oben beschrieben installiert werden. ˆ Es wird von Microsoft empfohlen, die gesamte Software entweder komplett in einer 64 Bit oder 32 Bit Architektur zu installieren. Ein Mischen beider Architekturen kann zu Problemen führen. ˆ Zwischen den Installationen der jeweiligen Softwarepakete müssen diverse Kongurationen am System vorgenommen werden. Diese sind genau zu dem Zeitpunkt durchführen, wie Sie in der Installationsanleitung beschrieben sind. Abbildung 8: Eine erfolgreiche BizTalk Server Installation Die Installation dauert im allgemeinen sehr lange und kann je nach Leistungsfähigkeit des System bis zu 4 Stunden in Anspruch nehmen. Es wird sehr viel Speicherplatz benötigt und ein Teil der installierte Software gräbt sich tief in das Betriebssystem ein, so dass die Installation ohne virtuelle Maschine wohl überlegt sein sollte. An einigen Stellen während der Installation, werden auch Kenntnisse mit den Windows Betriebssystemen vorausgesetzt. Vor allem, wenn Nutzerberechtigungen eingerichtet werden müssen. Wie eingangs erwähnt, lief die Installation beider Systeme weitestgehend reibungslos, doch sollte an dieser Stelle doch noch ein kleines Problem erwähnt werden. Bei der Installation der SQL-Server 2005 Notications Services gibt es Versionsunstimmigkeiten. So bietet Microsoft auf unterschiedlichen Webseiten verschieden Versionen dieser Dateien an, die aber genau gleich bezeichnet sind. Wird

31 4 Der Loan Broker mit BizTalk die falsche Version installiert, schlieÿt die BizTalk Server Installation mit einem Fehler ab. 4.2 Architektur des Loan Broker Basierend auf dem Szenario in Abbildung 1 auf Seite 3 wurde eine Architektur erstellt, bei der die einzelnen Prozessschritte mit Enterprise Integration Patterns modelliert wurden. Das nale Ergebnis ist in Abbildung 9 abstrakt illustriert, ohne auf technische Details der Implementierung einzugehen. Abbildung 9: Finale Architektur Gemäÿ der Architektur ergibt sich folgender Ablauf: 1. Der Kunde stellt eine Kreditanfrage über eine Web-Anwendung an den Loan Broker. 2. Der Loan Broker nimmt diese Anfrage entgegen und ermittelt über einen Web Service beim Kreditbüro die Kreditwürdigkeit des Kunden. Über einen Content Enricher wird die Anfrage des Kunden mit den Daten Kreditwürdigkeit und Kredithistorie aus der Antwortnachricht des Kreditbüros erweitert. Das Credit Bureau benötigt auÿer der Social Security Number (SSN) keine weiteren Daten des Kunden. Die Aufgabe, Daten zu ltern übernimmt das Muster Content Filter.

32 4 Der Loan Broker mit BizTalk Die Kreditanfrage des Kunden soll nun an die einzelnen Banken weitergeleitet werden, welche jeweils über einen Web Service angebunden sind. Da die Banken die Kreditwürdigkeit des Kunden für die Kreditvergabe benötigen, wird die zuvor angereicherte Nachricht verwendet. Eine Recipient List ist dafür zuständig, dass die Kundenanfrage nur an die Banken weitergereicht wird, welche sich für die Kreditanfrage interessieren. Diese Auswahl wird auf Grundlage der Kreditwürdigkeit und der Kredithistorie innerhalb der Recipient List getroen. 4. Nachdem jede Bank den Antrag auf einen Kredit bearbeitet hat, senden diese die Kreditkonditionen zurück zum Loan Broker. Dieser aggregiert die Antwort der Banken und ermittelt den besten Kredit. 5. Im letzten Schritt erhält der Kund das beste für ihn ermittelte Kreditangebot zu seiner Anfrage als Antwort innerhalb der Web-Anwendung zurück und wird zudem durch den Versand einer mit dem Kerditangebot asynchron informiert. 4.3 Umsetzung mit Microsoft BizTalk Dieses Unterkapitel beschreibt die konkrete Umsetzung des Loan Broker. Zur besseren Orientierung ist die Abbildung 10 auf der nächsten Seite in mehrere Segmente aufgeteilt. Die Buchstaben repräsentieren verschiedene Komponenten der Realisierung, die römische Nummerierung Funktionsbereiche und die arabischen Zahlen die einzelnen Prozessschritte innerhalb des Loan Broker. Anhand dieser Nummerierung soll in den nachfolgenden Unterkapiteln die technische Umsetzung mit dem BizTalk Server sowie die allgemeine Funktion schrittweise erklärt werden A - Der Web Client Damit der Kunde seine Kreditanfrage stellen kann, steht ihm ein Web Client zur Verfügung (siehe Abbildung 11 auf der nächsten Seite), der mit Spring MVC realisiert ist. Hierzu muss der Kunde seinen Vor- und Nachnamen, seine - Adresse und SSN sowie die Kredithöhe als auch die Kreditdauer eingeben. Wenn er seine Eingaben quittiert, greift der Web Client über einen Web-Service auf den Loan Broker zu und stöÿt den Loan Broker Prozess an. Der Kunde kann darauf hin mit einer zeitnahen Antwort rechnen. Das Ergebnis seiner Anfrage sieht aus wie in Abbildung 12 auf Seite 26.

33 4 Der Loan Broker mit BizTalk Abbildung 10: Finale unterteilte Architektur Abbildung 11: Der Web Client / Kreditanfrage Als Antwort erhält der Kunde neben seiner SSN den angebotenen Zinssatz für seinen Kredit und eine Anfrage-ID, die er bei der Bank für dieses Angebot vorlegen kann B - Das Credit Bureau Das Credit Bureau selbst wurde als eigenständige BizTalk-Orchestration erstellt und stellt die Funktion GetCreditScore() als Schnittstelle zur Verfügung. Durch den Web Publishing Wizard (vergleiche 3.2.5) wird diese als ein SOAP konformer ASP.NET Web Service bereitgestellt. Die Hauptaufgabe der Orchestration ist

34 4 Der Loan Broker mit BizTalk Abbildung 12: Der Web Client / Kreditangebot es, eine Nachricht zurückzusenden, welche die Kreditwürdigkeit (CreditScore) und die Kredithistorie (HistoryLength) beinhaltet. Da dem Credit Bureau kein echtes Rating-System zur Verfügung steht, werden die gewünschten Werte durch einen Algorithmus zufällig berechnet. Abbildung 13: Die Credit Bureau Orchestration Die Credit Bureau Orchestration besitzt einen Port durch den die Nachrichten eingehen und zurückgesendet werden. Eine CreditBureauRequest Message gelangt über den Port-Eingang durch das Receive Shape zur Weiterverarbeitung in die Orchestration. Das Transform Shape transformiert notwendige Daten der Credit- BureauRequest Message in eine CreditBureauReply Message. Die Abbildung 14 auf der nächsten Seite zeigt das zugrunde liegende Mapping. Die CreditBureauReply Message benötigt neben diesen Daten noch zusätzlich die bereits erwähnten Werte CreditScore und HistoryLength. Diese Werte lassen sich in BizTalk durch Funktoide errechnen. Jedem Funktoid ist ein spezieller

35 4 Der Loan Broker mit BizTalk Abbildung 14: Erzeuge Message CreditBureauReply Algorithmus zur Berechnung eines Zufallswertes in Form eines inline C# Skripts hinterlegt. Die zugehörigen Funktionen sind in nachfolgender Auistung abgebildet. 1. CreditScore: 1 public int GetCreditScore() 2 { 3 Random random = new Random(); 4 return (int)(random.next(600) + 300); 5 } 2. HistoryLength: 1 public int GetHistoryLength() 2 { 3 Random random = new Random(); 4 return (int)(random.next(19) + 1); 5 } C - Die Banken Im Gegensatz zum Credit Bureau sind die Banken nicht als Orechestration implementiert, sondern liegen in Form eines Visual C# ASP.NET Web Service Projekts vor. Jede Bank läuft als eigener Web Service und bietet die Schnittstellenfunktion GetLoanQuote() an. Es sind drei Banken implementiert, die unterschiedliche Charakteristiken aufweisen. ˆ Bank 1: Consumer Bank Maximale Kreditdauer: 48 Monate Kreditwürdigkeit: >= 500 Kredithistorie: >= 5 Jahre ˆ Bank 2: Exclusive Bank Maximale Kreditdauer: 60 Monate

36 4 Der Loan Broker mit BizTalk Kreditwürdigkeit: >= 700 Kredithistorie: >= 10 Jahre ˆ Bank 3: Loan Shark Maximale Kreditdauer: 72 Monate Kreditwürdigkeit: Nicht benötigt. Kredithistorie: Nicht benötigt. Info: Bank vergibt auf jede Anfrage einen Kredit, aber mit sehr hohen Zinssätzen D - Der Loan Broker Der Loan Broker bildet das Hauptsystem des gesamten Projekts und integriert den Web Client, das Credit Bureau und die Banken so, dass ein vollständiger Geschäftsprozess entsteht. Wie auch das Credit Bureau ist der Loan Broker eine Orchestration und veröentlicht die Schnittstelle GetLoanQuote() als einen SOAP konformen ASP.NET Web Service, die vom Web Client aufgerufen wird. Die nachfolgenden Unterkapitel beschreiben detailliert die Ablauogik des Loan Brokers I. Kreditbüroanfrage Der Bereich Kreditbüroanfrage nimmt die Message LoanQuoteRequest entgegen und transformiert die Nachricht in einen CreditBureauRequest und sendet diesen an das Credit Bureau. 1. Wire Tap: Ein Wire Tap ist im Rahmen der Enterprise Integration Patterns (EIP) zuständig für das Speichern von Nachrichten in einem Message Store, um diese zu einem späteren Zeitpunkt wiederzuverwenden oder für eine eventuelle Fehlersuche. Das hier abgebildete Wire Tap und die Speicherung in dem Message Store steht symbolisch für die Tatsache, dass die Nachrichten einer Orchestration in der Message Box des BizTalk Servers gespeichert sind. Siehe dazu Kapitel Dadurch entsteht der Vorteil, dass innerhalb einer Orchestration an jeder beliebeigen Stelle auf die Nachrichten und ihre Daten zugegrien werden kann. 2. Erzeuge Message CreditBureauRequest: Dieser Schritt steht für die Erstellung der CreditBureauRequest Nachricht. Dies

37 4 Der Loan Broker mit BizTalk Abbildung 15: Bereich Kreditbüroanfrage ist notwendig, da das Credit Bureau nicht alle Daten des Kunden benötigt, sondern nur das konkrete Datum SSN. Diesen Filter-Prozess, wie er auch in der abstrakten Architektur skizziert ist (vgl. Auistungpunkt 2 in Kapitel 4.2), kann innerhalb der Orchestration durch den Message Translator erzielt und durch den Mapping Editor (siehe dazu Abbildung 16) konguriert werden. Abbildung 16: Erstelle Kreditbüroanfrage II. Kreditanfrage an die Banken Im Bereich II wird die Antwortnachricht des Credit Bureau (CreditBureauReply) empfangen und an die drei Banken verteilt. Für diese Verteilung eignet sich die Recipient List aus den EIP und ndet ihr entsprechendes BizTalk Gegenstück im Parallel Shape. Die Banken werden dabei als Recipients angesehen. Da jede Bank unterschiedliche Anforderungen für die Kreditvergabe hat (siehe dazu Kapitel 4.3.3), muss vor der Nachrichtenverteilung an die Banken eine Auswahl in Form von Regeln getroen werden. Abbildung 17 auf der nächsten Seite zeigt

38 4 Der Loan Broker mit BizTalk den dazugehörigen Prozessausschnitt innerhalb der Orchestration. Abbildung 17: Gesamtansicht Banken 3. Verteilen der Messages an die Banken: Das Parallel Shape besitzt Verzweigungen, die parallel zueinander ablaufen. In der dieser Ausarbeitung zugrunde liegenden Implementierung kapselt jede Verzweigung jeweils die Aufruogik pro Bank. Abbildung 18 auf der nächsten Seite illustriert dies anhand der Bank Denition der Regeln: Die bereits angedeuteten Regeln für die Auswahl der Banken, entsprechend ihrer Anforderungen für die Kreditvergabe, lässt sich über eine sogenannte Entscheidung (siehe Abbildung 19 auf der nächsten Seite) realisieren, die fester Bestandteil eines Zweigs innerhalb des Parallel Shapes ist. Bezogen auf die EIP entspricht dieser Ansatz einem Message Filter. Den, bei so einer Regel hinterlegten, C# Code zeigt nachfolgendes Code-Listing beispielhaft für die entsprechende Entscheidung bei der Bank 1. 1 CreditBureauReplyMsg.GetCreditScoreResult.CreditScore >= 500 && 2 CreditBureauReplyMsg.GetCreditScoreResult.HistoryLength >= 5 5. Erzeuge Message BankRequest:

39 4 Der Loan Broker mit BizTalk Abbildung 18: Detailansicht der Bank 1 Abbildung 19: Denition der Regeln Nachdem durch die denierten Regeln der Prozessuss in den Verzweigungen der interessierten Banken angekommen ist, muss die Anfrage an die Banken in Form der BankRequest Nachricht gebildet werden. Diese setzt sich aus den Daten von jeweils zwei Nachrichten zusammen. Aus der ursprünglichen Anfragenachricht LoanRequest sind die SSN sowie der LoanTerm und aus der Antwortnachricht des Credit Bureau der CreditScore als auch die HistoryLength weiter zu verwenden. Umgesetzt ist das durch den Transform Mapper, welcher dank der gespeicherten Nachrichten in der Message Box zeitgleich auf beide Nachrichten zugreifen kann. Abbildung 20 auf der nächsten Seite zeigt dieses Mapping von zwei Nachrichten zu einer Nachricht.

40 4 Der Loan Broker mit BizTalk Abbildung 20: Erzeuge BankRequest III. Antworten der Kreditanfrage bearbeiten Der Zweck des in diesem Unterkapitel beschriebenen Bereiches ist die Aggregation der Bankantworten und die Erstellung einer entsprechenden Antwortnachricht an den anfragenden Kunden. Die Aggregation sorgt für die Auswahl des besten Kreditangebots der Banken. Abbildung 21 illustriert den Teilprozess. Abbildung 21: Bereich Antwort Kreditanfrage 6. Aggregiere zu Message BestBankQuote:

41 4 Der Loan Broker mit BizTalk Der Aggregator steht als eine.net Assembly zur Verfügung und ist in C# programmiert. Er wertet die Antworten der Banken aus, ermittelt den besten Kredit und baut daraus die Nachricht BestBankQuote zusammen. Seine Funktionalität steht nach der Kompilierung in der Datei BankQuoteAggregator.dll zur Benutzung bereit und wird über nachfolgendes Code Listing in der Orchestration über ein Assignment Shape verwendet. 1 BestBankQuoteMsg = QuoteAggregator.GetResultMessage(); 7. Erzeuge Message LoanQuoteReply: An dieser Stelle wird die Antwortnachricht (LoanQuteReply) für den Kunden erzeugt. Da in der zugrunde liegenden Lösung ein Web Client zum Einsatz kommt (vgl. Kapitel 12 auf Seite 26) dient der Inhalt von LoanQuoteReply der Antwortseite des Web Client als Datengrundlage und informiert den Loan Broker Kunden über das bestmögliche Kreditangebot. Der LoanQuoteReply wird aus den Daten der Nachrichten LoanQuoteRequest und BestBankQuote erstellt (vgl. Abbildung 22). Wieder ist der gleichzeitige Zugri auf mehrere Nachrichten aufgrund der Message Box möglich. Abbildung 22: Erzeuge LoanQuoteReply IV. an den Kunden senden Zusätzlich zur zuvor beschriebenen Loan Broker Antwortnachricht, ist eine asynchrone Information über das beste Kreditangebot gewünscht. Eine an den Kunden setzt diese Asynchronität um. Abbildung 23 auf der nächsten Seite gibt eine Übersicht über den Teilablauf.

42 4 Der Loan Broker mit BizTalk Abbildung 23: Bereich 8. Erzeuge Message LoanBrokerMail: Die Realisierung der im vorangegangenen Kapitel beschriebenen Logik erfordert mehrere Schritte. Zuerst muss die Nachricht LoanBrokerMail für den nachfolgenden Schritt erzeugt werden. Erreicht wird das durch ein Tranform Shape, welches mittels des Mapping Editors (vgl. Abbildung 24), der Nachricht LoanBrokerMail, die adresse des Kunden aus der Nachricht LoanQuoteReply zuweist. Abbildung 24: Erzeuge LoanBrokerMail Erst nachdem die Nachricht LoanBrokerMail erzeugt (initialisiert) wurde, ist es möglich im Assignment Shape mit dem Namen MailAssignment die unter Verwendung von C# Code dynamisch zusammen zu stellen. Das geschieht über nachfolgendes Code Listing. 1 LoanBrokerMailOutMsg = LoanBrokerMailOutMsg; 2 Port_LoanBrokerMailOut(Microsoft.XLANGs.BaseTypes.Address) = "mailto:" + LoanBrokerMailOutMsg.To; 3 LoanBrokerMailOutMsg(SMTP. BodyTextCharset) = "UTF-8"; 4 LoanBrokerMailOutMsg(SMTP.From) = 5 LoanBrokerMailOutMsg(SMTP.Subject) = "Ihre Anfrage für einen Kredit vom " + System.DateTime.Now.ToString() + "."; 6 LoanBrokerMailOutMsg(SMTP. BodyText) =

43 4 Der Loan Broker mit BizTalk "Sehr geehrte(r) " + LoanQuoteRequestMsg.FirstName + " " + LoanQuoteRequestMsg.LastName + ",\r\n\r\n" + 8 "Vielen Dank für Ihre Anfrage.\r\n" + 9 "Unsere Systeme haben folgende Bank für Ihren gewünschten Kredit ermittelt:\r\n\r\n" + 10 "Kredithöhe : " + System.String.Format("{0:0.00}",System.Convert.ToString(LoanQuoteRequestMsg.LoanAmount)) + " \r\n" + 11 "Kreditdauer : " + System.Convert.ToString(LoanQuoteRequestMsg.LoanTerm) + " Monate\r\n" + 12 "Zinssatz : " + System.Convert.ToString(BestBankQuoteMsg.InterestRate) + "%\r\n" + 13 "Anfrage-ID : " + BestBankQuoteMsg.QuoteID + "\r\n\r\n" + 14 "Mit freundlichen Grü"sen,\r\n" + 15 " Ihr LoanBroker-Team"; Das tatsächliche Senden der ist über einen, an einen Simple Mail Transfer Protocol (SMTP) Adapter gekoppelten, dynamischen Port realisiert. Der dynamische Port konguriert sich im Gegensatz zu einem statischen Port zur Laufzeit der Orchestration. So kann er sich jedes mal, abhängig von der Kunden- -Adresse, neu einrichten. Abbildung 25 zeigt das Ergebnis des dynamischen Erstellens und Sendens der anhand eines ktiven Loan Broker Kunden. Dieser erhält die Benachrichtung über die Konditionen des bestmöglichen Kreditangebots. Abbildung 25: Antwort 4.4 Aufgetretene Probleme Obwohl bei der Entwicklung des Loan Broker das Whitepaper Enterprise Integration Patterns with BizTalk Server als Hilfe diente, verlief die Entwicklung nicht ganz unproblematisch. Eines der Hauptursachen dafür war der Versionsunterschied zwischen der Version BizTalk Server 2004, die im Whitepaper Verwendung fand und der Version BizTalk Server 2010, welcher als Entwicklungsplattform für den Loan Broker zum Einsatz kam. Dabei führten weniger die BizTalk Server Unterschiede zu Problemen, als die benötigten Technologien. BizTalk Server 2004 basiert auf.net 1.0 und verwendet das Visual Studio.NET (2003) 18 [HT04]

Abschlusspräsentation Projekt Loan Broker mit BizTalk 2010

Abschlusspräsentation Projekt Loan Broker mit BizTalk 2010 Abschlusspräsentation Projekt Loan Broker mit BizTalk 2010 Vortrag im Rahmen der Vorlesung Integration Engineering Dozent: Prof. Dr. Martin Buchheit SS 2011 Referenten: Florian Kalisch, Denis Radjenovic

Mehr

1 BizTalk Server-Einführung... 17. 2 Einführung in die Entwicklung einer BizTalk-Anwendung... 69

1 BizTalk Server-Einführung... 17. 2 Einführung in die Entwicklung einer BizTalk-Anwendung... 69 Auf einen Blick 1 BizTalk Server-Einführung... 17 2 Einführung in die Entwicklung einer BizTalk-Anwendung... 69 3 Einführung in die Administration einer BizTalk-Anwendung... 181 4 BizTalk-Einsatz... 225

Mehr

Die Windows Workflow Foundation in Microsoft.NET 3.0

Die Windows Workflow Foundation in Microsoft.NET 3.0 Die Windows Workflow Foundation in Microsoft.NET 3.0 Klaus Rohe (klrohe@microsoft.com) Developer Platform & Strategy Group Microsoft Deutschland GmbH Agenda Was ist Windows Workflow Foundation? Microsoft

Mehr

Business Process Management und Enterprise Service Bus

Business Process Management und Enterprise Service Bus Business Process Management und Enterprise Service Bus Gegner oder doch eine gute Ergänzung? Author: Date: Markus Demolsky Soreco International 08. November 2010 Vortragender Warum über Integration nachdenken?

Mehr

PRODATIS CONSULTING AG. Folie 1

PRODATIS CONSULTING AG. Folie 1 Folie 1 Führend im Gartner Magic Quadranten für verteilte, interagierende SOA Projekte Oracle ist weltweit auf Rang 1 auf dem Markt der Enterprise Service Bus Suiten (ESB) für SOA Software 2010 26,3 %

Mehr

Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant

<Insert Picture Here> Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant Oracle Business Process Analysis Suite Gert Schüßler Principal Sales Consultant 1 Geschäftsprozesse Zerlegung am Beispiel Kreditvergabe Antrag aufnehmen Antrag erfassen Schufa Kunden

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final Systembeschreibung Masterplan Kommunikationsinterface ASEKO GmbH Version 1.0 Status: Final 0 Inhaltsverzeichnis 1 Einleitung... 2 2 Architektur... 2 2.1 Anbindung an die MKI Lösung... 2 2.2 Inbound Kommunikationsmethoden...

Mehr

Die nächste Revolution in der modelgetriebenen Entwicklung?

Die nächste Revolution in der modelgetriebenen Entwicklung? Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF

Mehr

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

Mehr

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011 Lastenheft swp11-4 3. Mai 2011 Zielbestimmungen In der heutigen Geschäftswelt stehen mittelständische Unternehmen vor dem Dilemma, einerseits interne und externe Kommunikation in angemessener Weise gewährleisten

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Geschäftsprozessmodellierung essmodellierung mit BPEL

Geschäftsprozessmodellierung essmodellierung mit BPEL Geschäftsprozessmodellierung essmodellierung mit BPEL Autor: Stefan Berntheisel Datum: 8. Januar 2010 Stefan Berntheisel Hochschule RheinMain Fachseminar WS 09/10 Agenda Grundlagen Business Process Execution

Mehr

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum Analyse der Android Plattform Andre Rein, Johannes Florian Tietje FH-Gieÿen-Friedberg Android Praktikum 28. Oktober 2010 Topics 1 Übersicht Android Plattform Application Framework Activities und Services

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Business Rules und SOA. Parallelen und Synergien

Business Rules und SOA. Parallelen und Synergien Business Rules und SOA Parallelen und Synergien White Paper Januar 2008 Innovations Software Technology GmbH, 2008. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Stand September 2010. TransConnect Die Plattform für skalierbare Anwendungsintegration

Stand September 2010. TransConnect Die Plattform für skalierbare Anwendungsintegration Stand September 2010 TransConnect Die Plattform für skalierbare Anwendungsintegration Herausforderungen für EAI-Lösungen Spezialisierte Anwendungssysteme ERP CRM ecommerce Gesundheitswesen Produktion Herausforderungen

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

EDI/XML Datentransaktionen über System- und Unternehmensgrenzen. Referent: Jan Freitag

EDI/XML Datentransaktionen über System- und Unternehmensgrenzen. Referent: Jan Freitag EDI/XML Datentransaktionen über System- und Unternehmensgrenzen Referent: Jan Freitag Warum EDI? Internet bedeutender Wirtschaftsfaktor Nur wenige Unternehmen steuern Geschäftsprozesse über das Internet

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa Dr. Stefan Pietschmann, PF Service-Oriented Enterprise Applications, T-Systems MMS Dresden, 22.10.2013 About US PF42 Service-oriented enterprise

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Windows Azure-Integration

Windows Azure-Integration Windows Azure-Integration On-Premise Services und Benutzerdaten an die Cloud anbinden Jürgen Mayrbäurl Architect Evangelist Microsoft Österreich jurgenma@microsoft.com Andreas Winterer Geschäftsführer

Mehr

Geschäftsprozesse automatisieren mit Biztalk Server 2004. Integrierte E-Business-Lösungen für die Windows Welt

Geschäftsprozesse automatisieren mit Biztalk Server 2004. Integrierte E-Business-Lösungen für die Windows Welt Geschäftsprozesse automatisieren mit Biztalk Server 2004 Integrierte E-Business-Lösungen für die Windows Welt Motivation und Grundlagen Ein typischer Ist-Zustand im Unternehmen mit seinen Haken und Ösen

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE PROZESSE INTEGRIEREN leicht gemacht DURCH TransConnect Geschäftsprozesse ableiten mit der Universal Worklist (UWL) Integrationsszenarien effektiver verwalten und transportieren Optimierte Personalverwaltung

Mehr

SOA mit.net: Vom Geschäftsprozess zur Lösung

SOA mit.net: Vom Geschäftsprozess zur Lösung SOA mit.net: Vom Geschäftsprozess zur Lösung Manfred Steyer Aktuelles Buch.Net 4.0 Update ISBN 978-3866454439 http://tinyurl.com/net4update 1 Kontakt [www] www.softwarearchitekt.at [mail] Manfred.Steyer@SoftwareArchitekt.at

Mehr

Whitepaper. Produkt: combit List & Label 16. List & Label Windows Azure. combit GmbH Untere Laube 30 78462 Konstanz

Whitepaper. Produkt: combit List & Label 16. List & Label Windows Azure. combit GmbH Untere Laube 30 78462 Konstanz combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit List & Label 16 List & Label Windows Azure List & Label Windows Azure - 2 - Inhalt Softwarevoraussetzungen 3 Schritt 1: Neues Projekt

Mehr

Enterprise Application Integration. Sascha M. Köhler Software Architekt

Enterprise Application Integration. Sascha M. Köhler Software Architekt Sascha M. Köhler Software Architekt Agenda 2 01 Herausforderungen unserer Kunden 02 Lösungsdefinition 03 PROFI Angebot 04 Zusammenfassung Der IT-Gemüsegarten ITK Systeme sind auf Grund von Funktionen &

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Informationen zu fachlichen und technischen Aspekten der Koordinations- und Kommunikationsplattform KoKoBahn

Informationen zu fachlichen und technischen Aspekten der Koordinations- und Kommunikationsplattform KoKoBahn Informationen zu fachlichen und technischen Aspekten der Koordinations- und Kommunikationsplattform KoKoBahn ISETEC II KoKoBahn Seite 1 KoKoBahn Hafenübergreifende Koordinations- und Kommunikationsplattform

Mehr

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128 ... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA

Mehr

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION Präambel Die COI GmbH entwickelt seit 1988 moderne, prozessorientierte Lösungen rund um die Themen Archivierung, Dokumentenmanagement und Workflow. Als kompetenter

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Architecture Blueprints

Architecture Blueprints Architecture Blueprints Daniel Liebhart, Peter Welkenbach, Perry Pakull, Mischa Kölliker, Michael Könings, Markus Heinisch, Guido Schmutz Ein Leitfaden zur Konstruktion von Softwaresystemen mit Java Spring,.NET,

Mehr

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SO A Fraunhofer-Institut für Softwareund Systemtechnik ISST Dr. Ulrich Springer Dr. Bernhard Holtkamp Dortmund, 20.01.2009

Mehr

Java Web Services mit Apache Axis2 Entwickler

Java Web Services mit Apache Axis2 Entwickler Thilo Frotscher, Dapeng Wang, Marc Teufel Java Web Services mit Apache Axis2 Entwickler Vorwort 15 1 Einleitung 25 1.1 Entstehung 26 1.2 Unterstützte Standards 28 1.3 Was beinhaltet Axis2? 29 1.4 Warum

Mehr

Benutzerdokumentation Web-Portal

Benutzerdokumentation Web-Portal GRUPP: SWT0822 Benutzerdokumentation Web-Portal Yet Another Reversi Game Martin Gielow, Stephan Mennicke, Daniel Moos, Christine Schröder, Christine Stüve, Christian Sura 05. Mai 2009 Inhalt 1. Einleitung...3

Mehr

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen.

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. 181 In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. Wir beginnen mit dem Startup-Unternehmen Seals GmbH aus Frankfurt,

Mehr

Realisierung einer B2B-Integration

Realisierung einer B2B-Integration Realisierung einer B2B-Integration Dargestellt am Beispiel einer Bestellabwicklung zwischen SAP R/3 und MBS-Navision unter Einsatz des Microsoft BizTalk-Servers Gastvortrag MBS Hochschulpartnerkonferenz

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

Organisation und Systeme SOA: Erstellung von Templates für WebService Consumer und Provider in Java

Organisation und Systeme SOA: Erstellung von Templates für WebService Consumer und Provider in Java SOA: Erstellung von Templates für WebService Consumer und Provider in Java Entwicklung von Java WebService Provider- und Consumer-Bibliotheken zur Standardisierung der Karmann WebService Landschaft. Konzeption

Mehr

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Inhaltsverzeichnis Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Einleitung... 15 Zielgruppe... 16 Aufbau... 16 Inhalt der einzelnen Kapitel... 17 Systemanforderungen...

Mehr

Bachelorarbeit. Modellierung interaktiver Web Service Workflows. Thema: Benjamin Koch. von

Bachelorarbeit. Modellierung interaktiver Web Service Workflows. Thema: Benjamin Koch. von Bachelorarbeit Thema: Modellierung interaktiver Web Service Workflows von Benjamin Koch Gliederung Beispiel Interaktive Workflows Komponenten o BPEL o Web Service o Web-Interface o Eclipse-Plugin Vorführung

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Technische Voraussetzungen Stand: 29. Juli 2014

Technische Voraussetzungen Stand: 29. Juli 2014 Technische Voraussetzungen Stand: 29. Juli 2014 FineSolutions AG Culmannstrasse 37 8006 Zürich Telefon +41 44 245 85 85 Telefax +41 44 245 85 95 support@finesolutions.ch Inhaltsverzeichnis 1 Einführung...

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Vertiefte Grundlagen. Übung 2.7. TU Dresden - Institut für Bauinformatik

Vertiefte Grundlagen. Übung 2.7. TU Dresden - Institut für Bauinformatik Bauinformatik Vertiefte Grundlagen Geschäftsprozessmodellierung Übung 2.7 Begriffe Ein Geschäftsprozess beschreibt wiederkehrenden Ablauf. Dieser Ablauf beschreibt, welche Aktivitäten in welcher Folge

Mehr

Leistung schafft Vertrauen

Leistung schafft Vertrauen SOA Hintergrund und Praxis visionäre Praxis oder praxisnahe Vision Toni Gasser Integration Services 27. Oktober 2010 Leistung schafft Vertrauen Private Banking Investment Banking Asset Management Seite

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

A Generic Database Web Service for the Venice Lightweight Service Grid

A Generic Database Web Service for the Venice Lightweight Service Grid A Generic Database Web Service for the Venice Lightweight Service Grid Michael Koch Bachelorarbeit Michael Koch University of Kaiserslautern, Germany Integrated Communication Systems Lab Email: m_koch2@cs.uni-kl.de

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

Mehr

Universal Mobile Gateway V4

Universal Mobile Gateway V4 PV-Electronic, Lyss Universal Mobile Gateway V4 Autor: P.Groner Inhaltsverzeichnis Allgemeine Informationen... 3 Copyrightvermerk... 3 Support Informationen... 3 Produkte Support... 3 Allgemein... 4 Definition

Mehr

EDI CONNECT. für Microsoft Dynamics NAV. Auf einen Blick:

EDI CONNECT. für Microsoft Dynamics NAV. Auf einen Blick: Seite 1 PROTAKT Speziallösung EDI Connect Auf einen Blick: EDI CONNECT für Microsoft Dynamics NAV Elektronischer Datenaustausch ganz effizient und einfach über Ihr Microsoft Dynamics NAV System. Vollständige

Mehr

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Die Herausforderung: Hostanbindung Viele Unternehmen besitzen Mainframe- und Legacy-Anwendungen, so genannte Enterprise Information Systems (EIS),

Mehr

Inhaltsverzeichnis. Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach

Inhaltsverzeichnis. Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach sverzeichnis Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach Integration Architecture Blueprint Leitfaden zur Konstruktion

Mehr

Mit Open Source schrittweise zur SOA

Mit Open Source schrittweise zur SOA Mit Open Source schrittweise zur SOA Kristian Köhler koehler at oio.de Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de info@oio.de Wer steht vor Ihnen? 10+ Jahre Erfahrung in der

Mehr

MailStore Service Provider Edition (SPE)

MailStore Service Provider Edition (SPE) MailStore Solutions MailStore Service Provider Edition (SPE) E-Mail-Archivierung für Service Provider Mit Hilfe der MailStore Service Provider Edition können Sie Ihren Kunden moderne E-Mail-Archivierung

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

.NET-Objekte einfach speichern Michael Braam, Senior Sales Engineer InterSystems GmbH

.NET-Objekte einfach speichern Michael Braam, Senior Sales Engineer InterSystems GmbH Make Applications Faster.NET-Objekte einfach speichern Michael Braam, Senior Sales Engineer InterSystems GmbH Agenda Vorstellung InterSystems Überblick Caché Live Demo InterSystems auf einen Blick 100.000

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Java Forum Stuttgart 2008

Java Forum Stuttgart 2008 Professionelle Open Source SOA in 45 Minuten! Java Forum Stuttgart 2008 Dr. Halil-Cem Gürsoy, CDI AG Der Referent Insgesamt ca. 10 Jahre Beratung, davor Forschung Senior Consultant - JEE Evangelist Hauptsächlich

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

TransConnect Business Integration Platform. universeller Server zur Integration von Daten, Anwendungen und Geschäftsprozessen

TransConnect Business Integration Platform. universeller Server zur Integration von Daten, Anwendungen und Geschäftsprozessen TransConnect Business Integration Platform universeller Server zur Integration von Daten, Anwendungen und Geschäftsprozessen Einleitung TransConnect ist die zentrale Serverplattform für den Aufbau einer

Mehr

Band M, Kapitel 7: IT-Dienste

Band M, Kapitel 7: IT-Dienste Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0 E-Mail: Hochverfuegbarkeit@bsi.bund.de Internet: https://www.bsi.bund.de Bundesamt für Sicherheit

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Inauguraldissertation zur Erlangung des akademischen Grades eines Doktors

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

Mehr

Service Oriented Architecture. IM-Briefing 2008 4. Dezember 2008

Service Oriented Architecture. IM-Briefing 2008 4. Dezember 2008 Service Oriented Architecture IM-Briefing 2008 4. Dezember 2008 Agenda Begrüssung Was ist SOA Herkunft Player Modell Komponenten Zusammenfassung Diskussion Seite 1 Was ist SOA? Herkunft Der Begriff serviceorientierte

Mehr

Philosophie & Tätigkeiten. Geschäftsfelder. Software Engineering. Business Applikationen. Mobile Applikationen. Web Applikationen.

Philosophie & Tätigkeiten. Geschäftsfelder. Software Engineering. Business Applikationen. Mobile Applikationen. Web Applikationen. Philosophie & Tätigkeiten Wir sind ein Unternehmen, welches sich mit der Umsetzung kundenspezifischer Softwareprodukte und IT-Lösungen beschäftigt. Wir unterstützen unsere Kunde während des gesamten Projektprozesses,

Mehr

EAI. Integration. EAI Version 0.9 1

EAI. Integration. EAI Version 0.9 1 EAI Enterprise Application Integration EAI Version 0.9 1 Heterogene Informationssysteme KIS DRG Grouper Stand-alone Anwendung (Windows) PACS Client-Server Anwendung (Java, LINUX, Caché) QM-System Client-Server

Mehr

Aufgabenstellung und Zielsetzung

Aufgabenstellung und Zielsetzung Aufgabenstellung und Zielsetzung In diesem Szenario werden Sie eine Bestellung, vorliegend im XML-Format, über einen Web-Client per HTTP zum XI- System senden. Dort wird die XML-Datei mittels eines HTTP-Interfaces

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

IBM SolutionsConnect 2013 COOP CISP Schweizer Messer für agile Integration

IBM SolutionsConnect 2013 COOP CISP Schweizer Messer für agile Integration IBM SolutionsConnect 2013 COOP CISP Schweizer Messer für agile Integration auf Basis des EIB Konzepts der CAS AG Patrick Wimmer Bad Nauheim, 14.06.2013 Agenda Zur Person Portrait COOP die Gruppe in Kürze

Mehr

Mobile Backend in der

Mobile Backend in der Mobile Backend in der Cloud Azure Mobile Services / Websites / Active Directory / Kontext Auth Back-Office Mobile Users Push Data Website DevOps Social Networks Logic Others TFS online Windows Azure Mobile

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Workshop 3. Excel, EDIFACT, ebxml- Was ist state. of the art und wo liegt die Zukunft. 16. September 2002

Workshop 3. Excel, EDIFACT, ebxml- Was ist state. of the art und wo liegt die Zukunft. 16. September 2002 Workshop 3 Excel, EDIFACT, ebxml- Was ist state of the art und wo liegt die Zukunft 16. September 2002 Dipl. Kfm. power2e energy solutions GmbH Wendenstraße 4 20097 Hamburg Telefon (040) 80.80.65.9 0 info@power2e.de

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10. AustroFeedr Pushing the Realtime Web Projektplan erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.2010 gefördert durch die Internet Privatstiftung Austria (IPA) 1 Projektbeschreibung

Mehr

Sichere Web-Services in einem föderierten Umfeld

Sichere Web-Services in einem föderierten Umfeld Sichere Web-Services in einem föderierten Umfeld ZKI Arbeitskreis Verzeichnisdienste ZEDAT FU Berlin Axel Maurer Die Kooperation von Forschungszentrum Karlsruhe GmbH und Universität Karlsruhe (TH) integrierte

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2013 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A POIS-Praktikum 2007 Prozessimplementierung, RosettaNet PIPs 3A Manuel Blechschmidt, David Foerster, Michael Leben, Mike Nagora, Jonas Rogge, Paul Römer Gliederung 2 Einleitung Was war unsere Aufgabe? Was

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Service Oriented Architectures

Service Oriented Architectures Service Oriented Architectures Einführung in die Integration verschiedener Anwendungssysteme - Problematik und allgemeine Architektur Julia Weisheitel (WI5773) Inhalt Überblick Probleme und Entscheidungen

Mehr