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>>

Developing Web Services Using EJB 3.0

The specification Web Services for Java EE, JSR 109 defines two ways of implementing a web service. One way is based on the Java class programming model -- the web service is implemented by a Java class that runs in a web container. The other way is based on the Enterprise JavaBeans (EJB) programming model -- the web service is implemented as a stateless session bean that runs in an EJB container. A previous Tech Tip, Developing Web Services Using JAX-WS, described how to develop a web service using the Java class programming model and Java API for XML Web Services (JAX-WS) 2.0, JSR 224. In the following tip, you'll learn how to develop a web service using JAX-WS and the EJB programming model. In particular, you'll learn how to use an EJB 3.0 stateless session bean to implement a Calculator service -- the same Calculator service that was covered in the previous Tech Tip.

A sample package accompanies this tip. It demonstrates a standalone Java client accessing the EJB 3.0-based Calculator service. The example uses an open source reference implementation of Java EE 5 called GlassFish. You can download GlassFish from the GlassFish Community Downloads page.

Writing the EJB 3.0 Stateless Session Bean Class

Let's start by creating the stateless session bean for the service. One of the significant improvements in the Java EE 5 platform is a much simpler EJB programming model as defined in the Enterprise JavaBeans 3.0 Specification, JSR-220. One of the simplifications is that a bean implementation class is no longer required to implement the javax.ejb.SessionBean or javax.ejb.EntityBean interface. You can declare a class a session bean or entity bean simply by annotating it. For example, you can declare a class a stateless session bean by annotating it with the @Stateless annotation.

EJB 3.0 does specify additional rules for the bean implementation class:

• It must be declared public and must have a default constructor that doesn't take any arguments.
• It must not be final or abstract and must be a top-level class.
• It must not define a finalize() method.

Another simplification in EJB 3.0 is that a component interface or home interface is no longer required for a session bean. The one interface a session bean needs is a business interface that defines the business methods for the bean. Unlike business methods in a component interface, the business methods in a business interface are not required to throw java.remote.RemoteException. However the business methods can define throws clauses for arbitrary application exceptions. The EJB 3.0 business methods should not be static and final.

Given these simplifications and rules, here is a stateless session bean for the Calculator class that conforms to the EJB 3.0 programming model (you can find the source code for the Calculator class in the endpoint directory of the installed sample package):

package endpoint; import javax.ejb.Stateless; @Stateless public class Calculator { public Calculator() {} public int add(int i, int j) { int k = i +j ; System.out.println(i + "+" + j +" = " + k); return k; } }

Because the EJB 3.0 bean doesn't need to implement the javax.ejb.SessionBean interface, it no longer needs to include unimplemented lifecycle methods such as ejbActivate and ejbPassivate. This results in a much simpler and cleaner class. Various annotations defined in EJB 3.0 reduce the burden on developers and deployers by reducing or eliminating the need to write a deployment descriptor for the component.

Marking the EJB 3.0 Bean as a Web Service

To mark a bean as a web service simply annotate the class with the @WebService annotation. This is an annotation type defined in the javax.jws.WebService package, and is specified in Web Services Metadata for the Java Platform, JSR 181. Here is the code for Calculator class marked as a web service:

package endpoint; import javax.ejb.Stateless; import javax.jws.WebService; @Stateless @WebService public class Calculator { public Calculator() {} public int add(int i, int j) { int k = i +j ; System.out.println(i + "+" + j +" = " + k); return k; } }

Marking a Java class with a @WebService annotation makes it a service implementation class. Note that you don't have to implement a service endpoint interface. According to the JSR 109, you only need to provide a javax.jws.WebService-annotated service implementation bean. Deployment tools can then be used to generate a service endpoint interface, as well as a WSDL document, using JAX-WS rules for Java WSDL mapping.

Packaging the Web Service

A web service based on the EJB programming model needs to be packaged as a JAR file. Using the @WebService annotation, you only need to package the service implementation bean class (with its dependent classes, if any) and the service endpoint interface class (if explicitly provided). Additionally, the @Stateless annotation frees you from packaging ejb-jar.xml. By comparison, in the JAX-RPC style of packaging web services based on EJB 2.0 or earlier, you were responsible for providing the service endpoint interface class, the service implementation bean class (and dependent classes), generated portable artifacts, the JAX-RPC mapping file, and a web services deployment descriptor (webservices.xml and ejb-jar.xml).

With JSR 224, JSR 109, JSR 181 and JSR 220, an application server deployment tool can generate all the necessary artifacts such as a deployment descriptor (if not explicitly provided by the user) for deploying the web service. These artifacts, bundled in the EJB JAR file, are deployed in an EJB container. A deployer can choose to overwrite values specified by the @WebService and @Stateless annotations by explicitly providing any of the previously-mentioned artifacts and packaging them in the EJB module at the time of deployment. For this tip, the following files are packaged in the EJB module to be deployed:

  endpoint/Calculator.class
endpoint/jaxws/Add.class
endpoint/jaxws/AddResponse.class

The rest of the deployment artifacts are generated by the application server (in this case, GlassFish).

