Entwicklung einer einheitlichen Webdienstschnittstelle für Microsoft Enterprise Systems

Transkript

1 Technische Universität München Fakultät für Informatik Lehrstuhl für Software und Systems Engineering (I 19) Diplomarbeit Entwicklung einer einheitlichen Webdienstschnittstelle für Microsoft Enterprise Systems Rumen Traykov Aufgabensteller: Prof. Dr. Florian Matthes Betreuer: Sheng Wei Abgabedatum:

2 Erklärung Ich versichere, dass ich diese Diplom-Arbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. München, den 15.September 2005 Rumen Traykov II

3 Inhaltsverzeichnis 1 Einleitung Begriffe und Konzepte Grundlagen der Systemintegration Datenintegration Anwendungsintegration Prozessintegration Metadaten-Beschreibung Unternehmensanwendungen Datenbanksystem Verzeichnisdienst Groupware-Server Informationsportale (Portal Server) Systeme vom besonderen Interesse BizTalk Server Information Bridge Framework Oracle9iBC4J SharePoint Portal Server Funktionale und nichtfunktionale Anforderungen Übersicht über die technischen Hilfsmittel in Microsoft Welt Microsoft.NET Xml-Unterstützung in.net Code-Generierung mit System.CodeDom-Namespace Reflektion mit den System.Reflection- und System.Type-... Namespace Webdienste mit ASP.NET Kommunikationsprotokolle und Schnittstellen Component Object Model Ole DB Lightweight Directory Access Protocol Active Directory Service Interfaces Web Distributed Authoring and Versioning(WebDAV) Objektmodelle Collaboration Data Objects ActiveX Data Objects und ADO.NET Microsoft-Unternehmensanwendungen in Hinblick auf Daten- Schema und Porgrammierschnittstellen Active Directory Programmierschnittstellen Metadatenbeschreibung Microsoft Sql Server Programmierschnittstellen Metadatenbeschreibung Exchange Server Programmierschnittstellen ADO/CDO und OLEDB WebDAV Metadatenbeschreibung SharePoint Portal Server Programmierschnittstellen...55 III

4 4.4.2 Metadatenbeschreibung Entwurf und Implementierungsdetails Architektur-Entwurf Extrahieren der Metadaten Microsoft Sql Server Active Directory Exchange Server Benutzerdefiniertes Modell Code-Generierung Komponenten für den Datenzugriff (Data-Access-Layers) Exchange Server Active Directory Microsoft SQL Server Systeminterne Objekt-Datenzugriffsschnittstelle Dienstentwurf Konfigurationsschema und Dienstbeschreibung Deployment Use-Cases und Szenarien Testfälle Java-Client Zusammenfassung Ausblick Literatur- und Quellenverzeichniss IV

5 Abbildungsverzeichnis Abbildung 1: Systemarchitektur von BizTalk Server[BizT04] 10 Abbildung 2: Systemarchitektur von Microsoft IBF[IFAP] 12 Abbildung 3: Systemgrenzen aus der Sicht eines Integrationsbrokers.16 Abbildung 4:.Net-Framework Schichtendiagramm.17 Abbildung 5: Active Directory Service Interfaces 29 Abbildung 6: Collaboration Data Objects[CDOSDK]..36 Abbildung 7: ADO.NET...39 Abbildung 8: Datenzugriffs-Architektur für Exchange Server 2003 [ESDK01]..49 Abbildung 9: Zugriff auf dem Exchange Store über WebDAV [ESDK02].50 Abbildung 10: SharePoint Portal Server Workspace [MicSPS2].54 Abbildung 11:Client-Interaktion mit SharePoint Information Store über WebDAV...56 Abbildung 12: Schichtendiagram.59 Abbildung 13: Komponentendiagramm 62 Abbildung 14: Ausschnitt aus dem Datenbankschema der Beispielsdatenbank Northwind..65 Abbildung 15: Ausschnitt aus Active Directory Schema.67 Abbildung 16: Ausschnitt aus dem Exchange Server-Schema.70 Abbildung 17: Beispielsinstanz des Common-Models.72 Abbildung 18: Transformation zwischen Metamodellen [Anhang 3]..73 Abbildung 19: Zuordnung Unternehmensanwendung XmlSchema. 75 Abbildung 20: Die codegenerator-komponente zur Codegenerierung aus XSD...76 Abbildung 21: Erweiterungen für das zusätzliche Anpassung des Quellcodes bei Code- Generierung...79 Abbildung 22: Attribute, die Strukturen in relationalen Datenbanken beschreiben.80 Abbildung 23: Klassendiagramm der Datenzugriffskomponente.83 Abbildung 24: Klassendiagramm der Konfigurationskomponente..92 V

