Friday, May 27, 2011

J2EE Part 3 - J2EE Containers

While writing business logic in J2EE application many programmers faced many similar problems for which they had to re-implement the solutions. Enterprise JavaBeans(EJB) was intended to handle such common concerns.

The EJB container is a runtime environment that controls the enterprise beans and provides them with important system-level services. Since you don't have to develop these services yourself, you are free to concentrate on the business methods in the enterprise beans. 
The EJB container provides solutions for common concerns to the enterprise beans such as:
1. Transaction Management
2. Security
3. Remote Client Connectivity
4. Lifecycle Management
5. Database Connection
For each enterprise bean, the container is responsible for registering the object, providing a remote interface for the object, creating and destroying object instances, checking security for the object, managing the active state for the object, and coordinating distributed transactions. Optionally, the container can also manage all persistent data within the object. Therefore the programmer can focus on the main logic and leave all this work for the container.

J2EE Client contains application client container that manages execution of application client components. 
J2EE Server contains EJB containers and web containers. EJB containers manages execution of enterprise beans. Web containers manages the JSPs and servelet components.  

Enterprise beans are server components written in the Java programming language. Enterprise beans contain the business logic for your application.
Enterprise JavaBeans technology supports both transient and persistent objects. A transient object is called a session bean, and a persistent object is called an entity bean.

A session bean exists only for the duration of a single client/server session. A session bean performs operations such as accessing a database or performing calculations. Session beans can be transactional, but normally are not recoverable following a system crash. Session beans can be stateless, or they can maintain conversational state across methods and transactions. A session bean must manage its own persistent data.

An entity bean is an object representation of persistent data maintained in a permanent data store, such as a database. An entity object can manage its own persistence, or it can delegate its persistence to its container.

Purpose of sessions bean is to perform a task for a client and is not persistent. It may have one client only. Entity bean on the other hand represents business entity object in persistent storage. It can have multiple clients. 

Simple example showing both:

The customer, order and product require persistent storage and hence entity bean.

A good rule of thumb is that entity beans model business concept expresses as 'noun' since they model real world objects that are persistent. For the above example -> product, order and customer are entity beans. 

Session beans only manages the client processes and tasks. It manages activities like for the above example 'shopping activity'. It does not represent any persistent data in database. It is transient because it performs the set of activities it is supposed to and then it ends. It therefore models interactions.

Lets have a brief look at how to implement an enterprise bean:
1. you need to define two interfaces and two classes.
2. Remote Interface: defines business methods of the bean. It extends javax.ejb.EJBObject that in turn extends java.rmi.Remote.
3. Home Interface: defines bean's lifecycle methods. Therefore it includes methods for creating new beans, finding beans and removing them. It extends javax.ejb.EJBHome that in turn extends java.rmi.Remote.
4. Bean Class: actually implements bean's business methods. An entity bean must extend javax.ejb.EntityBean and a session bean must extend javax.ejb.SessionBean. Also both should extend javax.ejb.EnterpriseBean. NOTE -> This class does not implement either of the above interfaces but must have methods matching signatures of methods in Remote Interface and must implement some methods of Home Interface... We will see more on this later.
4. Primary Key: It is a simple class that provides a pointer into the database. It should implement Serializable. As we already know that only entity beans deals with persistent data, only entity beans will need primary key and session beans clearly doesn't.

You need to know two basic things before we proceed:
1. Client never interacts with Bean Class directly. It makes use of both the interfaces only to interact with stubs that are generated automatically.
2. A bean that needs services of another bean is a client to it if seen in a relative manner and therefore the above applies to it too.

Container is primarily responsible for creating 'instances' of beans and making sure they are stored properly by the server. There are many containers provided by different vendors in market providing different tools and therefore must be selected accordingly... At least one tool will deal with mapping of beans with database. Some tools will generate a code that will implement the interfaces to create bean and store it in database. This is why the Bean Class need not implement them :) 

So why did they make container... Why not just make the server do the container's work for the beans. One of the reasons is that a third party can provide containers and it can plugged into any server. The vendors can decide whether to make server or container and focus on it. One disadvantage of this container-server interface could     
be performance. Advantage follows the rule -> Higher the abstraction, greater the flexibility. Disadvantage is due to the rule -> Tighter the integration, better the performance. In the case of container-server interface the integration is not tight and hence low performance but the abstraction is at a higher level and hence the flexibility.

The responsibilities of server and container is dependent on the vendors. Many different types are available based on this and we should make a choice depending on our need.

Anyways we will talk more on EJB container only. I know we did a lot for the day... So details covered in next post and for now you can go for your coffee break :)

Coffee Break
Enterprise Beans are business object components.
Two types of beans - Session and Entity beans.
Session beans is transient.
Entity beans is persistent.
Beans contained in container.
Container handles common concerns of the app.
EJB container used for J2EE app. 
Container also manages object's database optionally
Container therefore relieves the programmer of common tasks and he can focus on business logic implementation only.
Enterprise Bean implemented by two classes and two interfaces.
Client has no direct interaction with beans.
A bean needing service from another bean acts like a client to it.
Remote Interface defines methods for the bean's business logic.
Home Interface defines methods for the bean's lifecycle.
Bean Class implements state and behaviour of beans.
Primary Key provides pointer into the database.

Wednesday, May 18, 2011

J2EE Part 2

Although a J2EE application can consist of the three or four tiers, J2EE multitiered applications are generally considered to be three-tiered applications because they are distributed over three different locations: client machines, the J2EE server machine, and the database.


The above shows multi-tiered applications.

J2EE CLIENTS: can be web client or application client. Web clients consists of dynamic web pages generated by web components running in web-tier and web browser that renders the dynamic pages received from server in presentable format. Applet is a small client application that executes in JVM installed in web browser. Web clients are also called as 'thin clients' as they do not do heavy weight operations such as database queries or implementation of complex business logic. Another type of client is application client. Application client makes use of typical swing or Abstract Window Toolkit(AWT) APIs to provide a rich user interface.
The difference between standalone client and J2EE client is that J2EE client can connect to J2EE services.

Now we know that the client communicates to the business tier(meaning business layer on another computing system... therefore 'tier') either directly or through the presentation tier(meaning presentation layer on another computing system... through JSPs and servelets).

Web Component: They can be servelets or JSPs. Servelets are java classes having embedded html pages for dynamically processing requests and constructing responses. JSPs on the other hand are html pages having embedded java code.
Business Component: It contains the business logic or the implementation part... implementation of all the business rules.
JavaBeans Component: They can be on client side for managing data flow between applet or any other client to the components on J2EE server or it can be on J2EE server side for managing data flow between J2EE server components and database.

EIS Tier: It includes Enterprise Resource Planning(ERP) and handles information systems. It manages all the database connectivity stuff.

Finally we get:

Coffee Break
Noramlly J2EE used is 3 tiered architecture.
The tiers are J2EE client, J2EE server and database server.
Client tier can be web client or application client.
JavaBeans components are NOT considered as J2EE components by specification.
J2EE server consists of web tier and business tier. 
Database server consists of EIS tier.