Entwicklung eines verteilten Kundeninformationssystems

Fachhochschule Darmstadt

Entwicklung eines

verteilten Kundeninformationssystems

Band I - Extranet und Applikationsserver

Darmstadt, im März 2000

"Sage nicht immer, was Du weißt, aber wisse immer, was Du sagst."

Claudius, Matthias, deut. Dichter (1740 - 1815)

Eidesstattliche Erklärung

Eidesstattliche Erklärung

Ich, David Ebers, erkläre an Eides statt, dass ich die vorliegende Diplomarbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benutzt und die den benutzten Quellen wörtliche oder inhaltlich entnommene Stellen als solche kenntlich gemacht habe.

Vorwort

Vorwort

Im September 1996 begann ich mein Studium der Informatik an der Fachhochschule in Darmstadt. Seitdem beschäftige ich mich intensiv mit den Konzepten und Methoden der modernen Anwendungsentwicklung. Besonders wertvoll für mich sind dabei die Erfahrungen während meiner Arbeit im "Forschungslabor für verteilte und komponentenbasierte Anwendungssysteme" (VAS) der Fachhochschule ¹ . Hier erarbeitete ich mir die Grundlagen der komponentenbasierten Softwareentwicklung.

Mit der vorliegenden Arbeit schließe ich mein Studium ab. Ich blicke zurück auf einen sehr interessanten, vielseitigen und lehrreichen Lebensabschnitt und schaue in eine Zukunft, welche mir die Möglichkeit bieten wird, die Herausforderungen neuer Aufgaben in der Informatik anzunehmen und das erlernte Wissen in Projekten anzuwenden sowie zielorientiert auszubauen.

Ich bin mir bewusst, mit diesem Schritt Verantwortung zu übernehmen. Mit dieser Arbeit möchte ich zeigen, dass ich in der Lage bin, eine Problemstellung wissenschaftlich zu bearbeiten und praktisch zu lösen.

Gern möchte ich Herrn Prof. Dr. Günter Turetschek und Herrn Prof. Dr. Udo Bleimann für die Betreuung dieser Arbeit danken.

Dank spreche ich aber auch dem gesamten VAS-Team aus. Thomas Hock, Volker Münch, Holger Hofmann und Matthias Amrhein möchte ich namentlich nennen und mich damit für die gute Zusammenarbeit und fachliche Unterstützung im VAS-Labor bedanken.

Darüber hinaus verdient die Firma Samsung Semiconductor GmbH, bei der ich diese Diplomarbeit durchführte, meinen Dank. Dazu zähle ich insbesondere Herrn Peter Färber, Herrn Carsten Ribbe und Herrn Christoph Hermans, die immer bereit waren, mir bei der Beantwortung fachlicher Fragen zu helfen.

Unterstützend durch konstruktive Kritik, neue Ideen und Lösungsvorschläge haben alle zum Gelingen dieser Arbeit beigetragen.

Nicht zuletzt danke ich meinen Eltern, die es mir ermöglichten, mich während des Studiums frei von Sorgen ganz auf meine Ausbildung zu konzentrieren.

Einleitung

Das erste Kapitel stellt die Aufgabenstellung bei Samsung und das

methodische Vorgehen - Konzepte und Methoden der Informatik - für die Erarbeitung einer Lösung vor.

Die Firma Samsung Semiconductor GmbH mit Sitz in Schwalbach stellt

Samsungs Vertriebszentrale für den europäischen Markt dar. Vertrieben werden in Korea produzierte Halbleiterprodukte und TFT-Panels.

Computerhersteller wie IBM, Siemens, DELL oder Hewlett Packard aber auch Firmen der Telekommunikationsbranche wie Alcatel, Ericson und Nokia zählen

zu den Geschäftskunden von Samsung.

Das Marktsegment der Halbleiterprodukte ist hart umkämpft. Ziel ist es Kunden

zu binden, ihnen nicht nur qualitativ hochwertige Produkte, sondern darüber hinaus auch weitreichende Serviceleistungen anzubieten.

Skizziert man den Prozess einer Auftragsabwicklung von der Bestellung bis hin zur Auslieferung der Waren und der Fakturierung, so existiert eine Vielzahl von Informationen, die für den Kunden interessant sind:

Welchen Status hat mein Auftrag?

Wann erhalte ich die nächste Lieferung?

Existieren offene, unbezahlte Rechnungen?

An wen kann ich mich bei Qualitätsmängeln wenden?

Bisher wurden diese Informationen telefonisch, per Fax oder Email bearbeitet. Diese Formen von Serviceleistungen binden Personal und damit teure Arbeitszeit. Zudem treten eine Reihe bekannter Probleme auf. Nicht selten ist der persönliche Ansprechpartner des Kunden vorübergehend telefonisch nicht zu erreichen und seine Vertretung ist nur unzureichend informiert. Außerdem kann es vorkommen, dass eine gesendete Faxnachricht nur schwer zu entziffern ist. Missverständnisse erfordern die telefonische Rücksprache etc.

Einleitung