6 Abbildung 25: Data Access Object - Pattern [BPJ2EE]...94 Abbildung 26: Sequenzdiagramm für den Service Locator...96 Abbildung 27: Deployment-Diagramm 98 Tabellenverzeichnis Tabelle 1: ADSI-Provider.31 Tabelle 2: Einschränkungen (Spaltennamen der Ergebnistabelle-DataTable) für den OleDbSchemaGuid.Tables Identifikator...40 Tabelle 3: Zuordnung von Syntaxen in Active Directory und.net-datentypen 45 Tabelle 4: Zuordnung von Sql Server Datentypen zu SQLOLEDB- und.net-datentypen.47 VI

7 1 Einleitung In Unternehmen werden in der Regel mehrere Enterprise Systeme für die Verwaltung der Unternehmensdatenbestände und die Koordination der Arbeitsprozesse eingesetzt. Bei der Gestaltung der innerbetrieblichen und überbetrieblichen Geschäftsprozesse können die Informationsbestände und Dienste mehrerer Unternehmensanwendungen benötigt werden, wenn das Ziel nicht mit einer einzigen Anwendung erreichbar ist. Darüber hinaus werden oft redundante, semantisch zusammengehörige Daten in unterschiedlichen und unabhängig voneinander bestehenden Informationssystemen gespeichert. Dabei ist sowohl die Einhaltung der Konsistenz problematisch, die ohne eine zentrale Verwaltung nur mit erhöhter Komplexität zu gewährleisten ist, als auch die Verwaltung und Pflege der Daten, die für jedes Informationssystem separat und nicht unbedingt zeitgleich durchzuführen sind. Eine wichtige Voraussetzung für die Lösung dieser Probleme ist die Integration der Unternehmensanwendungen. Die Zentralverwaltung von Anwendungen bringt viele Vorteile mit sich, z.b. eine vereinheitlichte Zugriffsschnittstelle für Dienste und Informationsobjekte, impliziert jedoch auch die Integration von Unternehmensanwendungen, die nicht immer in homogener Systemumgebung laufen müssen. Durch die immer wachsende Bedeutung von Internet und verteilten Anwendungen in heterogenen Systemen ist der Druck für Webdienstschnittstellen gewachsen. Die Microsoft Enterprise Systeme verfügen oft über keine XML-basierten Webdienstschnittstellen und bieten nur Kommunikationsprotokolle und Programmierschnittstellen, die nicht für das Internet konzipiert sind. Das Ziel dieser Arbeit ist, ein Konzept für ein System zu entwickeln, das einerseits die Integration von Unternehmensanwendungen, im Sinne der Offenlegung von deren Informationsobjekten und Diensten via XML-basierte Webdienste, und andererseits die Modellierung von komplexen anwendungsübergreifenden Informationsobjekten umfasst. Die Integration der Systeme impliziert sowohl die Extrahierung der Metadaten aus den Anwendungen, die die Informationsobjekte beschreiben, als auch die Entwicklung von Konnektoren für die von den Anwendungen unterstützten Kommunikationsprotokollen und Programmierschnittstellen. Bei den vorliegenden Komponenten, die die Kommunikationsprotokolle implementieren, stellen die Konnektoren nur Adapter dar, die diese Komponente an den im System vordefinierten Schnittstellen anpassen. Mit der Offenlegung dieser Schnittstellen in einer vom System zur Verfügung gestellten

