Tuesday, July 26, 2005

Case for a POJO MicroContainer

People who are familiar with J2EE realize that it is a complicated/bloated and cumbersome world. How easy it would be if we could deal with Plain Old Java Objects [POJOs]? Remember writing a "Hello World" program with EJB 2.1

Pundits will tell you that EJBs are not for Hello World kind of programs. I agree. It was just an example.

J2EE provides you a container and as a component running in the container, you get all the services the container is capable of - naming via JNDI, Security, Transactions (Yummy), EIS Integration via JCA (includes good old JDBC connections), caching, pooling etc etc.

Consider the case where I have a POJO. Lets call it the Employee POJO. Nothing fancy about it. Now as an Employee POJO, I want database access, transactions to update my salary (ha ha), security controls (so that only my Manager Pojo) updates my salary etc etc.

To get all this, I would go J2EE. I would write an EJB and cry a lot because to test my business logic, I would need a container. AND the container takes a hell lot of time to start (Paradigm changed by JBoss of course - fast startup).

Now since you have read this much on my blog, lets cut to the chase.

Since I mentioned I want to deal with POJOs and POJOs alone, lets do POJOs only. But what about the services I need from the container? Gawd, I will have to instrument my code to lookup the service, implement the EJB container callbacks etc.

Here is my code:


public class Employee
{
String name;
float salary;

public void updateSalary(float addAmount)
{salary += addAmount;}

}


Damn, simple POJO. Now I want to implement this as a stateless session bean and I want the container to provide the "REQUIRED" transactional isolation. Only the "Manager" roled user cannot invoke the updateSalary method. All this is possible by making the POJO implement javax.ejb.SessionBean interface and add dummy container callback methods. Go to the f***ing deployment descriptor, set the security and transactional semantics. Excellent work, Joe. I said I wanna deal with POJOs alone. Now you made me do SLSB. What if I want my POJO to be a servlet, a Web Service endpoint. Sweet Jesus, you are asking too much.

Don't despair! There is help on the way. With the introduction of JDK5 annotations, life will be simpler for developers. Plus less XML deployment descriptor hell. With J2EE5 and EJB3, annotations will do all the work AND THE CONTAINER WILL iNjEcT the services you need.

Lets look at the same POJO.


public class Employee
{
@Inject EntityManager manager;
String name;
float salary;

public void updateSalary(float addAmount)
{salary += addAmount;}

}


Don't go with the syntax. I am just trying to get the message across. Now the @Inject annotation will tell the container that I need this POJO to be persistent. Wow!! I got the entity bean capability for my POJO.

Now how about if my bean needs transactions. I will need the services of a transaction manager. Let the container inject it.


public class Employee
{
@Inject TransactionManager manager;
String name;
float salary;

@Transaction (type=required)
@Security (role=Manager)
public void updateSalary(float addAmount)
{salary += addAmount;}

}


Now I explicitly asked my method to have the REQUIRED semantics. If I do not specify, just because the container injected a TM, it can choose the default transaction semantics.

I am not done. Where are you going? Now I want to expose this bean as a web service. Thanks to JSR 181 annotations, all I need to do to the pojo is the @WebService annotation.


@WebService
public class Employee
{
String name;
float salary;

public void updateSalary(float addAmount)
{salary += addAmount;}
}


So having a POJO container, server or microcontainer or whatever you wanna call it, is going to be good. The container will be lightweight, can help in testing and will be mostly driven by annotations or some form of a xml dd. The idea is not the declarative descriptors in xml to drive the pojos.

The things you need to derive from this blog post are:
1) POJO based development is easier.
2) POJOs running in a container when annotated appropriately, can run an enterprise.
3) The POJO container can inject services into the POJO at runtime. As a POJO, you can specify which services you will need and the container will inject them. Instead of the gazillion default services that an EJB undergoes prior to J2EE5.
4) Take a POJO, add annotations and drop it in a container - it will become an EJB or a Servlet or a Web Service based on the services that are injected.

