Automatisierte Anpassung von .NET-Komponenten an einen kanonischen Interaktionsstil

Angebote / Angebote:

Inhaltsangabe:Zusammenfassung: Die komponentenbasierte Software-Entwicklung ist die Lösung der Softwaretechnik zu einer Modularisierung der Software, die zu einer erhöhten Wiederverwendung, Qualität, Wartbarkeit und Flexibilität führt. Es haben sich mittlerweile mehrere Komponentenmodelle (COM ¿ Component Object Model von Microsoft, Java Beans, Enterprise Java Beans, .NET, CORBA Component Model usw.) mit verschiedenen Vor- und Nachteilen in der Software-Industrie etabliert. Die Investitionen in die Entwicklung von Komponenten sind in den letzten Jahren enorm gestiegen und es besteht bereits ein beachtlicher Bestand an Software-Komponenten. Immer häufiger wird der Weg der Integration einer bestehenden Komponente als die Neuentwicklung gewählt. Wegen der Heterogenität der Komponentenmodelle und ihrer Laufzeitumgebungen kann man leider nicht ohne weiteres eine Komponente für eine bestimmte Laufzeitumgebung in einer anderen Laufzeitumgebung, die mit der ersten inkompatibel ist, nutzbar machen. Wenn die Interaktionsstile in den beiden Umgebungen aufrufbasiert und die Unterschiede nur technischer Natur sind, kann eine aufrufbasierte Middleware für Fernaufrufe wie CORBA weiterhelfen, die Implementierungen in vielen Programmiersprachen vorzuweisen hat. Wenn die Laufzeitumgebungen vom Prinzip her unterschiedliche Interaktionsstile aufweisen, kann der Ansatz von Prof. Dr.-Ing. Klaus-Peter Löhr zum Einsatz kommen, der dieser Arbeit zugrunde gelegt wurde. Er stellt eine weitgehende Generalisierung des generator-gestützten Vertreter-Treiber-Ansatzes von CORBA dar (bekannt im Englischen als ¿Proxy/Driver¿ oder ¿Stub/Skeleton¿). Ziel ist es, dass die Vermittlung zur Komponente für den Nutzer völlig transparent abläuft, so dass der Anschein erweckt wird, als wäre die Komponente speziell für die gewünschte Umgebung geschaffen worden. Zu diesem Zweck wird ein kanonischer Interaktionsstil definiert, auf den alle zu unterstützenden Interaktionsstile abgebildet werden können. Die Schnittstelle der Komponente wird in AID (Abstract Interface Definition), eine speziell für den kanonischen Interaktionsstil entwickelte Sprache, beschrieben. Nun können auf dieser Basis die Generatoren für die gewünschte Umgebung bzw. die Umgebung der Komponente einen Vertreter bzw. einen Treiber zur Komponente erstellen. Vertreter und Treiber kommunizieren über einen Kommunikationskanal, da sie in unterschiedlichen Umgebungen laufen. Im Rahmen dieser Arbeit wurde eine Lösung zur [...]