Tuesday, August 26, 2008

SCBCD 5.0 Section One Exam Objectives Sun Certified Business Component Developer Exam EJB 3.0

EJB 3.0 Overview

· Identify the uses, benefits, and characteristics of Enterprise JavaBeans technology, for version 3.0 of the EJB specification.

· Identify the APIs that all EJB 3.0 containers must make available to developers.

· Identify correct and incorrect statements or examples about EJB programming restrictions.

· Match the seven EJB roles with the corresponding description of the role's responsibilities.

· Describe the packaging and deployment requirements for enterprise beans.

· Describe the purposes and uses of annotations and deployment descriptors, including how the two mechanisms interact, how overriding is handled, and how these mechanisms function at the class, method, and field levels.

The first set of objectives for the SCBCD exam are mostly marketing hype.

As with any vendor certification, the company wants the people it certifies to not only be competent with the technology, but they want their certified professionals to be able to promote the product on which they are certified to others. It's not good enough to simply know how to program an EJB to be a SCBCD, but Sun also wants you to be able to sit in front of an architecture review board, or participate in a design meeting, and be able to prognosticate on why life will be so much easier if EJB 3.0 components were used.

Saturday, August 23, 2008

Bloom's Taxonomy of Learning

I used to do seminars on learning how to learn, and Bloom's taxonomy of learning was a part of it. I think it's a great goal, or scale to use, when writing computer books. When I'm done a Java or JEE or Sun Certification book, I like to think I've hit upon the various levels in the hierarchy as much as possible. taking people from the lower level, to the higher levels.

In 1956, Benjamin Bloom headed a group of educational psychologists who developed a classification of levels of intellectual behavior important in learning. Bloom found that over 95 % of the test questions students encounter require them to think only at the lowest possible level...the recall of information.

Bloom identified six levels within the cognitive domain, from the simple recall or recognition of facts, as the lowest level, through increasingly more complex and abstract mental levels, to the highest order which is classified as evaluation. Verb examples that represent intellectual activity on each level are listed here.

  1. Knowledge: arrange, define, duplicate, label, list, memorize, name, order, recognize, relate, recall, repeat, reproduce state.
  2. Comprehension: classify, describe, discuss, explain, express, identify, indicate, locate, recognize, report, restate, review, select, translate,
  3. Application: apply, choose, demonstrate, dramatize, employ, illustrate, interpret, operate, practice, schedule, sketch, solve, use, write.
  4. Analysis: analyze, appraise, calculate, categorize, compare, contrast, criticize, differentiate, discriminate, distinguish, examine, experiment, question, test.
  5. Synthesis: arrange, assemble, collect, compose, construct, create, design, develop, formulate, manage, organize, plan, prepare, propose, set up, write.
  6. Evaluation: appraise, argue, assess, attach, choose compare, defend estimate, judge, predict, rate, core, select, support, value, evaluate.


Monday, August 18, 2008

com.ibm.wsspi.amm.exception.NoSuchClassException: unable to locate class in module

[8/18/08 15:44:16:748 PDT] 00000000 wtp E org.eclipse.jst.j2ee.commonarchivecore.internal.impl.EJBJarFileImpl processAnnotations Annotations scanning of EJB JAR [ MayhemEJB.jar ] completed with errors.
[8/18/08 15:44:16:748 PDT] 00000000 wtp E org.eclipse.jst.j2ee.commonarchivecore.internal.impl.EJBJarFileImpl processAnnotations Annotations error:
com.ibm.wsspi.amm.exception.NoSuchClassException: unable to locate class com.mcnz.ejb.StatelessTimerLocal in module MayhemWeb.war
at com.ibm.ws.amm.scan.util.info.impl.DelayedClassInfo.getClassInfo(DelayedClassInfo.java:247)
at com.ibm.ws.amm.scan.util.info.impl.DelayedClassInfo.getDeclaredMethods(DelayedClassInfo.java:113)

Dang, I keep seeing this error. Somehow, my design time classpath isn't recognized by the runtime. That sucks. So, I included the EJB project in the classpath, and I thought the classloader loaded from both EJB and web modules, so I'm a little annoyed. Do I have to create an EJB client jar and put it in the root of the EAR. I saw some funny business with the EJB client
jar with IRAD 7.5 Beta, so I'd prefer not to. Oh well. We gotta get this running on WebSphere 7!

