Enterprise Java Beans

The Observer Pattern has been one of the most widely used design pattern in Software Development. If not most, many use the pattern for their development to call different independent modules to do processes after the initial action from another module. Certain scenarios like, a display table was updated after an insert call, a window resize after a clicked of a button.

JEE6 introduced a more easy way of using the observer pattern.

Assuming that you have a ManagedBean, with a register transaction method.

Observe this:

Event<?> will be the one responsible for storing entity or object to be observed.

A fire method is called passing the entity. (memberEventSrc.fire(newMember));

Once the fire event method is called, it will search for all ManagedBean observing this entity.

Observer this:

@Observe annotation is used for the final Member class in the method, this is our flag for the method call

This is located on the ManagedBean – We need a POJO that is class loaded for this process.

The MessageProducerList class is also a ManagedBean that is called after a transaction is made. The fire event from the MemberRegistration ManagedBean will call the method (on the screenshot) to load all the members. These list of members is then loaded to the JSF Page.

“How can an EJB client invoke the methods of multiple session or entity beans within one transaction, without the need to block and wait for responses from each bean?”

Asynchronous Behavior – From a J2EE Development standpoint, it is a behavior of a business use case logic can be executed separately from the client itself, e.i without requiring to wait for the execution to be complete. With design consideration of this behavior, we can allow clients to still interact with the user interface with the maximum response times. This is because they don’t need to sit and wait while the use case the initiated finishes. This approach allows a large system to scale, because use cases can be queued and operated on in a batch, transparent to the user, who instantly moves on to the next part of a UI. Portions of the system that actually execute the use cases can also be scaled up and go through system upgrades if backlogs of queued use cases begin to develop, all without changing the quality or availability of service for the clients.

For EJB: We can use message-driven beans to create a fault-tolerant, asynchronous façade. Clients should have access to message-driven beans only, not to entity beans.

Instant response time/asynchronous communication. When a client sends a JMS message, it is free to continue processing without waiting for the server to complete the use case and respond. A lengthy, complex use case can thus be initiated while control flow instantly returns to the user.

Eliminates single points of failure. Using messaging will ensure that your application continues functioning even if the EJB server or some other subsystem it relies upon is down. For example, if the database is down, the MDB’s transaction will not complete, and the reserve seatmessage will remain on the queue and be retried later. If the EJB container is down, the message will again be stored. Such fail-over capabilities would not be possible if we used a synchronous model. Of course if your JMS server is not clustered and it goes down, this still represents a single point of failure, but at least the number of potential show stoppers is reduced.

Disadvantage of the Message Façade pattern includes:

Message-driven beans have weakly-typed input parameters. The role of a message-driven bean is to consume JMS messages, all of which appear identical at compile time. This is in contrast to session/entity beans, which leverage Java’s built-in strong typing of the methods and parameters of the remote and local interfaces to catch common errors at compile time. Extra care must be taken by the developer to load a JMS message with the appropriate contents required by its destined MDB. One solution to this problem is to encapsulate all the data from the JMS message into a custom data transfer object, and serialize this object into the JMS Message.

Message-driven beans do not have any return values. Since MDB invocations are asynchronous, Message Façade cannot be used for use cases that require a return value after execution. Using Message Façade is thus superficially similar to using Session Façade, in which all session bean methods simply return void. However, it is possible to get a response from a message-driven bean back to the message creator by using JMS as the transport mechanism, please refer to the book Mastering Enterprise Java Beans, Second Edition for a discussion of this mechanism.

Message-driven beans do not propagate exceptions back to clients. Unlike session/entity beans, message-driven beans cannot throw application exceptions or RemoteException from any of their methods. MDBs must therefore handle all the exceptions presented in some application-specific format (that is, emailing the user if something went wrong, logging errors to an admin log, and so on).

Developers can create EJB / JPA Business components and expose it through Data Controls.

Data Controls are created to expose functionalities to Oracle ADF.

Once Data Controls are created, this can be used to create ADF based form components like Manager Forms and Graphs

