Anwendungsbindungen

Eine auf einem Anwendungsserver installierte Anwendung kann erst gestartet werden, wenn alle in der Anwendung definierten EJB-Referenzen und Ressourcenreferenzen an die tatsächlichen, im Anwendungsserver definierten Artefakte (Enterprise-Beans und Ressourcen) gebunden sind.

Wenn Sie Bindungen definieren, geben Sie für die referenzierbaren und referenzierten Artefakte JNDI-Namen (Java™ Naming and Directory Interface) in einer Anwendung an. Die für Artefakte angegebenen jndiName-Werte müssen qualifizierte Lookup-Namen sein. Eine in einer Anwendung definierte EJB ist ein Beispiel für ein referenzierbares Artefakt. Eine von der Anwendung verwendete EJB-Referenz oder Ressourcenreferenz ist ein Beispiel für ein referenziertes Artefakt.

Bindungsdefinitionen werden in den Dateien ibm-xxx-bnd.xml oder ibm-xxx-bnd.xmi einer Anwendung gespeichert. Die Bindungsdefinitionen der Version 7.0 unterstützen Dateien mit dem Suffix XML für EJB-3.x- und Web-2.5-Module sowie spätere Module. Module vor Java EE 5 verwenden weiterhin die Bindungsdefinitionsdateien mit dem Suffix XMI wie in früheren Versionen von WebSphere Application Server. Die Angabe xxx kann den Wert ejb-jar, web, application oder application-client haben.

Informationen zu Bindungen finden Sie in den folgenden Abschnitten:

Zeitrahmen für das Definieren von Bindungen

Sie können Bindungen zu folgenden Zeiten definieren:

  • Während der Anwendungsentwicklung

    Ein Anwendungsentwickler kann Bindungsdefinitionen in den Dateien ibm-xxx-bnd.xml (für EJB-3.x- und Web-2.5-Module sowie spätere Module) und in ibm-xxx-bnd.xmi (für Module vor Java EE 5) erstellen. Der Anwendungsentwickler kann diese Dateien mit einem Tool wie IBM® Rational Developer oder, für EJB-3.x- oder Web-2.5-Module sowie spätere Module, mit einem XML-Editor oder einem Texteditor erstellen. Die vollständige Unternehmensanwendung (Datei .ear) mit Bindungen übergibt der Entwickler dann an einen Anwendungsassemblierer oder an einen Implementierer. Der Assemblierer wird die Bindungen beim Assemblieren der Anwendung nicht ändern. Außerdem wird der Implementierer, der die Anwendung auf einem von WebSphere Application Server unterstützten Server installiert, die Bindungen nicht ändern oder überschreiben, und er wird auch keine Standardbindungen generieren, es sei denn, eine Änderung der Bindungen ist erforderlich, damit die Anwendung erfolgreich implementiert werden kann.

  • Während der Anwendungsassemblierung

    Ein Anwendungsassemblierer kann Bindungen in Annotationen oder Implementierungsdeskriptoren einer Anwendung definieren. Java EE 5-Module oder spätere Module enthalten Annotationen im Quellcode. Zum Deklarieren einer Annotation stellt ein Anwendungsassemblierer einem Schlüsselwort das Zeichen @ (kommerzielles A) voran. Bindungen für Module vor Java EE 5 werden im Abschnitt WebSphere-Bindungen eines Editors für den Implementierungsdeskriptor angegeben. Beim Ändern des Implementierungsdeskriptors können die Bindungsdefinitionen in den Dateien ibm-xxx-bnd.xmi geändert werden, die beim Entwickeln der Anwendung erstellt wurden. Nachdem die Bindungen definiert wurden, übergibt der Assemblierer die Anwendung an einen Implementierer. Wenn der Implementierer die Anwendung auf einem von WebSphere Application Server unterstützten Server installiert, wird er die Bindungen nicht ändern oder überschreiben, und er wird auch keine Standardbindungen generieren, es sei denn, eine Änderung der Bindungen ist erforderlich, damit die Anwendung implementiert werden kann.

  • Während der Anwendungsinstallation

    Ein Anwendungsimplementierer oder Serveradministrator kann die Bindungen beim Installieren der Anwendung auf einem von WebSphere Application Server unterstützten Server in der Administrationskonsole ändern. Neue Bindungsdefinitionen können auf den Seiten des Installationsassistenten angegeben werden.

    Außerdem kann ein Implementierer oder Administrator festlegen, dass die Standardbindungen während der Anwendungsinstallation generiert werden. Wenn Sie während der Anwendungsinstallation Standardbindungen generieren auswählen, wird das Produkt dazu angewiesen, Standardwerte für die unvollständigen Bindungen in der Anwendung festzulegen. Vorhandene Bindungen werden nicht geändert.

    Einschränkung: Für Anwendungsclients können während der Anwendungsinstallation keine Bindungen definiert oder überschrieben werden. Sie müssen während der Assemblierung Bindungen für Anwendungsclientmodule definieren und die Bindungen in der Datei ibm-application-client-bnd.xmi speichern.
  • Beim Konfigurieren einer installierten Anwendung

    Nach der Installation einer Anwendung auf einem von WebSphere Application Server unterstützten Server kann ein Anwendungsimplementierer oder Serveradministrator die Bindungen modifizieren, indem er Werte auf den Seiten der Administrationskonsole ändert, z. B. auf der Seite mit den Einstellungen für die Unternehmensanwendung.

