Doubt about Container Services

I have a doubt:
Transaction Service, Security, lifecycle managemant and remote-method invocator are services of EJB or container?

Hi!
These are services of the EJB Container. As an EJB Developer (role: Bean Supplier) you should *not* worry about such things.

Howdy -- the distinction does not matter. If the exam says, "EJB 2.0" or "the Container" or "The Container Provider" or even "The EJB Server" they all mean the same thing. So the services you mentioned could be considered to belong to any of the phrases mentioned above. The real spec DOES make a slight distinction, but that distinction no longer matters.
Originally, in the first version of EJB, they had planned to make an API between the container and the actual server, so that you could potentially buy your app server from one vendor, and plug-in a container from another vendor! But they abandoned that whole idea. So even though there is a separate role for container and server, the distinction is completely meaningless to an EJB developer.
Does that help?

cheers,
Kathy
Are you well-encapsulated? Show the world...
"... dive in, Head First"
-Scott McNealy
[ August 15, 2003: Message edited by: Kathy Sierra ]

Ok, but my other doubt is if this topics are services of "EJB Container".
I read that security is a service of "EJB Container", but Transaction, lifecycle managemant and remote-method invocator I dont know if is defined (named) as services of Container

Howdy -- maybe I don't quite understand your question, but if your question is "Are these guaranteed services of the container/EJB/server?" then the answer is YES. The EJB container is required to provide capabilities for transaction management (although not necessarily two-phase commit), lifecycle management (in other words, when and how the objects live and die on the heap), and remote method invocation (the container has to build the stubs and remote objects so that remote clients can access using normal RMI-IIOP semantics.)
These services *are* considered part of the EJB container, as opposed to the following services, which are *not* guaranteed capabilities of EJB (and you DO have to know this for the exam

):
* load balancing
* fault tolerance
* lazy loading of entities
* an actual relational database (the server is required to provide *persistence*, which IS a guarantee, but that persistence need not be a relational database. But... the server/container is also required to provide support for JDBC 2.0 API, but again, that does not mean that the server/container ships with an actual JDBC-driver-capable database.)
* failover
Does that help?
cheers,
Kathy

I dont agree Kathy.
In the book "Sun� Certified Enterprise Architect for J2EE Study Guide". there is a question that ask what is the services of EJB, and the answer is lifecycle management and remote-method invocator. The alternative transaction service not is a service of EJB (the book said).
Fernanda, do you read this book ?

For Transaction Support refer to EJB 2.0 spec @ page # 332:
Support for transactions is an essential component of the Enterprise JavaBeans architecture. The enter-prise Bean Provider and the client application programmer are not exposed to the complexity of distrib-uted
transactions. The Bean Provider can choose between using programmatic transaction demarcation in the enterprise bean code (this style is called bean-managed transaction demarcation) or declarative transaction demarcation performed automatically by the EJB Container (this style is called con-tainer-managed transaction demarcation).
For Lifecycle Management & RMI, I don't quite understand what the author mean by the EJB. These are service provided by EJB Container as dictated by EJB 2.0 spec.
Thanks.

Howdy --
Transaction support is in the EJB specification in several ways and places. Including page 332:
"Regardless whether an enterprise bean uses bean-managed or container-managed transaction demarcation, the burden of implementing transaction management is on the EJB Container and the Server Provider. The EJB Container and the Server implement the necessary low-level transaction protocols..."
And the first paragraph in section 17 of the EJB spec says:
" One of the key features of the Enterprise JavaBeans architecture is support for distributed transactions." The rest of chapter 17 is all about *how* transactions are managed in EJB, and what everybody is responsible for (i.e Bean Provider's role, Container's role, etc.)
In fact, you can't even *use* Entity beans without using Container-Managed Transactions

I don't know what Simon and Mark were thinking if that's what they said in their book... they both know that transactions are a fundamental service of EJB, and in fact one of the primary reasons for using EJB in the first place...

cheers,
Kathy