Now what if my team mate is a dumb ass and he does not know which annotations to use. Just specify the annotation and do not provide a type for the annotation. Let the container inject the default service [Eg: By default, the transaction type that is injected is "REQUIRED"]. Now if my dumbass team mate annotates @Transaction(type=never), the container will run the pojo method with no transaction.Now you know why he is a dumbass.

Monday, July 25, 2005

J2EE Classloading Mysteries

The J2EE specification has not clearly mandated the classloading scheme to be used by the containers. Hence every app server vendor does it in a different way. WebSphere does it differently, JBoss does it diff, Oracle does it diff and WebLogic does it diff.

Remember that in J2EE, Thread.currentThread.getContextLoader() is the king and the only method that should be utilised to do classloading. Debu Panda from Oracle has a blog on some best practices for J2EE classloading. J2EE Classloading Best Practices

OnJava Article on classloading. Inside Class Loaders: Debugging

Now if you want to learn about the internals of classloading, the following article is useful,Internals of Java Class Loading

Ok, for advanced classloading, read Advanced Classloading

Classloaders are powerful and are key to hot deployment of applications, that we have come to love, as developers. Thanks to JBoss.

XDoclet versus Java Annotations

I have nothing against XDoclet. It eases the development process for many developers. One issue I see is standards/maintenance. If somebody develops some custom doclet tags, be assured that they will not maintain them for ever.

Instead with the introduction of annotations in JDK5, you can get the power of xdoclet in a standard way. Plus EJB3, J2EE 5 as well as JSR-181 annotations for webservices all aim to ease development pain and the wrath of xml files.

I feel annotations are the way to go for developers.

Thursday, July 21, 2005

.Net versus Java

I moved over to the Java world from the MS world around 1998. Ever since, I have been attached to open standards, open forums, zero monopoly blah blah.

I fell in love with Java ever since, as I did not have to deal with the platform idiosynchracies. Now .Net is trying to make a comeback in my mind.

I had taken a huge laugh when MS created C# and then .Net and then Passport. Okay, C# gives you the best of C++ and Java. As I have been focussing on Web Services, a topic that is hot right now is how to make .Net programs communicate with Java programs.

MS, IBM etc created Web Services for this reason. Interoperability!!!

Since Web Services has promise, I need to give .Net a shot.

Apart from this, there is discussion about integrating .Net and J2EE via JMS. Ofcourse messaging can be the glue. Take a look at: .Net/J2EE via JMS

But I think there are two simpler ways of integrating .Net and J2EE (or JEE - whatever):- Databases and Regular files. BUT the developer has to do the brunt work in a non standard way.

I was reading Eric Newcomer's book: "Understanding Web Services". In that he mentions that J2EE views Web Services as Objects and Classes that will be turned into webservices by the webservice provider, whereas .Net views Web Services as something that will be created by a developer, which will be turned into Objects and classes by the .Net implementation. How true? Microsoft has always been the King at providing point and click tools to the developer/end user and does the brunt work (however mysterious it may be) in the background.

Java and Portability

Writing Java programs was a blessing to developers who did not have to bother about the platforms on which the programs would run. But as Java became enterprise quality and an enterprise darling, developers have to be aware of JVM issues and other platform issues. They should also befriend their sysadmin and their DBA, as they are as relevant to your project success as your quality code is.


Googling, I found this link, which talks of why Java is a nightmare for Sysadmins. Java Sucks For Sysadmins

Java IO abstraction creates the most problems on various platforms in my opinion.

Get to know swap spaces, file descriptors, ulimit command. Just because you know java.io.File, you are not an enterprise developer. Kidding!

Wednesday, July 20, 2005

CJUG Panel on Java Performance

Last evening (Tuesday) was a great evening. I hosted the first ever panel on Java Performance at the Chicago Java Users Group. CJUG's PR Janet Traub made it happen by getting the support of Bank Of America. So we used the great conference room at the Bank location on Lasalle Street, adjacent to the Chicago Board of Trade.



Since it was the first time, we were holding such an exercize, we invited panelists from the Chicagoland region only. Why take the trouble of inviting panelists from out of town, to disappoint them, if we do not meet their expectations?



Ok, lets get to the story now.



