In the previous article of this series, I touched upon how EJB specification architects have enhanced the new EJB specs to meet the goals that were set out for EJB 2. In particular, I discussed the improved support for Container Managed Persistence (CMP) and the introduction of Container Managed Relationships (CMR) between entity beans, all built on the foundations provided by local bean interfaces. In this part, we will conclude the introduction to the new features and goals of EJB 2.
Goals of the EJB 2.0 Specification
The Proposed Final Draft 2 specifically lists out the goals for the 2.0 specification as:
- Define the integration of EJB with the Java Message Service (JMS)
- Provide a local client view and support for efficient, lightweight access to EJBs from local clients
- Provide improved support for the persistence of entity beans
- Provide improved support for management of relationships among entity beans
- Provide a query syntax for entity bean finder methods
- Provide support for additional methods in the home interface
- Provide for network interoperability among EJB servers.
Goal 5: Provision of a standardized query syntax for entity bean finder methods
Entity beans managed by the container usually define finder methods that allow clients to locate certain entity beans or collections of beans. Previous releases of EJB did not define a standardized syntax for defining these methods. Instead these were implemented by hand. The container generates the finder methods at runtime, though the bean provider must declare the finder specification in the deployment descriptor. The result of this was that queries to finders would have to be coded to the persistent store being used resulting in a slightly lower level of portability and adding operating environment specific finder declarations.
In order to provide a standard way of declaring finder methods, thereby increasing portability across persistent stores, EJB architects choose to specify a new, declarative, SQL-like language known as EJB QL (EJB Query Language). The use of EJB QL also allows persistent store specific optimizations since the language is compiled to the native language of the persistent store.
The abstract persistence schema and relationships of the entity bean provides the data model for the bean deployer to write queries to locate the bean. The EJB QL declarations are defined in the deployment descriptor using the
EJB QL is a highly stripped version of SQL that allows ease of migration and virtually zero learning curve.
Consider the example of a Subscriber entity bean that has other bean fields representing Preferences and it’s Address. The EJB QL declaration for a Subscriber who uses the Gold theme to view his personalized pages would look like:
SELECT OBJECT(sub) FROM Subscriber as sub IN sub.preferences AS pref WHERE pref.theme='Gold'
SQL deja vu!
The introduction of EJB QL will further standardize the EJB platform resulting in increased portability and provides scope of optimization of queries to the persistence store being used.
Goal 6: Provide support for additional methods in the home interface
EJB 2 allows both local and remote client views for the Home interface. The specifications of EJB 2 have been updated to support the new home interface methods for local client views.
Goal 7: Provide for network interoperability among EJB servers
There is an ever-increasing need for server side components to be accessed across a heterogeneous network environment. For example, it should be possible for an EJB to be deployed in a Container to access other EJBs from a Container from another vendor. A CORBA object should also be able to access EJB services deployed in a Container. A stand-alone application resident on the network should also be able to access EJB services. This is precisely the requirement for interoperability.
Multiple EJB containers must have a standard means and protocol for communicating with other containers. This will ensure that every EJB 2 compliant container will be able to speak with containers from other vendors. EJB 2 uses the CORBA/IIOP standards as the means by which containers communicate with each other and access EJBs. Using CORBA/IIOP automatically enables CORBA compliant applications and components to access EJB services.
The introduction of a standard communication protocol for EJB opens up a whole new world of distributed computing with multiple, heterogeneous EJB containers, CORBA compliant applications and other network enabled component applications. Now your server environment can consist of various mix and match containers running on multiple machines each accessing and rendering services for each other. This is the essence of distributed component computing.
The EJB 2 specifications have addressed many short falls of previous releases and is more tightly integrated, more portable, more efficient and more standardized. Integration support with other commonly found enterprise applications has been improved upon and new technologies have been supported. But this is not the end of the road for EJB. There are still more features planned and still more evolution to the specifications shall we see (that’s Yoda inspired). In particular, architects have listed the following new features to be expected in future revisions of the specifications.
- Support for method interceptors
- Support for component level inheritance
- Read-only entity beans with CMP
- Aggregate operations for EJB QL queries
- Support for other types of messaging in addition to JMS
- Specifications for pluggability of Persistence stores.
Summary and Conclusion
EJB 2 has made significant strides towards becoming a complete, enterprise friendly, feature rich, practical technology to implement server components. In conjunction with tighter integration with J2EE and EJB containers it seems like the dream of component-based enterprise distributed computing has finally arrived. Other technologies tried but the maturity, elegant simplicity, interoperability, scope and standards-based approach of EJB 2 makes it the best and virtually only server component technology that will succeed.
About the Author
Apu Shah is the CTO of FreeOS Technologies, a leading provider of software solutions based on open source and free operating systems such as Linux.