Enterprise JavaBeans 3.1, 6th Edition

Chapter 2. Component Types

Modeling real-life objects and concepts is one of the first skills a programmer must develop. As such, we’ve become fairly adept at implementing object-oriented axioms such as reusability and extensibility on a daily basis. When we focus these principles on business logic, we end up with a set of business objects that encapsulate the rules of the road.

Starting with the 3.0 version of the Specification, EJB imposes no API coupling or restrictions upon the classes that will define our business objects. Commonly known as POJO (Plain Old Java Object)^[2] development, this means that an application developer is under no obligation to extend, implement, or have any references tying the application to EJB. Now we can create class hierarchies however we see fit, and reuse our objects in some non-EJB environment (perhaps for quick testing outside of the Container).

Because a POJO class is just like any other class, it does not become an EJB until it’s:

1. Assembled/packaged

2. Deployed

3. Accessed via the Container

This is an important distinction. EJBs become such only in the context of the EJB Container.

The Container, in turn, is responsible for equipping POJOs with EJB Services (covered in Chapter 3) as well as exposing their behavior via one of three personalities. We call these personalities component types, and while implementing their semantics is beyond scope for an application developer, it’s important to know how, by contract, they’ll behave.

We’ll use the example of ...