This report describes the tests I made and the process of testing performed for the EJB security component of the NetDynamics server.
NetDynamics Application Server. 5.0.0.22 SP2. For Windows NT 4.0 + ND patch 40-REFRESH, and Solaris 5.6 + ND patch 40-REFRESH.
The container is responsible for enforcing the security rules. It will enforce that the EJB security methods in a bean at run-time are allowed to be called by the caller (bean client). This is done by checking for the security role and the principle of the context that the call is made under.
The principle is the name assigned to the SECUIRTY_PRINCIPLE by the caller.
The role is the name of the role (or group) that the principle belongs to.
The container will check that the bean method is allowed to be called by the principle making the call, by checking that the SECURITY_PRINCIPLE of the caller belongs to a role that the bean methods belongs to.
Roles are assigned to methods at design time of the bean, using the ND studio. The container will read this information from the deployment serialized file when it first loads the bean class. The mapping of the principle name to a role is already known to the server, this was done earlier by loading the file called ejbUsers.txt into the server.
A stateful session bean context is fixed when the bean is created (when the ejbCreate() method is called). It is not allowed to change the context of the stateful session bean after it was created.
Figure 1 illustrates some of the above discussion.
For web projects testing, the client will access the bean using a web server.
The client sends a URL string which contains the name of the web plugin, and the name of the page to invoke. The webserver will then invoke the plugin executable and pass it the information. The plugin will then communicate with the ND plugin server, the ND plugin server then passes the data to a CP worker, which creates the bean using information from the web server environment variables that was passed to it from the web plugin via the ND plugin server.
The web plugin knows where the ND plugin server is by looking up its IP address from a file called plugin.nd.
The ND plugin Server then returns the web page back to the client via the web plugin. Additional requests/responses will follow this pattern. see figure ?? for illustration.
The following is an example of URL send from the client to the application server to bring up a web page:
http://localhost/SCRIPTS/nd_CGI_50.exe/securityTestsWeb/Stateless3Page?^start=&^uniqueValue=934486027
Figure 2 illustrates this.
We first list the steps needed to run the tests from the standalone clients, then show more details on each step.
In General, these are the steps needed to run the tests
Netdynamics application server EJB service is an EJB container that meets 1.0 EJB specification. Some of the services mentioned in the specification are:
Diagram 3 Illustrates a high level view of relationship between the server, the container, and the EBJ instances.
A client uses JNDI to locate a reference to the Home object. The Home object is the name given to implementation of the Home interface of the bean. Once the client has obtained this reference, it will call the create() method in the Home object. This causes the container to create the bean instance, and to allocate a remote interface object on the server side (called EJBObject), which it then return its reference back to the client. The client then uses the reference to the remote object to access the business methods inside the bean.
The client does not have a direct reference to the bean class instance itself, but to the implementation of its remote interface. The remote interface then calls the business methods in the bean on behave of the client.
So, the remote interface implementation, called EJBObject, is the one the calls the bean business methods. In addition, the EJBObjec communicate with the container to determine security and transaction context of the bean, since the container is the one who have knowledge of such information.
So, the EJBObject, the implementation of the remote interface, acts as a remote proxy for the bean instance.
The bean itself is not a network object, and can not be accessed directly over the network. Access to the bean must occur via its proxy, the EJBObject. Both the EJBObject, and the bean must reside in the same container.
Each bean instance, has a corresponding EJBObject instance. The EJBObject instance contains a reference to the bean instance, which the container initialized the EJBObject with when the bean was created.
The same Home interface can be used to create more instances of the bean (implying more instances of EJBObject).
Figure 4 Illustrates some of the above concepts.
The following are additional specific notes written down during EJB overview meeting given by ELain.
We now look at the classes involved in implementation of EJB. First, we look at the classes used to implement the client side of the Home and Remote interfaces.
Figure 5 shows the relationship.
This is a report on how to setup and run the J2EE Compatibility Tests for servlet/JSP for ND 5.0 SP2.
Directory structure
To make it easier to setup the test environment, I’ll first show a diagram of how the directory structure should look like before running the tests.
Assume that you will install everything on the C: drive. (On UNIX, simply replace the C: in the diagram with the root where you will installed the software.
In This diagram, I’ll also show the files that you need to edit/configure before running the tests.
some root (example C:\ or /) | | | | +--------------------+-----------------+----------------+-------------------+ | | | jdk1.2.1/ | qa/ NetDynamics/ j2eects/ temp/ | | | +---------+ | | | | | | Servlets/ wwwroot/ bin/ +-----+------------+ | | | | | | AllTestsJTReport/ AllTestsJTWork/ Tests/ cts_env.bat | jets.bat AllTestSuite.html AllTestSuite.jtp netdyn.jte netdynurl.maps
To set up the above directory, download the J2EE CTS and install it. Look for the file j2eects.tar.gz in the J2EE related web page. extract the content of the above tar file to create the /j2eects directory. Look at the CTS user guide for any special configuration before starting going further.
The latest qa directory shown above can be obtained from CVS (when it is on-line :)
Install JDK 1.2.1 (Make sure it is JDK 1.2.1 since that is the one j2EE CTS supports.
