PreDestroy annotation in SCBCD 5.0

@PreDestroy as the name suggests is called when the container wants to get rid of the instance and wants to notify the bean that it is doing so. PreDestroy can be called in the method ready state.

In the case of a stateless session bean -
- if the processing has got completed and it is no longer required.

If its a stateful session bean then -
@PreDestroy happens as soon as the @Remove method gets completed.

APIs that all EJB 3.0 containers must make available to developers

• Java 2 Platform, Standard Edition v5 (J2SE) APIs, which include the following APIs:

  • JDBC

    The EJB container must include the JDBC 3.0 extension and provide its functionality to the enterprise bean instances, with the exception of the low-level XA and connection pooling interfaces. These low-level interfaces are intended for integration of a JDBC driver with an application server, not for direct use by enterprise beans.

  • RMI-IIOP

    An enterprise bean's remote business interfaces and/or remote home and remote interfaces are remote interfaces for Java RMI. The container must ensure the semantics for passing arguments conforms to Java RMI-IIOP. Non-remote objects must be passed by value.

    Specifically, the EJB container is not allowed to pass non-remote objects by reference on inter-EJB invocations when the calling and called enterprise beans are collocated in the same JVM. Doing so could result in the multiple beans sharing the state of a Java object, which would break the enterprise bean's semantics. Any local optimizations of remote interface calls must ensure the semantics for passing arguments conforms to Java RMI-IIOP.

    An enterprise bean's local business interfaces and/or local home and local interfaces are local Java interfaces. The caller and callee enterprise beans that make use of these local interfaces are typically collocated in the same JVM. The EJB container must ensure the semantics for passing arguments across these interfaces conforms to the standard argument passing semantics of the Java programming language.

  • JNDI

    At the minimum, the EJB container must provide a JNDI API name space to the enterprise bean instances. The EJB container must make the name space available to an instance when the instance invokes the javax.naming.InitialContext default (no-arg) constructor.

    The EJB container must make available at least the following objects in the name space:

    • The business interfaces of other enterprise beans.

    • The resource factories used by the enterprise beans.

    • The entity managers and entity manager factories used by the enterprise beans.

    • The web service interfaces used by the enterprise beans.

    • The home interfaces of other enterprise beans.

    • ORB objects

    • UserTransaction objects

    • EJBContext objects

    • TimerService objects

  • JAXP

  • Java IDL

• EJB 3.0 APIs, including the Java Persistence API

  The container must implement the semantics of the metadata annotations that are supported by EJB 3.0

  The container must implement (or provide through a third-party implementation) the javax.persistence interfaces and metadata annotations.

• JTA 1.1, the UserTransaction interface only

  The EJB container must include the JTA 1.1 extension, and it must provide the javax.transaction.UserTransaction interface to enterprise beans with bean-managed transaction demarcation through the javax.ejb.EJBContext interface, and also in JNDI under the name java:comp/UserTransaction, in the cases required by the EJB specification.

• JMS 1.1

  The EJB container must include the JMS 1.1 extension and provide its functionality to the enterprise bean instances, with the exception of the low-level interfaces that are intended for integration of a JMS provider with an application server, not for direct use by enterprise beans.

• JavaMail 1.4, sending mail only

• JAF 1.1

• JAXP 1.2

• JAXR 1.0

• JAX-RPC 1.1

• JAX-WS 2.0

• JAXB 2.0

• SAAJ 1.3

• Connector 1.5

• Web Services 1.2

• Web Services Metadata 2.0

• Common Annotations 1.0

• StAX 1.0

SCBCD 5.0 Tips

It's for those who already have knowledge of EJB 2.0 or 2.1

Read first..... Enterprise Java Beans by Oreilly publications. Too good book.

Then read sun's specifications.. Yes I mean it.. How much time it would take.. total you'll have to read around 1000 pages but its worth.

I tell you.... you will get the same code with some words shuffled here and there.. from the specs in your exam. Read it carefully. Try to understand.

But don't read EJB QL from specs. I don't like the way it's explained. Instead go for Oreilly's book.

Then again make one repetition of Enterprise Java Beans by Oreilly... publications.
And finally one more times the specs.

finally Done....

Then start solving JavaBeat SCBCD 5.0 mocks.... You'll score well in the mock exams I'm sure..

What I've experienced in the SCBCD is you'll get some design based questions on JPA. They will ask you to design certain things.. and what's going to be your approach, or what you'll do in this etc.


Since JPA is new.. I would recommend Enterprise Java Beans by Oreilly... publications. You'll get code samples, descriptors for each annotations.. that's what you need.

And JNDI ENC, Transactions, Exceptions, it's really good in Specs as well as in the same book.

See on the day of exam just make a revision of those code samples from Enterprise Java Beans by Oreilly... publications.

If you do this much you are done..

Guaranteed to get the certification.

