What's New in EJB 2.1?
Pages: 1, 2
One of the best features of EJB 2.1 is the support for Web services. This applies to two different areas: accessing an EJB as if it were a Web service, and an EJB directly accessing a Web service.
EJB As Web Service
A stateless session EJB can now be accessed through a Web service. In order to do that, the client must use SOAP over HTTP or HTTPS, and use a WSDL descriptor. Furthermore, the stateless session bean must be invoked "RPC-style." To help with the development of Web-service-enabled beans, the specification was changed in these ways:
SessionContext.getMessageContext()was added, to get a
javax.xml.rpc.handler.MessageContextfrom within the bean implementation.
- The container is now required to provide a tool that can produce Web service facades in front of stateless session beans (called "Web Service endpoint interface implementation class").
- The home interface is now optional, while the
ejbCreate()method is still needed.
- The specification stipulates that for each stateless session bean, a WSDL file must be provided, and its interfaces must match the bean's methods. This WSDL file can be generated by the container.
- A new
<service-endpoint>element has been added to
Mandatorytransaction attribute is not accepted for stateless-session-bean Web services. This is understandable, because transactions cannot be propagated from the client to the bean, as in RMI invocations.
ServiceEndPointas a value.
- Exceptions are transformed into SOAP faults. Note that the server has no control over the client's transactions, so it cannot roll them back if a system exception happens.
- There doesn't seem to be any special note regarding security. But the credentials cannot be sent from the client to the bean the way RMI does, so I suspect that the usage of declarative security (using
<method-permission>) will require the use of the
Forcing the use of HTTP is somewhat restrictive, since Web services are supposed to accept any protocol and technology, but this follows the general trend. By spelling out these restrictions, though, I think we will get into the same trap as JMS-only message-driven beans. The specification will later have to change to accommodate more standards.
Many people have pointed out the disconnection between what exists in the Web service realm and what is available in EJBs. Here are a few examples:
- How can the client's identity be propagated to the EJB? How can one set permissions?
- How can the client demarcate transactions?
- How can the client perform connection-based services (stateful session) or obtain data (entity)?
While these things are not addressed in the specification, they are not addressed in SOAP, either. There are programmatic solutions around those limitations, and it will be up to the container providers and/or bean developers to invent these solutions.
EJB Accessing a Web Service
An EJB can directly access a Web service, simply as a regular Web service client does. But this means the Web service's location has to be hard-coded
in the bean implementation's code. This is not ideal, because if the Web
service moves to a new location, the EJB must be modified and recompiled.
To work around this problem, the new EJB 2.1 specification introduces
the concept of a Web service reference. This is exactly the same concept
as environment entries, EJB references, and resource references.
Adding a Web service reference in
ejb-jar.xml is done using
the new tag
<service-ref>. It is up to the container provider
to map the reference to the actual Web service location. The reference
can be looked up in the bean implementation, and the resulting factory
object can be used to connect to the Web service.
EJB Timer Service
The new EJB 2.1 timer service is a mechanism to enable time-based business logic. For example, one could want to automatically:
- Run a certain query in five minutes.
- Delete the content of the "garbage can" database table one hour from now, and then every two hours.
- Post an email saying "server shutdown in 1 hour" to all employees next Saturday at 11 pm.
- Send a usage report to the administrator every Monday at 8 am.
Note that this timer service is not meant to be used in real-time systems. Notifications will be sent at approximate times.
To set up a timer object, use the method
javax.ejb.TimerService object. This object is a factory
javax.ejb.Timer objects. Once such an object is created,
the container will take care of calling the bean at the right time. Timer
objects can later be retrieved using the
TimerService object or
Serializable), and they can be cancelled
Only "stateless" objects (stateless session beans, pooled entity beans) can process timer events. Their bean implementations must implement the
interface, which contains a single method:
Also, the security identity during the timer call can be specified using
<run-as>; othrwise, permissions cannot be verified.
Lastly, it is not clear how the EJB container provider will know which
bean is linked to which timer. Timer creation methods do not have parameters
to specify which bean would consume the
ejbTimeout events. Plus it would
be nice to have the choice of setting up timers declaratively in
(this would take effect at deployment time).
Other New Features
Here's a list of (smaller) new features:
- EJB containers must now support the newest specifications: J2SE 1.4, JMS 1.1, JavaMain 1.3, JAF 1.0, JAXP 1.2, JAXR 1.0, and JAX-RPC 1.0.
ejb-jar.xmlstandard deployment descriptor is now specified with XML schema, rather than DTD.
- Message destinations (the same idea as EJB references, resource references, etc.) have been added.
You would like to see a feature in the next EJB specification? You think you saw a flaw, a typo, or any kind of mistake? You can influence the future of EJBs. Visit www.jcp.org (Java Community Process) and register as an Expert for free. You will then be able to contribute your ideas.
Emmanuel Proulx is an expert in J2EE and Enterprise JavaBeans, and is a certified WebLogic Server 7.0 engineer. He works in the fields of telecommunications and web development.
Return to ONJava.com.