SCORE^® Composition Manager ist das zentrale Werkzeug der SCORE Adaptive Bridges, mit dem der Entwickler adaptive Services erstellt und pflegt. Die Informationen zu bestehenden Anwendungen und Datenspeichern werden „entdeckt“ (Discovery). Danach werden auf der Basis des OMG-Standards EDOC-ECA/CCA neue Services zusammengesetzt. Der letzte Schritt ist die automatische Produktion all dessen, was zur Implementierung des Service auf der Client-, Middleware- und Server-Plattform benötigt wird:

• Discovery – Der erste Schritt in MDLI ist die Suche nach PSMs für die Schnittstellen zu Ihren bestehenden Anwendungen und Datenhaltunssystemen. Diese werden für die Composition der adaptiven Services zunächst automatisch in PIMs transformiert.
• Composition – Im zweiten MDLI-Schritt erstellen Sie Ihr Service-basiertes Composition Model aus den verschiedenen PIMs der bestehenden Anwendungen und Datenhaltungssystemen.
• Production – Im letzten MDLI-Schritt werden die in Ihrem Composition Model definierten adaptiven Services von SCORE Adaptive Bridges in PSMs und von diesen in Code für den Application Adapter (auf der Serverseite) und das adaptive Proxy (auf der Clientseite) transformiert.

Der Composition Manager gibt Ihnen die Flexibilität, so zu arbeiten, wie Sie es möchten. Sie können bei Ihren bestehenden Legacy-Anwendungen und Fatenhaltungssystemen beginnen und sich danach zu Ihren neuen adaptiven Services „vorarbeiten“. Alternativ können Sie auch mit den neuen adaptiven Services beginnen und in Richtung der bestehenden Anwendungen und Datenhaltungssysteme „zurückarbeiten“. Sie können sogar in der Mitte beginnen und sich „nach außen vorarbeiten“. Mit dem Composition Manager können Sie genau so arbeiten, wie Sie es möchten. Das Composition Repository sorgt dafür, dass Ihr Modell konsistent bleibt, unabhängig davon, wo Sie beginnen und in welcher Reihenfolge Sie arbeiten.

Discovery

Der erste Schritt in MDLI ist die Suche nach PSMs für die Schnittstellen zu Ihren bestehenden Anwendungen und Datenhaltungssystemen. Für die Composition Ihrer adaptiven Services werden diese PSMs zunächst automatisch in PIMs transformiert.

Bei vertikalen Integrationsszenarien wird auch das PSM für die Zielplattform gesucht. Verwendet man zum Beispiel Web Services, so sucht man das PSM in der WSDL, um SCORE Adaptive Bridges die Schnittstellen für die neuen adaptiven Services mitzuteilen. Das ist häufig die effektivste Vorgehensweise, weil die Schnittstellen der zu produzierenden Services bereits definiert sind (z.B. ein XML-basierter Standard für Ihre spezielle Branche oder einen spezifischen Markt). Falls solche Schnittstellendefinitionen verfügbar sind, können Sie diese aus SCORE Adaptive Bridges heraus suchen und wiederverwenden – sie müssen nicht zweimal definiert werden.

Abhängig von der Menge der verfügbaren Metadaten im PSM muss eventuell das PIM erweitert werden. So könnten zum Beispiel Informationen darüber eingefügt werden, wie die Funktionen der bestehenden Anwendung aufgerufen werden sollen. In diesem Stadium werden zum Beispiel Details zu Funktionscodes, Aufrufsequenzen, Parameter-Zuordnung, Mapping von Datenstrukturen und andere physikalische Details der bestehenden Anwendung hinzugefügt. Ziel ist es, alle diese physikalischen Details der bestehenden Anwendung zu verkapseln und so eine saubere und wiederverwendbare Schnittstelle für die Composition herzustellen.

