COM als Middleware - Seite 2

1.1 Definition des komponentenbasierten Ansatzes  

Zu Zeiten der Softwarekrise im Jahre 1969 führte M. D. McIlroy Begriff anlässlich einer Softwareengineering Tagung des NATO Science Commitee den Begriff der komponentenorientierten Softwareentwicklung ein, der seitdem zunehmend an Bedeutung gewinnt. Dies fußt einerseits auf konzeptionelle Vorteile der Komponenten-philosophie und andererseits auf der weitläufigen Verbreitung der hierfür notwendigen Technologien in Form von Microsoft-Betriebssystemen.

Die Idee der Komponente formte sich aus der mittlerweile etablierten objektorientierten Softwareproduktion. Um diese Entwicklung zu verstehen, ist zunächst kurz die Notwendigkeit von Objektbildung zu klären. Der wesentliche Vorteil der objektorientierten Betrachtung, als Nachfolgerin des prozeduralen Ansatzes, liegt in der erhöhten Wiederverwendbarkeit und Erweiterbarkeit von Programmsegmenten. Zudem bietet sie dem Entwickler ein Werkzeug, das verständlichere Entwürfe entstehen lässt. Mit der objektorientierten Programmierung [OOP] erfährt Code eine stärkere und sicherere Modularisierung, sprich Kapselung, sowie eine höhere Abstraktionsebene. Weiterhin birgt komponentenbasierte Softwareentwicklung ein größeres Potential bei der Arbeitsteilung.

Eine Komponente ist als Weiterentwicklung der OOP verstehbar. Sie hebt in einen Systemkontext, dem Framework gesetzt, den Nachteil der Anwendungsbezogenheit auf. Im klassischen Sinne bestehen Objekte nur zur Laufzeit eines Programmes und sind über ihren Prozess hinaus isoliert. Zwar kann die Kapselung einer Funktionalität auf Prozess-, nicht aber auf Betriebssystemebene stattfinden. Hierdurch ergeben sich sowohl ressourcenbindende, redundante Strukturen, als auch zusätzlicher Wartungsaufwand und Kosten. Eine in voneinander unabhängigen Anwendungen verwendete Klasse, ist bei Änderung oder Erweiterung ihrer Konstruktion jeweils erneut, anwendungsspezifisch zu implementieren. Die Lebensdauer eines zur Laufzeit erstellten Objekts ist an seine Anwendung gekoppelt, es verliert seine Zustände bei Beendigung der Applikation. Erstrebenswert wäre es daher, eine Klasse einmalig, nach Möglichkeit ortsungebunden anzulegen und über ihren Namen, aus verschiedenen Applikationen heraus beliebig instanzieren zu können. Es gilt also das Verständnis des klassischen Objekts mit den Eigenschaften einer eindeutigen globalen, persistenten Identität zu erweitern, um damit die Grundbedingung einer Komponente zu schaffen.

Eine Komponente beschreibt ein schnittstellenorientiertes Modul, in dem Daten und Operationen in Art der objektorientierten Betrachtung zu Klassen zusammengefasst sind und das über seine definierten, öffentlichen Interfaces kommuniziert. Ein solches Modul besitzt die allgemeinen Eigenschaften der Vererbung, Kapselung und Polymorphie, sowie ferner die Relationen der Assoziation, Aggregation und Komposition etc.. Es lässt sich ohne Kenntnis seines Aufbaus in ein Betriebssystem integrieren und ohne binäre Einbettung beliebig instanzieren.

Die einmalige, systemweite Schnittstellendefinition einer Komponente muss auf Grund der Kompatibilitätsbedingung unverändert bleiben. Sie ist unabhängig weiterhin von der verwendeten Programmiersprache, der jeweiligen Release-Version und ihrer örtlichen Lage. Um diese Autonomie zu gewährleisten, ist das Modul von compiler- bzw. interpreterspezifischen Merkmalen zu befreien. Komponenten dürfen nicht binär in Anwendungen eingebunden werden. Ihre Einbindung erfolgt durch Schnittstellenverweise, die direkte Instanzierung bewirkt das System; nicht der Anwender.

Die Umsetzungen eines solchen Konzeptes bindet Komponenten stets an einen Kontext, beispielsweise an Entwicklungsplattformen oder an ein Betriebssystem. Eine Komponente umschließt Softwareschnittstellen, über die sie nicht nur ihren eigentlichen anwenderspezifischen Service offengelegt, sondern darüber hinaus auch den Rahmen der Dienste definiert, den ihre Umgebung zu bedienen hat. Die standardisierte Abhandlung dieser Anforderungen bedingt ein Framework, auch Componentware oder Middleware genannt, und ist die entscheidende Voraussetzung für die Interaktion und den Zusammenschluss von Komponenten. Einen typischen Middleware-Standard legt, neben anderen das COM [Component Object Model] der Firma Microsoft fest.

Die Implementierungen einer Komponente stellen sich dem Anwender gegenüber als Blackbox dar, sie sind transparent. Die Komponente selbst beschreibt sich ausschließlich über ihre öffentlichen Schnittstellen, so dass sich keine externen oder gar versteckten Abhängigkeiten ergeben. Dienste, die im Zusammenhang mit der Komponentenarchitektur stehen übernimmt meist das Framework.

Dem objektorientierten Ansatz ähnlich, lässt sich die Komponentenentwicklung ebenfalls unter dem Aspekt ihrer Granularität betrachten. Granularität beschreibt die Größe der strukturellen Einheit eines Objekts. Komponenten besitzen in dieser Hinsicht keine definierten Einschränkungen und dürfen daher das Spektrum kleinster Basisklassen bis hin zu ganzen Applikationen abdecken. Praktisch ist festzustellen, dass sämtliche Schichten vertreten sind. So repräsentieren simple Elemente, wie beispielsweise Buttons das fine grained level, Anwendungen wie Word sind hingegen coarse grained. Komponenten der oberen Kategorie eignen sich besonders für verteilte Applikationen in Form von Client- Serveranwendungen. Die beteiligten Komponenten selbst können hierbei auf verschiedenen Knoten in einem verteilten System liegen. Verteilte Komponenten unterliegen der gleichen Transparenz wie lokale. Operationen auf entfernte Objekte unterscheiden sich syntaktisch und semantisch nicht von denen auf lokale.