When it comes to Java and the topic is performance, the first thing that eludes anybody's mind, is the JVM performance. Very few Java knowledgeable people know about the JVM tuning/settings. They take the JVM for granted. Hence CJUG was very fortunate to have Brian Doherty from Sun Microsystems on the panel. Brian is a Chicago native and he works in the performance group dealing with the Sun JVM. So when it comes to benchmarking, Brian is the guy.We needed a representative from BEA to talk on JRockit and BEA suite of products. Siva Krishnan from BEA was present at the panel.There were two representatives from Oracle - Phil Bergman (Principal Solutions Architect, J2EE Application Server) and Phil McGlaughlin, formerly Actional and now Oracle.



Jon Hansen, formerly Sun Professional Services and now an independent consultant was on the panel. Jon is an expert in real world deployment of SOA, XML and Web Services for many big customers.



Tim O'Brien, author of a book on Maven and Jakarta Commons, who is an independent consultant, was also on the panel. Rob Lambert who is an independent consultant and has experience in Spring Framework was on the panel. But Rob did not get too much of a window to participate in the discussion. Dave Orme, Eclipse Visual Editor Lead and currently working for db4objects was on the panel too. Brian Pontarelli, CJUG president and Senior Engineer at Orbitz was there.



Questions from attendees.



Do the vendors like Sun,BEA, JBoss,Oracle etc do performance benchmarks before they release the product?



The answer from the vendors was that they do run a lot of industry standard benchmarks before they release the products. A general consensus was that many times benchmarks are done to clinch sales deals, as customers request for benchmark numbers. Also, benchmarks do not always cover real performance issues that may exist, but they do provide a lot of insight into the product for the engineers who are running the benchmarks.

What are the steps one can do to achieve performance?



Brian Doherty quoted Donald Knuth's famous quote: "Premature optimization is the root of all evil.". There was an argument as to whether it is suitable to first implement the algorithm and then optimize it or write a simple/optimized/maintainable algorithm.

General notes from the panel:



- Java Performance is the onestop location for Java Performance.

- VisualGC and JConsole are great tools to attach to the JVM in production where regular profiling tools like JProbe etc are not recommended.

- Brian Pontarelli discussed how Orbitz was revolutionizing computing via Jini and he discussed various benefits of Jini over traditional RMI.

- Some panelists agreed that the root of performance issues or a project being in mess is not really a technology problem but because of personnel and business expectations.

Sunday, July 17, 2005

Chicago Java Users Group: Panel on Java Performance

Its been two years since I have been associated with CJUG. On Tuesday (July 19), CJUG is holding a very important event, a panel on Java Performance. It will cover all facets on Java - JVM Performance, J2EE Performance, Applications performance, Monitoring etc.

Be sure to be there. http://www.cjug.org

Kent Spillner in Bangalore

Kent Spillner is a good friend of mine from Chicago. He is as old as my younger brother. He has helped me in moving furniture to my place from IKEA, Harlem Furniture etc.

He is now in Bangalore, getting trained at Thoughtworks. He was reading a lot of travel books before he went to India. I have asked him to find a nice Indian girl and get hooked when he comes back to the US.

He has told me over AIM that he likes Bangalore. I personally liked Old Bangalore, that was laidback and it was lot more fun + less crowded.

Who wants to see traffic jams on Sunday at 11am? Hey, it was just after 'Mahabharat' on TV. Kent is enjoying Bangalore. Eating all the yummy dosas, chats and the hustle/bustle of big city.

Kent, your 'firangi' story of drycleaning and underwears is hilarious.

For others, here is Kent's blog address:
Ken's Bangalore Blog


And his usual rants:
http://sl4mmy.blogspot.com


Now, Kent being in Guzzlers Paradise, I suggest that you retain the habit you will learn at Bangalore, when you are back in Chicago. I am counting on you for a decent New Year Binge. We need to celebrate with Prashanth (my other buddy)

Where to blog?

I have been blogging at various places - JBossBlog, Jroller etc. Never found one place to blog on technology as well as general stuff. Blogspot looks like a good place to blog about the day to day events.