Working with WebLogic Server 7.0

BEA WebLogic Server 7.0 is a commercial, J2EE 1.3-compliant server software from the middleware vendor BEA. As mentioned earlier, we use it to run our examples. For this purpose, you will need a copy of BEA WebLogic Server software. You can download this with evaluation license from BEA's website http://www.bea.com.

Installing BEA WebLogic Server 7.0

Follow the instructions at BEA's website to download the WebLogic Server software and install it on your machine. This is a fairly straightforward process. The only thing to keep in mind is that the download size is quite large (more than 150MB for WebLogic Server 7.0 SP2) and you should not attempt the download over a slow connection. Also, you should have sufficient disk space on your machine. It is possible to save some space by deselecting certain components such as WebLogic Integration and WebLogic Portal during installation, but you should have around 500MB available.

During the installation process, you need to specify the BEA home directory and WebLogic Server home directory. The default values for these directories are c:ea and c:eaweblogic700 on a MS Windows machine. For examples in this chapter, we use these default values. At the end of the installation, you will be prompted to run the Configuration Wizard to create an application domain.

Configuring a Domain and Running the Server

A WebLogic domain is an interrelated set of WebLogic Server resources that are managed as a unit. One instance of WebLogic Server in each domain is configured as an Administrative Server. Other instances are known as managed servers and are used to host J2EE applications. A standalone server domain has only one WebLogic Server that hosts the J2EE applications and also acts as the Administrative Server.

We create a standalone server domain for our examples. To do so, run the Domain Configuration Wizard, either immediately after completing the installation or from the Program menu. The Wizard asks a series of questions to create a directory structure, configuration files and server execution scripts for a domain. Select "standalone server domain" and "WLS Domain" template to create a domain with no custom application and give it a name of your choice. Accept default values for the rest of the parameters, except for server name, user name and password. The screenshot in Figure 10-1 shows a typical selection with domain name "test", server name "vishnu", username "testuser" and password "testpass". With these values, the domain specific files are stored in the c:eauser_projects est directory.

To run the WebLogic Server of this domain, launch a command window, go to the domain directory c:eauser_projects est, and run the script startWebLogic.cmd. This script prompts for the domain username and password, prints informative messages such as the port numbers for accepting HTTP and HTTPS connections, full pathname of configuration file config.xml and announces that the Server is running. Figure 10-2 shows a screenshot of such a command window.

As indicated in the startup screen message, WebLogic Server accepts HTTP connections at port 7001 and HTTPS connections at 7002. The same port numbers, i.e., 7001 and 7002, are used for WebLogic specific protocols t3 and t3s (t3 over SSL), respectively.

You can access the default Web application of WebLogic Server by pointing your browser to http://localhost:7001. This application displays an HTML page with links to documentation on WebLogic Server, stored at BEA's website. You can launch the browser-based administrative console by pointing your browser to http://localhost:7001/console and supplying the username (i.e., testuser) and password (i.e., testpass) specified during the domain creation. Play around with the console pages to become familiar with them. Pay particular attention to options under Security → Realms → myrealm. Try adding users, groups and roles using these options. We use these operations later for setting up an appropriate environment for examples. To shutdown the Server, click Server → vishnu (or whatever is the name of your server machine) and click on Control → Start/Stop tab. Now select “Shutdown the Server ...”.

Building Echo EJB

The build process for an EJB application involves:

• compiling the source files,

• creating a jar file with compiled class files and deployment descriptors, and

• running WebLogic EJB compiler, to generate client jar file and supplement the previously created jar file with generated stubs.

Let us carry out these steps for the example program discussed in the section A Brief Overview of EJBs. Recall that all the files of this example are stored in the subdirectory rooted at srcjsbookch10ex1 within the JSTK installation. The relative locations of all the files are shown below:

echoEcho.java
    EchoBean.java
    EchoHome.java
clientClient.java
META-INFejb-jar.xml
        weblogic-ejb-jar.xml

We have looked at the content of all these source files except for weblogic-ejb-jar.xml. This file contains the WebLogic Server specific deployment configuration and is shown in Listing 10-4.

Listing 10-4. WebLogic Server specific deployment descriptor

<?xml version="1.0"?>

<!DOCTYPE weblogic-ejb-jar PUBLIC
'-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN'
'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>

<weblogic-ejb-jar>
  <weblogic-enterprise-bean>
    <ejb-name>Echo</ejb-name>
							<jndi-name>ex1-echo-EchoHome</jndi-name>
  </weblogic-enterprise-bean>
</weblogic-ejb-jar>

Notice that this file specifies the JNDI Name of the Echo bean as "ex1-echo-EchoHome", the same string used in the client program of Listing 10-3. Besides this, many other WebLogic Server-specific configuration details could be specified in this deployment descriptor. We come across some of these later in this chapter.

The first step of the build process is to set the appropriate environment variables. As we need to do this for every example, it makes sense to have all the set statements in single script file. This file, shown in Listing 10-5, is named wlenv.bat and can be found in the directory src/jsbook/ch10. It can either be run at the command prompt or invoked from other scripts.

Listing 10-5. Script file wlenv.bat

set BEA_HOME=c:ea
set JAVA_HOME=%BEA_HOME%jdk131_06
set WLS_HOME=%BEA_HOME%weblogic700server
set CP1=%JAVA_HOME%lib	ools.jar;%WLS_HOME%libweblogic_sp.jar
set CLASSPATH=%CP1%;%WLS_HOME%libweblogic.jar
set JAVA=%JAVA_HOME%injava
set JAVAC=%JAVA_HOME%injavac

