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

 

where do the cookies get stored in the request object

 

Cookies are stored in the headers. In the response header it is stored at Set-Cookie and in the request object it is stored under Cookie header

Is the exception implicit object available in all the JSP pages?

 

No, it is avaliable only in the error pages. that is in the pages where this directive is present


<%@ page isErrorPage="true" import="java.io.*" %>

how do you navigate to error pages in JSP

 

In the page where exception might occur, add a page directive as below


<%@ page errorPage="ExceptionHandler.jsp" %>

 

Here ExceptionHandler.jsp is the actual error JSP to which exception implicit object is made available when exception occurs. Inside this page we need to add a page directive as shown below


<%@ page isErrorPage="true" import="java.io.*" %>

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.

Template Method Pattern

It defines steps of an algorithm and lets sub-classes decide which steps to override.

In core java, java.util.Comparable interface is based on this pattern. Here sorting algorithm is already defined in Arrays class and steps in sort algorithm (compareTo()) is left to the user defined class(Duck.java).

public class Duck implements Comparable {
        String name;
        int weight;
	public Duck(String name, int weight) {
		this.name = name;
		this.weight = weight;
	}
	public String toString() {
		return name + " weighs " + weight;
	}
	public int compareTo(Object object) {
		Duck otherDuck = (Duck)object;
		if (this.weight < otherDuck.weight) {
			return -1;
		} else if (this.weight == otherDuck.weight) {
			return 0;
		} else { // this.weight > otherDuck.weight
			return 1;
		}
	}
}

// client to sort instances of Duck class
public class DuckSortTestDrive {
	public static void main(String[] args) {
		Duck[] ducks = {        new Duck("Daffy", 8),
		new Duck("Dewey", 2),
		new Duck("Howard", 7),
		new Duck("Louie", 2),
		new Duck("Donald", 10),
		new Duck("Huey", 2)};

		System.out.println("Before sorting:");
		display(ducks);
		
		// sort
		Arrays.sort(ducks);
		
		System.out.println("\nAfter sorting:");
		display(ducks);
	}

	public static void display(Duck[] ducks) {
		for (int i = 0; i < ducks.length; i++) {
			System.out.println(ducks<em>);
		}
	}
}

Dependency Inversion Principle and Abstract factory Pattern

DI Principle says high level components/classes should not directly depend on low level components/classes instead both should depend on the abstraction.

direct dependency Object tree
FactoryWithDependencyInversion

Object tree through abstraction
TemplatePattern
From these figures the object tree has been reversed which is dictated by DI principle.

Guidelines that help us avoid violation of DI principle:

  • No variable should hold a reference to the concrete class
  • No class should derive from concrete class
  • No method should override an implemented method of any of its subclasses

Abstract factory patterns is an extension to the factory pattern which helps in creating families of related or dependent objects without specifying their concrete classes.

Classification of design patterns and KISS principle

Classification based on creation/structure/behavior.

Creational Patterns provide us a way to decouple the client from the objects that it needs to instantiate.

  • Singleton
  • Factory
  • Abstract factory
  • Prototype
  • Builder

Structural patterns help us to compose classes or objects into larger structures

  • Composite
  • Decorator
  • Facade
  • Proxy
  • Adapter
  • Bridge
  • Flyweight

Behavioral Patterns dictates how classes and objects interact with each other and distribute the responsibilities

  • Template Method
  • Strategy
  • Observer
  • Command
  • Iterator
  • Chain of responsibility
  • Visitor, Mediator and Interpretor
  • State

Secondary classification based on classes and objects.

Class patterns describe how relationships between classes is defined via inheritance and these relationships are established at compile time

  • Template Method
  • Factory Method
  • Adapter
  • Interpretor

Object patterns describe relationships between objects via composition and these relationships are created at runtime which is more dynamic and flexible

  • Singleton
  • Abstract Factory
  • Composite
  • Decorator
  • Command
  • Observer
  • Strategy
  • … all others go here

It doesnt matter how any patterns we know, always make sure to keep the code simple. KISS PRINCIPLE keep it simple stupid principle

Mawazo

Mostly technology with occasional sprinkling of other random thoughts

amintabar

Amir Amintabar's personal page

101 Books

Reading my way through Time Magazine's 100 Greatest Novels since 1923 (plus Ulysses)

Seek, Plunnge and more...

My words, my world...

ARRM Foundation

Do not wait for leaders; do it alone, person to person - Mother Teresa

Executive Management

An unexamined life is not worth living – Socrates

javaproffesionals

A topnotch WordPress.com site

thehandwritinganalyst

Just another WordPress.com site

coding algorithms

"An approximate answer to the right problem is worth a good deal more than an exact answer to an approximate problem." -- John Tukey

%d bloggers like this: