One thing I hate is history lessons. Nothing annoys me more than picking up a book on a technology that I'm interesting in learning, only to be given a ridiculously long lecture on the history of the Internet. Not that I don't find history mildly entertaining, but when I want to learn something, I want to learn it, not learn a great big long history that really doesn't have anything to do with what I'm studying.
With that being said, I'm going to lead in with a short history of EJBs. While I'm a little remiss in doing it, I do feel that it is important to understand how we got to where we are today in the world of Enterprise JavaBean development.
Interestingly enough, when the whole EJB thing started out, there was only one type of Enterprise JavaBean, and that was the Session bean. Now, if you know anything about EJB development, you might find that a little strange, after all, Entity Beans, a special type of EJB, have been around for years, and anyone that's tinkered in that shallow pool of enterprise messaging has heard of the other, third type of EJB, the Message Driven Bean, but in fact, when the whole EJB thing got started, there was only one type of EJB - the Session Bean.
If only one thing can be said about enterprise programming, it's the fact that it is hard. And not only is it hard, but the same types of development issues are constantly rearing their ugly heads.
For example, if you've got a powerful piece of business logic, what happens when a large number of concurrent business clients request access to it? Many good pieces of code fail when placed under a heavy, multithreaded, load. And for that matter, how will enterprise Java code be accessed by remote clients, or perhaps even clients that aren't necessarily even Java clients. After all, many established Fortune 500 companies have large infrastructures that speak more CORBA than Java.
And of course, security is always an issue. People always want to secure business logic, especially when it's being accessed by all sorts of remote clients that might not necessarily have your application's best interests in mind. So, to appease all of those paranoid administrators that sit on architecture review boards, enterprise developers recognized that they needed some way to secure their scalable, multithreaded, remotely accessible components.
So, as intelligent and handsome, enterprise Java developers were recognizing that Java applets running in a web browser weren't going to address all of their real world needs, they started to play with the idea of a container managed component that would address the challenges of enterprise development in Java. At the time, Servlets and JSPs were already a way for Internet browser based requests to be handled in a secure, multithreaded and scalable manner by what is known as a 'web container' or 'servlet engine.' Why couldn't business components have the same type of thing, where the problems of remotely accessible, multithreaded and secure business logic could be accessed just as easliy as a web page could be requested, rendered, and returned to a client?
So, as the idea of an EJB emerged, what we had was a very simple and effective, remotely accessible, scalable, secure and multithreaded business component that was known as a Session bean. That was the good old days, when life was simple. But the simple times didn't last too long in the EJB world.
If you've ever worked with developers, you know that they can never leave things alone. They always have to make good things 'better', which typically results in everything getting all messed up, and that's exactly what happened with Session beans. You see, developers figured that since Session beans were so great, they'd be even greater if we put a bunch of database code in them, and mapped those Session beans to database tables. Developers across the globe started sticking database access code within Session beans, and were just making a mess out of Session EJBs. It was at that point that it was decided to introduce a new type of EJB into the mix, the Entity Bean, which would be a special type of EJB that maps Java fields and properties directly to database tables and columns. It was a bit of an ugly, kloogy hack on the Session bean, but everyone was excited about it at the time, so the entity bean proliferated.
Of course, the Entity Bean and Session Bean combination didn't solve every problem. You see, business logic and database access represent only two of the three legs that keeps the enterprise programming stool standing - the EJB spec hadn't addressed messaging at all, and again, developers were creating all sorts of awful solutions that stuffed JMS code in an already over-stuffed Session bean. So, the next step in the de-evolution of the EJB specification was the introduction of a Message Driven Bean, or MDB, which frankly, didn't look like an EJB at all, and skirting around many of the rules and design guidelines we had taken for granted when it came to EJB development.
Anyways, the picture I'm trying to paint here is one of a very reactionary evolution of the EJB specification, where additions and improvements were made by duct taping them on top of the original specification, which was really awful, especially in light of the fact that Java itself has always been very elegant and symmetrical in its evolution and growth. The fact was, by time the EJB 2.1 specification came around, EJB development looked ugly, and many industry experts were recommending against it.
In my own 2004 book, What is WebSphere?, I wrote a section on when to use EJBs, which more than anything, tried to dissuade people from using EJBs unless absolutely necessary. At about the same time that I was writing that, Rod Johnson and Juergen Hoeller released Expert One-on-One J2EE Development WithOUT EJBs, emphasizing that enterprise development could be done without these heavyweight components. Rather than solving many of the key challenges developers and architects face when building enterprise applications, EJBs themselves were starting to be seen as the problem, and people were avoiding them. I know that I was.
But all of that has changed with EJB 3.0. The developers and the contributors to the EJB specification recognized pretty much as soon as the EJB 2.1 specification came out that things were going in the wrong direction.
Version 3 is a significant departure from earlier EJB specifications. Rather than being onerous and intimidating, 3.0 EJBs promise to be easier to code and deploy, using a POJO based (POJO = Plain Ordinary Java Object) approach to development, leveraging annotations to allow for declarative bean metadata, as opposed to using detached XML files, and EJB 3.0 even incorporates the idea of dependency injection for the first time ever.
And the whole approach to enterprise development with EJB 3.0 is much more philisophically sound, as can be seen by the EJB 3.0 JSR document itself. (JSR 220)
Unlike most Sun JSRs, the EJB 3.0 spec is actually broken down into three separate documents, which together make up the specification.
The first of these thre documents is named the EJB 3.0 Simplified API Document, which details the new, simpler approach to EJB development that we see with this specification.
The second document describes the Java Persistence API, which represents a much simpler and easier way to implement data persistence within an EJB, or even non-EJB, POJO based, environment.
Finally, the third document, the EJB Core Contracts and Requirements, which essentially outlines what a developer can expect from any 3.0 compliant EJB container.
"The document “EJB 3.0 Simplified API” provides an overview of the simplified API that is introduced
by the Enterprise JavaBeans 3.0 release.
The document “Java Persistence API” is the specification of the new API for the management of persistence
together with the full specification of the Java Persistence query language (a superset of EJB QL).
It provides the definition of the persistence API that is required to be supported under the Enterprise
JavaBeans 3.0 release as well as the definition of how the Java Persistence API is supported for use in
Java SE environments.
This document, “EJB Core Contracts and Requirements”, defines the contracts and requirements for the
use and implementation of Enterprise JavaBeans. These contracts include those for the EJB 3.0 Simplified
API, as well as for the EJB 2.1 API, which is also required to be supported in this release. The contracts
and requirements for implementations of this specification also include, by reference, those
defined in the “Java Persistence API” document [2].
"
-EJB 3.0 Specification
com.mcnz.ejb.EJSLocal0SFStatefulTimer_5d1d8f07.getStartTime() 
1218676944775 (long) 
Object contains no fields
