| Sign In/My Account | View Cart |
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.
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.MessageContext
from within the bean implementation.ejbCreate() method is still
needed.<service-endpoint> element has been added to ejb-jar.xml.Mandatory transaction 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.<method-intf> accepts ServiceEndPoint as a value.<method-permission>)
will require the use of the <run-as> tag.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:
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.
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.
The new EJB 2.1 timer service is a mechanism to enable time-based business logic. For example, one could want to automatically:
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 EJBContext.getTimerService(),
returning a javax.ejb.TimerService object. This object is a factory
for creating 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
with a TimerHandle (Serializable), and they can be cancelled
and reconfigured.
Only "stateless" objects (stateless session beans, pooled entity beans) can process timer events. Their bean implementations must implement the
javax.ejb.TimedObject
interface, which contains a single method: void ejbTimeout(Timer).
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 ejb-jar.xml
(this would take effect at deployment time).
Here's a list of (smaller) new features:
ejb-jar.xml standard deployment descriptor is now specified with XML schema, rather than DTD.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.
As a Java developer working on server-side technologies, I found this page very useful. It gives a brief, yet comprehensive overview of the basic enhancements in EJB 2.1. Looking forward to more such articles and also to using these technologies,
Yours sincerely,
Lakshmi Iyer