8 Programmierschnittstelle werden die Austauschbarkeit von Adaptern und die Erweiterung des Systems mit neuen Adaptern sichergestellt. Darüber hinaus muss das System eine Komponente für die Extrahierung der Metadaten aus ausgewählten Systemen anbieten und durch offen gelegte Schnittstellen erweiterbar sein. Die Integration neuer Anwendungen muss mit der Angabe der Adapter, Metadaten und Konfigurationseinstellungen erfolgen. Für die anwendungsübergreifenden Informationsobjekten ist außerdem eine Datenzugriffsschnittstelle gefordert, die die Verteilung der Anfragen an den mitwirkenden Enterprise Systemen automatisiert. Das erfolgt für alle möglichen Informationsobjekten als zyklenfreien Objektgraphen. Gliederung der Arbeit In Kapitel 2 werden Konzepte vorgestellt, aus denen sich zusätzliche Anforderungen an dem zu entwickelten System herleiten lassen. Außerdem werden Begriffe und Definitionen erklärt, die in den folgenden Kapiteln verwendet werden. Eine Übersicht über die Kommunikationsprotokolle und Programmierschnittstellen für die Enterprise Systeme, die als Beweis des Konzepts in dieser Arbeit behandelt worden sind, ist in Kapitel 3 gegeben. Die Enterprise Systeme selbst werden im Kapitel 4 auf Programmierschnittstellen und Metadatenbeschreibungen untersucht. Der Entwurf und die Implementierungsdetails werden in Kapitel 5 behandelt. Als erstes wird die Extrahierung der Metadaten in Xml Schema Definition (XSD)-Dokumente für jede in Betracht gezogene Unternehmensanwendung, dann die Generierung von Code aus den erzeugten XSD-Dokumenten und anschließend die Entwicklung der Konnektoren und der Konfigurationskomponente behandelt. Kapitel 6 beschäftigt sich mit der Qualitätssicherung. Im Kapitel 7 und 8 werden abschießend eine Zusammenfassung über die Arbeit und Ausblick auf Erweiterungsmöglichkeiten verfasst. 2

9 2 Begriffe und Konzepte Um die Problemstellung im fachlichen Konzept nach den theoretischen Grundlagen einordnen zu können, wird demnächst kurz auf diese eingegangen. 2.1 Grundlagen der Systemintegration Die Kernidee der Enterprise Application Integeration (EAI) ist, eine zentrale Plattform bereitzustellen, welche Applikationen über entsprechende, zum Teil vorgefertigte Adapter, anbindet. Gegenüber der Point to Point Integration lässt sich eine erheblich geringere Anzahl an Schnittstellen realisieren. Dieser Effekt verstärkt sich quadratisch bei steigender Anzahl der zu integrierenden Applikationen [SAMS04]. Wolfgang Keller [Kell02] grenzt EAI von B2B ab, da hier in der Regel mehrere Parteien beteiligt sind. Allerdings werden die Konzepte als strukturell und technisch gleich beschrieben. Laut ihm liegt der einzige Unterschied in der unternehmensübergreifenden Sichtweise des B2B-Ansatzes und des unternehmensinternen Fokus von EAI. Im Siemens online Lexikon [SiemL] ist folgende Definition eines Informationsbrokers angegeben: Integrationsbroker, auch als Integrationsserver, Orchestrierungsserver oder Integrationsplattformen bezeichnet, liefern den Unterbau für das Zusammenwirken der einzelnen Webservices. Sie dienen der Orchestrierung von Webservices und dafür die entsprechenden Schnittstellen bereit. Des Weiteren nehmen Integrationsbroker Nachrichten aus Applikationen entgegen, prüfen und analysieren diese, wandeln die auszutauschenden Dateiformate um und übertragen sie an die Zielanwendungen. Neben der Anwendung von Sicherheitsverfahren managen Integrationsbroker auch Transaktionen In dieser Definition sind zwei für diese Arbeit wichtige Anforderungen an dem Funktionsumfang eines Integrationsbrokers erwähnt. Er muss Webdienste offen legen sowie in der Lage sein, Nachrichten aus verschiedenen Anwendungen entgegenzunehmen, zu bearbeiten und anschließend an die entsprechende Anwendung weiterzuleiten. Das sind auch Anforderungen an dem Konzept, das in dieser Arbeit entwickelt wird, mit der Einschränkung, dass das zu entwickelnde System nur über Webdienste angesprochen werden kann. 3

