Richard Monson-Haefel's Blog

J2EE Archives

OpenEJB: The BEST way to test EJBs

Advanced EJB Testing with OpenEJB

David Blevin's and I founded OpenEJB some five years ago to create a fast and lightweight EJB container system that could be easily embedded in any application (its even been used in handheld devices). I stayed with the project for the first couple of years, but haven't been very involved in it since. David Blevins, on the other hand, has kept the project going and has continuously improved it (along with a small army of volunteers). Today OpenEJB the EJB container system used with Apache Geronimo - its very powerful, fast, and best of all lightweight.

The fact that OpenEJB is so lightweight and embeddable is why it actually serves as an excellent EJB testing tool. It starts up and deploys EJBs is seconds (that right I said seconds, not minutes). In addition, it provides a robust and fully compliant EJB container system - one that is used by Apache Geronimo for production enviorments.

Rather than create some type of home spun "moch" container system use OpenEJB. All the hard stuff is done - you don't have to re-invent the wheel. As you'll see in Rupp's article, OpenEJB is ridiculously easy to work with and provides you with the best EJB testing framework available today.

I would go a bit further and encourage people who are using commercial products like WebLogic and WebSphere to use OpenEJB in development. A developer can deploy and redeploy his EJBs over and over again quickly, giving him time to focus on developing his EJBs rather than waiting for a server to start-up and deploy an J2EE application - a process that I believe saps as much as 80% of development time.

How Tomcat Works, the book.

A few months back, maybe a year ago, I was contacted by Budi Kurniawan. Budi wanted advice on self publishing - I don't even remember what I told him, but he says it was helpful so there you are. Last week Budi contacted me to tell me he has successfully written and self published his first book, How Tomcat Works. You can buy it directly from Budi and get a 45% discount (www.brainysoftware.com) or from Amazon.com. How cool is that!?

Well, I've been reading Budi's book and I have to say that it's really excellent. I mean, I can't put the thing down! His writing style is really straight forward and engaging. The book is in need of some serious copy editing, that's for sure, but in many cases those little rough spots add to its home-grown charm.

Budi's book, How Tomcat Works teaches the reader exactly how the Apache Tomcat Servlet engine works. Budi starts with a very simple (3 classes) web server and slowly, over the course of a dozen chapters, enhances that example until it becomes Tomcat. It's a really cool approach to explaining the inner workings of a system and I just love it. I'm staying up way too late reading the thing and learning a lot about how Tomcat works.

You don't have to be rocket scientist to appreciate the book or understand it. If you have intermediate to advanced Java skills and know something about Servlets, you'll have no problem at all and you will learn a lot.

I hope the book continues to be as good as the first couple of chapters. If it is, I'll probably become its biggest booster. In my opinion, knowing how the software you use works under the covers is far more important than anything else you can learn. Patterns and APIs are fine, but nothing beats knowing how things really work. The best in the business have this type knowledge, so if you want to be the best at Servlet development, than this book is for you.

9 of Clubs Seeks a new Deck of Cards

Recently I had the honor of being named one of the 53 most influential people in the Java industry by The Middleware Company. My card was the 9 of Clubs – I have no idea how to interpret that distinction. Obviously, it’s a nice complement especially considering that the votes came from developers who subscribe to TheServerSide.com mailing list – a resource I consult regularly even if the threads are frequently hijacked.

You would think that a guy in this deck of cards is probably making gross amounts of money and living a leisurely life. I can't speak for the other people on the list, but that doesn't describe my life at all. I work really freaking hard – as hard as anyone reading this blog – and I don't own a yacht or drive a Lamborghini. I'm not poor by any stretch of the imagination, but I'm not going to make the Forbs list anytime soon.

The truth is being an independent is hard work. I've been at it now for about five years and its never been a cake walk – ok occasionally it's been easy, but most of the time its not. For the most part I'm busting my butt trying to convince companies that I'm worth what I'm worth even if John and Jane Doe charge a faction of the price. The truth is, I'm usually over qualified for most consulting gigs so the spectrum of opportunities available to me is actually less than the average developer.

