References used for this summary:
- the following white papers and articles from java.sun.com/products/ejb/
- book on CORBA (for OTS):
- www.ejbhome.com
This allows:
So far each component execution system has defined its own component model, with the consequence that components could only be sold and reused for once specific brand and kind of systems, hindering and effective market for business components. With EJB, Java tries to change it. I think there are at least two points why that could be successful: the EJB only defines the interface between the component execution system and the business components, not the interface between the component execution system and the client using such a system, thus allowing different types of exeuction systems with different characteristics. This allows a much broader reuse of business components. Secondly, they might have luck that the market is ready to embrace a new standard, and that Java is strong enough to help it break through.
State, roadmap: EJBs is out, the first books have been written, the first execution systems are available and many more are to come. The finalisation of the specification as well as the implementation of a refence implementation take place throughout 1999. Certain enhancements are foreseen in phase two and three, mainly enhancing the portabilitiy of EJBs not only across different comonent execution systems, but also across different underlying databases, directory servers, transaction services (i.e. the interface between the beans and the rest of the enterprise services used by the beans).
The basic architecture is a multi-tier system, with a thin client, a component execution system in the middle tier that supports things like transactions, high-volume throughput, load-balancing, state management, multithreading, resource pooling, and other complex low-level details, and then the EJBs and whatever system the EJBs use, e.g. database systems. The client is thin, i.e. it contains no business and data access logic, just presentation logic. EJB architectures make such application easy to write because the EJB server takes care of the low-level details, and the application programming just concentrates on writing EJBs for the business logic.
Reuse model for the EJB components: EJB components are bought,
copied and installed in the company building up the overall system. CHAIMS:
the whole system composed by having one component exeuction system and
a set of Beans might offer autonomous services, but the EJB components
are not autonomous in our sense, they are very similar to the graphical
Java Beans. They brought and integrated into the target system. Reuse
of both, the component execution system and the Beans is enabled by having
the EJB interface. Moreover, because the two are disentangled, Beans can
be used within different kind of exeuction systems, thus being reused within
system in totally different domains with differing requirements.
EJBs are encapsulations. The EJB component model defines the basic
architecture of the beans, the structure of their interface (they have
to extend specific interface classes), the mechanism by which the component
interacts with the container of the component execution system and
with other beans.
Beans can be customized by the purchaser who integrates them into his
system. Customization does not touch the code, instead a bean provides
external property values that can be set by an integrator.
A component execution system for EJBs consists
of a server, the EJB server, and a container containing the EJBs,
the EJB container. It offers runtime services like:
- multi-threading, concurrency control
- persistency management, life-cycle management of beans,
- transaction management with commit, rollback, nested transactions,
- state management, security
- resource-sharing, resource pooling
These services can be split up into the services provided by the EJB
server and the onces provided by the EJB container, and, theoretically,
these could be two seperate systems.
|
|
|
| Represent data in databases and related processes, e.g. "bank account" | Represent stateful dialogs between a business server and a client |
| Implements business entity. | Implements business task. |
| is transactional | may be aware of transactions |
| One entity bean serves multiple client; shares access for multiple users | One session bean serves one client; handles database access for one client |
| survive crashes | do not survive crashes |
| always persistent, kept in persistent storage; corresponds to life of data in database | typically transient; corresponds to life of client |
Database access can be done directly from session beans, or session beans can be clients of entity beans that then access databases.