So entstand die Idee eines webbasierten Kundeninformationssystems. Damit kann der Kunde selbst eine Vielzahl von bereitgestellten Informationen über das Internet abfragen. Diese Informationen sind dann zu jeder Zeit verfügbar, immer aktuell und können kundenspezifisch präsentiert werden.

Abgeleitet aus den Geschäftsprozessen bei Samsung ergeben sich vier Selfservice-Szenarien:

Auftragsstatus

Lieferstatus

Offene Rechnungen

Reklamationen

Objektorientiert

Anwendungsprogramme modellieren einen Ausschnitt unseres realen Umfeldes. Die Bestrebung, diesen Ausschnitt so exakt und realitätsnah wie möglich abzubilden, führte die Informatik von einer funktional strukturierten Sicht (ablauforientiert) hin zum Paradigma der Objektorientierung.

Das Kernkonzept der Objektorientierung sind Klassen, eine Abbildung realer Objekte unserer Umgebung in die Welt der Computer. Sie kapseln Attribute und Methoden und beschreiben damit die Eigenschaften und das Verhalten jener Objekte. Klassen sind als Schablonen für die Instanziierung individueller Objektinstanzen zu sehen. Auf dieser Abstraktionsebene werden Daten und Funktionen zu einem Element zusammengefasst. Objektorientierter Quellcode ist durch Übersichtlichkeit und gute Lesbarkeit gekennzeichnet und auf Quellcode-Ebene wiederverwendbar. Wird das Klassendesign überarbeitet und beispielsweise der Algorithmus zur Implementierung einer Methode verbessert, profitiert automatisch jede Anwendung, die diese Klasse benutzt, von dieser Optimierung.

Einleitung

Komponentenbasiert

Der dynamische Prozess der Anpassung von Geschäftsprozessen an eine neue Marktsituation spiegelt sich auch in Anforderungen an Anwendungsprogramme wider. Software muss flexibel, anpassungsfähig und erweiterbar sein. Komponentenbasierte Systeme bestehen im Gegensatz zu monolithischen Anwendungen aus einer Vielzahl einzelner Komponenten, die nahtlos zusammenwirken. Jede dieser Komponenten erfüllt eine bestimmte Aufgabe. Sie kann unabhängig von allen anderen Komponenten des Systems modifiziert, durch eine leistungsfähigere ersetzt oder in anderen Projekten direkt wiederverwendet werden. Mit diesen Möglichkeiten adressieren komponentenbasierte Systeme sehr genau die oben genannten Anforderungen.

N-Tier-Architektur

Um eine klare Trennung von Präsentations-, Anwendungs-, und Datenschicht zu erreichen, werden Anwendungssysteme auf der Basis von N-Tier-Architekturen erstellt. Die Anwendungslogik ist somit, verglichen mit Two-Tier-Architekturen, nicht redundant über alle Client-Applikationen verteilt, sondern kann an zentraler Stelle gepflegt und erweitert werden.

Applikationsserver

Die hohe Komplexität verteilter Anwendungen erfordert eine leistungsfähige Infrastruktur für die Objektkommunikation, die Thread-Verwaltung und das

Skalierungsmechanismen. Um sich bei der Entwicklung von verteilten Anwendungen ganz auf die Implementierung von Anwendungslogik konzentrieren zu können, werden für diese Aufgaben Applikationsserver eingesetzt.

Internetbasiert

Zunehmend etabliert sich das Internet als Plattform für verteilte Anwendungen. Als globales Netz und plattformübergreifende Lösung eignet es sich hervorragend bei der Umsetzung von Anwendungen zur Erschließung neuer Märkte und alternativer Vertriebswege. Auf der Basis von Web-Browsern als Clients werden server-seitige Applikationen entwickelt, die Geschäftsprozesse von Unternehmen an das Internet anknüpfen.

Einleitung

1.3 Ziel der Diplomarbeit

In dieser Arbeit möchte ich die beschriebene Aufgabenstellung eines Kundeninformationssystems aufgreifen und die vorgestellten Szenarien nach den neuesten Erkenntnissen der Informatik prototypisch realisieren.

Dabei erfolgt der Zugriff auf die Informationen über ein Web-Frontend auf ein Set von Komponenten, welche die Geschäftslogik implementieren und in einem

Applikationsserver ausgeführt werden.

Den Schwerpunkt bildet eine Realisierung mit Microsofts Produkten und Technologien. Der entwickelten Lösung soll anschließend eine Java-Implementierung gegenübergestellt werden.

Die Erkenntnisse der Realisierung, das Aufzeigen von Möglichkeiten und Grenzen, die Bewertung ausgewählter Dienste eines Applikationsservers und die Gegenüberstellung der beiden Technologien bilden das Ergebnis der Arbeit.

Der externe Zugriff auf die Daten des SAP R/3 Systems als primäre Informationsquelle für die Applikation wird im Band II dieser Arbeit, bearbeitet durch Herrn Oliver Kurt, ausführlich dargestellt. Die Arbeit trägt den Untertitel: „Applikationsserver und Wrapping von Legacy -Systemen“.