10 Aus Microsoft-Sicht [MCED03] kann die Anwendungsintegration als das Zusammenführen von mehreren autonomen Anwendungen oder Teilen davon, in eine neue verteilte Anwendung, angesehen werden. Das kann auf verschiedene Weisen geschehen, wie z.b. beim direkten Zugriff auf die Funktionalitäten einer Anwendung von einer anderen, oder bei der Kommunikation von Anwendungen in heterogenen Systemen über das Versenden von Nachrichten in vordefiniertem Format. Die Anwendungsintegration ermöglicht die Zusammenarbeit der Anwendungen, um ein größeres Ziel zu erreichen, das von den einzelnen Anwendungen nicht erreicht werden kann. Diese Zusammenarbeit erfordert einen Grad an Interoperabilität zwischen den Systemen. Um Strukturen zum Konzept von Interoperabilität anbieten zu können, wurde von Microsoft die Entwicklung eines Interoperabilitätsframeworks-NDAM initiiert. NDAM ist die Abkürzung für Netzwerk, Daten, Anwendungen und Management, die nach Microsoft die vier Anforderungen für Interoperabilität unter Systemen darstellen. Die Technologien, die Anwendungsintegration ermöglichen, werden dann in zwei Bereiche eingeteilt werden: Anwendung-Infrastruktur-Technologien verschaffen Interoperabilität in folgenden Anwendung-Infrastuktur-Ebenen: o Transaktionen o Komponente o Präsentation; Geschäftsprozess-Integrationstechnologien. Beide schließen sich nicht einander aus, z.b. eine verteilte, zur Ausführung von Transaktionen entworfene Anwendung kann von wieder verwendbaren Komponenten aufgebaut werden. Ein anderes Beispiel ist die Kommunikation zweier Anwendungen mithilfe von XML für die Ausführung einer Transaktion, womit eine reelle Geschäftsprozessintegration erreicht wird. Das Ziel der Arbeit beschränkt sich nur in der Domäne der Komponenten- und als Ausblick in die Zukunft die Transaktions-Ebenen der Anwendungs-Infrastruktur. Die Transaktionsebene stellt die Möglichkeit Operationen von mehreren Systemen in einer Transaktion zu vereinen - die Operationen einer Transaktion werden als eine atomare Operation betrachtet, die entweder mit Erfolg beendet oder fehlgeschlagen ist. Die Präsentationsebene beschäftigt sich mit der Einbettung von Benutzeroberflächen, also der Präsentationsschicht einer Anwendung. 4

11 Die Integrationsmethoden nach Linthicum [Lint00] werden in Interface Level, Data Level, Application Interface Level und Prozessintegration eingeteilt, die in den folgenden Punkten beschrieben werden. Das Konzept dieser Arbeit spiegelt sich in der Definition der Anwendungs- und Datenintegration wider Datenintegration Das zu integrierendem System greift bei der Data Level Integration direkt auf die Daten einer Datenbank zu. Die Business-Logik anderer Applikationen, die ebenfalls die betroffe Datenquelle nutzen, wird nicht verwendet. Die Daten werden gelesen, nach individuellen Regeln transformiert oder durch eigene Logik interpretiert, um in die gleiche Quelle zurück geschrieben bzw. auf andere Art und Weise weiterverwendet zu werden Anwendungsintegration Die integrierende Software greift auf die Daten und Businessprozesse einer Anwendung mithilfe von Application Programming Interfaces (API) unter Verwendung der Applikationslogik des Systems zu. Die Daten werden dann in ein für die Zielanwendung oder für die zentrale EAI-Instanz verständliches Format umgewandelt und übertragen. Ein Vorteil dieser Methode im Vergleich zur Data Level Integration besteht darin, dass die Geschäftslogik die Konsistenz und die Einhaltung der Datenformate garantiert. Als Nachteil werden in der Regel die API-Restriktionen bezüglich des Datenzugriffs und Funktionsumfangs sowie die Komplexität der systemübergreifenden Funktionsintegration im Fall fehlender Standard-APIs betrachtet. Eine Integrationsinstanz agiert als Bridge für die in der Kommunikation beteiligten Anwendungen. Dazu kommt noch die Prozessintegration, bei der die Geschäftsprozesse im Mittelpunkt stehen. Bei BizTalk Server ist der Integrationsbroker mit Metamodellen (intern definierte Modelle für die benutzerdefinierten Modelle) und Werkzeugen versehen, die durch einen MDA 1 -Ansatz das Modellieren von Geschäftsprozessen und dafür benötigten Entitäten vereinfachen. Die Entitäten sind Objekte, die in den zu integrierenden Systemen definiert sind und im 1 MDA steht für Model Driven Architecture, ein Standard von Object Management Group, der eine Vorgehensweise bei dem Softwareentwicklungsprozess unter Verwendung von UML definiert, dass Anwendungslogik von der unterliegenden Plattformtechnologie trennt. 5

