EJB3: Why are transaction semantics and statefulness considered implementation details?

Transaction semantics and state-fullness are considered implementation details in EJB3. An implementation can decide whether to use bean or container managed transactions. It can decide the type of of container managed transaction. It can decide whether it's state-full or stateless.

However, logically, these are important interface details. Examples: (a) A bean using bean managed transactions cannot invoke a bean using container managed transactions. (b) A stateless bean cannot invoke a state-full bean.

When presented with an EJB3 interface you have no idea what kind of transaction semantics it requires. Likewise you have no idea whether it's state-full or stateless. You need extra implementation details. Example: documentation.

At run time, different beans and call chains can be instantiated dynamically. So an invalid state could arise. Now开发者_JAVA技巧 - the container can trap these situations; but why wait until runtime?

Why are transaction semantics and state-fullness requirements not part of the interface?

---

Transaction semantics and state-fullness are considered implementation details in EJB3. An implementation can decide whether to use bean or container managed transactions. It can decide the type of of container managed transaction. It can decide whether it's state-full or stateless.

I understand the point of state management which is indeed important from point of view of the client.

Concerning the transactions, it's a bit more tricky.

• The type of transaction (bean-managed or container-managed) is implementation details (I'm not sure about your example (a)).
• The propagation semantics is not. (required, mandatory, none, etc.).

Now - the container can trap these situations; but why wait until runtime?

Even if all that was present with an interface, the type system would still not be sufficient to enforce the rules at compile type.

You anyway need a tool to check these constraints according to their applicative semantics. The IDE could do it if it parse the annotation, the container could do it when the module is deployed, and at worse it fails at run-time.

Why are transaction semantics and state-fullness requirements not part of the interface?

A java interface carries only a limited set of information about the correct usage of a component, be it a class, and bean, or an API. The overal contract of most component is way more complicated than what is exposed in the interface.

Examples:

• Thread-safety: how do you know if a particular class is thread-safe without looking in the doc?
• ContentHandler.characters(): how do you know that it can be called more than once per XML tag?
• And the list goes on...

I personally use the term contract to refer to complete set of constraints. The interface gives me only the signature of the methods from the point of view of the type system.

If you are interested in the topic I would suggest you look at design by contract. The idea to formalize the contract between component more precisely has been around since a long time.

So my answer would be: because even if it were, you would still need more information.