I heard once that winning an Oscar in Hollywood is a double edge sword. Actors who win are recognized for the quality of their work, but subsequently find it hard to find work. I even heard it descried as the Oscar "Death Knell": Its great to win, but its better to get nominated. This is probably a bit of hyperbola and I don't mean to compare my meager success to winning an Oscar, but the truth is: Success is measured in many ways and peer recognition – while wonderful – doesn't always translate into big bucks and loads of free time.

After more than five years of going-it-alone, I finally asked for help. This Monday I decided to try my luck for the first time with the grape vine. Although I have frequently helped others find work, I've rarely asked for help myself. Why? Well I guess I felt that I should be able to find my own work. Also it’s a matter of pride. I don’t like to ask for help. I don't want my peers to know that its hard for me to find work that fits my skills and pays well – everyone seems to assume that if your well known you automatically make tones of money. Its not always true.

I've been very involved in the Java industry. Two months after I started learning Java I started the Wisconsin Java User's group – that was back in the spring of 1996. Since than I've volunteered for all sorts of things from open source projects to JSRs and I'm proud of what I've accomplished. The culmination of all this altruism was being voted into the JCP Executive Committee last fall – an honor I've take very seriously.

I've done good things for our industry, but I feel its time to step back and let others have the glory. I have a family now. My boy, Henry is about 2 1/2, and my daughter, Olivia, is just 9 months. I need to look inward toward my family and put them first. That means I need to find a stable job with some longevity and hopefully something with a lot less travel. I think I was honored with the 9 of clubs because I've donated so much of my time to the Java community – people will probably laugh at that, but I can't think of any other reason. Working on expert groups, open source, and the JCP consume enormous amounts of time, but pays nothing, zip, zilch. That's ok, I knew that going into these endeavors and its expected that I should be able to leverage my contacts and name recognition into a living. I have done that to some extent, but it hasn't been easy. You still have to find work that fits your credentials and sell yourself at rates that are affordable – these are usually contradictory objectives after a certain point.

OK, so why this blog? Well, I'm hoping that someone will read it and say "Hey, I got just the job for this guy! What's his e-mail address?" (btw it is Richard@Monson-Haefel.com). Head hunters and other professional placement guys should not bother to contact me - you guys are evil.

There is another reason: On occasion I've had people ask me how they can manage their career to become more successful – to be more like me. This always makes me wince. I've been fortunate – no doubt about it – but I wouldn't recommend my life style to anyone. It’s a lot of work with very little pay. As I said, peer recognition is great – its probably the best recognition you can have – but making a living is not a bad thing either. I'm honored to be counted in that deck of cards with the likes of James Gosling, Rod Johnson, Gavin King and others – but its time to join a new deck – one that gives me more time with my family and actually pays a salary.

JSR-241: Groovy – A New Standard Programming Language for the Java Platform

Until now the Java programming language has reigned supreme as the standard programming language for the Java Platform. It has served us well for close to nine years, but it cannot be all things to all people. And it shouldn't. The Java Programming language, like C++ and C#, is a strongly and statically typed programming language. While this type of language, sometimes called a "conventional" language, is useful for solving many problems, it is not a panacea. Conventional programming languages are very exacting, meaning that you have to dot every 'i' and cross every 't' in order for the program to compile. This orthography of statically defining all the types may result in more predictable code, but it also tends to slow developers down.

An alternative to conventional programming languages are agile programming languages like Python, Ruby and Perl among others. These agile languages have long been called "scripting" languages, but that term is not, IMO, sufficient. Many in IT perceive scripting languages as layman languages that sacrifice technical sophistication for easy of use. This may be true of some scripting languages, but it's certainly not the case with Python, Ruby or Perl. These are dynamic and powerful programming languages that happen to use less syntax to accomplish more.

To be perfectly honest, although I'm listed on the JSR as a co-spec lead, I'm a Johnny-come-lately to the Groovy bandwagon. Groovy already has a grass roots following and all the credit for the development of Groovy goes James Strachan and other contributors to the Groovy open source project. I'm not a language designer, but I understand the power that languages like Python and Ruby offer developers and I believe it is time for the Java Platform to include an agile programming language. It's this personal conviction that led me to initiate and co-develop JSR-241 with James Strachan and Gier Magnusson of Apache. My role as a specification lead is to manage the progression of this JSR through the JCP and author the Groovy Language Specification – two tasks that can be terribly distracting to those doing the really hard work of developing the JSR itself.