Erforderliche Bindungen

Vor der Implementierung einer Anwendung müssen für Referenzen Bindungen an die folgenden Artefakte definiert werden:

JNDI-Namen der EJBs
Sie müssen für jede Enterprise-Bean (EJB) der Version 2.1 oder einer früheren Version einen JNDI-Namen angeben. Mit dem Namen wird ein Eintrag für das EJB-Home-Objekt an den globalen JNDI-Namespace gebunden. Der JNDI-Name für eine EJB Produkt in einer Anwendung Lager könnte beispielsweise Lager/ejb/Produkt lauten. Die Bindungsdefinition wird in der Datei META-INF/ibm-ejb-jar-bnd.xmi gespeichert.

Wenn ein Implementierer festlegt, dass die Standardbindungen bei der Installation der Anwendung generiert werden sollen, ordnet der Installationsassistent unvollständigen Bindungen EJB-JNDI-Namen mit dem Format Präfix/EJB-Name zu. Das Standardpräfix ist ejb, es kann jedoch überschrieben werden. Der EJB-Name entspricht der Angabe im Tag <ejb-name> des Implementierungsdeskriptors.

Während und nach der Anwendungsinstallation können EJB-JNDI-Namen auf der Seite JNDI-Namen für Beans angeben angegeben werden. Klicken Sie nach der Installation in der Administrationskonsole auf Anwendungen > Anwendungstypen > WebSphere-Unternehmensanwendungen > Anwendungsname > EJB-JNDI-Namen.

Es ist nicht erforderlich, JNDI-Bindungsnamen für jede EJB-3.x-Home- oder -Geschäftsschnittstelle in Ihren Enterprise-Beans zuzuordnen, da der EJB-Container Standardbindungen zuordnet.

Datenquellen für Entity-Beans
Entity-Beans wie CMP-Beans (Container Managed Persistence) speichern persistente Daten in Datenspeichern. Bei CMP-Beans wird der persistente Status der Beans von einem EJB-Container verwaltet. Welchen Datenspeicher eine Bean verwenden soll, können Sie durch das Binden eines EJB-Moduls oder einer einzelnen Enterprise-Bean an eine Datenquelle angeben. Wird ein EJB-Modul an eine Datenquelle gebunden, verwenden alle Entity-Beans in diesem Modul dieselbe Datenquelle für die Persistenz.

Der JNDI-Name für eine Datenquelle Lager in einer Anwendung Lager könnte beispielsweise Lager/jdbc/Lager lauten. für Module vor Java EE 5 wird die Bindungsdefinition in IBM Bindungsdateien wie ibm-ejb-jar-bnd.xmi gespeichert. Ein Implementierer kann außerdem angeben, ob die Authentifizierung auf Container- oder Anwendungsebene stattfinden soll.

