Introduction to J2EE (2.x), its Architecture and Component Diagram

Java 2 Platform enterprise edition is an integrated set of individual APIs required for developing server side MULTI-TYRED, DISTRIBUTED, TRANSACTIONAL and SECURE applications.

J2EE Component Diagram

J2EE is released in 4 parts:
• J2EE Specification: which declares all the APIs included in the release
• J2EE Reference Implementation: Open source implementation for the APIs given under J2EE spec and is provided by SUN i.e, j2sdkee
This is given to prove that APIs given under the spec are properly implemented
To help 3rd party vendors (as a reference) to implement the spec
• J2EE Test Suit: It provides compatibility test suit which can be used to confirm the J2EE product.
• J2EE Blue Print: This includes some best practices of the J2EE APIs provided

J2EE Architecture

Components:
• Component Provider: It is responsible for implementing components i.e, responsible to implement core business logic. Here the provider is required to be strong in programming, component architectures, component life cycles and with good business domain knowledge. The outcome from this provider will be JAR files containing components
• Application Assembler: It will take the components developed by the component provider and assemble them into an application. Here he may be required to write some simple client components. It uses J2EE standards to integrate components like some parts of deployment descriptors and some configuration files.
• Container provider: is responsible to implement low level services which are required to run the component like security, transactions, life cycle management etc..
• Server provider: responsible to provide system level services. Server and container providers must be same
• Deployer: is responsible to take the application assembled by the assembler and configure it so that it can be placed on top of a server/container. He is required to write vendor specific deployment descriptors and configuration files.
• Administrators: is responsible to configure the resources required for the application in the server, like creating users, configuring connection pools, etc..

Inversion of Control and Dependency Injection

Inversion of control is too broad term for the frameworks to claim that they are based on IoC. It depends on what control of the application are you inverting? Especially with new set of containers or frameworks IoC is about how they lookup and inject a particular 3rd party provided plugins into the application. These container/framework providers ensure that the user follows some conventions that allows separate assembler module (from the container providers) to inject dependencies into their applications.
As a result we now see IoC as too generic name and we need some other specific name to name this and for this reason we came up with Dependency injection (DI).

Let us start with some basic example

    public Class StudentLister {
    private StudentFinder finder;

    public StudentLister() {
        finder = new ElectronicBranchStudents();
    }
}

Here the StudentLister class is dependent on the interface StudentFinder and its implementation. We’d prefer if the class is just dependent on the interface alone but not the implementation class. But how can me make StudentLister class aware of the the implementation details of finder interface. We describe this scenario as the PLUGIN.
The aim is that the StudentLister class should not be linked to the finder implementation class at compile time, so that the implementation class can be changed at any time later based on the requirement.
Expanding this problem to the real world scenario, there will be many services and components. In each case we abstract these components through interfaces and access via interfaces. But if we wanna deploy these components in different ways then we should have plugin mechanism in place.
This is the place where set of all new light weight containers came in by implementing IoC design pattern.

There are three different ways of injecting the dependencies:

• Constructor Injection
• Injection through Setter Methods
• Interface Injection

Setter Injection via Spring framework

public class StudentLister {
    private StudentFinder finder;
    ApplicationContext context = new FileSystemXmlApplicationContext("src\\applicationconfig.xml");

    public StudentLister() {
        //finder = new ElectronicsStudents();

        // Get the instance using spring framework
        finder = (ElectronicsStudents)context.getBean("students");
    }

    public static void main(String[] args) {
        new StudentLister();
    }
}

Here there is no compile time dependency on the finder interface implementation and hence can be plugged in into any implementation class at later point of time.

Here is the complete source code
https://github.com/ntallapa/ForumWorkspace/tree/master/Spring082201DI

Introduction to Hibernate, Its Architecture

Founder of the Hibernate Open Source Framework
Gavin King is the lead for Hibernate and Craig Russell & David Jordan, the lead authors for SUN-sponsored JDO effort. Due to some technical problems, it appears that the majority in JCP favours Hibernate. The syntax and the approach appear to be almost same with other vendors, but Hibernate syntax is easier to learn. It is interesting to note that Craig Russell works for SUN and Gavin King is now with JBoss. It shows that JCP is a democratic community and SUN is not dictating terms except to protect the language and its enterprise-level users.

Introduction to Hibernate
HIBERNATE is an ORM ( Object-Relational-Mapping) technology. It is an Open-Source and free technology , developed in SourceForge.net in JAVA. There have been a number of such ORM technologies,in recent past.. TopLink is one such tool , subsequently adopted by Oracle and so proprietary. Hibernate from SourceForge and OJB(Object-Relational-Bridge) from Apache are two well known ORM tools, open-source and free. JDO, also falls within the same category.
Advantages of Hibernate in general:
• Writing SQL queries in Java program can be avoided
• Iterating result set is abstracted
• Exception handling is already taken care of in hibernate API and if something programmatically goes wrong we(appn) are thrown with runtime errors
• Support for transactions
• Support for Caching (we can integrate any 2rd party provided caching mechanisms)
• Support for Connection Pooling
Hibernate3.x
Starting from version 3.x, Hibernate is implementing JPA specification. SUN has released this JPA spec under JSR-317. This spec standardizes the basic APIs and the metadata needed for any object/relational persistence mechanism. Any ORM which implements this spec is standardized and using it in our applications makes the application loosely coupled with any ORM vendor so that we can migrate from Hibernate to TopLink if required with minimal changes in the application (provided these two vendors are adhering to standards/spec covered under JPA2 spec released by SUN)

Architecture Diagram

The above diagram shows that Hibernate is using the database and configuration data to provide persistence services (and persistent objects) to the application.
Hibernate has in built support to perform all CRUD operations (Create, Read(select), Update, Delete) operations in ANSI SQL standard and hence it is database vendor independent.
Main components:
• Connection Management
Hibernate Connection management service provide efficient management of the database connections. Database connection is the most expensive part of interacting with the database as it requires a lot of resources of open and close the database connection.
• Transaction management:
Transaction management service provide the ability to the user to execute more than one database statements at a time.
• Object relational mapping:
Object relational mapping is technique of mapping the data representation from an object model to a relational data model. This part of the hibernate is used to select, insert, update and delete the records form the underlying table. When we pass an object to a Session.save() method, Hibernate reads the state of the variables of that object and executes the necessary query.

Hibernate is very good tool as far as object relational mapping is concern, but in terms of connection management and transaction management, it is lacking in performance and capabilities. So usually hibernate is being used with other connection management and transaction management tools.