Home: www.vipan.com Vipan Singla e-mail: vipan@vipan.com
EJBs Demystified
includes JDBC and JNDI Access

Some Information on Weblogic

A Simple EJB Example (Stateless Session EJB)

EJBs Demystified

  • An EJB is a way to instantiate an object in a different Java Virtual Machine(JVM) than the one your code is running in. You can then call this "remote" object's methods just as if you would call the methods of an object you instantiated in your own code by calling new (i.e. a local object).

    The second JVM may be on the same computer as your code is on, or it may be on a networked computer accessible through a URL.

    If you want, EJB servers can also automatically access databases and manage database transactions for you (entity EJBs with container-managed-persistence) without any coding on your part.EJB vs. RMI/CORBA

  • In essence, EJBs combine the best practices of Java RMI and CORBA to make an enterprise's business logic and data available to any client on the network.

Stateless session EJB

Stateful Session EJB

Entity EJB

Coding an EJB

  • All methods in both "home" and "remote" interfaces must throw java.rmi.RemoteException.
  • All method arguments, return values and exceptions in both "home" and "remote" interfaces must be serializable (as they are sent over the wire).
  • Don't write any classes that actually implement the "home" and "remote" interfaces. EJB server will write these classes for you which call the corresponding methods in the EJB class that you write. This EJB class must implement either SessionBean or EntityBean. For each method that you declared in the "home" and "remote" interfaces, you will write the method definitions in the EJB class (some method names will need to be prefixed with the word "ejb").

Deployment Steps

  1. Compile EJB classes and interfaces. You don't need Weblogic (or some other EJB server) specific library classes or JAR files to compile a spec-compliant EJB. You only need your code classes and the standard "j2ee.jar" file in your classpath. The "j2ee.jar" file comes with the J2EE software from Sun Microsystems. For example, enter this command on one line:
    java -verbose -d c:\junk2 -classpath c:\junk2;
       c:\j2ee\j2ee.jar -sourcepath c:\junk c:\junk\pkg1\subpkg1\src-file.java 
  2. Here is a suggested compilation order:
    1. EJBObject sub-interface
    2. Primary key class, if Entity EJB
    3. EntityBean or SessionBean subclass
    4. EJBHome sub-interface
  3. JAR your compiled classes. Make sure that you preserve the package structure as the directory tree within the JAR file. There should be no directory visible above the package's root directory (below which all package directories are located) within the JAR file. Run jar tvf to list the JAR file contents, just to make sure. This is a standard Java requirement.

    The best way to do this is to first change your current directory to just above the first directory of your package structure

    cd c:\junk2
    jar cvf c:\junk2\junky.jar pkg1  

    This will have the effect of starting with the first directory within your package structure and recursively bundle all files and subdirectories within it, preserving the directory tree.

    If you have multiple packages, run the jar uvf your-filename.jar command on each package but after changing directory to the root of each package.

  4. Write a "META-INF/ejb-jar.xml" text file in XML format as required by the EJB spec. It is easier to open an existing file (probably provided as an example with your EJB server), modify it and save it as "ejb-jar.xml" under a "META-INF" subdirectory within your source code directory.
  5. Update your JAR file to include the "META-INF/ejb-jar.xml" file. First change directory to just above the META-INF directory. For example, if "c:\junk" has the "META-INF" directory under it:
    cd c:\junk
    jar uvf c:\junk2\junky.jar META-INF 

    "META-INF" must be written in all uppercase letters even if your operating system (Windows) is not case-sensitive (because Java is!).

  6. You now have the JAR file you need to deploy your EJB in any EJB server in a server-specific way. Notice that you have not needed any server-specific classes or libraries to compile the .java files.
  7. Update your JAR file to contain the server-specific XML files (e.g. "META-INF\weblogic-ejb-jar.xml"). Write and place additional XML files in the "META-INF" directory containing the "ejb-jar.xml" file.
    cd c:\junk
    jar uvf c:\junk2\junky.jar META-INF 

    Note that this will pick up all the files and subdirectories of the "META-INF" directory and bundle them into the JAR file.

  8. Some servers need RMI stubs, skeletons and other supporting classes in your JAR file before they can deploy it. You don't have to write any code, just run the server-supplied tool to generate what server needs.

    Other servers take your JAR file and generate these on the fly as needed during startup and deployment.

    For Weblogic, you need to run a command to do so.

    java weblogic.ejbc c:\junk2\junky.jar c:\junk\junkyForWeblogic.jar
  9. If all goes well (i.e. your code checks out OK), the computer, after a while, will come back with:
    [EJB]: Creating output jar:wantedFinalJar.jar
  10. For Weblogic, add the JAR file name in your server's "weblogic.properties" file. Be careful! Only use "/" as path separator because you will use "\" as line-continuation character.
    weblogic.ejb.deploy=  \
       c:/junk2/junky.jar,    \

    The "weblogic.ejb.deploy" property can only appear in one place and all comma-separated JAR files are to be added there.

  11. Restart the server for the changes to take effect.

Hot Deploy to a Running Weblogic Server

Weblogic XML Deployment Files Examples

EJB Client

Coding an EJB Client

Transactions and EJBs

Username/Group based Access to EJB Methods

JDBC - Accessing Databases in Java Code

(Redundant) Notes on JNDI

  • Java Naming and Directory Interface (JNDI) allows you to give common, well-known names to your objects. JNDI enables Java programs to connect to real-life directory services. Programming to use a directory service is just about as hard as programming to use an RDBMS.
  • A "naming" service is almost similar to a computer's directory tree with files at the lowest level of each node in a tree.
  • A "directory" service allows assigning attributes (e.g. date modified for a file) to bound objects where as a naming service does not (just a name is assigned to a real thing, no attributes).

    Popular keys for object attributes are "c", "o", "ou", "cn" (common name or first name) and "sn" (last name). The values for these keys are "objects" which are vendor-proprietory.


Home Handle

Remote Object's Handle

Miscellaneous Information

© 2000 Vipan Singla