WebSphere Application Server Version 8.x unterstützt CMP-Beans in EJB-2.x- oder EJB-1.x-Modulen. Version 8.x unterstützt keine CMP-Beans in EJB-3.0-Modulen.

Wenn ein Implementierer festlegt, dass die Standardbindungen bei Installation der Anwendung generiert werden sollen, dann generiert der Installationsassistent folgende unvollständige Bindungen:

  • Für .jar-Dateien gemäß EJB 2.x die Verbindungsfactory-Bindungen, die auf dem JNDI-Namen und den angegebenen Berechtigungsinformationen basieren
  • Für .jar-Dateien gemäß EJB 1.1 die Datenquellenbindungen ausgehend vom JNDI-Namen, sowie den Benutzernamen und das angegebene Kennwort für die Datenquelle

Die generierten Bindungen stellen Standardeinstellungen für Verbindungsfactorys für jede .jar-Datei gemäß EJB 2.x und jede .jar-Datei gemäß EJB 1.1 in der zu installierenden Anwendung bereit. Es werden keine Verbindungsfactory-Bindungen oder Datenquellenbindungen auf Bean-Ebene generiert, sofern sie während der Generierung der Standardbindung nicht in der Regel für die angepasste Strategie angegeben werden.

Während und nach der Anwendungsinstallation können auf den Seiten "Datenquellen für 2.x-CMP-Beans und "Datenquellen für 2.x-Entity-Beans" Datenquellen für 2.x-Entity-Beans zugeordnet werden. Klicken Sie nach der Installation in der Administrationskonsole auf Anwendungen > Anwendungstypen > WebSphere-Unternehmensanwendungen > Anwendungsname, und wählen Sie anschließend Datenquellen für 2.x-CMP-Beans oder Datenquellen für 2.x-Entity-Beans aus. Für die Zuordnung von Datenquellen zu 1.x-Entity-Beans können Sie die Seiten "Datenquellen für alle 1.x-CMP-Beans zuordnen" und "Zuordnung der Standarddatenquelle für Module mit 1.x-Entity-Beans angeben" verwenden. Wählen Sie nach der Installation die entsprechenden Konsolseiten aus, wie z. B. für 2.x-CMP-Beans. Klicken Sie jedoch nicht auf Links für 1.x-CMP-Beans.

Back-End-ID für EJB-Module
Wenn eine .jar-Datei einer EJB, die CMP-Beans definiert, Zuordnungen für mehrere Back-End-Datenbanken enthält, geben Sie die geeignete Back-End-ID an, die festlegt, welche Persister-Klassen zur Laufzeit geladen werden.

Geben Sie während der Anwendungsinstallation die Back-End-ID an. Nach der Installation der Anwendung auf einem Server können Sie keine Back-End-ID auswählen.

Gehen Sie zum Aktivieren von Back-End-IDs für einzelne EJB-Module wie folgt vor:

  1. Wählen Sie während der Anwendungsinstallation auf der Seite Installationsoptionen auswählen die Option Enterprise-Beans implementieren aus. Wenn Sie die Option Enterprise-Beans implementieren auswählen, können Sie die Seite Optionen für die EJB-Implementierung angeben zugreifen.
  2. Setzen Sie auf der Seite Optionen für die EJB-Implementierung angeben den Datenbanktyp auf "" (leer).

Wenn Sie während der Anwendungsinstallation die Option Enterprise-Beans implementieren auf der Seite "Installationsoptionen auswählen" auswählen und auf der Seite Optionen für die EJB-Implementierung angeben einen Datenbanktyp für das EJB-Implementierungstool angeben, werden zuvor definierte Back-End-IDs für alle EJB-Module mit dem ausgewählten Datenbanktyp überschrieben.

Der Standarddatenbanktyp ist DB2UDB_V81.

Das EJB-Implementierungstool wird während der Installation von Modulen der EJB Version 3.0 und späteren Modulen nicht ausgeführt.

Weitere Informationen zu Back-End-Datenbanken finden Sie in der Dokumentation zu V8.5.5 im Artikel über das Tool für die EJB-Implementierung und den Befehl ejbdeploy.