And for those who don't know EJBs and want to start preparing for it.. I would recommend read Head First EJB (The best book on EJB)

Getting Started with EJB 3.0 and Enterprise Bean Components

Although the EJB 3.0 specification has yet to be released, it is already generating much interest in the software development community by both proponents and opponents alike. All recognize the need to find more productive methods for developing software; the debate centers on whether, and to what extent, EJB 3.0 will play a role in this new landscape.
Debate notwithstanding, the release of the EJB 3.0 public draft and preliminary support in JBoss mean that now is a great time to explore this influential technology. In fact, reports of the use of EJB 3.0 in production systems are already emerging.

This article is the first in a three-part series exploring EJB 3.0 as defined in the public draft. Each article will introduce you to particular concepts from the specification and will walk you through the implementation of these techniques using JBoss. This first article will introduce EJB 3.0 and the basics of Enterprise Bean Components.Read Full Article>>

Simplifying EJB Development with EJB 3.0

Enterprise JavaBeans (EJB) has been criticized by many developers for its complexity. EJB 3.0, being worked under JSR-220 of the Java Community Process, is designed to simplify development of applications and standardize the persistence API for the Java platform.

In this article, I will explain how EJB 3.0, a full implementation of which is available in Oracle Application Server EJB 3.0 Preview, simplifies the programming model for EJB and defines a simple API for persistence.

Complexities with EJB 2.x

The current EJB 2.x model is overly complex for a variety of reasons:

• The current EJB model requires you to create several component interfaces and implement several unnecessary callback methods.
• The component interfaces require implementation of EJBObject or EJBLocalObject and handling of many unnecessary exceptions.
• The EJB deployment descriptor is complex and error prone.
• The container-managed persistence, being based on the EJB model, is overly complex to develop and manage. Several basic features are missing--such as a standard way to define a primary key using a database sequence. The EJBQL syntax is very limited.
• EJB components are not truly object-oriented, as they have restrictions for using inheritance and polymorphism.
• Developers cannot test EJB modules outside an EJB container and debugging an EJB inside the container is a nightmare.
• Looking up and invoking an EJB is a complex task. Detailed knowledge of JNDI is required for even the most basic use of an EJB in your application.

Simplifying Developers view

If you’ve ever developed an EJB with the current spec, you probably realize how difficult it is develop a simple EJB such as HelloWorld EJB. Even for this simple task, you need at least two interfaces: a bean class and a deployment descriptor. IDEs such as Oracle JDeveloper and utilities like XDoclet simplify these mundane tasks; however, it is still the responsibility of developers to compile these classes and package the deployment descriptor before the EJB can be deployed in the container of choice.

EJB 3.0 is designed to address the complexities of the current EJB model by:

• Removing need for unnecessary interfaces and implementation of callback methods
• Using metadata annotations instead of deployment descriptors
• Using regular Java classes as EJBs and regular business interfaces for EJBs

Read Full Article>>

Migrating from EJB 2.x to EJB 3.0

The EJB 3.0 specification makes programming much simpler. It makes the container do more work and the developers do less work. It decreases the number of programming artifacts for developers to provide, eliminates the requirement to implement ejb callback methods, and reduces the complexity of the entity bean programming model. EJB 3.0 should attract a larger developer community with this new programming model.

The EJB 3.0 specification provides the following advantages:

1. Fewer number of classes and interfaces
2. POJO/POJI-based components
3. Deployment descriptors are optional
4. JNDI lookups are no longer necessary
5. Persistence API for lightweight persistence for OR mapping
6. Interceptors

This article discusses possible migration strategies for moving applications written using EJB 2.x or earlier versions to the new EJB 3.0 programming model. With this in mind, this article discusses the changes in the new specification in the context of each of the different bean types. Also, this article is not very exhaustive in illustrating the migration options. Read Full Article>>

Packaging EJB 3.0 Applications

The real success of Java EE applications lies in assembly and deployment, as this is the key to delivering on Java's promise of write once, run anywhere (WORA). If you fail to fully grasp this step, your application may not realize this level of portability.

A typical application has a handful of Java classes, and maintenance can be a nightmare if you are shipping your applications from one environment to another. To simplify maintenance you can create a Java archive (JAR) file. Typically, a JAR file is a file in zip format that contains classes. However, enterprise Java applications are packaged as specialized versions of JAR files—EAR, WAR, and EJB-JAR modules—before they can be deployed to a Java EE.compliant application server.

In this article we begin with a discussion of application packaging and deployment. The article also provides critical information on class loading, so that you can appreciate why the archives are packaged as they are. This is intended to provide you a better understanding of the packaging requirements for EJB that include entities. We explain the need for deployment descriptors, and look at how to use them. Finally, we look at a persistence unit and how to per form object-relational (O/R) mapping using XML. Read Full Article>>