Groovy represents the beginning of a new era in the Java platform, one in which the Java community embraces language diversification and harnesses the full potential of the Java platform. It’s the recognition that the Java is more than a programming language; it’s a robust platform upon which multiple languages can operate and co-exist. To me this has always been the unrealized promise of the Java Platform.

The Java programming language is, simply put, a convenient abstraction for the real language of the Java platform: byte code. As a user-friendly abstraction for byte code the Java programming language is powerful, but it's not omnipotent. There are circumstances in which a different language, an agile programming language, is more expressive and productive.

So why Groovy? Why not Jython or JRuby? Why not one of the dozens of other programming languages that are designed to run on the Java Virtual Machine? It's my opinion, and I believe the opinion of those who support this JSR, that Groovy is the best choice because it was built from the ground up for the Java Platform and uses syntax that is familiar to Java developers, while leveraging some of best features that Python, Ruby and Smalltalk have to offer. Jython and JRuby are excellent examples of how existing languages can be ported to the Java platform, but they are, after all, ports. They use syntax that is not designed with Java developers in mind and they are founded on a completely different set of code libraries. Groovy is designed for Java developers and its foundation is the standard APIs of the Java Platform.

13 improvements for EJB

What struck me, after counting and grouping relevant posts, was that the developer community desperately desires a simpler programming model for EJB.

In particular developers appear to be most interested in the following:

1. Ditch CMP or make it simpler like Hibernate or JDO
2. Use a POJO programming model
3. Add support for Interceptors/filters/AOP.
4. Eliminate/Consolidate the component interfaces (remote, local and endpoint).
5. Make deployment descriptors more like XDoclet
6. Instance-level authentication/entitlement.
7. Replace the JNDI ENC with Dependency Injection (a.k.a. IoC).
8. Add a Mutable Application Level Context
9. Support development and testing outside the container system.
10. Define cluster-wide singletons for EJB.
11. Clearly specify and standardize class loading requirements.
12. Standardize the deployment directory structure for EJBs.
13. Support Inheritance.

Some of the items can be grouped together to give more weight to a particular approach. For example, item 1, 2, 4, 7, 9 and 13 all seem to point at a CMP programming model that is more like Hibernate. Hibernate uses a POJO programming model with dependency injection (IoC) and is not dependent on client interfaces. In addition, Hibernate applications can be developed and tested without a container system. A tip of the hat to Galvin King and crew.

Other items were interesting but not surprising like asking for an XDoclet-like vendor-agnostic deployment processes. This is a big concern of mine since EJB isn't really portable in its current incarnation – you can't just drop an EJB JAR into most J2EE servers without adding some vendor specific deployment information. Actually this aligns nicely with the request that EJB define a standard directory structure for deployments similar to Web components.

The mutable application level context was a surprise for me. Standardization and specification of class loading behavior was not a surprise. Requests for instance-level authorization was also expected – it's something developers have been asking for since EJB 1.0.

I was delighted to see so many posts on this subject. Clearly people feel there is much to be done. I was less excited to see the thread wander off into Spring vs. JBoss vs. Mike Spille territory – but I found those posts interesting too.

Obviously, there are better mechanisms for measuring public opinion than a blog. Perhaps someone will take on the task of organizing a more accurate pole, but for me the information and posts were very informative. I read every one of them. I greatly appreciate the time and effort so many put into responding. Thank you.

I'm sharing these findings with the JSR 220 (EJB 3.0) Expert Group and expect your comments will generate a lot of discussion and a great deal of solid action by the group members. Keep an eye on JSR 220, eventually it will make it into public review at which time you'll have something solid to review and comment on. Your feedback is critical to the success of EJB.

You can make EJB better

What do you like or dislike about EJB? If it's broke, how should we fix it?

This is an excellent chance for you to make a real difference. All I ask is that you stick to the facts and your own experiences. Please try to avoid flames, zingers, and debates so that I can make the most of your feedback.

IBM and BEA: Are they thumbing their noses at the JCP?

