Just amazing what can be found in borring JCP document. All this story started once I decided to do some research regarding EJB 3.1 specification.
I will print only a few sentences from JSR-318 and will add some thought and comments about only one tiny part of it, just what is related with Embedded EJB container.
Enterprise JavaBeansTM 3.1 and what is said about Embedded Container.
Embeddable usage allows client code and its corresponding EJB 3.1 to run within the same JVM and class loader. This provides better support for testing, offline processing (e.g. batch), and the use of the EJB programming model in desktop applications.
The client uses a spec-defined bootstrapping API to start the container and identify the set of enterprise bean components for execution. The embeddable EJB container provides a managed environment with support for the same basic services that exist within a Java EE runtime : injection, access to a component environment, container-managed transactions, etc. In general, enterprise bean components are unaware of the kind of managed environment in which they are running. This allows maximum reusability of enterprise components across a wide range of testing and deployment scenarios without significant rework.
My comments and thoughts.
What makes me happy, this is an ability to have an EJB in desktop applications or regular java web application packaged as war and running in tomcat or other servlet container. Idea of having an EJB in tomcat is not absolutely new, OpenEJB does exactly that, but to be used in desktop application, for me it's a mind blowing idea. I like it very much.
Most of the people are using spring for their desktop applications and it helps a lot. Everyone knows that there are more frameworks following dependency injection pattern such as google-guice, pico container and others. Some of them have better performance, others are easier to use, but all, all of them without exceptions makes you dependent on them, you can not throw them out or replace by something more suitable later, or remove from runtime. Yes application is always dependent on execution environment and in this case dependent on spring or some other DI or EJB container. The point is an EJB container is a specification and it can be replaced by another more suitable for current task or environment, but spring can be replaced only by a newer version of spring.
What is most amazing, even full blown EJB containers such as Glassfish already are close to or almost at the same level of performance as spring framework and is easier to write and configure. Feel shocked, trust me or read these blog posts.
And here are some other interesting blog posts, for example I will list a few of them with some comments:
* Simplest possible EJB 3.1 shows what effort it takes to write an EJB 3.1 compliant bean, no xml, no interfaces, nothing what you ever could call boilerplate code.
* Some interesting thoughts about EJB vs POJO.
* EJB vs POJO performance
* EJB3 memory consumption.
And now the last thoughts. Everyone knows that spring framework is going to become application server, scary, yeah that's right a Java EE Application Server. Don't you think that spring has no option anymore, EJB's already becoming more effective in some cases and it's not a vendor lock in. Only option for spring is to become another option in list of options. What irony I see, is that spring lost his enemy, spring always was an opposition to EE, and now it becomes an EE by himself. That automatically makes it less appealing choice for new projects.
Have fun feature are bright
Regards Remigijus Bauzys
Subscribe to:
Post Comments (Atom)
6 comments:
You cannot be more wrong. Spring as DI is just a jar, nothing more.It cannot become EE it just a library! True that SpringSource has its own application server (dmServer) which not in any sense is compatible with EE specification its BASED od spring di (core) library and osgi implementation equinox.
My advice for the future , please read documentation before do wronge statements.
Spring has grown, it's not a little DI framework and never will be it again. Weapon they used before is not valid anymore. Point to switch to spring always was, easier more agile development, better productivity easy testing and lighter container if you needed one.
Reevaluate all or some of these point today. What you will be left with?
Spring had, they had no choice but to add annotation support to improve mess in XML configurations.
I well aware about what and how they a going to do in next version, but does that change my point. Their initial arguments not very valid anymore.
They did a great job and I do respect them very mach because of that. What is most amazing they managed to change even frozen Java EE vendor's market.
On another side JCP reacted extremely positive and came up with amazing improvements.
Sounds more like a de-facto standard is becomming a real standard
On another side JCP reacted extremely positive and came up with amazing improvements.
YMMV.
You mention embedding OpenEJB in Tomcat (thanks!). Not surprisingly the embeddable EJB container functionality in EJB 3.1 comes straight from OpenEJB as well.
Here's a three part series on TheServerSide from 2004 with some good content of the vision behind an embeddable EJB container. We've got a ton of current examples on our website. All of them run an embedded container.
Nice post. J.A.
Post a Comment