However now that I'm looking at it, I didn't go to the Web Libraries module dependency tab and click my EJB module. Maybe that's what I need to do. I had done it in the J2EE Modules tab though....Heh...J2EE...Shouldn't it be JEE?

Installing WebSphere 7 on Vista - IRAD 7.5

So, I had my buddy install the IBM Rational Application Developer 7.5 on Vista. I'd already installed IRAD 7.5 on my Windows XP laptop, and I've been having fun with it. My buddy has the curse of a laptop with Vista on it, but I figured what the heck, let's give it an install.

Well, we chose the basic options, and the WebSphere 7 test environment. The install seemed to go smoothly for the first three quarters of the progress bar, but then it just totally hung. It looked like it was the WebSphere 7 installation part that was barking up, as all the little console messages seemed to indicate that the IRAD libraries got installed ok.

Certainly, Vista is not a supported operating system for WebSphere 7, as it is a desktop operating system, not a server system. And of course, we must stress Beta. And I don't blame IBM, I blame Microsoft. But still, it's a drag. While WebSphere deserves a server operating system, there's lots of places that will want a local sandbox environment that has a familiar OS desktop operating system, and since Microsoft doesn't sell computers with XP any more, that's going to put alot of desktop users at a disadvantage. Of course, I guess the problem could just be solved if we all just did .NET development, and threw the whole Java/WebSphere/JEE development framework away. I'm sure M$ would just love that.

Wednesday, August 13, 2008

IRAD 7.5 Annotations View - IBM WebSphere7 Rational Applicaion Developer Java Perspective Tool

I just noticed a new View in Rational Application Developer 7.5 beta - it's the Annotations View. It appears that it provides data entry fields for all of the various attributes that can be set for a given annotation.

Annotations are new with Java 5. This is the first time I've seen this tab. I wonder if this is a standard tab with Eclipse, or a tab only provided with Rational Software Development Platform tooling.

How does WebSphere7 Bind EJB 3.0 Beans to the JNDI Server? Local and Remote Interfaces for Lookup

So, how easy is it going to be to do a lookup from a JSF app to an EJB? I've got both a remote and a local interface in this EJB 3.0 stateless session bean. Here's the binding information provided by WebSphere. Hopefully, this will make it easy. The web module awaits!

[8/13/08 18:09:11:074 PDT] 00000065 CompositionUn A WSVR0192I: Stopping composition unit WebSphere:cuname=TestProject,cuedition=1.0 in BLA WebSphere:blaname=TestProject,blaedition=1.0.
[8/13/08 18:09:11:074 PDT] 00000065 ApplicationMg A WSVR0217I: Stopping application: TestProject
[8/13/08 18:09:11:254 PDT] 00000065 EJBContainerI I WSVR0041I: Stopping EJB jar: TestEJB.jar
[8/13/08 18:09:11:274 PDT] 00000065 EJBContainerI I WSVR0059I: EJB jar stopped: TestEJB.jar
[8/13/08 18:09:11:324 PDT] 00000065 ApplicationMg A WSVR0220I: Application stopped: TestProject
[8/13/08 18:09:12:786 PDT] 00000065 CompositionUn A WSVR0193I: Composition unit WebSphere:cuname=TestProject,cuedition=1.0 in BLA WebSphere:blaname=TestProject,blaedition=1.0 stopped.
[8/13/08 18:09:12:916 PDT] 00000065 CompositionUn A WSVR0190I: Starting composition unit WebSphere:cuname=TestProject,cuedition=1.0 in BLA WebSphere:blaname=TestProject,blaedition=1.0.
[8/13/08 18:09:13:037 PDT] 00000065 ApplicationMg A WSVR0200I: Starting application: TestProject
[8/13/08 18:09:13:037 PDT] 00000065 ApplicationMg A WSVR0204I: Application: TestProject Application build level: Unknown