The Java Community Process (JCP) is designed to facilitate the creation of standard, vendor-agnostic Java technologies. This is my quick and dirty definition, the keys to which are the words "facilitate" and "vendor agnostic". The primary objective of the JCP is to provide a framework for defining Java standards. In most cases, an expert group develops the standards based on a set of objectives defined by the proposed JSR (Java Specification Request). In other words, usually the specification is grown from scratch under the auspicious of the JCP. This, however, is not a requirement. The actual specification can be grown from scratch (e.g. JSP, JSF, EJB, etc.), based on established non-JCP standards (e.g. CORBA, DOM, SAX, ext.), or an existing implementation or architecture as is the case here. It really doesn't matter very much as long as the JCP accepts the JSRs, approve their progression through community and public drafts, and endorses the final specifications. The bottom line is that the JCP is not supposed to stifle the development of specifications seeded outside of the process - to the contrary. If leading vendors want to hammer out the details before beginning a JSR, then so be it. Who cares how it got started?

Contrary to what my friend from Microsoft Land may say, the JCP is not doomed to obsolescence – not by a long shot. The truth is, IBM and BEA need the JCP. Neither of these companies could go it alone, outside the JCP. For example, before EJB/J2EE, both IBM and BEA marketed proprietary server-side component models. IBM's was called Component Broker and BEA's was called M3 (a.k.a. Ice Berg). Both vendors abandoned their proprietary architectures in favor of Enterprise JavaBeans. Why? Because their customers had more confidence in standards based solutions than proprietary ones. It’s the money that talks, and the money (customers) prefers standards to proprietary solutions. That hasn't changed and since IBM and BEA are not a standards organization, they will always need the JCP – or something like it - to manage the standards on which their products are built.

A little history illustrates the necessity of a standards organization like the JCP. In the mid to late 90's CORBA, not J2EE, was the leading application server standard for non-Microsoft vendors. The OMG defines the CORBA standards and initially vendors fell in line with those standards. But after Visigenic and IONA emerged as the market leaders (not unlike IBM and BEA today) they became more antagonistic toward the OMG. Now to be perfectly honest, I think the OMG was getting a little carried away, but that doesn't change the outcome. IONA and Visigenic thumbed their noses at the OMG to their own undoing. Where are Visigenic and IONA today? Are they still the major players? No, I'm afraid not. They've become minor players in the J2EE market. EJB and J2EE came along and everyone – vendors, customers, and developers – jumped the CORBA ship and went to J2EE. J2EE is the centerpiece of server-side products in Java Land because it’s a vendor agnostic standard that vendors respect and follow. IBM and BEA know this and are not eager to repeat the mistakes of their predecessors. They will continue to work with and conform to the requirements of the JCP. If they don't, J2EE will be lost and so will IBM's WebSphere and BEA's WebLogic.

The Rebel Alliance: Apache / ObjectWeb Join Forces

