The EJB Query Language (EJB-QL) - Part 1

The EJB Query Language (EJB-QL)

Part -1
In this article, we will fully understand the syntax and semantics of the EJB Query Language (EJB-QL), which is the language that you use to describe query methods for container-managed persistent entity beans.

Overview
EJB-QL is a standard and portable language for expressing container-managed persistent entity bean query operations. These entity bean query operations can include finder methods (used by external entity bean clients), as well as select methods (used internally by the entity bean itself). EJB-QL is not necessary for bean-managed persistence because the bean provider writes the database access code, which is integrated into the entity bean class itself.

EJB-QL is a new addition to EJB 2.0. Before EJB 2.0, you would need to explain to the container how to implement your query operations in a proprietary way.

For example, you might bundle a container-specific flat-file with your bean. This flat-file would not be portable to other containers, which is very annoying for bean-providers who wish to write components that are container-agnostic.

Throughout this appendix, we will use an E-Commerce object model to illustrate EJB-QL, using such entity beans as orders, line-items, products, and customers. We designed that object model in Chapter X.

A simple example
Let's kick things off with a simple EJB-QL example. Take the following entity bean remote finder method:
public java.util.Collection findAvailableProducts() throws FinderException, RemoteException;
This finder method means to find all products that are currently in-stock.

The following EJB-QL in the deployment descriptor will instruct the container on how to generate the database access code that corresponds to this finder method:
...


Product
examples.ProductHome
examples.Product
examples.ProductBean
Container
examples.ProductPK
False

2.x
Product


inventory

...more container-managed persistent fields...



findAvailableProducts




0]]>



...

In the code above, we are putting together a query that resembles SQL or ORQL (see Chapter X for more on OQL). We can refer to entity beans inside of the EJB-QL by using that entity bean's abstract-schema-name defined earlier in the deployment descriptor. We can also query its container-managed fields or container-managed relationships, or other entity beans.

In fact, if we're using a relational database, the container will translate this EJB-QL code into SQL code in the form of JDBC statements.

The following SQL is an example of what might be generated depending on your container implementation:

SELECT DISTINCT p.PKEY
FROM PRODUCT p
WHERE p.INVENTORY > 0

The above SQL returns primary keys (not rows) back to the container. The container than wraps those primary keys in EJB objects and returns RMI-IIOP stubs to the client who called the finder method. When the client calls business methods on those stubs, the EJB objects will intercept the call, and then the ejbLoad() method will be called on the entity beans.

The container will then load the actual rows from the database. Note that this process may be optimized depending on your container implementation.

The power of relationships
The big difference between EJB-QL and SQL is that EJB-QL allows you to traverse relationships between entity beans using a dot-notation. For example:

SELECT o.customer
FROM Order o

In the above EJB-QL, we are returning all customers that have placed orders. We are navigating from the order entity bean to the customer entity bean easily using a dot-notation. This is quite seamless.

What's exciting about this notation is that bean providers don't need to know about tables or columns, rather they merely need to understand the relationships between the entity beans that they've authored. The container will handle the traversal of relationships for us because we declare our entity beans in the same deployment descriptor and ejb-jar file, empowering the container to manage all of our beans and thus understand their relationships.

In fact, you can traverse more than one relationship. That relationship can involve container-managed relationship fields and container-managed persistent fields. For example:

SELECT o.customer.address.homePhoneNumber
FROM Order o

The restriction on this type of recursive relationship traversal is that you are limited by the navigatability of the relationships that you define in the deployment descriptor. For example, let's say that in the deployment descriptor, you declare that orders have a 1-to-many relationship with line-items, but you do not define the reverse many-to-1 relationship that line-items have with orders. When performing EJB-QL, you can then get from orders to line-items, but not from line-items to orders. For more about how to define these types of relationships, see Chapter X in next article.

Virtual Functions in C++

C++ virtual function is a member function of a class, whose functionality can be over-ridden in its derived classes.
The whole function body can be replaced with a new set of implementation in the derived class. The concept of c++ virtual functions is different from C++ Function overloading.

C++ Virtual Function - Properties:

C++ virtual function is,

• A member function of a class
• Declared with virtual keyword
• Usually has a different functionality in the derived class
• A function call is resolved at run-time