Zum Verständnis der Arbeit setze ich voraus, dass der Leser mit der Programmiersprache Visual Basic und den Grundlagen von Komponentenmodellen vertraut ist.

Einleitung

1.4 Kapitelübersicht

Kapitel 1 beschreibt die Entwicklung verteilter Anwendungen mit Microsoft Visual Basic. Es zeigt Möglichkeiten und Grenzen bei der Umsetzung der COM-Spezifikation auf.

Kapitel 2 untersucht die Dienste von Applikationsservern hinsichtlich

Objektmanagement und Skalierbarkeit verteilter webbasierter Anwendungen.

Kapitel 3 stellt die Entwicklung von Active Server Pages (ASPs) im Vergleich zu Java Server Pages (JSPs) und damit die Anbindung eines Komponentensets an das Internet dar.

Kapitel 4 beschreibt die Lösungsansätze und die programmtechnische Umsetzung des Kundeninformationssystems.

Verteilte Anwendungen mit Visual Basic

2 Verteilte Anwendungen mit Visual Basic

Das folgende Kapitel stellt die Programmiersprache Microsoft Visual Basic und Microsofts Komponentenmodell (Component Object Model, COM) vor. Es wird untersucht, inwieweit Visual Basic die COM-Spezifikation unterstützt.

2.1 Microsoft Visual Basic

Visual Basic ist eine Programmiersprache, die einfach zu erlernen ist und mit der man sehr schnell Anwendungen entwickeln kann. Dazu versteckt Visual Basic eine Menge Details und viel Komplexität vor dem Programmierer. Es ist verständlich, dass damit Flexibilität und Leistungsfähigkeit verloren gehen. Trotz dieser Einschränkungen hat sich die Sprache für die Entwicklung von formularbasierten Desktop- und Datenbankapplikationen durchgesetzt.

„Microsoft Visual Basic makes it easy to write 95 percent of your application, but when reach that last 5 percent [...] it seems to be fighting you every step of the way.“ [McKi97, Seite xix]

Bisher hauptsächlich für die Entwicklung von grafischen Benutzeroberflächen eingesetzt verfolgt Microsoft nun das Ziel, die Sprache auch als Werkzeug für die Entwicklung server-seitiger Komponenten zu etablieren.

„We want to bring the same level of productivity to creating middle-tier business logic that Visual Basic® brought to forms-based development.“ [Micr00c]

Visual Basic ist eine objektorientierte Programmiersprache, obgleich sie nicht alle Merkmale der Objektorientierung unterstützt. Dazu zählen beispielsweise die Implementierungsvererbung und das Überladen von Konstruktoren einer Klasse. Dies führt bis heute zu fehlender Akzeptanz bei der Entwicklung von

Komponenten, obwohl Visual Basic dies bereits seit der Version 4.0 unterstützt.

„[...] the lack of object-oriented language features has limited its acceptance for creating middle-tier components.“ [Micr00c]

Verteilte Anwendungen mit Visual Basic

2.2 Microsofts Komponentenmodell

Über viele Jahre hinweg entwickelte Microsoft ein Komponentenmodell (Component Object Modell, COM), welches eine Welt beschreibt, in der Anwendungen aus verschiedenen, voneinander unabhängiger Komponenten bestehen, die nahtlos zusammenwirken.

1993 veröffentlichte Microsoft die COM-Spezifikation ¹ , welche ganz genau beschreibt, wie diese Komponenten als Teil einer verteilten Anwendung aufgebaut sind. Die COM-Laufzeitumgebung, eine Middleware-Technologie, ermöglicht die Kommunikation und damit das Zusammenwirken der einzelnen Komponenten auch über Prozessgrenzen hinweg.

Abbildung 2.1: Kommunikation von Client und Komponenten via COM

Welche Vorteile kann dieses neue Paradigma der Softwareentwicklung bieten?

Das Component Object Model ist ein Binärstandard und eröffnet damit zwei ganz neue Perspektiven. Zum Einen ist die Wiederverwendung von Software damit unabhängig vom Quellcode. Das bedeutet, neue Systeme können modular aus bereits existierenden Komponenten zusammengesetzt werden, ohne diese neu zu kompilieren. Andererseits wird damit aber auch Sprachunabhängigkeit erreicht. Es ist nun möglich, die Vorteile (Produktivität, Flexibilität, Performance) verschiedener COM-fähiger Programmiersprachen wie C/C++, Visual Basic oder Delphi bei der Entwicklung verteilter Anwendungen zu nutzen und in einem Projekt zu integrieren.

Verteilte Anwendungen mit Visual Basic

Darüber hinaus beschränkt sich die Anpassung und Erweiterung eines komponentenbasierten Systems auf einzelne Komponenten, die unabhängig voneinander modifiziert oder ausgetauscht werden können. Die Wartung und Pflege von Software wird dadurch einfacher, schneller und kostengünstiger.

Die COM-Laufzeitumgebung bietet eine prozessübergreifende Kommunikation zwischen Komponenten und kapselt somit komplexe Interprozess-Kommunikationsmechanismen; Ein COM-Merkmal, welches auch als örtliche Transparenz bezeichnet wird, da sich aus Sicht des Client-Entwicklers prozessinterne und prozessexterne Server gleichermaßen verhalten.

