Die Entwicklung einer einheitliche - sebis

Transcrição

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: 15.09.2005
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
Inhaltsverzeichnis
1
2
Einleitung.......................................................................................................................1
Begriffe und Konzepte..................................................................................................3
2.1
Grundlagen der Systemintegration .................................................................3
2.1.1 Datenintegration ....................................................................................5
2.1.2 Anwendungsintegration.........................................................................5
2.1.3 Prozessintegration..................................................................................6
2.2
Metadaten-Beschreibung .................................................................................6
2.3
Unternehmensanwendungen............................................................................7
2.3.1 Datenbanksystem ..................................................................................7
2.3.2 Verzeichnisdienst ..................................................................................8
2.3.3 Groupware-Server ................................................................................8
2.3.4 Informationsportale (Portal Server) ...................................................9
2.4
Systeme vom besonderen Interesse .................................................................9
2.4.1 BizTalk Server 2004 ...............................................................................9
2.4.2 Information Bridge Framework..........................................................12
2.4.3 Oracle9iBC4J .......................................................................................13
2.4.4 SharePoint Portal Server .....................................................................14
2.5
Funktionale und nichtfunktionale Anforderungen......................................14
3
Übersicht über die technischen Hilfsmittel in Microsoft Welt ...............................17
3.1
Microsoft .NET................................................................................................17
3.1.1 Xml-Unterstützung in .NET...............................................................19
3.1.2 Code-Generierung mit System.CodeDom-Namespace .....................22
3.1.3 Reflektion mit den System.Reflection- und System.Type-.....................
Namespace ...........................................................................................23
3.1.4 Webdienste mit ASP.NET ....................................................................23
3.2
Kommunikationsprotokolle und Schnittstellen ...........................................25
3.2.1 Component Object Model ....................................................................25
3.2.2 Ole DB ..................................................................................................26
3.2.3 Lightweight Directory Access Protocol ...............................................28
3.2.4 Active Directory Service Interfaces .....................................................29
3.2.5 Web Distributed Authoring and Versioning(WebDAV) .....................32
3.3
Objektmodelle .................................................................................................36
3.3.1 Collaboration Data Objects .................................................................36
3.3.2 ActiveX Data Objects und ADO.NET..................................................37
4
Microsoft-Unternehmensanwendungen in Hinblick auf Daten- Schema und
Porgrammierschnittstellen ....................................................................................................41
4.1
Active Directory ..............................................................................................41
4.1.1 Programmierschnittstellen...................................................................43
4.1.2 Metadatenbeschreibung.......................................................................44
4.2
Microsoft Sql Server .......................................................................................46
4.3
Exchange Server..............................................................................................47
4.3.1.1 ADO/CDO und OLEDB ..................................................................49
4.3.1.2 WebDAV...........................................................................................50
4.4
SharePoint Portal Server ...............................................................................53
III
5
6
7
8
9
Entwurf und Implementierungsdetails.....................................................................59
5.1
Architektur-Entwurf ......................................................................................59
5.2
Extrahieren der Metadaten............................................................................62
5.2.1
Microsoft Sql Server ...........................................................................63
5.2.2
Active Directory ..................................................................................66
5.2.3
Exchange Server..................................................................................68
5.2.4
Benutzerdefiniertes Modell ................................................................71
5.3
Code-Generierung...........................................................................................74
5.4
Komponenten für den Datenzugriff (Data-Access-Layers) ........................82
5.4.1 Exchange Server ..................................................................................85
5.4.2 Active Directory....................................................................................88
5.4.3 Microsoft SQL Server ..........................................................................89
5.4.4 Systeminterne Objekt-Datenzugriffsschnittstelle................................90
5.5
Dienstentwurf ..................................................................................................92
5.6
Konfigurationsschema und Dienstbeschreibung .........................................94
5.7
Deployment......................................................................................................97
Use-Cases und Szenarien .........................................................................................100
6.1
Testfälle..........................................................................................................100
6.2
Java-Client.....................................................................................................100
Zusammenfassung ....................................................................................................101
Ausblick .....................................................................................................................104
Literatur- und Quellenverzeichniss ........................................................................105
IV
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 CodeGenerierung…………………………………………………………………………………...79
Abbildung 22: Attribute, die Strukturen in relationalen Datenbanken beschreiben………….80
Abbildung 23: Klassendiagramm der Datenzugriffskomponente…………………………….83
Abbildung 24: Klassendiagramm der Konfigurationskomponente…………………………..92
V
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
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
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
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
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
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.
2.1.1
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.
2.1.2
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 MDA1-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
Integrationsbroker durch ein Modell beschreiben werden. Dieses Modell muss mit dem
festgelegten generischen Metamodell des Brokers konform sein.
2.1.3
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-DatenBeschreibung, 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
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 PortalServers analog zu der Integration des ausgewählten Groupware-Servers verläuft.
2.3.1
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
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].
2.3.2
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.
2.3.3
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
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 Emails 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.
2.3.4
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 KollaborationsFunktionen 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.
2.4.1
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
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
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
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. IBFLösungen erhöht die Produktivität der Informationsbearbeiter, indem sie die Möglichkeit
bereitstellen, Informationen zu bekommen und bearbeiten, ohne die bekannte OfficeApplikationen 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
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 DML2bezogenen 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 UMLMetamodellierung 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
2.4.4
SharePoint Portal Server
Mit den Webdienstschnittstelle, Konnektoren und dem Dokumentenmodell, die von
SharePoint Portal Server (SPS) angeboten werden, behandelt der SPS Problemstellungen, die
auch in dieser Arbeit in Betracht gezogen werden.
Der SharePoint Portal Server erfüllt die Anforderung eines modernen Portals [Wegn02]
Enterprise Anwendungen integrieren zu können, damit er einen strukturierten Zugang zu
Informationen
aus
verschiedenen
Quellen,
sowie
die
Offenlegung
deren
Anwendungsfunktionalitäten bieten kann. Dazu gibt es Konnektoren, z.B. zu SAP R/3, mit
denen SPS sich selbständig an den jeweiligen Unternehmensanwendungen anmeldet und
Dienste oder Inhalte für diese offen legt. Außerdem bietet SPS die Möglichkeit Termine und
Nachrichten aus Exchange Server und Benutzerdaten aus Active Directory zu importieren.
Die Windows SharePoint Portal Services (WSPS) basieren auf ASP.NET zur Präsentation.
Das Portal besteht aus einer oder mehreren WSPS-Webseiten mit denen der Webclient
interagiert. WSPS bieten zusätzlich Webdienstschnittstellen, mit denen die internettaugliche
Client-Anwendungen oder Integration von SPS in anderen Unternehmensanwendungen
ermöglicht wird. Die Webdienste sind abhängig von dem im SPS aufgestellten Objektmodell
realisiert.
2.5
Funktionale und nichtfunktionale Anforderungen
In Bezug auf die Ziele dieser Arbeit und die in vorherigen Punkten beschriebenen Grundlagen
und Systemanwendungen werden in diesem Unterkapitel funktionale und nichtfunktionale
Anforderungen an dem zu entwickelnden System aufgestellt.
Nichtfunktionale Anforderungen
n01: Erweiterbarkeit. Das System muss dynamisch erweiterbar sein. Es muss möglich sein
ohne ihre Komponenten ändern zu müssen, neue Anwendungen integrieren zu können. Das
System muss mit den Unternehmensanwendungen mit Hilfe von Adaptern verbunden
werden[AlMa02] sowie mit neuen Adaptern und Komponenten erweiterbar sein. In diesem
Zusammenhang muss das System Schnittstellen in einer Programmierschnittstelle offen legen.
n02: Benutzerfreundlichkeit. Die vom System offen gelegten Schnittstellen müssen
möglichst einfach und einheitlich verwendet werden können. Die Anforderung ist mit der
Aufsetzung der Schnittstellen auf XML-basierten Webdiensten erfüllt.
14
n02: Verteilung. Es soll eine möglichst schwache Kopplung der sich im System befindenden
Komponenten erreicht werden. Beispielsweise sollte die Datenzugriffskomponente nicht mit
den Modellen verlinkt sein.
n03: Sicherheit. Es müssen Kommunikationsmechanismen gegeben werden, die die sichere
Übertragung und Integrität der Daten sicherstellen.
Funktionale Anforderungen
f01: Metadaten. Die Informationsobjekte in den integrierten Systemen müssen in dem zu
entwickelnden System beschrieben werden. Es müssen Klassen erzeugt werden, die außerdem
mit Metainformationen angereichert werden müssen, falls es spezifische Eigenschaften für
das Informationsobjekt gibt, die mit der Struktur der Klasse nicht wiedergegeben werden
können.
f02: Benutzerdefinierte Klassen. Das System muss die Möglichkeit zur Verfügung stellen,
benutzerdefinierte Klassen zu erstellen, die sowohl mehrere Informationsobjekte aus den
integrierten Systemen erfassen können, als auch von diesen erben können. Mit der Vererbung
ist auch einen einheitlichen Zugriff über übergeordneten Klassen auf die Informationsobjekte
in den Unternehmensanwendungen gegeben.
f03: Komplexe Prozessabläufe - 1. Mit der Definition der benutzerdefinierten Klassen
können Informationsobjekte in mehreren Unternehmensanwendungen nur mit einer Frage
verändert, gelöscht oder hinzugefügt werden. Die Anforderung schließt nicht die Erfassung
von einzelnen Eigenschaften von Informationsobjekten ein, sondern immer von den Objekten
als Ganze. Außerdem müssen die Informationsobjekten-Klassen im System als Komponente
vorliegen, die zur Entwicklung eigener komplexen Geschäftsprozesse benutzt werden kann.
f04: Komplexe Prozessabläufe - 2. Die Verteilung der Anfrage an den mitwirkenden
Enterpise Systemen soll für alle möglichen (s. f03) benutzerdefinierten Informationsobjekten
als zyklenfreie Objektgrahpen automatisiert verlaufen.
f05: Veröffentlichung der Informationsobjekte: Für jedes der Informationsobjekten muss
jeweils einen entsprechenden Dienst erstellt werden.
In Abbildung 3 sind die Systemgrenzen eines Integrationsbrokers in Bezug auf die in dieser
Arbeit betrachteten Systeme angegeben.
15
Abbildung 3: Systemgrenzen aus der Sicht eines Integrationsbrokers
Die Systemgrenzen stehen auch mit den verwendeten Programmierschnittstellen der
Unternehmensanwendungen in Zusammenhang. Überbetrieblich legt der Broker
Informationsobjekte und Dienste über SOAP-basierte Webdienste offen.
16
3
In
Übersicht über die technischen Hilfsmittel in Microsoft Welt
diesem
Kapitel
werden
Programmierschnittstellen,
Frameworks
und
Kommunikationsprotokolle vorgestellt, die bei der Arbeit von Bedeutung sind. Einige
Technologien, wie Component Object Model sind nur indirekt eingesetzt worden, werden
aber zum besseren Verständnis der Programmierschnittstellen mit ihren Hintergrundprozessen
erläutert.
3.1
Microsoft .NET
Die Grundidee von .NET ist, eine betriebssystemunabhängige Laufzeitumgebung als
Entwicklungsplattform fürs Internet bereitzustellen. Es besteht aus einer Kombination von
.NET Framework und verschiedenen .NET Diensten, wie z.B. Web Services und ASP.NET.
Das Framework ist schichtweise aufgebaut, um ein strukturiertes Programmiermodell zur
Verfügung zu stellen. Die Bausteine von .NET sind die Laufzeitumgebung und die
Bibliotheken und Dienste (s. Abbildung 4).
Abbildung 4: .Net-Framework Schichtendiagramm
17
Die Common Language Runtime (CLR) übernimmt die Verwaltung von Systemdiensten, wie
die Thread- und Codeausführung, Überprüfung der Codesicherheit, Kompilierung, sowie
Speicherverwaltung [MASFRE]. Durch Garbage Collection ist der Programmierer von der
Aufgabe entlastet, den nicht mehr gebrauchten Speicherplatz freizugeben. Der Code, in dem
.Net-Programme geschrieben sind, wird daher als verwaltet (managed) bezeichnet und der
Code, der ohne das .NET Laufzeitsystem (CLR) ausgeführt werden kann, gilt als nicht
verwalteter Code [MSDN11]. COM-Komponenten sind für das CLR dagegen unmanaged
Code. Jedoch können unmanaged Komponenten durch COM Interop im verwalteten Code
wieder verwendet werden. Mit den COM Interop-Tools werden die benötigten Typen
importiert und dem managed-Code zur Verfügung gestellt. Über den so genannten Runtime
Callable Wrapper (RCW) sorgt das Laufzeitsystem u.a. für das Lokalisieren, Laden und für
die Zuordnung zwischen COM- und CLR-Datentypen.
Zum Zeitpunkt der Programmentwicklung wird der Code in einer Zwischensprache –
Intermediate Language (IL) übersetzt. Soll ein .NET Programm ausgeführt werden, sorgt der
darin enthaltene Code dafür, dass die .NET Laufzeitumgebung gestartet wird, die in IL
vorliegenden Programme und Komponenten geladen und diese zur Ausführung vorbereitet
werden. Die Vorbereitung besteht darin, die Verweise aufzulösen und die verwendeten
Typen3 zu laden. Anschließend wird der IL von einem Compiler, der sogenannte Just-In-Time
(JIT) Compiler, in ausführbaren Code übersetzt und unter Kontrolle von CLR ausgeführt. An
dieser Stelle werden auch Informationen vom Programm herausgefiltert, wie Herkunft und
Signatur des Herstellers, die für den Sicherheitsmechanismus wichtig sind. Der .NET-Code
wird auch als typensicher bezeichnet. Der Code ist typensicher, wenn er nur auf Speicher, der
ihm explizit zugewiesen wurde, und auf Typen nur durch offen gelegte Schnittstellen zugreift.
Die .NET-Klassenbibliothek setzt auf CLR auf, die Bibliotheken und Dienste zur Verfügung
stellt, deren Klassen von jeder beliebigen .NET Sprache aus aufrufbar sind. Die Klassen
werden in Namensräume strukturiert und verwaltet. Die oberste Schicht des Frameworks
bilden ASP.NET und Windows Forms, die die Möglichkeit bieten Web- bzw.
Windowsanwendung zu erstellen.
Die folglich aufgeführten Namensräume implementieren Konzepte, die später in der Arbeit
gebraucht werden. Die Klassen und Code-Beispiele sind entsprechend in C# angegeben.
3
In .NET wird zwischen Werte- und Referenztypen (Objekte) unterschieden. Bei Übergabe als Parameter einer
Methode werden für die Wertetypen Kopien und für die Referenztypen Referenzen auf das gleiche Objekt
verwendet.
18
Deklarationsinformationen
C# ist die Programmiersprache, die bei der Entwicklung des Prototyps verwendet wird. Ein
großer Teil der Sprache ermöglicht das Festlegen von Deklarationsinformationen zu den im
Programm definierten Entitäten, wie z.B. die „method-modifiers“ (public, protected…) für
die Zugriffsmöglichkeit einer Methode. C# ermöglicht aber auch die Einführung neuer Arten
von Deklarationsinformationen, die als Attribute bezeichnet werden. Diese werden über die
Deklaration von attribute-Klassen definiert. Eine attribute-Klasse wird von der abstrakten
System.Attribute-Klasse
abgeleitet.
Attribute
können
für
verschiedene
Arten
von
Deklarationen verwendet werden, wie z.B. Typdeklarationen, accessor-Deklarationen für
Eigenschaften, Schnittstellendeklarationen u.s.w. Die Attribute einer Deklaration werden in
eckigen Klammern angegeben. Ein Attribut besteht aus einem Namen, der dem Namen der
attribute-Klasse entspricht, und aus einer optionalen Liste positioneller und benannter
Argumente. Die benannten Argumente legen die Werte zusätzlich über den Namen des
Arguments im Konstruktor der argument-Klasse fest. Die positionellen Argumente dagegen
hängen von der Position des Arguments im Konstruktor ab. In dieser Arbeit werden eigene
Attribut-Klassen für die Deklarationen der aus einem relationalen Datenbanksystem
gewonnenen Entitäten definiert. Beispielsweise wird mit folgender Deklaration ein Mapping
einer Eigenschaft einer Klasse zu einem Xml-Element in einem Xml-Dokument definiert. Es
werden zwei Properties des Attributs angegeben, der Name des Elements und den
entsprechenden Namensraum im Xml.
[System.Xml.Serialization.XmlElementAttribute("message",
Namespace="urn:content-classes:")]
public MessageCollection message{…}
In dieser Arbeit werden Attribute auch Annotations genannt, wie sie bei anderen Plattformen
heißen (Java).
3.1.1
Xml-Unterstützung in .NET
Die Xml-Dokumente4 sind baumförmig strukturiert. Der Namensraum System.Xml enthält
Klassen, die den Knoten in der Baumstruktur entsprechen [HAN02]. Die Klassen
implementieren also den Xml Information Set und bilden ein Objektmodell für XmlDokumente. Es gibt zwei Programmierschnittstellen zur Verarbeitung von Xml:
4
Die Extensible Markup Language (Xml) ist ein Standard zur Erstellung strukturierter, maschinen- und
menschenlesbarer, baumförmiger Dokumente. Xml definiert dabei den grundsätzlichen Aufbau der Dokumente
[W32005], indem die Knoten der Baumstruktur in einem weiteren Standard – Xml Information Set [W32004]
definiert werden.
19
•
SAX (Simple Api for Xml) gibt den Parser vor, ein Xml-Dokument als Datenstrom
anzusehen und beim Durchlauf der Knoten im Dokumentenstruktur ein Strom von
Ereignissen zu produzieren. Es wird den Anwendungen überlassen, welche und wie
sie Ereignisse verarbeiten. Ein Nachteil besteht darin, dass nur ein vorwärtsgerichtetes
Arbeiten möglich ist. SAX ist in diesem Namensraum mit der Klasse XmlReader und
ihren Nachfahren XmlTextReader, XmlNodeReader und XmlValidatingReader
vertreten.
•
DOM (Document Object Model) stellt ein Objektmodell zur Verfügung, mit dem der
gesamte Dokumentbaum im Speicher aufgebaut wird. So werden Beziehungen
zwischen den Knoten, wie z.B. Eltern-, Geschwister- und Kinderknoten, beibehalten.
In diesem Objektmodell entspricht jeder Knoten der Instanz einer Klasse, die von
XmlNode abgeleitet wird. Das gesamte Dokument wird durch die Klasse
XmlDocument repräsentiert.
System.Xml.XmlSchema
Ein Xml-Schema ermöglicht das Erstellen und Überprüfen von Xml-Dokumenten. Es
definiert die Struktur der Xml-Dokumente durch Festlegen der Elemente, die in Dokumenten
verwendet werden dürfen. Es definiert außerdem für diese Elemente die Struktur und die
Typen, denen diese Elemente entsprechen müssen, um für dieses Schema gültig zu sein. Das
Schema ist seinerseits auch ein Xml-Dokument, in dem beispielsweise Elemente und
Attribute durch element- und attribute-Elemente deklariert werden und die Struktur mit Hilfe
von complexType- und simpleType-Elemente vorgeschrieben wird. Die Struktur und gültiger
Inhalt eines Xml-Schema-Dokuments wird mit der Xml Schema Definition (XSD5)–Sprache
definiert [MSDN13].
Der Namensraum System.Xml.Schema besteht aus Klassen, die die Unterstützung für XSD
bereitstellen. Das sind die Klassen, die zur Validierung der Xml-Dokumente auf Gültigkeit
benötigt werden, sowie die Klassen, mit denen das Schema Object Model (SOM) gebildet
wird. Dabei wird ähnlich wie bei DOM, die Baumstruktur eines Schemas in einem
Objektmodel abgebildet. Beispielsweise enthält die XmlSchema-Klasse die Definition eines
Schemas. Alle XSD-Elemente sind dem schema-Element untergeordnet, das im Objektmodel
5
Xml Schema ist eine Sprache zur Definition von Xml Dokumenten. XSD ist die Abkürzung von Xml Schema
Definition, standardisiert von World Wide Web Consortium[W32001]. Dabei geht es um standardisierte
Schemaüberprüfung und -zuordnung, sowie um die Definition von Datentypen für XSD.
20
von
der
XmlSchema-Klasse
XmlSchemaComplexType
und
vertreten
wird.
Entsprechend
XmlSchemaSimpleType
das
repräsentieren
complexType-
und
die
das
simpleType-Element. Nach der programmatischen Erstellung eines Schemas kann sie mit der
Methode Compile der XmlSchema-Klasse verifiziert werden. Dabei wird z.B. überprüft, ob
die Struktur richtig ist und ob Typen richtig abgeleitet sind. Während der Validierung können
über einen ValidationEventHandler die Fehler und Warnungen abgefangen werden.
Mit der Compile-Methode wird außerdem der post-schema-validation infoset [W30304]
erstellt. SOM repräsentiert das Model vor und nach dem Ausführen der Compile-Methode.
Eigenschaften wie z.B. ElementType der XmlSchemaElement-Klasse werden erst nach der
Validierung des Schemas gesetzt. Vor der Validierung enthält es eine Null-Referenz.
System.Xml.XPath
Der Namensraum enthält die Klassen, die die Abfrage von Xml-Strukturen mit Hilfe der
XPath-Sprache [W31999] ermöglichen. Die wichtigsten Klassen in diesem Namespace sind
die XPathDocument und die XPathNavigator. Der XPathNavigator basiert auf dem XPathDatenmodell, das auf dem Xml Information Set beruht ([W31999] - B References). Eine
Instanz dieser Klasse wird durch Aufruf der Methode CreateNavigator der XmlNode- oder
XPathDocument-Klasse erhalten. XPathNavigator stellt Methoden zur Verfügung, die zur
Filterung von Xml-Strukturen oder zur direkten Navigation durch den Knoten eines XmlDokuments benutzt werden können. Bei der Filterung wird ein XPathNodeIterator
zurückgegeben, mit dem die Ergebnisse der Anfrage durchlaufen werden können. Einmal
gefiltert, gibt es keine Möglichkeit weiter mit den Klassen aus dem System.Xml-Namensraum
zu arbeiten. Die Verbindung zwischen dem System.Xml.XPath-Namensraum und dem
Objektmodel in System.Xml wird erst in Version 2.0 des .NET-Frameworks eingeführt. Eine
Alternative dazu bieten die zwei Methoden SelectNodes und SelectSingleNode der
XmlDocument-Klasse, die entsprechend eine Liste von Knoten - XmlNodeList und einen
Knoten – XmlNode zurückgeben [HANI02].
System.Xml.Serialization
Serialisierung bedeutet das Speichern des Zustandes von Objekten, z.B. in eine Datei, oder die
Verpackung der Objekte für den Transport über Prozess- und Maschinengrenzen bei einem
entfernten Aufruf. Mit dem Zustand sind die aktuellen Daten und Variableninhalte des
Objekts gemeint. Xml ist innerhalb von .NET-Framework die Grundlage für die
21
Serialisierung
von
Klasseninstanzen.
Die
Namensräume
System.Xml
und
System.Xml.Serialization sind Bestandteil von dem Framework und bieten die für diesen
Zweck benötigten Funktionalitäten. Mit Deserialisierung wird das Laden einer Klasseninstanz
aus einem Xml-Dokument bezeichnet.
Der Prozess der Serialisierung und Deserialisierung kann über den Einsatz verschiedener
Attribute gesteuert werden. Beispielsweise kann das Wurzelelement eines Xml-Dokuments
mit [XmlRoot()] geändert werden, oder anstatt für ein Feld ein eigenes Xml-Element zu
generieren, kann mit [XmlAttribute] ein Attribut des umgebenden Elternelements hinzugefügt
werden.
3.1.2
Code-Generierung mit System.CodeDom-Namespace
Für die automatische Code-Generierung wird in .NET-Framework den Namensraum
System.CodeDom (Code Document Object Model) bereitgestellt. Er enthält Klassen, die viele
Quellcode-Konstrukte repräsentieren, ohne sich auf die Syntax einer Programmiersprache
festzulegen
[CAZZ04]. Die Klassen können benutzt werden, um die Struktur eines
Quellcode-Dokuments als ein Objektgraph zu modellieren. Der Graph kann danach mit Hilfe
des
System.CodeDom.Compiler-Namensraums
als
Quellcode
in
einer
unterstützten
Programmiersprache ausgegeben werden. Für die Codegenerierung aus einem Xml Schema
wird der CodeDom-Namensraum in Zusammenhang mit der Serialisierungskomponente im
nächsten Punkt beschrieben.
Codegenerierung aus XSD
Das xsd.exe-Tool generiert Code aus einer Xml Schema-Definition. Es bietet jedoch keine
Möglichkeit, diesen Prozess anzupassen. Das Tool benutzt Klassen, wie XmlSchemas,
XmlSchemaImporter, XmlTypeMapping, XmlCodeExporter von System.Xml.SerializationNamespace, die in .Net 1.1 nach der Dokumentation nur für internen Gebrauch gedacht sind.
Diese Klassen implementieren das XSD->CLR-Datentypenzuordnung, die Vererbung von
Typen in XSD, Serialisierungsattribute und weitere Problemstellungen, die bei manueller
Generierung von Code durch Durchlaufen des Xml Schema-Objectmodell bestehen. Mit der
XmlSchemaImporter-Klasse werden Typen einer Ansammlung von XmlSchema-Objekten
nach ihrem qualifizierten Namen (Namensraum und Name) importiert. Sie werden als
XmlMapping-Objekte (stellt die Zuordnung XSD->CLR-Datentypen dar) zurückgegeben und
22
durch Einsatz einer Instanz der XmlSchemaExporter-Klasse in einem CodeDom-Namensraum
eingefügt. Einen Nachteil besteht darin, dass nur global definierte Elemente, die Kinder des
schema-Elements in XSD sind, importiert werden können. Nachdem der Namensraum
aufgefüllt ist, können aber weitere Änderungen an dem CodeDom-Objektgraph vorgenommen
werden.
3.1.3
Reflektion mit den System.Reflection- und System.Type-Namespace
Der System.Type stellt Typdeklarationen wie Klassentypen, Schnittstellentypen, Wertetypen
etc. dar. Es stellt die Basis für die System.Reflection-Funktionalität und das Hauptverfahren
für den Zugriff auf Metadaten [MSDN20].
In .NET enthalten Assemblies Module, die Module bestehen aus Typen (Klassen, Strukturen),
die ihrerseits aus Member bestehen. Reflektion stellt Objekte zur Verfügung, die die
genannten Konstrukte einkapseln. Mit dem System.Reflection–Objektmodell lassen sich
Typinformationen über ein vorhandenes Objekt erhalten sowie Instanzen von Typen
dynamisch erzeugen (System.Reflection.Emit). Mit FieldInfo und PropertyInfo lassen sich
Informationen wie z.B. Name und Datentyp ermitteln, sowie Werten abfragen oder festlegen.
Außerdem können auch Attributen eines Konstrukts abgerufen werden, z.B. liefern die
folgenden Anweisungen alle deklarierten Attribute einer Eigenschaft und eines Typs.
System.Reflection.PropertyInfo: propertyInfo.GetCustomAttributes(…)
System.Type: type.GetCustomAttributes(…)
3.1.4
Webdienste mit ASP.NET
Aus dem Bedarf an Anwendungen, die auf mehreren Computern ausgeführt werden, entstehen
Modelle für die Verteilung und Interaktion von Computer-Programmen. Die Webdienste von
Microsoft .NET stellen Dienste für andere Prozesse im Internet oder Intranet zur Verfügung.
Da Webdienste auf offenen Standards wie XML, HTTP und SOAP(Simple Object Access
Protocol) basieren, sind sie unter Verwendung eines URL (Uniform Ressource Locator)
einfach zu adressieren, aufzurufen und konsumieren [MASFRE].
Mit SOAP wird die Möglichkeit XML-basiert Anfragen und Antworten über HTTP zu
versenden. Damit können sowohl die Web-Methode als auch deren Aufruf-Parameter
spezifiziert werden. Auf gleiche Weise werden die Ergebnisse eingepackt und zurückgegeben.
SOAP-basierte Webdienste ermöglichen die Übergabe von komplexen Datenstrukturen in
23
Xml-Format sowie Funktionalitäten, wie z.B. Authorisierung und Athentifizierung über
Webdienst-Erweiterungen (WS-Extensions). Bei einem Dienstorientierten-Ansatz wird der
Dienst genau einmal implementiert und auf einem Server für Zugriffe von außen
bereitgestellt.
Die Webdienste mit ASP.NET müssen als Klassen-Dateien in einem Virutelen-Verzeichnis
von Internet Information Server (IIS) gespeichert sein und die Endung .asmx besitzen. Die
Erstellung von ASP.NET-Webdienste kann nur durch die Deklaration von Attributen für die
Klasse und ausgewählte Methoden erfolgen. Die Webdienst Klasse kann aber auch von der
Klasse System.Web.Services.WebService abgeleitet sein.
public class ExchangeMessageDAO : System.Web.Services.WebService
{
… …
[WebMethod]
public bool deleteMessage(Message message)
{
return dal.deleteObject(message);
}
……
}
Die Webdienste in ASP.NET sind WS-I Basic-Profile-konform und damit für alle WS-Ikonforme Klienten nutzbar. Mit dem Basic-Profile werden Regeln für die SOAP-Nachrichten
festgelegt und alle, die diese Regeln bei der Implementierung des Protokolls befolgen, sollten
Problemlos mit einander über SOAP-Nachrichten kommunizieren können. ASP.NET
implementiert aber die Erweiterungen nicht, die z.B. die Authentifizierung über Webdienste
ermöglichen. Diese müssen separat installiert werden.
Das neue Framework von Microsoft für verteilte Anwendungen - Indigo umfasst mehrere
Komponenten und Technologien, wie z.B. seinen Vorgänger .NET-Remoting und Framework
zur Entwicklung von WS-I konforme Webdienste mit mehreren zur Verfügung gestellten
Erweiterungen. Mit Indigo können auch Anwendungen entwickelt werden die nicht in IIS
installiert sein müssen, das wird von den Microsoft Windows Activation Services (WAS)
ermöglicht. Indigo garantiert nicht die Integration von Anwendungen, die die für ASP.NET
entwickelten WS-* (WS-Erweiterungen)-Komponenten verwenden.
using System.ServiceModel;
[ServiceContract]
class Calculator
{
[OperationContract]
private int Add(int a, int b){ return a+b; }……
24
Wie in dem Beispiel zu sehen ist, führt Indigo das Konzept von Contracts. Jede IndigoDienstklasse implementiert ein Service Contract., die die Operationen der Dienste offen
legen.
3.2
Kommunikationsprotokolle und Schnittstellen
3.2.1
Component Object Model
Component Object Model (COM) ist die Microsoft Technologie für die Entwicklung und
Nutzung
objektorientierter
Softwarekomponenten
[SCHW01].
COM
stellt
einen
Binärstandard für Komponenten dar und ist daher programmiersprachunabhängig. Mit dem
Binärstandard wird ein Satz von Datentypen definiert und festgelegt, wie diese in Bytefolgen
umgesetzt werden. Darüber hinaus wird einen Mechanismus angegeben, wie Komponenten
lokalisiert werden und wie den angehörigen Programmcode aufgerufen wird.
COM basiert auf die Object Linking and Embedding (OLE)-Technologie, die heute in Form
von ActiveX-Technologie6 Teil von COM ist. Der Begriff Automation entstand aus der ersten
Version von OLE und diente der entfernten Steuerung von Office-Anwendungen wie Excel
und Word. COM Automation steht für dynamischen Aufruf und ist eine Weiterentwicklung
der OLE-Automation.
COM-Objekte bilden Server, die von anderen Programmen, Clients, genutzt werden können.
Im Gegensatz zu statischem Binden, wo der Client zur Entwicklungszeit die Position(offset)
einer Funktion in einer virtuellen Funktionstabelle (vTable) kennt, ist bei dynamischem
Binden die Position einer Methode nicht bekannt. Diese wird mit Hilfe von verschiedenen
Mechanismen zur Laufzeit ermittelt. Ob eine Komponente mit oder ohne Automation
entworfen ist, kann aus den implementierten Schnittstellen festgestellt werden. Alle COMKlassen implementieren die Schnittstelle IUnknown. Alle COM-Schnittstellen sind auch von
IUnknown
abgeleitet.
Diese
Schnittstelle
definiert
drei
Methoden
für
die
Komponentennutzung. Mit QueryInterface wird überprüft, ob die Komponente eine als
Parameter übergebene Schnittstelle unterstützt und gegebenenfalls eine Referenz auf diese
Schnittstelle zurückgibt. Mit den weiteren zwei wird einen Verweiszähler entsprechend hoch
gezählt oder heruntergesetzt. Die Verwendung einzelner Komponenten wird von COM durch
das Zählen von Verweisen registriert. Beim Aufruf einer Methode auf einer Schnittstelle wird
zuerst überprüft, ob der Verweiszähler auf 0 steht. Wenn das der Fall ist, wird zuerst die
Komponente, zu der die Methode gehört, geladen und initialisiert. Andernfalls wird der
6
ActiveX stellt einen COM-Dienst dar, der im Beitrag [Q154544] in der Knowledge Base genauer mit den
Teiltechnologien definiert wird.
25
Zähler erhöht, bei einer Methodenrückgabe wird der Verweiszähler heruntergesetzt. Erreicht
der Verweiszähler den Wert 0 wird die Komponente freigegeben.
Die über dynamisches Binden benutzten Objekte implementieren die IDispatch Schnittstelle,
die außer von IUnknown vererbten Funktionalitäten noch die Möglichkeit bereitstellt, eine
Methode über ihren Namen in Textform aufzurufen.
Die wesentlichen Probleme von wieder verwendbaren Komponenten sind die Namens- und
Versionsauflösung. Beim Gebrauch von externen Komponenten muss der Code einer
Anwendung immer auf dem aktuellen Stand gehalten werden, damit Inkompatibilitäten
vermieden werden können. Beim Einsatz von COM-Komponenten kann das Problem
umgangen werden, indem beim Aufruf von externen Schnittstellen und Komponenten GUID
(Global Unique Identifier – eine 128 Bit Zahl) benutzt wird. Jede Schnittstelle in COM ist
durch eigene GUID eindeutig definiert.
Da viele Microsoft Unternehmensanwendungen über COM-Schnittstellen verfügen, ist die
Idee entstanden, die einheitliche Webdienstschnittstelle über die von den COM-Komponenten
bereitgestellten Schnittstellen zu bilden. Im Ablauf des Arbeitsprozesses ist diese Absicht
verworfen, weil gleichzeitig das Ziel bestand, eine Modelgetriebene Architektur zu schaffen.
Das bedeutet, sich nicht auf die Funktionalitäten der COM-Komponenten, sondern auf die
Modelle in den Unternehmensanwendungen zu konzentrieren. Für diese Modelle werden
universelle Datenzugriffsfunktionen als Webdienste ausgesetzt, indem internettaugliche
Programmierschnittstellen der Unternehmensanwendungen bevorzugt werden.
3.2.2
Ole DB
OLE DB definiert eine umfassende Menge von COM-Schnittstellen, die verschiedene
Datenbank-Verwaltungsdienste
(DBMS7)
einschließen
und
bildet
somit
die
Programmierschnittstelle, die die Microsoft-Strategie für Universal Data Access[MSDN05]
umsetzt. Die Strategie stellt Anforderungen für einen einheitlichen Zugriff und für die
Fähigkeit in Datenquellen, die nicht Teil eines DBMS sind, zugreifen zu können. Einheitlich
bedeutet in diesem Zusammenhang, dass es grundsätzlich möglich ist, die gleiche Abfrage in
allen Datenquellen durchzuführen. Im Gegensatz zu ODBC8 ermöglicht OLE DB den Zugriff
sowohl auf relationale (strukturierte), als auch auf nichtrelationale und hierarchische (semi-
7
Eine Datenbank wird überlicherweise von einem Datenbank-Managementsystem(DBMS) verwaltet[KEMP04].
Open Database Connectivity ist der Vorgänger von OLE DB, der sich auf strukturierte(relationale)
Datenquellen und SQL-Befehle beschränkt. [MSDN02]
8
26
strukturierte) Datenstrukturen (s. Kapitel 2.2). Darüber hinaus können OLE DB-Befehle nicht
nur SQL-Anweisungen sein. Sie müssen nur im verständlichen für den Zielprovider Syntax
geschrieben sein.
Weiterhin führt OLE DB das Konzept von Datenprovider und Datenkonsumenten ein und
stellt eine Relation zwischen diesen. Die Datenkonsumenten sind die Clientkomponenten, die
Daten anfordern und transportieren. Die Datenprovider enthalten die Daten und legen diese
offen. OLE DB-Datenprovider können viele Datenquellen unterstützen – von einer SQL
DBMS bis zu Textdateien und Datenströme [ESPO01]. Eine Liste mit OLE DBDatenprovidern für relationale Datenbanken, Dateisysteme und andere Datenquellen sowohl
von Microsoft, als auch von anderen Herstellern ist in [SCHW01] angegeben.
Sowohl Konsumenten als auch Provider sind COM-Objekte. Über abstrakten Schnittstellen,
wie DataSource, Command, Rowset, implementiert von einem Datenprovider, können die
Konsumenten z.B. eine Verbindung mit einer beliebigen Datenquelle (Datasource) anfordern,
über diese Command ausführen lassen und Rowset abrufen.
OLE DB beinhaltet, außer Konsumenten und Provider, eine dritte COM-Komponente, die
OLE DB-Dienste. Diese erweitern die Funktionalitäten von OLE DB. Sie verarbeiten, die von
der Datenquelle erhaltenen Daten (Rowset) und geben diese anschließend an den
Datenkonsument weiter.
OLE DB stellt ein Interaktionsmodel, bei dem die Verbindung zwischen Datenkonsumenten
und Datenprovider nicht die ganze Zeit aufrechterhalten werden muss. Nachdem die
Verbindung hergestellt ist, die Abfrage abgeschickt ist und das Ergebnis vorliegt, wird die
Verbindung wieder getrennt. Mit dem Ergebnis wird offline gearbeitet und bei Änderungen an
den Datensätzen die Verbindung wieder hergestellt [ESPO01].
Damit der Zugriff auf unterschiedlichen Datenquellen überhaupt möglich ist, definiert OLE
DB Datentypen, die aus OLE- und Microsoft Windows-Datentypen zusammengesetzt sind.
Der Datenprovider übernimmt die Zuordnung von OLE DB-Datentypen und nativen für die
Datenquelle Datentypen, sowie die Durchführung benötigter Transformation. Die OLE DBDatentypen werden durch Indikatoren eindeutig festgelegt. Der Indikator ist eine Variable von
dem enumerierten Typ DBTYPE und wird den Metadaten hinzugefügt, um den Datentyp
eines Parameters oder einer Spalte zu spezifizieren [MSDN09].
enum DBTYPEENUM {
// The following values exactly match VARENUM
// in Automation and may be used in VARIANT.
DBTYPE_EMPTY = 0,
DBTYPE_NULL = 1,
27
DBTYPE_I2 = 2,
DBTYPE_I4 = 3,
…………
}
Der Typ DBTYPE_I4 einer Spalte wird also in den Metadaten durch einen Wert von 2, der
die Position in der Enumerierung entspricht, angegeben und stellt beispielsweise in .NET
einen 4-Byte Integer dar.
Schemainformationen werden bei OLE DB über den vordefinierten „schema rowsets“ mit
IDBSchemaRowset::GetRowset erhalten [MSDN10]. Die „schema rowset“ legen das Format,
wie Spaltennamen und Spaltendatentypen, der zurückgegebenen System.Data.DataTableSchemainformationen fest. Alle „schema rowsets“ enthalten außerdem einen eindeutigen
Identifikator GUID, der als Parameter an GetRowset übergeben wird. Der TABLES-Rowset
(TABLES ist der Wert von GUID) z.B. identifiziert die Tabellen, inklusive Sichten, die in
einem Datenbank-Katalog definiert und für einen gegebenen Benutzer zugreifbar sind. Der
FOREIGN_KEYS-Rowset dagegen spezifiziert die Fremdschlüsselspalten. Weiterhin ist
beispielsweise festgelegt, das die dritte Spalte der zurückgegebene Tabelle für den
FOREIGN_KEYS-Rowset den Namen PK_TABLE_NAME hat, vom Typ DBTYPE_WSTR
ist und somit als Wert den Namen der Tabelle hat, die vom Fremdschlüssel referenzierten
Primärschlüssel enthält.
3.2.3
Lightweight Directory Access Protocol
Das Protokoll ist entworfen, um den Zugriff auf Verzeichnisse9 zu ermöglichen, die die
X.500-Modelle [RFC2256] unterstützen. Im Gegensatz zu X.500 Data Access Protocol
(DAP) definiert LDAP den Aufbau des Verzeichnisses nicht, sondern nur ein Teil der X.500DAP Funktionen (die search-, compare-, add-, delete-, modify-, modifyRDN-Funktion
[SCHW01]), die aber durch Emulation den vollständigen Zugriff auf X.500-Verzeichnisse
ermöglichen. Es wurde von der Internet Engineering Task Force (IETF) standardisiert
[RFC2251] und basiert auf dem TCP/IP-Stack mit der Portnummer 389.
Ein LDAP-Verzeichnis enthält Einträge, die ihrerseits aus Attributen bestehen. Die Attribute
besitzen Typen, die durch ihren Namen eindeutig identifizierbar sind und auf Grundlage von
X.500-Benutzerschema [RFC2256] definiert werden. Jeder Eintrag besitzt ein Attribut des
Typs „objectClass“, das den Typ des Eintrags spezifiziert. Die Attribute können einen oder
9
Ein Verzeichnis dient dem Verwalten, Finden und Nutzen von entfernten Resourcen (s. Kapitel 2.3.2).
28
mehrere Werte enthalten.
Beispielsweise enthält ein Eintrag für das Attribut „objectClass“
den Wert „person“, für das Attribut „Name“ (oder der LDAP-Name CN, für Common Name)
- „Doe“ und für das Attribut „Hobby“- „Kino, Malen, Theater“. Die LDAP-Namen für die
Attribute „Country“ und „Organization“ sind entsprechend C und O. Darüber hinaus besitzt
jeder Eintrag das Attribut „distinguishedName“ (DN) in X.500-Notation, das ihn eindeutig
bezeichnet. Er besteht aus Attribut-Wert-Paare (RDN für Relative DN), wie im Folgenden
Beispiel erläutert: „cn=Doe, o=tum, c=de“ bezeichnet einen DN, bestehend aus mehreren
durch Komma getrennte RDNs. Daraus ergibt sich die Anordnung der Einträge in einer
Baumstruktur. Diese wird Directory Information Tree genannt und wird weiter im nächsten
Kapitel in Zusammenhang mit Active Directory Services behandelt.
3.2.4
Active Directory Service Interfaces
Mit Active Directory Service (ADS) bietet Microsoft eine homogene Sicht auf eine Vielzahl
von Verzeichnisdiensten (z.B. Active Directory, Exchange Server und Internet Information
Server), indem für jeden Verzeichnisdienst einen Provider zur Verfügung gestellt wird und
ein allgemeines ADS-Meta-Objektmodell auf den Providern aufgesetzt wird. Die Provider (s.
Abbildung 5) realisieren den eigentlichen Zugriff auf die Verzeichnisobjekte und stellen
COM/DCOM-Schnittstellen für die ADS-Interfaces (ADSI) bereit, die ihrerseits von den
Benutzern verwendet werden, um Verzeichnisobjekte in Form von COM/DCOM-Objekten zu
erhalten.
Abbildung 5: Active Directory Service Interfaces
29
Die in der Abbildung dargestellten Provider werden mit Windows 2000 und Windows 2003
installiert. Einen ADSI-Dienstprovider für den Microsoft Internet Information Server
Metabase wird mit dem Internet Information Server installiert.
ADSI macht es viel einfacher Anwendungen Verzeichnisdiensttauglich zu machen. Es wird
nur mit einem einzigen Set von Verzeichnisdienstschnittstellen gehandelt, ohne Rücksicht
darauf
zu
nehmen,
welche
Verzeichnisdienste
installiert
sind.
Die
Verzeichnisdienstschnittstellen sind COM-Schnittstellen, die für den Zugriff auf die
Funktionen und Eigenschaften von Verzeichnisdiensten über die Dienstprovider benutzt
werden. Die Entwickler und Administratoren spezifizieren und verwalten Ressourcen in
einem Verzeichnisdienst, unabhängig von der Netzwerkumgebung, die die entsprechende
Ressource beinhaltet. ADSI ermöglicht allgemeine Administrativaufgaben zu bewältigen,
wie z.B. Einfügen eines neuen Benutzers, Druckerverwaltung, sowie Lokalisierung von
Ressourcen in einer verteilten Computerumgebung. Das Meta-Objektmodel ist mit dem von
LDAP eng verwandt [BEIG97]. Die Attribute heißen bei ADSI „Properties“ und beschreiben
beliebig genau ein Verzeichnisobjekt (einen Eintrag im Verzeichnis). Der Kern des MetaObjektmodels unterscheidet zwischen Container-Objekte und Directory-Leaf-Objekte, welche
die persistenten Objekte des darunter liegenden Verzeichnisdienstes repräsentieren. Ein
Container kann sowohl andere Einträge, als auch Container beinhalten. Die Schnittstellen im
Meta-Objektmodell, die diese abstrakten Objekte vertreten, werden von den Dienstprovidern
spezifisch für den entsprechenden Verzeichnisdienst implementiert. Die Methoden und
Eigenschaften, die von den ADSI-Schnittstellen offen gelegt werden, werden nicht von allen
Dienstprovidern unterstützt. Je nach Verzeichnisdienst können verschiedene Objekttypen und
Eigenschaften
gespeichert
werden
und
verschiedene
Netzwerkprotokolle
und
Authentifizierung verwendet werden. Also gibt es Schnittstellen und Methoden, die z.B. mit
LDAP funktionieren, aber nicht mit WinNT. Damit definiert jeder Provider eine eigene
Hierarchie von Objekten. Jedes Objekt besitzt innerhalb der Hierarchie einen eindeutigen
Pfad (ADsPath), der auch als URL angegeben werden kann und im Allgemeinen
folgendermaßen aussieht:
Namensraum(Providername)://Host(Domäne)/provider_spezifischen_ressource_identifikator
In Tabelle 1 sind die Provider aufgelistet, die für diese Arbeit von Bedeutung sind.
30
Provider
Beschreibung
LDAP
Namensraum-Implementierung kompatibel mit Lightweight Directory Access Protocol
WinNT
WinNT Namensraum-Implementierung kompatibel mit Windows NT/Windows 2000.
IIS ADSI
Der ADSI-Dienstannbieter, genau wie WMI-Dienstanbieter, stellt mithilfe von IISAdminobjekte eine einheitliche Syntax für den Zugriff auf IIS-Konfigurationsdaten zur
Verfügung.
Tabelle 1: ADSI-Provider
Mit dem LDAP-Provider wird der Zugriff auf LDAP-fähige Verzeichnisdienste ermöglicht,
wie z.B. Windows 2000/2003 Active Directory und Microsoft Exchange Server. Mit dem
WinNT-Provider ist der Zugriff auf das Windows-NT4-Verzeichnis und Windows
2000/2003-System ohne installiertes Active Directory möglich. Der WinNT-Provider kann
auch das Active Directory ansprechen, jedoch nur eingeschränkt. Die Dienstprovider werden
in Zusammenhang mit den entsprechenden Unternehmensanwendungen im Kapitel 4
behandelt.
Die ADSI-Komponente definiert primären, unmanaged Datentypen [MSDN19], die sie in
ihrer Strukturen und Schnittstellen benutzt. In der Struktur ADSTYPEENUM [MSDN17]
definiert sie weitere Datentypen, die für die Identifikation des Typs eines Attributs im ADSI
benutzt wird. Der Dienstprovider ist dafür zuständig, die ADSI Datentypen den für das
Kommunikationsprotokoll spezifischen Datentypen zuzuweisen.
.NET-Framework-Directory Services-Komponente
Die in diesem Namensraum implementierte Komponente ermöglicht den einfachen Zugriff
auf Verzeichnisdienste aus verwaltetem Code.
Namensraum
Mit dem System.DirectoryServices-
kann die Struktur eines Verzeichnisdienstes durchlaufen, durchsucht und
geändert werden, sowie die Eigenschaften eines Knotens gelesen oder überschrieben werden.
Die wichtigsten Komponenten-Klassen sind DirectoryEntry und DirectorySearcher, die die
ADSI-Technologie verwenden. Die DirectoryEntry-Klasse repräsentiert einen Knoten oder
Objekt in der Verzeichnisdienst-Hierarchie. Sie ermöglicht das Anbinden von Objekten, das
Lesen und Aktualisieren von Eigenschaften und, mit Hilfe von anderen Klassen in diesem
Namensraum, die Navigation im Verzeichnisdienst. Untergeordnete Knoten können somit
gelöscht, umbenannt, erstellt oder verschoben werden. Beim Anbinden wird das Objekt mit
31
dem ADsPath-String eindeutig identifiziert. Von hier aus können weitere Objekte angebunden
werden, indem nach diesen gesucht oder navigiert wird.
Die Properties-Eigenschaft der DirectroryEntry-Klasse enthält die Attribute eines gebundenen
Objektes. Die DirectoryServices-Komponente ist für das Mapping zwischen .NETDatentypen und ADSI-Datentypen verantwortlich. Der System.Boolean Datentyp wird heißt
in ADSI ADSTYPE_ENUM (s. Kapitel 3.2.4). Um ein date/time-Attribut (property) eines
Objekts (entry) im Verzeichnisdienst zu setzen wird ein .NET-System.DateTime-Objekt
gebraucht.
DateTime dt = new DateTime(2005, 5, 5, 11, 4, 5, 0);
entry.Properties["myDateTimeProperty"].Value = dt;
entry.CommitChanges();
Der Typ für date/time heißt im ADSI ADSTYPE_UTC_TIME. Um die Änderungen in
Verzeichnisdienst zu speichern wird die CommintChanges-Methode aufgerufen. Einige
Datentypen im ADSI haben keine Äquivalente im .NET-Framework. Wenn der
Verzeichnisdienst z.B. einen COM-Objekt zurückgibt muss das Objekt über COM Interop (s.
Kapitel 3.1) mit einer ADSI-Schnittstelle gecastet werden. So einen Typ ist z.B. „DN with
Binary“. Er stellt eine Folge von Bytes dar, die einen binären Wert und eindeutigen Namen
enthält. Die Datentypen im Zusammenhang mit DirectoryService und Active Directory
werden noch im Kapitel 5.2 behandelt.
Mit der DirectorySearcher-Klasse kann das Verzeichnis durchsucht werden. Der einzige
ADSI-Provider, der das unterstützt, ist der LDAP-Provider, also ist das Durchsuchen eines
Verzeichnisses mit der DirectoryServices-Komponente nur bei Active Directory möglich. Die
Klasse enthält zwei Eigenschaften, die für diese Arbeit von Bedeutung sind. Die SizeLimitEigenschaft beschränkt die Anzahl zurückgegebener Objekten. Der Standartwert von 0
bedeutet, dass die von Active Directory-Server vorgegebene Einschränkung von 1000
Einträgen verwendet wird. Die PageSize-Eigenschaft beschränkt bei einer Anfrage die
Höchstanzahl von Objekten, die der Active Directory-Server auf einmal (Seitengröße)
zurückgeben soll. Im Gegensatz zu SizeLimit, wenn die Client-Anwendung mehr Daten
anfordert, startet der Server die Suche an der Stelle, wo er durch die PageSize-Einschränkung
unterbrochen wurde.
3.2.5
Web Distributed Authoring and Versioning(WebDAV)
Das WebDAV-Protokoll [RFC2518] erweitert das HTTP-Protokoll um neue Methoden,
Header, Xml-Anfragen und Antworten, die einen WebDAV-Client die Erzeugung, Änderung
32
und Verschiebung von Dateien und Verzeichnisse auf dem Server erlaubt. Der Client kann
sowohl auf die Metadaten einer Ressource zugreifen, wie z.B. den Autor und das
Erstellungsdatum eines Dokuments ändern, als auch die Ressourcen für das Lesen von
anderen Benutzern sperren. WebDAV definiert die Methodenparameter sowohl als HTTPHeaders, als auch im Xml-Dokument im Inhalt der HTTP-Anfrage. Xml wird aber auch für
die Ergebnisse der Anfrage verwendet. Die Definition der Elemente und der Struktur der
Xml-Dokumente wird von WebDAV vorgegeben [RFC2518].
WebDAV erweitert außerdem die Status-Codes von HTTP/1.1. Einige Methoden können
gleichzeitig mehrere Ressourcen bearbeiten. Der Multi-Status-Antwort wird eingeführt, um
Status-Informationen über mehrere Ressourcen zurückzugeben.
Darüber hinaus muss WebDAV wegen der HTTP-Integration nicht auf Fähigkeiten
verzichten, wie z.B. die verschlüsselte Kommunikation mit SSL, die auf Zertifikate
basierende Authentifikation, „HTTP basic“-Authentifikation usw.
HEADERS
In diesem Abschnitt werden einige Headers vorgestellt, die von den Methoden verwendet
werden. Der Destination-Header bestimmt die URI, die eine Zielressource für Methoden wie
COPY und MOVE identifiziert, die zwei URIs als Paramter erwarten.
Der Depth-Header wird mit Methoden verwendet, die auf potentiell geschachtelten
Ressourcen zugreifen. Der Header legt fest, ob die Methode nur auf die Ressource ausgeführt
wird („Depth:0“), auf die Ressource und seine unmittelbaren Kinder („Depth:1“), oder auf die
Ressource und alle seine Nachfahren („Depth:infinity“). Der Header wird nur dann
unterstützt, wenn die Definition der Methode es ausdrücklich angibt.
Der Overwrite-Header legt für einige Methoden fest, ob die Zielressourcen überschrieben
werden müssen. Wenn er den Wert „T“ enthält, wird vor dem Kopieren eine DELETEOperation mit einem Wert von „infinity“ des Depth-Headers auf die Zielressource ausgeführt.
Mit dem Wert „F“ des Headers wird die Operation fehlschlagen.
Das WebDAV-Protokoll definiert u.a. folgende neue HTTP-Methoden:
COPY
Die Methode erstellt ein Duplikat der Quellressource, identifiziert durch die Anfrage-URI, in
der Zielressource, identifiziert durch den Destination-Header. Bei Collections wird das
Duplikat abhängig vom Depth-Header erstellt. Mit einem Wert von „infinity“ werden die
Nachfolger-Ressourcen rekursiv und relativ zum Zielpfad angelegt. Wenn die Zielressource
33
existiert, wird sie abhängig vom Overwrite-Header überschrieben oder die Operation
unterbrochen. Im folgenden Beispiel wird die Datei datei.jpg des Benutzer user2 mit der vom
Benutzer user1 überschrieben, was vom Statuscode (204) hervorgeht.
>>Anfrage
COPY /webordner/user1/datei.jpg HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/webordner/user2/datei.jpg
Overwrite: F
>>Antwort
HTTP/1.1 204 No Content
Der Statuscode 201 (Created) bezeichnet ein erfolgreicher Kopierungsvorgang ohne
Vorkommnisse, wie z.B. das Überschreiben der Zielressource. Es können außerdem im
HTTP-Rumpf mit XML Einschränkungen angegeben werden, die den Prozess des Kopierens
von Properties vom Quell- nach Zielressource steuern.
MOVE
Ressourcen werden von einem URI zu einem anderen verschoben. Die MOVE Anfrage
kopiert die Ressourcen analog zu der COPY-Methode, indem sie aber auf die
Konsistenzhaltung
achtet
und
anschließend
die
Delete-Methode
ausführt.
Die
Konsistenzhaltung besteht in der Aktualisierung der URI, z.B. beim Kopieren von mehreren
Ressourcen.
MKCOL
Mit der Methode eine neue Collection (Verzeichnis) an der durch den Ziel-URI definierte
Stelle erstellt. Wenn bereits eine Ressource an dieser Stelle existiert, wird ein FehlerStatuscode (405- Method Not Allowed) zurückgegeben. Um ein Verzeichnis im /webordner
zu erstellen, können die Anfrage und Antwort folgendermaßen aussehen:
>>Anfrage
MKCOL /webordner/files/ HTTP/1.1
Host: www.example.org
>>Antwort
HTTP/1.1 201 Created
Weitere Fehler-Statuscodes weisen auf Problemfälle wie fehlender Speicherplatz, oder nicht
ausreichende Rechte hin.
34
PROPFIND
Wie bereits erwähnt, können WebDAV-Ressourcen über Metadateninformationen verfügen.
Die PROPFIND-Methode ermöglicht es die Metainformation für eine durch den Anfrage-URI
festgelegte Ressource abzufragen. Wenn die Ressource ein Verzeichnis ist, enthält sie auch
die URI der Unterressourcen. Alle Werte des Depth-Headers sind erlaubt. Wenn der Header
nicht angegeben ist, ist das Verhalten der Methode wie beim „Depth: infinity“. Mit einem
propfind-Xml-Element kann eine Beschreibung der angeforderten Informationen zugeschickt
werden. Die Angabe eines Rumpfes der HTTP-Anfrage ist nicht obligatorisch.
LOCK und UNLOCK
Das Sperren verhindert die gleichzeitige Bearbeitung eines Dokuments von mehreren
Personen, indem eine Eigenschaft der Ressource (Dokument) gesetzt wird. Auf diese Weise
wird das „lost update“-Problem gelöst, bei dem die Änderungen einer Person an einem
Dokument, von einer anderen Person nicht beachtet und überschrieben werden.
DELETE
Mit dieser Methode wird die Ressource, bestimmt durch den Anfrage-URI, gelöscht. Wenn
der URI auf ein Verzeichnis verweist, kann für den Depth-Header nur den Standardwert
„infinity“ angegeben werden, um den Löschvorgang rekursiv auf alle Unterressourcen
auszuführen. Wenn die Ressource kein Verzeichnis ist, wird der Ressource-URI von allen
Kollektionen gelöscht, die ihn als Unterressource referenzieren.
DELETE /webordner/ HTTP/1.1
Host: www.example.com
>>Response
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.example.com/webordner/resource</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
</d:response>
</d:multistatus>
Eine Unterressource des Verzeichnisses webordner im obigen Beispiel wurde für die
Bearbeitung von anderen Benutzern gesperrt, also ist die Operation fehlgeschlagen und der
Status mit genaueren Informationen als Xml im HTTP-Rumpf zurückgegeben.
35
Beispielsweise werden im Kapitel 4.1 einige Methoden im Zusammenhang mit der
entsprechenden Unternehmensanwendung vorgestellt.
3.3
Objektmodelle
Ein Objektmodel stellt eine Hierarchie von Objekten dar, die sowohl eine semantische Sicht
auf das bestehende Datenmodell einer Domäne darstellt, als auch die allgemeine
Modellierung des Verhaltens beschreibt. Es besteht aus Objekten und Beziehungen zwischen
ihnen. Ein Objektmodell beschreibt aus einem Objekt als Einstiegspunkt, die Positionen der
verbundenen Objekte.
3.3.1
Collaboration Data Objects
CDO für Windows 2000 (CDO 2.0) ist das Objektmodell, das Datenobjekte für die
Zusammenarbeit auf Dokumente bereitstellt und die Standard-API unter Windows 2000 zur
Entwicklung
webbasierten
Messaging-Anwendungen
darstellt.
Als
Systemkomponente(CDOSYS.DLL) ist das Objektmodell (s. Abbildung 6) mit den Microsoft
Windows 2000/2003 Server-Installationen verfügbar.
Abbildung 6: Collaboration Data Objects[CDOSDK]
36
Ein Message-Objekt enthält die Informationen einer Nachricht, die in einem Ordner
gespeichert ist. Das Konfigurations-Objekt dient zum festlegen von Konfigurationsparameter
wie Mailserver, Benutzername und Passwort etc. Mit den anderen dem Message-Objekt
untergeordneten Objekten werden nachrichtenbezogene Attribute festgelegt, wie z.B.
Absender, Empfänger, Inhalt etc.
In einem Messaging-System (s. Kapitel 4.3) werden alle Arten von Einträgen, wie z.B.
Kontakte, Termine u.s.w. als Nachricht bezeichnet, da diese genauso wie eine Email abgelegt
sind. CDO 3.0 erweitert das Objektmodel von CDO 2.0 (CalendarMessage, Appointment,
Person etc.), um die Inhalte eines Informationsspeichers besser widerspiegeln zu können. Die
CDO 3.0 (CDOEX)-Komponente wird mit dem Exchange Server installiert. Sie verwendet
ADO zur Bindung an Objekte. Mit CDOEX können im Exchange Store Items verwaltet
werden, neue Nachrichten erstellt, gelöscht oder geändert werden, alle mögliche Nachrichten
für den Kalender oder die Termine (inklusive Terminanfragen) erstellt werden. Weiterhin
können Kontaktinformationen in Active Directory oder in öffentlichen Verzeichnissen
verwaltet werden.
Eine weitere Erweiterung von CDO bildet die CDO for Exchange Management-Komponente.
Die Komponente setzt auf ADSI auf und vereinfacht durch ihr Objektmodel die Verwaltung
des Exchange Servers. Unter anderem sind administrative Aufgaben wie das Anlegen und
Verwalten sowohl von Postfächern und Empfängern, als auch der Hierarchien von
öffentlichen Ordnern. Die Komponente CDO Workflow Objects for Microsoft Exchange
(CDOWF) wird zur Entwicklung und Verwaltung von Arbeitsprozessen verwendet.
3.3.2
ActiveX Data Objects und ADO.NET
Die Programmierschnittstellen von ODBC und OLE DB sind kompliziert und systemnahe.
Mit ActiveX Data Objects (ADO) ist der Wunsch nach einer einfachen, objektorientierten, auf
Basis der komplexen OLE DB-Schnittstelle Programmierschnittstelle erfüllt. Als eine
automationsfähige
(s.
Kapitel
3.2.1)
COM-Komponente
ist
ADO
programmiersprachenunabhängig. Die COM-Schnittstellen von OLE DB dagegen sind nicht
automationsfähig und können nur von C++ aus komplett genutzt werden [SCHW01].
Als Nachteil von ADO wird die eingeschränkte Flexibilität und Funktionalität vom ADORecordSet gesehen [SCHW03]. Dabei stellt der RecordSet eine Ergebnis-Tabelle dar, die
zwar den OLE DB-Rowset als vielfältigere und skriptfähige Objekte abstrahiert, aber nur
sequentielle Navigation ermöglicht. Außerdem muss eine Verbindung mit der Datenquelle
37
während der gesamten Zeit, in der mit den Daten gearbeitet wird, bestehen. Da aber OLE DB
als Interaktionsmodel nicht auf eine dauerhafte Verbindung mit der Datenquelle setzt [s.
Kapitel 3.2.2], wird ADO über einen OLE DB-Dienst erweitert.
ADO.NET
Wie bei ADO dient ADO.NET zum Trennen des Datenzugriffs von der Datenbearbeitung.
Weiterhin beseitigt ADO.NET als Nachfolger von ADO die im vorherigen Abschnitt
beschriebenen Nachteile. Die neue Datenbanktechnologie ist mit seinen Namespaces und
Klassen Bestandteil von .NET Framework und löst ADO und OLE DB ab. Sie bietet ein
Zugriffsmodell, das zusammen mit dem Xml-Namespace die einheitliche Arbeit mit Daten
aus unterschiedlichen Datenquellen definiert und dabei die Interaktionsmodelle von OLE DB
und ADO beibehält. Das bedeutet, dass mit den Daten entweder offline, anhand
eines
Objektgeflechts im Speicher, gearbeitet oder eine Verbindung während der gesamten
Arbeitszeit mit den Daten aufrechterhalten werden kann.
Das ADO.NET Objektmodell besteht aus Klassen, unterteilt in den System.Data-Namespace
und Unternamespaces. Zum Zweck dieser Arbeit dienen die Namensräume System.Data und
System.Data.OleDb.
ADO.NET besteht aus zwei wesentlichen Komponenten (s. Abbildung 7) - .NET FrameworkDatenprovider und das DataSet. Mit dem .Net Framework werden zwei verwaltete Provider
geliefert. Der erste ist der SQL Provider. Verborgen hinter Klassen wie SQLDataReader,
SQLDataSetCommand und SQLCommand im System.Data.Sql-Namespace bietet er einen
hoch optimierten Datenaustausch mit Sql Server 7.0 (oder höher). Beim verwalteten OLE
DB-Provider handelt es sich um .Net-Klassen, die über die COM-Interoperabilitätsbrücke die
zugrunde liegenden OLE DB-Provider (COM-Objekte) integrieren. Für Microsoft SQL
Server ist der verwaltete OLE DB-Provider auf die Dienste (s. Kapitel 3.2.2) des OLE DBProviders SQLOLEDB angewiesen.
Die zwei grundlegenden Ansätze für Datenzugriff definieren in diesem Objektmodell die
Klassen DataReader und DataSet. Der DataReader basiert auf einem Hochleistungsstream,
verzichtet dabei auf eine große Anzahl von Objekten im Speicher und setzt eine explizite
Trennung der Verbindung voraus; dagegen stellen die DataSets eine relationale Abbildung
der Daten im Speicher dar, in dem einer relationale Navigation möglich ist und wegen des
offline-Arbeitsprinzips für das Internet besser geeignet ist.
38
Abbildung 7: ADO.NET
Das DataSet ist so entworfen, von den Datenquellen unabhängig zu sein. Es enthält eine
Auflistung von Datentabellen, die ihrerseits aus Datenspalten, -zeilen, Primärschlüssel,
Fremdschlüssel
und
Einschränkungen
besteht.
Das
DataSet
legt
außerdem
die
Beziehungsinformationen für die enthaltenen Tabellen mit einem DataRelationCollectionObjekt fest [MSDN07]. Es benötigt ein DataAdapter-Objekt, um die Verbindung zur
Datenquelle, ausgenommen Xml-Dateien oder -Objekten, herzustellen. Der DataAdapter ist
seinerseits auf dem DataReader zum Ausfüllen des DataSets angewiesen. Die Daten werden
dabei standardmäßig per XML an das DataSet übertragen.
Die
restlichen
in
der
Abbildung
angegebenen
Elemente,
nämlich
das
Verbindung(Connection)- und das Befehl(Command)-Objekt, ermöglichen entsprechend die
Verbindung mit der Datenquelle und den Zugriff auf Datenbankbefehle oder Ausführung von
gespeicherten Prozeduren. Das Verbindungsobjekt wird für den verwalteten OLE DBProvider von der Klasse OleDbConnection instanziiert. Bei der Initialisierung wird eine
Verbindungszeichenfolge benötigt, die den Namen der Datenquelle und weitere für das
Herstellen der Anfangsverbindung erforderlichen Parameter enthält. Für den verwalteten OLE
DB-Provider kann die Verbindungszeichenfolge wie folgt aussehen:
Provider=SQLOLEDB;Data Source=localhost;Initial Catalog=Northwind;
Integrated Security=SSPI;
39
Um Schemainformationen aus einer Datenquelle zu erhalten, steht die Methode
OleDbConnection.GetOleDbSchemaTable zur Verfügung. Die allgemeine Funktionsweise ist
ähnlich wie bei OLE DB (Kapitel 3.2.2). Die Schemainformationen werden als eine
System.Data.DataTable-Ergebnistabelle zurückgegeben. Als Parameter der Methode werden
ein
OleDbSchemaGuid-Feld
und
die
gewünschten
Einschränkungen
übergeben.
OLEDbSchemaGuid ist eine Klasse, die aus öffentlichen Feldern vom Typ System.Guid
besteht. Der Einschränkungsparameter ist ein Objekt-Array. Er filtert die in der DataTable
zurückgegebenen Zeilen, beispielsweise durch Angabe von Tabellenname, Typ usw. Tabelle
2 gibt die möglichen Einschränkungsparameter für den OleDbSchemaGuid.TablesIdentifikator an. Diese Parameter entsprechen den Spalten der zurückgegebenen
Ergebnistabelle-DataTable mit den Schemainformationen.
schemaTable = cn.GetOleDbSchemaTable(OleDbSchemaGuid.Primary_Keys,
new Object[] {"Northwind", "dbo", "Employees"});
Im Einschränkungsparameter bedeuten die NULL-Werte im Array, dass es kein Filter
eingesetzt wird[309681].
Spaltenname
CLR-Datentyp
Beschreibung
TABLE_CATALOG
String
Katalogname, enthält einen NULL-Wert, wenn der
Provider Kataloge nicht unterstützt.
TABLE_SCHEMA
String
Schemaname, enthält einen NULL-Wert, wenn der
Provider Schemas nicht unterstützt.
TABLE_NAME
String
Tabellenname, die zurückgegebene Spalte darf keinen
NULL-Wert enthalten.
TABLE_TYPE
String
Tabellentyp, wie z.B. "TABLE", "SYSTEM TABLE",
"VIEW", oder "SYSTEM VIEW".
Tabelle 2: Einschränkungen (Spaltennamen der Ergebnistabelle-DataTable) für den
OleDbSchemaGuid.Tables Identifikator.
Für den GUID-Identifikator Columns ist der Wert der Spalte „Spaltenamen“ der letzten Zeile
mit
COLUMN_NAME
auszutauschen.
Für
die
Identifikatoren
OleDbSchemaGuid.Primary_Keys und OleDbSchemaGuid.Foreign_Keys fehlt bei den
Einschränkungen die letzte Zeile der Tabelle 2.
40
4
Microsoft-Unternehmensanwendungen in Hinblick auf DatenSchema und Porgrammierschnittstellen
Die Unternehmensanwendungen, die in dieser Arbeit in Betracht gezogen wurden, sind
Microsoft Sql Server, Exchange Server und Active Directory. Sie werden im Folgenden in
Bezug auf Programmierschnittstellen und Metadaten-Beschreibung untersucht, die ihrerseits
so ausgewählt werden müssen, um der nichtfunktionalen Anforderung gerecht zu werden,
.NET Framework als Programmierplattform für die Entwicklung zu benutzen.
4.1
Active Directory
Active Directory (AD) stellt die Verzeichnisdienste dar, mit denen das Netzwerk von einem
Ort aus verwaltet wird. Benutzer und Ressourcen können auf einfache Weise hinzugefügt,
entfernt und verschoben werden. AD trennt die logische Struktur der Domänenhierarchie von
der physischen Struktur des Netzwerks. Dadurch lassen sich
Änderungen an der
physikalischen Struktur für den Benutzer transparent durchführen. AD ist außerdem die
größte Änderung in Microsoft Exchange 2000/2003 Server, weil es den ExchangeVerzeichnisdienst ersetzt.
Acive Directory ist eine Datenbank, die ein spezielles Ziel erfüllt und kein Ersatz für die
Windows Registry darstellt. Das Verzeichnis ist entworfen, um große Mengen an Lese- und
Schreiboperationen und wesentlich kleinere Anzahl von Änderungen durchzuführen. ADDaten sind hierarchisch, repliziert und erweiterbar. Weil sie repliziert werden, sind sie nicht
dazu konzipiert, dynamische Daten zu speichern, wie z.B. Prozessorauslastung. Wenn die
Daten spezifisch für den Host sind, sind sie in die Registry zu speichern. Typische Beispiele
für
im
Verzeichnis
gespeicherte
Daten
sind
diese
der
Druckerwarteschlange,
Benutzerkontakten und Netzwerk/Computer-Konfiguration. AD-Datenbank besteht aus
Objekten und Attributen. Objekt- und Attributdefinitionen sind im AD-Schema gespeichert
[MSDN12].
Mit Active Directory ändert sich der gesamte NT-Namensraum, indem das flache
Domänenkonzept durch einen hierarchisch gegliederten Domänenbaum ersetzt wird. Die NTHierarchie besteht aus Containern und Directory-Leaf-Objekte, wie z.B. der Container
Namespaces, der den WinNT-Namensraum enthält, der seinerseits aus Domänen besteht. Die
Domänen können sowohl Leaf-Objekte, wie Benutzer und Gruppen, als auch Container wie
41
Schema und Computer enthalten. Der ADsPath (s. Kapitel 3.2.4) kann folgende Formen
annehmen:
WinNT:
WinNT://<domain name>
WinNT://<domain name>/<server>
WinNT://<domain name>/<path>
WinNT://<domain name>/<object name>
……
WinNT://<server>/<object name>,<object class>
Der Domänename kann entweder NETBIOS- oder DNS-Name sein [MSDN14]. Der server
bezeichnet einen Server innerhalb des Domains. Mit path wird der Pfad eines Objekts
gekennzeichnet wie z.B. „server/printer“. Mit object class wird zu dem Objektnamen auch
den Objekttyp angegeben, damit die Leistung des Servers gesteigert wird.
Bei Active Directory (NT-5.0) dagegen besteht der Namensraum aus Domänen, die in einem
Baum gegliedert sind. Jede Domäne selbst stellt einen Baum dar, indem alle Objekte der
Domäne (Benutzer, Computer, Printer usw.) als Einträge in einem Verzeichnis betrachtet
werden. Es wird außerdem zwischen einer Domänenstruktur (Tree) und der Gesamtstruktur
(Forest) unterschieden. In einer Domänenstruktur haben alle Domänen einen fortlaufenden
DNS-Namensraum. Die Domäne erster.example.com und zweiter.example.com sind der
Domäne example.com untergeordnet und alle drei bilden eine Domänenstruktur. Die
Gesamtstruktur kann eine oder mehrere unabhängigen Domänenstrukturen beinhalten.
Innerhalb der Domäne einer Gesamtstruktur werden dasselbe Active Directory-Schema und
dieselben Replikationsinformationen10 verwendet. Ein globaler Katalog ist für die Suche von
Objekten im Verzeichnis zuständig. Er ist an einer zentralen Stelle in der Gesamtstruktur
installiert und hat wegen der Replikation alle benötigten Informationen, um die gesuchten
Objekte zu finden.
Neben den Domänen sind auch die Organisationseinheiten (OU) für die logische Gruppierung
von Netzwerkressourcen zuständig. Die OU kann Mitglieder der Domäne beinhalten. In einer
OU werden Objekte in Gruppen eingeteilt. Sie kann außerdem weitere OUs als Objekte
beinhalten. Die Angabe einer OU kann als eine weitere Einschränkung die Suche nach
Objekten in Active Directory beschleunigen.
10
Die Domänenverwalter, so genannten Domänencontroller (DC), in einer Domäne tauschen
Verzeichnisinformationen unter sich aus, damit die Änderungen an einem DC schnellstmöglich den anderen DC
verfügbar gemacht werden. Die Replikationsinformationen steuern diesen Prozess.
42
4.1.1
Programmierschnittstellen
Die Programmierschnittstelle für Active Directory ist entweder die ADSI-Komponente oder
die
darauf
basierende
verwaltete
.NET-Komponente,
implementiert
im
System.DirectoryServices Namensraum. Beide sind im Kapitel 3.2.4 beschrieben.
Der ADsPath benötigt beim LDAP-Provider folgendes Format:
LDAP://HostName[:PortNumber][/DistinguishedName]
Die in eckigen Klammern angegebenen Elemente sind optional. Wenn der Port nicht
angegeben ist, wird der Standard-LDAP-Port 389 verwendet. Der HostName kann ähnlich
wie bei dem WinNT-Provider einen Domänennamen, einen Computernamen oder eine IPAdresse sein. DistinguischedName (DN) identifiziert eindeutig ein Objekt im Active
Directory (s. Kapitel 3.2.3). Wenn der Hostname nicht bekannt ist, kann das von dem
entsprechenden Domaincontroller mit Hilfe des so genannten Locator Service abgefragt
werden. In LDAP 3.0 ist rootDSE der obersten Knoten im DIT (s. Kapitel LDAP). Sein Ziel
ist Informationen über das Verzeichnisdienst zur Verfügung zu stellen. Es ist also möglich
sich an eine „default“ Domäne zu binden, ohne den Namen des Domaincontrollers zu
spezifizieren. Der Wert des ADsPath ist in diesem Fall LDAP://rootDSE. Active Directory
teilt
sich
darunter
in
drei
Partitionen:
der
DefaultNamingContext,
ConfigurationNameingContext und SchemaNamingContext. Das rootDSE-Objekt enthält als
Eigenschaften (Properties) sowohl die DNs für die drei Partitionen, als auch andere
Konfigurationseigenschaften von Active Directory, u.a. die DNS-Addresse des Servers –
dnsHostName. Wenn der DN fehlt, wird der DefaultNamingContext in der aktuellen Domäne
angesprochen.
Mit DirectoryServices können die angebundenen Objekte gelöscht oder ihre Eigenschaften
geändert werden. Wenn sie Container repräsentieren, enthalten sie durch die Eigenschaft
Children einen Verweis auf alle Kinderknoten. Über diese Eigenschaft können neue Kinder
mit Hilfe der Add-Methode hinzugefügt werden oder mit der Find-Methode wird nach einem
untergeordneten Objekt gesucht. Die LDAP-Attribute sind in der Eigenschaft Properties
gespeichert.
Die DirectoryEntry-Komponente bietet die Möglichkeit, Objekte aus der Hierarchie zu
entfernen. Um einen untergeordneten Eintrag aus einer untergeordneten Auflistung des
aktuellen übergeordneten Verzeichnisses zu entfernen, kann die Remove-Methode aufgerufen
werden. Die Remove-Methode enthält als einziges Argument den zu entfernenden
43
Eintragsnamen und darf nur für einen leeren Container oder ein Objekt verwendet werden,
das z.B. als Container einen Drucker oder Computerknoten enthält.
entry.Children.Remove(entryZuEntfernen)
Um einen Eintrag und alle untergeordneten Einträge zu löschen, kann die DeleteTreeMethode aufgerufen werden. Durch die DeleteTree-Methode werden der aktuelle Eintrag und
alle in der Teilstruktur enthaltenen Einträge aus der Hierarchie gelöscht.
entry.DeleteTree()
Um anschließend die Änderungen im Active Directory zu speichern, muss die
CommitChanges-Methode aufgerufen werden.
Bei der Suche können Filter am Ende des ADsPath gefolgt von einem Semikolon angegeben
werden. Die Filter werden in Postfix-Notation definiert, dabei stehen die Operationen am
Anfang, vor den Termen:
LDAP://host/dc=example,dc=com;(&(objectclass=user)(name=r*))
Mit dem obigen Beispiel wird im Unterverzeichnis des angebundenen Knotens nach allen
Benutzern gesucht, deren Namen mit „r“ anfangen. Weiterhin kann einen Scope für die Suche
definiert werden: BASE, ONELEVEL und SUBTREE, die entsprechend den Eintrag selbst,
die unmittelbar untergeordneten Einträge und alle darunter liegenden Einträge durchsucht.
Ein komplexeres Beispiel für ein Filter ist bei der Suche aller Benutzer, die sich nie
angemeldet
haben,
mit
dem
folgenden
Zeischenfolge
angegeben:
(&(objectCategory=person)(objectClass=user))(|(lastLogon=0)(!(lastLogon=*)))
Wenn ein Objekt mit der Klasse User beschrieben wird und gleichzeitig sich in der Kategorie
der person befindet, dann aber auch sein Attribut lastLogon 0 oder gar keinen Wert hat wird
das Objekt in die Ergebnismenge hinzugefügt.
4.1.2
Metadatenbeschreibung
AD hat drei Partitionen. Diese, auch „naming-contexts“ genannt, sind die Domäne-, die
Schema- und die Konfigurationspartition. Die Domänepartition enthält Benutzer, Gruppen,
Kontakte, Computer, Organisationseinheiten (OU) und viele andere Objekttypen. Die
Konfigurationspartition erfasst die Konfigurationsdaten für Dienste und Partitionen. Die
Schemapartition enthält die Klassen- und Attributdefinitionen. AD ist erweiterbar und bietet
die Möglichkeit, benutzerdefinierte Klassen und Attributdefinitionen hinzuzufügen. Die
44
Attributdefinitionen und Klassen sind wiederum Objekte in der SchemaNamingContextPartition. Die Attributdefinitionen sind Objekte vom Typ attributeSchema und die Klassen
vom Typ classSchema. Also enthält eine Attributdefinition auch Attribute, die
zusammengenommen die eigentliche Definition des Attributs darstellen. Die Attribute
attributeSyntax, oMSyntax und oMObjectClass definieren zusammen den Datentyp (Syntax)
der Instanzen dieser Attributdefinition. Mehrere Attribute werden benötigt, weil mehrere
Standarten involviert sind. Das attributeSyntax-Attribut repräsentiert die X.500 Syntax (OIDSyntaxwerten) und das oMSyntax die XOM-Syntax (XOM steht für XAPIA X/Open Object
Management). Weil AD Syntaxen benötigt hat, die der X.500-Standard nicht definiert,
enthalten einige Datentypen für attributeSyntax die gleichen Werte. Um sie unterscheiden zu
können, wird noch der XOM-Syntax gebraucht. Active Directory unterstützt 23 Syntaxen
[MSDN15]. Sie sind im AD integriert und durch keine Objekte im Schema repräsentiert. Also
ist es nicht möglich neue Syntaxen hinzuzufügen. Für die einfachen Datentypen stehen
insgesamt vier Syntaxen zur Verfügung (die ersten drei Reihen in Tabelle 3). Der Datentyp
mit attributeSyntax 2.5.5.9 und oMSyntax 10 stellt beispielsweise eine 32-bit Zahl dar.
Weitere zehn Syntaxen definieren das Format von Zeichenfolgen. Zwei beschreiben
Zeitdatentypen, die wiederum Zeichenfolgen sind. Sieben Verweisdatentypen stellen
verschiedene Objektreferenzen dar [KOSE01].
Attribute-Syntax
oMSyntax
oMObjectClass
DotNet-Typ
2.5.5.8
1
Boolean
2.5.5.9
10
Int32
2.5.5.16
65
Int64
2.5.5.1
127
2B0C0287731C00854A System.__ComObject (DN)
Tabelle 3: Zuordnung von Syntaxen in Active Directory und .NET-Datentypen
Für die Objektreferenzen enthält der oMSyntax immer den Wert 127.
Außerdem definiert AD ein Mapping zwischen seine Datentypen und diese von LDAP
[MSDN18], um Objekte über LDAP offenlegen zu können. Die LDAP-Datentypen sind
eindeutig durch ihren Objektidentifikator (OID) definiert. Jede Attributdefinition in AD
enthält auch ein obligatorisches Attribut attributeID mit einem OID-Wert.
45
Einige Attribute können mehrere Werte enthalten. Das wird mit dem Attribut isSingleValued
in der Attributdefinition festgelegt. Ein Attribut wird durch die Attribute lDAPDisplayName,
cn (Common- Name) und distinguishedName in der Definition eindeutig bestimmt, wobei die
erste zwei für die Definition obligatorisch sind. Der LDAP-Display-Name wird von LDAPClienten für das Lesen und Schreiben in einem Attribut. Sein Wert kann aus dem CommonName durch Streichen der Bindestriche und durch das Kleinschreiben der erste Buchstabe
erzeugt werden [LOWE99].
Klassen und Attributdefinitionen können Attribute entsprechend von anderen Klassen und
Attributdefinitionen erben. Diese Beziehungen werden durch das Attribut subClassOf
angegeben. Ganz oben in der Hierarchie steht die Klasse top. Beispielsweise erbt die
attributeSchema-Klasse 73 Attribute von der top-Klasse.
4.2
Microsoft Sql Server
Microsoft Sql Server 2000 ist die SQL-basierte, relationale Datenbank, die in dieser Arbeit
eingesetzt wird. Darüber hinaus wird die Northwind-Beispieldatenbank verwendet, die mit
der Serverinstallation mitgeliefert wird. Sie enthält die Daten für das frei erfundene
Unternehmen Northwind Traders, das mit Spezialitäten aus aller Welt handelt.
4.2.1
Sql Server 2000 verfügt über eine integrierte XML-Unterstützung für Internetanwendungen.
Die Xml-Unterstützung wird aber in Bezug auf Version 7.0 aus Rückkompatibilitätsgründen
nicht in Betracht gezogen. Vielmehr ist im Konzept das Ziel festegelegt, über den verwalteten
OLE DB-Provider (s. Kapitel 3.2.2) eine breitere Unterstützung von Datenquellen zu
gewährleisten und sich nur für den Prototyp auf den Microsoft Sql Server(MsSQL) zu
beschränken. ADO.NET (s. Kapitel 3.3.2) ist das Objektmodel für die Entwicklung von
Datenbankanwendungen in .NET und wird in dieser Arbeit zusammen mit dem OLE DBDatenprovider als Programmierschnittstelle für den Zugriff auf Microsoft Sql Server
eingesetzt.
46
4.2.2
Der SQLOLEDB-Datenprovider repräsentiert die Daten, gespeichert in Microsoft Sql Server
2000, indem er die in [MSSQL1] angegebene Zuordnung von OLE DB-Datentypen zu
nativen Sql Server-Datentypen definiert. Die Relation ist dabei nicht bijektiv. Es können
durchaus mehrere SQLOLEDB-Datentypen einem SQL Server-Datentyp zugewiesen werden.
Es ist zu beachten, dass nur bei einer Zuweisung mit keinen Verlusten von Daten zu rechnen
ist.
Das Mapping zwischen einigen SQL Server- und SQLOLEDB-Datentypen ist in Tabelle 4
angegeben.
SQL Server Datentypen
SQLOLEDB Datentypen
.Net Datentypen
Bigint
DBTYPE_I8
Int64
Binary
DBTYPE_BYTES
Byte[ ]
…..
…..
Int
DBTYPE_I4
Int32
Tabelle 4: Zuordnung von Sql Server Datentypen zu SQLOLEDB- und .Net-Datentypen
Darüber hinaus wird mit der zweiten und dritten Spalte der Tabelle eine Zuordnung von OLE
DB zu .NET-Datentypen angegeben [MSDN08]. Um die zugewiesenen Datentypen der
Spalten
einer
Tabelle
zu
erhalten
(s.
Kapitel
3.2.2),
wird
die
OleDbConnection.GetOleDbSchemaTable-Methode zum Extrahieren von Metainformationen
verwendet.
4.3
Exchange Server
Microsoft Exchange ist ein Groupware-Server für Microsoft Windows, der u.a.
Funktionalitäten zur E-Mail-Kommunikation, zur zentralen Verwaltung und Nutzung von
Informationen oder zum Instant-Messaging bietet. Ein Groupware-Server dient u.a. dem
Austausch von Kontakten und Terminen. Neben der spezialisierten Client-Anwendung
Microsoft Outlook können auch Web-Browser und Instant-Messaging-Anwendungen zum
Zugriff verwendet werden. Die folgenden Betrachtungen beziehen sich auf die
Produktversionen Microsoft Exchange 2000 und Microsoft Exchange 2003.
Exchange besitzt in den erwähnten Versionen keinen Verzeichnisdienst mehr, sondern benutzt
das Active Directory. Bei der Installation wird das Active Directory Schema mit zahlreichen
Klassen und Attributen erweitert. Die Klassen user, contact und group bilden die Grundlage
47
für Postfächer, benutzerdefinierte Empfänger und Verteilerlisten. Als Erweiterung der Active
Directory-Benutzer-Klassen sind die Exchange-Empfänger im DefaultNamingContext
abgelegt. Ein Postfach stellt die Erweiterung der user-Klasse dar, eine Verteilerliste erweitert
die group-Klasse und ein benutzerdefinierter Empfänger ist die Erweiterung der contactKlasse. Im ConfigurationNamingContext werden die Konfigurationsinformationen von
Exchange gespeichert.
Die eigentlichen Daten werden in dem so genannten Webstore (Web Storage System)
gespeichert. Der Webstore ist eine semi-strukturierte Datenbank (s. Kapitel 2.2), in der
unterschiedliche Nachrichtentypen gespeichert werden können, wie z.B. Emails oder Dateien
beliebigen Typs. Der Webstore besteht aus Ordnern, die in öffentliche und private eingeteilt
werden. Ein privater Ordner bildet das Postfach eines Benutzers und ist ausschließlich dem
Benutzer zugeteilt. Die öffentlichen Ordner stehen in der Regel allen Benutzern zur
Verfügung und sind Teil einer öffentlichen Ordnerhierarchie. Der WebStore wird damit in
mailbox store und public store aufgeteilt. Für jeden öffentlichen Ordner gibt es außerdem
einen Eintrag im DefaultNamingContext von Active Directory unterhalb des Containers
„CN=Microsoft Exchange System Objects“.
Im Exchange Server können Ordner und auch einzelne Nachrichten über URLs angesprochen
werden. Microsoft Exchange 2000 SDK legt für die Konstruktion eines URLs die gleiche
Vorgehensweise fest, wie bei der Identifizierung einer über HTTP zugreifbaren Ressource.
Die URL hat folgende Struktur:
http://servername/virtual-directory/virtual-path
Servername ist der Name des Webservers, der in die IP-Adresse des Hosts aufgelöst wird.
Virtual-directory ist das virtuelle Verzeichnis von Microsoft Exchange HTTP Virtual Server,
das auf dem öffentlichen Verzeichnis abgebildet ist. Virtual-path ist der virtuelle Weg zum
Item. Die URLs in der Tabelle im Anhang 2 sind typische HTTP:URLs für ein MailboxVerzeichnis eines Benutzers bei einer englischen Installationsversion des Exchange Servers.
Die konkrete URLs können ermittelt werden, indem die Eigenschaften, wie inbox-Feld oder
calendar-Feld, von dem Mailbox-Grundverzeichnis abgefragt werden.
4.3.1
Die Programmierschnittstellen, die für den Zugriff auf dem Exchange Webstore verwendet
werden können, erfüllen bestimmte Zwecke und bringen auch Nachteile mit sich, so dass sie
48
sich gegenseitig nicht ausschließen können. Exchange Server bietet u.a. in den folgenden
Punkten ausgeführten Programmierschnittstellen.
4.3.1.1
ADO/CDO und OLEDB
Für ADO (ADO.NET) und CDO gibt es zwei OLEDB-Provider, die den Zugriff auf dem
WebStore ermöglichen: der Microsoft Internet Publishing-Provider (MSDAIP) und der
ExOLEDB-Provider (s. Abb. 8). Der MSDAIP-Provider greift über im IIS konfigurierte
virtuelle Verzeichnisse via HTTP und WebDAV auf dem Exchange Server zu. Bei der
Version 2003 kann er nicht zusammen an einem Computer mit Exchange Server installiert
werden.
Der ExOLEDB-Provider verwendet direkt das Exchange Server-API und darf nur auf dem
Server selbst verwendet werden. Die Clientanwendungen müssen auf dem gleichen Computer
laufen. Er unterstützt außerdem keine Impersonifizierung, bei der der Prozess mit den
Rechten des aufrufenden Benutzers laufen kann.
Abbildung 8: Datenzugriffs-Architektur für Exchange Server 2003 [ESDK01]
Mit der Version 3.0 von CDO (CDOEX) wird nicht via MAPI11 auf dem Exchange Server
zugegriffen,
sondern
werden
die
ADSI-Komponente
für
den
Zugriff
auf
den
Verzeichnisdienst und ADO/OLEDB für den Zugriff auf den Webstore verwendet. Wie im
Kapitel 3.3.1 erwähnt besteht der Nachteil bei der CDOEX-Komponente, genauso wie bei
ADO und dem ExOLEDB-Provider, das sie nur zusammen mit Exchange Server auf dem
gleichen Computer laufen können. Nur mit CDOEXM kann entfernt zugegriffen werden, um
11
MAPI umfasst ein Protokoll zur Kommunikation zwischen Messaging-Client und Server. Ähnlich wie bei
OLEDB basiert MAPI auf dem Provider-Konzept.
49
Verwaltungsaufgaben im Exchange Server über das Active Directory lösen zu können. Das ist
möglich, weil CDOEXM für Verwaltungszwecke auf ADSI und den LDAP-Provider aufsetzt.
Beispielsweise ist sowohl mit ADSI, als auch mit CDOEXM möglich, ein Postfach
anzulegen.
4.3.1.2
WebDAV
Es wird auch die Möglichkeit geboten, Exchange Store über WebDAV anzusprechen (s. Abb.
9). Wie in Kapitel 3.2.5 bereits erwähnt, werden die Informationen in den WebDAVAnfragen und Antworten in Form von Xml-Dokumenten übermittelt.
Abbildung 9: Zugriff auf dem Exchange Store über WebDAV [ESDK02]
Im Folgenden wird anhand eines Beispiels den Ablauf eines Zugriffs über WebDAV erläutert.
Das Erstellen eines Verzeichnisses mit WebDAV kann in folgenden Schritten
zusammengefasst werden:
1. Einen MKCOL-Methodenaufruf erstellen. Der URI für die Methode ist der URI zur
Kollektion, die erstellt werden muss.
2. Optional können Eigenschaften von dem neuen Verzeichnis gesetzt werden, indem ein
XML Body im Aufruf mitgeschickt wird. Diese Eigenschaften können entweder in diesem
MKCOL-Methodenaufruf gesetzt werden, oder durch einen separaten PROPPATCHMethodenaufruf, wenn das Verzeichnis bereits angelegt ist. Das XML-Format ist wie ein
üblicher PROPPATCH-Methodenaufruf:
<d:propertyupdate xmlns:d="DAV:">
<d:set>
<d:prop>
<d:displayname>Folder 1</d:displayname>
</d:prop>
</d:set>
</d:propertyupdate>
50
Beim Zuschicken eines XML-Bodys mit der MKCOL-Methodenaufruf muss der ContentType-Header auf „text/xml“ und Content-Length-Header auf den entsprechenden Wert
gesetzt werden.
3. Nachricht senden.
4. Wenn die Aktion erfolgreich war, ist der Antwortstatus „201 Created“.
Im Folgenden ist ein typischer MKCOL-Methodenaufruf angegeben, bei dem mit der
Erzeugung des Ordners zusätzlich zwei Eigenschaften gesetzt werden [MicExc2]. Der zu
erstellenden Ordner hat den Namen testname und wird im öffentlichen Verzeichnis
/pub/folder1/folder2 auf dem Host „hostname“ angelegt.
MKCOL /pub/folder1/folder2/ HTTP/1.1
Host: hostname
Content-Type: text/xml
Content-Length: XXX
<?xml version="1.0"?>
<g:propertyupdate xmlns:g="DAV:" >
<g:set>
<g:prop>
<g:displayname>testname</g:displayname>
</g:prop>
<g:prop>
<f:myprop xmlns:f="urn:schemas-mydomain-tld:">Test</f:myprop>
</g:prop>
</g:set>
</g:propertyupdate>
Die Namensräume in diesem Beispiel werden im nächsten Abschnitt besprochen werden.
4.3.2
Das Exchange Store-Schema besteht aus Eigenschaften, die alle Ressourcen im Store,
einschließlich Email-Nachrichten, Termine, Verzeichnisse und Kontakte, definieren. Der
Exchange Store enthält zahlreiche vordefinierte Eigenschaften. Das Schema kann aber auch
mit benutzerdefinierten Eigenschaften erweitert werden. Jede Eigenschaft wird über einen
hierarchischen, global eindeutigen Identifikator (URI) und den Eigenschaftsnamen definiert.
Der URI ist entweder in der Form eines URLs oder eines Uniform Resource Names (URN).
Ein URN hat im Gegensatz zu einem URL keine Protokollangabe. Im Exchange Server
werden auf diese Weise auch Klassennamen gebildet. Die Elemente im Exchange-Webstore
sind Instanzen dieser Klassen, die auch Content Classes genannt werden [SCHW01].
51
Das Webstore-Schema umfasst Attribute aus mehreren Namensräumen, die sich in drei
Gruppen einteilen lassen. Die im WebDAV-definierte Attribute werden mit dem „DAV:“Namensraum festgelegt, wie z.B. das „DAV:displayName“-Attribut. In diesem Namensraum
sind auch Elemente für die WebDAV-Anfrage- und WebDAV-Antwort-Syntax enthalten. Es
muss also ein Unterschied gemacht werden, zwischen Elemente in diesem Namensraum, die
ausschließlich für das WebDAV-Protokoll verwendet werden und solche die als
Eigenschaften in den Einträgen im WebStore benutzt werden können. Im vorhin ausgeführten
Beispiel über WebDAV-Anfragen werden mehrere Attribute, wie propertyupdate, set, prop
und displayname aus diesem Namensraum verwendet, aber nur displayname wird auch als
Eigenschaft eines Elements im WebStore benutzt.
Die mit einem URN benannten Namensräume definieren Eigenschaften, die auf anderen
Internet-Standards basieren, wie z.B. das Attribut urn:schemas:mailheader:sender. Die letzte
Gruppe besteht aus Eigenschaften, deren Namensräume mit einem URL benannt werden. Die
Microsoft Exchange-spezifischen Eigenschaften werden entweder in dem Namensraum
http://schemas.microsoft.com/exchange oder in seinen untergeordneten Namensräumen
definiert.
Die Klassen werden im Namensraum urn:content-classes definiert. Jedes Attribut gehört zu
einer Content Class. Durch Vererbung der Content Classes kann ein Attribut zu mehreren
Klassen gehören. Die oberste Klasse ist die Content Class urn:content-classes:object.
Oft benutzte Content Classes sind
z.B. urn:content-classes:folder, urn:content-
classes:appointment, urn:content-classes:message, die entsprechend als Schablone für die
gespeicherten in Webstore Ordner, Termine und Nachrichten dienen.
Wenn der Namensraum mit den Zeichen „:“ oder „/“ endet, wird die Eigenschaft über den
URI, konkateniert mit dem Eigenschaftsnamen, refernziert. Andernfalls wird dazwischen ein
„#“-Zeichen
eingefügt,
wie
z.B.
bei
der
Eigenschaft
urn:schemas-microsoft-
com:office:office#Author.
Für das ganze WebStore wird ein globales Schema definiert, das aus den Namensräumen und
aus den darin definierten Eigenschaften- und Content Class-Definitionen besteht. In jedem
Verzeichnis
können
weitere
für
das
Verzeichnis
spezifischen
Attribut-
und
Klassendefinitionen angegeben werden, die das globale Schema erweitern. Das erste
gefundene Attribut in der Verzeichnishierarchie wird genommen und die predefinierten in den
untergeordneten Ordnern auf dem Pfad zu einem Item werden ignoriert. Das globale Schema
52
befindet sich im schema-Verzeichnis, untergeordnet von dem Installationsverzechnis des
Servers - Exchsrvr. Das Schema kann aber auch über HTTP mit dem URL
http://server/public/##SCHEMAURI##/microsoft/ExchangeV1
ausgelesen werden. Seit Version Exchange 2000 Server SP1 wird der Zugriff auf das globale
Schema über den „##SCHEMAURI##“-Macro ermöglicht. Benutzerdefiniertes globales
Schema ist über den folgenden URI erreichbar:
http://server/<vroot>/##SCHEMAURI##/
In dem schema-Ordner sind außerdem die Dateien enthalten, die die XDR-Elemente und die
Struktur eines XDR-konformen Dokuments definieren.
Für jedes Attribut oder Content Class im Schema ist eine Datei angelegt, die das Attribut oder
Content Class beschreibt. Der Inhalt der Dateien ist im Xml-Format. Für die Deklaration der
Elemente wird das Xml Schema Reduce (XDR), die von Microsoft entwickelte
Schemasprache, verwendet. Für primären Datentypen werden die Microsoft primären
Datentypen genommen, die im Namensraum urn:schemas-microsoft-com:datatypes definiert
und über das type-Feld im Schema referenzierbar sind [ESDK03].
4.4
SharePoint Portal Server
SharePoint Portal Server ermöglicht es Mitarbeitern, über ein web-basiertes Portal
Informationen freizugeben, zu veröffentlichen oder Informationen in verschiedenen Quellen
zu suchen. Ein Portal fasst an einer zentralen Stelle Informationen und Dokumenten aus
verschiedenen Quellen zusammen. SPS baut den Exchange Information Store (Webstore) mit
zusätzlichen Datenbankfunktionen und Anwendungsmethoden aus, wie z.B. Steuer für
Datenspeicherung und Versionsverwaltung. Mit dem SharePoint Store wird die Microsoft
Digital Dashboard Technologie erweitert, mit dem Ziel ohne eigenes Code zu entwickeln,
Arbeitsdomänen und kollaborativen Anwendungen erstellen zu können [WeiGan].
SharePoint Portal Server 2003 basiert auf die Windows SharePoint Services und besitzt
entsprechend alle ihren Fähigkeiten, dabei sind alle SharePoint Sites, Informationen und
Anwendungen in ein einziges Portal enthalten. SharePoint Services ist eine Kollektion von
Diensten für Microsoft Windows Server 2003, die eingesetzt werden kann, um die
Zusammenarbeit von Benutzer bei der Bearbeitung von Dokumenten zu ermöglichen, sowie
gemeinsame Listen von Kontakten, Ankündigungen und Aufgaben bereitzustellen.
53
Wie in Abbildung. 10 zu sehen ist, bildet der Workspace die höchste Ebene in der Struktur
von SPS.
Abbildung 10: SharePoint Portal Server Workspace [MicSPS2]
Microsoft legt u.a. folgende Konzepte für die Struktur von SPS fest [MicSPS1]:
•
Workspaces
Ein SharePoint Portal Server Workspace bietet durch Webfolder Zugriff auf
Dokumentenbibliotheken, Informationsquellen, Kategorien u.s.w. auf dem Server. Der
in der Abbildung abgebildeten Workspace enthält folgende Verzeichnisse: Categories,
Dashboards, Documents, Management und Portal Content.
•
Web Folders
Ein Web-Verzeichnis bietet eine Schnittstelle für die Verwaltung von Dateien auf dem
entfernten Web Server. Web-Verzeichnisse bieten Dokumentenspeicherung und
Funktionalitäten zur Veröffentlichung. Damit freier Zugang auf die Dateien
ermöglicht wird, muss der Web Server Web-Verzeichnisse unterstützen und
entsprechende Zugriffsrechte müssen den Benutzern für den Webserver vergeben
werden.
•
Categories
Eine Kategorie ist eine Dokumenteigenschaft, die programmatisch gesetzt wird und in
Hierarchien von Themen und Unterthemen definiert wird, um Dokumente in Gruppen
54
mit verwandtem Inhalt zu organisieren. Dokumente können in verschiedenen
Kategorien klassifiziert werden. Benutzer können ihre Dokumente kategorisieren,
indem sie die Kategorieeigenschaft in Dokumentenprofil hinzufügen.
•
Best Bets
Best Bet ist eine Dokumenteigenschaft, die programmatisch gesetzt wird, um den
Rank bei Suchanfragen zu manipulieren.
•
Document Profiles
Ein Dokumentprofil enthält eine Kollektion von Dokumenteigenschaften. Jedes
Dokument
im
Workspace
ist
mit
einem
Dokumentprofil
assoziiert.
Dokumenteigenschaften enthalten Kategorien, „best-bets“ und Schlagwörter. Diese
klassifizieren die Dokumenteninhalte und Attribute in einem Format. Dieses Format
ermöglicht das Hinzufügen des Dokumentes in einem Index und das Finden von
diesem nach einer Suche, wenn es veröffentlicht wird.
Alle SharePoint Portal Server Dokumente sind in hierarchischen Verzeichnissen gespeichert,
die ähnlich der Verzeichnisse im Dateisystem operieren. Darüber hinaus enthalten einige
Verzeichnisse, wie z.B. das Workspace-Schema-Verzeichnis, Items als Metadaten, wie z.B.
Property, Definition, Dokumentenprofil und Dictionaries, die für die Kategorisierung und für
die Suche von Informationsobjekten nach bestimmten Aspekten, wie z.B. Autor oder
Schlagwort, herangezogen werden.
4.4.1
Abbildung.3 veranschaulicht wie Clientanwendungen die Microsoft Server XMLHTTP
COM-Komponente und WebDAV benutzen können, um nach Elementen in SharePoint Portal
Server Store zu suchen. Die Anfrage enthält eine in XML verkapselte SharePoint Portal
Server SQL query. Damit eine Anfrage gesendet wird, muss ein Stream-Objekt oder eine
Zeichenkette erzeugt werden, die die XML-Anfragedaten enthält. Der SharePoint Portal
Server antwortet auf die Suchanfrage mit einer Nachricht in text/XML-Format, das dem
DAV:PROPFIND-Antwortformat entspricht [MicSPS]. Das XMLHTTP COM-Objekt ist Teil
von Microsoft XML (MSXML) 2.0 oder späteren COM-Komponente. Das XML body einer
erfolgreichen PROPFIND-Methode kann unmittelbar von dem XMLHTTP-Objekt als ein
DOM-Dokumentobjekt erfasst werden [MicExc1]. Die Komponente erleichtert die Erzeugung
der Anfrage und Bearbeitung der Antworten, diese können aber auch durch eine eigene auf
55
System.Web basierende und somit verwaltete Komponente geparst und in Objekten gepackt
werden.
Abbildung 11: Client-Interaktion mit SharePoint Information Store über WebDAV [MicSPS]
Im Folgenden wird beispielsweise eine Suchanfrage angegeben, die das von SharePoint
vorgeschriebene Format einhalten muss.
SEARCH /myworkspace HTTP1.1
Host: example.com
Content-Type: text/xml
Content-Language: en
Connection: Close
Range: rows=0-99
………
Content-Length: 457
<D:searchrequest xmlns:D = "DAV:" >
<D:sql>
SELECT "DAV:getcontentlength",
"urn:schemas-microsoft-com:office:office#Title",
"urn:schemas.microsoft.com:fulltextqueryinfo:rank"
FROM SCOPE ('DEEP TRAVERSAL OF "/myworkspace/documents"')
WHERE ("DAV:getcontentlength" > 10000)
RANK BY COERCION ( Absolute, 1000 )
ORDER BY "DAV:getcontentlength" DESC
</D:sql>
</D:searchrequest>
56
In dieser SQL-Anfrage werden drei Spalten angefordert: Dokumentgröße, Titel und Rank. Ein
Datensatz wird für jedes Dokument zurückgegeben, das größer als 10000 Bytes ist und sich
auf dem Server im Verzeichnis /documents oder dessen Unterverzeichnisse befindet. Die
Antworten haben alle den Rankwert 1000 und sind in absteigender Reihenfolge bezüglich der
Dokumentengröße geordnet. Weil es noch eine Einschränkung „Range“ in den Headers
vorliegt, werden nur die ersten 100 Dokumente zurückgegeben. Weil die Namensräume
Sonderzeichen
enthalten
können,
müssen
sie
werden
hier
bei
einer
WebDAV-Anfrage
in
Anführungszeichen gesetzt werden.
Zum
Zweck
der
Vollständigkeit
auch
die
anderen
wesentlichen
Programmierschnittstellen erwähnt, die vom Server offen gelegt werden. Neben einer
Erweiterung für CDO – Publishing and Knowledge Management Collaboration Data Objects
(PKMCDO), die das Objektmodell von SharePoint Portal Server repräsentiert, wird mit
SharePoint Portal Services auch eine Webdienst-Schnittstelle geliefert. Über Webdienste
können u.a. sowohl Dokumente, Sites etc. als auch der SPS-Server verwaltet werden. In dem
Namensraum
Microsoft.SharePoint
sind
die
Klassenbibliothek
und
die
Programmierschnittstelle der Microsoft SharePoint Diensten implementiert. Die Webdienste
befinden sich in der Microsoft.SharePoint.SoapServer-Komponente und basieren auf dem
ASP.NET-Framework. Um beispielsweise ein Verzeichnis im Dokumenten-Workspace
(s.Abb. 10) zu erzeugen, wird der Document Workspace-Dienst verwendet, der via folgenden
URL ansprechbar ist:
http://Server_Name/_vti_bin/Dws.asmx
Die Web-Methode heißt in diesem Fall CreateFolder (String) und erwartet als Parameter
einen Namen für das Verzeichnis.
4.4.2
Der ScharePoint Server basiert auf dem Exchange Webstore (in den älteren Versionen wird er
Information Store genannt) und erweitert den Webstore mit eigenen Attribut- und
Klassendefinitionen zum Zweck seiner Bestimmung als Kollaborationssoftware. Sowohl
Exchange, als auch SharePoint Portal Server bieten über Internet Information Services und
WebDAV einen Zugriff auf die Funktionalitäten und Daten, gespeichert in dem WebStore. Im
Folgenden werden nur einige Besonderheiten der Attribut- und Klassendefinition von SPS
erwähnt, ansonsten ist auf die Metadatenbeschreibung von Exchange Server im Kapitel 4.3.2
hinzuweisen.
57
Das globale Schema kann ähnlich wie bei Exchange Server programmatisch mit dem
folgenden URI erhalten werden:
http://<server>/<workspace>/##SchemaURI##/microsoft/tahoev1
Das Schare Point-Schema unterscheidet zwischen Eigenschaften, die bei einer Suche
einbezogen werden können und solche, bei denen das nicht möglich ist. Die suchbaren
Dokumenteigenschaften stellen Dokumenten-Attribute dar, die der Server mit den
Dokumenten
im
Workspace
assoziiert,
wie
z.B.
letzter
Änderungsstempel
oder
Erstellungsdatum, die zum Dokumentenprofil gehören. Weitere Eigenschaften werden vom
Suchdienst benötigt, um die Items im Webstore zu indexieren. Der Suchdienst ermöglicht
auch Volltextsuche, indem die Anfragen auf Sql aufbauen und ein Full Text Index verwendet
wird. Das Ergebnis der Volltextsuche kann nach bestimmten Kriterien (z.B. Kategorie, Autor)
sortiert werden.
58
5
Entwurf und Implementierungsdetails
5.1
Architektur-Entwurf
Angesichts der Ziele dieser Arbeit ergibt sich eine 3-Schichten Client/Server Architektur. Die
Datenzugriffskomponenten sorgen für die Persistenz der Daten (ähnlich wie bei CMP-Entity
Beans12 in J2EE [SUN05]), sie laufen aber nicht in einem eigenen Container, was die
Verteilung der Komponenten ermöglichen würde und bieten auf dieser Ebene keine
Möglichkeit an, Geschäftsprozesse zu implementieren, was von einem Business-Tier erwartet
wird. In diesem Zusammenhang weisen die Schichten in Abbildung 12 nur auf die
Funktionsbestimmung der mitwirkenden Komponenten hin.
•
Java-Client
•
WS-I & WS-*
•
Autorisierung,
Authentifizierung
•
Data Access
Objects/Service
Facade
•
Adapter/DAL/
Modelle
•
APIs und eigene
DALs(DataAccess
Helper [SET04])
•
Enterprise
Systeme
Abbildung 12: Schichtendiagram
12
Entity Beans repräsentieren Business-Objekte (Customers, Order…) aus einer Datenbank. Bei Container
Managed Persistence (CMP) wird die Persistenz der Daten von dem EJB-Container mit Hilfe des Deployment
Descriptors, wo ein abstraktes Schema für die Daten vorgegeben ist, bereitgestellt.
59
Auf der Datenebene befinden sich die zu integrierenden Unternehmensanwendungen. Diese
beinhalten die Daten und bieten Zugriffspunkte für die höher liegende Ebene, die die in
Kapitel 4 beschriebenen Programmierschnittstellen erfasst.
Die Ebene der Dienste bildet den Kern des Systems. Sie wird in weitere drei Ebenen
unterteilt: die DataAccess-Helper (s. Kapitel 3), die Datenzugriffsschnittstellen und
Datenabstraktion sowie die Dienstebene.
Die Datenzugriffsebene abstrahiert die DataAccess-Helper-Ebene [SET04], indem sie
Aktionen
wie
Initialisierung,
Datenvorbereitung
und
Authentifizierung
an
den
Unternehmensanwendungen übernehmen. Bei Bedarf, wie z.B. bei der fehlenden
Unterstützung in .NET für WebDAV (die XMLHTTP-COM-Komponente ist in .NET nur
durch COM Interop einsetzbar), werden hier auch die ganzen Kommunikationsmechanismen,
anhand der zugrunde liegenden Programmierschnittstellen, implementiert. Somit ist es
möglich z.B. mehrere auf System.Web-Namespace Datenzugriffskomponenten zu entwickeln,
wobei jede von diesen spezifischen Eigenschaften für den Kommunikationsmechanismus
berücksichtigt. Darüber hinaus enthält diese Komponente auch die objektorientierten Adapter,
die die von den DataAccess-Helper definierten Schnittstellen an den intern für das System
vorgelegte Schnittstelle anpassen. Die Adapter sorgen außerdem durch Reflektion für das Ein/Auspacken der Daten entsprechend in/aus den Objekten. Insofern werden auch die
Datentypen
und
Befehlssyntax
beachtet,
die
für
die
unterliegenden
Datenzugriffskomponenten von Bedeutung sind. Damit ist ein weiteres Abstraktionsniveau
für die höher liegenden Komponenten vorgegeben, das immer noch nicht von der Existenz der
Modelle weiß und mit keinen Metainformationen über die Daten, mit Ausnahme von der
primären Schnittstellen-/Systemtypen, verfügt.
Die Data Abstraction Komponente besteht aus den extrahierten Modellen. In Form von C#Klassen, die zusätzlich mit Metadaten angereichert werden, legen diese die Struktur und
gegebenenfalls weitere Eigenschaften der Daten fest. Diese Metadaten sind im Code durch
Annotationen realisiert und bilden eine Metamodell-Ebene für die zu integrierendem
Unternehmensanwendungsschema.
Mit den Diensten wird die Lücke zwischen dem abstrakten Datenzugriff und den MetadatenBeschreibungen gefüllt. Die Dienste greifen mit Hilfe der Datenzugriffschnittstellen auf die
Daten zu. Mit den vorliegenden Modellen kennen sie auch die Struktur der Daten. In Bezug
auf die transferierenden Objekte und Datenzugriffskomponenten als Schnittstellen zu den
60
Datenquellen erweist sich der Data Access Object (DAO)-Pattern als geeignet für den
Entwurf. Diese Überlegung wird im Kapitel 5.5 näher betrachtet.
In Abbildung 13 sind die Systemkomponenten und die Relationen zwischen diesen
angegeben.
Die
SchemaExtractor-Komponente
extrahiert
die
Metadaten
aus
den
Unternehmensanwendungen und erzeugt ein System.Xml.Serialization.XmlSchemas-Objekt,
das bei Bedarf auch die Serialisierung in Xsd-Dateien vornimmt. Wie im Diagramm zu sehen
ist, wird dieses Objekt von der CodeGenerator-Komponente zum Erzeugen von C#-Code
verwendet. Abhängig von den Anpassungen, definiert durch annotations in einem Xml
Schema, kommt auch die Extensions-Komponente zum Einsatz. Anschließend wird der Code
kompiliert und daraus entsteht die de.tu._in_.ib.models Komponente. In der letztgenannten
Komponente fließen außerdem Metadaten in Form von .Net-Attributen ein. Ein Beispiel für
solche Attribute ist der PrimaryKey-Constraint für eine Tabelle in einer relationalen
Datenbank. Die Attribute werden in der de.tu-Komponente definiert. Der gesamte Prozess ist
in de.tu._in_.ib.engine implementiert und wird abhängig vom Zustand der instanziierten
Konfigurationskomponente gesteuert.
61
Abbildung 13: Komponentendiagram
Die Konfigurationskomponente wird auch dazu verwendet, den Diensten (de.tum._in_.ib.dao)
Datenzugriffskomponenten und Metadatenbeschreibungen zur Verfügung zu stellen. Insofern
die Datenzugriffskomponente die Schnittstelle IDAL implementieren und anhand von
Reflektion mit abstrakten Objekten arbeiten, ist die dynamische Erzeugung der Data Access
Objects, abhängig von den Entitäten in der models-Komponente, möglich. Für jede Entität
wird der Quellcode einer Klasse generiert, der die IDAL-Schnittstelle implementiert.
5.2
Extrahieren der Metadaten
Wie im vorherigen Kapitel erwähnt, braucht das System die Metadaten, um Zugriffe auf
unterschiedliche Datenquellen automatisch durchführen zu können und die darin enthaltenen
Entitäten offen zu legen. Solche Metadaten sind auch die primären Datentypen, die in jeder
Unternehmensanwendung unterschiedlich sein können. Alle Modelle befinden sich in der
62
de.tum._in_.ib.models Namespace. Sie werden dann weiter in exchange, ad, mssql
Namespaces unterteilt. Der de.tum._in_.ib.annotations-Namensraum bildet eine MetamodellEbene für das Schema in den Unternehmensanwendungen und kann nicht automatisch
generiert oder aus den Anwendungen extrahiert werden. Sie wird in Zusammenhang mit den
in den Anwendungen realisierten Konzepten für die Persistenz von Datenbeständen
entwickelt.
Für jede der Unternehmensanwendungen implementiert eine Klasse den Mechanismus zum
Extrahieren der Metadaten, vorgegeben durch die ISchemaExtractor-Schnittstelle (s. Abb.13).
Im Allgemeinen werden folgende Schritte befolgt:
•
Angabe von den systemeigenen, primären Datentypen;
•
Zuordnung zu Xml Schema-Datentypen erstellen;
•
aus den extrahierten Metainformationen, Xml Schema-Elemente generieren, dabei
Namensräume, Vererbung und Einschränkungen der Daten beachten und die
vorliegenden primären Datentypen einsetzen;
•
aus den Xml-Schemas C#-Code generieren.
Die primären Datentypen können entweder in Xml Schema-Format angegeben werden, oder
fest im Code programmiert sein. Die erste Variante ist wegen der Versionierung besser
geeignet. Für neue Versionen der Unternehmensanwendungen können bei Bedarf die
primären Datentypen geändert oder erweitert werden.
Im Folgenden werden die Vorgehensweisen beim Extrahieren der Metadaten für jede
Unternehmensanwendung detaillierter vorgestellt.
5.2.1
Microsoft Sql Server
Als Programmierschnittstelle werden das ADO.NET-Framework zusammen mit dem OLE
DB-Datenprovider eingesetzt. Die primären Datentypen ergeben sich also aus den OLE DBProvider-Datentypen. Die Zuordnung von OLE DB-Provider-Datentypen zu Sql ServerDatentypen ist dabei uninteressant, weil die benötigten Relationen und gegebenenfalls
Transformationen von dem Provider übernommen werden. Es bleibt also den OLE DBDatentypen Xml Schema-Datentypen zuzuweisen. In der Herstellerdokumentation von
Microsoft Sql Server, .Net-Framework und OLE DB-Referenzbuch (s. Kapitel 3.2.2) sind
sowohl die benötigten Informationen über die primären Datentypen vorhanden, als auch die
63
Zuordnung von OLE DB-Datentypen zu .Net-Datentypen angegeben. Daraus wird nun
jeweils ein Xml Schema-Element für jede der SQLOLEDB-Datentypen generiert. Das Xml
Schema-Element13 BigInt ist simpleType.
<xs:simpleType name="BigInt">
<xs:annotation>
<xs:appinfo>
<c:dotNetType
xmlns:c="http://da.matthes.in.tum.de/oleDBTypes">
System.Int64</c:dotNetType>
</xs:appinfo>
</xs:annotation>
<xs:restriction base="xs:long"/>
</xs:simpleType>
Dem Element werden aus dem XML Schema-Namensraum ein Attribut name und die
restriction und annotation Unterelemente eingefügt. Das Attribut „name“ enthält als Wert den
OLE DB-Datentyp und das restriction-Element legt den basis Xml Schema-Datentyp an. Das
annotation-Element gibt weitere benutzerdefinierten Informationen, die bei der Entwicklung
der SchemaExtractor-Komponente von Hilfe sein können. In diesem Fall ist das der .NetDatentyp, der dem OLE DB-Datentyp entspricht.
Nun werden die eigentlichen Daten, die in der Datenbank gespeichert sind, beschrieben.
Zuerst werden mit Hilfe der Methode OleDbConnection.GetOleDbSchemaTable alle Tabellen
aufgelistet und jeweils ein Xml Schema-element-Element erzeugt. Die Methode gibt bei
jedem Aufruf eine Tabelle mit Metainformationen, abhängig von den GUID- und
Einschränkungswerten (s. Kapitel 4.2). Mit einem GUID-Wert „COLUMNS“ legt die
zurückgegebene DataTable die Struktur jeder Tabelle fest. Es wird ein complexTypeUnterelement mit einer Sequenz von Unterelementen eingefügt, die der Tabellenspalten
entsprechen. Als Beispiel wird die Tabelle „Categories“ in der Nortwind-Datenbank
ausgesucht. Mit sql ist der Zielnamensraum des Dokuments referenziert.
<xs:element name="Categories">
<xs:complexType>
<xs:sequence>
<xs:element name="CategoryID" type="xs:int" />
<xs:element minOccurs="0" name="CategoryName" type="xs:string" />
<xs:element minOccurs="0" name="Description" type="xs:string" />
<xs:element minOccurs="0" name="Picture" type="xs:base64Binary" />
</xs:sequence>
</xs:complexType>
<xs:key name="CategoryID_pk">
<xs:selector xpath=".//Categories" />
<xs:field xpath="CategoryID" />
13
Xml Schema-Namensraum ist mit dem Unified Resource Identifier „http://www.w3.org/2001/XMLSchema“
eindeutig festgelegt. Aus diesem Namensraum stammen die oben erwähnten Elemente, die in der XSD Spezifikation [W32001] definiert werden.
64
</xs:key>
<xs:keyref name="CategoryID_fk_Products_CategoryID"
refer="sql:Products_Constraint1">
<xs:selector xpath=".//Categories" />
<xs:field xpath="CategoryID" />
</xs:keyref>
</xs:element>
Die Einschränkungsinformationen, wie Primär- und Fremdschlüssel, werden durch keyElemente ausgedrückt. Diese referenzieren entsprechend Primärschlüssel-Unterelemente im
gleichen Tabellenelement oder als Fremdschlüssel-Einschränkungselemente in einem anderen
Tabellenelement. Das keyref-Element referenziert für einen Primärschlüssel in der Tabelle die
Fremdschlüssel-Einschränkung, die auf diesem Primärschlüssel zeigt. Das keyref-Element
kann dann über annotation-Elemente mit den Optionen für Lösch- oder Änderungsweitergabe
(cascading) erweitert werden (s. Kapitel 4.2). In Abbildung 14 wird ein Ausschnitt aus dem
Datenbankschema mit Tabellen und die Beziehungen zwischen diesen angegeben.
Abbildung 14: Ausschnitt aus dem Datenbankschema der Beispielsdatenbank „Northwind“
Wie in der Abbildung zu sehen ist, werden die Produkte in Kategorien eingeteilt. Wenn z.B.
eine Kategorie gelöscht wird, wirkt sich das auf die Produkte aus. Entweder werden alle
Produkte in dieser Kategorie mitgelöscht oder der Löschvorgang schlägt fehl.
Eine andere Möglichkeit besteht darin, anstatt gleich Xml-Elemente zu produzieren, die
integrierte Xml-Unterstützung von dem ADO.NET-DataSet zu nutzen. Aus den erhaltenen
Metainformationen wird ein DataSet gebildet. Wie im vorherigen Abschnitt beschrieben,
65
werden alle Tabellen, Spalten und Einschränkungseigenschaften durchlaufen. Dabei werden
aber nicht XSD-Elemente, sondern die entsprechenden Tabellenobjekte, Spaltenobjekte und
Einschränkungsobjekte erzeugt. Bei der Initialisierung der Spalten werden die .NetDatentypen benötigt, also wird die Zuordnung von OLE DB-Datentypen zu .NET-Datentypen
eingesetzt. Das DataSet benutzt für Ein- und Ausgabe Xml-Ströme (s. Kapitel 3.3.2), daher
kann aus dem DataSet ein Xml Schema-Objekt nur mit den folgenden zwei Zeilen erzeugt
werden.
DataSet ds = new DataSet();
………
System.IO.StringReader sr = new System.IO.StringReader(ds.GetXmlSchema());
System.Xml.Schema.XmlSchema schema= System.Xml.Schema.XmlSchema.Read(sr,…);
Nachdem das DataSet mit den Tabellen und den Beziehungen zwischen diesen aufgefüllt ist,
wird das SOM-Model über einen Datenstrom in einer XmlSchema-Instanz eingelesen. Diese
wird zurückgegeben, um sie später entweder als in Textform zu bringen oder Quellcode
daraus zu erzeugen.
5.2.2
Active Directory
Die primären Datentypen sind in Active Directory fest programmiert und können nicht als
Objekte ausgelesen werden. Die Informationen für das Mapping zwischen AD-Datentypen
und XmlSchema-Datentypen müssen also aus der Herstellerdokumentation [MSDN15]
gewonnen werden. In der Dokumentation wird ein Mapping zwischen .NET-Datentypen, die
primäre ADSI-Datentypen (COM Automation-Datentypen), sowie die ADSI-Strukturen und
AD-Datentypen definiert. Jeder Eintrag in diesem Mapping wird durch den attributeSyntaxund oMSyntax-Wert eindeutig festgelegt, mit Ausnahme der Objekttypen, die zusätzlich durch
einen oMObjectClass-Wert definiert werden (s. Kapitel 4.1). Daraus wird ein Xml-Schema
erzeugt, dessen Elemente einen eindeutigen Identifikator haben. Wenn der Typ kein COMObjekt darstellt (oMSyntax-Wert ist gleich 127), besteht der Identifikator nur aus den
zusammengefügten Werten von attributSyntax und oMSyntax, andernfalls wird dazu auch den
Wert von oMObjectClass genommen. Für jede Kombination ist ein simpleType-Element mit
einem restriction-Unterelement im Schema definiert. Das restriction-Element enthält den
XSD-Typ als Wert eines base-Attributs. Für die Objekttypen muss der Wert xs:any sein,
damit bei der Codegenerierung die Serialisierungskomponente ein Feld vom Typ
System.Xml.XmlElement
erzeugt.
Dieser
Typ
kann
dann
mit
einer
Code-
Anpassungserweiterung mit System.Object ausgetauscht werden. Dann kann dieses Feld eine
66
COM-Objekt-Eigenschaft aufnehmen. Für die Nutzung dieser Eigenschaft ist entweder eine
Typumwandlung auf eine ADSI-Schnittstelle oder Reflektion nötig.
Wie im Kapitel 4.1.2 beschreiben, sind die Metainformationen von Active Directory in der
Schemapartition gespeichert. Die Metainformationen sind auch Objekte mit Eigenschaften,
die mit Hilfe von ADSI und der verwalteten Komponente DirectoryServices ausgelesen
werden können. Als erstes muss eine Bindung zum Schema-Naming-Context hergestellt
werden. Wenn der Hostname und der „Distinguished Name“ (DN) nicht bekannt sind, werden
diese über rootDSE ermittelt. Aus der Position des Schema-Containers wird die Suche nach
den Objekten für die Xml-Schema-Erstellung gestartet.
Das objectClass-Attribut legt die Klasse eines Objekts fest, die die Verwendung eines Objekts
bestimmt. Die Einträge in der Schemapartition enthalten als Objekte auch dieses
obligatorische Attribut. Die Werte die es annehmen kann, sind attributeSchema und
classSchema. Die Attributdefinitionen beschreiben die Attribute und die Klassen – die
Struktur der Objekte. In der Abbildung 15 sind einige vordefinierten Klassen in Active
Directory dargestellt. Die Klassen sind hierarchisch angeordnet und können von weiteren
Klassen abgeleitet sein.
<xs:complexType name="user">
<xs:complexContent mixed="false">
<xs:extension base="lt:organizationalPerson">
<xs:sequence>
<xs:element ref="lt:businessCategory" />
<xs:element ref="lt:userCertificate" />
………
<xs:element ref="lt:accountExpires" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Abbildung 15: Ausschnitt aus Active Directory Schema
Die Klasse User erbt die Attribute von OrganizationalPerson und Person und alle Klassen
erben die Attribute der top-Klasse. Ein Attribut kann von mehreren Klassen benutzt werden,
also ist es sinnvoll, genauso wie bei AD, die Attribute global zu definieren und aus den Xml67
Schema-Elementen, die die Klassen repräsentieren, zu referenzieren. Für die Attribute werden
simpleType-Elemente erzeugt, deren Datentypen von den drei typspezifizierenden Attributen
und in Xml-Schema definiertem Mapping festgelegt wird. Die Attribute werden mit Hilfe der
DirectorySearcher-Klasse mit dem Filter „objectClass=attributeSchema“ erhalten. Die
Attributnamen werden dann zwischengespeichert, weil sie bei der Erzeugung der KlassenElemente gebraucht werden. Die Namen sowohl der Attributen, als auch der Klassen werden
eindeutig durch das Attribut lDAPDisplayName bestimmt.
Für die Klassen werden complexType-Elemente erzeugt. Dabei wird in der Definition auf das
Attribut subClassOf geachtet. Es enthält die Klasse, von deren Xml-Schema-Repräsentant
der Xml-Schema-Typ abgeleitet werden muss. Das Attribut für die top-Klasse enthält den
Wert top und wird beim Durchlauf ignoriert. Die Vererbung wird durch ein extensionElement definiert, das mit dem base-Attribut auf den vererbenden Typ zeigt. Beispielsweise
ist in der Abbildung die XSD-Definition von der User-Klasse angegeben. Mit “lt” wird der
Prefix eines Namensraums bezeichnet, der auch Zielnamensraum in diesem XSD-Dokument
ist. Weil die User-Klasse von OrganizationalPerson erbt, enthält sie als Wert für das baseAttribut den qualifizierten Namen des organizationalPerson-Typs.
5.2.3
Exchange Server
Wie in Kapitel 4.3 erwähnt, befindet sich die Metadatenbeschreibung der Items im Webstore
in Xml-Dateien in einem schema-Ordner. Sie sind auch über HTTP/WebDAV zugänglich.
Die Xml-Dokumente in diesen Dateien sind in XDR-Format, wobei für jedes Attribut und für
jedes Element eine eigene Datei angelegt worden ist. Die primären Datentypen befinden sich
im urn:schemas-microsoft-com:datatypes-Namensraum und werden im Exchange Server
SDK definiert [ESDK03]. Von der Dokumentation kann also ein Mapping zwischen den
Microsoft-Datentypen und den XSD-Datentypen erstellt werden. Eine andere Möglichkeit
bietet der World Wide Web Consortium, indem sie die Microsoft-Datentypen als Data Type
Definition (DTD)-Notation-Deklarationen deklarieren [W30100]. Diese können dann über
den festgelegten Namen referenziert werden.
Mit der System.Xml.Schema-Komponente ist es möglich, aus diesen Dokumenten ein SOM14
zu bilden. Der Nachteil dabei ist, dass der XDR-Prozessor in dieser Komponente die
Namensräume nicht beibehält und diese bei der Generierung von z.B. SQL-Anfragen benötigt
werden. Also muss ein XDR-Prozessor für die Exchange-Schemadokumente entwickelt
14
Schema Object Model (s. Kapitel 3.1.1)
68
werden. Weil die Definitionen der XDR-Elemente und Attribute auch in Dateien in diesem
Ordner deklariert werden, müssen sie bei der Umwandlung übersprungen werden. Das ist mit
der Ignorierung aller Elementen und Attributen aus dem urn:schemas-microsoft-com:xmldata-Namensraum gleichgesetzt, der die XDR-Definition für XDR-konforme Dokumente
repräsentiert.
Die Dokumente werden mit der System.Xml-Komponente ausgelesen. Die Frage nach der
Wahl zwischen SAX und DOM bedeutet für die Entwicklung der Extrahierungskomponente,
ob mehr Effizienz oder weniger Komplexität gewünscht ist. Es kann ohne weiteres
angenommen werden, dass die Extrahierung der Metadaten aus Exchange Server sehr selten,
wenn nicht nur bei jeder Installation ausgeführt wird. Also fällt die Entscheidung wegen der
Komplexität der Aufgabe auf DOM.
Bei der Erzeugung der XSD-Dokumente müssen die Namensräume beibehalten werden und
da es mehrere gibt, muss für jeden ein separates XSD-Dokument mit dem entsprechenden
Zielnamensraum erzeugt werden. Am Ende sind genauso viele Dateien, wie es Namensräume
in den XDR-Deklarationen gibt, mit Ausnahme der zwei oben genannten Namensräume.
Im Folgenden ist die Deklaration der folder-Content Klasse angegeben. Mit ElementType
wird ein Typ definiert, unabhängig davon, ob er im Vergleich zu XSD einen komplexen Typ
mit Unterelementen darstellt.
<Schema name='ExchangeSchema' xmlns="urn:schemas-microsoft-com:xml-data"
xmlns:d="DAV:" xmlns:ex="http://schemas.microsoft.com/exchange/"
xmlns:cc="urn:content-classes:" xmlns:dt="urn:schemas-microsoftcom:datatypes" xmlns:s="urn:schemas-microsoft-com:exch-data:"
xmlns:m="urn:schemas:httpmail:">
<ElementType name="cc:folder" d:contentclass="cc:contentclassdef"
s:comclassid="CD00010E-8B95-11D1-82DB-00C04FB1625D"
s:comprogid="CDO.Folder" s:closedexpectedcontentclasses="0" >
<extends type="cc:item"/>
<s:expected-content-class type="cc:item"/>
<s:expected-content-class type="cc:folder"/>
<element type="ex:adminfolderdescription"/>
<element type="s:baseschema"/>
……
<element type="s:expected-content-class"/>
……
<element type="ex:foldersize"/>
……
</ElementType>
</Schema>
69
Im urn:schemas-microsoft-com:exch-data-Namensraum werden Elemente definiert, die
spezifische für den Exchange Server oder für die Anwendungsprogrammierer Metadaten
darstellen.
Mit
der
„urn:schemas-microsoft-com:exch-data:expected-content-class“-
Eigenschaft z.B. kann eine Einschränkung für die enthaltenen Items für dieses Verzeichnis
festgelegt werden. Mit s:commclassid-Eigenschaft und s:comprogid-Eigenschaft können
Items dynamisch auf die allokierte und instanziirte Klasse der CDO-Komponente (s. Kapitel
3.2.1) gecastet werden.
Der Exchange Webstore besitzt eine hierarchische Struktur, in der Items Eigenschaften von
anderen Items erben können. Ein ElementType-Element in XDR besitzt dafür ein extendsUnterelement, der auf die übergeordnete Itemdefinition zeigt. In Abb.16 sind einige für den
Exchange Server wesentlichen Itemdefinitionen und die Beziehungen zwischen diesen
angegeben. Alle Elemente im Webstore sind Items, daher übernimmt die Itemdefinition die
oberste Stelle in der Hierarchie der Metadaten. Sowohl Message als auch Folder erben von
Item. Ein Mailverzeichnis ist auch ein Verzeichnis und erbt die Attribute sowohl von Folder
als auch von Item. Nun kann die eigentliche Umwandlung von XDR- nach XSD-Dokumenten
erfolgen.
Abbildung 16: Ausschnitt aus dem Exchange Server-Schema
Die ElementType-Elemente aus allen XDR-Dokumenten werden in einer DOM-Struktur auf
gleiches Niveau als Kinder eines XDR-Schema-Elementes abgebildet. Bei der Arbeit muss
auf die XPath-Komponente verzichtet werden, weil in XDR in den name-Attributen
70
Referenzen über die definierten Präfixe für die Namensräume erlaubt sind. Das „:“-Zeichen
ist also in den Werten dieser Attribute enthalten und obwohl Attribute in Xml als Werte nicht
geparste Zeichenketten (CDATA) annehmen können, schlägt die Komponente fehl.
Als erstes werden alle Namensräume des XDR-Schema-Elements in einem neuen
XmlSchema-Objekt
geladen.
Dann
werden
alle
ElementType-Elemente
im
DOM
durchgelaufen. Für diese, die primäre Datentypen haben, also das urn:schemas-microsoftcom:datatypes:type-Attribut enthalten, werden im XOM XSD-simpleType-Elemente erstellt
und für alle anderen - complexType-Elemente, jeweils mit den entsprechenden Präfixen für
die Namensräume in den Name-Attributen. Für die simpleType-Elemente werden noch
resctriction-Elemente mit den entsprechenden Typen aus dem vordefinierten Mapping
hinzugefügt. Damit sind die simpleType-Elemente, die die Definitionen der Eigenschaften in
Exchange Webstore-Schema repräsentieren, vollständig deklariert.
Bei den komplexen Typen werden noch die Unterelemente betrachtet. Für das extend-Element
werden für die Modellierung der Vererbung die Elemente complexContent und extension aus
XSD eingesetzt (s. Abb. 16). Für jedes element-Element wird in XOM ein Element in die vom
complexType enthaltene Sequenz mit Kindelementen (XSD-sequence) hinzugefügt. Die
expected-content-class-Eigenschaften stellen Sammlungen (Collections) von Objekten von
bestimmten Typen dar, die ein Verzeichnis aufnehmen können. Für die Collections können
komplexe Typen erstellt werden, die mit den Attributen minOccurs und maxOccurs im
untergeordneten sequence-Element die Häufigkeit der im sequence-Element enthaltenen
Unterelemente festlegen. Auf diese Weise können Arrays vom entsprechenden Typ für jedes
XDR-expected-content-class-Element modelliert werden.
Die Xml-Schema-Dokumente befinden sich nun in mehreren XOM-Instanzen. Damit sie
einzeln validiert und kompiliert werden können, werden import-Anweisungen deklariert, die
die Xml-Schema-Dokumenten referenzieren, die externen für das Dokument Xml-SchemaDeklarationen enthalten.
5.2.4
Benutzerdefiniertes Modell
Das Benutzerdefiniertes Modell (Common-Model) bildet das Kernkonzept des Systems und
zwar das Assemblieren von Entitäten die in unterschiedlichen Anwendungen definiert sind.
In der Abbildung 17 ist u.a. die Entität IBUser (information bridge - User) definiert. Ein
IBUser in diesem System enthält Nachrichten, Daten über ihn als Angestellter in einer
71
Datenbank, die für ihn enthaltenen Daten im Verzeichnisdienst, sowie ein Verzeichnis mit
Dokumenten und Nachrichten.
Abbildung 17: Beispielsinstanz des Common-Models
Die Entitäten IBUser, CustomFolder, DocumentCollection, Messages und MessageCollection
sind Entitäten, die im Common-Model definiert werden. Die restlichen stellen Entitäten aus
den integrierten Anwendungen dar. Um Daten persistent zu halten, müssen die deklarierenden
Entitäten auf Entitäten in den Unternehmensanwendungen verweisen. Verständlicherweise
müssen die Modelle für die Unternehmensanwendungen vorliegen, um das Common-Model
modellieren zu können. Die in den vorherigen Punkten beschriebenen Modelle werden in
Dateien als XSD-konforme Dokumente gespeichert. Das Common-Model ist selbst ein XSDDokument und importiert Typen von den anderen Modellen. Im Folgenden
wird ein
Ausschnitt für die IBUser-Entität aus dem Common-Model (s. Anhang 1) angegeben.
<xs:element name="IBUser">
<xs:complexType>
<xs:sequence>
<xs:element ref="lt:user"/>
<xs:element ref="sql:Employees"/>
<xs:element ref="cm:messages"/>
<xs:element ref="cm:CustomFolder"/>
</xs:sequence>
</xs:complexType></xs:element>
72
Bei der Deklaration von IBUser müssen nur die importierten und selbst definierten Typen
aufgelistet werden. Alternativ kann die messages-Entität gleich im IBUser deklariert werden,
um im Code ein Array vom Typ Exchange-message zu erhalten, anstatt einer Referenz auf
den Typ Messages, der seinerseits ein Array vom Typ Exchange-message enthält:
<xs:element ref="cm:message" minOccurs="0" maxOccurs="unbounded"/>
Die CustomFolder-Entität (s. Anhang 1) assembliert Nachrichten und Dokumente und stellt
gleichzeitig ein Verzeichnis dar, indem er die Eigenschaften der Exchange-mailfolder-Entität
erbt.
Als Angestellte und Benutzer im Active Directory enthält möglicherweise der IBUser
redundante Daten (s. Abbildung 18), wie z.B. Familiennamen. Die Lösung des Problems ist
eine bijektive Transformation zwischen den Common-Model-Entitäten und den Entitäten in
den Unternehmensanwendungen zu definieren. Dafür müssen Regeln aufgestellt werden, die
Fragmente des Common-Model-Modells (die benutzerdefinierten Entitäten - Quellmodell) auf
solche in den Unternehmensanwendung-Modellen (extrahierten Metadaten - Zielmodell)
zuweisen.
Exch.Employee
fname:John
IBUser
sname:Doe
fname=John
height:174cm
sname=Doe
height=174cm
AD.User
name=Doe,John
height=5,7ft
Transformation
Abbildung 18: Transformation zwischen Metamodellen [Anhang 3]
Weil Metamodelltransformationen außerhalb der Rahmen dieser Arbeit sind, werden im
Folgenden nur kurz zwei dafür geeignete Ansätze erwähnt. Hierfür werden als Metamodelle
die im System enthaltenen Modelle bezeichnet, wie z.B. die im Kapitel 5.2 extrahierten
Modelle und die eigentlichen Daten (Modell-Instanzen als Informationsobjekte) Modelle
genannt.
73
BizTalk Server behandelt dieses Problem (s. Kapitel 2.4.1), indem er mit dem BizTalkMapper ein graphisches Werkzeug für die Zuordnung von Elementen im Quellschema zu
Elementen im Zielschema zur Verfügung stellt. Die Zuordnungen werden im XSLT-Format
[W31199] gespeichert und bei ankommenden Daten eingesetzt (s. Anhang 4). Der Nachteil
dabei ist, dass die Transformation nicht bidirektional verlaufen kann und somit für beide
Richtungen die Zuordnungen erstellt werden müssen. Außerdem kann mit XSLT nicht
sichergestellt oder überprüft werden, ob das Ergebnis (Zielmetamodell-Instanz oder
Zielmodel) konform zum Zielmetamodell ist.
Mit der Bidirectional Object-oriented Transformation Language-Sprache (BOTL) [BRM03]
können
Regeln
in
Xml-Format
aufgestellt
werden,
die
mit
Hilfe
einer
Transformationskomponente auf Objektgeflechten angewendet werden können. Weil sie eine
UML-basierte MOF15-Instanz darstellt, können die Regeln und Metamodelle in einem
graphischen Werkzeug erstellt werden. Bei der Entwicklung sorgen Heuristiken dafür, dass
die Regeln auf die konkreten Daten (Objektmodelle), die konform zum Quellmetamodell sind,
mit immer dem gleichen Ergebnis angewendet werden können, unabhängig von der
Reihenfolge der transformierten Fragmente. Außerdem überprüfen sie, ob das Zielmodell der
Transformation
immer
konform
zum
Zielmetamodell
sein
wird.
Die
Transformationskomponente überführt zur Laufzeit abhängig von den definierten Regeln das
Quellmetamodell in das Zielmetamodell. Im Anhang 3 ist ein anschauliches Beispiel
angegeben, das nicht BOTL-konform ist und nur die grobe Vorgehensweise darstellt.
5.3
Code-Generierung
Die folgende Abbildung zeigt eine Zuordnung von den Elementen eines Xml-Schemas zu den
in UML dargestellten Klassen. Es wird darauf hingewiesen, dass es Elemente mit dem
gleichen Namen aus verschiedenen Namensräumen geben kann. Diese Elemente müssen bei
der Codegenerierung gegebenenfalls umbenannt und mit den Namensräumen über .NETAttribute gekennzeichnet werden. Die Vererbung zwischen den Entitäten muss beibehalten
werden.
15
Meta-Object Facility (MOF) von Object Management Group ist ein Metamodell für alle OMG-Metamodelle.
74
<xs:complexType name="message“…>
<xs:complexContent mixed="false">
<xs:extension base="cc:item">
<xs:sequence>
<xs:element ref="h:approved"/>
<xs:element ref="h:bcc"/>
<xs:element ref="m:bcc"/>
….
<xs:element ref="m:date"/>
….
</xs:sequence>
</xs:extension>
</xs:complexType>
<xs:simpleType name="date">
<xs:restriction base=„dt:dateTime"/>
</xs:simpleType>
Abbildung 19: Zuordnung Unternehmensanwendung - XmlSchema
Für die Code-Generierung wird die CodeDom .NET-Framework-Komponente verwendet.
Die Komponente CodeGenerator (s. Abb. 19) setzt auf diese auf, um aus Xml-Schema strikte
.NET-Datentypen
implementierten
zu
erstellen.
Objektmodel,
Es
um
benutzt
also
das
XSD-Dokumente
im
in
CodeDom-Namensraum
.NET-Quellcodedokumente
umzuwandeln. Die Metadaten müssen also bereits in XSD-Format definiert sein und
außerdem im Schema Objektmodel, abgekürzt SOM, geladen sein, was von der
SchemaExtractor-Komponente (s. Kapitel 5.2) übernommen wird.
Die Process-Methode der CodeGenerator-Klasse ist der Einstiegspunkt für die CodeGenerierung. Sie erwartet als Parameter ein XmlSchemas-Objekt, das eine Sammlung von
SOM-Instanzen – XmlSchema darstellt, die der geladenen und kompilierten Schemas
entsprechen. Als Rückgabe wird das Objektmodel des Quellcodes als ein CodeNamespaceObjekt zurückgegeben.
75
Abbildung 20: Die codeGenerator-Komponente zur Codegenerierung aus XSD.
Der Prozess der Code-Generierung aus XSD wird grob im Kapitel 3.1.2 beschrieben. Er kann,
wie bereits erwähnt, nicht beliebig gesteuert werden. Es ergeben sich zwei Möglichkeiten:
entweder wird für jedes Element im SOM ein Objekt aus dem CodeDom-Objektmodel
anhand von switch-Anweisungen und Fallunterscheidung instanziiert, oder wird mit Hilfe der
Serialisierungs-Komponente in .NET-Framework das CodeDom-Objektmodel aufgebaut und
später angepasst. Bei der zweiten Variante können beliebige Anpassungen hinzugefügt
werden, ohne den bestehenden Code in der codeGenerator-Komponente zu ändern. Das wird
über die ICodeGeneratorExtension-Schnittstelle ermöglicht. Jede Erweiterungs-Klasse im
Extensions-Namensraum muss diese Schnittstelle implementieren. Im übergebenen SOMModell wird nach einem <annotation>-Element gesucht, der die Anpassungen des Codes
durch Angabe der Klassen, die die genannte Schnittstelle implementieren und die Assembly
in dem sie sich befinden festlegt. Die Anpassungserweiterungen werden später in diesem
Kapitel für die Modellen für die einzelnen Unternehmensanwendungen beschrieben. Die
Erweiterungen können auch in einer externen Datei oder in einem XmlSchema-Objekt
definiert werden, im Folgenden Beispiel sind zwei Erweiterungen definiert.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo>
<Code xmlns="http://de.tum.in.ib/codeGenerator/extensions">
<Extension
Type="de.tum._in_.ib.codeGenerator.extensions.ArraysToCollectionsExtension,
ModelSerializer"/>
<Extension
Type="de.tum._in_.ib.codeGenerator.extensions.AddAnnotationNodeName,
ModelSerializer"/>
76
………
</xs:schema>
Beide befinden sich im ModelSerializer-Assembly und geben die Namen der Klassen an, die
die Schnittstelle implementieren. Nach dem Instanziieren der aufgelisteten Klassen wird für
jede Instanz für die XmlSchemas-Sammlung die Methode Process aufgerufen.
In dieser Arbeit wird diese zweite Variante ausgearbeitet. Für alle im SOM definierten
Elemente wird eine Zuordnung auf .NET-Konstrukte mit Hilfe der XmlTypeMapping-Klasse
und der XmlSchemaImporter-Klasse erstellt. Die .NET-Konstrukte werden dann unter
Verwendung der XmlCodeExporter-Klasse in dem CodeDom-Objektgraph eingefügt, der von
der CodeNamespace-Klasse repräsentiert wird. Der Name des neu erstellten .NETNamensraums wird als Parameter der Process-Methode übergeben. Für jede übergebene
XmlSchemas-Ansammlung wird ein separater .NET-Namensraum im Quellcode erstellt.
Beispielsweise befinden sich alle Klassen, die die im Active Direcory und Exchange Server
Entitäten
beschreiben,
in
den
Namensräume
de.tum._in_.ib.models.ad
und
de.tum._in_.ib.models.exchange. Die definierten in den XSD-Dokumenten Elemente kommen
aus verschiedenen Xml-Namensräume, die beibehalten werden müssen (s. Abb. 19). Sie
werden später von den Datenzugriffskomponenten gebraucht, um die qualifizierten Namen
der Entitäten in den Unternehmensanwendungen wiederherstellen zu können. Das geschieht,
indem weitere Meta-Informationen den .NET-Deklarationen in Form von Attributen
hinzugefügt werden. Diese Aufgabe wird teilweise von der Serialisierungskomponente
übernommen. Für jede Klasse, Feld oder Eigenschaft werden der Name und der Namensraum
aus dem Xml-Schema-Dokument mit Hilfe eines Serializierungsattributs angegeben. Das
Attribut entspricht einem Konstrukt aus dem Infoset von Document Object Model (DOM). Im
Folgenden
ist
beispielsweise
die
Klasse
IBUser
im
Namensraum
de.tum._in_.ib.models.common mit dem XmlRootAttribute-Attribut angegeben.
namespace
using
using
using
de.tum._in_.ib.models.common {
de.tum._in_.ib.models.exchange;
de.tum._in_.ib.models.ad;
de.tum._in_.ib.models.mssql;
using System.Xml.Serialization;
[System.Xml.Serialization.XmlRootAttribute("IBUser",
Namespace="http://da.matthes.in.tum.de/commonModel", IsNullable=false)]
public class IBUser {
[System.Xml.Serialization.XmlElementAttribute(Namespace="http://da.m
atthes.in.tum.de/ldapSchema")]
public de.tum._in_.ib.models.ad.User user{…}
[System.Xml.Serialization.XmlElementAttribute(Namespace="http://da.m
atthes.in.tum.de/sqlDBSchema")]
77
public de.tum._in_.ib.models.mssql.Employees employees{…}
[System.Xml.Serialization.XmlElementAttribute("message",
Namespace="urn:content-classes:")]
public MessageCollection message{…}
public CustomFolder customFolder{…}
}
………
}
Die Serialisierungskomponente fügt im Attribut des Quellcode-Konstrukts in CodeDomObjektgraph jedoch den Namen des Elements nicht hinzu, wenn der Name des Tags im XmlDokument mit dem Namen des Konstrukts im Quellcode übereinstimmt. Bei Serialisierung
und Deserialisierung kann der qualifizierte Name, der auf eine Entität oder eine
Entitätseigenschaft in der Unternehmensanwendung verweist, trotzdem wiederhergestellt
werden. Keine Übereinstimmung entsteht, wenn z.B. der Name in der Programmiersprache
belegt ist (es wird ein „@“ vor dem ersten Zeichen eingefügt) oder er unerlaubte Zeichen
enthält (diese werden entfernt), oder wenn zwei Eigenschaften aus verschiedenen XmlNamensräume kommen, die gleichen Namen haben und in der gleichen Klasse definiert
werden müssen (hier wird wiederum ein „_“ vor dem ersten Zeichen eingefügt). Solche Fälle
müssen berücksichtigt werden, wenn Erweiterungen für das Anpassen des Codes entwickelt
werden. In dem angegebenen Beispiel wird der Name der Klasse IBUser, obwohl es mit dem
Parameter des Attributs übereinstimmt, angegeben. Der Parameter wird z.B. wegen der
Erweiterung SetCapitalClassFirstLetterExtension (s.Abb. 21) gebraucht, die die erste
Buchstabe
aller
Klassennamen
großschreibt.
Nun
um
den
qualifizierten
Namen
wiederherstellen zu können, wird die Erweiterung AddAnnotationNodeName eingesetzt. Diese
fügt den ursprünglichen Namen, falls nicht vorhanden, als Parameter des Attributs hinzu.
Diese Attribute werden außerdem von den Erweiterungskomponenten bei der Anpassung des
Codes verwendet, die dafür den Objektgraph reflektieren.
78
Abbildung 21: Erweiterungen für die zusätzliche Anpassung des Quellcodes bei CodeGenerierung
Die Serialisierungskomponente in .NET 1.1 exportiert nur Felder und Arrays, wo
Eigenschaften und Collections den automatisierten Zugriff auf die erstellten Klassen
erleichtern. Die ArraysToCollectionsExtension übernimmt die Aufgabe, für jede generierte
Array-Deklaration
eine
Wrapper-Klasse
zu
erstellen,
die
von
System.Collections.CollectionBase abgeleitet wird. Die Wrapper-Klasse implementiert für die
Sammlung von Objekten den Zugriff über die Position des Objektes und eine Add-Methode,
mit der neue Objekte von dem Array-Typ eingefügt werden können. An dem Namen dieser
Wrapper-Klasse wird außerdem „Collection“ angehängt. Anschließend wird anstelle der
Array-Deklaration einen Verweis auf der neu erstellten Klasse eingefügt. Es wird darauf
geachtet, dass in einem Namensraum nur eine Wrapper-Klasse für einen Array-Typ generiert
wird und alle Array-Deklarationen von diesem Typ mit Verweisen auf diese Klasse ersetzt
werden.
Mit der FieldsToPropertiesExtension werden für alle Felder Eigenschaften mit AccessorMethoden erstellt. Dabei werden die Namen mit einem Unterstrich als erstes Zeichen
erweitert. Die Kommentare und Attribute werden den Eigenschaften zugewiesen. In der getund set-Accessor-Methode werden keine Einschränkungen der Datentypen berücksichtigt.
79
Die letzte in der Abbildung 21 dargestellte Erweiterung ist die AddDBConstraintAnnotationsKlasse. Mit dieser Erweiterung wird der Quellcode mit Metadaten angereichert, die die
Elemente des relationalen Datenbankmodels (s. Kapitel 4.2) beschreiben. Die Attribute sind
im de.tum._in_.ib.annotations Namensraum deklariert.
Abbildung 22: Attribute, die Strukturen in relationalen Datenbanken beschreiben.
Diese Attribute können dazu benutzt werden, um komplexe Datenstrukturen über die
Datenzugriffskomponente anzufordern, oder Methoden automatisch zu generieren, die als
Parameter die Primärschlüssel einer Tabelle erhalten, damit z.B. bei Suchanfrage
gewährleistet wird, dass nur einen Datensatz gefunden und zurückgegeben wird.
Es ist ersichtlich, dass die Reihenfolge, in der die Erweiterungen ausgeführt werden, von
großer Bedeutung ist. Für das „common model“, das Model vom Exchange Server und das
von Active Directory hat sich folgende Reihenfolge bewährt:
ArraysToCollectionsExtension
AddAnnotationNodeName
SetCapitalClassFirstLetterExtension
FieldsToPropertiesExtension
Nachdem die Wrapper-Klassen für die Collections erstellt werden und der Name jeder Klasse
in ihrem Attribut eingefügt wird, können nun die ersten Buchstaben aller Klassen
großgeschrieben werden. Die FieldToPropertiesExtension wird als letzte ausgeführt, weil
ansonsten die anderen Erweiterungen, die die Felder im CodeDom-Objektgraph durchlaufen
und modifizieren, dann auch die Eigenschaften berücksichtigen müssen. Bei dem Microsoft
Sql Server bleibt die Reihenfolge dasselbe, hinzu kommt nur die Erweiterung für die Attribute
des relationalen Datenbankmodels. Sie wird zuletzt ausgeführt.
Im Abschluss dieses Kapitels werden die Problemfälle beim Verweis auf externe Datentypen
behandelt. Hier geht es darum, dass XSD-Dokumente von einander abhängen können, indem
80
sie externe Typen referenzieren (s. Kapitel 5.2). Wenn für alle Schemas den gleichen
CodeNamespace-Namensraum benutzt wird, besteht kein Bedarf die qualifizierten Namen der
Code-Konstrukte anzugeben, wie z.B. bei Exchange Server: obwohl die Elemente in den
Xml-Schema-Dokumenten aus verschiedenen Xml-Namensraümen stammen und in
verschiedenen Xml-Schemas deklariert sind, werden für diese Klassen im gleichen .NETNamensraum - de.tum._in_.ib.models.exchange deklariert. Wie bereits erwähnt, werden die
Xml-Namensräume als zusätzliche Metainformationen in den Attributen angegeben. Der
qualifizierte
Name
für
IBUser
im
vorherigen
Beispiel
ist
de.tum._in_.ib.models.common.IBUser. Die Klasse enthält aber Eigenschaften, die außerhalb
dieses .NET-Namensraums (CodeNamespace im CodeDom-Objektgraph) deklariert werden,
wie z.B. die Eigenschaft user, die im .NET-Namensraum de.tum._in_.ib.models.ad deklariert
wird.
Das
Common-Model
besteht
nur
deswegen,
um
benutzerdefinierten
Entitäten
(Systementitäten) zu definieren, die Entitäten aus verschiedenen Unternehmensanwendungen
zusammenführen.
Die
Systementitäten
bieten
auf
diese
Weise
eine
einheitliche
Zugriffsmöglichkeit auf komplexe Datenstrukturen, die im Einzelnen aus verschiedenen
Unternehmensanwendungen stammen können. Die Datenzugriffsebene übernimmt die
Verteilung der Anfragen an den verschiedenen Unternehmensanwendungen abhängig von der
Struktur und Eigenschaften der Systementitäten. Der oben beschriebene Problemfall mit den
.NET-Namensräumen entsteht also ausschließlich bei der Codegenerierung für das CommonModel. Hier ist noch einmal darauf hinzuweisen (s. Kapitel 5.2.4), das es dabei um Verweise
geht und nur auf ganze Entitäten. Der Verweis auf Eigenschaften einer Entität ist nicht
möglich. Damit werden die Problemstellungen bei Metamodelltransformationen vermieden,
die sicherlich nicht in dieser Arbeit überwindbar wären.
Beim Exportieren der Elementen aus den Schemas in den CodeNamespace durch die
Serialisierungskomponente werden nur die Referenzen auf Typen des gleichen CodeNamensraums oder die intern definierten Zuordnungen auf .NET-Framewrok-Typen
aufgelöst. Externe für den Code-Namensraum Datentypen müssen also besonders behandelt
werden.
Die
Klasse
CodeGenerator
enthält
drei
Felder:
eine
Referenz
auf
CodeNamespaceCollection, der Target-Namensraum des Xml-Schemas; eine Zeichenfolge als
Bezeichnung des zu erstellenden .NET-Namensraums, der ab jetzt als Zielnamensraum
genannt wird; und einen Verweis auf einem XPath-Ausdruck, der bei Bedarf extern für das
Schema definierte Erweiterungen enthält.
81
Die erste und zweite Variable sind für die Lösung der Problemstellung vorgesehen und
enthalten entsprechend die CodeDom-Namensräume, auf die referenziert wird und das
Target-Namensraum eines XmlSchemas, falls nur Elemente aus diesem Target-Namensraum
in Code umgewandelt werden müssen. Wenn beide gesetzt sind, werden die qualifizierten
Namen der extern definierten Typen über die CodeDom-Namensräume ermittelt und
entsprechende CodeDom-Deklarationen mit diesen angelegt. Anschließend werden die
import-Anweisungen für die externe Namensräume im CodeDom-Objektgraph eingefügt.
Mit Hilfe der CodeDomProvider-Klasse und der Microsoft.CSharp.CSharpCodeProviderKlasse ist der CodeDom-Objektgraph in Textform serialisierbar. Es bleibt nur übrig, den
Quellcode zu kompilieren und die .NET-Assembly den Datenzugriffsschnittstellen zur
Verfügung zu stellen. Für das Kompilieren des Quellcodes gibt es zwei Möglichkeiten. Die
erste basiert auf dem .NET-Compiler csc.exe. Der Compiler wird in einer Konsole gestartet,
die Quellcode-Dateien erhält er als Parameter. Die zweite Möglichkeit beruht auf dem Einsatz
des CodeCompileUnit im CodeDom, dem gleich die erstellten CodeDom-Objektgraphen
übergeben werden. Über Parameter kann der Prozess des Kompilierens gesteuert werden, wie
z.B. Verlinken mit anderen Assemblies, oder den Namen des Assembly festlegen. Die
Prozesse der Serialisierung in Textform und das Kompilieren werden in der Klasse
ModelSerialiser implementiert. Eine weitere Komponente – de.tum._in_.ib.engine übernimmt
die Steuerung des gesamten Prozesses, der außerdem von den Konfigurationseinstellungen
abhängt. Mit der Erzeugung des Assembly ist die Aufgabe dieser Komponente abgeschlossen.
5.4
Komponenten für den Datenzugriff (Data-Access-Layers)
Der Datenzugriff wird in drei Schichten eingeteilt. Die unterste Ebene bilden alle
Komponenten, die Zugriff auf die Unternehmensanwendungen anbieten, einschlißlich die
selbst implementierten Kommunikationsprotokolle. Sie werden in der .NET-Architektur
DataAccess-Helper [SET04] genannt. Die selbst implementierten Kommunikationsprotokolle
erfüllen in dieser Arbeit gleichzeitig die Rolle der mittleren Schicht, die die
Datenzugriffskomponenten repräsentiert. Sie führen Aufgaben wie Initialisierung der
DataAccess-Helper, die Authentifizierung an den Unternehmensanwendungen etc. durch.
Damit bieten sie den überliegenden Komponenten einen einfachen und strukturierten Zugriff
auf
die
Unternehmensanwendungen.
Die
Object-Datenzugriffsebene
sorgt
für
die
Serialisierung der Objekte in den von den Unternehmensanwendungen geforderten Formaten
und vereinheitlicht die Arbeit mit den Datenzugriffskomponenten über vorgegebene
82
Schnittstelle. Die Struktur der erhaltenen über diese Schnittstelle Objekte ist wegen fehlender
Verlinkung mit der Model-Komponente nicht bekannt. Die Objekte müssen dann nach
systemspezifischen Regeln dynamisch verarbeitet werden. Somit wäre die nichtfunktionale
Anforderung für eine möglichst lose Kopplung erfüllt (s. Kapitel 2.5).
In Abbildung 23 sind die Klassen und Schnittstellen der Datenzugriffskomponente
angegeben. Dabei wurde versucht, die Schichten übereinander zu ordnen. Alle Klassen, deren
Namen mit „DAL“ enden, bilden die Datenzugriffsebene und alle, deren Namen mit
„Generic“ enden – die Object-DAL-Ebene. Die DataAccess-Helper-Ebene ist in diesem
Diagramm nur mit der ExchangeDAL-Klasse vertreten, die zusätzlich zu den Aufgaben in der
mittleren Ebene die WebDAV Kommunikationsprotokolle teilweise implementiert. Die
restlichen in der Abbildung angegebenen Klassen helfen den ObjectDALs mit der Reflektion
der Objekte, indem sie dabei behilfliche Strukturen aufstellen.
Abbildung 23: Klassendiagramm der Datenzugriffskomponente
Eine ObjectDAL-Klasse erfüllt die Rolle eines Objektadapters, indem sie die DAL-Klassen
(Adaptee-Objekte)
an der
vordefinierten
Schnittstelle (Target-IDAL)
anpasst.
Die
ObjectDALs erhalten von den überliegenden Komponenten (Diensten) Objekte, die sie
83
untersuchen. Abhängig von den in den Objekten gesetzten Eigenschaften und der
aufgerufenen Methoden bilden die ObjektDALs Nachrichten, die sie an den darunter
liegenden Datenzugriffsschnittstellen weiterleiten. Beispielsweise werden bei der Suche nach
Informationsobjekten gesetzte Eigenschaften zusammen mit den Werten als Suchattributen
und die nicht-gesetzten – als angeforderten Attributen in der Suchanfrage eingefügt.
Reflektion mit den Util-Klassen
Die in der Abbildung dargestellten Util-Klassen können als Parser von Objekten aufgefasst
werden. Mit Hilfe der Reflektions-Komponente System.Reflection laufen sie die Struktur des
Objekts
durch
und
abhängig
davon
erfüllen
Sie
verschiedene,
für
Unternehemensanwendungen spezifischen Aufgaben, um die Arbeit der ObjectDAL-Klassen
zu erleichtern. Die DALGenericUtil-Klasse übernimmt allgemeine Aufgaben, wie z.B. die
Ermittlung des qualifizierten Namens vom Typ eines Informationsobjekts in der
Unternehemensanwendung, oder des Namens einer von seinen Eigenschaften. Solche Art von
Informationen wurden in den Modellen in Form von Attributen hinzugefügt. Die
Ausprägungen dieser Klassen, wie DALGenericExchangeUtil, DALGenericADUtil etc.
übernehmen für die Systeme spezifische Aufgaben, wie z.B. die Ermittlung der
Schlüsseleigenschaft eines Objekts, um ihn in den Systemen eindeutig indetifizieren zu
können. Bei Microsoft Sql Server ist diese Eigenschaft durch einen selbst definierten Attribut
PrimaryKey (s. Kapitel 5.3.) angegeben. Bei Exchange Server ist sie die href-Eigenschaft der
Item-Klasse, die die Wurzel der im Modell aufgestellten Hierarchie darstellt. Im Active
Directory
sind
das
mehrere
Eigenschaften.
Weil
die
Attributdefinitionen
für
Einschränkungseigenschaften in dieser Arbeit nur für relationale Datenbanken erstellt worden
sind, wurden diese Informationen in den Util-Klassen fest codiert. Die Hauptaufgabe der UtilKlassen ist, beim Durchlaufen des Instanz-Objektmodells die gesetzten und nicht-gesetzten
Eigenschaften zu sammeln und zusammen mit den weiteren benötigten Informationen wie
Schlüsselattributen und qualifizierten Namen an den ObjektDALs zur Verfügung zu stellen.
Die Eigenschaften werden außerdem abhängig vom Typ in einem für das Zugriffsprotokoll
bestimmten Format überführt, z.B. der Wert einer Eigenschaft vom Typ String, die als
Suchattribut in einer Sql-Suchanfrage benutzt wird, wird in Anführungszeichen gesetzt.
Die DALCommonModelUtil-Klasse enthält weitere Funktionen, die Objekte mit bestimmten
Typ-Eigenschaften über Reflektion kopieren. Beispielsweise, wenn die Klasse B von A erbt,
können für alle in A definierten Eigenschaften den Werten für diese Eigenschaften von einer
A-Instanz einer B-Instanz zugewiesen werden. Die Laufzeitumgebungen moderner
84
objektorientierten Sprachen (Java RE, .NET CLR) erlauben nicht, einer B-Instanz eine AInstanz zuzuweisen. Der Bedarf für diese Funktionen wird bei der Beschreibung des internen
ObjektDAL für die anwendungsübergreifenden Anfragen erklärt.
Im Folgenden werden die Eigenschaften und Funktionsumfang der Schichten in Bezug auf die
für den Beweis des Konzepts ausgesuchten Anwendung genauer betrachtet.
5.4.1
Exchange Server
Data Access Layer (DAL)
Für die Kommunikation mit Exchange Server (s. Kapitel 4.3) wird WebDAV (s. Kapitel
3.2.5) verwendet. System.Web wird als Hilfskomponente eingesetzt, die die HTTP/HTTPSProtokolle implementiert. Die ExchangeDAL-Klasse benutzt die System.Web-Komponente,
für den Verbindungsaufbau und für die Autorisierung an Exchange Server. Im Fall von
HTTPS müssen die Zertifikate überprüft und angenommen werden. Die Überprüfung der
Zertifikate ist außer der Rahmen dieser Arbeit, es wird aber eine Methode zur Verfügung
gestellt, die alle Zertifikate als gültig einstuft, um die Verbindung herstellen zu können, die
bei der Weiterentwicklung entsprechend erweitert werden kann.
Nachdem die Verbindung aufgebaut ist, werden die Header und den Inhalt der HTTP-Anfrage
aufgefüllt. Der Content-Type-Header wird bei allen auf text/xml gesetzt.
Wie im Kapitel 4.3 erklärt wird, können die Items im Webstore über URI eindeutig
identifiziert werden. Der Host-URI oder der kompletten URI des Items muss beim Aufbau der
Verbindung angegeben werden. Falls nur der Host-URI angegeben wird, kann der relative
Pfad vom Host-URI zum Item als Header übergeben werden.
Die Klasse ExchangeDAL implementiert vier WebDAV-Methoden, auf die im Folgenden
eingegangen wird. Alle dieser Methoden fordern eine HTTP-Verbindung an, mit dem sie
dann weiter arbeiten.
propFind
Mit der propFind-WebDAV-Methode werden Eigenschaften von Items abgefragt. Bei der
Anbindung an Verzeichnisse können die Items des Verzeichnisses und ihren Eigenschaften
aufgelistet. Mit dem DEPTH-Header sind bei Verzeichnissen auch rekursive Anfragen
möglich. Bei Items wird mit diesem Header festgelegt, ob einige bestimmte Eigenschaften
angezeigt werden sollen. Als Erweiterung dieser Methode kann der Inhalt-Teil der HTTP-
85
Anfrage mit einem Xml-Dokument aufgefüllt werden, mit dem Eigenschaften gefiltert werden
können und somit der Netzwerk-Trafik entlastet wird.
...
request = (HttpWebRequest)HttpWebRequest.Create(url);
request.Method = "PROPFIND";
request.Headers.Add("DEPTH:"+depth);
…
reqStream.Write(bytes, 0, bytes.Length);
Die Methode erhält als Ergebnis ein Xml-Dokument, das sie als Ergebnis an der ObjectDAL
weiterleitet.
mkcol
Mit der mkcol-WebDAV-Methode können Verzeichnisse (Collections) erstellt werden. Diese
Methode setzt die HTTP-Methode auf MKCOL, den als Parameter übergebenen URI, und
schickt die Anfrage ab. Als Ergebnis erhält die Methode einen Statuscode im Textformat. Für
die Methoden müssen noch die Exceptions für die entsprechenden Antwortstatus-Codes
entwickelt werden. Der ObjectDAL behandelt nur den „201-Created“-Code.
delete
Genau so wie bei mkcol und propFind, wird nur der URI angegeben, der das zu löschendem
Item im Webstore definiert. Bei gesperrten Items oder fehlenden Rechten werden
entsprechende Statuscodes zurückgegeben.
search
Die Methode wird dafür Benutzt, um mittels Exchange SQL nach Items im Webstore zu
suchen. Die Methode setzt den DEPTH-Header auf den als Parameter übergebenen Wert. Das
Xml-Dokument, das die Sql-Anfrage enthält, wurde in einem String-Parameter übergeben und
muss vor dem Abschicken der Anfrage in einem Bytearray umgewandelt werden. Mit dem
Bytearray in HTTP-Content wird die Anfrage abgeschickt, dazu wird noch der ContentLength Header mit der Anzahl der übergebenen im Content Bytes aufgefüllt.
reqStream.Write(bytes, 0, bytes.Length);
Die Antwort ist ein Xml-Dokument, der als Ergebnis weitergeleitet wird.
ObjectDAL
In Exchange Server werden die Informationsobjekte über den URI adressiert. Die Dienste
setzten die „href“-Eigenschaft des Item-Typs auf den URI, der jedes Item im Webstore
86
eindeutig identifiziert. Das ist deshalb möglich, weil alle Informationsobjekte im Webstore
vom Item abgeleitet sind. Sie übergeben die so initialisierten Objekte an der ExchangeObjectDAL, die die DALGenericExchangeUtil-Klasse benutzt, um den URI, gesetzte
Eigenschaften und andere systemspezifischen Eigenschaften aus dem Objekt herauszufiltern.
Diese Klasse übernimmt abhängig von dem Typ der Eigenschaften ihre Formatierung, damit
die resultierende Nachricht konform zum von der Anwendung geforderten Syntax ist.
Die ObjektDAL-Komponente braucht bei den getund delete-Methoden nur den URI, um die
Anfragen über die Datenzugriffsschnittstelle abzuschicken. Dafür extrahieren sie nur den
Wert der „href“-Eigenschaft vom von den Diensten übergebenen Informationsobjekt. Die
Antwort ist in Form eines Xml-Dokuments, das von dem ObjectDAL geparst wird, um es in
solcher Form zu bringen, damit es über die .NET-Serialisierungs-Komponente in das gleiche,
von dem Dienst erhaltene Informationsobjekt deserialisiert werden kann. Das so gewonnene
Informationsobjekt wird an den Dienst zurückgegeben.
Bei einem insert wird der Typ des Objekts untersucht. Wenn es ein Verzeichnisobjekt
darstellt,
wird
mit
der
„href“-Eigenschaft
als
URI
die
mkcol-Methode
der
Datenzugriffsschnittstelle aufgerufen. Andernfalls wird vorausgesetzt, dass das Objekt eine
Nachricht darstellt, und eine Email-Nachricht mit Hilfe der .NET-System.Web.MailKomponente erzeugt. Dabei werden die System.Web.Mail.MailMessage-Eigenschaften
Exchange-Message-Eigenschaften zugeordnet.
Bei der search-Methode werden die gesetzten und nicht gesetzten Eigenschaften bei der
Generierung der Sql-Anfrage gebraucht. Die Util-Klasse füllt bei der Reflektion drei
Haschtabellen aus. Die ersten zwei enthalten entsprechend für die gesetzten und nicht
gesetzten Eigenschaften eine Zuordnung von einer Instanz der Reflektions-Klasse
PropertyInfo zu dem qualifizierten Namen der Eigenschaft. Die qualifizierten Namen
extrahiert die Util-Klasse aus den benutzerdefinierten Attributen der Klassen, die bei der
Code-Generierung erzeugt wurden. Die dritte Haschtabelle enthält eine Zuordnung von den
qualifizierten Namen der gesetzten Eigenschaften zu den Werten der Eigenschaften. Die
Werte der Eigenschaften müssen abhängig von ihren Typen formatiert werden, damit die
Suchanfrage konform zu der vom Exchange geforderten Syntax ist. Die Werte der
Eigenschaften
vom
Typ
String
werden
beispielsweise
in
die
Haschtabelle
in
Anführungszeichen hinzugefügt.
Die ObjectDAL-Komponente muss nun das Xml-Dokument (s. Kapitel 4.3) generieren, das
zusammen mit dem URI an die Datenzugriffsschnittstelle als Parameter übergeben wird. Es
87
wird ein DOM-Objektmodell gebildet, indem zuerst die Grundlegendestruktur angelegt wird.
Das sind die Xml-Deklaration, das searchrequest-Element und das sql-Element. Im sqlElement muss die eigentliche Sql-Anfrage angegeben werden.
Es werden alle Eigenschaften des Informationsobjekts durchlaufen. Für jede Eigenschaft, die
als PropertyInfo in der Haschtabelle für nicht-gesetzte Eigenschaften gefunden wird, wird der
qualifizierte Name (der eindeutigen Namen des Typs im Webstore-Schema) der Eigenschaft
im Select-Teil der Sql-Anfrage hinzugefügt. Diese werden mit Komma getrennt. In den
„From“-Teil wird der Wert der „href“-Eigenschaft angegeben. Für die Where-Klausel werden
die gesetzten Eigenschaften gebraucht. Die Zeichenketten „qualifizierter Name“, „=“, Wert
der Eigenschaft werden zusammengefügt und die einzelnen Bedingungen mit „AND“
getrennt. Da qualifizierte Namen unerlaubte Zeichen enthalten können, werden sie auch in
Anführungszeichen gesetzt. Die Werte falls nötig sind bereits von der Util-Klasse formatiert.
Anschließend wird diese Nachricht mit Hilfe der Datenzugriffschnittstelle abgeschickt.
Die Antwort wird als Xml-Dokument zurückgegeben. Nun werden alle prop-Elemente im
Dokument durchlaufen. Diese Elemente stellen die zurückgegebenen Datensätze dar. Da der
Typ der zurückgegebenen Informationsobjekte mit dem Typ des untersuchten, von den
Diensten übergebenen Informationsobjekts übereinstimmt, kann das Xml-Dokument mit Hilfe
der Util-Klasse überarbeitet und deserialisiert werden. Das geschieht folgendermaßen:
sb.Append("<cc:"+util.systemEntityName+" xmlns=\"DAV:\"
xmlns:cc=\"urn:content-classes:\">");
sb.Append(nodeVal);
sb.Append("</cc:"+util.systemEntityName+">");
Die Util-Klasse enthält immer noch den Namen der Entität im Exchange-Server und nodeVal
ist der Inhalt eines prop-Elements. Auf diese Weise kann die Serialisierungskomponente
entweder ein Objekt oder ein Array aus Objekten eines bestimmten Typs erzeugen.
5.4.2
Active Directory
Für LDAP wurde eine Datenzugriffsschnittstelle entwickelt, die mit Hilfe von
System.DirectoryServices die grundlegenden Funktionalitäten für die Arbeit mit einem
Verzeichnisdienst
implementiert.
Sie
übernimmt
den
Verbindungsaufbau,
die
Authentifizierung etc., indem nur die Initialisierung der Klasse und Angabe von wenigen
Parametern an den Methoden gefordert werden. Die Initialisierung wird von der ObjektDAL
(ADSIDALGeneric
und
Hilfsklassen)
übernommen,
indem
von
der
Konfigurationskomponente festgelegten Eigenschaften an die Datenzugriffsschnittstelle
88
weitergeleitet werden. Um einen Eintrag zu erstellen, werden z.B. die Properties, die contentclass (s. Kapitel 4.1) und der Name des Eintrags gebraucht. Der Eintrag wird, wenn nicht
anders angegeben, im DefaultNamingContext erzeugt.
Die ObjectDAL-Klasse operiert genauso wie die Exchange-ObjectDAL. Die Util-Klasse
trennt gesetzte und nicht-gesetzte Eigenschaften in Haschtabellen. Der eindeutige
Identifikator in dem gebundenen Container stellt hier das name-Attribut. Das Einfügen eines
Eintrags kann nach der Initialisierung der Util-Klasse in den folgenden zwei Zeilen
durchgeführt werden:
objName = util.objName.StartsWith("cn=")?util.objName:"cn="+util.objName;
dal.addObject(objName, util.systemEntityName, util.sysNameToValue, null);
Dabei
repräsentiert
die
util.sysNameToValue
die
gesetzten
Eigenschaften.
Die
Datenzugriffsschnittstelle muss diese durchlaufen und die Properties des neu erstellten
Eintrags setzen.
foreach (string key in util.sysNameToValue.Keys)
newObj.Properties[key].Value = util.sysNameToValue[key];
util.systemEntityName stellt das objectClass-Attribut des zu erzeugenden Eintrags dar, mit
dem die content-class und somit die Struktur des Eintrags festgelegt wird.
Bei der Angabe der Properties muss außerdem auf die Typen geachtet werden. Properties
können auch mehrere Werte besitzen, die entsprechend aufgelistet werden müssen.
5.4.3
Microsoft SQL Server
Der Zugriff auf die Microsoft Sql Datenbank verläuft analog zu diesem bei Exchange und
Active Directory. Die Ausnahme ist, dass die ObjectDAL-Klassen mit Hilfe von den
benutzerdefinierten Attributen für Datenbank-Constraints den Ablaufprozess zusätzlich
steuern können. Beispielsweise kann ein einziger Datensatz mit getObject zurückgegeben
werden, indem aus den Attributen der Eigenschaften festgelegt wird, welche Eigenschaft als
Primärschlüssel dienen kann. Es wird außerdem durch dem Herausfiltern der FremdschlüsselAttribute ermöglicht, komplexen Strukturen von der Datenbank anzufordern. Dafür muss aber
die Komponente erweitert werden, um die Tabellennamen bei der Angabe der Eigenschaften
in den Sql-Anfragen einzubeziehen.
89
Die Datenzugriffsschnittstelle benutzt die IDataReader-Schnittstelle von ADO.NET, um
Anfragen an den Server zu schicken. Sie sorgt für den Auf- und Abbau der Verbindung sowie
für die Übergabe der in der Konfiguration definierten Verbindungseigenschaften.
Die Sql-ObjectDAL-Klassen sorgen wie bei diesen für Exchange Server für den Aufbau der
Sql-Anfragen und für das richtige Format der Werten und Eigenschaftsnamen bei ihrer
Angabe in die Sql-Anweisungen. Im Gegensatz zu dem Exchange-Sql ist es hier möglich
auch Insert, Delete und Update Anweisungen durchzuführen. Diese werden auf die gleiche
Art und Weise wie die Search-Anweisung aufgebaut, indem die Anweisung in Teilen zerlegt
wird und jeder Teil mit den entsprechend formatierten Eigenschaftsnamen und Werten
aufgefüllt wird. Analog werden die Ergebnisse über Reflektion in Objekten gepackt, indem
bei dem Sql-Server für das Casting eine Fallunterscheidung nach dem OLEDB-DBNull Typ
erfolgen muss.
5.4.4
Systeminterne Objekt-Datenzugriffsschnittstelle
Das Common-Model (s. Kapitel 5.2.4) wird für das Zusammenfassen von Entitäten, die in
unterschiedlichsten Systemen definiert sein können, verwendet. Die Common-Modell
Entitäten können außerdem von anderen Entitäten abgeleitet werden und auch andere
benutzerdefinierten Entitäten erfassen. Die einzige Einschränkung ist, dass die Instanzen
dieser Entitäten zyklenfreie Objektgraphen darstellen müssen. Um die nichtfunktionale
Anforderung für einen automatisierten Prozessablauf zu erfüllen, muss sowohl eine
Fallunterscheidung nach den erfassten Entitäten in Betracht gezogen werden, als auch eine
Zuordnung
von
den
Modellen
zu
den
ObjektDALs
existieren.
Die
Klasse
CommonGenericDAL enthält eine Eigenschaft, die den Namen der Modell-Namensräume
ObjectDALs zuweist. Damit wird folgende Anfrage ermöglich:
((IDAL)_nsToDAL[ns]).updateObject(searchObject, updateObject);
Dabei stellt nsToDAL das vorhin genannte Mapping. Diese Eigenschaft wird von dem Dienst
über die Konfigurationskomponente gesetzt, der mit der Modell-Komponente verlinkt ist und
die Namensräume der Modelle kennt.
Der Prozessablauf wird über ein Beispiel für eine Update-Anfrage an das Integrationssystem,
mit der in Abbildung 17 definierten Common-Model-Entität erläutert wird.
Eine DALCommonModelUtil-Instanz liefert die gesetzten und nicht-gesetzten Eigenschaften
des benutzerdefinierten Informationsobjekts IBUser. Angenommen alle Eigenschaften in
90
diesem Objekt sind gesetzt. Das System muss also die Update-Anfrage an allen Enterprise
Systemen verteilen. Sie erhält als Parameter zwei IBUser-Objekten: der erste Parameter ist
mit den Daten für die Suchanfrage aufgefüllt (seachObject); der zweite enthält die
Änderungsdaten (updateObject). Es wird ohne weiteres angenommen, dass beide Objekte
über die gleichen gesetzten und nicht-gesetzten Eigenschaften verfügen.
Für den Typ des Informationsobjekts in dem searchObjekt wird über Reflektion geprüft, ob er
von einem unterschiedlichen von System.Object Typ abgeleitet ist und falls ja, ob ein von
seinen Basistypen in der Hierarchie eine Kollektion ist. Im Fall einer Kollektion muss die
Update-Anfrage an alle Teilnehmer dieser Kollektion rekursiv geschickt werden. Dieser Fall
tritt beim rekursiven Durchlauf des IBUser-Objektgraphs ein, wenn das Objekt
MessageCollection erreicht wird. Nun muss jede Nachricht in dieser Kollektion geändert
werden, also wird für jeden Teilnehmer der Kollektion in der searchObjekt rekursiv die
Update-Methode mit den searchObjekt- und updateObjekt-Teilnehmer der entsprechenden
Kollektionen aufgerufen.
Wenn keiner der Basistypen eine Kollektion darstellt, wird überprüft ob der Typ und der
Basistyp im gleichen Namensraum definiert sind, mit anderen Worten, ob der Basistyp im
CommonModel definiert ist. In diesem Fall wird eine Instanz des Basistyps des searchObjects
erzeugt und die Werte der Typ-Instanz für die gemeinsamen Eigenschaften werden in der
erzeugten Basistyp-Instanz gesetzt:
object parent = Activator.CreateInstance(type.BaseType);
DALCommonModelUtil.copyObjValAccordingTargetObjProps(searchObject ,parent);
Das gleiche wird für den updateObject gemacht und beide Objekte als Parameter des
rekursiven Aufrufs übergeben. Der Fall tritt bei CustomFolder ein, wo zwei Objekte vom Typ
Folder mit entsprechend Such- und Update-Eigenschaften an der update-Methode der
Exchange ObjectDAL übergeben werden.
Falls der Typ von keinem verschiedenen als System.Object Basistyp abgeleitet ist, wird die
Klasse
DALCommonModelUtil
instanziert,
um
die
gesetzten
und
nicht-gesetzten
Eigenschaften des searchObjekts zu erhalten. Für jede der gesetzten Eigenschaften wird die
update-Methode mit den Werten der Eigenschaft in searchObject und updateObject der
jenigen ObjectDAL,
die in der Zuordnung dem Namensraum des Eigenschafts-Typs
zugewiesen wird. Diese Anfrage kann auch rekursiv erfolgen, wenn der Typ der Eigenschaft
im
Common-Model
definiert
ist,
also
aus
dem
Common-Model-Namensraum
de.tum._in_.ib.common stammt.
91
5.5
Dienstentwurf
Die Dienste, die das Integrationssystems zur Verfügung stellen, werden abhängig von den
extrahierten Modellen entwickelt. Jeder Entität in diesen Modellen wird ein Dienst
zugeordnet. Er muss die Informationsobjekte in den integrierten Unternehmensanwendungen
übers Internet (s. Kapitel 2.1) zur Verfügung stellen können, also muss er die
Datenzugriffsschnittstellen verwenden, um auf die Systeme zugreifen zu können. Aus diesen
Überlegungen erweist sich der Data Access Object (DAO)-Pattern als angebracht, obwohl er
in den BluePrints [BPJEE] von J2EE in den unteren Ebenen der System-Architektur
eingestufft wird. Das wird ersichtlich nachdem im Folgenden der Pattern beschrieben wird (s.
Abbildung 24).
Abbildung 24: Data Access Object - Pattern [BPJ2EE]
Ein DAO-Objekt interagiert mit dem Client (BusinessObject), indem sie Informationsobjekte
(TransferObject) austauschen. Er greift auf die Informationssysteme zu, um die
Infromationsobjekte zur Verfügung stellen zu können und kapselt in dieser Hinsicht die
Funktionalitäten der Informationssysteme. Die DAOs müssen auf die Informationsobjekte
verweisen können, um sie mit den aus den Informationssystemen erhaltenen Daten in diesen
Objekten zu kapseln.
Die Dienste werden nun als DAOs betrachtet. Sie müssen also mit der Modell-Komponente
verlinkt sein und auf die Informationssysteme zufgreifen können. Von DAOs werden standard
Methoden erwartet, wie insertTO (insertTransferObject), deleteTO, updateTO etc. die im
konkreten Fall als Webmethoden offen gelegt werden müssen. In den BluePrints ist außerdem
auf die Möglichkeit hingewiesen, die DAOs mit entsprechenden Tools automatisch zu
erzeugen. Sie müssen Referenzen auf die TransferObjekte sowie in den Standardmethoden
Anweisungen
für
die
Weitergabe
der
Aufrufe
an
den
entsprechenden
92
Datenzugriffsschnittstellen beinhalten. Die Deklaration der get-Methode für die Entität User
sieht folgendermassen aus:
public User getUser(int userId){…}
Der User muss eindeutig über seine Id identifizierbar sein. Schlüsselattribute können wie in
Kapitel 5.4 beschrieben, in den Attribut-Deklarationen der Entitäten angegeben werden. Für
eine relationale Datenbank wurden diese Attribute erstellt und mit diesen die Entitäten der
Beispielsdatenbank Nortwind (s. Kapitel 5.3) ergänzt. In Active Directory ist der
ldapDisplayName auch ein Schlüsselattribut. Das Attribut in Exchange Server heißt href.
Die Erstellung der Anweisungen für die Weitergabe der Aufrufe in den DAOs-Methoden ist
insofern trivial, weil alle Datenzugriffskomponenten die vom System definierten Schnittstelle
IDAL implementieren müssen. Es bleibt nur die Zuweisung von Datenzugriffskomponenten
zu DAOs übrig das von im übernächsten Unterkapitel aufgeführten Service Locator
übernommen wird.
Um ein DAO als Webdienst offen zu legen, muss seine Klasse von der ASP.NET-Klasse
System.Web.Services.WebService abgeleitet sein. Die DAO-Methoden werden mit ASP.NETAttribute versehen, die sie als Webmethoden kennzeichnen. Weil hier ein so genannter
Contract-First-Ansatz stattgefunden hat, indem zuerst die Entitäten in XSD beschrieben
wurden und ihren Eigenschaften Serialisierungs-Elemente versehen sind, erfolgt die
Serialisierung der Modell-Entitäten
im Schema-Teil der SOAP-Nachrichten problemlos.
Wenn nicht anders in den Webdienst-Attributen angegeben wird, erfolgt die Kommunikation
über document/literal Einstellungen, mit denen die ASP.NET-Dienste WS-I-konform sind
und somit in heterogener Systemumgebung verwendet werden können.
Mit diesem Pattern wird auch ermöglicht die DAOs in einem anderen Framework zu
integrieren, indem sie mit anderen Attributen angereichert werden. Deswegen ist auch wichtig
die Trennung zwischen DAOs als Dienste und der Object-Datenzugriffsschnittstellen
festzulegen. Darüber hinaus enthalten alle DAOs eine Referenz auf die IDAL-Schnittstelle. Es
wird außerdem ermöglicht über die Konfiguration ein einziges DAO beispielsweise für eine
redundante, in mehreren Datenbanken enthaltene Entität zur Verfügung zu stellen. Es müssen
nur die entsprechenden Datenzugriffsschnittstellen zugewiesen werden. DAOs bieten als
Pattern die Möglichkeit, mehrere DAOs semantisch in einem so genannten Factory
zusammenzuführen. Das Factory-Pattern kann über einen zentralen Dienst abgefragt werden
und als Lokator für die anderen Dienste dienen kann.
93
Die benutzerdefinierten Entitäten im Common-Model repräsentieren die so genannten
CompositeObjects und stellen damit eine Facade für die einzelnen Dienste zur Verfügung.
Die Dienste und Modelle sind außerdem als Komponenten verfügbar und können über die
festgelegten Schnittstellen zur Entwicklung von komplexeren Orechestrierungen und
Geschäftsprozesse verwendet werden.
5.6
Konfigurationsschema und Dienstbeschreibung
Die Konfigurationskomponente dient der Auslagerung von Einstellungsinformationen aus den
Komponenten sowie die dynamische Anbindung von Komponenten, um eine möglichst lose
Kopplung zu erreichen. Dafür ist in dieser Arbeit ein Modell entworfen, das die Komponenten
im Integrationssystem widerspiegelt und diese in Beziehung setzt. Die Komponente wird
sowohl während der Extrahierung der Modelle aus den Unternehmensanwendungen benötigt,
als auch von den Diensten, um Datenzugriffsschnittstellen und Modell-Namensräume
zuzuweisen. In Abbildung 24 wird deutlich wie die Komponente die Struktur des Systems
festlegt. Es wird eine Konfigurationsdatei ausgelesen und daraus ein Objektmodell erzeugt.
Abbildung 25: Klassendigramm der Konfigurationskomponente
Die Dienste benutzen in diesem System die Konfigurationsdatei der Webanwendung
Web.config. Als Anwendung, z.B. für die Extrahierung der Metamodelle wird standartmäßig
94
die App.config-Datei von .NET verwendet. Beide stellen Xml-Dokumente dar. Das Laden des
Objektmodells wird automatisch ausgeführt, indem sich die Komponente in diesen Dateien
registriert. Das geschieht, indem in dem configSections-Element folgendes Unterelement
hinzugefügt wird:
<section
name="ibconfig"
type="de.tum._in_.ib.config.ConfigSectionHandler,
ConfigUtil, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
Über einen Callback wird beim Ausführen der Anwendung die Create-Methode der
ConfigSectionHandler-Klasse aufgerufen. Das wird von der .NET-System.ConfigurationKomponente ermöglicht. Ein Ausschnitt aus der Konfiguration ist in Anhang 8 angegeben.
Die Klassen in diesem Objektmodell sind mit Annotationen versehen, damit die automatische
Deserialisierung ermöglich wird.
Die Create-Methode erhält als Parameter einen Verweis auf das in section definierte Element
als XmlNode in DOM-Modell der Konfigurationsdatei. Das ibconfig-Element enthält als typeAttribut der Name der EntSystemLocator Klasse, die über diesen Wert dynamisch instanziirt
wird und anschließend mit dem Inhalt des ibconfig-Elements deserialisiert wird. Mit
folgender Definition eines Adapters in der Konfigurartion, die entsprechend in einem
EntSystemAdapter-Objekt deserialisiert wird ist die dynamische Instanziierung der
ObjectDALs ermöglicht. (s. auch Anhang 8).
<adapter location="de.tum._in_.ib.dal.ADSIDALGeneric, DALFactory">
<args>
<arg name="provider">LDAP</arg>
<arg name="dnsHostName">laptop.rumpi.homelinux.net</arg>
<arg name="container">CN=Users,DC=rumpi,DC=homelinux,DC=net</arg>
</args>
</adapter>
Die Argumente entsprechen dabei den Parametern einer Konstruktor, definiert in diesem Fall
in der de.tum._in_.ib.dal.ADSIDALGeneric-Klasse.
In Anhang 8 sind auch die Einstellungen für das Integrationssystems selbst angegeben. Wie
aus dem Ausschnitt zu erkenen ist, wird das Integrationssystem als jedes andere integrierte
Enterprise System angesehen, mit der Ausnahme, dass für die Datenzugriffsschnittstelle keine
Angaben gemacht werden. Diese Datenzugriffsschnittstelle muss über eine Zuordnung von
Modell-Namensräumen zu Datenzugriffsschnittstellen verfügen und wird daher vom ServiceLocator besonders behandelt.
Der Service-Locator (s. Abbildung 26) stellt eine Singleton-Registry dar, mit dem er so
genannte lookups für die Suche nach Diensten über einen bestimmten Identifikator
durchführt. Im Gegensatz zu einem Dependency Injection-Ansatz, bei dem die Referenz auf
95
die IDAL-Schnittstelle im DAO von dem Framework gesetzt wird, müssen die DAOs beim
Service Locator bei der Initialisierung das selbst machen.
EntSystemLocator systems = EntSystemLocator.getInstance();
EntSystem sys = systems.lookup("MsSql");
dal = (IDAL)sys.adapter.getDALInstance();
Der Lokator stellt für alle ihrer Aufrufer nur eine Instanz zur Verfügung. Mit dieser Instanz
erhält er bei der Initialisierung die gesuchte EnterpriseSystem-Instanz, die die
Unternehmensanwendung repräsentiert. Die EntSystemAdapter-Klasse ermöglicht dann eine
Instanz von dem entsprechenden ObjectDAL zu erhalten. Dabei führt das EntSystemAdapterObject die Instanziierung der ObjectDAL-Klasse mit den in der Konfiguration angegebenen
Parametern durch:
Type type = Type.GetType(this._location, true);
return Activator.CreateInstance(type, this.args);
Dabei ist die _location-Variable bei der Initialisierung der EnterpriseSystem-Klasse gesetzt
worden.
Abbildung 26: Sequenzdiagramm für den Service Locator
Die Weitergabe des Aufrufs in der DAO-Methode kann dann sehr einfach erfolgen:
96
[WebMethod]
public bool insertMessage(Message message)
{
return dal.insertObject(message);
}
5.7
Deployment
Im Deployment Diagramm in Abb. 27 werden die Abhängigkeiten und die Anforderungen an
die Komponenten deutlich, um eine erfolgreiche Integration und Deployment gewährleisten
zu können. Es müssen folgende Informationen und Komponenten gegeben sein, damit das
Deployment erfolgreich durchgeführt wird:
•
falls nicht vorhanden, eine Datenzugriffskomponente entwickeln, die die Schnittstelle
IDAL implementiert;
•
Es muss eine SchemaExtractor-Komponente entwickelt werden, die die Schnittstelle
ISchemaExtractor implementiert oder
o das Model als eine .xsd-Datei(Xml Schema-Format) angeben oder
o das Model als eine .xs-Datei(C#-Code) angeben;
•
Erweiterung der Konfigurationsdatei mit den Eigenschaften, benötigt für die
Initialisierung der Datenzugriffskomponente und der Diensten;
•
die Metamodell-Komponente de.tum._in_.ib.annotations mit den gemeinsamen für die
Modell-Instanzen (Informationsobjekten) Metadaten erweitern.
97
Abbildung 27: Deployment-Diagramm
Anschließend muss das System neu gestartet werden, damit die Konfigurationsänderungen
aufgenommen werden. Wie in der Abbildung zu sehen ist, ist die einzige Systemanforderung,
das Integrationssystem auf dem Betriebssystem Win2000/2003 zu installieren. Das ist
empfehlenswert, damit keine zusätzlichen Schnittstellen (ADSI) installiert werden müssen
oder IIS 6.0 installiert werden muss und dann .NET neu installiert werden muss.
Die engine-Komponente stellt eine ausführbare Komponente dar, die den DeploymentProzess realisiert. Für die erfolgreiche Integration eines Systems müssen die oben
aufgelisteten Anforderungen erfüllt sein. Abhängig von der Konfiguration werden die
Modelle entweder generiert oder von dem angegebenen Pfad ausgelesen. Dann werden sie
von der Code-Generator-Komponente in Code umgewandelt, mit den angegebenen
Erweiterungen angepasst, entsprechend auch mit den Annotations-Metadaten angereichert
und anschließend kompiliert. Die resultierende Assembly wird über die Konfiguration den
Diensten zur Verfügung gestellt. Die Dienste benutzen außerdem die DatenzugriffsebeneKomponenten die als Konnektoren für die zu integrierenden Systemen dienen. Wie im Kapitel
98
5.5 beschrieben stellen die Dienste Datenzugriffsobjekten dar und sie müssen für jede
beschriebene Entität in den Modellen erstellt werden. Der Prozess der Entwicklung ist nach
den in diesem Kapitel beschriebenen Bedingungen automatisierbar und kann im DeploymentProzessablauf integriert werden. Mit Hilfe von dem entwickelten Active DirectoryObjectDAL und einem IIS-Modell mit Entitäten wie z.B. VirtualFolder kann ein VirtualFolder als Webanwendung in IIS erstellt und anschließend die generierten Assemblies in
diesem kopiert werden. Dabei muss die Datenzugriffskomponente mit dem IIS-Provider (s.
Kapitel 3.2.4) initialisiert werden.
99
6
Use-Cases und Szenarien
6.1
Testfälle
Während der gesamten Entwicklungszeit wurden regression Tests durchgeführt. Diese
wurden in dem NUnit-Framework für .NET entwickelt, der ähnliche Struktur von den
Testklassen erfordert, wie das JUnit-Framework. Er verfügt außerdem über ein graphisches
Tool zur Verwaltung und Durchführung von Tests.
Wegen der Größe und Komplexität der Arbeit wurden weniger funktionale Tests, sondern viel
mehr komponente Tests entwickelt. Die Tests wurden nach den Diensten der Komponenten
strukturiert und mit Hilfe des Testreibers verwaltet. Alle sind mit den lokal installierten
Exchange, AD und Microsoft SQL Server durchgeführt. Dabei sind zuvor selbst preparierten
Daten oder solche die mit der Installation der Systemen zur Verfügung standen, z.B. die
Northwind-Beispielsdatenbank, verwendet. Das System wurde für Exchange Server im
Lehrstuhl SEBIS in realen Bedingungen getestet, wobei anzumerken ist, dass alle geforderten
Certifikate ohne Überprüfung anngenommen worden sind.
Die Beispiele in dieser Arbeit stammen aus den entwickelten Szenarien und Testfällen. Alle
Tests wurden sind beibehalten worden und über den Verlauf der Arbeit regelmäßig
ausgeführt.
6.2
Java-Client
Der Java-Client dient für die Valiedierung der Konzepte in Bezug auf die Webdienste. Das
Axis WSDL-to-Java-Tool (org.apache.axis.wsdl.WSDL2Java) wurde eingesetzt, um die
JavaBeans-Klassen und entsprechende Proxies zu erzeugen. Es wurden eine Web- und eine
Konsole-Testanwendung entwickelt, mit denen einfache Testfälle wie die Erzeugung eines
Benutzers in Active Directory oder die Abfrage nach den Daten eines Employees in
Microsoft Sql durchgeführt worden sind.
100
7
Im
Zusammenfassung
Rahmen
dieser
Arbeit
wurde
ein
Konzept
für
die
Integration
von
Unternehmensanwendungen entwickelt, mit dem ein Komponentenmodell von MetadatenModell-, Konnektoren-, Code-Generierung- und Dienst-Komponenten aufgestellt wird. Das
Konzept dient als Basis für den Entwurf und Implementierung des konkreten Falls der
Integration von Microsoft Exchange Server, Active Directory und Microsoft Sql Server.
Zunächst wurden die theoretischen Grundlagen in Zusammenhang mit dem fachlichen
Konzept analysiert und somit weitere spezifische Anforderungen an das System gestellt.
Danach wurden die Unternehmensanwendungen in Bezug auf den Einsatz von .NET als
Entwicklungsplattform
auf
Metadaten-Beschreibung
und
untersucht. Dabei wurden die internettauglichen Zugriffsschnittstellen ausgesucht, damit
keine Annahmen über die Verteilung der Anwendungen festgelegt werden.
Für jede der ausgesuchten Anwendungen wurden konforme zum Modell Komponenten
entwickelt. Für alle Anwendungen wurden entsprechende Komponenten für die Extrahierung
der Metadaten in XSD-Dokumenten realisiert. Die implementierte Code-GenerierungsKomponente wird für alle Metadaten-Beschreibungen eingesetzt und der generierte
Quellcode-Objektgraph mit Anpassungserweiterungen anwendungsspezifisch adaptiert.
Einige Erweiterungen stellen anwendungsunabhängige Anpassungen dar und werden bei der
Codegenerierung aus den Metadaten aller Anwendungen eingesetzt. Die so erstellten C#Klassen werden mit der Code-Generierungs-Komponente kompiliert und als Komponente
dem Integrationssystem zur Verfügung gestellt. Die Anpassungserweiterungen sind in diesem
Konzept austauschbar und die Komponente über vordefinierten Schnittstellen erweiterbar.
Des Weiteren wurden die Programmierschnittstellen und Kommunikationsprotokolle
behandelt. Dabei wurde das Konzept für Integrationsbroker umgesetzt, bei dem sie
Nachrichten aus Anwendungen entgegennehmen, diese prüfen und analysieren, wandeln die
auszutauschenden Dateiformate um und übertragen die resultierenden Nachrichten an die
Zielanwendungen.
Für jedes System wurde eine Datenzugriffsebene erstellt, die Zugriffpunkte für die darauf
aufbauenden Komponenten bietet und dabei eine einheitliche und benutzerfreundliche
Abstraktion der von ihnen adaptierten Programmierschnittstellen bildet. Für Exchange Server
wurde zusätzlich die Protokollimplementierung entwickelt.
101
Die auf diese Datenzugriffsebene aufbauenden Komponenten implementieren obligatorisch
die vom Integrationssystem vorgegebene Schnittstelle. Diese Komponenten wurden abhängig
von der von den Anwendungen definierten Syntax der Nachrichten entwickelt. Sie führen die
Serialisierung (Deserialisierung) von .NET-Typen (Nachrichten) in Nachrichten (.NETTypen) durch, die das für die Zielanwendung spezifische Format haben müssen. Die .NETTypen repräsentieren dabei die Informationsobjekte in den integrierten Anwendungen. Für
diese Komponenten sind sie aber nur .NET-Objekte, die sie reflektieren müssen, weil sie nicht
mit der Modell-Komponente verlinkt sind. Die Modell-Objekte sind mit benötigten
systemspezifischen Metadaten in Form von Annotationen angereichert. Teil davon bilden die
Metadaten in der Annotations-Komponente, welche als Metamodelle der extrahierten Modelle
aufgefasst werden. Die anderen werden über Reflektion ausgelesen und dienen der ObjektDatenzugriffskomponente für die Steuerung des Datenzugriffsprozesses. Beispielsweise
erhalten die ObjektDALs Objekte von den Diensten entgegen und reflektieren sie. Abhängig
von den gesetzten und nicht-gesetzten Eigenschaften eines Objekts und die aufgerufene
Methode generiert die ObjektDAL eine Nachricht, die an die darunter liegende
Datenzugriffschnittstelle übergeben wird. Eine weitere, für das System interne Komponente
behandelt die anwendungsübergreifenden Informationsobjekte, um über Reflektion und
abhängig von der Konfiguration automatisch die Anfragen an den für sie entwickelten ObjektDatenzugriffskomponenten weiterzuleiten und dann die Antworten zurück in den
ursprünglichen .NET-Objektmodel zu packen und an die Dienstkomponente zurückzugeben.
Als nächstes wurde ein Modell für die Klassen der Dienst-Komponente erstellt. Die Dienste
verwenden
Objekt-Datenzugriffsschnittstellen
und
die
Modell-Komponente,
um
Informationsobjekte einheitlich und an einer zentralen Stelle als Webdienste offen zu legen.
Sie stellen dabei die in der Schnittstelle der Objekt-Datenzugriffskomponente definierten
Funktionalitäten dar und wurden für ausgewählte Entitäten realisiert. Die automatisierte
Erzeugung der Dienste ist bis auf zusätzliche Anreicherung mit Metadaten der AnnotationsMetamodell-Komponente, mit Ausnahme für die Dienste für Microsoft Sql Server, nicht
gegeben (s. Kapitel 5.5).
Abschließend ist die Konfigurationskomponente entwickelt, von deren Zustand das Verhalten
aller anderen Komponenten betroffen wird. Sie bestimmen, welche Dienste mit welcher
Modell-Komponente und Objekt-Datenzugriffsschnittstelle interagieren müssen, welche
Objekt-Datenzugriffsschnittstelle welche Datenzugriffsebenen und mit welchen Einstellungen
verwenden sollen.
102
Für alle Komponenten während der gesamten Entwicklungszeit wurden Regression Tests
durchgeführt, die ihrerseits auch eine eigene Komponente bilden und nach dem Konzept von
Test-Units strukturiert sind. Zusätzlich wurde eine Java-Anwendung implementiert, die über
AXIS als Client in vordefinierten Use Cases teilgenommen hat. Aus den von den
Webdiensten
offen
gelegten
Modellen
wurden
die
Java-Beans-Klassen
und
die
entsprechenden Proxy-Klassen über das AXIS-Wsdl2Java-Tool erzeugt.
103
8
Ausblick
Das entwickelte System realisiert weitgehend das in dieser Arbeit aufgestellten Konzept. Ein
Integrationsbroker im Sinne von BizTalk Server verfügt aber über eine sehr große Menge von
Funktionalitäten, die als Vorgabe für die Erweiterung des entwickelten Systems dienen
können. Im Folgenden werden aber nur Konzepte und Vorstellungen erläutert, die beim
Entwurf des Systems als machbar kwalifiziert worden sind.
Dem System fehlt an Sicherheits- und Benutzerverwaltung, das aber als nichfunktionale
Anforderung verfasst wurde. Das Thema wurde nur wenig behandelt, weil dafür der Einsatz
von WS-Extensions nötig ist, die separat von ASP.NET installiert werden müssen und nach
Angaben von Microsoft in dem neuen Framework für verteilte Anwendungen - Indigo nicht
integrierbar sind.
Es findet auch keine Impersonisierung statt, damit die Benutzer die Dienste mit ihren rechten
ausführen können. Die Impersonisierung ist wegen des Kontextwechsels zeitaufwendig und
wird mit der Verwendung von Internetbasierten-Protkolle für den Zugriff auf die
Unternehmensanwendungen überflüssig.
Für die zukünftige Weiterentwicklung des Systems wird die Erweiterung der AnnotationsKomponente mit großem Vorrang eingestufft. Das Metamodell, das diese Komponente
repräsentiert, wird für die automatische Erzeugung der Dienste verwendet (s. Kapitel 5.5).
Der Vorgehensweise wird dabei mit dem bereits entwickelten Metamodell für realtionale
Datenbanken festgelegt. Die Metamodelle können außerdem zur Erweiterung der von den
Diensten unterstützten Schnittstellen dienen. Beispiel dafür ist z.B. Microsoft Sql Server nach
einer komplexen, zusammenhängenden Struktur anzufragen. Die Methode GetDependants
würde die vom System vorgegebenen Schnittstelle erweitern oder in einer spezifischen für
den Sql-Server deklariert sein, was zum nächsten Punkt führt. Es ist nur eine
Datenzugriffsschnittstelle den Diensten überlassen – IDAL, wobei weiteren Schnittstellen
diese
erweitern
können.
Die
Dienste
werden
dann
abhängig
von
zugewiesen
Datenzugriffskompomonente auf die entsprechenden Schnittstellen verweisen und deren
Methoden implementieren.
104
9
Literatur- und Quellenverzeichniss
Gedruckte Literatur
[SAMS04] Aier,
Stephan;
Shönherr,
Marten:
Enterprise
Application
Integration-
Flexibilisierung komplexer Unternehmensarchitekturen. Berlin: Gito Verlag,
2003.
[Ramm02] Rammer, Ingo: Advanced .NET Remoting. Berkely, CA.: Apress, 2002.
[FreJon]
Freeman, Adam; Jones, Allen: Microsoft-.NET-XML-Webdienste Schritt für
Schritt. Unterschleißheim: Microsoft Press, 2003.
[WeiGan]
Weisbrod, Markus; Ganser, Reiner: Microsoft Office SharePoint Portal Server
2003 - Das Handbuch. Unterschleißheim: Microsoft Press, 2004.
[Nath02]
Nathan, Adam: .NET and COM. The complete interoperability guide.
Indianapolis, Ind: SAMS, 2002.
[SCHW01] Schwichtenberg, Holger: COM-Komponenten-Handbuch. München: AddisonWesley Verlag, 2001.
[SCHW03] Schwichtenberg, Holger: Das Active Directory im Windows Server. Kissing:
INTEREST Verlag, 2003.
[MASFRE] Maslo, Andreas; Freiberger, Jörg M.: .NET-Framework Developer’s Guide.
München: Markt+Technik Verlag, 2002.
[KEMP04] Kemper, Alfons, Eickler, Andre: Datenbanksysteme. München: Oldenbourg,
2004.
[Lint00]
Linthicum, D.S.: Enterprise Application Integration. Boston: Addison-Wesley
Professional, 2000.
[Kell02]
Keller, W.: Enterprise Application Integration, Heidelberg: Dpunkt Verlag,
2002.
[BEIG97]
Beigl, Michael; Segor, Christian: Unter einem Hut. In: iX 8/1997. S. 122.
[HANI02]
Hanisch, Armin: Xml mit .Net. Addison-Wesley Verlag, 2002.
105
[STK02]
Snell, James; Tidwell Doug, Kulchenko, Pavel: Webservice-Programmierung
mit SOAP. O’Reilly Verlag, Juli, 2002.
[THUR05] Knecht-Thurmann, Stephanie: Small Business Server 2003. München: AddisonWesley Verlag, 2005.
[KOSE01] Kouti, Sakari; Seitsonen, Mika: Inside Active Directory: A System
Administrator's Guide. Addison Wesley Professional, Dezember 2001.
[CAMA04] Carius, Frank; Mantke Ingrid: MS Exchange Server 2003. München Wien: Carl
Hanser Verlag. 2004.
[SSRB00]
Schmidt, D.; Stal, M.; Rohnert, Hans; Buschmann, Frank: Pattern-oriented
Software Architecure. New York: John Wiley & Sons, Inc. 04, 2000.
[RUMBE]
Rumpe, Bernhard: Softaretechnik. Vorlesung.
Internetquellen / MSDN-, Anwendungsdokumentation
[MSDN01] Microsoft
Corporation:
MSDN
Library,
System.DirectoryServices-Namespace,
.Net-Klassenbibliothek,
2003:
ms-help://
MS.MSDNQTR.2003FEB.1031/cpref/html/frlrfSystemDirectoryServices.htm.
[ESPO01]
Esposito, Dino: Überlegungen zu OLE DB und .NET, MSDN Portal, 2004:
http://www.microsoft.com/germany/msdn/library/data/UeberlegungenZuOLED
BUndNET.mspx.
[MSDN02] Microsoft Corporation: MSDN Library, Programming ODBC SQL Server
Applications, 2002: http://msdn.microsoft.com/library/default.asp?url=/library
/en-us/odbcsql/od_6_0oview_8sc3.asp.
[MSDN03] Microsoft
Corporation:
MSDN
Library,
Microsoft SQL Server 7.0
Data Warehousing Framework, 2003, Microsoft Artikel-Nr.: 098-80704:
ms-help://MS.MSDNQTR.2003FEB.1031/dntaloc/html/
datawarefmwk.htm#datawarefmwk_oledb.
[MSDN04] Microsoft
Corporation:
MSDN
Library,
Visual C++-
Konzepte: Hinzufügen von Funktionalität, Grundlagen zu ODBC
ms-help://MS.MSDNQTR.2003FEB.1031/vccore/html/_core_odbc.htm
106
[MSDN05] Microsoft Corporation: MSDN Library, Übersicht über die OLE DBProgrammierung, 2003: ms-help://MS.MSDNQTR.2003FEB.1031/vccore/html/
vcconOverviewOLEDBProgramming.htm.
[MSDN06] Microsoft Corporation: MSDN Library, Win32 and COM Development, Data
Access and Storage, OLE DB Minimum Levels of Consumer and Provider
Functionality, 2005: http://msdn.microsoft.com/library/default.asp?url=/library/
en-us/dnoledb/html/oledbleveling2.asp.
[MSDN07] Microsoft Corporation: MSDN Library, .NET Framework, Programmieren mit
.NET Framework, Zugreifen auf Daten mit ADO.NET,
Übersicht über
ADO.NET. 2005: http://msdn.microsoft.com/library/deu/default.asp?url=/library
/DEU/cpguide/html/cpconadonetarchitecture.asp.
[MSDN08] Microsoft Corporation: MSDN Library, .NET Framework, OleDbTypeEnumeration:
ms-help://MS.MSDNQTR.2003FEB.1031/cpref/html/
frlrfSystemDataOleDbOleDbTypeClassTopic.htm.
[MSDN09] Microsoft Corporation: MSDN Library, Win32 and COM Development, Data
Access and Storage, Microsoft OLE DB, OLE DB Programmer’s Reference,
Introduction to OLE DB, Chapter 13: Data Types in OLE DB. 1998-2004:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/oledb/htm/
oledbdata_types_in_ole_db.asp
[MSDN10] Microsoft Corporation: MSDN Library, OLE DB Programmer's Reference,
Appendix B: Schema Rowsets. 1998-2004: http://msdn.microsoft.com/library
/default.asp?url=/library/en-us/oledb/htm/oledbschema_rowsets.asp
[MSDN11] Microsoft Corporation: MSDN Library, Übersicht über .NET Framework. 20012002:
ms-help://MS.MSDNQTR.2003FEB.1031/cpguide/html/
cpovrintroductiontonetframeworksdk.htm
[MSDN12] Platform SDK: Active Directory Service Interfaces, So What Is Active
Directory?:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/adsi/adsi/so_what_is_active_directory.asp
[MSDN13] Microsoft Corporation: .NET Framework Developer's Guide, XML Schema
Object Model (SOM). 2005: http://winfx.msdn.microsoft.com/library/default.asp
?url=/library/en-us/wd_xml/html/a897a599-ffd1-43f9-8807-e58c8a7194cd.asp
107
[MSDN14] Platform SDK: Active Directory Service Interfaces: ADSI Service Providers. 06.
2005:
http://msdn.microsoft.com/library/en-us/adsi/adsi/
adsi_system_providers.asp
[MSDN15] Platform SDK: Active
Directory
Schema:
Syntaxes.
July,
2005:
http://msdn.microsoft.com/library/en-us/adschema/adschema/syntaxes.asp
[MSDN16] Platform SDK: Active Directory Service Interfaces: LDAP Syntax Object. July,
2005: http://msdn.microsoft.com/library/en-us/adsi/adsi/ldap_syntax_object.asp
[MSDN17] Platform SDK: Active Directory Service Interfaces: ADSTYPEENUM. July,
2005: http://msdn.microsoft.com/library/en-us/adsi/adsi/adstypeenum.asp
[MSDN18] Platform SDK: Active Directory Service Interfaces: Data Type Mapping
between
Active
Directory
and
LDAP.
July,
2005:
data_type_mapping_between_active_directory_and_ldap.asp
[MSDN19] Platform SDK: Active Directory Service Interfaces: ADSI Simple Data Types.
July,
2005:
adsi_simple_data_types.asp
[MSDN20] .NET Framework-Klassenbibliothek:
Type-Klasse.
11,
2002:
ms-
help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1031/cpref/html/frlrfsystemty
peclasstopic.htm
[MSSQL1] Microsoft Corporation: Sql Server-Onlinedokumentation, Building SQL Server
Applications, OLE DB and Sql Server, Programming OLE DB SQL Server
Applications, Data Types(OLE DB). 1998-2000.
[309681]
Microsoft Corporation: Microsoft Knowledge Base, How To Retrieve Schema
Information by Using GetOleDbSchemaTable and Visual C# .NET. Article-ID:
Q309681, Juli 2004.
[154544]
Microsoft Corporation: Microsoft Knowledge Base, Article-ID: Q154544, 2004.
[SUNM02] Sun Microsystems: Core J2EE Patterns - Data Access Object, 2001-2002
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html.
108
[CDOSDK] Platform SDK: CDO for Windows 2000, CDO for Windows 2000 Object
Model. 2000-2001: ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1031
/cdosys/html/_cdosys_cdo_for_windows_2000_object_model.htm.
[W32001]
World
Wide
Web
Consortium:
Xml
Schema.
02.2001:
http://www.w3.org/2001/XMLSchema
[W32005]
World Wide Web Consortium: Extensible Markup Language (XML). 08.2005:
http://www.w3.org/XML/
[W32004]
World Wide Web Consortium: XML Information Set (Second Edition). 04.2004:
http://www.w3.org/TR/xml-infoset/
[W31999]
World Wide Web Consortium: XML Path Language (XPath). November, 1999:
http://www.w3.org/TR/xpath
[W30304]
World
Wide
Web
Consortium:
XML
Schema
API.
03.2004:
http://www.w3.org/Submission/2004/SUBM-xmlschema-api-20040309/xmlschema-api.html
[W30603]
World Wide Web Consortium: SOAP Version 1.2 Part 0: Primer. June, 2003:
http://www.w3.org/TR/soap12-part0/
[W30100]
World Wide Web Consortium: Datatypes for DTDs (DT4DTD) 1.0. Januar,
2000: http://www.w3.org/TR/dt4dtd
[W31199]
World Wide Web Consortium: XSL Transformations (XSLT) Version 1.0.
November, 1999. http://www.w3.org/TR/xslt
[CAZZ04] Cazzulino, Daniel: Code Generation in the .NET Framework Using XML
Schema.
May
2004:
http://msdn.microsoft.com/library/default.asp?url=
/library/en-us/dnxmlnet/html/xsdcodegen.asp
[SUN05]
Sun
Microsystems:
The
J2EE
1.4
Tutorial.
Juni
,2005
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html
[LOWE99] Lowe-Norris, Alistair G.: An ADSI Primer, Part 12: Extending the Schema.
12.1999:http://www.windowsitpro.com/Article/ArticleID/7666/7666.html?Ad=1
[ESDK01] Microsoft
Exchange
Server
2003
SDK:
Architecture->Programming
Technologies->CDO: ExOLEDB. März, 2004.
109
[ESDK02] Microsoft
Exchange
Server
2003
SDK:
SDK:
Technologies: WebDAV. März, 2004.
[ESDK03] Microsoft
Exchange
Server
2003
Technologies: Schema. März, 2004.
[MicSPS1] Microsoft SharePoint Portal Server 2001 SDK: Share Point Portal Server
Concepts. 2001: http://msdn.microsoft.com/library/default.asp?url=/library/enus/ spssdk/html/_introduction_to_basic_concepts.asp
[MicSPS2] Microsoft SharePoint Portal Server 2001 SDK: Document Management Object
Model Overview. 2001: http://msdn.microsoft.com/library/en-us/spssdk/html
/dmx_functional.gif
[MicSPS]
Microsoft SharePoint Portal Server SDK:Searching with XMLHTTP and
WebDAV. 2001: http://msdn.microsoft.com/library/default.asp?url=/library/enus/spssdk/html/_searching_with_xmlhttp_and_webdav.asp
[MicExc2] Microsoft Exchange 2000 SDK: Creating Folders (WebDAV). 12, 2004:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss
/_exch2k_creating_folders_http.asp
[BRM03]
Braun, Peter; Marschall, Frank: Transforming Object Oriented Models with
BOTL. 2003: http://www4.in.tum.de/~marschal/pub/entcs-bm02.pdf
[WEGN02] Wegner, Holm: Analyse und objektorientierter Entwurf eines integrierten
Portalsystems für das Wissensmanagement. Technische Universität HamburgHarburg, Dissertation, 2002.
[MCED03] Microsoft Corporation:
Application
Enterprise Development (General) Technical Articles:
Integration.
August,
1999:
ms-help://MS.VSCC.2003/
MS.MSDNQTR.2003FEB.1031/dnentdevgen/html/appint.htm
[AlMa02]
Altomare, C.; Malanowski, M.: Content Management Lösungen für KMU.
Fachhoch-schule beider Basel (FHBB), Departement Wirtschaft, Seminararbeit,
05.2002.
[SET04]
Software Engineering Today Conferences: Aktuell zur Software Engineering
Today
2004,
Software
Architecture
Today
Poster.
2004:
http://www.zuehlke.com/set-conference/
110
[BPJ2EE]
Core
J2EE
Patterns:
Blue
Prints:
Data
Access
Object:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
[BizT04]
Microsoft Corporation: White paper “Understanding BizTalk Server 2004”.
2004: http://go.microsoft.com/fwlink/?LinkId=21313
[IFAP]
© Microsoft Corporation: Microsoft Office Information Bridge Framework 1.0
Planning
and
Architecture
Guide:
http://www.microsoft.com/technet/
itsolutions/cits/iwp/ibf/pa/p_a_chap1.mspx
Requests for Comment (RFCs)
[RFC2251] Howes, T; Kille, S: Lightweight Directory Access Protocol: Dezember, 1997.
[RFC2256] Wahl, M.: A summary of the X.500(96) User Schema for use with LDAPv3:
Dezember, 1997.
[RFC2518] IETF WEBDAV Working Group: HTTP Extensions for Distributed Authoring –
WEBDAV. February 1999.
111
Anhang
1. Common Model
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cm="http://da.matthes.in.tum.de/commonModel"
xmlns:cc="urn:content-classes:"
xmlns:lt="http://da.matthes.in.tum.de/ldapSchema"
xmlns:sql="http://da.matthes.in.tum.de/sqlDBSchema"
targetNamespace="http://da.matthes.in.tum.de/commonModel"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="ttp://da.matthes.in.tum.de/sqlDBSchema"
schemaLocation="./mssqlSchema.xsd"/>
<xs:import namespace="ttp://da.matthes.in.tum.de/ldapSchema"
schemaLocation="./ adSchema.xsd"/>
<xs:import namespace="urn:content-classes:"
schemaLocation="./xmlns_cc.xsd"/>
<xs:complexType name="messages">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element ref="cc:message"/>
</xs:sequence>
</xs:complexType>
<xs:element name="messages" type="cm:messages"/>
<xs:element name="IBUser">
<xs:complexType>
<xs:sequence>
<xs:element ref="lt:user"/>
<xs:element ref="sql:Employees"/>
<xs:element ref="cm:messages"/>
<xs:element ref="cm:CustomFolder"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CustomFolder">
<xs:complexType>
<xs:complexContent>
<xs:extension base="cc:mailfolder">
<xs:sequence>
<xs:element ref="cc:message"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="cc:document"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexType>
</xs:element>
</xs:schema>
112
2. Vordefinierte Ordner im Postfach eines Exchange Empfängers
Verzeichnis
URL
Calendar
http://server.example.com/exchange/UserAlias/Calendar
Contacts
http://server.example.com/exchange/UserAlias/Contacts
Drafts
http://server.example.com/exchange/UserAlias/Drafts
Inbox
http://server.example.com/exchange/UserAlias/Inbox
Journal
http://server.example.com/exchange/UserAlias/Journal
Notes
http://server.example.com/exchange/UserAlias/Notes
SentItems
http://server.example.com/exchange/UserAlias/Sent%20Items
Outbox
http://server.example.com/exchange/UserAlias/Outbox
Tasks
http://server.example.com/exchange/UserAlias/Tasks
3. Metamodell-Transformationen
IBUser
Exch.Employee
fname:string
fname:string
sname:string
sname:string
height:int
height:int
AD.User
name:string
height:float
Information Bridge:
Common-Model
Metamodelle der Unternehmensanwendungen
Exch.Employee
fname:f
sname:s
IBUser
height=h
fname=f
sname:s
height:h
AD.User
name:s°“,“°f
height:h*3,3
Transformationsregel
113
Exch.Employee
fname:John
IBUser
sname:Doe
fname=John
height:174cm
sname=Doe
height=174cm
AD.User
name=Doe,John
height=5,7ft
Transformation
4. BizTalk Mapper
5. BizTalk Adapter
SOAP-Adapter: Ermöglicht das Senden und Empfangen von Nachrichten mithilfe von
SOAP über HTTP. Da SOAP das wichtigste Protokoll für Webdienste ist, verleiht
dieser Adapter BizTalk Server 2004 die Fähigkeit, mit Webdiensten zu interagieren.
Zur Identifizierung der Sende- und Empfangssysteme werden URLs verwendet.
Adapter für BizTalk-Message Queuing: Ermöglicht das Senden und Empfangen von
Nachrichten mithilfe von BizTalk-Message Queuing (MSMQT). BizTalk-Message
Queuing ist eine Implementierung des Microsoft Message Queuing-Protokolls
(MSMQ). Damit ist es möglich, MSMQ-Nachrichten aus der MessageBox-Datenbank
zu empfangen bzw. an diese zu senden. Es stellt zwar keinen Ersatz für MSMQ dar,
bildet jedoch eine effiziente Möglichkeit zur Verwendung des Transports für MSMQ
mit BizTalk Server.
114
Dateiadapter: Ermöglicht das Lesen von und das Schreiben in Dateien im Microsoft
Windows®-Dateisystem. Da die Anwendungen in einem Geschäftsprozess oft lokal
oder über ein Netzwerk auf das gleiche Dateisystem zugreifen, kann der Austausch
von Nachrichten über Dateien eine zweckmäßige Option sein.
HTTP-Adapter. Ermöglicht das Senden und Empfangen von Daten mithilfe von HTTP.
Das BizTalk Server 2004-Modul macht einen oder mehrere URLs zugänglich, damit
andere Anwendungen Daten dorthin senden können, und kann diesen Adapter zum
Senden von Daten an andere URLs verwenden.
SMTP-Adapter. Ermöglicht das Senden von Nachrichten mithilfe von Simple Mail
Transfer Protocol (SMTP). Zur Identifizierung der Teilnehmer werden Standard-EMail-Adressen verwendet.
SQL-Adapter. Ermöglicht das Lesen und Schreiben von Daten aus einer bzw. in eine
Datenbank von Microsoft SQL Server™.
Basis-EDI-Adapter. Ermöglicht das Senden und Empfangen von Nachrichten mithilfe der
Standards des American National Standards Institute (ANSI) X-12 und Electronic
Data Interchange for Administration, Commerce, and Trade (EDIFACT).
FTP-Adapter. Ermöglicht den Dateiaustausch zwischen BizTalk- und FTP-Servern.
6. Model-Namensräume
115
7. System-Namensräume
8. Konfigurations-Ausschnitt
<configuration>
<ibconfig type="de.tum._in_.ib.config.EntSystemLocator, ConfigUtil"
metamodelAssembly="ib.metamodel.dll">
<ibsystems>
<entSystem name="Exchange" location="RUMPI">

<schema targetPath="../../../../schemes/exchange/"
schemaExtractor="de.tum._in_.ib.schemaExtractor.SchemaExtractorExchan
ge, schemaExtractor">
<args>
<arg name="locationOfExchangeSchemaFolder">
../../../../../schemes/exchange/schema/</arg>
<arg>../../../../schemes/exchange/xdrExchangeAllInOne.xdr</arg>
<arg name="simpleTypesSchemaLocation">
../../../../schemes/exchange/xdr2xsd.xml</arg>
</args>
</schema>
<codeGenerator classNamespace="de.tum._in_.ib.metamodels.exchange"
codeGeneratorDefExt="../../../../schemes/codeGeneratorExtensions.xsd"
targetPath="../../../../schemes/exchange/"/>
116
<adapter location="de.tum._in_.ib.dal.ExchangeDALGeneric,
DALFactory">
<args>
<arg name="dnsHostName">http://laptop/</arg>
</args>
</adapter>
</entSystem>
………
………
<entSystem name="IB">
<schema schemaLocation="../../../../schemes/commonModel.xsd"/>
<codeGenerator classNamespace="de.tum._in_.ib.metamodels.common"
codeGeneratorDefExt="../../../../schemes/codeGeneratorExtensions.xsd
" targetPath="../../../../schemes/"/>
</entSystem>
</ibsystems>
</ibconfig>
</configuration>
117

Die Entwicklung einer einheitliche - sebis

Transcrição

Documentos relacionados

Netzwerktechnik CHS Villach Mag. Rainer Swatek Dauer: 2

IXI-UMS und der Dienst Fax

visionapp Platform Management Suite Most Recently Used List

Bericht über eine Migration von NT SBS auf Windows 2003

IT - May Computer

Datenblatt CDxPress 2015

DynamIk Für IHr UntErnEHmEn.

AutoSketch 9

Webhosting - easyWEB4u

Anwenderbericht Altenheim Emmaus