Run this script to set the environment variables:

C:ch10ex1>..wlenv
						

Next, create build directory to store all the files that would go in the jar file echo.jar and copy the deployment descriptor files from META-INF directory:

C:ch10ex1>mkdir build
C:ch10ex1>mkdir buildMETA-INF
C:ch10ex1>copy META-INF* buildMETA-INF
						

Compile the source files so that the class files are created in the build directory:

C:ch10ex1>%JAVAC% -d build echo*.java
						

The build directory now has all the compiled classes and deployment descriptor files in a directory structure appropriate for EJB application. Let us archive this directory in the jar file echo.jar:

C:ch10ex1>jar cvf echo.jar -C build .
						

The next step is to run the EJB compiler. This command not only creates the echo_client.jar file (recall that this filename was specified in the deployment descriptor ejb-jar.xml) but also modifies the echo.jar file by adding generated class files:

C:ch10ex1>%JAVA% -Dweblogic.home=%WLS_HOME% weblogic.ejbc 
							-compiler javac echo.jar
						

The last step is to compile the client program. This requires the generated echo_client.jar to be in CLASSPATH:

C:ch10ex1>%JAVAC% -classpath %CLASSPATH%;echo_client.jar 
							-d build clientClient.java
						

We are now done with the build process and the Echo EJB application is ready to be deployed.

Though we carried out all the build steps individually, you will most likely use a build script or an IDE (Integrated Development Environment). You can find one such build script comp.bat in the subdirectory ch10ex1.

Deploying Echo EJB

There are many different ways to deploy an EJB application file to the WebLogic Server. You can use the Web-based console; modify the configuration file config.xml in the WebLogic domain directory to include an entry for the application, or copy the EJB jar file to the applications subdirectory of the domain directory. Let us deploy Echo EJB by adding an entry into config.xml. The modified file would look like this:

<Domain ConfigurationVersion="7.0.2.0" Name="test">
  <Application Deployed="true" Name="DefaultWebApp"
    Path=".applications" StagedTargets="" TwoPhase="false">
    <WebAppComponent Name="DefaultWebApp"
      Targets="vishnu" URI="DefaultWebApp"/>
  </Application>
  <Application Deployed="true" Name="echo_jar" Path="c:ch10ex1"
							StagedTargets="vishnu" StagingMode="nostage" TwoPhase="true">
							<EJBComponent Name="echo" Targets="vishnu" URI="echo.jar"/>
							</Application>
  ... skipped ...
</Domain>

You should replace the directory "c:ch10ex1" as Path value with the directory name in your setup. Now start the WebLogic Server by running startWebLogic.cmd script . EJB application Echo is deployed and ready to be invoked.

Running the Client

To run the client program against WebLogic Server running on a local machine and listening for t3 connections on port 7001, issue the following commands from example directory c:ch10ex1:

C:ch10ex1>..wlenv
C:ch10ex1>%JAVA% -cp %CLASSPATH%;echo_client.jar;build 
							client.Client t3://localhost:7001
Calling Echo..echo("Hello, World!!") ...
... Echo.echo("Hello, World!!") = Hello, World!!
Echo Client Executed successfully.

Look at the output on the the WebLogic Server window:

							... startup notices skipped ...
EchoBean.setSessionContext called
EchoBean.ejbCreate called
--- BEGIN EchoBean.echo("Hello, World!!") ---
--- END EchoBean.echo("Hello, World!!") ---

Great! You just got your first EJB application up, running and invoked.

At this moment, it is instructive to match this output with the sources shown in Listing 10-3 and Listing 10-1, respectively.

In the previous invocation, the client program used BEA's proprietary t3 protocol to connect to the WebLogic Server. As we mentioned earlier, it is also possible to use IIOP protocol. To use this protocol, you need to specify –iiop option to the weblogic.ejbc command while compiling the EJB jar file:

C:ch10ex1>%JAVA% -Dweblogic.home=%WLS_HOME% weblogic.ejbc 
							-iiop -compiler javac echo.jar
						

You should stop the WebLogic Server before running this command, for this command rewrites the echo.jar file. Rewriting will fail if the Echo bean is deployed and the jar is being used by the WebLogic Server.

Once you have run the EJB compiler, restart the WebLogic Server and run the client, this time with an IIOP URL:

C:ch10ex1>%JAVA% -cp %CLASSPATH%;echo_client.jar;build 
							client.Client iiop://localhost:7001
						

The output in this window and in the window running the WebLogic Server should be the same as in the previous client run. In practice, t3 is faster than IIOP, and is recommended when both client and server are using WebLogic.

At this moment, let us step back and go over the various components of the example program. We have the client program running in a separate JVM and communicating with the Server JVM, potentially on a different machine. There are also a number of Java objects in both JVMs. Figure 10-3 shows various objects of interest and their interaction.

What security issues do you see with this program? Here are a few:

• If the WebLogic Server is running on a machine connected to a network then anyone can write a program to invoke the Echo bean methods. An innocuous method like echo() does not pose any problem but this is an issue with sensitive methods, like credit() on an Account bean that could take out money from a real customer account.

• The echo() method has no user associated with it. If it is to do something significant on behalf of a real user, it should be running under the identity of that user.

• All the traffic between the client and server is vulnerable to normal network-related attacks: anyone having access to the network can snoop on the messages; alter them; run them at a later point in time; subvert them to a different machine, and so on.

We modify certain parts of this example in the following sections to illustrate how these issues can be addressed by the proper use of EJB security mechanisms.