EJB-Referenzen
Eine EJB-Referenz (Enterprise-Bean) ist ein logischer Name, mit dem nach der Home-Schnittstelle einer Enterprise-Bean gesucht wird. EJB-Referenzen werden während der Implementierung angegeben. In der Laufzeit werden die Referenzen an die physische Speicherposition (globaler JNDI-Name) der Enterprise-Beans in der Zielbetriebsumgebung gebunden. EJB-Referenzen werden im Java-Naming-Subkontext java:comp/env/ejb oder in einem anderen java:-Namespace bereitgestellt, wenn der Referenzname eine java:module-, eine java:app- oder eine java:global-URL ist. EJB-Referenzen mit URL-Namen sind an den entsprechenden Namespace gemäß URL gebunden.

Das Produkt ordnet JNDI-Standardwerte zu oder löst unvollständige EJB-3.0-Referenzziele automatisch auf.

Für jede EJB-Referenz der Version 2.1 oder einer früheren Version muss ein JNDI-Name angegeben werden. Der JNDI-Name für eine EJB-Referenz Lieferant in einer Anwendung Lager könnte beispielsweise Lager/ejb/Lieferant lauten. Die Bindungsdefinition wird in IBM Bindungsdateien gespeichert, z. B. in ibm-ejb-jar-bnd.xmi. Wenn die referenzierte EJB in demselben Anwendungsserver implementiert wird, können Sie einen für den gesamten Server geltenden JNDI-Namen angeben. Wenn die referenzierte EJB jedoch auf einem anderen Anwendungsserver implementiert wird oder ejb-ref in einem Anwendungsclientmodul definiert ist, sollten Sie den globalen JNDI-Namen, der für die Zelle gilt, angeben.

Wenn ein Implementierer festlegt, dass bei der Installation der Anwendung Standardbindungen generiert werden sollen, bindet der Installationsassistent EJB-Referenzen wie folgt: Wird das Tag <ejb-link> gefunden, wird es berücksichtigt. Stimmt das Tag ejb-name einer in der Anwendung definierten EJB mit dem Namen von ejb-ref überein, wird diese EJB ausgewählt. Wird eine eindeutige EJB mit einer übereinstimmenden Home-Schnittstelle oder lokale Home-Schnittstelle als referenzierte Bean ermittelt, wird die Referenz automatisch aufgelöst.

Auf der Seite EJB-Referenzen Beans zuordnen können Sie während und nach der Anwendungsinstallation die JNDI-Namen von EJB-Referenzen angeben. Klicken Sie nach der Installation in der Administrationskonsole auf Anwendungen > Anwendungstypen > WebSphere-Unternehmensanwendungen > Anwendungsname > EJB-Referenzen.

Anmerkung: Damit EJB-Referenzziele automatisch aufgelöst werden, wenn die Referenzen aus EJB-2.1-Modulen oder früheren Modulen bzw. aus Web-2.3-Modulen oder früheren Modulen stammen, wählen Sie auf der Seite zur Vorbereitung der Anwendungsinstallation die Option Standardbindungen generieren aus, oder wählen Sie auf der Seite Installationsoptionen auswählen, EJB-Referenzen Beans zuordnen oder EJB-Referenzen in der Administrationskonsole die Option Automatische Auflösung von EJB-Referenzen zulassen aus.
Ressourcenreferenzen
Eine Ressourcenreferenz ist ein logischer Name, mit dem nach einer externen Ressource für eine Anwendung gesucht wird. Ressourcenreferenzen werden während der Implementierung angegeben. In der Laufzeitumgebung werden die Referenzen an die physische Speicherposition (globaler JNDI-Name) der Ressource in der Zielbetriebsumgebung gebunden. Ressourcenreferenzen, die keinen URL für den JNDI-Namen verwenden, werden wie folgt zur Verfügung gestellt:
Tabelle 1. Subkontexte für Ressourcenreferenzen. JNDI-Namen des Typs java:comp/env werden für Subkontexte von Ressourcenreferenzen verwendet.
Ressourcenreferenztyp Subkontext für die Deklaration
JDBC-Datenquelle (Java DataBase Connectivity) java:comp/env/jdbc
JMS-Verbindungsfactory java:comp/env/jms
JavaMail-Verbindungsfactory java:comp/env/mail
URL-Verbindungsfactory java:comp/env/url