12 Integrationsbroker durch ein Modell beschreiben werden. Dieses Modell muss mit dem festgelegten generischen Metamodell des Brokers konform sein Prozessintegration Die geschäftsprozessorientierte Anwendungsintegration hat ihren Fokus auf einer höheren Abstraktionsebene als die informationsorientierte. Die letzte richtet ihren Blick auf das Geschäftsmodell bzw. die Geschäftsprozesse mit der Geschäftslogik, den Prozessabläufen und der Hierarchisierung von Prozessen in Subprozesse. Der Ansatz ist eng mit dem der Geschäftsprozessautomatisierung verbunden. Die Prozesse werden einheitlich zentral gestaltet und definiert. Die Anwendungen werden letztendlich durch die Anbindung an die Prozesse integriert. Voraussetzung dafür sind Schnittstellen zu den Funktionen und Daten der Anwendungen, die in einer geeigneten Granularität vorhanden sein müssen. Die dienstorientierte und informationsorientierte Anwendungsintegration spielt bei der Bereitstellung der Schnittstellen eine Rolle. Die Prozesse müssen auf einer genügend abstrakten Ebene definiert werden sowie mit einer Modellierungssprache und (grafischen) Modellierungstools modellierbar sein. Durch die Trennung zwischen der Geschäftsprozessebene und den darunter liegenden Integrationsschichten können die Prozesse angepasst werden, ohne dass die darunter liegenden Implementierungen geändert werden müssen. Gleiches gilt für Änderungen in den unteren Integrationsschichten. Dafür wird ein MDA-Tool (s. Kapitel 2.1.2)empfohlen. 2.2 Metadaten-Beschreibung Damit eine sinnvolle Integration möglich ist, muss die Qualität und Struktur der Daten, die entweder schon vorhanden sind oder neu erfasst werden müssen, wie deren Meta-Daten- Beschreibung, analysiert werden. Es wird versucht, allgemein gültige Informationsstrukturen zu erheben, die in einer ganzen Klasse von Problemfällen anzutreffen sind. Die so gefundenen und dokumentierten Muster können daher in verschiedenen konkreten Anwendungsfällen zum Einsatz kommen. Von den Modellen benutzte Begriffe variieren bei der konkreten Problemstellung. Daher wird das generische Modell als zusätzliche Modellierungsebene aufgefasst und dient als Modell eines konkreten Modells, oder auch Metamodell. Metamodelle ermöglichen die Definition generischer Vorgehensweisen, die später auf den konkreten Modellen (d.h. den Ausprägungen des Metamodells) angewandt werden können [SAMS04]. 6

13 Datenstrukturen Bei den strukturierten Datenquellen kann ein Datensatz nicht von der vorgegebenen Feldstruktur abweichen. Beispiel dafür sind die Datensätze einer Tabelle in einer relationalen Datenbank. Diese müssen die gleichen Felder besitzen. Bei semi-strukturierten Datenquellen dagegen, wie z.b. bei Verzeichnisdienste und Nachrichtenspeicher, verfügen nicht alle Datensätze über die gleichen Felder [SCHW01]. Bei einer semi-strukturierten Datenbank kann es optionale Felder geben, für die ein konkretes Objekt keinen Wert bereitzustellen braucht. 2.3 Unternehmensanwendungen Für den Beweis des Konzepts wird als Ziel dieser Arbeit gesetzt, einen Verzeichnisdienst, ein relationales Datenbanksystem und einen Groupware-Server im zu entwickelnden System zu integrieren. Im Folgenden wird die Definition sowohl für jedes dieser Systeme, als auch für einen Portal-Server angegeben, weil die Integration des in dieser Arbeit ausgewählten Portal- Servers analog zu der Integration des ausgewählten Groupware-Servers verläuft Datenbanksystem Die Ansammlung von Informationen, die sich auf ein bestimmtes Thema oder Zweck beziehen, wird als Datenbank bezeichnet. Die Datenbank wird normalerweise von einem Datenbankverwaltungssystem (database management system DBMS) verwaltet. Ein Datenbanksystem besteht aus einer oder mehreren Datenbanken und dem Verwaltungssystem, das dem Benutzer ermöglicht, bestimmte Informationen zu erfassen, zu speichern, zu finden und zu aktualisieren. Es behandelt außerdem Problemfälle wie z.b. gleichzeitigen Zugriff auf Daten von mehreren Benutzern. Die Datenbank ist nach einer bestimmten Struktur aufgebaut, demnach sind in dieser Arbeit die relationale und hierarchische Datenstrukturen von Bedeutung. Die hierarchische Datenstruktur wird im Zusammenhang mit den Verzeichnisdiensten behandelt. Im Folgenden ist als Datenbank diese mit relationaler Datenstruktur gemeint. Eine relationale Datenbank basiert auf dem relationalen Datenbankmodell. Dabei werden die Daten in zweidimensionalen Tabellen verwaltet, die über Schlüssel miteinander verknüpft 7

