Hello Ranchers, well I am working in ejb 3 in my current project but i dont know indepth of ejb, as only this time i just read about ejb first time, while doing this current project. i don't understand the concept of JNDI, much can you please help me to know it .. here are some code from my project...
there is code "servicelocator.java" class doing jndi work whcih i didn't understand (pls explain me every stuff, step by step) and code that is calling it..
One of the reasons why no one has answered this question might have to do with the fact that this needs lot of explanation if you are new to EJB. But, let me give it a try.
So your first question: What is difference between local and remote interfaces for EJB and when to use which?
Local interfaces are meant to be used when the EJB client will be part of the same JVM where the EJB is deployed. If the EJB client is on some other JVM (remote) then the remote interface comes into picture. When you use remote interfaces, the objects that get passed from the client to the EJB are serialized and deserialized. In case of local interfaces this is not the case, the objects are passed by reference. This is just a short explanation on remote and local interfaces.
Your next question: how we formulate JNDI name ?
JNDI name is just a name that you would use to identify the object that is bound in the JNDI tree. In case of EJB's the home objects are bound to the JNDI tree. The application will provide a unique name to be used to bind the home object in the JNDI tree. If you look at the code that you have posted, there's something like:
Context ctx = new InitialContext(); Object obj = ctx.lookup("someName");
This is the point where you are doing the lookup of the object in the JNDI tree. First you get hold of the context in the JNDI tree and then do a lookup in that context.
JNDI, the Java Naming and Directory Interface, is one of the most important J2EE services your applications will employ.
J2EE components are interesting and powerful because the can take advantage of a variety of features and services that are implemented and managed by the J2EE application server; However, most of these services and features are created, initialized, maintained and exist outside of the Java code our developers write.
Applications must be capable of accessing these server managed J2EE services. The first step towards gaining access to these resources is looking them up through a directory naming service.
What J2EE components and services are accessed initially accessed through JNDI?
A short list of the elusive enterprise objects initially accessed though a naming service includes:
F Remote Enterprise JavaBeans F DataSources F Transaction Objects F Custom Services F Message Queues F Local Enterprise JavaBeans F Mail Servers
All enterprise environments, be it CORBA or .Net, use the facilities of a naming service. In a J2EE environment, the Java Naming and Directory Interface (JNDI) provides our components access to the underlying naming service implemented by the Application Server.
How does a naming service work?
When WebSphere boots, a variety of resources are initialized and subsequently bound to the naming service.
The first step in accessing a JNDI bound resource, such as an EJB, is to look up the resource according to its JNDI bound name. The naming service will then return to the client a reference to the object of interest.
A Conversation Between JNDI and an EJB at Start-Up
EJB: Hey, JNDI, do you know who I am?
JNDI: Ya, you�re a really important EJB.
EJB: That�s right, and people are going to be coming around these parts asking for me.
JNDI: What�s your name?
JNDI: Great. And when someone asks, where should I send them?
EJB: Point them to my home. It�s the big mansion on the corner.
JNDI: Will do! After all, binding names to objects is what I do best!
Who assigns resources their JNDI names?
When resources such as DataSources and message queues are created and configured by the administrator, the JNDI name is one of the configurable properties.
For the most part, the WebSphere administrator has the final say over the name a resource will use when binding itself to JNDI.
A naming service uses a directory, or folder structure, to keep track of objects and their corresponding names.
For example, EJBs usually go under a sub-directory named ejb, and database related objects usually go under a subdirectory named jdbc. An InitialContext is a connection to the root or base directory of the naming service, off of which all folders or subdirectories branch.
To use an analogy, if the Windows operating system was a directory server, the InitialContext would be the root, C:\, since all folders and subdirectories sprout from there.
Figure 18-1 Exploring a JNDI Tree
Objects are bound to a directory in a tree like structure.
When looking up an object bound to a JNDI server, we reference the name of the object relative to the root of the directory, or as we say in developerspeak, we reference the InitialContext.
How does JNDI help with distributed programming?
To obtain a reference to an EJB running on a remote server, we must first connect to the naming service on that server. Once we have a connection to the remote naming service, we provide the JNDI name of the desired EJB. If we provide the correct name, the naming service will return a reference to the EJB in question.
How do I look up a JNDI addressable resource?
When a connection pool is created, or an EJB is deployed, those resources are configured with a JNDI name.
A DataSource might be bound to the naming service with the name jdbc/pulpds, or and EJB might be bound with the name ejb/com/pulpjava/session/Timer.
To lookup a JNDI addressable resource in your application, your Java code would look something like this:
Of course, you would never, ever, want to hard code into your Java the name with which your EJB is bound to the naming service. There�s a whole whack of reasons why, not the least of which is the fact that the name you use to reference your EJB or DataSource at development time might be very different from the name the WebSphere Administrator gives to the resource at runtime.
�Develop one way, deploy another, and use configurable bindings to tie the two together.�
Figure 18-2 Configuring a Resource Reference in web.xml
The development name jdbc/ExamBankDS,which is mapped to the name jdbc/db2/ExamAppDS, which is the name used at runtime.
What is so bad about hard coding JNDI names into your code?
If you hardcode the names of JNDI addressable resources into your applications during the development phase, and the name of those resources happen to change at runtime, your applications will not work To avoid this problem, we use something called a resource reference to loosely bind the names used in our code to the actual name given to a J2EE resource at deployment time. At least, that�s what we should do.
How does a resource reference work?
Never hardcode a JNDI name in Java code. Code the name of a resource reference instead.
For example, if an EJB is bound to the JNDI server with the name ejb/com/pulpjava/session/Timer, a resource reference with the name ejb/Timer could be configured to point to this EJB.
In your code, you would perform a lookup against the name java:comp/env/ejb/Timer, which is the full name of the resource reference. The WebSphere environment recognizes anything under java:comp/env/ as a resource reference lookup. In this case, WebSphere will find a resource reference that binds the abstract name ejb/Timer with the actual ejb named ejb/com/pulpjava/session/Timer, and at runtime, a reference to the ejb/com/pulpjava/session/Timer will be returned to the client.
If the actual name of the EJB running on the server ever changes, the application assembler would only be required to change the binding between the resource reference and the actual name of the EJB. No change to the code would need to be made.
Resource references area great!
What does a resource reference lookup look like?
Resource references include the String �java:comp/env/� before the name of the configured reference name.
To look up an ejb with the JNDI bound name of ejb/com/pulpjava/session/Timer, using a resource reference of ejb/Timer, your code would look something like this:
Notice how when using the resource reference, we use the prefix java:comp.
The last line of code in this example looks up the Timer EJB according to the name used when binding the timer to the naming service. This is not a scalable or easily maintainable solution, and should never be done in production code.
What does java:comp/env/ejb/Timer mean?
Interpreting java:comp/env/ejb/Timer goes something like this:
Using the connection to a JNDI server, connect to the common Java namespace (java F Look for a component bound to the common environment of the name service (comp/env) F Find, in the deployment descriptor of the calling resource, a reference for ejb/Timer F Resolve the resource reference � in this case:
ejb/Timer (the resource reference) resolves to ejb/com/pulpjava/session/Timer
F Return to the client a reference to the resolved resource
Where are resource references stored and configured?
A resource reference is an abstract binding configured in the deployment descriptor of the J2EE module of the component that uses it.
For example, if a Servlet uses a resource reference, the deployment descriptor for the web module would contain the resource reference. If an EJB used a resource reference, the ejb-jar.xml file, which is the deployment descriptor for an EJB module, would contain the resource reference.
When the application assembler prepares the application for deployment, they will configure the bindings and make sure the abstract name in the web or ejb module maps to the appropriate resource running on the server. After all, the name of the resource in the development environment will likely be different from the name of the resource in the pre-production (pre-prod) or testing environment.
Again, develop one way, deploy another, and use configured bindings to tie the two together. Resource references make this happen.
Isn�t configuring resource references and doing these bindings a lot of work?
The extra configuration the administrator or application assembler must perform before deployment does constitute a bit of extra work, but it is not a huge burden. It sure beats having to dig into the code and fix all of the hard coded JNDI name references if the runtime name of a given resource ever changes. Besides, WebSphere Administrators never have much to do anyways � they like the extra work.
How has naming changed between WebSphere 4 and WebSphere 5?