[8/13/08 18:09:13:167 PDT] 00000065 EJBContainerI I WSVR0037I: Starting EJB jar: TestEJB.jar
[8/13/08 18:09:13:167 PDT] 00000065 EJBContainerI I CNTR0167I: The server is binding the StatefulTimerRemote interface of the StatefulTimer enterprise bean in the TestEJB.jar module of the TestProject application. The binding location is: ejb/TestProject/TestEJB.jar/StatefulTimer#com.mcnz.ejb.StatefulTimerRemote
[8/13/08 18:09:13:167 PDT] 00000065 EJBContainerI I CNTR0167I: The server is binding the StatefulTimerRemote interface of the StatefulTimer enterprise bean in the TestEJB.jar module of the TestProject application.

The binding location is: com.mcnz.ejb.StatefulTimerRemote

[8/13/08 18:09:13:177 PDT] 00000065 EJBContainerI I CNTR0167I: The server is binding the StatefulTimerLocal interface of the StatefulTimer enterprise bean in the TestEJB.jar module of the TestProject application.

The binding location is: ejblocal:TestProject/TestEJB.jar/StatefulTimer#com.mcnz.ejb.StatefulTimerLocal

[8/13/08 18:09:13:177 PDT] 00000065 EJBContainerI I CNTR0167I: The server is binding the StatefulTimerLocal interface of the StatefulTimer enterprise bean in the TestEJB.jar module of the TestProject application.

The binding location is: ejblocal:com.mcnz.ejb.StatefulTimerLocal

[8/13/08 18:09:13:197 PDT] 00000065 EJBContainerI I WSVR0057I: EJB jar started: TestEJB.jar

[8/13/08 18:09:13:227 PDT] 00000065 webapp I com.ibm.ws.webcontainer.webapp.WebGroupImpl WebGroup SRVE0169I: Loading Web Module: TestWeb.
[8/13/08 18:09:13:267 PDT] 00000065 SessionCore I SessionContextRegistry getSessionContext SESN0176I: Will create a new session context for application key default_host/TestWeb
[8/13/08 18:09:13:297 PDT] 00000065 webcontainer I com.ibm.ws.wswebcontainer.VirtualHost addWebApplication SRVE0250I: Web Module TestWeb has been bound to default_host[*:9081,*:80,*:9444,*:5063,*:5062,*:443].
[8/13/08 18:09:13:367 PDT] 00000065 ApplicationMg A WSVR0221I: Application started: TestProject
[8/13/08 18:09:13:367 PDT] 00000065 CompositionUn A WSVR0191I: Composition unit WebSphere:cuname=TestProject,cuedition=1.0 in BLA WebSphere:blaname=TestProject,blaedition=1.0 started.
[8/13/08 18:09:13:537 PDT] 00000065 FileRepositor A ADMR0009I: Document cells/T41Node01Cell/applications/TestProject.ear/deltas/TestProject/delta-1218676150483 is created.
[8/13/08 18:09:13:537 PDT] 00000065 FileRepositor A ADMR0010I: Document cells/T41Node01Cell/applications/TestProject.ear/deployments/TestProject/META-INF/ibm-application-runtime.props is modified.
[8/13/08 18:09:13:537 PDT] 00000065 FileRepositor A ADMR0010I: Document cells/T41Node01Cell/applications/TestProject.ear/deployments/TestProject/deployment.xml is modified.

Creating EJB 3.0 Entity Beans in IRAD 7.5 - The JPA Entity Wizard in Rational

Entity Beans with IRAD 7.5 - EJB 3.0 JPA Annotated Entities

Just something neat about an EJB project in WebSphere IBM Rational Application Developer 7.5. You'll notice there is no option to create an EJB 3.0 entity bean, only 1.x and 2.x entity beans.

Of course, you can certainly create entity beans, but they're not so much entity beans of old, but instead, JPA entity is the more appropriate terminology, and it's created through the JPA wizard for creating an entity.

How many EJBs are here? IRAD 7.5 Seems To Think There's ALOT!

So, my first EJB developed with IRAD 7.5 beta has revealed some bugginess. I expect bugs, but I was hoping it would take longer for me to find one than my first EJB in my first IRAD project.

I created a single, simple, stateful session bean EJB, but for some reason, the development tool tells me that they're creating clones of themselves. Attack of the Clones I guess?