14 werden können. Die Schlüssel (Primär-, Fremdschlüssel) sind ausgewählte Attribute (Spalten) in der Tabelle, die die referenzielle Integrität sicherstellen. Die referenzielle Integrität befasst sich mit der Korrektheit der Beziehungen zwischen Tabellen und der Eindeutigkeit der Schlüssel. Die Reihen stellen Datensätze in der Tabelle dar, die über den Primärschlüssel eindeutig bestimmt werden. Die Fremdschlüssel ermöglichen das Verknüpfen von Tabellen, indem Primärschlüssel referenziert werden. Das Datenbanksystem stellt sicher, dass die Primärschlüssel existieren und nur gemeinsam mit dem Fremdschlüssel geändert oder gelöscht werden können. Alle Attribute haben eine festgelegte Domäne (Wertebereich) für Attributwerte. Die Einhaltung dieser Wertebereiche wird als Wertebereichintegrität bezeichnet. Mit Sql (Structured Query Language) wird eine Abfragesprache für relationale Datenbanken definiert. Im Prinzip ist Sql standardisiert, allerdings unterstützen nicht alle Hersteller den kompletten Standard und jeder hat seine eigenen Erweiterungen [KEMP04] Verzeichnisdienst Das Verzeichnis stellt einen hierarchischen Speicher für Informationen dar. Die Verzeichniseinträge bilden einen Verzeichnisbaum, wobei es drei Typen von Einträgen gibt: Root (Wurzel), Container (Knoten) und Leaves (Blätter). Das oberste Element im Verzeichnisbaum ist die Wurzel. Ein Container kann im Gegensatz zu den Blättern andere Einträge enthalten. Wie in allen hierarchischen Datenbanken können Verknüpfungen zwischen Einträgen nur als Eltern-Kind-Beziehungen im Verzeichnisbaum realisiert werden. Jeder Eintrag enthält Attribute, die ihn beliebig genau beschreiben. In einigen Verzeichnissen, wie z.b. bei Active Direcory der Fall ist, kann ein Attribut auch mehrere Werte haben. Der Verzeichnisdienst umfasst neben der Speicherung auch den Zugriff auf die Informationen. Die Verzeichniseinträge werden als Objekte und die Definitionen der Struktur der Objekte als Klassen bezeichnet. Die Operationen auf einem Verzeichnisdienst werden von den Zugriffsprotokollen, wie das Lightweight Directory Access Protocol (LDAP), definiert Groupware-Server Ein Groupware-Server erfüllt die Anforderungen für kooperatives Arbeiten (Computer Supported Cooperative Work CSCW). Er unterstützt die Kommunikation, Koordination von 8

15 Arbeitsprozessen, sowie Informations- und Dokumentenmanagement. Im Bereich der Kommunikation agiert ein Groupware-Server als Nachrichtenserver, indem er die für die Anwender bestimmten Nachrichten annimmt und diese in das Postfach des Anwenders zustellt, sowie die gesendeten s des Benutzers annimmt und an den Empfänger übermittelt. Die Arbeitsprozesse werden durch gruppenübergreifende Termin- und Aufgabenplanung erleichtert. Bei Groupware-Systeme werden z.b. die Verwaltung von persönlichen und öffentlichen Kontaktinformationen als Informationsmanagement und die Strukturierung und Einreicherung der Dokumenten mit Metadaten als Dokumentenmanagement verstanden Informationsportale (Portal Server) Ein Portal Server erfüllt den Wunsch die im Unternehmen unverbundenen Systeme unter einer einheitlichen, web-basierten Benutzungsoberfläche zu integrieren, so dass benötigte Funktionen (suchen, freigeben, veröffentlichen) und im Unternehmen vorhandenen Informationen und Dokumente unter einem einheitlichen Zugang erreicht werden können. Ein Portal stellt dabei sowohl Funktionen des Datenbank-Management-Systems (DMS), z.b. Dokumenten- und Versionsverwaltung, sowie von diesen unterstützten Kollaborations- Funktionen für Dokumentaustausch und Koordination von Aufgaben, zur Verfügung. Also erfüllt ein Portal Server viele Anforderungen, die an einem Groupware-Server gestellt werden. 2.4 Systeme vom besonderen Interesse Der BizTalk Server, Mircrosoft IBF und Oracle 9iBC4J sind Systeme, die sich mit den Problemen der EAI (s. Kapitel 2.1) befassen. In Bezug auf die Projektziele werden einige Eigenschaften dieser Systeme untersucht BizTalk Server 2004 Bei vielen Integrationsprojekten kommunizieren die Anwendungen mit verschiedenen Protokollen. Die Nachrichteninfrastruktur von BizTalk Server ist so ausgelegt, dass er für jede Anwendung ihren eigenen Kommunikationsmechanismus benutzt. Um das zu ermöglichen, ist er auf Adapter angewiesen. Jeder Adapter implementiert einen Kommunikationsmechanismus wie ein bestimmtes Protokoll [BizT04]. 9

