Linkedin - 99% Java Inside

For about 7 years that I have done active coding, it has been mostly using Java, a language I fell in love with when I wrote my first hello world program in it, way back in 1997. I liked the fact that it was natural for me to think, design and code in a language which was so close to OOP concepts. Everybody during that time in Bangalore seemed to be learning Java and java courses were selling like hot potatoes throughout ever mushrooming computer learning centers. Java was the language in demand and a passport to get a quick programming job. Some time later I came to know about EJBs and J2EE which were projected as some sort of Holy Grail of distributed systems. Everybody wanted to work on EJB projects. JSP/servlets were for lesser mortals. When I read EJB specification and J2EE book (I think it was wrox series) for first time, I felt like a student reading a high philosophy from the Zen Masters. It was beautiful. EJBs were the black art. Then sometime later came J2EE design patterns, pet shop and blueprints. You couldn’t; get through an interview if you didn’t know about Blueprints or if you didn’t know about session facade and value objects.

Well, those good old days…. lots of things happened after that within industry and with java language. I personally, have worked a bit with other languages like PHP which I got to learn because it seemed to be the lingua franca of internet. For me coding in PHP was difficult initially as I hated those nested arrays without which you couldn't do a lot in PHP and I missed beauty of strict typing of java. Exposure to internet made me realize that most large, high volume systems are written not in Java but in scripting languages. Possibly because such systems are easy to host and possibly because dynamic languages are natural fit for volatile business of internet. Whatever the reason, java has clearly lagged behind on web. Its focus has been behind firewall, within enterprise, backend processing. So for old time sake and love of a language, it is good to know when you come across a high volume internet site written entirely in java. Below is a presentation which explains how Linkedin runs on 99% java. Just to get an idea of scale, here are some numbers:

• 22 million members
• 4+ million unique visitors/month
• 40 million page views/day
• 2 million searches/day

Take a loot at architecture and how it has evolved. It is all about partitoning the data I guess and 1% is taken by C++ implmentation of custom JVM heap!!. Also read this post here.

View Upload your own

If embedded slide doesn't show up , use link to slideshare

Lightweight containers (Spring)

A container like Spring container is analogous to EJB container in sense that container can manage objects and also provides infrastructural aspects like transactions transparently to these managed objects. These containers are not conceptually different from EJB containers as they also provide a managed environment for a piece of code to run, but, they are lightweight as they are non invasive and can manage almost any java object. For example, Spring can manage any java object written to simple java bean specifications unlike EJB Container which can only manage components adhering to EJB specifications.

Container frameworks are designed to serve following objectives:

1. To enable a business object or component declare its dependencies (Configuration)
2. To resolve these dependencies (Dependency management)
3. To provide object lifecycle services (Lifecycle management, pooling etc).
4. Provide Low level Services (like Transaction, security)

In terms of dependencies, a business object might have two types of dependencies:

1. Low level service dependency (like transactions, persistence)
2. Other business object dependency

An EJB Container serves these objectives for business objects which are written as per EJB specifications. For example, EJB container does lifecycle management of EJB, EJB can tell container about its “service needs” through declarative semantic of an EJB descriptor. EJBs can also resolve their dependencies upon other EJBs through JNDI lookups

An EJB container is termed as “heavyweight” container as for it to serve its objectives it dictates certain interface dependencies upon EJBs. For example, any object which needs to run within EJB container must implement home and remote interfaces. A lightweight container on the other hand is less invasive than this. For example, Spring container can host any java object without it requiring implementing any specialized interface. This is most fundamental difference between lightweight containers like Spring and so called heavier containers like EJB container. A lightweight container can run virtually any java object. This implies that any java object can be run inside any lightweight container.

The lightness of Spring also emanates from fact that the java objects it manages are run inside regular JVM with Spring just being used as a system library. An EJB container on other hand is a full blown application in its own right. Lightweight containers also like to flaunt their IOC and AOP abilities. IOC which is Inversion of Control is a design pattern which is not documented authoritatively anywhere but conceptually it is all about taking a control away from an object to its container or framework, which is very crux of any framework. IOC as refered by most Lightweight container is about “Dependency Injection IOC”. In EJB system, an EJB component has to lookup its dependency upon other EJBs or resource like Data Source through JNDI, whereas in a lightweight container these dependencies are “injected” into managed Object. This way dependency lookup control is taken away from an object and hence name “Dependency injection IOC”.

Another features advertised by lightweight containers like Spring is their AOP, or Aspect Oriented Programming features. An Aspect is a behavior which cuts across set of objects. A well known example of an Aspect is “transaction management” which is required by most of systems. AOP containers provide these cross cutting services through Aspect oriented techniques. It is possible in these containers to create new Aspects (like Auditing) and attach them to target objects.

Spring does not require to be run inside any Application server, which means that it can also be used for standalone POJO applications. The biggest advantage of spring is that it gives a managed environment for POJO’s without being API invasive and intrusive (There are no callback method from container). Spring framework can also be viewed as “Framework for frameworks”, which is that it can be used to snap together various frameworks targeted at different layers of J2EE stack and glue them together as a cohesive system. In fact, Spring seems to provide a very attractive alternative to EJBs for a small to medium scale J2EE web system where use of a full bloodied EJB container might be luxury and overkill in many ways that one.