Für einen von der zugrundeliegenden Implementierungstechnologie unabhängigen Zugriff auf Datenhaltungssysteme gibt es ein vollständiges Objektmodell. Die Service-Benutzer können über eine einfache Kollektion von Standard-Services auf alle Datenhaltungssysteme zugreifen. SCORE Integration Suite enthält ausgefeilte Werkzeuge, die alle physikalischen Details des Zugriffs auf verschiedene relationale Datenbanken und Datei-basierte Systeme übernehmen. Für die Composition wird immer dasselbe Objektmodell verwendet. Deshalb braucht sich der Entwickler nicht um Details der Speicherung oder der physikalischen Navigation in der Datenbank zu kümmern.

Discovery ist auch der Prozess, der die vollständige und partielle Wiederverwendung von Elementen anderer Composition Models ermöglicht. Wenn Sie über einen Satz gemeinsamer Schnittstellen, Datenstrukturen, Methodenbeschreibungen etc. verfügen, können diese in einem gemeinsamen Composition Repository definiert werden. Danach können Sie von den Composition Models für Ihre adaptiven Services auf diese zentralen Definitionen verweisen. Durch die Speicherung aller Informationen über Abhängigkeiten und Referenzen im Composition Repository behalten Sie die Kontrolle darüber, was wo verwendet wird. Bei Veränderungen eines gemeinsam genutzten Objekts kann leicht verifiziert werden, wo es verwendet wird. So können die Änderungen kontrolliert und gezielt auf die gesamte Anwendung angewendet werden.

Es gibt Discovery-Adapter für eine große Anzahl unterschiedlicher herkömmlicher und aktueller Implementierungstechnologien und Datenbanken.

Weitere Discovery-Adapter, zum Beispiel für die Unterstützung projektspezifischer Anforderungen, können ganz einfach erstellt werden. Eine Liste der aktuell verfügbaren Discovery-Adapter finden Sie unter Unterstützte Plattformen.

Composition

Im zweiten MDLI-Schritt erstellen Sie Ihr Service-basiertes Composition Model aus den verschiedenen PIMs der bestehenden Anwendungen und Datenhaltungssysteme.

Bei der Composition werden die noch zu erstellenden Services beschrieben sowie die Zuordnung (Mapping) zwischen den Service-Anbietern (bestehende Systeme) und den Service-Benutzern (neue Anwendung oder Client).

Das Composition Model implementiert den OMG-Standards EDOC-ECA/CCA. Sie arbeiten mit mindestens zwei Komponenten: Mit der wiederverwendeten Funktion der Legacy-Anwendung bzw. dem Datenhaltungssystem und mit der Komponente, die den adaptiven Service repräsentiert, den Sie für Ihre Client-Plattform verfügbar machen.

Die Composition erstreckt sich sowohl auf statische als auch auf dynamische Informationen. Die statische Sicht zeigt die Struktur oder Composition des Service als Objekte in einer niedrigeren Granularitätsstufe. Die dynamische Sicht stellt die Choreographie der Composition dar, also wie die verschiedenen Komponenten bei der Implementierung einer bestimmten Business-Transaktion zusammenarbeiten.

Je mehr Informationen Sie definieren können, wie die externe Schnittstelle Ihres adaptiven Service funktionieren soll, desto mehr Möglichkeiten bekommt SCORE Adaptive Bridges zur Optimierung des Laufzeitverhaltens. Dann kann auch zusätzlicher Code generiert werden, um sicherzustellen, dass die Reihenfolge der erwarteten Meldungen berücksichtigt wird. Wenn der erwartete Ablauf der Meldungen unterbrochen wird, kann der adaptive Service auf diesem Code aufbauend eine sinnvolle Wiederherstellung durchführen.

Für das interne Verhalten des adaptiven Service werden ebenfalls Choreographien definiert. In diesem Fall definiert die Choreographie den internen Prozess für die Implementierung des Service. Dazu zählt das Aufrufen von Funktionen aus bestehenden Anwendungen und/oder Zugriffe auf Datenhaltungssysteme, das Überprüfen der Resultate, die Kombination und Konvertierung von Daten und die allgemeine Ablaufsteuerung.