Anwendungen können Namen Ressourcen, die java:-URLs mit Präfixen wie java:module, java:app und java:global sind, abwechselnd zuordnen. Die URLs werden anderen Namespaces als dem Namespace "component" zugeordnet, der java:comp/env-Namensbindungen enthält. Ressourcenreferenzen mit URL-Namen sind an den entsprechenden Namespace gemäß URL gebunden.

Für jede Ressourcenreferenz müssen Sie einen JNDI-Namen angeben. Wenn ein Implementierer festgelegt hat, dass Standardbindungen bei der Installation der Anwendung generiert werden sollen, generiert der Installationsassistent Ressourcenreferenzbindungen, die vom Tag <res-ref-name> abgeleitet werden. Dies geschieht unter der Voraussetzung, dass der Name von java:comp/env mit dem globalen JNDI-Namen der Ressource übereinstimmt.

Während der Anwendungsinstallation können Sie auf der Seite Ressourcenreferenzen Referenzen zuordnen JNDI-Namen für Ressourcenreferenzen angeben. Geben Sie JNDI-Namen für die Ressourcen an, die die in Ressourcenreferenzen definierten logischen Namen repräsentieren. Optional können Sie für die Ressource den Namen einer Anmeldekonfiguration und Authentifizierungseigenschaften angeben. Klicken Sie nach dem Angeben der Authentifizierungseigenschaften auf OK, um die Werte zu speichern und zur Zuordnung zurückzukehren. Sie müssen jede in einer Anwendung definierte Ressourcenreferenz an eine in Ihrer Konfiguration von WebSphere Application Server definierte Ressource binden. Klicken Sie nach der Installation in der Administrationskonsole auf Anwendungen > Anwendungstypen > WebSphere-Unternehmensanwendungen > Anwendungsname > Ressourcenreferenzen, um auf die Seite Ressourcenreferenzen zuzugreifen.

Bindung von Webmodulen an virtuelle Hosts
Sie müssen jedes Webmodul an einen bestimmten virtuellen Host binden. Die Bindung teilt einem Web-Server-Plug-in mit, dass alle mit dem virtuellen Host übereinstimmenden Anforderungen von der Webanwendung bearbeitet werden müssen. Ein virtueller Host, der an eine Webanwendung Lager gebunden werden soll, könnte beispielsweise den Namen Lager_host haben. Die Bindungsdefinition wird in IBM Bindungsdateien gespeichert, z. B. in WEB-INF/ibm-web-bnd.xmi.

Wenn ein Implementierer festgelegt hat, dass Standardbindungen bei der Installation der Anwendung generiert werden sollen, setzt der Installationsassistent den virtuellen Host für jede .war-Datei auf default_host.

Während und nach der Anwendungsinstallation können Sie einen virtuellen Host einem Webmodul zuordnen, das in Ihrer Anwendung definiert ist. Geben Sie auf der Seite Virtuelle Hosts für Webmodule zuordnen einen virtuellen Host an. Eine Portnummer, die in der Definition eines virtuellen Hosts angegeben ist, wird in dem URL verwendet, mit dem auf Artefakte wie Servlets und JSP-Dateien (JavaServer Pages) im Webmodul zugegriffen wird. Ein externer URL für ein Webartefakt, wie z. B. eine JSP-Datei, könnte beispielsweise wie folgt lauten: http://Hostname:Port_des_virtuellen_Hosts/Kontextstammverzeichnis/JSP-Pfad. Klicken Sie nach der Installation in der Administrationskonsole auf Anwendungen > Anwendungstypen > WebSphere-Unternehmensanwendungen > Anwendungsname > Virtuelle Hosts.

