Making sense of JPA and EJB3 and WebServices

I'm just getting started with JPA, creating stateless session beans from the JPA entities, then accessing the beans through a web service. While I have a lot of experience developing database backed web services "the old way", I have some questions about what's going on behind the scenes with this new "annotation driven approach".

What I see is, NetBeans sort of directs you to build applications in this manner though their wizards.

1. Create an Enterprise Application with EJB and Web Application modules.
2. Create Entity classes. I created mine from an existing database.
3. Create session beans from the entity class.
4. Create Web services from the session bean.

It all looks pretty simple, but what's going on behind the scenes? Specifically:

1. I see that the web service (created with the @WebService annotation) references my stateless session bean (using the @EJB reference).
   • What happens here? Does it just grab an instance of the EJB from the application server's EJB pool?

     Nevermind. I was thinking of an instance where there was more than 1 table - meaning more than 1 type of Entity class and more than 1 type of EJB. I was looking at the web service and just seeing the @EJB reference and didn't understand who it was getting the bean type from that annotation. Just below that however, it the reference to the local bean interface - so that's that.

   • If there is more than 1 type of EJB deployed to the server, how does it know which one to grab?
2. The EJB is defined via the @Stateless and @Local annotations. The bean implementation references an EnityManager via the @PersistenceContext annotation.
   • Where is the jndi lookup to the database done (maybe in the persistence.xml file)?
   • Do all of the EJBs share a common EntityManager (assuming the Entity开发者_如何转开发Manager is thread safe)? If not, I know that the EnityManager utilizes a second level cache to help reduce trips to the database, are these caches somehow kept in sync?

I know this is a lot of questions, but they're all sort of related and there seem to be a lot of complicated concepts for something that's so easy to build through the wizards. I want to make sure I understand what's all going on here.

Thanks in advance!

What happens here? Does it just grab an instance of the EJB from the application server's EJB pool?

A JAX-WS web component endpoint (as opposed to a JAX-WS EJB endpoint) follows the typical servlet threading model, which means that typically there is one instance that is executed concurrently for each client. JAX-WS implementations are free to leverage pools of bean instances to handle a request in a fashion similar to stateless session EJB components. (source: Developing Applications for the Java^_TM EE Platform FJ-310).

In all cases, it is fine to inject/look-up stateless beans because the container guarantees that the beans will always be thread safe. In affect, the container automatically serializes clients calls but uses instance pooling to make sure you still get concurrency benefits.

If there is more than 1 EJB deployed to the server, how does it know which one to grab?

Hmm... I didn't get this one. Can you clarify what you mean exactly? Why would there be any ambiguity?

Where is the jndi lookup to the database done (maybe in the persistence.xml file)?

In a Java EE environment, you specify your data source in a <jta-data-source> element in each persistence unit of the persistence.xml file (which can contain several persistence units) and the data source will be obtained by the EntityManager (only when needed, i.e. only if a data access is really needed).

Do all of the EJBs share a common EntityManager?

No. The EntityManager is a non-thread-safe object that should be used once, for a single business process, a single unit of work, and then discarded. In a Java EE environment using EJB 3, the default pattern is "entitymanager-per-request". A request from the client is send to the EJB 3 persistence layer, a new EntityManager is opened, and all database operations are executed in this unit of work. Once the work has been completed (and the response for the client has been prepared), the persistence context is flushed and closed, as well as the entity manager object. (source: Chapter 4. Transactions and Concurrency).