-
Die
Erfindung bezieht sich auf verteilte Komponenten in vernetzten Computersystemen
und, im speziellen, auf ein Verfahren zur Generierung von JavaBeans
zur Kapselung des Zugriffs auf CORBA Komponenten sowie zu deren
Konfigurierung. Die Erfindung bezieht sich ferner auf entsprechende Software
und zugehörige
Programmträger.
-
CORBA
(Common Objekt Request Broker Architecture) stellt das Herzstück der von
OMC (Objekt Management Group) etablierten Referenzarchitektur für die Verteilung
und das Management verteilter Objekte dar. Diese Objekte sind dabei
die notwendigen Bestandteile objektorientierter Software. Ein Client-Programm
das einen bestimmten Dienst (Service) aufruft, wie z. B. eine Datenbankrecherche
oder die Konfiguration einer Server-Komponente, erbittet diese Vermittlung
durch den Objekt Request Broker (ORB). Der Object Request Broker
verteilt die entsprechenden Aufrufe (Requests), und liefert die
Antworten an das aufrufende Client-Programm zurück.
-
Das
CORBA Komponenten-Modell (CCM, Bestandteil der CORBA-Spezifikation 3.0)
definiert, auf welche Weise Client-Programme Server-Komponenten erzeugen
bzw. Zugriff auf bereits existierende Server-Komponenten erlangen,
sowie wie einzelne oder Gruppen von Server-Komponenten konfiguriert werden
können.
-
Um
auf eine Server-Komponente zugreifen zu können, muß ein Client-Programm zunächst ein sogenanntes
Stub-Objekt für
die Server-Komponente ermitteln, welches ein Programm-lokaler Platzhalter
der Komponente ist. Die Ermittlung des Stub-Objekts geschieht durch folgenden Mechanismus:
- 1) Finden eines Verzeichnisdienstes für sogenannte
Component Homes – dies
sind Dienste, die die Komponenten-Instanzen jeweils einer Komponenten-Klasse verwalten.
- 2) Finden des Component Home, welches für die Verwaltung der Komponenten
des gewünschten Typs
zuständig
ist.
- 3) Anfrage 'find' oder 'create' an das Component Home,
die als Resultat ein Stub-Objekt liefert, über welches dann Anfragen an
die existierende oder neu erzeugte Server-Komponente geschickt werden
können.
-
Insbesondere
für die
Schritte 1) und 2) werden Serverspezifische Parameter wie Namens-Kontext,
IP-Adresse und – Port
benötigt.
-
Die
Konfiguration von Server-Komponenten umfasst das Setzen von Attribut-Werten
einzelner Komponenten sowie die Verschaltung verschiedener Komponenten
durch Nutzung der von den Komponenten bereitgestellten sogenannten
Ports. Das CCM unterscheidet folgende Port-Typen, die für eine Verschaltung
genutzt werden können:
- – Facets
stellen unterschiedliche Dienste bereit, die von der Komponente
angeboten werden.
- – Receptacles
bieten dem Client die Möglichkeit, der
Komponente Dienste (d. h. Objekt-Referenzen von Diensten) zur Verfügung zu
stellen.
- – Publisher
und Emitter definieren Produzenten (Quellen) von Events.
- – Consumer
definieren Verarbeiter (Senken) von Events.
-
Die
Verschaltung zweier Komponenten besteht nun darin, ein Facet der
einen Komponente der anderen als Receptacle zur Verfügung zu
stellen, oder aber einen Consumer der einen Komponente bei einem
Publisher oder Emitter der anderen Komponente anzumelden. Die Verschaltungen
zwischen Komponenten können
innerhalb der Lebenszeit einer Komponenten-Instanz dynamisch erzeugt
und gelöst werden,
während
das CCM davon ausgeht, dass Attribut-Werte der Komponente nur während einer
Initialisierungs-Phase gesetzt werden.
-
Es
ist nun Aufgabe der vorliegenden Erfindung, den Zugriff von Java
Client-Programmen auf eine CORBA-Komponente und deren Konfiguration zu
vereinfachen. Weiterhin soll die Erfindung die Konfiguration einer
Gruppe verschalteter Komponenten durch grafische Entwicklungswerkzeuge
ermöglichen,
sowie die einfache Wiederverwendung solcher Konfigurationen in beliebigen
Java-Anwendungen.
-
Diese
Aufgaben werden erfindungsgemäß dadurch
gelöst,
daß ein
Proxy-Objekt bereitgestellt wird mit dem der Zugriff von Java Client-Programmen auf
eine CORBA-Komponente vereinfacht wird. Durch das Proxy-Objekt werden
die Zugriffe auf die CORBA-Komponente
sowie der Mechanismus zum Ermitteln des Stub-Objekts gekapselt.
-
Diese
Aufgaben werden durch das im Anspruch 1 definierte Verfahren sowie
durch einen im Anspruch 6 definierten Datenträger gelöst.
-
Laut
Erfindung wird ein Verfahren zum Zugriff auf eine CORBA-Komponente in Computersystemen
mit verteilten Komponenten, vorgeschlagen, das die folgenden Schritte
beinhaltet:
eine Proxy-Klasse wird generiert, deren Objekte
alle Zugriffe auf die CORBA-Komponente einkapselt, wobei die CORBA-Komponente durch
ein Stub-Objekt, das einen Programm-lokalen Platzhalter der Komponente
darstellt, definiert ist;
das Stub-Objekt der CORBA-Komponente
wird intern mit einem der Proxy-Objekte verwaltet; und
beim
ersten Zugriff durch einen Client des Proxy-Objekts wird das Stub-Objekt
der Server-Komponente mit einem Java Client-Programm ermittelt.
-
In
einer vorteilhaften Weiterführung
des erfindungsgemäßen Verfahrens
wird das Stub-Objekt ermittelt indem:
nach einem Verzeichnisdienst
für Component
Homes, die die Komponenten-Instanzen jeweils einer Komponenten-Klasse
verwalten, gesucht wird;
das Component Home, welches für die Verwaltung der
CORBA-Komponenten
des gewünschten
Typs zuständig
ist, gefunden wird; und
eine Anfrage 'find' oder 'create' an das Component Home übermittelt
wird, worauf das Component Home als Resultat ein Stub-Objekt liefert.
-
Vorteilhafterweise
können
dann nach Erhalt des Stub-Objekts vom Component Home Anfragen an
die existierende oder neu erzeugte Server-Komponente geschickt werden.
-
Laut
einer weiteren vorteilhaften Erweiterung der Erfindung werden für die Generierung
der Proxy-Klasse die IDL-Spezifikation
der Komponente und des Component Home, sowie die Parameter, die
für das
Ermitteln des Stub-Objekts benötigt
werden, eingegeben.
-
Die
Proxy-Klasse kann wie folgt generiert werden:
Java Interface-Definitionen
gemäß dem durch
CORBA 3.0 definierten Java Language Mapping werden zuerst generiert;
dann
werden die Java Interface-Definitionen mit einem Java Compiler zu
Java Byte-Code kompiliert; und
die Proxy-Klasse wird durch
ein Java-Programm generiert, welches den im vorhergehenden Schritt
generierten Byte-Code liest und mit Hilfe des Java Reflection Mechanismus
interpretiert.
-
JavaBeans
ist eine Komponentenarchitektur für Java. Objekte im Java werden
dabei in eine Hülle, d.
h. einen sogenannten Wrapper, gekleidet. Diese Hülle ist der Standard Interface
für die
Kommunikation zwischen den Komponenten. Eine Bean kann dabei die
jeweils anderen Beans befragen und Information weitergeben, während bestimmte
Informationen zurück-
und geheim gehalten werden. Die JavaBeans führen ihren Informationsaustausch über ein Network
durch die Java Remote Method Invocation (RMI). Die JavaBean Specifications
sind bei Sun Microsystems auf http://java.sun.com/products/javabeans/
erhältlich.
-
Die
Spezifikation des CCM sieht lediglich eine Verschaltung verschiedener
Komponenten durch den Administrator eines Komponentenservers mit
Hilfe sogenannter Assemblies vor. Diese Assemblies erlauben es,
eine Gruppe verschalteter Komponenten im Komponenten-Server gemeinsam
zu aktivieren. Das hier vorgeschlagene Verfahren sieht nun eine
Verschaltung von Komponenten durch beliebige Client-Anwendungen
vor. Diese Verschaltung ist im CCM zulässig und insbesondere für durch
die Client-Anwendung selbst erzeugte Komponenten-Instanzen auch
sinnvoll und von Vorteil.
-
Im
folgenden wird die Erfindung und der Aufbau des CORBA Systems im
Zusammenhang mit der Java Client Architektur anhand einer zeichnerischen Darstellung
näher erläutert. Dabei
zeigen:
-
1 eine
Blockdiagram der Komponentenverbindung von einem Java Client zum
Operating System.
-
2 ein
Blockdiagram der Beangenerierungsarchitektur, wobei als Beispiel
die Generierung eines Fax Beans erläutert wird.
-
Das
in 1 dargestellte System besteht aus drei Hauptgruppen:
auf der einen Seite liegt der Java Client, der in manchen Fällen Zugriff
sucht auf Dienste die im Operating System bereitgestellt werden,
oder für
die das Operating System Teile liefert. Der Java Client wird von
den Beans gegenüber
den CORBA-Komponenten geschützt,
d. h., gegenüber der
Komplexität
der CORBA-Komponenten. Für
den Java Client werden die Komponentent des CORBA durch die Java
Beans mittels des CORBA stubs zur Verfügung gestellt. Die zweite Hauptgruppe – die Vermittlergruppe – besteht
aus dem Container und den darüberliegenden
Components. Die Container schützen
die Clients und die Components gegenüber den Details der ORBs (Object
Request Brokers), der Services, des Networks und der Operating Systems.
-
Im
Gegensatz zum Stand der Technik ist es nach Implementierung der
gegenständlichen
Erfindung nicht mehr notwendig den Mechanismus zum Ermitteln des
Stub-Objekts in jeder Java-Applikation, die CORBA-Komponenten nutzen
möchte,
explizit zu programmieren.
-
Die
gegenständliche
Erfindung löst
das angegebene technische Problem auf sehr elegante und einfache
Weise.
-
Wie
in der oberen Hälfte
der 2 angedeutet, werden Beans aus dem CORBA IDL generiert. Die
nach der Erfindung generierte FaxBean steht nicht nur für den momentan
gewünschten
Zugriff, sondern auch für
zukünftige
Zugriffe zur Verfügung. Die
Zusammenstellung der Bean, d. h. die Bean Composition, wird im BeanContext
Container durchgeführt.
Diese Zusammenstellung ist im Block A angedeutet. Wenn der im Bean
definierte Service durchgeführt
werden soll, werden im Block B die Corba components zusammengeführt und
verbunden.
-
Für eine CORBA-Komponente,
die durch Java-Anwendungen genutzt werden soll, wird eine Proxy-Klasse
generiert, deren Objekte alle Zugriffe auf die CORBA-Komponente
einkapselt. Zu diesem Zweck verwaltet ein solches Proxy-Objekt intern
das Stub-Objekt
der CORBA-Komponente. Dieses Stub-Objekt wird bei Bedarf, d. h.
beim ersten Zugriffsversuch durch einen Verwender des Proxy-Objekts,
durch den oben genannten Mechanismus ermittelt.
-
Als
Eingabeinformationen für
die Generierung der Proxy-Klasse werden benötigt:
- • Die IDL-Spezifikation
der Komponente und des Component Home.
- • Die
Parameter, die für
die Schritte 1) (Verzeichnisdienst finden) und 2) (Component Home
finden) zum Ermitteln des Stub-Objekts benötigt werden.
-
Die
Generierung erfolgt in folgenden Schritten:
- a)
Zuerst werden Java Interface-Definitionen generiert gemäß dem durch
CORBA 3.0 definierten Java Language Mapping (nicht Bestandteil der
Erfindung)
- b) Die Java Interface-Definitionen werden mit einem Java Compiler
zu Java Byte-Code compiliert (der Java Byte-Code ist ebenfalls nicht Bestandteil
dieser Erfindung)
- c) Dann wird die Proxy-Klasse durch ein Java-Programm generiert,
welches den im vorhergehenden Schritt b) generierten Byte-Code liest und
mit Hilfe des Java Reflection Mechanismus interpretiert.
-
Dieser
letztgenannte Schritt c) generiert eine Proxy-Klasse, die das Java
Interface der CORBA-Komponente implementiert. Hierfür wird für jede Methode
dieses Interfaces eine Methode generiert, die zunächst die
Verfügbarkeit
des Stub-Objekts überprüft und dieses
ggf. ermittelt, und daraufhin den Aufruf an das Stub-Objekt delegiert.
-
Die
Stub-Objekte für
sogenannte Entity-Komponenten, deren Instanzen über einen Schlüssel-Wert
lokalisiert werden können,
besitzen folgende Eigenschaften (Properties), über die der Benutzer den Mechanismus
zum Ermitteln des Stub-Objektes
konfigurieren kann: Die „key" Property enthält den Schlüssel-Wert,
der zum Lokalisieren und zum Erzeugen einer Instanz benötigt wird.
Hat die „find"-Property den Wert „true", so wird im Schritt
3) des Mechanismus zum Ermitteln des Stub-Objektes zunächst versucht,
eine existierende Instanz mit den spezifizierten Schlüsseln zu
finden. Ist dies erfolgreich, so wird diese Instanz verwendet.
-
Ansonsten
wird, sofern die „create" Property den Wert „true" hat, eine Instanz
mit dem spezifizierten Schlüssel
erzeugt. Kann keine Komponenten-Instanz ermittelt werden, so wird
ein Fehler gemeldet.
-
Da
die Methoden für
die Verwendung der Ports der Komponente fest definierten Namens-Konventionen
genügen,
kann auch die Information über die
Ports der Komponente durch Interpretation des Byte-Codes gewonnen
werden. Mit dieser Information kann die Proxy-Klasse um Funktionalität zur Konfiguration
der zugehörigen
CORBA-Komponente erweitert werden.
-
Dieser
Konfigurationsmechanismus basiert auf dem JavaBeans Runtime Containment
und Services Protocol (BeanContextServices API). Die Proxy-Objekte
werden befähigt,
als Beans in einen BeanContextServices Container geladen, konfiguriert und
als konfigurierte Objekt-Instanzen persistent gespeichert und wiederverwendet
zu werden.
-
Hierdurch
wird die grafische Konfiguration einer Gruppe von Proxy-Objekten
mit Hilfe sämtlicher Bean
Builder Tools ermöglicht,
die einen BeanContextServices Container für eine grafische Komposition
von Beans zur Verfügung
stellen. Ein solcher Container bietet neben einem Design-Modus,
in welchem die Beans durch Editieren ihrer Properties konfiguriert
werden können,
zum Teil auch einen Ausführungs-Modus,
in dem die Komposition ausgeführt werden
kann. Das Wiederverwenden ganzer Kompositionen setzt lediglich voraus,
dass die persistent gespeicherten Objekt-Instanzen wiederum in einen BeanContextServices
Container geladen werden, der sich im Ausführungs-Modus befindet.
-
Werden
Proxy-Objekte in einen solchen Container eingefügt, so publizieren sie ihr
Komponenten-Interface sowie alle Facets und Consumer als Services,
welche dann von allen Beans innerhalb des Containers genutzt werden
können.
Diese Publikation geschieht durch Angabe der Java-Klasse, die den Service
beschreibt, des Objekts, das den Service zur Verfügung stellt,
und eines sogenannten Service Selectors, der zur Auswahl des Dienstanbieters
verwendet werden kann.
-
Für die Proxy-Objekte
wird ein Service Selektor definiert, der eine eindeutige Identifikation
des Proxy-Objekts innerhalb eines BeanContext ermöglicht.
Der Service Selektor setzt sich zusammen aus den Feldern Java Interface
der Komponente, PortName und Instanz-Name. Der Instanz-Name kann
vom Benutzer innerhalb eines Containers durch Setzen einer Property
eindeutig festgelegt werden. Der PortName entspricht dem Namen des
publizierten Facets oder Consumers der Komponente.
-
Diese
publizierten Services können
von anderen Proxy-Objekten abgefragt und genutzt werden, um Verschaltungen
der zugehörigen
CORBA-Komponente zu erzeugen, d. h. um die Objekt-Referenzen der Service-Anbieter
der CORBA-Komponente als Receptacle oder Consumer zur Verfügung zu
stellen. Weiterhin können
die Services auch durch Aufruf ihrer Methoden dazu genutzt werden,
Attribut-Werte für
das Setzen der Attribute der CORBA-Komponente bereitzustellen.
-
Die
Abfrage und Nutzung der im Container publizierten Services kann
für jeden
Port, d. h. jedes Receptacle, jeden Consumer und jedes Attribut
einzeln konfiguriert werden. Hierzu besitzt jedes Proxy-Objekt eine
Property namens „contextServiceUsage" die mit Hilfe eines
speziellen Editors bearbeitet werden kann. (Die Zuordnung des Editors
zu der Property geschieht durch das Bean Builder Tool anhand einer
der Proxy-Klasse durch Namenskonvention zugeordneten BeanInfo-Klasse).
-
Die
Konfiguration eines Ports besteht in der Zuordnung eines Service
Selektors zum jeweiligen Port sowie der Angabe, ob eine Verschaltung
dieses Ports nicht, optional oder verbindlich vorgenommen werden
soll.
-
Der
Editor unterstützt
die Auswahl eines Service Selektors dadurch, dass er aus der Liste
aller verfügbaren
Services die Service Selektoren aller für den jeweiligen Port nutzbaren
Services herausfiltert.
-
Für Attribut-Ports
sind alle Services nutzbar, die eine parameterlose Methode besitzen,
welche Rückgabewerte
liefert, die dem jeweiligen Attribut zugewiesen werden können. Die
Konfiguration eines Attribut-Ports enthält daher neben dem Service
Selektor auch den Namen der Methode, die den zuzuweisenden Attribut-Wert
liefern soll.
-
Die
Konfiguration der CORBA-Komponente, d. h. die Zuweisung der Attribut-Werte
und die Verschaltung der Ports, geschieht jedoch nicht in dem Moment,
in dem die Port-Konfiguration im Editor geschieht, sondern erst,
nachdem der Container den Design-Modus verlassen hat und aufgrund
der ersten Nutzung des Proxy-Objekts das Stub-Objekt ermittelt wird.
-
Eine
Konfiguration von Komponenten-Attributen geschieht nur dann, wenn
die Komponenten-Instanz im Schritt 3) des Mechanismus zum Ermitteln
des Stub-Objekts durch das Proxy-Objekt
erzeugt wurde. In diesem Fall werden noch vor der Ermittlung des
Stub-Objektes alle für
Zuweisungen benötigten
Attribut-Werte durch Nutzung der im Container publizierten Dienste
ermittelt. Hierbei können
zirkuläre
Initialisierungs-Abhängigkeiten
erkannt werden die bei Auftreten zu einer Fehlermeldung führen.
-
Nach
der Ermittlung des Stub-Objekts werden ggf. die zuvor ermittelten
Attribut-Werte an die CORBA-Komponente propagiert und die "configuration complete" Methode aufgerufen.
-
Als
letzter Konfigurations-Schritt erfolgt die Verschaltung der Receptacles
und Consumer gemäß der "contextServiceUsage" Konfiguration.
-
Sowohl
der Editor für
die "contextServiceUsage" Property als auch
der Mechanismus zur Durchführung
der Komponenten-Konfiguration
benutzen den Java Reflection Mechanismus zum dynamischen Auffinden
und Ausführen
von Methoden.
-
Erst
nachdem die Konfiguration der CORBA-Komponente abgeschlossen ist,
wird die vom Verwender des Stub-Objekts aufgerufene Methode durch
Propagierung des Aufrufs an das Stub-Objekt abgeschlossen.
-
Das
erfindungsgemässe
Verfahren soll nun anhand eines Beispiels erörtert werden. Das Verfahren
betrifft die Erstellung einer Komposition von Beans mit Hilfe eines
Bean Builder Tools:
- 1) Zuerst wird ein Bean
durch ein Bean Builder Tool im Design-Modus in einen BeanContextServicesContainer
geladen.
- 2) Die Bean initialisiert Service-Provision und Service-Usage
Beschreibungsobjekte und publiziert ihre Services gegenüber dem
BeanContext.
- 3) Danach werden weitere Beans analog geladen und publizieren
ihre Services.
- 4) Der Benutzer konfiguriert die Service-Usage Beschreibungen
der Bean. Für
jedes Receptacle, jede Event Source und jedes veränderbare
Attribut der Komponente bietet die Bean je eine Service-Usage Beschreibung
an. Die Konfiguration besteht für
Receptacles und Event Sources darin,
(a) den Bindungslevel
für die
automatische Konfiguration festzulegen, mögliche Werte sind
– keine
Bindung
– optionale
Bindung (Misserfolg wird ignoriert)
– notwendige Bindung (Exception
bei Misserfolg)
(b) den Service-Provider für die automatische Konfiguration
festzulegen. Der Property-Editor bietet hierzu alle von anderen
Beans angebotenen Services zur Auswahl an, die aufgrund ihrer Klassen-Signatur
für eine
Bindung in Frage kommen. Für
eine Attribut-Konfiguration besteht Teil (b) darin, einen Service-Provider
und eine parameterlose Methode dieses Service-Providers auszuwählen, die
bei Aufruf ein Resultat liefert, welches dem Attribut zugewiesen
werden kann.
- 5) Der Benutzer initiiert dann einen Wechsel der Bean Builder
Tools in den Laufzeit-Modus. Hierdurch werden die vorgesehenen Callback-Methoden
der Beans aufgerufen, um auf diesen Wechsel zu reagieren.
- 6) Die Bean versucht nun sofort (oder beim ersten Versuch einer
anderen Bean, einen von dieser publizierten Service zu nutzen) das
entsprechende Stub-Objekt durch Aufruf der Methode getStub() zu
erzeugen. Hierdurch werden ggf. (zum Ermitteln von Attributwerten,
die zur Initialisierung (gemäß folgendem
Schritt) benötigt
werden) Methoden anderer Beans aufgerufen, wodurch wiederum deren
Stub-Objekte (gemäß Schritt
6) erzeugt werden.
Wird eine zirkuläre Initialisierung entdeckt
(Versuch der Initialisieung einer Bean während ihrer Initialisierung),
so wird eine Exception ausgelöst.
- 7) Bei der Initialisierung, die die Erzeugung des Stub-Objekts abschließt, werden
die Service-Usage Beschreibungen der Bean folgendermaßen ausgewertet:
a.
Wenn der Bindungslevel keine Bindung vorsieht, ist man bereits fertig.
b.
Es wird im BeanContext nach einem Service gesucht, der der Konfiguration
entspricht.
c. Die Objekt-Referenz eines so gefundenen Service
wird für
Receptacles und Event Sources direkt als Parameter der 'connect ...' bzw. 'subscribe ...' Methoden verwendet.
Zum Ermitteln eines Attributwerts wird die in der Konfiguration
festgelegte Methode des Service aufgerufen.
- 8) Nach Abschluß der
Initialisierung können
andere Beans die Dienste einer Bean nutzen, indem sie über die
Methoden des BeanContextServices API Objekt-Referenzen der gewünschten
Bean erlangen und dann die Methoden der Service-Klasse aufrufen.
Im Zusammenspiel mit GUI Beans, welche genutzt werden, um Eingabeparameter
zu versorgen (z. B. Text-Felder), Aktionen auszulösen (z.
B. Buttons), und Ergebnisse anzuzeigen, können nun die Services der Beans
und damit die Facets der Komponenten genutzt werden.
- 9) Anschliessend wird der Laufzeit-Modus wieder verlassen – entweder
durch erneuten Wechsel in den Design-Modus, oder durch Beenden des Bean
Builder Tools. Hierdurch werden wiederum die vorgesehenen Callback-Methoden
der Beans aufgerufen, um auf diesen Modus-Wechsel zu reagieren.
- 10) In einem weiteren Verfahrensschritt löst die Bean dann die im siebten
Schritt erzeugten Verbindungen und löscht das Stub-Objekt.
- 11. Der Benutzer initiiert eine Speicherung der Komposition
durch das Bean Builder Tool. Hierbei wird die Java Object Serialization
verwendet, wodurch die gesamte Konfiguration der Bean Properties
erhalten bleibt.
- 12. Die Komposition wird erneut in das Bean Builder Tool geladen.
Da die Konfiguration der Bean-Properties nach wie vor gültig ist,
kann das Tool sofort in den Ausführungsmodus
wechseln. Andererseits kann die Komposition auch im Design-Modus verändert werden.
-
Eine
Nutzung der Erfindung bietet folgende Vorteile:
Die Generierung
der Proxy-Klasse muß nur
einmal bei Bereitstellung der CORBA-Komponente erfolgen. Nur hierbei
ist das Wissen über
die für
das Ermitteln des Stub-Objekts erforderlichen Parameter nötig. Sämtliche
Java-Programme, die die Komponente nutzen wollen, benötigen dann
nur noch die Proxy-Klasse und die zugrundeliegende Java Interface-Definition und können damit
die CORBA-Komponenten benutzen. Durch Nutzung der Konfigurationsmöglichkeiten
in einem BeanContextServices Container (z. B. Bean Builder Tools
wie die Beanbox von Sun Microsystems) können Gruppen zusammenwirkender
Komponenten konfiguriert und in BeanContextServices unterstützender
Laufzeitumgebungen wiederverwendet werden. (z. B. in speziellen Applets
oder Servlets).
-
Der
in den nachfolgenden Ansprüchen
verwendete Ausdruck „Datenträger" soll als möglichst weitgehend
definiert verstanden werden: darunter fallen nicht nur konventionelle
Datenträger
wie Disks, Speicherplatten, CDs und ähnliche optische Datenträger, sondern
auch RAM, ROM, EPROM, Internet und Intranet Server, sowie die Echtzeitübertragung der
entsprechenden Information durch Computer-Kommunikationsnetze. Im
letzteren Fall kann die Trägerwelle
als Datenträger
verstanden werden.