MDBs
Für jede nachrichtengesteuerte Bean müssen Sie angeben, für welche Warteschlange oder welches Topic die Bean empfangsbereit ist. Wenn in der Eingabewarteschlange, die ein JMS-Listener überwacht, eine Nachricht ankommt, ruft der Listener eine nachrichtengesteuerte Bean auf. Ein Implementierer gibt auf der Seite "Beans" des Editors für EJB-Implementierungsdeskriptoren eines Assembliertools unter WebSphere-Bindings einen Listener-Port oder JNDI-Namen für eine Aktivierungsspezifikation an, der in einem Connectormodul (Datei .rar) definiert ist. Der JNDI-Name eines Listener-Ports, der für eine Anwendung Lager verwendet werden soll, könnte beispielsweise LagerMdbListener lauten. Die Bindungsdefinition wird in IBM Bindungsdateien gespeichert, z. B. in ibm-ejb-jar-bnd.xmi.
Wenn ein Implementierer festlegt, dass Standardbindungen bei der Installation der Anwendung generiert werden sollen, ordnet der Installationsassistent unvollständigen Bindungen JNDI-Namen zu.
  • Für nachrichtengesteuerte Beans gemäß EJB 2.0 oder höher, die als JCA-1.5-konforme Ressourcen implementiert werden, ordnet der Installationsassistent JNDI-Namen zu, die Instanzen von activationSpec entsprechen und das Format eis/MDB_EJB-Name haben.
  • Für nachrichtengesteuerte Beans der EJB-Version 2.0 oder höher, die für Listener-Ports implementiert wurden, werden die Listener-Ports aus dem Tag <ejb-name> der nachrichtengesteuerten Bean abgeleitet, und anschließend wird die Zeichenfolge Port angefügt.

Während der Anwendungsinstallation können Sie in der Administrationskonsole auf der Seite Listener für MDBs binden für jede nachrichtengesteuerte Bean den Namen eines Listener-Ports oder den JNDI-Namen einer Aktivierungsspezifikation angeben. Wenn Sie als JMS-Provider den Standard-Messaging-Provider von Version 5, WebSphere MQ oder einen generischen Provider verwenden, müssen Sie den Namen eines Listener-Ports angeben. Werden die Ressourcen der Anwendung mit dem Standard-Messaging-Provider oder einem generischen J2C-Ressourcenadapter mit Unterstützung für eingehende Nachrichten konfiguriert, muss eine Aktivierungsspezifikation angegeben werden. Wenn Sie weder einen Port noch eine Spezifikation angeben und auf Fertig stellen klicken, wird auf der Seite "Zusammenfassung" ein Gültigkeitsfehler angezeigt.

Nach der Anwendungsinstallation können Sie JNDI-Namen und nachrichtengesteuerte Beans auf den Konsolseiten unter Ressourcen > JMS > JMS-Provider oder unter Ressourcen > Ressourcenadapter konfigurieren.

Einschränkung: Sie können nur MDBs binden, die in einem EJB-3.0-Modul an eine Aktivierungsspezifikation gebunden sind.
Nachrichtenzielreferenzen
Eine Nachrichtenzielreferenz ist ein logischer Name, mit dem in einem EJB-Modul, das als Nachrichtenziel verwendet wird, nach einer Enterprise-Bean gesucht wird. Nachrichtenzielreferenzen gibt es nur in Artefakten von J2EE 1.4 oder höher wie den folgenden:
  • Anwendungsclients gemäß J2EE 1.4
  • EJB-2.1-Projekte
  • Webanwendungen der Version 2.4

Sind einem Nachrichtenziellink mehrere Nachrichtenzielreferenzen zugeordnet. wird der der Implementierung ein JNDI-Name für eine Enterprise-Bean erfasst, die dem Nachrichtenziellink und damit allen verknüpften Nachrichtenzielreferenzen zugeordnet ist. In der Laufzeit werden die Nachrichtenzielreferenzen an die verwalteten Nachrichtenziele in der Zielbetriebsumgebung gebunden.

