Hadoop Overview

June 1, 2014
Hadoop-Overview

Hadoop Overview

Advertisements

Good REST Article

February 18, 2012

Hello,

Wanted to share a very nice article written by Martin Fowler about REST webservices. Easier to understand for the people like me who keeps using the webservices the traditional way as RPC.

I am hoping for the new development at least, I get a chance to try these principles.

Here is the article.

Bye,

Amit


iBatis or Hibernate ?

December 16, 2011

Hello,
I have been thinking to write this one since long. It almost now took 10 months to write the new blog entry.
In this one I will be talking about the iBatis and Hibernate. I purposely did not mention comparison as I myself do not think they are comparable to each other. Both of them have a different purpose and different applications in designing the solutions for Data access. While taking interviews I often come across candidates mentioning iBatis as a competitor of Hibernate. This exactly is the reason I felt I should share my views around the same.

iBatis is a very good and handy SQLMapper tool. I had experienced it’s usefulness while consuming the iBatis framework to build the solution that involved invoking Oracle Stored Procedures that returns REFERENCE cursors back. You simply configure the returned resultset to the Java objects and you are done. You get to work with the Java Objects in your application without bothering to write the usual and monotonous traversing logic and initializing the Java objects on your own. But this is where some colleagues starts thinking it as an ORM(Object Relational Mapping) tool. This is not the fact. iBatis  helps you map Java objects to the Parameters being passed to Stored PRocedure/Function/SQL without worrying about JDBC.

ORM has a altogether different domain to address. To understand this we have to first understand the challenges involved in mapping Object model to Relational model. This is usually called as Object Relational Impedance. We will see few of them hereafter.
First and foremost thing is Object Inheritance available in Object model which is not in Relational model. Hibernate as such addresses this by implementing Table per Class, Table per subclass and Table per Class hierarchy. We cannot go into more details of these and already a lot of information is available around this. The crux is when persisting/retrieving the Object hierarchy to/from database, either a discriminator column or table joins are implemented based on the strategy selection.
Another important feature that ORM tool provides is persisting the Object Graph when parent is being persisted. These are some of the things which are not addressed by iBatis. Well, you can do this with iBatis provided you write your own code for this. ORM tools also has a feature that helps identifying the dirty instance and persist it to the database once it is associated to Persistence context. Apart from this ORM has lot of other features which can be checked here.

In essence when we want to build a solution that involves just retrieving data from database and present it to the user, iBatis is simpler and effective solution. Whereas when one has the liberty to derive Relational model from the Object model and heavily retrieve/persist Object Graphs, Hibernate is appropriate solution. Using hibernate only for Data retrieval makes your solution over-engineered.

Hope this helps someone trying to compare iBatis and Hibernate.


n+1 rather 1+n

January 1, 2011

Hello,
I have been thinking to post this for quite some time. This one is about the famous “n+1” behavior/problem with the ORM tools. Initially when I had learnt about this one it took me a while to digest. I felt “1+n” is more easier to understand than “n+1” and it would be so for Beginner audience. That’s the reason behind this post.

In ORM world you often mark the relationships as “lazy” so that they are lazily loaded. First we will see what this means,

Consider the classic one-to-many Department(One) and Employee(Many) relationship.

From Department’s perspective this one is represented as the Collection of Employee objects within a Department as shown below.


/**
 * The Employee Entity.
 * Only OneToMany Bidirectional association is shown in the code.
 */
@Entity
public class Employee {
    @ManyToOne
private Department dept;
}

/**
 * Department Entity.
 */
@Entity
public class Department {
    @OneToMany(mappedBy="dept")
private Collection employees;
}

When we mark this relationship as lazy and query for the Departments, ORM shall fetch the Department objects satisfying the criteria. Due to the “lazy” attribute ORM will not initialize the Collection of Employees until they are requested.

For e.g Consider the following data set –

When we query the database to get all the departments, ORM will initialize the Department objects except the Employee Collection. This corresponds to 1 query namely

SELECT * FROM DEPARTMENT

Later whenever we access the Employee Collection contained within the Department object,ORM will again have to go the Database and fetch the employees for that department.

The query will be something like

SELECT * FROM EMPLOYEE WHERE DEPTID=?