„Nie war das entwickeln verteilter Anwendungen so einfach“. [Patt99a, Seite 2]

2.3 Komponentenentwicklung mit Visual Basic

Die genannten Vorteile der Anwendungsentwicklung mit Visual Basic sprechen deutlich dafür, Visual Basic für die Implementierung von Geschäftslogik einzusetzen. Dennoch möchte man auf die Vorteile komponentenbasierter Systeme nicht verzichten.

Kann man diese beiden Aspekte kombinieren? Ist es möglich, Visual Basic auch für die Entwicklung verteilter Anwendungen einzusetzen?

Um diese Fragen zu klären, werden im Folgenden diejenigen Aspekte der COM-Spezifikation aufgegriffen, die sich bei der Umsetzung mit Visual Basic als problematisch erweisen könnten. Es werden Möglichkeiten aber auch Grenzen aufgezeigt, die dabei helfen zu entscheiden, in welchen Bereichen der Entwicklung es sich empfiehlt, die Sprache Visual Basic einzusetzen.

Schnittstellenbasierte Programmierung

Ein Kernkonzept von COM stellt die schnittstellenbasierte Programmierung dar. Hierbei wird die Schnittstelle (Interface) als Zugriff auf die Funktionen einer Komponente von ihrer konkreten Implementierung getrennt. Dadurch werden Abhängigkeiten einer Client-Applikation von der konkreten Klassendefinition der Server-Komponente vermieden.

Verteilte Anwendungen mit Visual Basic

- PosX

- PosY + Betrag

abstrakt konret definiert Aufrufsyntax implementiert die Schnittstelle

Abbildung 2.2: Aufbau eines COM-Servers

Eine Schnittstelle ist somit eine abstrakte Klasse, das heißt sie enthält nur die Methodendeklarationen ohne eine konkrete Implementierung. „Dies bedeutet, dass eine Schnittstelle von einer oder mehreren Klassen implementiert werden muss, um einen Nutzen zu erbringen“ [Patt99a, Seite 27]. Eine Schnittstelle muss folglich durch mindestens eine Klasse, die als CoKlasse bezeichnet wird, implementiert werden. Beide zusammen bilden eine Komponente. Durch den Charakter abstrakter Klassen ist sichergestellt, dass die Implementierung aller exportierten Funktionen vollständig ist und der Deklaration entspricht. COM verlangt, dass jede Komponente mindestens eine Schnittstelle implementiert.

Die Schnittstellen bilden einen Vertrag zwischen Client und Server und werden im ersten Entwicklungsschritt einer Komponente definiert.

Mehrere solcher Komponenten werden in einem COM-Server zusammen-

Standardisierte COM-Schnittstellen

Damit eine Client-Applikation überhaupt Services einer COM-Komponente nutzen kann, müssen bestimmte einheitliche Schnittstellen implementiert sein, die es ermöglichen, die Komponente zu instanziieren, ihren Lebenszyklus zu verwalten und abzufragen, welche Schnittstellen die Komponente unterstützt.

Jede einzelne COM-Komponente muss daher die beiden Standardschnittstellen IClassFactory und IUnknown implementieren.

Verteilte Anwendungen mit Visual Basic

„IUnknown beschreibt das Grundverhalten eines COM-Objektes, im Gegensatz zum domänenspezifischen Verhalten einer benutzerdefinierten Schnittstelle.“ [Patt99a, Seite 60]

Diese Basisdienste beinhalten eindeutig definierte Aufgaben, welche nicht für

jede Komponente neu realisiert werden müssen. C++ bietet daher die

Möglichkeit, diese Standardfunktionalität von Template-Klassen aus der Active Template Library (ATL) zu erben. Visual Basic implementiert die Methoden dieser Standardschnittstellen sogar vollständig automatisch.

Microsoft Visual Basic vereinfacht und automatisiert die Erstellung von COM-

Zwar kann man sich nun bei der Erstellung von COM-Komponenten ganz auf die Implementierung der benutzerdefinierten Schnittstellen konzentrieren, es ist jedoch nicht mehr möglich, die Objektaktivierung anzupassen. Es wäre denkbar, eine Client-Anfrage zu bearbeiten, indem ein existierendes Objekt lokalisiert wird, anstatt ein neues Objekt zu instanziieren. Solch eine umfassende Verwendung der ClassFactory ist daher nur unter C++ möglich, vgl. [Patt99a, Seite 55]. Für die Bewertung dieser Aussage ist jedoch zu beachten, dass Applikationsserver, welche eine Infrastruktur für das Pooling von Objekten bereitstellen, die standardisierte Implementierung der Class-Factory voraussetzen.

Benutzerdefinierte COM-Schnittstellen

Um die Funktionalität der Geschäftslogik einer Komponente nach außen zu exportieren, können für diese Komponente zusätzlich zu den standardisierten Schnittstellen benutzerdefinierte Schnittstellen veröffentlicht werden.

Damit die Sprachunabhängigkeit bei der Definition von Schnittstellen gewährleistet ist, muss COM eine universelle Möglichkeit bieten, die Informationen über die integrierte Schnittstelle einer Komponente zu veröffentlichen. Nur dann kann diese Schnittstelle von jeder COM-fähigen Sprache implementiert oder verwendet werden. Die Schnittstellen-Definitions-Sprache (Interface Definition Language, IDL) ist die offizielle Sprache zur

Definition von Schnittstellen, sie wurde von der Object Management Group

(OMG) spezifiziert. Microsoft erweiterte diese Sprache zur Beschreibung von COM-Schnittstellen. Man spricht in diesem Zusammenhang von Microsoft IDL (MIDL).

Verteilte Anwendungen mit Visual Basic

Abbildung 2.3: Sprachunabhängige und sprachspezifische Schnittstellenbeschreibung

Zur Implementierung oder Verwendung einer IDL-Quelldatei wird die Schnittstellendefinition in ein sprachspezifisches Format übersetzt. Diese Aufgabe übernehmen IDL-Compiler, die oft auch in die Entwicklungsumgebung integriert sind. Der Microsoft IDL-Compiler (midl.exe) übersetzt die IDL-Quelldatei und erzeugt die spezifischen C++ Header-Dateien bzw. eine Typenbibliothek (Typelibrary, TLB) als binäres Abbild der IDL-Definition.

Anders als in C++ oder Java müssen Schnittstellen in Visual Basic nicht unter Verwendung von IDL definiert werden. In Visual Basic könnten Schnittstellen auch in Form eines abstrakten VB-Klassenmodules erstellt werden. Visual Basic generiert daraus beim Übersetzen des Projektes eine Typbibliothek, die alle Informationen über die Schnittstelle zusammenfasst. Der Entwickler muss sich somit nicht mit IDL auseinandersetzen.

Dies ist insofern keine Einschränkung, da auch Schnittstellen implementiert werden können, die, auf einer IDL-Datei basierend, in einer externen Typbibliotheken definiert sind, vgl. [Patt99a, Seite 50, 51].

Hinsichtlich der benutzerdefinierten Schnittstellen existiert eine weitere Besonderheit. Visual Basic erstellt neben den benutzerdefinierten Schnittstellen automatisch zu jeder CoKlasse eine Standardschnittstelle ¹ mit dem Namen „_KlassenName“. Diese Schnittstelle beinhaltet alle öffentlichen Attribute und Methoden der CoKlasse. Dadurch wird es möglich, eine Komponente zu

Verteilte Anwendungen mit Visual Basic

entwickeln, ohne sich explizit Gedanken über die Definition einer benutzerdefinierten Schnittstelle machen zu müssen.

Übersetzt man die Definition der Schnittstelle IMyInterface, die durch eine Klasse CMyClass implementiert wird,

'Schnittstelle IMyInterface Public Sub Method1() End Sub

Public Function Function1() As String End Function

in eine Typbibliothek und betrachtet dann die Schnittstellendefinition,

