CODEWITHSUNDEEP
javaservletsnetbeansejb-3.0
Murphy316
Murphy316

Reputation: 766

About Enterprise Java Session Beans

Being completely new to Enterprise Java development and after reading the following tutorial.I managed to develop my first session bean. After reading a little about session beans I do have some questions about it (session bean) and I hope the experts out here could help me out.

Normally in a servlet scenario without using EJB we would do something like the following to accomplish a certain task

 StudentList stud = businesslayer.businessMethod_GetStudentsFromDb();

Now the businesslayer would call the service layer which would get the details from the DB and return it.

Now my questions are as follows:

1-If I were to implement this mechanism using say a stateless EJB will I have to copy the domain package which contains the domain object StudentList to the "-ejb" folder of my enterprise project (I am using netbeans).Similarly will I have to copy other Business methods from the source folder of my "-war" folder to the ejb folder just so that the stateless bean in the "-ejb" folder can use those methods. Cant classes inside the "-ejb" folder use classes insider the source folder of the "-war" folder.

2-This is the question so far i could not understand. What advantage would i get if i used EJBs instead of my current mechanism ?

Upvotes: 2

Views: 178

Answers (1)

Arjan Tijms
Arjan Tijms

Reputation: 38163

1

If you're building a single application, there's nothing you need to copy. If you want to have a very strict separation between business code and web/view code you can create an ear, with an ejb module and a web module. All classes in the web module can access all classes in ejb module, but the reverse is not true. This effectively imposes a layering in your application.

But you don't have to go for this separation. You can also just put your EJB beans in a single war together with your Servlets and what have you. There's no restriction on where you put your beans. It can be in a separate package, or in the same package as your Servlets.

You might wanna look at this example I made: http://arjan-tijms.omnifaces.org/2011/08/minimal-3-tier-java-ee-app-without-any.html. There, BusinessBean is an EJB that resides in the same (default) package as the JSF backing bean in a single war.

In the single war setup, everything can access everything. Do note that even in this situation you probably would like to keep your business code "clean" and keep things like HttpRequest and such out of it.

2

EJB beans, especially EJB light, provide exactly those things that most every web application needs: transactions, pooling, thread-safeness, security and injection. You'll get the most out of EJB beans when combined with JPA. The advantage is that your code will be much less verbose and at the same time shielded from race conditions and inconsistencies that you'll run into when using plain JDBC.

E.g.

@Stateless 
public class CustomerService { 

  @PersistenceContext 
  private EntityManager entityManager; 

  public void addCustomer(Customer customer) { 
    entityManager.persist(customer); 
  } 
}

Without EJB you'll need a bunch of try/finally blocks which open and close the connection, start and commit the transaction etc. And without JPA you'll have a large block of tedious code that inserts individual fields of the Customer entity shown in the example into a prepared statement.

If you (later) have services that call one or more other services and either everything needs to be saved to the DB or nothing (as opposed to something undefined in between), then this is quite a challenge to accomplish in plain JDBC. You'll have to pass open connections around and need special variants of each service method that opens/closes connections and starts/commits transactions in addition to methods that can be used in an intermediate phase. Before long, this will become highly complex and a big ball of mud.

With EJB, every method in an EJB bean that you call from within an other EJB bean automatically joins the ongoing transaction or starts its own if no transaction is in progress. This alone massively simplifies many common business tasks carried out by typical web applications.

Don't let anyone tell you that only "enterprise applications" need transactions, and web applications don't need this. This is simply not true. A transaction is a very basic thing when doing DB operations, at the same level of basic requirements as primary keys or foreign keys are. When performing business logic for say an order (in a webshop), you definitely don't want your inventory being decremented, but no actual order being send, or an order being send but no money subtracted from your customer's account, etc etc. The simplest of business logic often involves writing to at least two tables, and every time that happens you'd better be using transactions.

Do make sure you're using EJB 3 though. Stay far away from everything that has to do with EJB 2. Don't even touch things like home interfaces or Entity Beans, which have been deprecated for some 6 years now. (don't confuse EJB Entity Beans with JPA Entities though, despite the unfortunate name similarity these are completely different. JPA Entities are very sane and useful)

Upvotes: 4

Related Questions