Offenbar ist für dich die Frage relevant, sonst würdest du sie nicht stellen. Allerdings kann ich mit der Frage nichts anfangen.
JNDI ist der Namensdienst innerhalb eines Containers (Spring bietet JNDI allerdings auch ohne Container an). Wie bei anderen Namensdiensten stellt JNDI "nur" die Verbindung zu einem angebotenem Service her, unabhängig davon, was das für ein Service ist. Es spielt für JNDI keine Rolle, ob sich bei dem unter dem Namen XYZ angefragten Service LDAP, eine Datasource im Sinne von Datenbank oder auch einem Dienst auf einer komplett anderen Maschine (RMI = Remote Method Invocation) handelt. Er/sie/es ist nur der Vermittler. Das sieht man vor allem auch daran, dass ein lookup weder ein Interface noch eine konkrete Klasse als Rückgabewert sondern lediglich "Object" hat, und dieses gecastet werden muss.
Ich weiß jetzt nicht, in wie weit du das Thema aufgenommen und verstanden hast, daher möchte ich eine Erklärung dafür liefern.
Stelle dir vor, du baust eine Applikation, die Zugriff auf Datenquelle benötigt und hast für diesen Zugriff nur ein Interface und einem Namen. Du weißt also, wie die Datenquelle heißt und was für Operationen sie dir anbietet. Nehmen wir an, die Schnittstelle bietet dir die Operation "findeEntität", "speicherEntität" und "löscheEntität". Der Dienst ist unter dem Namen "Anwendungsspeicher" verfügbar. Mit diesen Informationen gehst du jetzt zu JNDI um Zugriff auf den Dienst zu bekommen. Es wird also eine Anfrage (Look-up) durchgeführt und das Ergebnis auf deine Schnittstelle abgebildet. Jetzt kannst du die Operationen über die Schnittstelle ausführen.
Es interessiert dich aber nicht, wo der Dienst liegt und wie er seine Arbeit konkret erledigt, noch welche Anforderungen er stellt, um seine eigentlich Aufgabe zu erledigen (bspw. Datenbank-Treiber, Messaging-Treiber, Corba-Protokoll-API). Du willst ihn ja nur in Anspruch nehmen. JNDI bekommt über Konfiguration (beim Deployment) mitgeteilt, welche Dienste über Namensauflösung ereichbar sein sollen (z.B. über Annotation oder auch direkte Konfiguration per XML). Der Applikationserver kümmert sich dann darum, dass für deine Schnittstelle ein konkretes Objekt verfügbar ist und du damit die Operationen ausführen kannst.
Und ob der Service nun ein RMI, JPA-JTA-Datasource oder ein LDAP-Verzeichnis ist, ist nicht von Belang.
Jeder Appserver hat natürlich seine eigene Implementierung des Java-Naming-and-Directory-Interface. Ob und welchen Namen die JNDI-Komponenten in den jeweiligen Appservern haben, konnte ich jetzt nicht in Erfahrung bringen. Der JNDI-Service ist allerdings essentiell für den Betrieb eines Applikationservers.
Hier noch ein kleiner Pseudo-Code:
Code:
/**
* Schnittstelle für den Zugriff auf den Applikationsspeicher (Persistenz)
*/
interface Applikationsspeicher
{
public void speicher(Entität e);
public void lösche(Entität e);
public Entität findePerId(int id);
public List<Entität> findePerKriterien(Kriterium ... k);
}
/**
* Applikationsklasse (Geschäftslogik)
*/
class Geschäftslogik
{
Applikationspeicher speicher;
public Geschäftslogik()
{
/** Der parameterlose InitialContext bezieht sich auf den lokalen JNDI **/
Context context = new InitialContext();
this.speicher = (Applikationspeicher) context.lookup("Applikationsspeicher");
}
}
Ich hoffe, ich hab nicht zu viel geschwafelt, hatte nur den Eindruck, es besteht Unklarheit beim Begriff JNDI und was der so macht.