The difference between a non-virtual c++ member function and a virtual member function is, the non-virtual member functions are resolved at compile time.

This mechanism is called static binding. Where as the c++ virtual member functions are resolved during run-time. This mechanism is known as dynamic binding.

C++ Virtual Function - Reasons:
The most prominent reason why a C++ virtual function will be used is to have a different functionality in the derived class.

For example a Create function in a class Window may have to create a window with white background. But a class called CommandButton derived or inherited from Window, may have to use a gray background and write a caption on the center. The Create function for CommandButton now should have a functionality different from the one at the class called Window.

C++ Virtual function - Example:
This article assumes a base class named Window with a virtual member function named Create. The derived class name will be CommandButton, with our over ridden function Create.


class Window // Base class for C++ virtual function example
{

public : virtual void Create()

// virtual function for C++ virtual function example
{

cout <<"Base class Window";

}

}
class CommandButton : public Window
{

public:void Create()
{

cout<<"Derived class Command Button - Overridden C++ virtual function"

y = new CommandButton();

y->Create();

}

The output of the above program will be,
Base class Window
Derived class Command Button

If the function had not been declared virtual, then the base class function would have been called all the times. Because, the function address would have been statically bound during compile time. But now, as the function is declared virtual it is a candidate for run-time linking and the derived class function is being invoked.

C++ Virtual function - Call Mechanism:
Whenever a program has a C++ virtual function declared, a v-table is constructed for the class. The v-table consists of addresses to the virtual functions for classes and pointers to the functions from each of the objects of the derived class.

Whenever there is a function call made to the c++ virtual function, the v-table is used to resolve to the function address. This is how the Dynamic binding happens during a virtual function call.

JSP Model

JSP Model 1 and Model 2 Architectures

The early JSP specifications presented two approaches for building web applications using JSP technology. These two approaches were described in the specification as JSP Model 1 and Model 2 architectures.

Although the terms are no longer used in the JSP specification, their usage throughout the web tier development community is still widely used and referenced.

The two JSP architectures differed in several key areas.

The major difference was how and by which component the processing of a request was handled. With the Model 1 architecture, the JSP page handles all of the processing of the request and is also responsible for displaying the output to the client.

This is better seen in Figure 1-1.

Figure 1-1. JSP Model 1 Architecture

Notice that in Figure 1-1 there is no servlet involved in the process, the client request is sent directly to a JSP page, which may communicate with JavaBeans or other services, but ultimately the JSP page selects the next page for the client.
The next view is either determined based on the JSP selected or parameters within the client’s request.

In direct comparison to the Model 1 approach, in the Model 2 architecture, the client request is first intercepted by a servlet, most often referred to as a Controller servlet.
The servlet handles the initial processing of the request and also determines which JSP page to display next.
This approach is illustrated in Figure 1-2.

Figure 1-2. JSP Model 2 Architecture

As you can see from Figure 1-2, in the Model 2 architecture, a client never sends a request directly to a JSP page. The controller servlet acts as sort of a traffic cop. This allows the servlet to perform front-end processing like authentication and authorization, centralized logging, and possibly helps with Internationalization.

Once processing of the request has finished, the servlet directs the request to the appropriate JSP page. How exactly the next page is determined can vary widely across different applications, for example, in simpler applications, the next JSP page to display may be hard coded in the servlet based on the request, parameters, and current application state. In other more sophisticated web applications, a workflow/rules engine may be used.

As you can see, the main difference between the two approaches is that the Model 2 architecture introduces a controller servlet that provides a single point of entry and also encourages more reuse and extensibility than Model 1. With the Model 2 architecture, there is also a clear separation of the business logic, presentation output, and request processing.

This separation is often referred to as a Model-View-Controller (MVC) pattern. While the Model 2 architecture might seem overly complicated, it can actually simplify an application greatly. Web applications built using the Model 2 approach are generally easier to maintain and can be more extensible than comparable applications built around the Model 1 architecture.

All of this doesn’t mean that applications built using the Model 1 approach are incorrectly designed. The Model 1 architecture might be the best decision for smaller applications that have simple page navigation, no need for centralized features, and are fairly static.

However, for larger enterprise-size web applications, it would be more advantageous to utilize the Model 2 approach.