Innerhalb der Composition-Phase werden die Zusatzinformationen deklariert, die bei der Production-Phase zur Generierung des optimalen Codes für die gewünschte Deployment-Plattform benötigt werden.

Production

Im letzten MDLI-Schritt werden die in Ihrem Composition-Model definierten adaptiven Services von SCORE Adaptive Bridges in PSMs transformiert und anschließend aus diesen in Code für den Application Adapter (auf der Serverseite) und das adaptive Proxy (auf der Clientseite).

Der Application Adapter und das adaptive Proxy werden unabhängig voneinander erstellt. So können zum Beispiel zusätzliche Proxies für neue Plattformen generiert werden, ohne dass Ihre bestehenden Anwendungen davon berührt werden. Die Art und Weise, wie der Application Adapter und das adaptive Proxy generiert werden, ist stark von der Deployment-Plattform abhängig. Nähere Informationen darüber, wie die Laufzeit-Architektur für die verschiedenen Deployment-Plattformen erstellt wird, finden Sie unter Laufzeit-Sicht.

Ein wichtiges Ziel von SCORE Adaptive Bridges ist es, eine für die Entwickler der bestehenden Systeme und die Entwickler neuer Client-Anwendungen gleichermaßen vorteilhafte Situation zu schaffen. Ein wichtiger Beitrag hierzu ist die Erzeugung eines adaptiven Proxies, das mit der Client-Entwicklungsumgebung absolut kompatibel ist. Das bedeutet, dass nicht nur korrekter Code generiert werden muss, sondern dass dieser auch den Konventionen der Entwicklerkultur der jeweiligen Client-Plattform entsprechen muss. So erwartet zum Beispiel ein Java-Entwickler, dass sich eine Java-Klasse auf eine bestimmte Art verhält, dass sie mit JavaDoc dokumentiert ist und in Standard-Entwicklungsumgebungen für Java wie NetBeans etc. passt. SCORE Adaptive Bridges produziert adaptive Proxies, die allen diesen Konventionen entsprechen. Der Entwickler verwendet einfach die generierten Java-Klassen und braucht sich nicht darum zu kümmern, was hinter den Kulissen geschieht.

Das Composition Repository enthält detaillierte Informationen zu den Abhängigkeiten zwischen den verschiedenen Elementen des Composition Models. Das ermöglicht SCORE Adaptive Bridges die Optimierung der Produktion von Code-Komponenten. Es wird nur der absolut notwendige Code neu generiert, abhängig von Ihren Änderungen im Composition-Modell. Dieses Konzept gilt auch bei Änderungen bei der Deployment-Plattform, Middleware etc. – wegen der klar getrennten logischen Schichten der Laufzeitarchitektur braucht nicht alles neu generiert zu werden. In vielen Fällen braucht nur sehr wenig Code neu generiert werden.

Es gibt Plattform-Adapter, die native, nicht-invasive und optimierte Implementierungen Ihres Services für die gewünschten Rechner, Betriebssysteme, Sprachen, TP-Monitore, Middleware und Datenbanken erstellen. Der Wechsel auf eine neue Plattform ist im wahrsten Sinne des Wortes „nur einen Mausklick entfernt“.

Weitere Plattform-Adapter, zum Beispiel für die Unterstützung projektspezifischer Anforderungen, können schnell bereitgestellt werden. Eine Liste der aktuell verfügbaren Plattform- und Technology Adapter finden Sie unter Unterstützte Plattformen.

Und wohin jetzt?

Im nächsten Abschnitt lernen Sie die SCOUT² Development Platform kennen, Deltas erweiterbare Entwicklungsplattform für Projektteams, bei denen verschiedene Plattformen, Toolsets und CCM-Umgebungen zum Einsatz kommen.