Review: The tutorial is more of a declarative way of developing ADF applications. It first creates a Database Connection, then create an EJB Diagram to create Session Beans and JPA Entities. This beans will be the back bone (model) of our application for database transactions. Next, create Data Controls to expose EJBs for Oracle ADF. Then after exposing these, we can now use the ADF framework to create pages and combine very useful ADF components (accordion, data grids, graphs etc.)

This tutorial really showcased the power of Oracle ADF + the use of JDeveloper. Its completely a new way of developing Java EE applications. JDeveloper brings another level of development scheme as showed on the tutorial, its a very flexible IDE that support both declarative and narrative development method. The addition of full support on Oracle ADF sums up the whole package as it allows developers to drag and drop exposed ADF data controls and create components for it (graphs, forms, etc.).

I find EJB/JPA Development in Oracle JDeveloper too good to be true! 🙂 Seriously. I tried developing a new Java EE Application using JDeveloper:

The wizard created 2 components in the project. A ViewController package and a Model Package.

ViewController Package – Is where all JSF/JSP and Servlets go, basically the view and controller sources. Model – Business Components such as EJBs and JPA entities are placed in this package.

Lets try creating an end to end Person Registration! 🙂

1st Step: Design the Model.

Go to New > Offline Database

Start by creating a dummy database – developers can create an offline database (oracle database emulator) that will run with your application.

Then lets create a table on that offline database we just created.

Click on OK. After creating the table, new database components will be created on the project setup.

What we did with the first step is just to create a database and a table to store our Person Registration.

2nd Step: Create Model Diagram (EJB/JPA Diagram) and Components

After creating the database and table, we now need to create the components that will interact with the database from our application.

Create EJB/JPA Diagram: Developers usually skip the part of creating a diagram first – I would say that this process is one of the most under-rated process for any developer regardless of the platform (I sometimes wonder how one can develop without even doing some drawing to visualize the flow of their application logic).

After hitting “OK”, a blank diagramming canvass will be displayed. Note: This canvass I believe is one of the most powerful feature of Oracle JDeveloper! – Keep reading.

Next, drag the PERSON table on the canvass. This will create a new Entity Bean (JPA entity bean), create a new Persistence unit and a persistence XML for its definition.

Note: I move the generated entity class to a new package (this is one of the features I actually don’t like about all this automation stuff).

Create a simple Stateless Session Bean. Drag a new Session Bean from the EJB Component Palette on the right side to the canvass.

This will open up a wizard to create the new Session Bean.

Methods will be automatically generated. These generated methods will perform basic querying, insertion, delete and update.

Put the Session Bean on the beans package.

Remote and Local Interface (Both interface will be placed on the beansiface package).

Session Beans are now created. 🙂

We just created our Model Layer. We can now use the Session Beans to do Database Transaction from our Controller.

3rd Step: Develop the Page and ManagedBean

Open the faces-config.xml – We will create 2 JSP that will handle user input and a success page.

After creating creating the Page Flow, we now create the actual page. Right click on the diagram page component to create page.

Pages can be created from a template or a blank page. I will discuss Page template development in another post. 🙂

Create a ManagedBean – this is the controller class where in we put form fields and actual call to the business logic. From the faces-config.xml, right click on the canvas to create the managedbean. This will create a new ManageBean entry on the xml file.

After the ManagedBean is created, put the fields First Name and Last Name (Generate or create Accessors) in it. Put also the logic to insert the new Person data.

Create a Registration Form. Open the registerperson page to create the form and map the fields to its corresponding ManagedBean mapping.

Success Page:

4th Step: Test the Person Registration

Right Click on the Register Person Page.

Test the Person Registration:

As I’m trying this stuff, it took me a while to get a hang of getting my source running. The first thing I did was not to rely on automation scripts to really experience how to assemble each piece of components together. Yet as I go along some roadblocks and issues, I would really say that if I’ll be using this IDE for J2EE Development, I would rather build it using the automation tools available.

The Diagram tool is amazing, drag and drop your components and your off and running.

Offline database is cool. You don’t have to mind how much memory would it consume your terminal just to try a EJB/JPA, you can just use the offline database (which is basically just a file) and your good to go.