This means for whatever the number of departments(Let’s say “n” department records),the ORM will need to fire above query those many times. i.e. n times. So to iterate all the Departments along with their Employees ORM will fire “1+n” database queries in total.

This can be overcome by using eager fetching which will result in only one JOIN query that would collectively fetch Departments along with their Employees.

Hope this helps someone confused about 1+n problem.

Cheers,
Amit


Polymorphism without Inheritance

October 6, 2010

Can Polymorphism exist without Inheritance?

Abstraction“, “Encapsulation“, “Inheritance” and “Polymorphism” forms the basic building blocks of OOA&D.
We are so much overwhelmed by these facts that an immediate answer is “No“.

In Java there are two types of Polymorphism. One is Runtime(Dynamic) and other is compile time(Static).
In Runtime polymorphism the actual method to be invoked is decided based upon the actual object that the reference type refers at Runtime. This is achieved by OVERRIDING the method in sub classes. Of course this is where “Inheritance” is the KEY which is used to implement “Polymorphism”.

In Compile time or Static polymorphism, the method to be invoked is decided at compile time by diagnosing parameters of the method. This is implemented using Method OVERLOADING. Now this one does not depend on the Inheritance hierarchy because a method can be overloaded in different ways in the same class.

What does this mean?
Even without the Inheritance hierarchy we can have Polymorphism though of a Static kind.

Cheers,

Amit


Single SignOn and HTTP Cookies

September 1, 2010

Hello,
In this article we will see how the Single Sign On implementations use the HTTP Cookies.
Recently we integrated one of our intranet portals in a company-wide SSO. I wanted to test some functionality in the portal locally before releasing it to the Integration environment but was not able to login to the portal
because the codebase was dependent on the SSO solution.

To address this one of my colleague suggested to hit Integration environment and login there. After this in the same browser window type the URL of the locally deployed application.
Of course this is not going to work. Even if the local application has the similar URI, the browser shall not transmit cookie belonging to other domains to locally deployed application or for that matter applications in different domains.

To understand this we need to see how cookies are used in SSO applications.

Let’s say we own on a portal “foo.com” that is SSO enabled. In a Siteminder enabled SSO solution the cookie named “SMSESSION” is used to store the client identity. Consider that I am developing a webapp that will be part of foo.com named “myapp”. Now when we want to integrate this “myapp” as part of the SSO solution we use a sub-domain say “myapp.foo.com”. Of course we need to write some code that would read this SMSESSION and do the thing that would login the respective user in your application.(in this case “myapp”).
Now why we need the sub-domain in this case.

Domains share their cookie information with their sub-domains.

Hence when the Siteminder solution sets the cookie for “foo.com” and when we navigate to “myapp.foo.com”, the server side code serving “myapp” would get SMSESSION cookie that is set at the domain level. Reading and using SMSESSION, “myapp” can login the user in “myapp” and proceed.

In the figure below I am trying to explain this graphically.

Single SignOn and HTTP Cookies

Single SignOn and HTTP Cookies

Hence if you try a workaround as mentioned above it is not going to work.
In case of tomcat my URL will be http://localhost:8080/myapp” which is not part of the main domain “foo.com”. Due to this cookie information will never be shared with “myapp” deployed locally.

Hope this helps someone looking for information on this topic.
Your comments/suggestions/corrections are always welcome.

Cheers !!
Amit


Multithreading and Locking Strategies

July 30, 2010

Hello,
Concurrency in Java 5 has introduced new ways of developing multi-threaded applications.

The basic difference in these two APIs is Locking Strategy that is implemented for achieving the concurrency.

Java 5 concurrency API use Compare And Swap(CAS) mechanism. In CAS the original value is compared with the value that was read last time, if it matches then the thread modifies the shared variable with new value. The thread in this case is optimistic hoping that no other thread has modified the original value. This is the Optimistic locking strategy.

In Java 4, we use the synchronized keyword for locking the resource. This way we use the Pessimistic locking strategy. Because we lock the shared resource exclusively for the current thread. No other thread can access and modify the variable.

Both approaches have their own advantages and shortcomings. In this entry I just wanted to highlight the implementation difference that appealed me while reading the article.

Cheers !!
Amit