16 Abbildung 1: Systemarchitektur von BizTalk Server [BizT04] BizTalk Server stellt mehrere integrierte Adapter zur Verfügung. Ein Entwickler kann festlegen, welche Adapter in einer bestimmten Situation zum Einsatz kommen, oder auch benutzerdefinierte Adapter erstellen. Alle Adapter basieren auf einem Standard, der Adapterframework genannt wird. Dieses Framework bietet eine allgemeine Methode zum Erstellen und Ausführen von Adaptern und ermöglicht Ihnen, zur Verwaltung von standard- und benutzerdefinierten Adaptern dieselbe Tools zu verwenden. In BizTalk Server 2004 stehen u.a. Adapter für SOAP, HTTP und FTP zur Verfügung (s. Anhang 5). Intern arbeitet der Server nur mit XML-Dokumenten. Unabhängig in welchem Format eine Nachricht ankommt, wird sie immer in einem XML-Dokument umgewandelt. Analog, wenn die Zielanwendung die Nachricht nicht als XML-Dokument akzeptieren kann, werden sie in einem von der Zielanwendung erwarteten Format konvertiert. Das in Abbildung 1 vorgestellten Prozess könnte in folgenden Punkten erläutert werden: 1. Eine Nachricht wird mithilfe eines Empfangsadapters empfangen. Verschiedene Adapter bieten verschiedene Kommunikationsmechanismen an. 10

17 2. Die Nachricht wird durch eine Empfangspipeline bearbeitet. Diese Bearbeitungspipeline kann Komponenten enthalten, die Aktionen durchführen, wie die Umwandlung der Nachrichten vom ursprünglichen Format in ein XML-Dokument oder die Validierung der digitalen Signatur der Nachricht. 3. Die Nachricht wird an eine Datenbank, auch MessageBox-Datenbank genannt, die auf Microsoft SQL Server aufsetzt, geliefert. 4. Die Nachricht wird zu seiner Zielorchestrierung umgeschaltet, die für den Businessprozess benötigte Aktion durchführt. 5. Das Ergebnis von dieser Bearbeitung ist normalerweise eine andere Nachricht, erzeugt vom Businessprozess, sie wird in die MessageBox-Datenbank gespeichert. 6. Diese Nachricht, wird wiederum durch eine sendende Pipeline bearbeitet, die die Nachricht vom internen für BizTalk Server XML-Format, in ein von der Zielanwendung erfordertes Format umwandeln kann, oder z.b. eine Signatur hinzufügen kann. 7. Die Nachricht wird mithilfe eines Sendeadapters versendet, der einen entsprechenden Kommunikationsmechanismus benutzt, um die Nachricht an die Zielanwendung zu übermitteln, für die die Nachricht bestimmt ist. BizTalk Server 2004 hat außerdem noch zwei wichtige graphische Werkzeuge zur Erstellung von Orchestrierungen: BizTalk Editor zur Erstellung von Schemata für Daten. Dafür wird XML Schema angewendet. BizTalk Mapper für die Festlegung der Transformationen zwischen diesen Schemata, und Orchestrierungsdesigner für die einfache Festlegung des Ablaufs der Businessprozesse (s. Anhang 4). Für einen Teil der Information in den empfangenen Dokumenten ist es üblich, sie in die zu sendenden Dokumente, vielleicht auch transformiert, zu transferieren. Mit dem BizTalk Mapper können leicht sowohl die Zuordnungen von Elementen im Quell- zu Elementen im Zieldokument, sowie benötigte Transformationen, graphisch festgelegt werden. Diese werden dann in einem XSLT-Format [W31199] gespeichert. 11

