bsdwork: POJOs In Action is at http://www.manning.com/crichardson/ and you can download the source code from that page. If you open the zip file of source code at the link you can see the chapter 10 source code for ejb3.
Commercially in my day job I work with Spring run inside of websphere6 stateless session beans and Spring run in the webapplication running in websphere6. Make a pojo facade managed by Spring as per the POJOs In Action book then make an EJB stateless session bean that implements the interface. Then in the implementation of the EJB just programmatically start up a spring bean factory and get the bean that is the pojo facade and invoke its methods. The EJB is then just a very thin wrapper. Use the spring websphere transaction manager support to enlist in any ongoing container managed transactions (e.g. JMS messages might be sent under the same distributed transaction). The advantage of using spring to manage the transactions is that you can write junit tests that test database rollbacks that you can run in your IDE or on cruise control without having to start up a websphere container (which is just too slow for a JUnit test). Waiting to cycle websphere 6 in RAD slows you down to the point where you just cannot be productive. Last month I had to refactor another teams code that could not run outside of Websphere/RAD and my productivity dropped to about half as I spent hours during the day waiting for Websphere to restart. My teams code runs in either Websphere/RAD or Jetty due to the magic of Spring or in JUnit and we are massively more productive as we watch unit tests run in seconds so we run them constantly and we watch our webapp come up in tens of seconds not tens of minutes.
Do you need a EJB between your webapp and your data access code as recommended at the turn of the century? No not really. We did that and are now refactoring to just go from the webapp to the data access code. As we wired it all together with Spring the refactor is fairly easy. Spring encourages clear seperation of concerns, coding to interfaces, and wiring things together by external configuration such that one component knows nothing about another component other than its interface. No brittle or rigid code to glue it all together. It embodies best practice and supports best practice. Leave in EJBs to do messaging and other "talk to another server" work but use Spring simple session bean extractor to inject them into your normal POJO service classes.
Entity beans are another matter. The book makes a very good justification for not using them and to stick with either Hibernate or JDO. Commercially with Websphere+Spring I have seen Spring HibernateTemplate support used for persistence and Springs JDBCTemplates calling oracle procs (the 'transaction script pattern'). Both of them are well covered in the book POJOs In Action. I have not worked anywhere that was particularly keen to try EJB2 entity beans more than once. I have never interviewed a good candidate who would ever want to use them again or had not been told to avoid them by someone who's opinion they trusted. The domain model pattern with a good ORM framework as recommended in the book is simply easer to use and get a result that you can maintain and refactor as your application evolves.
A full J2EE container is useful because of JMS and its industrial strength transaction manager but it's just easier to wire things all together with Spring and have it manage the transactions using Spring's proxy interceptors such that you can JUnit test out of the heavy container (e.g. on a linux workstation acting as a build box). Spring forces you to code to interfaces which makes you actually do layering, encapsulation and seperation of concerns. Occasionally EJB-RMI and JMS are the right tool for the job so it is good to know how to run Spring within a full J2EE container that provides them. Big financial firms don't let you pick any old container for a given project - they have engineering support teams and support contracts for one particular leading container. It is a good idea to use Spring to keep your skills portable between those containers as Spring has great glue utilities for all of the main containers.
J2EE has a load of good tools but for most jobs it is just better to focus on your domain model and try to avoid throwing too much "heavy API" at the problem. I once interviewed a guy who said "yes we used webservices but I think it was just because the architect wanted to put it on his CV" - I truly think that there is a lot of that going around - guys writing articles about using X or Y API in order to bump their day rates rather than to tell the world about something that is really a good idea to use. Spring is worth telling the world about as it really is a good idea to use it.