interface _CMyClass : IDispatch { // empty due to no public methods in CMyClass };

^{coclass CMyClass {} [default] interface _CMyClass; interface IMyInterface; };

wird der beschriebene Sachverhalt deutlich. Visual Basic spezifiziert eine zusätzliche Schnittstelle mit dem Namen _CMyClass vom Type IDispatch und definiert sie als Standardschnittstelle der Komponente.

Unabhängig davon können jedoch uneingeschränkt eigene benutzerdefinierte Schnittstellen erstellt werden.

Definition und Implementierung einer Schnittstelle

Die ClassFactory und die drei Methoden AddRef(), Release() und QueryInterface() der standardisierten Schnittstelle IUnknown einer Komponente werden von Visual Basic vollständig automatisch implementiert.

Das folgende Beispiel zeigt daher die Definitition und Implementierung einer benutzerdefinierten Schnittstelle sowie deren Verwendung aus einer Client-

Applikation.

Verteilte Anwendungen mit Visual Basic

Im ersten Schritt wird eine abstrakte Klasse erstellt, die den Namen IDictionary trägt und die Schnittstelle der Komponente darstellt. Sie enthält die Deklaration einer öffentlichen Methode.

Hier die Visual Basic Syntax:

^{'Schnittstelle IDictionary} Public Function TranslateWord(ByVal Word as String) As String End Function

Im Vergleich dazu die entsprechende IDL-Definition ^{1 :}

[ uuid(DBD59698-AE3B-11d3-B09B-00AA00C8F8D5) ] library IDictionary {

interface IDictionary : IDispatch { HRESULT TranslateWord( [in] BSTR Word, [out, retval] BSTR* ); };

Eine weitere Klasse mit dem Namen CDictionary implementiert nun die benutzerdefinierte Schnittstelle IDictionary der Komponente.

^{'CoKlasse CDictionary} Implements IDictionary

Private FunctionIDictionary_TranslateWord(Word As String) As String 'Hier folgt der Implementierungscode End Function

Die Implements Anweisung drückt aus, dass diese Klasse die Schnittstelle IDictionary implementiert. Alle Memberfunktionen sind privat, wodurch sichergestellt wird, dass der Zugriff auf die Funktionen der Komponente ausschließlich über die definierte Schnittstelle erfolgt. An dieser Stelle wird nochmals deutlich, dass somit keine Abhängigkeiten zu Implementierungsdetails der CoKlasse bestehen können.

Nachdem die Schnittstelle von einer Klasse implementiert wurde, kann ein Client ein Objekt aus der Klasse erzeugen und mit diesem über eine Schnittstellenreferenz kommunizieren.

Verteilte Anwendungen mit Visual Basic

^{'Schnittstellenreferenz Dim objDictionary as} IDictionary ^{'Objektinstanziierung Set objDictionary =} New CDictionary 'Methodenaufruf MsgBox objDictionary.TranslateWord("Example")

Die Komponente aus diesem Beispiel verfügt nunmehr über die beiden Standardschnittstellen IClassFactory und IUnknown. Beide wurden von Visual Basic implementiert. Weiterhin besitzt sie die benutzerdefinierten Schnittstelle IDictionary und die Schnittstelle _CDictionary, welche Visual Basic aus der CoKlasse CDictionary generiert hat.

Abbildung 2.4: Schnittstellen einer Komponente

Im Folgenden wird auf wichtige Besonderheiten in diesem Zusammenhang hingewiesen.

“How many things can you think of that don't mix together well? Cats and dogs. Oil and water. Democrats and Republicans. Well, here's another pair you can add to the list: scripting clients and user-defined interfaces.” [Patt99b]

Der Autor Ted Pattison weist in einem Artikel deutlich darauf hin, das Client- die in Visual Basic Script programmiert sind, benutzerdefinierte Schnittstellen einer Komponente nicht unterstützen.

Was bedeutet diese Aussage?

Visual Basic Script ist eine typenlosen Sprache, die verschiedene Datentypen nicht unterscheidet. Es existiert ausschließlich der Variant-Datentyp. Er unterstützt die Speicherung von Ganz- und Gleitkommazahlen bis hin zu Objektreferenzen. Dieses Verhalten ist als schwache Typisierung bekannt, vgl. [Schw97, Seite 303]. Daher ist es unmöglich, bei der Referenzierung eines COM-Objektes eine bestimmte Schnittstelle (Schnittstelle=Klasse=Datentyp) auszuwählen.

Verteilte Anwendungen mit Visual Basic

'ungültiger Aufruf Dim objMyDictionary As IDictionary

'gültiger Aufruf Dim objMyDictionary

Stattdessen wird der Client immer an die Standardschnittstelle des Objektes gebunden.

Da die CoKlasse der vorgestellten Beispielkomponente weder öffentlichen Attribute noch öffentliche Methoden enthält, ist auch die Schnittstelle _CDictionary leer. Damit ist die gesamte Komponente für Skrip-Clients nutzlos.

Skript-Clients können benutzerdefinierte Schnittstellen nicht nutzen. Sie kommunizieren ausschließlich über die standardisierte Schnittselle mit Komponenten.

Der Grund, warum diese Thematik hier aufgegriffen wird, liegt darin, dass auch Microsofts Active Server Pages auf Visual Basic Script basieren.

Wie kann nun erreicht werden, dennoch Services von COM-Komponenten mit benutzerdefinierten Schnittstellen zu nutzen?

Eine erste Lösung dieses Problemes könnte darin bestehen, zumindest eine beliebige benutzerdefinierte Schnittstelle der Komponente als Standardschnittstelle zu definieren. Dies wird von Visual Basic in der Version 6.0 jedoch nicht unterstützt.

„It means you can't really benefit from the principles of interface-based programming when you're dealing with scripting clients. […] If you're creating a component that's going to support scripting clients, you're usually better off avoiding user-defined interfaces.“ [Patt99b]

Ted Pattison empfielt daher, bei der Entwicklung von Komponenten, deren Services auch von Skript-Clients genutzt werden, auf die Verwendung von benutzerdefinierten Schnittstellen zu verzichten.

Dann aber würden alle Vorteile der schnittstellenbasierten Programmierung verloren gehen, obwohl dies nicht zwingend erforderlich ist.

So stellen Wrapper-Komponenten, wie in Abbildung 2.5 gezeigt, einen anderen Weg dar, diese Einschränkung zu umgehen. Diese Wrapper instanziieren ein Objekt der Basiskomponente und bilden öffentliche, für einen Skript-Client

Verteilte Anwendungen mit Visual Basic

aufrufbare, Methoden auf die Methoden der benutzerdefinierten Schnittstellen der Basiskomponente ab. Nur so ist sichergestellt, dass die Basiskomponente ausschließlich über die definierten Schnittstellen verwendet wird.

Abbildung 2.5: Wrapping benutzerdefinierter Schnittstellen

Der beschriebene Weg ist zudem die einzige Möglichkeit, Komponenten von Drittanbietern, die ausschließlich benutzerdefinierte Schnittstellen zur Verfü- gung stellen, aus Script-Clients zu nutzen.

Versionsverwaltung

Damit Versionskonflikte beim Zugriff einer Client-Applikation auf die Dienste einer Komponente vermieden werden, legt COM fest, dass die Schnittstelle einer Komponente unveränderlich ist.

„COM was founded on the notion of interface immutability.“ [Rand00]

Sobald eine benutzerdefnierte Schnittstelle (ein vTable-Layout) unter einer bestimmten SchnittstellenID (IID) veröffentlicht wurde, muss sie unveränderlich sein. Wie bereits erwähnt, bildet die Schnittstelle einen festen Vertrag zwischen Client und Server. Die interne Implementierung der CoKlassen hingegen kann aber modifiziert werden. Denn es ist unbedeutend, ob beispielsweise ein Stack intern über ein Array oder eine verkettete Liste realisiert ist. Wichtig ist nur, dass die Schnittstelle weiterhin die beiden Methoden Push() und Pop() bereitstellt. Das Hinzufügen oder Löschen von Methoden zur Schnittstelle und das Ändern der Aufrufsyntax würden diesen Vertrag brechen. Um dennoch das Verhalten einer Komponente zu erweitern, kann eine weitere Schnittstelle, gekennzeichnet durch eine eigene IID, definiert werden. Vorhandene Clients, die mit der alten Schnittstelle arbeiten, müssen somit nicht neu kompiliert werden. Es können jedoch weitere Clients entwickelt werden, die über die neue Schnittstelle die erweiterte Funktionalität der Komponente nutzen können.

Das Beispiel zeigt eine Client-Applikation die prüft, welche Schnittstellen die Komponente unterstützt. Implementiert die Komponente Dictionary bereits die

Verteilte Anwendungen mit Visual Basic

erweiterte Methode TranslateWord(), welche einen zweiten Parameter anbietet mit dem die Sprache festgelegt werden kann, so wird diese aufgerufen.

'Schnittstellenreferenz Dim objMyDic As IDictionary 'Objektinstanziierung Set objMyDic = New CDictionary 'Methodenaufruf MsgBox objMyDic.TranslateWord(„Example“)

'Ist die Schnittstelle IExtendedDictionay implementiert? If TypeOf objMyDic Is IExtendedDictionary Then

Dim objMyExtendedDic As IExtendedDictionary Set objMyExtendedDic = objMyDic 'Methodenaufruf, zusätzliche Funktionalität der Komponente MsgBox objMyExtendedDic.TranslateWord("Example", "Deutsch") End If

Das Schlüsselwort TypeOf stellt also die C++ Methode QueryInterface() der Schnittstelle IUnknown dar.

Anders ausgedrückt definiert COM ein System, in dem Komponenten weiterhin die Schnittstellen unterstützen, durch die sie älteren Clients Services bereitgestellt haben und gleichzeitig neue, bessere Schnittstellen exportieren, über die sie neuen Clients erweiterte Services bereitstellen können. Komponenten können in ihrer Funktionalität erweitert werden, ohne dass bestehene Client-Applikationen angepasst werden müssen.

COM-Aktivierung

Das Laden einer COM-Komponente aus einer Client-Applikation und das Erstellen einer Verbindung wird als Aktivierung bezeichnet. Da COM verlangt, dass der Client keine Kenntnisse über die Implementierungsdetails einer COM-Klasse besitzt, kann er selbst kein Objekt der Klasse instanziieren. Wenn der Client das Datenlayout der Klasse nicht kennt, fehlt ihm dazu beispielsweise die Information, wieviel Speicher für das Objekt allokiert werden muss. Diese Aktivierung muss somit von der COM-Laufzeitumgebung unterstützt werden. Dazu nimmt der Service Control Manager (SCM) eine Aktivierungsanforderung vom Client entgegen. C++ Programmierer rufen dazu die COM-Funktion

Verteilte Anwendungen mit Visual Basic

CoCreateInstance() ¹ auf und übergeben als Parameter die CLSID der CoKlasse und die IID der geforderten Schnittstelle. In Visual Basic hingegen aktiviert man ein Objekt durch einen Aufruf des New Operators und Angabe des Namen der CoKlasse. Intern, wie Abbildung 2.6 verdeutlicht, übersetzt Visual Basic den Aufruf des New Operators in einen Aufruf der COM-Funktion CoCreateInstance(). Dabei wird der Klassenname durch die CLSID ersetzt. Diese Information entnimmt Visual Basic der Typbibliothek des Servers.

Abbildung 2.6: Befehlsausführung für die Instanziierung einer Komponente

Der Service Control Manager durchsucht die Windows-Registrierdatenbank anhand der CLSID, startet den entsprechenden COM-Server, übergibt die CLSID sowie die IID und erhält von der ClassFactory der Komponente eine Referenz auf die spezifizierte Schnittstelle. Diese leitet der Service Control Manager an den Client weiter. Über diese Schnittstelle erfolgt dann der Zugriff auf die Methoden des Servers.

„Client-Applikationen müssen die Dienste aufrufen, die von der COM-Bibliothek zur Verfügung gestellt werden, um Objekte zu erzeugen und eine Verbindung zu ihnen herzustellen.“ [Patt99a, Seite 52]

Lebensdauer einer Komponente

COM-Objekte werden zwar durch den Service Control Manager instanziiert, verwalten ihre Lebensdauer jedoch selbst. Dazu führt jedes Objekt einen Referenzzähler, der anzeigt, wieviele Clients an das Objekt gebunden sind. Dieser kann durch Aufruf der Methode Add() inkrementiert bzw. durch Aufruf der Methode Release() dekrementiert werden. Wird der Referenzzähler durch

Verteilte Anwendungen mit Visual Basic

den Aufruf der Methode Release() auf den Wert null gesetzt, gibt das Objekt alle Resourcen frei und wird aus dem Speicher entfernt.

Jedes COM-Objekt verwaltet seine Lebensdauer selbst.

Die Add() Methode wird implizit mit jedem Aufruf des Befehls CoCreateInstance() (C++) bzw. des New Operators (VB) ausgeführt. Den Aufruf der Methode Release() zum Freigeben eines COM-Objektes bildet Visual Basic auf das Nullsetzen der Objektreferenz-Variable ab. Es muss damit nicht, wie in C++ Programmen, explizit aufgerufen werden.

^{Set objReferenzVariable =} Nothing

Dynamisches Binden

Nutzt eine Client-Applikation die Services einer Komponente, so instanziiert es während der Programmausführung ein Server-Objekt, führt bestimmte Methodenaufrufe aus und zerstört das Objekt wieder. Der Client wird also erst zur Laufzeit dynamsich an das Objekt gebunden. Bis zur Instanziierung des Server-Objektes sind die Speicheradressen zum Einsprung für die Methodenaufrufe undefiniert. Daher arbeitet der Client mit einer Liste von Funktionszeigern (vTable), die während der Instanziierung mit den entsprechenden Speicheradressen gefüllt werden, vgl [Patt99a, Seite 44,45].

Eine virtuelle Tabelle (vTable) ist ein Array von Funktionszeigern auf die Methoden eines Objektes.

Obwohl Visual Basic das Arbeiten mit Zeigern nicht unterstützt, erfüllt es diese Anforderung der COM-Spezifikation. Der Visual Basic-Compiler kann den vTable-Bindungscode automatisch generieren. Dazu nutzt er die Schnittstelleninformationen die in der Typbibliothek der Server-Komponente zusammengefasst sind. Dann ist es möglich, dass die Client-Applikation über einen Schnittstellenzeiger die Methoden des Server-Objektes aufruft.

Skript-Clients, zu denen, wie bereits erwähnt, auch die webbasierten Technologien von Microsoft zählen, können bislang allerdings nicht auf die benötigten Informationen aus der Typbibliothek des Servers zugreifen. Wie soll dann aber der erforderliche vTable-Bindungscode generiert werden? Für diesen Fall bietet COM einen Bindungsmechanismus der als Automation bezeichnet wird. Automation Server implementieren eine Schnittstelle mit dem Namen

Verteilte Anwendungen mit Visual Basic

IDisapatch. „Diese Schnittstelle ermöglicht den Clients, Methodenbindungen in einem Prozess zur Laufzeit zu ermitteln.“ [Patt99a, Seite 63]. Im Gegensatz zu benutzerdefinierten vTables wird eine Methode nicht direkt aufgerufen, sondern es wird zur Laufzeit zunächst geprüft, ob eine Methode unterstützt wird, anschließend wird sie aufgerufen. Dazu stellt die Schnittstelle die beiden Funktionen GetIDsOfNames() und Invoke() bereit.

Abbildung 2.7: benutzerdefinierte vTable und die Schnittstelle IDispatch

Ganz gleich wieviele Funktionen eine Komponente exportiert, diese flexible Aufrufarchitektur stellt ein einheitliches vTable-Layout sicher. Damit ist es nicht notwendig, dass der Client die Typbibliothek kennt, um ein benutzerdefiniertes vTable-Layout mit Funktionszeigern für jede Methode zu generieren.

Der Flexibilität auf der einen Seite steht jedoch fehlende Effizienz gegenüber. Jeder Methodenaufruf über die IDispatch Schnittstelle erfordert tätsächtlich zwei Aufrufe und ist daher wenig performant.

Ein von mir im Rahmen dieser Diplomarbeit durchgeführter Performance-Test belegt die Aussage. Zehntausend Aufrufe einer Methode über die IDispatch Schnittstelle sind um den Faktor 12 langsamer, als der Aufruf der selben Methode über einen vTable-Funktionszeiger.

Um sowohl schnelle benutzerdefinierte vTables zu unterstützen aber auch Skript-Clients nicht auszuschließen, können Komponenten duale Schnittstellen anbieten.

“Eine duale Schnittstelle ermöglicht das Binden über IDispatch und benutzerdefinierte vTable-Schnittstellen" [Patt99a, Seite65].

Eine duale Schnittstelle ist die Kombination beider Schnittstellentypen. Jede Komponente, die mit Visual Basic erstellt wird, verfügt automatisch über eine duale Schnittstelle.

Verteilte Anwendungen mit Visual Basic