actually working with AS I got some questions.
If using hibernate as an ORMapper do one really need EJBs?
How would you set up an application in a scenario where you need to develop a webapp with database access to retrieve data and make a pdf of that? Where is the difference between a servlet solution and an EJB for the logic?
And what about if someone wants to exchange informations between two AS. Let us say to start some logic. Then one need EJBs right?
JPA, Java Persistence Api, defines a standard architecture of accessing persistent information for Java using Object semantics. It is independent of 'application servers' or ORM vendors. Using JPA, you can build pure POJO or JEE app server hosted applications.
The JEE container is JPA *compliant* and will handle some of the non-domain-specific boiler plate code that you would normally write if using JPA in a pure POJO environment. (In the EJB container, entity manager lookup and creation of a transaction and its conclusion are handled by the container, based on JPA annotations you have applied to your persistent object(s)).
If your persistent entities (JPA annotated POJOs) need to be accessed, it is irrelevant whether you are in a JEE container or not: you will need to access the entity manager for the given persistent context and use the EntityManager api to access the managed persistent entities.
Typically in JEE apps, the object responsible for above is a stateless session bean, or a servlet, that can access the EntityManager for the persistent context. Basically, a facade pattern capturing your use-case semantics in the presented API (servlet commands or EJB method calls) and then using the EM to do CRUD operations will be sufficient for the basic scenario you have outlined.
To get a feel for this, just write the most trivial persistent JPA PU -- say names and telephone numbers and bundle the whole thing in a jar file with appropriate JPA artifacts. Now, write a simple POJO class to use the above: you will need to access EM Factory, create the EM, start a transaction, do some stuff, and then commit if successful.
Now take the same JAR, deploy it, and write an JEE application to use the same entities. Your (facade) object (servlet or EJB) code will be a bit simpler than the POJO, if you use all the new annotations for transparent dependency injections (mainly the EM).
Your basic solution is a web-app that uses a stateless session bean facade to access the data captured in that persistent unit. What you do with the result from the data access facade (PDF, XML, woof) is irrelevant: the only issue is the notion of detached objects which is an ORM issue in general and has nothing to do with Java, JPA, or JEE. From your post, I think this is a non-issue for your app.
Connectivity between JEE containers is possible through a variety of means, including EJB, JMS, HTTP (servlet), or SOAP.
You may not use primitive (net) apis for direct socket connections given that such connections are not managed and are a violation of JEE spec. If you require synchronous linkage, you should not use MDBs.
Also, please note that in general, the notion of exchanging informations between two "AS" is somewhat meaningless (in the application domain context). A main point of JEE is to give you a degree of transparency regarding physical resources in your system.
If you are using the JEE semantics --i.e. coding to spec of JEE -- you generally have no notion of a specific "AS". JEE provides the 'local'/'remote' reference specification means to co-locate closely cooperating components in a given container, but that is about it.
Hope this helps.