TheServerSide is pleased to present a new monthly column on Enterprise JavaBeans, by Richard Monson-Haefel, author of O'Reilly's Enterprise JavaBeans, 3rd ed. The first column will provide an overview of the new features in the EJB 2.1 spec, including support for Web Services, enhancements to the MDB programming model and improvements to EJB QL.
Read Monson-Haefel's Guide to Enterprise JavaBeans: What's New in EJB 2.1
Nice article - and although I just took a quick scan through it, the part about auto-pk generation got my attention. I partially agree that EJB Containers should support a strategy to allow the database to generate primary keys (and most do!), but standardization on this would be difficult given that pk generation is database specific and CMP engines or persistence managers still have some way to go before they become 'pluggable' or 'interchangeable' between J2EE servers.
In fact, the upcoming JDBC 3.0 specification alleviates the problem of pk generation to some extent by requiring drivers to support primary key generation. When drivers start supporting this spec version, it will be relatively trivial for AppServers to use this functionality (via standard SQL interfaces & methods) irrespective of the underlying database vendor.
Nice article!! I know that many people complain about EJBs, but the truth, whether you like it or not, is that the specification is gaining momentum and getting better and better. I'm utilizing EJBs for the first time (using all local interfaces, nothing distributed), and it's great! CMP is really helping us work mainly with our business objects and business logic, allowing us to ignore raw JDBC details. EJB QL is getting better. Just waiting for native DATE support! =)
How do I get at this JDBC 3.0 feature of getting at the primary key? I looked at the docs and could not find it. Please help.
If you pop over to http://java.sun.com/products/jdbc/download.html
and download the JDBC 3.0 final release spec, the section "13.6 Retrieving Auto Generated Keys" should give the information you are looking for.
Note that some JDBC drivers are already supporting this feature. One of these is our own driver for JDataStore (a 100% pure Java database).
It does seems like Entity beans are being moved more towards being just Object-Relation mapping interfaces. Personally, I wish this focus welcome, but I am wondering where this will leave CMP Entity-beans in relation to other data mapping initives like JDO.
I agree with Richard that auto-generated primary keys is a long overdue feature. The right place to adapt to different database implementations of auto-generation is in the Application Server container. IMHO the primary key generation patterns would be more aptly named "primary key generation hacks". Most notably, they address only poorly databases that will be accessed by other applications and preexisting databases that should be adopted to J2EE. In my experience this means that for most real world projects, BMP is the only real option. IMHO, BMP Entity beans are about as fun as a root-canal, except you don't get the novocaine.
Richard states that lots of vendors implement some kind of key-generation already. I hope JBoss in particular will follow this trend; it seems like this is currently a non-issue on the JBoss-CMP forum. The schemes I have encountered with database generated primary keys all follow a general template: Insert a row with a missing primary key, and use some specialized query to access the newly generated primary key. Surely, this cannot be hard to put into a template, can it?
Thanks to Richard for an excellent article. I am looking forward to the day when cronjobs will be a thing of the past!
Nitpicking, but the 'printer-friendly' version would be enhanced by placing the URL, author and copyright on the page.
Gr8 column !!
< Timer Service >
I agree with richard.
We need essentially configurable TimerEnterpriseBean(TEB).
MDB serves the same purpose.
</ Timer Service >
I would like to make some comments on Timer Service specification proposal. I agree with Richard that Timer Service should be configurable at deployment time and expanded to MDBs, but I would RESTRICT it ONLY to MDBs.
Adding capability to accept timer notifications to session and entity beans seems to me like over-complicating simple things.
My opinion is that much more elegant solution would be to allow ONLY MDBs to receive timer notifications. Why would we need session beans to receive timer notifications when MDBs can accept it and invoke any business methods on session beans ? That is what MDBs are designed for, to receive asynchronous messages and events, and then take appropriate business action by invoking business methods on other session or entity beans.
Also, entity bean receiving direct timer notification seems to me like bad design. Better would be let MDB receive timer notification and then find any entity beans that shoud be affected and invoke appropriate bussines methods on them.
What do you think ?
You're right, Mileta. Though it'd be an extra step to trigger a message driven bean that would then invoke a session bean, it's far more logical.
It think the problem with evolving specs is to find the correct balance. For obvious reasons J2EE is considered complex and therefore difficult to use. Now they try to make it easy, try to avoid developer overhead, but I fear for this one here it's an oversimplification: by trying to make it easy they make it more complex and illogical.
But anyway, a great article and nevertheless I'm sure EJB2.1 will be a good specification (at least for a maintenance release).
It seems to me that we might wish the container to manage the time to execute timers rather than executing them precisely 45 days after (to the second). One way to avoid timer storms might be to give the container the option to execute a timer anytime within a specified granularity (whether it be an hour or day), depending on the load it has. This would allow the container to distribute the load of long-term timer events into times of little stress.
Perhaps TBD (timer-driven beans)?
TBD - To Be Determined?
TDB - Timer Driven Bean?
What's the difference at this moment? ;-)
Point taken, lu. I frequently trip over my fingers while rushing on to the ultimate fallacy......
At the systemic level, I think that this is a major change to the container paradigm. Right now a container is a place to store logic and data. It is a passive facility, not an active one. You can bring up a container and as long as you don't talk to it, it won't talk to you. This is the same model that most UI toolkits use.
I always try to avoid having startup servlets and things that kick off when an app is deployed or a server starts up. Most places have enterprise-wide schedulers that they prefer to use instead.
Also, I've found over the years that alot of programmers use such a facility as a crutch to implement initialization and polling mechanisms and the like. Were such a facility available I would be dubious about allowing it's use on any of my projects.
In short, I like the passive nature of the EJB container. I like the fact that it forces you to look to the world outside the container to initiate execution of business events.
Perhaps some sort of persistent timer would fulfill the author's requirements without adding too much more complexity, but I'm still dubious.
Thanks, very informative article. I agree with most of your "important to improve" list and would like to know why you don't have more in this list, like:
1) Read only beans!
2) Read-mostly beans! (i.e. explicate cache invalidation)
3) More robust "IN" list capability in EJB-QL (literal strings only??? - who uses that?)
4) Dynamic EJB-QL queries
5) Make getters/setters compatible with the JavaBean spec (the getter/setter for "SSN" is different in the JavaBean spec then the EJB spec!)
The EJB spec does address the read-only entity bean pattern you require (albeit not explicitly) - that is what the transaction commit Option A in the EJB spec (1.1 and 2.0) defines. Refer to Section 10.5.9 in the EJB 2.0 spec for more details.
In our product, it is possible to use Option A even in a clustered environment if your beans are (a) read-only, or (b) insert-only.
Read-mostly beans can be problematic since it involves sending broadcast messages to nodes in the cluster which can get expensive. Secondly, ensuring that transaction-semantics are not violated in the cluster is trickier. I'm not saying that the read-mostly pattern should not be used, rather just saying that there are some possible limitations and/or overhead.
Thanks for a good article. The same informative style Richard shows in all his books.
Hi Richard! The EJB spec. states that an EJB should not attempt to listen on a socket as well as accept connections on a socket, or use a socket for multicast. I have already read many (different ;) interpretations of this sentence and I would like to have your clarifications on it as far as it has impacts on accessing Web services from EJBs. My understanding of the first part of the sentence is that one can write on a Socket but not read. If my interpretation is the correct one, would using the JAX-RPC library straight from an EJB not be breaking this rule, as far as JAX-RPC needs obviously to read the reply from the Web service? Should Web services not rather be accessed via a connector? Thanks for clarification.
I pretty much agree with most of Richard's article.
Particularly, I think some addition to the spec is required for deployment/server lifecycle events. Currently, different servers have different approaches to this (e.g. Weblogic's Startup Classes) and some standardisation would be welcome. Perhaps an anonymous component like TimerDrivenBean is the answer. Perhaps the addition of onDeploy() / onUnDeploy() lifecycle methods would be simpler.
My initial thoughts on the Timer Service were similar to those aired in some earlier posts here - that the timer service should just produce events that a Timer MDB would consume from. However, on further reflection, this would just lead to a lot of messy, repetative code to determine what bean needed looking up, getting the Home Interface for that bean, getting the Component interface for that bean, working out what method to invoke - and all of this before actually doing any work.
The removal of the bean lookup is a good step in my opinion.
In addition to Richard's improvement-list for EJB2.1, I would add 4 things:
1) A Non-Persistant Entity Bean.
One of the first things that caught my eye in the JDO spec was the (optional) requirement for a Transient Transactional object. The EJB container could benefit from this concept a lot.
Currently, caching of non-persistant data is very difficult in the EJB container and most solutions usually depend on the J2EE Connector or a Singleton object (where different container classloading schemes have a big impact on behaviour). Often, you may want to cache some data that you dont ever want to persist (you may not even be able to persist it). An example may be the results of some expensive computations, or it may just be that you want to cache a "view" of some data.
This would require a new Bean that had the transaction/concurrency behaviour of an entity bean but the passivation/lifecycle behaviour of a Stateful-Session Bean.
Some container implementations could then even provide distributed synchonisation across a cluster.
2) Dynamic JMS MDB Subscriptions.
The ability to modify Message Driven Bean subscriptions at run-time is a very important thing for many applications. Particularly in the case of JMS Topics, it is often unknown at deployment time, what destinations the MDB must consume from.
A particularly good example of this is an MDB consuming from a market data feed. Here, as there are so many destinations and so many messages, that it is entirely necessary to dynamically add and remove subscriptions at runtime.
I propose the addition of a Home Interface for the MDB for the purpose of setting, querying and updating destinations and message selectors. Alternatively, this could be handled by the JMS spec and the standardisation of message routing (ie destination condensers).
3) Dynamic EJBQL
While the enhancements to EJBQL are welcome, the remaining weakness of EJBQL, when compared to JDO or JDBC is the lack of an ability to mix logic with query. The sooner EJB supports this the better.
4) Cursored Collections for find<methods> and select<methods>.
Currently most finder and select method implementations load and instantiate every bean/object that the database query returns. In some cases, this may be impossible (without running out of RAM) - in others it may be far more efficient to only load a limited number at a time - and chunk the results into RAM as the Collection is iterated. While this can be handled transparently by vendor implementations in CMP2.0, it would be helpful to have programmatic knowledge of the default points. You may, for example want to abort a particular query if you are about to instantiate the whole database. You may also want to return results to the user "page at a time". This would require more than the current java.util.Set and java.util.Collection can povide.
Particularly, I think some addition to the spec is required
> for deployment/server lifecycle events.
This exists, sort of, already. You can add a servlet that implements the init()/destroy() methods to do that, along with the load-on-startup flag in web.xml. However, all servers don't implement that properly (Orion didn't the last time I checked).
Thankx for relevant infos. It was also interesting to read the replies. I think that moving towards web services is important step for EJB's. I was mostly interested in reading about Timer Service. Hope more articles like this one will come.
sorry, interested :)
I was excited to first read RMHs views about the expanded
capibilities of MDBS. He writes about "...I can also
also envision other types of message-driven beans
supporting SMTP for e-mail...". Unfortunately, this
particular vision does appear in the current draft of
I must admit that at first glance getting excited about an
NDB being an SMTP endpoint. Then discovering that "SMTP"
does not even occur as a searchable string the the
Me thinks that this might be one time for RMH as "sitting
on the board" to suggest that SMTP be one of the supported
The obvious implementation details could be a pain in
the arse, but you brought it up...
Just stirring the soup.
Everyone agrees this is a nice column.
Is there any plan to include JDO into EJB2.x and/or J2EE? What are the pros and cons of using JDO, comparing against using CMP/CMR?
A nice column.
I have one issue to be disscussed with the community.
As we all know Scheduling Service will be part of J2EE1.4.
We also have the application demanding this service.
Now we have few options:
1.We build our own framework
2.We use the readymade exisisting framwork like FLUX.
3.We wait till j2ee 1.4 becomes production ready
The JSR mentions that the J2ee1.4 will be available in the second half of 2002.(Can't we be exact here a bit).When exactly the j2ee 1.4 will be available ?
So the issue is which option to choose ? Why ?
Thanks in advance
Vimarsh P Vasavada
Popnet infotech India Ltd.(www.popnet.co.in)