Erweiterungen fuer Visual-Age und Visual-Gen

14.10.1994

FRAMINGHAM (IDG) - Big Blue will den Entwicklern das Schreiben umstaendlicher Codes fuer die Netzkommunikation ersparen - allerdings nur innerhalb der IBM-Produktwelt. Konkret wurden die Smalltalk-basierte Entwicklungsumgebung Visual-Age und der grafische Nachfolger des Cross System Product (CSP), Visual-Gen, mit Schnittstellen fuer die asymmetrische Middleware MQ-Series ausgestattet.

Bei MQ-Series handelt es sich um ein Messaging-System der IBM, mit dem sich, aehnlich wie mit einem Remote Procedure Call, in heterogenen Netzen Programme starten lassen. Da es asynchron arbeitet, eignet es sich nicht fuer Dialogverfahren, sondern fuer Batch-aehnliche Vorgangsbearbeitung quer ueber heterogene Plattformen hinweg.

Fuer die Entwickler bedeutet die Anbindung von Visual-Age und Visual-Gen an das Messaging-System, dass sie ihre netzfaehigen Anwendungen nur noch auf dessen API abstimmen muessen. Bisher sind sie gezwungen, jedes in ihrem Unternehmen verwendete Kommunikationsprotokoll zu beruecksichtigen.

Corba 1.1 und Corba 2.0

Im Januar 1992 veroeffentlichte die Object Management Group (OMG) ihren ersten Objektstandard Corba 1.1. Als zentrale Komponente sieht Corba einen Object Request Broker (ORB) der als Postverteiler arbeitet (vgl. Abbildung. 1). Eine Nachricht an ein Objekt wird ueber den ORB transportiert. Dieser veranlasst die Ausfuehrung der entsprechenden Methode des Empfaengerobjektes und traegt die Ergebnisse wieder zum Sender der Nachricht zurueck. Dabei deuten die gestrichelten Linien die aus der Sicht von Anwendern bestehenden Abhaengigkeiten an. Die Objekte kennen sich.

Die einzelnen Kapseln konnten auch schon bei Corba 1.1 auf verschiedenen Maschinen liegen. Die Verbindung der ORB-Systeme erfolgte dabei noch herstellerspezifisch, das heisst nicht standardisiert. Beispiele: DST von HP, Orbix von Iona, DSOM von IBM.

Durch Corba 2.0 kann der Transport auf zwei oder mehr ORBs verteilt werden. Liegen die ORBs auf verschiedenen Maschinen, spricht man von einem Client-Server-System. Die beiden ORBs in Abbildung 2 koennen zudem von unterschiedlichen Herstellern stammen.

Die Aufteilung der Transportschicht von einem in zwei ORBs darf keine Auswirkungen auf die Anwendungsprogrammierung haben. Nur so ist es moeglich, die Arbeitsverteilung zwischen Client- und Server- Maschinen ohne Aenderung von Anwendungsprogrammen durchzufuehren. Allerdings werden die Verteilungsmoeglichkeiten zur Zeit noch deutlich durch die Transportkapazitaeten eingeschraenkt.

Mit Corba 2.0 ergeben sich interessante Perspektiven fuer die Standardsoftwarehersteller. Sie koennen Objektkapseln mit einem ORB zu Standardsoftware-Bausteinen zusammenfassen. Weil unterschiedliche ORBs verbunden werden koennen (vgl. Abbildung 3) passen die Kapseln in die beim Kunden vorhandene Landschaft.

Zur Zeit diskutiert die OMG zwei unterschiedliche Vorschlaege fuer Corba 2.0. Der eine basiert auf DCE, der andere nutzt das Standard-TCP/IP-Protokoll.