Understand InitialContext lookup - Understanding concepts
I am new to EJB, I am trying to understand the concepts. I am trying to understand example posted on https://glassfish.dev.java.net/javaee5/ejb/examples/Sful.html.
What I don't understand is how Standalone Java Client is doing the lookup and against what is it doing the lookup. Is it just getting the reference from the class that's packaged in jar file ? If so, then how is it maintaining state of the object - isn't that just as using any other class in the package. I would have thought that there would be some trading service like CORBA where server registers the object and client gets the reference to the object. But, in Client examples that I see it isn't clear how it get's the reference to the object that could either be running on the same host or different host in different JVM i.e being deployed by App server.
I am trying to understand specifics and can't seem to get simple and good information about it. Could somebody help me in understanding this.
I want to start this discussion and probably if you guys help me I'll ask some more questions.
# 1
Hi,
When an enterprise bean is deployed in the EJB container, this EJB container will register it into an object directory. For simplicity, I always think it like a file in particular folder in Windows perspective.
How can a client code get an acess to that enterprise bean?
We can use some functionality in JNDI to get that bean. Example
Context jndiContext = new InitialContext();
Object ref = jndiContext.lookup("java:comp/env/ejb/Customer");
CustomerRemote objCustomer = (CustomerRemote)
PortableRemoteObject.narrow(ref,CustomerRemote.class);
First line, we obtain a JNDI context. Then we use that contaxt to lookup or get the bean. In this example, we are getting Customer bean which is stored under java:comp/env/ejb directory. After we retrieve the bean, we cast it into its business interface. The client code will communicate with this business interface.
In the background, EJB container will create an implementation for that business interface (stub) in client's JVM. This stub doesn't do the bussiness process. It just know how to retrieve the request from client code, send the request to EJB container to be processed, retrieve the result from EJB container, and give back the result to client.
Correct me if my understanding is wrong.
Best regards,
Daniel
# 2
I've got same question with mohitanchlia, I am new too in EJB, I understand your explanation but you have not answer how client application know address of host where ejb module reside, (both in sparate machine).
Yayaa at 2007-7-12 19:57:17 >
# 3
Hi,As I know, for enterprise bean objects, those are registered under java:comp/env/ejb/ [enterprise_bean_name].Correct me if I am wrong.regards,Daniel
# 4
When you deploy an application containing an EJB that exposes a Remote interface, the EJB
container registers an object representing the Remote EJB in its naming service. The naming
service lives in the server JVM.The name of the Remote EJB object is vendor-specific. SUN's
approach for assigning global JNDI names (a.k.a. "mapped" names) is here :
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#SessionBeanGlobalJNDINameAssignment
The portable way to retrieve an EJB reference is to define an EJB dependency and access that
dependency via a java:comp/env lookup or through dependency injection.However, those options
are not available to stand-alone Java clients, since stand-alone Java clients are not Java EE
components.Take a look at the approach used by the Application Client in the Sful example to
see the difference.There's more on the difference between Application Clients and stand-alone
Java clients here :
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#AppClientDef
In the case of the stand-alone client, when the no-arg InitialContext is instantiated, the client
JVM bootstraps a naming provider that knows about the server's naming service. That
works because the appserv-rt.jar has a jndi.properties file that controls the bootstrapping.
Since the stand-alone java client can not use the Java EE component environment to access
the EJB dependency, it is forced to explicitly use a global JNDI name instead. In the example
you cited, the global JNDI name has defaulted to the fully qualified name of the remote business
interface.
--ken
ksaksa at 2007-7-12 19:57:17 >
# 5
I would like to chime in with a question about where packages are deployed in the sample code that java4every1 wrote. In order to declare objCustomer as CustomerRemote interface type on the client server we would need to have the ejb's package on the client machine in some capacity. Do we need to deploy the ear file for the Customer bean on the client server or do we just include the ejb class files in the client's war file and only load the interface class via import at runtime of the client? I guess I'm trying to define the footprint that the ejb makes on the client server...thanks
# 6
No, the entire .ear in which the EJB is defined is not a required part of the client.The only classes
that are required are the interfaces themselves and any classes used by those interfaces. The bean
implementation class is not part of the client view.
When the client component (either another EJB, a web component, or an Application Cilent) is
packaged within the same .ear as the target EJB, typically the way those classes are shared is by
putting them in a utility .jar and locating it within a directory called "lib" at the top level of the .ear.
If the client component lives outside of the application in which the EJB is defined, the interface classes
are merely replicated within the client component's packaging.
ksaksa at 2007-7-12 19:57:17 >
# 7
What do you mean by classes used by interface ? How would interface use classes, it should be other way round, could you please give an example.
Also I am not able to understand when do we need ejb-jar.xml file. If we are doing direct lookup then why would we need ejb-jar.xml. Is there somewhere that gives an example with the ejb-jar.xml file. Examples that I've seen don't use ejb-jar file
# 8
The local or remote business interface is the contract between the client and bean itself. The
methods of the interface can have any types for parameters or return values. Those are part of the
contract as well, and therefore must be present in the client's classpath.
public class Foo {
int i;
}
@Remote
public interface SomeInterface {
Foo getFoo();
}
Whether ejb-jar.xml is needed has nothing to do with how a remote client does a lookup.
The existence of ejb-jar.xml only applies to the packaging of an ejb-jar.Within an ejb-jar,
ejb-jar.xml is optional.In many cases it's possible to fully describe the EJB components
using only annotations and the EJB defaults.
The Java EE 5 examples tend not to use ejb-jar.xml. You can reference the J2EE 1.4 tutorial
for examples of ejb-jar.xml.
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/
ksaksa at 2007-7-12 19:57:17 >
# 9
mohitanchlia,
Sounds like you're trying to connect the dots between the docs/tutorials and what you see in the examples. Here's a simple ejb-jar.xml file from <sample install directory>\ejb\stateless\apps\simple\simple-ejb\src\conf. The samples can be downloaded from http://java.sun.com/j2ee/1.4/download.html, choose the Samples Bundle, should be named like j2eesdk-1_4_03-samples.zip.
/******************/
<?xml version = "1.0" encoding = "UTF-8"?>
<!--
Copyright 2004-2005 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
-->
<ejb-jar xmlns = "http://java.sun.com/xml/ns/j2ee" version = "2.1" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
<display-name>GreeterJAR</display-name>
<enterprise-beans>
<session>
<display-name>TheGreeter</display-name>
<ejb-name>TheGreeter</ejb-name>
<home>samples.ejb.stateless.simple.ejb.GreeterHome</home>
<remote>samples.ejb.stateless.simple.ejb.Greeter</remote>
<ejb-class>samples.ejb.stateless.simple.ejb.GreeterEJB</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Bean</transaction-type>
<security-identity>
<use-caller-identity/>
</security-identity>
</session>
</enterprise-beans>
</ejb-jar>
/*****************************/
This file is consumed by the ejb container during deploy so that it knows how to manage it, make it visible to clients, etc.
Once you get familiar with this format, you will then be ready to discard it since EJB 3.0 uses code annotations to replace this file (there may be some cases where it's still needed?). Check out http://java.sun.com/developer/technicalArticles/J2EE/intro_ee5/index.html for explanations of where ejb-jar.xml elements are replaced by code annotations. Here's an example ...
/* in ejb 3.0 */
@Stateless
public class GreeterEJB implements Greeter{...}
replaces <session-type> element. Also note that the ejb implements it's business interface (the remote interface in this case) instead of javax.ejb.SessionBean which is implicit in the @Stateless annotation.
Please correct me if I'm wrong because I'm learning this as I'm writing.
Jim
# 10
So does it mean that from Java EE 5 Sun is trying to do away with various xml files. I am tyring to understand the standard procedure so that I learn things accordingly. Also I am so much confused about various app server implementation. I think JBoss doesn't allow @EJB annotation. Is there any Java EE 5 tutorial that uses these xml files.
Currently I am looking at JNDI tutorial to understand little more about lookups. I'll ask if I have some questions from EJB lookup perspective.
# 11
It's not that the Java EE platform is trying to eliminate .xml for expressing metadata. It's just that in many
cases it has been shown that specifying metadata via .xml is cumbersome and error-prone. For many
kinds of metadata annotations are a better, easier option.
The developer can still express all metadata using only .xml.A combination of annotations and .xml
can also be used, as well as annotations only.
JBoss certainly supports @EJB. @EJB usage is defined by the Java EE specifications. It's not a
vendor-specific annotation.However, there is a separate issue that JBoss has not yet passed the
Java EE 5 certification for its product, so it's possible that some aspects of the Java EE 5 specifications
are not yet implemented in its current release. You can always check the most up-to-date list of
which vendors have passed Java EE 5 certification here :
http://java.sun.com/javaee/overview/compatibility.jsp
ksaksa at 2007-7-12 19:57:17 >
# 12
I am trying to run one simple sample from https://glassfish.dev.java.net/javaee5/ejb/EJB30.html.
I downloaded Sun's App server because I couldn't find j2ee.jar file. Then I included this j2ee.jar in eclipse and also in my build file. But I see that this jar file doesn't have "javax.ejb.Stateless" class that it refers to in one of the examples. Also other classes that it refers to like EJB, Remote doesn't seems to be in J2ee.jar. Is there some other jar file that I need to include along with J2ee.jar.
# 13
m10a,
I can't help you in other areas, but in eclipse open the properties dialog on your ejb3.0 sample project select java build path and in the libraries tab click add external jars.
Browse for <javaee5 install locations>\sun\sdk\lib and select all jar files. This should load all the server jars you need.
By the way, the one that contains javax.ejb.Stateless is javaee.jar. You'll have an easier time finding the classes you want once you get the jars into eclipse.