Writing the Client

After you deploy the web service, you can access it from a client program. A client uses a @WebServiceRef annotation to declare a reference to an EJB 3.0-based web service. The @WebServiceRef annotation is in the javax.xml.ws package, and is specified in JAX-WS 2.0 Web Services Metadata for the Java Platform, JSR 181. If you examine the source code JAXWSClient, the client program used in this tip (you can find the source code for JAXWSClient in the client directory of the installed sample package), you'll notice the following:

   @WebServiceRef(wsdlLocation=
  "http://localhost:8080/CalculatorService/Calculator?WSDL")
 static endpoint.CalculatorService service;

The value of the wsdlLocation parameter in @WebServiceRef is a URL that points to the location of the WSDL file for the referenced service. (The @WebServiceRef annotation supports additional properties that are optional. These optional properties are specified in section 7.9 of the JAX-WS 2.0 specification.) The static variable named service will be injected by the application client container.

Looking further at the source code for JAXWSClient, you'll notice the following line:

endpoint.Calculator port = service.getCalculatorPort();

The service object provides the method, getCalculatorPort, to access the Calculator port of the web service. Note that both endpoint.CalculatorService and endpoint.Calculator are portable artifacts that are generated by using the wsimport utility. The wsimport utility is used to generate JAX-WS artifacts (it is invoked as part of the build-client step when you run the example program.)

After you get the port, you can invoke a business method on it just as though you invoke a Java method on an object. For example, the following line in JAXWSClient invokes the add method in Calculator:

int ret = port.add(i, 10);

Running the Sample Code

A sample package accompanies this tip. It demonstrates the techniques covered in the tip. To install and run the sample:

1. If you haven't already done so, download GlassFish from the GlassFish Community Downloads page.
2. Set the following environment variables:

GLASSFISH_HOME: This should point to where you installed GlassFish (for example C:\Sun\AppServer)

ANT_HOME: This should point to where ant is installed. Ant is included in the GlassFish bundle that you downloaded. (In Windows, it's in the lib\ant subdirectory.)

JAVA_HOME: This should point to the location of JDK 5.0 on your system.

Also, add the ant location to your PATH environment variable.

3. Download the sample package for the tip and extract its contents. You should now see the newly extracted directory as /ttmar2006ejb-ws, where is the directory in which you installed the sample package. For example, if you extracted the contents to C:\ on a Windows machine, then your newly created directory should be at C:\ttmar2006ejb-ws. The ejb-techtip directory below ttmar2006ejb-ws contains the source files and other support file for the sample.
4. Change to the ejb-techtip directory and edit the build.properties files as appropriate. For example, if the admin host is remote, change the value of admin.host from the default (localhost) to the appropriate remote host.
5. Start GlassFish by entering the following command:

      /bin/asadmin start-domain domain1

where is the directory in which you installed GlassFish.

6. In the ejb-techtip directory, execute the following commands:

      ant build

This creates a build directory, compiles the classes, and puts the compiled classes in the build directory. It also creates an archive directory, creates a JAR file, and puts the JAR file in the archive directory.

      ant deploy

This deploys the JAR file on GlassFish.

      ant build-client

This generates portable artifacts and compiles the client source code.

      ant run

This runs the application client and invokes the add operation in the Calculator service 10 times, adding 10 to the numbers 0-to-9. You should see the following in response:

      run:

        [echo] Executing appclient with client class as
        client.JAXWSClient
        [exec] Retrieving port from the service
        endpoint.CalculatorService@159780d
        [exec] Invoking add operation on the calculator port
        [exec] Adding : 0 + 10 = 10
        [exec] Adding : 1 + 10 = 11
        [exec] Adding : 2 + 10 = 12
        [exec] Adding : 3 + 10 = 13
        [exec] Adding : 4 + 10 = 14
        [exec] Adding : 5 + 10 = 15
        [exec] Adding : 6 + 10 = 16
        [exec] Adding : 7 + 10 = 17
        [exec] Adding : 8 + 10 = 18
        [exec] Adding : 9 + 10 = 19

7. To undeploy the EJB Module from GlassFish, execute the following command:

      ant undeploy

About the Author

Manisha Umbarje is a member of the product engineering group for the Sun Java System Application Server.

Copyright (c) 2004-2005 Sun Microsystems, Inc.
All Rights Reserved.

SCBCD 5.0 Free Tutorials and Guide

This Blog lists all the free Tutorials and Guides available for the SCBCD 5.0 certification exam.

http://java.boot.by/scbcd5-guide - A must read notes for SCBCD 5.0.
http://www.geocities.com/rkbalgi/bcd5_notes.txt - Quick Revision notes for SCBCD 5.0

Common Articles for EJB 3.0

http://java.sun.com/javaee/5/docs/api/
http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html
What is new in EJB 3.0
EJB 3.0 Articles from JavaBeat
http://www.theserverside.com/tt/books/wiley/masteringEJB3/index.tss

Commercial Mock Exams for SCBCD 5.0

300 SCBCD 5.0 Mock Exam Questions