Wenn eine Nachrichtenzielreferenz und eine MDB durch dasselbe Nachrichtenziel miteinander verknüpft sind, müssen die Referenz und die Bean denselben JNDI-Namen für das Ziel verwenden. Wenn beide denselben Namen haben, wird nur der JNDI-Name des Ziels für die MDB erfasst und auf die entsprechende Nachrichtenzielreferenz angewendet.

Wenn ein Implementierer festlegt, dass Standardbindungen bei der Installation der Anwendung generiert werden sollen, ordnet der Installationsassistent unvollständigen Nachrichtenzielreferenzen wie folgt JNDI-Namen zu: Enthält eine Nachrichtenzielreferenz den Tag <message-destination-link>, wird der JNDI-Name auf ejs/message-destination-linkName gesetzt. Andernfalls wird der JNDI-Name auf eis/message-destination-refName gesetzt.

Je nachdem, welche Referenzen Ihre Anwendung enthält und welche Artefakte sie verwendet, müssen Sie unter Umständen Bindungen für in diesem Artikel nicht aufgeführte Referenzen und Artefakte definieren.

Konflikte bei Anwendungsressourcen

In den älteren Produktversionen vor Version 8 wurden anwendungsdefinierte Ressourcen wie z. B. Referenzen und Umgebungseinträge an den Komponenten-Namespace für java:comp/env gebunden. In Version 8.0 und höher kann ein Anwendungsentwickler einen Namen einer Ressource zuordnen, die ein java:-URL mit dem Präfix java:module, java:app oder java:global ist. Jeder dieser URLs wird in bestimmte Namespaces aufgelöst, die sich vom Namespace "component" unterscheiden. Ein Namespace vom Typ java:module wird von allen Komponenten in einem Modul, ein Namespace vom Typ java:app von allen Modulen in einer Anwendung und ein Namespace vom Typ java:global von allen Anwendungen in einer Zelle gemeinsam genutzt. Da die Namespaces gemeinsam genutzt werden, kann es geschehen, dass Ressourcen gleichzeitig genutzt werden, was zu Konflikten führt.

Konflikte auf Modulebene können nur auftreten, wenn zwei Komponenten im Modul Ressourcen desselben Namens definieren. Aufgrund des geringen Umfangs dieses Geltungsbereichs ist es unwahrscheinlich, dass in einem Modul schwerwiegende Konflikte auftreten. Wenn jedoch mehrere Instanzen derselben Ressourcendefinition vorhanden sind, müssen sie dieselbe Konfiguration haben. Beispielsweise müssen zwei EJB-Referenzen auf einen bestimmten EJB-Typ, denen derselbe java:module-Name zugeordnet ist, mit denselben Bindungsdaten konfiguriert werden. Andernfalls entsteht zwischen den beiden Ressourcen ein Konflikt, und die Anwendungskonfiguration schlägt fehl.

Anwendungsbezogene Ressourcen sind wie modulbezogene Ressourcen. Der einzige Unterschied, der im Folgenden gezeigt wird, besteht darin, dass die Definitionen aus einem beliebigen Modul in der Anwendung stammen können. Wie bei Ressourcen auf Modulebene müssen alle Ressourcen auf Anwendungsebene, die denselben Namen haben, demselben Ressourcentyp angehören und mit denselben Bindungsdaten konfiguriert werden.

Globale Ressourcen unterscheiden sich von Ressourcen auf Anwendungs- und Modulebene insofern, als Konflikte zwischen verschiedenen Anwendungen auftreten können. Tritt ein Konflikt auf, können die entsprechenden Anwendungen nicht koexistieren, wenn die Ressourcen logisch nicht gleich sind. Geben mehrere Vorkommen einer globalen Ressource logisch dieselbe Ressource an, müssen sie alle mit denselben Bindungsdaten konfiguriert werden, damit das Produkt sie nicht als miteinander in Konflikt stehend interpretiert. Wenn Sie eine globale Ressource editieren möchten, für die mehrere Anwendungen vorhanden sind, müssen alle definierenden Anwendungen in derselben Sitzung editiert werden, damit kein Konflikt entsteht. Geschieht dies nicht, tritt beim Speichern der Sitzung ein Fehler auf.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_app_bindings
Dateiname:crun_app_bindings.html