It seems the same type of stuff happens in the UTC. Strange...I'm sure it will all be fixed in the final release.

Trying to run any EJB bean except for the last one in the list gives the following error:

"Server Error: The Selection did not contain any resources that can run on a server."

Well, at least it works when I run the last one on the list. At least the working one isn't some mysterious one in the middle.

IBM Rational Application Developer 7.5 Seems Buggy

Well, IRAD 7.5, and more specifically, the EJB 3.0 development tool does seem a little buggy.

Still, I managed to create a simple, Stateful Session EJB (SFSB), add a method to both the local and remote interface, and then, deploy it and test it on WebSphere 7. Still, I got an exception, but I think that's more an issue of my logic than anything. I ran the test server and had a plate of scrabled eggs. Looks like my SFSB timed out, and when I tried to access a property of the bean, I got the following message:

javax.ejb.NoSuchEJBException: Stateful bean BeanId(TestProject#TestEJB.jar#StatefulTimer, BE9EC7AE-011B-4000-E000-0450C0A80167) was removed or timed out.
at com.ibm.ejs.container.activator.StatefulSessionActivationStrategy.atActivate(StatefulSessionActivationStrategy.java:240)
at com.ibm.ejs.container.activator.Activator.activateBean(Activator.java:599)
at com.ibm.ejs.container.EJSContainer.preInvokeActivate(EJSContainer.java:3868)
at com.ibm.ejs.container.EJSContainer.EjbPreInvoke(EJSContainer.java:3254)
at com.mcnz.ejb.EJSLocal0SFStatefulTimer_5d1d8f07.getStartTime(EJSLocal0SFStatefulTimer_5d1d8f07.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Shouldn't be a big problem. I'll just move the property initialization to the constructor, where it probably should be. Still, I'm not sure how to recreate a new SFSB instance using the WebSphere Test Environment for EJBs, aka Universal Test Client where the JNDI explorer resides. I think if I just close the UTC, and then select Run On Server again for the EJB, it'll work.


package com.mcnz.ejb;
import javax.ejb.Stateful;

@Stateful(mappedName = "SFSBTimer")
public class StatefulTimer implements StatefulTimerRemote, StatefulTimerLocal {

private long startTime = System.currentTimeMillis();

public StatefulTimer() {

public long getStartTime() {
return startTime;

public long getElapsedTime() {
return System.currentTimeMillis() - startTime;



package com.mcnz.ejb;
import javax.ejb.Local;

public interface StatefulTimerLocal {

long getStartTime();



package com.mcnz.ejb;
import javax.ejb.Remote;

public interface StatefulTimerRemote {

long getElapsedTime();



The ejb-jar.xml file for the EJB 3.0 module:

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" version="3.0">


I think this is the code I'll use to replace my SFSB bean class:

package com.mcnz.ejb;

import javax.ejb.Stateful;

@Stateful(mappedName = "SFSBTimer")
public class StatefulTimer implements StatefulTimerRemote, StatefulTimerLocal {

private long startTime;

public StatefulTimer() {
startTime = System.currentTimeMillis();

public long getStartTime() {
if (startTime == 0) {
startTime = System.currentTimeMillis();
return startTime;

public long getElapsedTime() {
return System.currentTimeMillis() - startTime;


Hmmmm...on the retry I got a new exception? Neat, a HomeDisabledException. Interesting...

com.ibm.ejs.container.HomeDisabledException: TestProject#TestEJB.jar#StatefulTimer at com.ibm.ejs.container.EJSHome.homeEnabled(EJSHome.java:483) at com.ibm.ejs.container.EJSHome.getBeanMetaData(EJSHome.java:1620) at com.ibm.ejs.container.BeanId.getBeanMetaData(BeanId.java:395) at com.ibm.ejs.container.drs.SfDRSCache.faultDataIntoCache(SfDRSCache.java:526) at com.ibm.ejs.container.drs.SfDRSCache.beanDoesNotExistOrHasTimedOut(SfDRSCache.java:285) at com.ibm.ejs.container.StatefulBeanReaper.beanDoesNotExistOrHasTimedOut(StatefulBeanReaper.java:406) at com.ibm.ejs.container.activator.StatefulSessionActivationStrategy.atActivate(StatefulSessionActivati
onStrategy.java:213) at com.ibm.ejs.container.activator.Activator.activateBean(Activator.java:599)

Heh...Perseverance works; after updating my code, redeploying the EJB, and not eating a plate of scrambled eggs and cheese in the between time, everything worked!

long getStartTime()

Results from com.mcnz.ejb.EJSLocal0SFStatefulTimer_5d1d8f07.getStartTime()
1218676944775 (long)

Object contains no fields

Creating Stateless & Stateful Session Beans - EJB 3.0 Java Development

When it comes to development, there are really three different types of components you can develop, namely, a Session Bean, an Entity Bean, and a Message Driven Bean.

As you could probably guess, Message Driven beans interact with a messaging system, reading messages off of a topic or a queue. Entity Beans represent data, and as you might expect, Entity Beans interact with some type of data storage facility, which is usually, but not exclusively limited to, a JDBC database. Session Beans on the other hand are much simpler. Session EJBs don't need to interact with a messaging system or a database. Session beans are simply components that contain Java code and business logic, and as such, they have no real dependency on any external infrastructure other than the EJB container in which they are deployed.

In light of the fact that they do not need a configured message queue, or a full database installation, in order to be developed, tested and deployed, Session Bean EJBs are definitely the best place to start when tackling the EJB 3.0 specification, and that's exactly what we're going to do right now - look at how to develop EJB 3.0 Session Beans.

Tuesday, August 12, 2008

A Little Bit About EJB 3.0

One thing I hate is history lessons. Nothing annoys me more than picking up a book on a technology that I'm interesting in learning, only to be given a ridiculously long lecture on the history of the Internet. Not that I don't find history mildly entertaining, but when I want to learn something, I want to learn it, not learn a great big long history that really doesn't have anything to do with what I'm studying.

With that being said, I'm going to lead in with a short history of EJBs. While I'm a little remiss in doing it, I do feel that it is important to understand how we got to where we are today in the world of Enterprise JavaBean development.

Interestingly enough, when the whole EJB thing started out, there was only one type of Enterprise JavaBean, and that was the Session bean. Now, if you know anything about EJB development, you might find that a little strange, after all, Entity Beans, a special type of EJB, have been around for years, and anyone that's tinkered in that shallow pool of enterprise messaging has heard of the other, third type of EJB, the Message Driven Bean, but in fact, when the whole EJB thing got started, there was only one type of EJB - the Session Bean.

If only one thing can be said about enterprise programming, it's the fact that it is hard. And not only is it hard, but the same types of development issues are constantly rearing their ugly heads.

For example, if you've got a powerful piece of business logic, what happens when a large number of concurrent business clients request access to it? Many good pieces of code fail when placed under a heavy, multithreaded, load. And for that matter, how will enterprise Java code be accessed by remote clients, or perhaps even clients that aren't necessarily even Java clients. After all, many established Fortune 500 companies have large infrastructures that speak more CORBA than Java.

And of course, security is always an issue. People always want to secure business logic, especially when it's being accessed by all sorts of remote clients that might not necessarily have your application's best interests in mind. So, to appease all of those paranoid administrators that sit on architecture review boards, enterprise developers recognized that they needed some way to secure their scalable, multithreaded, remotely accessible components.

So, as intelligent and handsome, enterprise Java developers were recognizing that Java applets running in a web browser weren't going to address all of their real world needs, they started to play with the idea of a container managed component that would address the challenges of enterprise development in Java. At the time, Servlets and JSPs were already a way for Internet browser based requests to be handled in a secure, multithreaded and scalable manner by what is known as a 'web container' or 'servlet engine.' Why couldn't business components have the same type of thing, where the problems of remotely accessible, multithreaded and secure business logic could be accessed just as easliy as a web page could be requested, rendered, and returned to a client?

So, as the idea of an EJB emerged, what we had was a very simple and effective, remotely accessible, scalable, secure and multithreaded business component that was known as a Session bean. That was the good old days, when life was simple. But the simple times didn't last too long in the EJB world.

If you've ever worked with developers, you know that they can never leave things alone. They always have to make good things 'better', which typically results in everything getting all messed up, and that's exactly what happened with Session beans. You see, developers figured that since Session beans were so great, they'd be even greater if we put a bunch of database code in them, and mapped those Session beans to database tables. Developers across the globe started sticking database access code within Session beans, and were just making a mess out of Session EJBs. It was at that point that it was decided to introduce a new type of EJB into the mix, the Entity Bean, which would be a special type of EJB that maps Java fields and properties directly to database tables and columns. It was a bit of an ugly, kloogy hack on the Session bean, but everyone was excited about it at the time, so the entity bean proliferated.

Of course, the Entity Bean and Session Bean combination didn't solve every problem. You see, business logic and database access represent only two of the three legs that keeps the enterprise programming stool standing - the EJB spec hadn't addressed messaging at all, and again, developers were creating all sorts of awful solutions that stuffed JMS code in an already over-stuffed Session bean. So, the next step in the de-evolution of the EJB specification was the introduction of a Message Driven Bean, or MDB, which frankly, didn't look like an EJB at all, and skirting around many of the rules and design guidelines we had taken for granted when it came to EJB development.

Anyways, the picture I'm trying to paint here is one of a very reactionary evolution of the EJB specification, where additions and improvements were made by duct taping them on top of the original specification, which was really awful, especially in light of the fact that Java itself has always been very elegant and symmetrical in its evolution and growth. The fact was, by time the EJB 2.1 specification came around, EJB development looked ugly, and many industry experts were recommending against it.

In my own 2004 book, What is WebSphere?, I wrote a section on when to use EJBs, which more than anything, tried to dissuade people from using EJBs unless absolutely necessary. At about the same time that I was writing that, Rod Johnson and Juergen Hoeller released Expert One-on-One J2EE Development WithOUT EJBs, emphasizing that enterprise development could be done without these heavyweight components. Rather than solving many of the key challenges developers and architects face when building enterprise applications, EJBs themselves were starting to be seen as the problem, and people were avoiding them. I know that I was.

But all of that has changed with EJB 3.0. The developers and the contributors to the EJB specification recognized pretty much as soon as the EJB 2.1 specification came out that things were going in the wrong direction.

Version 3 is a significant departure from earlier EJB specifications. Rather than being onerous and intimidating, 3.0 EJBs promise to be easier to code and deploy, using a POJO based (POJO = Plain Ordinary Java Object) approach to development, leveraging annotations to allow for declarative bean metadata, as opposed to using detached XML files, and EJB 3.0 even incorporates the idea of dependency injection for the first time ever.

And the whole approach to enterprise development with EJB 3.0 is much more philisophically sound, as can be seen by the EJB 3.0 JSR document itself. (JSR 220)

Unlike most Sun JSRs, the EJB 3.0 spec is actually broken down into three separate documents, which together make up the specification.

The first of these thre documents is named the EJB 3.0 Simplified API Document, which details the new, simpler approach to EJB development that we see with this specification.

The second document describes the Java Persistence API, which represents a much simpler and easier way to implement data persistence within an EJB, or even non-EJB, POJO based, environment.

Finally, the third document, the EJB Core Contracts and Requirements, which essentially outlines what a developer can expect from any 3.0 compliant EJB container.

"The document “EJB 3.0 Simplified API” provides an overview of the simplified API that is introduced
by the Enterprise JavaBeans 3.0 release.

The document “Java Persistence API” is the specification of the new API for the management of persistence
together with the full specification of the Java Persistence query language (a superset of EJB QL).
It provides the definition of the persistence API that is required to be supported under the Enterprise
JavaBeans 3.0 release as well as the definition of how the Java Persistence API is supported for use in
Java SE environments.

This document, “EJB Core Contracts and Requirements”, defines the contracts and requirements for the
use and implementation of Enterprise JavaBeans. These contracts include those for the EJB 3.0 Simplified
API, as well as for the EJB 2.1 API, which is also required to be supported in this release. The contracts
and requirements for implementations of this specification also include, by reference, those
defined in the “Java Persistence API” document [2].

-EJB 3.0 Specification