Acknowledgement modes in Java Message Server (JMS)

There are two types – auto-acknowledge – dups-ok-acknowledge

auto-acknowledge: the acknowledge message from MDB to the JMS is sent as soon as the message is received

dups-ok-acknowledge: the acknowledge message from MDB to the JMS can be sent any time later and hence there is chance of JMS sending the message again and MDB should be able to handle the duplicate messages

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.

Java Security Model and its anatomy

Java Sandbox Model
Java has circumvented the virus or Trojan horse problems that plagued other models of software distributions. Java sandbox model is responsible for protecting a number of resources and it does it at number of levels.
Java programs are considered safe because they cannot run, install or propagate viruses and program itself cannot perform any action that is harmful to the user’s computing environment.

Anatomy of java application in SECURITY

Java Sandbox Model

The components drawn in the above figure play important role in java security model.

Byte Code verifier:
It ensures that all java class files that are loaded into JVM follow the rules of the Java language. In terms of resources, it helps enforce memory protections for all java programs. As the figure implies not all the class files are subjected to byte code verification.

Class Loader
One or more class loaders load all the java classes. Programmatically, the class loader can set permissions for each class it loads.

Access Controller
It allows OR prevents access from the core API to the operating system, based upon the policies set by the end user or administrator.

Security Manager
This is the primary interface between Core API and Operating System, however it exists for historic reasons

Security Package
It allows you to add security features to your applications as well as providing the basis by which java classes may be signed. This is a complex API and is further broken into following

• Security Provider Interface– the means by which different security implementations can be plugged into security package.
• Message Digests
• Keys and certificates
• Digital Signatures
• Encryption (JCE & JSSE)
• Authentication (through JAAS)

Key database
Key database is a set of keys used by the security infrastructure to create or verify digital signatures.
With respect to the sandbox, digital signatures play an important role because they provide authentication of who actually provided java class

Java Naming and Directory Interface (JNDI), JNDI Architecture

Naming Service? Is a service which allows us to store and retrieve simple objects with a unique name. It is just like one of the storage unit.

Directory Service? Is an added service on top of naming service which allows us to store and retrieve objects with some directory names (i.e, maintained into groups)

These services are implemented by different vendors where each vendor provides their own APIs and protocols to interact with theirs naming and directory services.
If any java application wants to use these services, it has to plugin to any of the vendor provided implementation, then

• Application becomes vendor specific
• While deploying we need to know about the vendor and its service API
• While migrating the application from one vendor to another we need to change the code base of the application

To avoid these problems we want a standard abstraction through which a java application can interact with any vendor implemented Naming and Directory Service. To meet the above requirement SUN has released standard API providing solution to the above mentioned problems. These standards have been released under JNDI (Java Naming and Directory Service)

JNDI is an standard abstraction which allows any java application to interact with any vendor implemented naming and Directory Service.

In this case if java application wants to interact with any naming registry it just requires to prepare a request in JNDI format using JNDI API i.e, request is explained and submitted to JNDI API classes where JNDI API uses the information given by the java application and locates the SPI implementation and initializes it.
JNDI API dispatches the request to the SPI implementation through JNDI SPI.

SPI implementation converts the request and interact with the respective registry to process the request, collects the response convert it into the JNDI format and return it.
JNDI API returns response to the java application.

JNDI API
javax.naming.Context
Is an interface given under JNDI specification. Declared with methods required to read, insert, update and remove the objects like lookup, bind, rebind, unbind, list

This interface should be implemented by the vendors as part of SPI implementation.

javax.naming.InitialContext
Is a non-abstract class implementing Context interface given under JNDI specification. It implements wrapper pattern, it wraps one context implementation instance (i.e, instance of context interface implementation class given by third party vendor)
This is given to simplify the process of locating and initializing SPI implementation objects. i.e, it separates logic required to locate and initiaze SPI implementation objects from java objects.

Using JNDI API to connect to the naming registry

• Set the required properties like
  a. Name: Context.INITIAL_CONTEXT_FACTORY
  Value: should be the qualified class name of the implementation class of javax.naming.spi.InitialContextFactory interface
  Example: weblogic.jndi.WLInitialContextFactory is the implementation class name of javax.naming.spi.InitialContextFactory. This allows us to interact with weblogic naming registry
  b. Name: Context.PROVIDER_URL
  Value: should be the url pointing to the naming registry
  Example: t3:\\localhost:7001 : points to weblogic naming registry running on the local machine on 7001 port.
  These properties can be set into the system properties into hashtable
• Create an instance of InitialContext (IC) where it has following constructors
  a. IC as no arguments: In this case it gets the properties from the system props object
  b. IC(Hashtable ht): It gets the properties from hashtable
  Note: The first property given under the step1 is mandatory and if it is not found, IC object will not be created and it throws NamingException describing NoInitialContextFoundException

Step 1:

Hastable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,  “weblogic.jndi.WLInitialContextFactory”);
ht.put(Context.PROVIDER_URL, “t3:\\localhost:7001”);

//Here t3 is weblogic specific protocol
InitialContext ic = new InitialContext(ht);

Step 2:

System.setProperty(Context. INITIAL_CONTEXT_FACTORY,  “weblogic.jndi.WLInitialContextFactory”);
System.setProperty(Context.PROVIDER_URL, “t3:\\localhost:7001”);
InitialContext ic = new InitialContext(ht);

The above steps connects to the naming registry, now we can use IC object reference and interact with the naming registry to get the object and store the object.