ObjectWeb, if you haven't heard of it, is an organization similar in purpose to the Apache Software Foundation (ASF). They have a fairly large offering of their own, but until recently they have predominantly used a LGPL license, which is simply incompatible with the Apache's BSD-style license. When Geronimo was announced back in August, some of the engineers from ObjectWeb approached us (I'm a Geronimo team member) about collaborating on some projects. Their JOnAS and JOTM development teams are also working toward J2EE Certification so they are creating a lot of the same components (EJB container, Transaction Monitor, Messaging, etc.) that the Geronimo folks are working on. The ObjectWeb engineers suggested that we collaborate on facilities common to both projects. The Geronimo team was very interested and agreed to meet with ObjectWeb at ApacheCon. That meeting took place last night.

The synergy, other than licensing, between ObjectWeb JOnAS/JOTM and Apache Geronimo appears to be excellent. Our development cultures are admittedly different but the differences actually strengthen our alliance rather than weaken it. The JOnAS/JOTM folks are, on average, older and more experienced in big-iron (mainframe kind-of stuff). Their depth of knowledge is really incredible – David Egolf of ObjectWeb kept Geronimo developers mesmerized for hours after the BOF talking about mainframe transaction processing. It was, for me at least, like finding my own Obi-Wan Kenobi. Given the chance I would have spoken to him all night.

While the depth of knowledge exhibited by the JOnAS/JOTM teams is extraordinary, the ObjectWeb folks tend to be slower out the gate than Geronimo. This is because they are more methodical. They are, in essence, the old men of the sea. The Geronimo team, on the other hand, is younger. These young-upstarts tend to develop solutions quickly and redesign often. But the output form the Geronimo folks is staggering. For example, the Gerionimo team is close to having an alpha release of the J2EE Geronimo platform four months after starting development. The technical expertise of the Geronimo folks is nothing to sneeze at either – almost everyone I've been working with has developed at least one successful open source container system before Geronimo.

So how will these teams work together? We will leverage each other's unique cultures and experience to co-develop common components for our J2EE container systems. The best, and first, example of this is JOTM. JOTM is ObjectWeb's transaction processing monitor. Transaction processing monitors are notoriously tricky critters to get right, and being able to plug in an existing and – according to Dain Sundstrom – excellent implementation like JOTM is a huge win for Geronimo. In addition, the JOTM people will go on to develop journaling and recovery, which is perhaps the most difficult and most critical aspects of a enterprise transaction manager – it's what makes transaction managers truly reliable. No open source project today offers a real journaling and recovery system. JOTM will be the first. Since the JOnAS/JOTM folks have more depth in this area, the Geronimo team is happy to endorse and support their development efforts. From this point forward, Geronimo and JoNAS will co-develop, maintain, and utilize JOTM for their transaction processing monitors. Of course, this would not have been possible if the JOnAS team had not agreed to change the license of JOTM from LGPL to BSD-style at the meeting last night. That was the last barrier to collaboration between the groups, and it turned out not to be a barrier at all.

For their part, ObjectWeb is thrilled to have the support of the Geronimo team and just as importantly, they are excited about the prospect that their software will be reused outside of ObjectWeb. This is open source after all; we believe in sharing software, exchanging ideas, and cross development. Geronimo will be contributing resources and unparalleled expertise in the Java platform – no one leverages byte code complication like the Geronimo team.

It's been an interesting turn of events. Before the BOF with ObjectWeb last night, the Geronimo folks worked together 16 hours a day at ApacheCon and were inseparable. As of today all that has changed. Now it’s the Geronoimo and ObjectWeb folks that are inseparable: The old men of the sea share their decades of hard-won big-iron wisdom; the young Geronimo upstarts share their passion, container development experience, and Java platform expertise. The feeling of camaraderie is sincere and an unadulterated. This is the start of a powerful alliance and the beginning of many new friendships.

The State of Geronimo

What does that mean? Well, it means that Geronimo, when it's ready, can be tested against Sun's Technology Compatibility Kit (TCK). An application server has to pass the tests in TCK in order to be called "J2EE Compliant". The fact that Sun has extended this license to Apache, is a huge vote of confidence in the Geronimo project. It says that Sun believes that Geronimo is a legitimate application server that may, provided it passes the TCK, be called "J2EE Compliant." Although, ObjectWeb (another open source organization) was given the TCK scholarship (something Geronimo still needs), Geronimo is the first open source project to receive the license. The license gives you permission to run tests against the TCK, but it normally costs a butt-load of money to label an application server as compliant – that licensing fee is one of the ways that Sun realizes income on J2EE. The scholarship, on the other hand, is designed to support non-profit organizations. It basically waves the costs that commercial vendors are required to pay in order to use the "J2EE Computable" branding.

But wait! That's not all … it was also announced that Geronimo will be using OpenEJB as it EJB container system. Actually, several of the Geronimo folks have been hard at work on a new OpenEJB branch that can be used by Geronimo and the established OpenEJB community. This is an item close to my heart, as I co-founded the OpenEJB project with David Blevins four years ago. It's been a blast working with the OpenEJB code base again. My hat is off to David and the rest of the OpenEJB community – the fact that the Geronimo folks chose to use OpenEJB, rather than develop their own EJB container system is a huge endorsement of that project.

There is more to this, specifically about Geronimo collaborating with ObjectWeb, but I'll cover that tomorrow …

This work is licensed under a Creative Commons License.