JSF Flow Diagram is great. I’ve use the faces-config diagram and its like mapping the flow of your pages. All drag and drop components are available, page and beans generate are also available.

One thing I didn’t like at all is the package management, it seems that if you have a convention of creating sub-packages, you’ll likely to be irritated by that fact that it can’t create sub-package for itself. You’ll have to create one sub-package after the other.

Overall, I’m impress how Oracle manage to put a lot of automation in the IDE. The Diagramming canvass is perfect for modelling (EJB and JPA generated), the offline database is too good to be true for development trials and the JSF Diagram canvass from faces-config and bean generators really did put the ease on developing view components.

Session Facade – The most commonly used of all EJB Design Pattern. This Design Pattern is almost mandatory for all EJB Application.

This approach is somehow the most generic form of design consideration, its basically putting another layer of service abstraction on the model side that will handle client request. The abstracted layer is formed to support the application’s use case scenario. How about an example of a bank withdraw and transfer use case:

The user tries to withdraw money from Account 1 and Transfer money to Account 2.

Sequence Diagram without Session Facade on the Model Layer:

This seem to be a fine process right? We’re actually calling the model from the controller.

Well, MVC really is a good thing to consider, the overall picture suggest that we are actually seperating each layers concern – view for the presentation, controller for the servlets, model for database transactions.

Yet that’s just 50% of the actual architecture problem we solved. How about considering: Network overhead? poor concurrency? tight coupling? reusability? maintainbility? development practice? How will these problems affect the users transaction?

Network Overhead problem: We are actually calling each functionality from the model one at a time on the servlet level (client side), we are passing data through the network each time a person logs in with a valid credentials). You called more than 1 functionality over the network for a use case, now what if I have 5000 users simultaneously logs in?

Poor Concurrency Problem: What if one of the processes / transactions from the servlet broke down? What if the network was out right in the middle of the process?

Tight coupling Problem: The servlet is actually calling the bean, what if there are changes to the bean in the future? We might need to change client as well if these happens right? – and that’s not good.

Reusability Problem: What if a future functionality needs the user validation process? How do we re-use the existing functionality?

Maintainability Problem: Since we put all our model calls on the servlet, we need to implement a transaction API on it (commit and rollback process). Would it be much more easier if we implement a new layer for this so that we can tweak them without affecting business cases on the client side?

Development Practice Problem: Sure we did put the model calls on the servlet, yet the actual business logic is still in the controller, thus development roles (jsp/servlet and ejb developers) separation will not be as easy as it could be.

MVC alone will just give you the overall separation for each layers, yet that only solves coupling between layers (and possibly not so losely). We still need to improve our architectural structure to solve recurring problems (above) on Enterprise Application Development.

Session Facade solves these problems by creating a new layer of abstraction in-between the Controller and Model, to wrap business cases and hide actual implementation calls. This process will clearly separate our client from the model.

Sequence Diagram with BankTeller SessionBean (Facade).

Obviously, Enterprise Software applications has different business process and rules to support. Using Session Facade approach, developers can wrap functionalities from use cases and create Session Beans to support each (Maybe, investment fund or loan services?).

Alright, so what did putting another layer yield’s to our application development? Obviously:

Lower Network Overhead: Since we are now just throwing one request for multiple process, we actually minimized the network overhead.

Concurrency: Since we are calling the bean only once, concurrency issues will be minimized. Transactions will now be placed on an independent layer thus can be more controlled and contained.

Low Coupling: We have separated the client from the model by putting another layer in between. this gives flexbility to the application when a large functionality will be implemented.

Re-usability: Since we wrap a certain process in a Session Facade, we can re-use that facade for future functionalities.

Maintainability: Separation brings maintainability across layers, its far more easier to maintain a layered application since developers can clearly see the overall picture.

The Session Facade is a mandatory design pattern in EJB development. Its the most basic form of enterprise software development pattern that will clearly solve many recurring issues. The separation obviously is the key to its long standing approach and the concept of “one request for multiple process” clearly helps Networking Overhead issues.