18 2.4.2 Information Bridge Framework Microsoft Office Information Bridge Framework (IBF) ist eine Office-Komponente, die Zugang zu Informationen via Webdienste anbietet. IBF enthält ein add-in für Visual Studio.NET, das den Entwickler ermöglicht webdienstbasierten Lösungen zu entwickeln, die Zugang zu Unternehmensgeschäftsdaten wie Verkaufszahlen, Kundeninformationen usw. ermöglicht, die oft line of business (LOB) Dienste genannt werden. Diese Informationen können gleich in die 2003 Version von Word, Excel und Outlook angezeigt werden. IBF- Lösungen erhöht die Produktivität der Informationsbearbeiter, indem sie die Möglichkeit bereitstellen, Informationen zu bekommen und bearbeiten, ohne die bekannte Office- Applikationen zu verlassen [IFAP]. IBF enthält ein XML Schema zur Definition von Dienstoperationen, Businessentitäten und User Interface (UI) Elementen. Der Bridge benutzt dieses Schema, um den Transfer von Daten zwischen den verschiedenen Komponenten zu ermöglichen, ohne die Metadaten zu verlieren, die für einen Update der Informationen bei der Datenquelle, wie z.b. eine LOB Applikation, notwendig sind. Die Struktur der Metadaten in IBF ist in Anhang 1 aufgeführt. Die IBF Server-Komponente ist ein Metadatendienst, basierend auf IIS-Webdienste und Microsoft SQL Server, in dem die Metadaten gespeichert sind. Der IBF Klient ist eine add-in Komponente für Microsoft Office Lösungen, die das in Metadaten festgelegte Verhalten der Lösung steuert. Abbildung 2: Systemarchitektur von Microsoft IBF [IFAP] IBF verfügt über ein Visual Studio add-in Werkzeug - Metadata Designer, um Metadaten zu erzeugen und sie an den Metadatendienst für die Aufbewahrung über einen Webdienst zu übergeben. 12

19 2.4.3 Oracle9iBC4J Das JDeveloper-Framework BC4J (Oracle9i Business Components for Java) erlaubt eine erheblich vereinfachte Entwicklung von n-tier Anwendungen und die Entwicklung bzw. Integration unternehmensweiter Anwendungssysteme. JDeveloper führt sämtliche DML 2 - bezogenen Datenbankoperationen über BC4J aus (Abfragen, Einfügungen, Aktualisierungen und Löschoperationen). Die BC4J-Komponenten bieten eine funktionale Schnittstelle zur Datenbank, die sich Mithilfe der eingebauten Codegeneratoren oder Assistenten aufbauen lässt. Gültigkeitsprüfungen lassen sich auch in BC4J-Klassen implementieren. BC4J-Komponenten bestehen aus einer Kombination von Java und XML. Mit XML werden die Daten beschrieben und mit Java werden die Operationen auf den Daten ausgeführt. In BC4J enthält eine XML-Datei die Metadaten mit den Definitionen, die Java-Datei die Methoden zur Implementierung der Geschäftskomponenten. Die.java-Datei umfasst get() und set() Methoden, die zur Laufzeit dynamisch insert-, update- und delete-anweisungen generieren. Die Darstellung der statischen Informationsstrukturen, welche die Basis aller zeitlich nachgelagerten Aktivitäten in Oracle9iDS ist, stellt die Möglichkeit zur Auswahl, sich für Java-, bzw. SQL-Programmierung bei der Modellierung der Domain-Ontologie für UML- Metamodellierung oder SQL-Datenbankdesign zu entscheiden. Unter Domain-Ontologie ist die BC4J eigene virtuelle Datenbank mit den Elementen Entity Objects, Associations, Domains und Properties zu verstehen. Hinsichtlich der UML-Metamodellierung ist noch einmal auf Metadaten-Beschreibung (s. Kapitel 2.2) und MDA-Ansatz (s. Kapitel 2.1.2) zu verweisen. Insbesondere lassen sich so identische Interpretationen auf verschiedene Modelle anwenden, ohne die Prinzipien anpassen zu müssen. Das ORACLE9iDS bietet zu diesem Zweck die BC4J-Views und Links. View-Objekte definieren und filtern Daten mithilfe von SQL-Abfragen, die in den Entitätsobjekten definiert sind. View-Links drücken die Beziehungen zwischen den View-Objekten aus. Damit können spezifische problemorientierte Sichten auf die Fach-Domain unabhängig davon definiert werden, ob sie z.b. als gewöhnliche Java-Anwendung oder Web-Client konzipiert sind. 2 Data Manipulation Language ist Teil von SQL und enthält Befehle zur Datenmanipulation [KEMP04]. 13