Note that the EJB specification does not detail how an application server provides persistence (a task delegated to the JPA specification), but instead details how business logic can easily integrate with the persistence services offered by the application server.
This is because the original specification allowed only for remote method invocation through CORBA (and optionally other protocols), even though the large majority of business applications actually do not require this distributed computing functionality.
The EJB 2.0 specification addressed this concern by adding the concept of local interfaces which could be called directly without performance penalties by applications that were not distributed over multiple servers.
EJB 3.0 shows an influence from Spring in its use of plain Java objects, and its support for dependency injection to simplify configuration and integration of heterogeneous systems.
Gavin King, the creator of Hibernate, participated in the EJB 3.0 process and is an outspoken advocate of the technology.
Many features originally in Hibernate were incorporated in the Java Persistence API, the replacement for entity beans in EJB 3.0.
The EJB 3.0 specification relies heavily on the use of annotations (a feature added to the Java language with its 5.0 release) and convention over configuration to enable a much less verbose coding style.
[citation needed] The following shows a basic example of what an EJB looks like in code: The above defines a service class for persisting a Customer object (via O/R mapping).
The EJB takes care of managing the persistence context and the addCustomer() method is transactional and thread-safe by default.
[8] If concurrent access to a single bean is attempted, the container simply routes each request to a different instance.
The lack of overhead to maintain a conversation with the calling client makes them less resource-intensive than stateful beans.
Additionally, Singleton Session Beans can explicitly request to be instantiated when the EJB container starts up, using the @Startup annotation.
This proxy is needed in order to give the EJB container the opportunity to transparently provide cross-cutting (AOP-like) services to a bean like transactions, security, interceptions, injections, and remoting.
When the bean method returns, the proxy ends the transaction (i.e. by committing it or doing a rollback) and transfers control back to the client.
This behavior may be declaratively tuned by the bean via annotations and if needed such configuration can later be overridden in the deployment descriptor.
The following variations are supported:[23][24] Alternatively, the bean can also declare via an annotation that it wants to handle transactions programmatically via the JTA API.
This alternative can be used in cases where injection is not available, such as in non-managed code or standalone remote Java SE clients, or when it's necessary to programmatically determine which bean to obtain.
E.g. code running in the same module as the CustomerService bean (as given by the example shown earlier in this article) could use the following code to obtain a (local) reference to it: For communication with a client that's written in the Java programming language a session bean can expose a remote-view via an interface annotated with @Remote.
[29] This allows those beans to be called from clients in other JVMs which may be running on other systems (from the point of view of the EJB container, any code in another JVM is remote).
Stateless and Singleton session beans may also expose a "web service client view" for remote communication via WSDL and SOAP or plain XML.
[33] To support JAX-WS, the session bean is annotated with @WebService, and methods that are to be exposed remotely with @WebMethod.
Additionally, web service based communication can be used by Java clients to circumvent the arcane and ill-defined requirements for the so-called "client-libraries"; a set of jar files that a Java client must have on its class-path in order to communicate with the remote EJB server.
An EJB platform vendor generally provided their own tools that would read this deployment descriptor, and possibly generated a set of classes that would implement the now deprecated Home and Remote interfaces.
Enterprise JavaBeans 3.2 was a relatively minor release that mainly contained specification clarifications and lifted some restrictions that were imposed by the spec but over time appeared to serve no real purpose.