Because lifecycle methods are invoked by the container, there really is no sense in throwing application specific exceptions during the invocation of a lifecycle interceptor method. As such, lifecycle interceptor methods may not throw application exceptions, although they are allowed to throw RuntimeExceptions. If a runtime exception is thrown during an EJB3 lifecycle callback interceptor method, the interceptor chain unwinds, and the EJB instance is discarded. Of course, what else can you really do when a RuntimeException is thrown?
"Lifecycle callback interceptor methods may throw system runtime exceptions, but not application exceptions.
A runtime exception thrown by any lifecycle interceptor callback method causes the bean instance and its interceptors to be discarded after the interceptor chain unwinds. The lifecycle callback interceptor methods for a lifecycle event run in the same Java call stack as the lifecycle callback method on the bean class. InvocationContext.proceed() will throw the
same exception as any thrown by another lifecycle callback interceptor method or lifecycle callback method on the bean class unless an interceptor further down the Java call stack has caught it and thrown a different exception. A lifecycle callback interceptor method (other than a method on the bean call or its superclasses) may catch an exception thrown by another lifecycle callback interceptor method in the invocation chain, and clean up before returning. Exceptions and initialization and/or cleanup operations should typically be handled in try/catch/finally blocks around the proceed() method. The PreDestroy callbacks are not invoked when the bean and the interceptors are discarded as a result of such exceptions: the lifecycle callback interceptor methods in the chain should perform any necessary clean-up operations as the interceptor chain unwinds."
Wednesday, September 3, 2008
What is the order of invocation on lifecycle interceptor methods for EJB3 beans - Passivate, Activate, PostContruct & PreDestroy annotations and xml
One of the confusing things about lifecycle interceptors is the fact that they can be defined in a variety of places, including a superclass, a deployment descriptor that references a class that acts as an interceptor, and even the EJB3 bean itself. So, the question arises, what is the order that a given set of lifecycle interceptor methods will be invoked if they are defined in a variety of different, yet valid, locations? Well, the EJB specification, namely page 306 of the core contracts document, specifically addresses this very question. Check it out!
"If multiple callback interceptor methods are defined for a lifecycle event for a bean, the following rules governing their invocation order apply. The deployment descriptor may be used to override the interceptor invocation order specified in annotations, as described in section 12.8.
• Default interceptors, if any, are invoked first. Default interceptors can only be specified in the deployment descriptor. Default interceptors are invoked in the order of their specification in the deployment descriptor.
• If there are any interceptor classes defined on the bean class, the lifecycle callback interceptor methods defined by those interceptor classes are invoked before any lifecycle callback interceptor methods defined on the bean class itself.
• The lifecycle callback interceptor methods defined on those interceptor classes are invoked in the same order as the specification of the interceptor classes in the Interceptors annotation.
• If an interceptor class itself has superclasses, the lifecycle callback interceptor methods defined by the interceptor class’s superclasses are invoked before the lifecycle callback interceptor method defined by the interceptor class, most general superclass first.
• After the lifecycle callback interceptor methods defined on interceptor classes have been invoked, then
• If a bean class has superclasses, any lifecycle callback interceptor methods defined on those superclasses are invoked, most general superclass first.
• The lifecycle callback interceptor method, if any, on the bean class itself is invoked.
• If a lifecycle callback interceptor method is overridden by another method (regardless of
whether that method is itself a lifecycle callback interceptor method (of the same or different
type)), it will not be invoked.
The deployment descriptor may be used to override the interceptor invocation order specified in annotations, as described in section 12.8.2. All lifecycle callback interceptor methods for a given lifecycle event run in the same Java call stack. If there is no corresponding callback method on the bean class (or any of its superclasses), the InvocationContext.proceed invocation on the last interceptor method defined on an interceptor class in the chain will be a no-op. The InvocationContext object provides metadata that enables interceptor methods to control the invocation of further methods in the chain. See Section 12.5."
"If multiple callback interceptor methods are defined for a lifecycle event for a bean, the following rules governing their invocation order apply. The deployment descriptor may be used to override the interceptor invocation order specified in annotations, as described in section 12.8.
• Default interceptors, if any, are invoked first. Default interceptors can only be specified in the deployment descriptor. Default interceptors are invoked in the order of their specification in the deployment descriptor.
• If there are any interceptor classes defined on the bean class, the lifecycle callback interceptor methods defined by those interceptor classes are invoked before any lifecycle callback interceptor methods defined on the bean class itself.
• The lifecycle callback interceptor methods defined on those interceptor classes are invoked in the same order as the specification of the interceptor classes in the Interceptors annotation.
• If an interceptor class itself has superclasses, the lifecycle callback interceptor methods defined by the interceptor class’s superclasses are invoked before the lifecycle callback interceptor method defined by the interceptor class, most general superclass first.
• After the lifecycle callback interceptor methods defined on interceptor classes have been invoked, then
• If a bean class has superclasses, any lifecycle callback interceptor methods defined on those superclasses are invoked, most general superclass first.
• The lifecycle callback interceptor method, if any, on the bean class itself is invoked.
• If a lifecycle callback interceptor method is overridden by another method (regardless of
whether that method is itself a lifecycle callback interceptor method (of the same or different
type)), it will not be invoked.
The deployment descriptor may be used to override the interceptor invocation order specified in annotations, as described in section 12.8.2. All lifecycle callback interceptor methods for a given lifecycle event run in the same Java call stack. If there is no corresponding callback method on the bean class (or any of its superclasses), the InvocationContext.proceed invocation on the last interceptor method defined on an interceptor class in the chain will be a no-op. The InvocationContext object provides metadata that enables interceptor methods to control the invocation of further methods in the chain. See Section 12.5."
Identify correct statements about the lifecycle of EJB instances, including the use of the @PostConstruct and @PreDestroy callback methods
SCBCD Objective: Identify correct and incorrect statements or examples about the lifecycle of all 3.0 Enterprise Bean instances, including the use of the @PostConstruct and @PreDestroy callback methods.
One of the things you need to understand about EJBs, especially Session Beans and Message Driven Beans, is that the lifecycle of these objects are managed by the application server. As a developer, you will never call the constructor of a Session bean, or invoke the finalize method on a Message Driven Bean. To do so would imply that you, the developer, have some part in managing the lifecycle of an EJB, and alas, you simply do not. Session Beans and Message Driven beans have their entire lifecycle managed by the application server, and there's nothing you, as a developer, can do about it.
Of course, as developers, sometimes it would be nice to do something, or take some action, or perform some type of initialization when the application server creates, or initializes, a real-live instance of one of the EJBs you have created. Similarly, it might be nice to perhaps release some resources, or perform some type of clean-up when a given EJB is take out of service by the EJB container. Certainly, this isn't an unreasonable request for a developer to ask, so as you could imagine, the EJB3 spec provides a very simple facility that allows the developer to respond to various EJB lifecycle events. This facility is known as lifecycle method interceptor callbacks.
Basically, if you want to perform some logic immediately after an EJB has been created by the EJB container, you simply code a method in your EJB bean class, and decorate that method with the @PostConstruct annotation. If you would like to have some funky logic performed immediately before an EJB is taken out of service and garbage collected, you simply code a method in the EJB bean class and decorate that method with the @PreDestroy annotation. It's all just that simple!
******************************
******************************
What types of EJBs can have lifecycle interceptor methods?
"Lifecycle callback interceptor methods may be defined for session beans and message driven beans.
Interceptor methods for lifecycle event callbacks can be defined on an interceptor class and/or directly on the bean class. The PostConstruct, PreDestroy, PostActivate, and PrePassivate annotations are used to define an interceptor method for a lifecycle callback event. If the deployment descriptor is used to define interceptors, the post-construct, pre-destroy, post-activate, and pre-passivate elements are used.
Lifecycle callback interceptor methods and business method interceptor methods may be defined on the same interceptor class. Lifecycle callback interceptor methods are invoked in an unspecified transaction and security context. Lifecycle callback interceptor methods may be defined on superclasses of the bean class or interceptor classes. However, a given class may not have more than one lifecycle callback interceptor method for the same lifecycle event. Any subset or combination of lifecycle callback annotations may be specified on a given class. A single lifecycle callback interceptor method may be used to interpose on multiple callback events (e.g., PostConstruct and PostActivate). Lifecycle callback interceptor methods defined on an interceptor class have the following signature:
void (InvocationContext)
Lifecycle callback interceptor methods defined on a bean class have the following signature:
void()
Lifecycle callback interceptor methods can have public, private, protected, or package level access. A lifecycle callback interceptor method must not be declared as final or static." -Core Contracts EJB 3 Document pg 305
One of the things you need to understand about EJBs, especially Session Beans and Message Driven Beans, is that the lifecycle of these objects are managed by the application server. As a developer, you will never call the constructor of a Session bean, or invoke the finalize method on a Message Driven Bean. To do so would imply that you, the developer, have some part in managing the lifecycle of an EJB, and alas, you simply do not. Session Beans and Message Driven beans have their entire lifecycle managed by the application server, and there's nothing you, as a developer, can do about it.
Of course, as developers, sometimes it would be nice to do something, or take some action, or perform some type of initialization when the application server creates, or initializes, a real-live instance of one of the EJBs you have created. Similarly, it might be nice to perhaps release some resources, or perform some type of clean-up when a given EJB is take out of service by the EJB container. Certainly, this isn't an unreasonable request for a developer to ask, so as you could imagine, the EJB3 spec provides a very simple facility that allows the developer to respond to various EJB lifecycle events. This facility is known as lifecycle method interceptor callbacks.
Basically, if you want to perform some logic immediately after an EJB has been created by the EJB container, you simply code a method in your EJB bean class, and decorate that method with the @PostConstruct annotation. If you would like to have some funky logic performed immediately before an EJB is taken out of service and garbage collected, you simply code a method in the EJB bean class and decorate that method with the @PreDestroy annotation. It's all just that simple!
******************************
package com.mcnz.ejb;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.PostActivate;
import javax.ejb.PrePassivate;
import javax.ejb.Stateful;
@Stateful
public class StatefulTimerBean implements StatefulTimerLocal {
private Long startTime;
public StatefulTimerBean() {System.out.print("Constructor");}
@PostConstruct
void negate() {
startTime = new Long(-1);
System.out.println("PostCreate");
}
@PreDestroy
void nullify() {
startTime = null;
System.out.println("PreDestroy");
}
public void start(){
startTime = System.currentTimeMillis();
}
public long getStartTime() {
return startTime;
}
public long getElapsedTime() {
return System.currentTimeMillis() - startTime;
}
public boolean isStarted() {
if (! (startTime > 0) ){return false;}
else {return true;}
}
@PrePassivate
public void customSave() {
System.out.println("Container is Passivating!");
}
@PostActivate
public void customLoad() {
System.out.println("Container has Activated!");
}
}
******************************
What types of EJBs can have lifecycle interceptor methods?
"Lifecycle callback interceptor methods may be defined for session beans and message driven beans.
Interceptor methods for lifecycle event callbacks can be defined on an interceptor class and/or directly on the bean class. The PostConstruct, PreDestroy, PostActivate, and PrePassivate annotations are used to define an interceptor method for a lifecycle callback event. If the deployment descriptor is used to define interceptors, the post-construct, pre-destroy, post-activate, and pre-passivate elements are used.
Lifecycle callback interceptor methods and business method interceptor methods may be defined on the same interceptor class. Lifecycle callback interceptor methods are invoked in an unspecified transaction and security context. Lifecycle callback interceptor methods may be defined on superclasses of the bean class or interceptor classes. However, a given class may not have more than one lifecycle callback interceptor method for the same lifecycle event. Any subset or combination of lifecycle callback annotations may be specified on a given class. A single lifecycle callback interceptor method may be used to interpose on multiple callback events (e.g., PostConstruct and PostActivate). Lifecycle callback interceptor methods defined on an interceptor class have the following signature:
void
Lifecycle callback interceptor methods defined on a bean class have the following signature:
void
Lifecycle callback interceptor methods can have public, private, protected, or package level access. A lifecycle callback interceptor method must not be declared as final or static." -Core Contracts EJB 3 Document pg 305
Tuesday, September 2, 2008
rules for writing a web service endpoint interface and use of the @WebService and @WebMethod annotations.
Identify correct and incorrect statements or examples about implementing a session bean as a web service endpoint, including rules for writing a web service endpoint interface and use of the @WebService and @WebMethod annotations.
"To support web service interoperability, the EJB specification requires compliant implementations tosupport XML-based web service invocations using WSDL and SOAP or plain XML over HTTP in conformance with the requirements of the JAX-WS [32], JAX-RPC [25], Web Services for Java EE [31], and Web Services Metadata for the Java Platform [30] specifications."
You know, it's amazing, but turning Stateless Session EJBs into Web Services is just as simple as adding an annotation after the @Stateless decoration. Here's the little EJB I created to test the @WebService annotation. All I had to do was add the annotation, deploy, and I was able to test it with WebSphere 7's Web Services explorer.
package com.mcnz.ejb;
import javax.ejb.Stateless;
import javax.jws.WebService;
@Stateless
@WebService
public class StatelessTimerBean implements StatelessTimerLocal {
public StatelessTimerBean() {
}
public String helloWorld() {
return "Hello World";
}
}
One thing I didn't really understand was how the EJB container knew how to deploy my EJB as a web service. I mean, I guess it just deployed the EJB, but how did all the Web Service razzle dazzle happen? I mean, that has to go through an HTTP port, right? So does that mean an EJB3 SLSB with a @WebService decoration uses a web project or web container? I'm perplexed right now, but I'll dig into the WebSphere Application Server and see exactly what is going on behind the scenes. Here's what the spec says:
"Session Bean’s Web Service Endpoint Interface
EJB 3.0 does not require the definition of a web service endpoint interface for session beans that implement a web service endpoint.
The following are requirements for session beans with JAX-RPC web service endpoint interfaces. The JAX-WS and Web Services for Java EE specifications do not require that a separate interface be defined for a web service endpoint.
The following are the requirements for a stateless session bean’s web service endpoint interface. The web service endpoint interface must follow the rules for JAX-RPC service endpoint interfaces.
• The web service endpoint interface must extend the java.rmi.Remote interface.
• The methods defined in the interface must follow the rules for JAX-RPC service endpoint interfaces. This means that their argument and return values must be of valid types for JAX-RPC, and their throws clauses must include the java.rmi.RemoteException.
The throws clause may additionally include application exceptions.
Note that JAX-RPC Holder classes may be used as method parameters. The JAX-RPC specification requires support for Holder classes as part of the standard Java mapping of WSDL operations in order to handle out and inout parameters. Holder classes implement the javax.xml.rpc.holders.Holder interface
• For each method defined in the web service endpoint interface, there must be a matching method in the session bean’s class. The matching method must have:
• The same name.
• The same number and types of arguments, and the same return type.
• All the exceptions defined in the throws clause of the matching method of the session bean class must be defined in the throws clause of the method of the web ser vice endpoint interface.
• The web service endpoint interface must not include an EJBObject or EJBLocalObject as either a parameter or return type. An array or JAX-RPC value type must not include an EJBObject or EJBLocalObject as a contained element. The web service endpoint interface methods must not expose business interface types, local or remote interface types, local or remote home interface types, timers or timer handles, or the managed collection classes that are used for entity beans with container-managed persistence as arguments or results or as fields of value types.
• JAX-RPC serialization rules apply for any value types that are used by the web service endpoint interface. If it is important that Java serialization semantics apply, the Bean Provider should use the restricted set of JAX-RPC value types for which the semantics of Java serialization apply under JAX-RPC serialization. See the JAX-RPC specification [25] for details.
• The web service endpoint interface must not include constant (as public final static) declarations.
• The Bean Provider must designate the web service endpoint interface in the deployment descriptor by means of the service-endpoint element. The service endpoint itself is only exposed within a web service if it is referenced by a web service deployment descriptor.
The implementation class for a stateless session bean’s web service endpoint is generated by the container’s deployment tools. This class must handle requests to the web service endpoint, unmarshall the SOAP request, invoke any business method interceptor methods, and invoke the stateless session bean method that matches the web service endpoint method that corresponds to the request."
"To support web service interoperability, the EJB specification requires compliant implementations tosupport XML-based web service invocations using WSDL and SOAP or plain XML over HTTP in conformance with the requirements of the JAX-WS [32], JAX-RPC [25], Web Services for Java EE [31], and Web Services Metadata for the Java Platform [30] specifications."
You know, it's amazing, but turning Stateless Session EJBs into Web Services is just as simple as adding an annotation after the @Stateless decoration. Here's the little EJB I created to test the @WebService annotation. All I had to do was add the annotation, deploy, and I was able to test it with WebSphere 7's Web Services explorer.
package com.mcnz.ejb;
import javax.ejb.Stateless;
import javax.jws.WebService;
@Stateless
@WebService
public class StatelessTimerBean implements StatelessTimerLocal {
public StatelessTimerBean() {
}
public String helloWorld() {
return "Hello World";
}
}
One thing I didn't really understand was how the EJB container knew how to deploy my EJB as a web service. I mean, I guess it just deployed the EJB, but how did all the Web Service razzle dazzle happen? I mean, that has to go through an HTTP port, right? So does that mean an EJB3 SLSB with a @WebService decoration uses a web project or web container? I'm perplexed right now, but I'll dig into the WebSphere Application Server and see exactly what is going on behind the scenes. Here's what the spec says:
"Session Bean’s Web Service Endpoint Interface
EJB 3.0 does not require the definition of a web service endpoint interface for session beans that implement a web service endpoint.
The following are requirements for session beans with JAX-RPC web service endpoint interfaces. The JAX-WS and Web Services for Java EE specifications do not require that a separate interface be defined for a web service endpoint.
The following are the requirements for a stateless session bean’s web service endpoint interface. The web service endpoint interface must follow the rules for JAX-RPC service endpoint interfaces.
• The web service endpoint interface must extend the java.rmi.Remote interface.
• The methods defined in the interface must follow the rules for JAX-RPC service endpoint interfaces. This means that their argument and return values must be of valid types for JAX-RPC, and their throws clauses must include the java.rmi.RemoteException.
The throws clause may additionally include application exceptions.
Note that JAX-RPC Holder classes may be used as method parameters. The JAX-RPC specification requires support for Holder classes as part of the standard Java mapping of WSDL operations in order to handle out and inout parameters. Holder classes implement the javax.xml.rpc.holders.Holder interface
• For each method defined in the web service endpoint interface, there must be a matching method in the session bean’s class. The matching method must have:
• The same name.
• The same number and types of arguments, and the same return type.
• All the exceptions defined in the throws clause of the matching method of the session bean class must be defined in the throws clause of the method of the web ser vice endpoint interface.
• The web service endpoint interface must not include an EJBObject or EJBLocalObject as either a parameter or return type. An array or JAX-RPC value type must not include an EJBObject or EJBLocalObject as a contained element. The web service endpoint interface methods must not expose business interface types, local or remote interface types, local or remote home interface types, timers or timer handles, or the managed collection classes that are used for entity beans with container-managed persistence as arguments or results or as fields of value types.
• JAX-RPC serialization rules apply for any value types that are used by the web service endpoint interface. If it is important that Java serialization semantics apply, the Bean Provider should use the restricted set of JAX-RPC value types for which the semantics of Java serialization apply under JAX-RPC serialization. See the JAX-RPC specification [25] for details.
• The web service endpoint interface must not include constant (as public final static) declarations.
• The Bean Provider must designate the web service endpoint interface in the deployment descriptor by means of the service-endpoint element. The service endpoint itself is only exposed within a web service if it is referenced by a web service deployment descriptor.
The implementation class for a stateless session bean’s web service endpoint is generated by the container’s deployment tools. This class must handle requests to the web service endpoint, unmarshall the SOAP request, invoke any business method interceptor methods, and invoke the stateless session bean method that matches the web service endpoint method that corresponds to the request."
Creating & Testing EJB3 Web Services with IBM Rational IRAD 7.5 for WebSphere
So, I'm playing with IRAD 7.5 Beta, and I'm testing the tools ability to create a Web Service out of a simple Stateless Session Bean (SLSB). In theory, creating it should be as easy as simply decorating the EJB with the @WebService annotation and deploying it, so that's what I did.
Now, I did see a Wizard that said Web Services --> Create Web Services, so I figured I'd give it a try. However, a huge wizard came up, and it looked like it was the same old wizard from before. I created a web service based on a FooEJB, but the IRAD 7.5 beta tool didn't actually decorate my version 3 EJB with @WebService annotations, so I knew that whatever it was doing, it was doing it the old way, not the new way. Still, I let the wizard run. The good thing about the wizard is that it brings up a whole Web Service test environment, and I figured that'd be good, just to see the URL that WebSphere creates for the test Web Service.
So, I deployed my project with the Wizard created Web Service, along with my annotated @WebService EJB. The Web Service test window came up, and the Web Service created by the tool seemed to work.Now, one thing I did before using the wizard was click on something called a Web Service Endpoint Enabler.
Anyways, under Services in my EJB module, the web service created with the wizard was listed, so I right clicked and selected "Test with Web Service Explorer." The wizard created WS worked!
So, I dug around, and somehow, under WebSphere Web Service WSDL documents, a link to my EJB3.0 @WebService was listed. I clicked GO, and then tested my HelloWorld method, and lo and behold, it worked!
I must say, I was pretty impressed! Good job, IBM!
****************************************************
package com.mcnz.ejb;
import javax.ejb.Stateless;
import javax.jws.WebService;
@Stateless
@WebService
public class StatelessTimerBean implements StatelessTimerLocal {
public StatelessTimerBean() {
}
public String helloWorld() {
return "Hello World";
}
}
*** ********** **** ********** * ******** **** ******* ****
package com.mcnz.ejb;
import javax.ejb.Local;
@Local
public interface StatelessTimerLocal {
String helloWorld();
}
****************************************************
Wednesday, August 27, 2008
Forcing Passivation with Stateful Session EJBs on WebSphere IRAD 7.5 - EJB3
So, I'm actually trying to passivate my EJBs, and then activate them, but I can't seem to force WAS to do it.
I believe that with EJB 2.1, WebSphere did active passivation, so as soon as you invoked a method, the bean was passivated when invocation was finished. Then the bean was activated just before calling another method in it. So, it was easy to test an activation and passivation implementation.
But, with this version of Rational Application Developer, 7.5, it doesn't seem to be doing active passivation. Instead, passivation only seems to happen when the bean times out, and after being removed, any call to the timed out EJB instance triggers a HomeDisabledException.
All I want is my active-passivation back from the EJB Container in the WebSphere Application Server. Is that too much to ask?
I believe that with EJB 2.1, WebSphere did active passivation, so as soon as you invoked a method, the bean was passivated when invocation was finished. Then the bean was activated just before calling another method in it. So, it was easy to test an activation and passivation implementation.
But, with this version of Rational Application Developer, 7.5, it doesn't seem to be doing active passivation. Instead, passivation only seems to happen when the bean times out, and after being removed, any call to the timed out EJB instance triggers a HomeDisabledException.
All I want is my active-passivation back from the EJB Container in the WebSphere Application Server. Is that too much to ask?
com.ibm.ejs.container.HomeDisabledException
Look at this, pretty little exception:
javax.ejb.EJBException: See nested exception; nested exception is:
com.ibm.ejs.container.HomeDisabledException: Mayhem#MayhemEJB.jar#StatefulTimerBean com.ibm.ejs.container.HomeDisabledException: Mayhem#MayhemEJB.jar#StatefulTimerBean 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(StatefulSessionActivationStrategy.java:213)
So, HomeDisabled, eh? I thought version 3.0 EJBs didn't have Homes? Well, I guess it's up to the container whether they do or not - it's really not my business, because I'm not using them.
So, what's the solution to this problem? Well, in this case, my bean SFSB was passivated, likely removed from the server when I "Cleaned the WebSphere Application Server in IRAD" and then, when I invoked it again, the bean was gone, nowhere to be found, as it was likely not just passivated, but completely removed from the container.
So, I guess when you invoke a Stateful Session Bean, you must be careful that it doesn't timeout, catch the EJB exception, and look it up again if it is expired or timed out. Does that sound right?
javax.ejb.EJBException: See nested exception; nested exception is:
com.ibm.ejs.container.HomeDisabledException: Mayhem#MayhemEJB.jar#StatefulTimerBean com.ibm.ejs.container.HomeDisabledException: Mayhem#MayhemEJB.jar#StatefulTimerBean 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(StatefulSessionActivationStrategy.java:213)
So, HomeDisabled, eh? I thought version 3.0 EJBs didn't have Homes? Well, I guess it's up to the container whether they do or not - it's really not my business, because I'm not using them.
So, what's the solution to this problem? Well, in this case, my bean SFSB was passivated, likely removed from the server when I "Cleaned the WebSphere Application Server in IRAD" and then, when I invoked it again, the bean was gone, nowhere to be found, as it was likely not just passivated, but completely removed from the container.
So, I guess when you invoke a Stateful Session Bean, you must be careful that it doesn't timeout, catch the EJB exception, and look it up again if it is expired or timed out. Does that sound right?
ID correct statements on the lifecycle of a Stateful Session Bean including @PrePassivate & @PostActivate lifecycle callback & @Remove methods SCBCD5
Identify correct and incorrect statements or examples about the lifecycle of a Stateful Session Bean including the @PrePassivate and @PostActivate lifecycle callback methods and @Remove methods.
Stateful Session Beans maintain state, that is, they store data or information about a given client that has invoked them. SFSB clients can be anywhere, but all of that data about all of those clients has to be stored somewhere, and since a SFSB is a server side component, it's that application server, or more accurately, the EJB container, that must maintain all of this information about conversational clients.
Of course, if there are loads of clients invoking stateful session beans, then there's going to be loads of data to be stored on the server. To minimize the stress maintaining stateful clients places on an application server, the EJB container is allowed to take a Stateful Session Bean out of memory, and temporarily store the state of that SFSB until the client to which it is tied requests its services again. The process of storing the state of a Stateful Session Bean is known as passivation.
Of course, if the state of a bean is temporarily taken out of memory and places in some sort of persistence store, well, the time will come where the reverse will happen, that is, the EJB container must reassemble the SFSB, or un-passivate it. The process of un-passivating a Stateful Session Bean is known as activation.
For the most part, an EJB container doesn't have any problems passivating and subsequently activating Stateful Session Beans, especially if they are simply composed of primitive types and Serializable objects. However, if you've put some strange, fancy-dancy data type into your SFSB, and the JVM has no idea how to store or retrieve this crazy type of data, well, you're going to have to do some fancy footwork when the EJB container both passivates and activates your Stateful Session Bean.
To take evasive action when the EJB container is about to passivate your SFSB, all you have to do is write a method that performs your fancy footwork, and decorate that method with the @PrePassivate annotation.
To help the EJB container re-construct your Stateful Session Bean when the passivated bean is activated, you simply write your supporting code into a standard Java method, and then decorate that method with the @PostActivate annotation.
The semantics of PrePassivate and PostActivate are the same as the EJB 2.1 ejbActivate and ejbPassivate callback methods.
Stateful Session Bean Removal
The Remove annotation may be used to annotate a stateful session bean business method. Use of this annotation will cause the container to remove the stateful session bean instance after the completion (normal or abnormal) of the annotated method.
-pg 30 EJB 3.0 Simplified API
Stateful Session Beans maintain state, that is, they store data or information about a given client that has invoked them. SFSB clients can be anywhere, but all of that data about all of those clients has to be stored somewhere, and since a SFSB is a server side component, it's that application server, or more accurately, the EJB container, that must maintain all of this information about conversational clients.
Of course, if there are loads of clients invoking stateful session beans, then there's going to be loads of data to be stored on the server. To minimize the stress maintaining stateful clients places on an application server, the EJB container is allowed to take a Stateful Session Bean out of memory, and temporarily store the state of that SFSB until the client to which it is tied requests its services again. The process of storing the state of a Stateful Session Bean is known as passivation.
Of course, if the state of a bean is temporarily taken out of memory and places in some sort of persistence store, well, the time will come where the reverse will happen, that is, the EJB container must reassemble the SFSB, or un-passivate it. The process of un-passivating a Stateful Session Bean is known as activation.
For the most part, an EJB container doesn't have any problems passivating and subsequently activating Stateful Session Beans, especially if they are simply composed of primitive types and Serializable objects. However, if you've put some strange, fancy-dancy data type into your SFSB, and the JVM has no idea how to store or retrieve this crazy type of data, well, you're going to have to do some fancy footwork when the EJB container both passivates and activates your Stateful Session Bean.
To take evasive action when the EJB container is about to passivate your SFSB, all you have to do is write a method that performs your fancy footwork, and decorate that method with the @PrePassivate annotation.
To help the EJB container re-construct your Stateful Session Bean when the passivated bean is activated, you simply write your supporting code into a standard Java method, and then decorate that method with the @PostActivate annotation.
The semantics of PrePassivate and PostActivate are the same as the EJB 2.1 ejbActivate and ejbPassivate callback methods.
Stateful Session Bean Removal
The Remove annotation may be used to annotate a stateful session bean business method. Use of this annotation will cause the container to remove the stateful session bean instance after the completion (normal or abnormal) of the annotated method.
-pg 30 EJB 3.0 Simplified API
Identify correct and incorrect statements or examples about remote and local business interfaces for Session Beans SCBCD Exam Objective
Identify correct and incorrect statements or examples about remote and local business interfaces for Session Beans
For this objective, you need to know the obvious - that remote EJB clients go through a remote interface, and clients running on the same JVM as the EJB they are invoking can go through a local interface. Of course, there's nothing stopping a client on the same JVM using a remote interface, but it does seem a little excessive.
For Remote interfaces, they are used exactly the same way, regardless of whether the client is actually remote, or if the client is right there on the same JVM. This can't really be said for local EJB interfaces.
"Access to an enterprise bean through the local client view requires the collocation in the same JVM ofboth the local client and the enterprise bean that provides the local client view. The local client viewtherefore does not provide the location transparency provided by the remote client view."
What else?
3.0 EJBs do not need Home interfaces. Home interfaces are part of EJB 2.1, and not needed for EJB3, unless that is, you want to maintain backwards compatibility. Home interfaces are not required by 3.0 EJBs, but the Home interface is still there in the specification. We always want to try and maintain backwards compatability!
Page 41 of the EJB 3.0 Core Contracts pdf document states the following about Remote Interfaces:
"In EJB 3.0, a remote client accesses a session bean through the bean’s remote business interface. For a session bean client and component written to the EJB 2.1 and earlier APIs, the remote client accesses the session bean through the session bean’s remote home and remote component interfaces.
Compatibility Note: The EJB 2.1 and earlier API required that a remote client access the session bean by means of the session bean’s remote home and remote component interfaces. These interfaces remain available for use with EJB 3.0, and are described in Section 3.6.
The remote client view of an enterprise bean is location independent. A client running in the same JVM as a bean instance uses the same API to access the bean as a client running in a different JVM on the same or different machine.
The arguments and results of the methods of the remote business interface are passed by value."
One thing to note about local interfaces is that they pass their arguments by reference, rather than by value as happens through the remote interface. This can really mess up a developer, especially if they are providing both a local and remote interface for an EJB. As such, developers should take the argument passing mechanism into account when they code their applications.
"The Bean Provider must be aware of the potential sharing of objects passed through local interfaces. In particular, the Bean Provider must be careful that the state of one enterprise bean is not assigned as the state of another. In general, the references that are passed across local interfaces cannot be used outside of the immediate call chain and must never be stored as part of the state of another enterprise bean. The Bean Provider must also exercise caution in determining which objects to pass across local interfaces. This caution applies particularly in
the case where there is a change in transaction or security context."
-pg 42 EJB Core Contracts Document
For this objective, you need to know the obvious - that remote EJB clients go through a remote interface, and clients running on the same JVM as the EJB they are invoking can go through a local interface. Of course, there's nothing stopping a client on the same JVM using a remote interface, but it does seem a little excessive.
For Remote interfaces, they are used exactly the same way, regardless of whether the client is actually remote, or if the client is right there on the same JVM. This can't really be said for local EJB interfaces.
"Access to an enterprise bean through the local client view requires the collocation in the same JVM ofboth the local client and the enterprise bean that provides the local client view. The local client viewtherefore does not provide the location transparency provided by the remote client view."
What else?
3.0 EJBs do not need Home interfaces. Home interfaces are part of EJB 2.1, and not needed for EJB3, unless that is, you want to maintain backwards compatibility. Home interfaces are not required by 3.0 EJBs, but the Home interface is still there in the specification. We always want to try and maintain backwards compatability!
Page 41 of the EJB 3.0 Core Contracts pdf document states the following about Remote Interfaces:
"In EJB 3.0, a remote client accesses a session bean through the bean’s remote business interface. For a session bean client and component written to the EJB 2.1 and earlier APIs, the remote client accesses the session bean through the session bean’s remote home and remote component interfaces.
Compatibility Note: The EJB 2.1 and earlier API required that a remote client access the session bean by means of the session bean’s remote home and remote component interfaces. These interfaces remain available for use with EJB 3.0, and are described in Section 3.6.
The remote client view of an enterprise bean is location independent. A client running in the same JVM as a bean instance uses the same API to access the bean as a client running in a different JVM on the same or different machine.
The arguments and results of the methods of the remote business interface are passed by value."
One thing to note about local interfaces is that they pass their arguments by reference, rather than by value as happens through the remote interface. This can really mess up a developer, especially if they are providing both a local and remote interface for an EJB. As such, developers should take the argument passing mechanism into account when they code their applications.
"The Bean Provider must be aware of the potential sharing of objects passed through local interfaces. In particular, the Bean Provider must be careful that the state of one enterprise bean is not assigned as the state of another. In general, the references that are passed across local interfaces cannot be used outside of the immediate call chain and must never be stored as part of the state of another enterprise bean. The Bean Provider must also exercise caution in determining which objects to pass across local interfaces. This caution applies particularly in
the case where there is a change in transaction or security context."
-pg 42 EJB Core Contracts Document
Identify correct and incorrect statements or examples that compare the purpose and use of Stateful and Stateless Session Beans SCBCD
Identify correct and incorrect statements or examples that compare the purpose and use of Stateful and Stateless Session Beans
Once again, the EJB 3.0 Core Contracts document does a pretty good job at describing exactly what a Session bean is:
Session Objects
A typical session object has the following characteristics:
• Executes on behalf of a single client.
• Can be transaction-aware.
• Updates shared data in an underlying database.
• Does not represent directly shared data in the database, although it may access and update such data.
• Is relatively short-lived.
• Is removed when the EJB container crashes. The client has to re-establish a new session objectto continue computation.
A typical EJB container provides a scalable runtime environment to execute a large number of session objects concurrently.
The EJB specification defines both stateful and stateless session beans. There are differences in the API between stateful session beans and stateless session beans.
Page 83 of the EJB Core Contract document goes into more detail on Stateless Session Beans in EJB3.0:
Stateless Session Beans
Stateless session beans are session beans whose instances have no conversational state. This means that all bean instances are equivalent when they are not involved in servicing a client invoked method. The term stateless signifies that an instance has no state for a specific client. However, the instance variables of the instance can contain the state across client-invoked method calls. Examples of such state include an open database connection and an object reference to an enterprise bean object.
The Bean Provider must exercise caution if retaining any application state across method calls. In particular, references to common bean state should not be returned through multiple local interface method calls.
Because all instances of a stateless session bean are equivalent, the container can choose to delegate a client-invoked method to any available instance. This means, for example, that the container may delegate the requests from the same client within the same transaction to different instances, and that the container may interleave requests from multiple transactions to the same instance.
A container only needs to retain the number of instances required to service the current client load. Due to client think time, this number is typically much smaller than the number of active clients. Passivaion is not needed or used for stateless sessions. The container creates another stateless session bean instance if one is needed to handle an increase in client work load. If a stateless session bean is not needed to handle the current client work load, the container can destroy it. Because stateless session beans minimize the resources needed to support a large population of clients, depending on the implementation of the container, applications that use stateless session beans may scale somewhat better than those using stateful session beans. However, this benefit may be offset by the increased complexity of the client application that uses the stateless beans.
Compatibility Note: Local and remote clients using the EJB 2.1 client view interfaces use the create and remove methods on the home interface of a stateless session bean in the same way as on a stateful session bean. To the EJB 2.1 client, it appears as if the client controls the life cycle of the session object.
However, the container handles the create and remove calls without necessarily creating and removing an EJB instance. The home interface of a stateless session bean must have one create method that takes no arguments. The create method of the remote home interface must return the session bean’s remote interface. The create method of the local home interface must return the session bean’s local interface. There can be no other create methods in the home interface. There is no fixed mapping between clients and stateless instances. The container simply delegates a client’s work to any available instance that is method-ready. A stateless session bean must not implement the javax.ejb.SessionSynchronization interace.
There's also a little bit of good information on Stateful Session Bean EJBs:
• stateful—the session bean instances contain conversational state which must be retained across methods and transactions
Once again, the EJB 3.0 Core Contracts document does a pretty good job at describing exactly what a Session bean is:
Session Objects
A typical session object has the following characteristics:
• Executes on behalf of a single client.
• Can be transaction-aware.
• Updates shared data in an underlying database.
• Does not represent directly shared data in the database, although it may access and update such data.
• Is relatively short-lived.
• Is removed when the EJB container crashes. The client has to re-establish a new session objectto continue computation.
A typical EJB container provides a scalable runtime environment to execute a large number of session objects concurrently.
The EJB specification defines both stateful and stateless session beans. There are differences in the API between stateful session beans and stateless session beans.
Page 83 of the EJB Core Contract document goes into more detail on Stateless Session Beans in EJB3.0:
Stateless Session Beans
Stateless session beans are session beans whose instances have no conversational state. This means that all bean instances are equivalent when they are not involved in servicing a client invoked method. The term stateless signifies that an instance has no state for a specific client. However, the instance variables of the instance can contain the state across client-invoked method calls. Examples of such state include an open database connection and an object reference to an enterprise bean object.
The Bean Provider must exercise caution if retaining any application state across method calls. In particular, references to common bean state should not be returned through multiple local interface method calls.
Because all instances of a stateless session bean are equivalent, the container can choose to delegate a client-invoked method to any available instance. This means, for example, that the container may delegate the requests from the same client within the same transaction to different instances, and that the container may interleave requests from multiple transactions to the same instance.
A container only needs to retain the number of instances required to service the current client load. Due to client think time, this number is typically much smaller than the number of active clients. Passivaion is not needed or used for stateless sessions. The container creates another stateless session bean instance if one is needed to handle an increase in client work load. If a stateless session bean is not needed to handle the current client work load, the container can destroy it. Because stateless session beans minimize the resources needed to support a large population of clients, depending on the implementation of the container, applications that use stateless session beans may scale somewhat better than those using stateful session beans. However, this benefit may be offset by the increased complexity of the client application that uses the stateless beans.
Compatibility Note: Local and remote clients using the EJB 2.1 client view interfaces use the create and remove methods on the home interface of a stateless session bean in the same way as on a stateful session bean. To the EJB 2.1 client, it appears as if the client controls the life cycle of the session object.
However, the container handles the create and remove calls without necessarily creating and removing an EJB instance. The home interface of a stateless session bean must have one create method that takes no arguments. The create method of the remote home interface must return the session bean’s remote interface. The create method of the local home interface must return the session bean’s local interface. There can be no other create methods in the home interface. There is no fixed mapping between clients and stateless instances. The container simply delegates a client’s work to any available instance that is method-ready. A stateless session bean must not implement the javax.ejb.SessionSynchronization interace.
There's also a little bit of good information on Stateful Session Bean EJBs:
• stateful—the session bean instances contain conversational state which must be retained across methods and transactions
Write code for the bean classes of Stateful and Stateless Session Beans SCBCD Exam Objective
Write code for the bean classes of Stateful and Stateless Session Beans.
The new EJB 3.0 specification makes developing and designing enterprise components easier and simpler than ever.
The best place to start designing EJBs is with Session beans. There’s really three types of EJBs: Session Beans, Entity Beans and Message Driven beans. Entity Beans save data to a persistence store, such as a database. Message driven beans read messages off of a queue or topic. Session beans? Well, they’re the EJBs that aren’t Entity Beans or Message Driven Beans. J
A tongue in cheek definition for sure, but it’s not all that far from the truth. If you have an enterprise component, something that might need to be invoked by remote clients, might have concurrency issues under a heavy load, or simply needs the server side, enterprise scalability that deployment to an EJB container provides, while of course, not being an entity bean or a message driven bean, well, that’s a Session EJB.
Session Beans can be divided into one of two categories: Stateful Session Beans (SFSBs) or Stateless Session Beans (SLSB). I always liked calling them American Beans, or Canadian Beans, because America has lots of States, and Canada doesn’t have any (it has provinces), but that naming convention never really caught on, so SLSB and SFSL will remain the accepted nomenclature for the timebeing. Basically, Stateful Session beans maintain a conversational state with the client, and Stateful Session Beans don’t. A more Java centric definition might be to say that Statefule Session beans have meaningful instance variables that are associated with a given client, whereas Stateless Session beans do not. Of course, I could try and describe the differences between Stateful Session Beans and StatelessSession Beans using big words and descriptive definitions, but in my world, a good example is always the better way to go.
Take a look at this Java class. It’s simply a home-made Timer. It can stop, it can start, and once it’s been started, it can tell you how much time has elapsed since starting it. It’s not going to win anyone a programmer of the year title, but it’s a good class, it’s a simple class, and it will be absolutely perfect for exploring Session beans, and the subtle distinction between a Stateful Session Bean and a Stateless Session Bean.
Take a look at the following Java class:
package com.mcnz;
public class Timer {
private long startTime;
public Timer() {}
public void start(){
startTime = System.currentTimeMillis();
}
public long getStartTime() {
return startTime;
}
public long getElapsedTime() {
return System.currentTimeMillis() - startTime;
}
public boolean isStarted() {
if (startTime == 0 ){return false;}
else {return true;}
}
}
It’s a Timer, as you could probably gather from the name of the class. It’s a simple class, with one instance variable of type long that keeps track of when the Timer is started, it has a default constructor that doesn’t really do anything other than look pretty, it has a getter method for the startTime instance variable, and it has a little getElapsedTime method that tells you how long it has been since the timer was started. Oh yeah, and I just threw in a little isStarted method that can tell you whether the timer has been started or not. Basically, if the instance variable has a value of zero, the Timer hasn’t been started.
I like this little class because it’s simple and stratight forward, conceptually it’s fairly easy to comprehend, and from a Java standpoint, it combines a good mix method signatures, with one returning a Boolean, two returning longs, a void method, and even a cute little default constructor. This is a great little class with which to work.
I’m just going to throw this little Timer class into a runnable class named TimerTester. It’s just going to iterate through a loop a bunch of times and print out how long it took to iterate through the loop – it’s all, simple, Introudction to Java type of stuff:
package com.mcnz;
public class TimerTester {
public static void main(String[] args) {
Timer t = new Timer();
t.start();
for (int i = 0; i<100; i++){
System.out.print(":"+t.getElapsedTime());
}
System.out.print("\nTotal Time: " + t.getElapsedTime());
}
}
When I run this program, get output that looks something like this:
:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20
Total Time: 20
Man, those IBM Thinkpads are fast! 100 iterations only took about 20 milliseconds. J
Unfortunately, all of the time spent on the Timer class and the TimerTester hasn’t advanced our knowledge of Enterprise Java programming one, little, iota. Everything we’ve done so far leverages nothing more than the Standard Java Development ToolKit (SDK), and you certainly don’t need the facilities of an EJB container to run this code. This code could run on any computer that has a standard, Java Runtime Environment installed.
BUT…
Let’s just say that our Timer was becoming extremely popular. And not only was it popular, but its services were being required by a large number of applications, not only for logging, but for monitoring, performance, and basic information feedback about how applications were running. Furthermore, perhaps many applications were needing the technical facilities provided by the Timer class, many different types of applications were using the Timer, from stand-alone Java applications, to Servlets, JSPs, and potentially, even other EJBs. And let’s also say that we wanted to optimize our hardware utilization, so instead of wasting clock cycles on stand-alone client machines, or other web servers or Servlet engines, we wanted to run the Timer class on high performance, dedicated server hardware that would redue the client load and make scalability and concurrency much easier to manage. Well, if that was the case, we’d want to throw away the Timer class that runs in a stand-alone mode in a single Java Runtime Environment (JRE), and instead, morph our existing Timer class into a exceptionally talented Enterprise Java Bean.
So, how would our Timer morph into an EJB? Well, first of all, it doesn’t map to a database table, and it doesn’t read any data from a Queue, so it’s not an Entity Bean or a Message Driven Bean. Our Timer is definitely a Session Bean EJB candidate. And of course, Session Beans can fall into one of two categories: Stateful Session Beans or Stateless Session Beans, and since our Timer class does have an instance variable, the startTime of type long, and since the instance variable can take on different values depending on which client is invoking it, we have to conclude that our Timer class would best fit into the mold of a Stateful Session EJB.
So, how does a normal, innocuous, simple JavaBean transition itself into an Enterprise Java Bean? Well, it’s amazingly simple, especially with EJB 3.0.
For me, the toughest part of turning my Timer class into an EJB is changing the name of the Timer class to StatefulTimerBean, and a corresponding change of the constructor from Timer() to StatefulTimerBean(). A quick change of the package name from com.mcnz to com.mcnz.ejb is another little razzle-dazzle change that I’ve made. Also, you’ll notice the added import statement bringing in javax.ejb.*;
The new EJB 3.0 specification makes developing and designing enterprise components easier and simpler than ever.
The best place to start designing EJBs is with Session beans. There’s really three types of EJBs: Session Beans, Entity Beans and Message Driven beans. Entity Beans save data to a persistence store, such as a database. Message driven beans read messages off of a queue or topic. Session beans? Well, they’re the EJBs that aren’t Entity Beans or Message Driven Beans. J
A tongue in cheek definition for sure, but it’s not all that far from the truth. If you have an enterprise component, something that might need to be invoked by remote clients, might have concurrency issues under a heavy load, or simply needs the server side, enterprise scalability that deployment to an EJB container provides, while of course, not being an entity bean or a message driven bean, well, that’s a Session EJB.
Session Beans can be divided into one of two categories: Stateful Session Beans (SFSBs) or Stateless Session Beans (SLSB). I always liked calling them American Beans, or Canadian Beans, because America has lots of States, and Canada doesn’t have any (it has provinces), but that naming convention never really caught on, so SLSB and SFSL will remain the accepted nomenclature for the timebeing. Basically, Stateful Session beans maintain a conversational state with the client, and Stateful Session Beans don’t. A more Java centric definition might be to say that Statefule Session beans have meaningful instance variables that are associated with a given client, whereas Stateless Session beans do not. Of course, I could try and describe the differences between Stateful Session Beans and StatelessSession Beans using big words and descriptive definitions, but in my world, a good example is always the better way to go.
Take a look at this Java class. It’s simply a home-made Timer. It can stop, it can start, and once it’s been started, it can tell you how much time has elapsed since starting it. It’s not going to win anyone a programmer of the year title, but it’s a good class, it’s a simple class, and it will be absolutely perfect for exploring Session beans, and the subtle distinction between a Stateful Session Bean and a Stateless Session Bean.
Take a look at the following Java class:
package com.mcnz;
public class Timer {
private long startTime;
public Timer() {}
public void start(){
startTime = System.currentTimeMillis();
}
public long getStartTime() {
return startTime;
}
public long getElapsedTime() {
return System.currentTimeMillis() - startTime;
}
public boolean isStarted() {
if (startTime == 0 ){return false;}
else {return true;}
}
}
It’s a Timer, as you could probably gather from the name of the class. It’s a simple class, with one instance variable of type long that keeps track of when the Timer is started, it has a default constructor that doesn’t really do anything other than look pretty, it has a getter method for the startTime instance variable, and it has a little getElapsedTime method that tells you how long it has been since the timer was started. Oh yeah, and I just threw in a little isStarted method that can tell you whether the timer has been started or not. Basically, if the instance variable has a value of zero, the Timer hasn’t been started.
I like this little class because it’s simple and stratight forward, conceptually it’s fairly easy to comprehend, and from a Java standpoint, it combines a good mix method signatures, with one returning a Boolean, two returning longs, a void method, and even a cute little default constructor. This is a great little class with which to work.
I’m just going to throw this little Timer class into a runnable class named TimerTester. It’s just going to iterate through a loop a bunch of times and print out how long it took to iterate through the loop – it’s all, simple, Introudction to Java type of stuff:
package com.mcnz;
public class TimerTester {
public static void main(String[] args) {
Timer t = new Timer();
t.start();
for (int i = 0; i<100; i++){
System.out.print(":"+t.getElapsedTime());
}
System.out.print("\nTotal Time: " + t.getElapsedTime());
}
}
When I run this program, get output that looks something like this:
:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:10:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20:20
Total Time: 20
Man, those IBM Thinkpads are fast! 100 iterations only took about 20 milliseconds. J
Unfortunately, all of the time spent on the Timer class and the TimerTester hasn’t advanced our knowledge of Enterprise Java programming one, little, iota. Everything we’ve done so far leverages nothing more than the Standard Java Development ToolKit (SDK), and you certainly don’t need the facilities of an EJB container to run this code. This code could run on any computer that has a standard, Java Runtime Environment installed.
BUT…
Let’s just say that our Timer was becoming extremely popular. And not only was it popular, but its services were being required by a large number of applications, not only for logging, but for monitoring, performance, and basic information feedback about how applications were running. Furthermore, perhaps many applications were needing the technical facilities provided by the Timer class, many different types of applications were using the Timer, from stand-alone Java applications, to Servlets, JSPs, and potentially, even other EJBs. And let’s also say that we wanted to optimize our hardware utilization, so instead of wasting clock cycles on stand-alone client machines, or other web servers or Servlet engines, we wanted to run the Timer class on high performance, dedicated server hardware that would redue the client load and make scalability and concurrency much easier to manage. Well, if that was the case, we’d want to throw away the Timer class that runs in a stand-alone mode in a single Java Runtime Environment (JRE), and instead, morph our existing Timer class into a exceptionally talented Enterprise Java Bean.
So, how would our Timer morph into an EJB? Well, first of all, it doesn’t map to a database table, and it doesn’t read any data from a Queue, so it’s not an Entity Bean or a Message Driven Bean. Our Timer is definitely a Session Bean EJB candidate. And of course, Session Beans can fall into one of two categories: Stateful Session Beans or Stateless Session Beans, and since our Timer class does have an instance variable, the startTime of type long, and since the instance variable can take on different values depending on which client is invoking it, we have to conclude that our Timer class would best fit into the mold of a Stateful Session EJB.
So, how does a normal, innocuous, simple JavaBean transition itself into an Enterprise Java Bean? Well, it’s amazingly simple, especially with EJB 3.0.
For me, the toughest part of turning my Timer class into an EJB is changing the name of the Timer class to StatefulTimerBean, and a corresponding change of the constructor from Timer() to StatefulTimerBean(). A quick change of the package name from com.mcnz to com.mcnz.ejb is another little razzle-dazzle change that I’ve made. Also, you’ll notice the added import statement bringing in javax.ejb.*;
Tuesday, August 26, 2008
Describe the packaging and deployment requirements for enterprise beans - Sun SCBCD Exam Objective EJB3 JEE5
Objective: Describe the packaging and deployment requirements for enterprise beans
Chapter 20 of the JEE5 EJB Core Contracts document fairly succinctly describes how EJB3 applications must be packaged and deployed. Basically, Enterprise JavaBean applications should be deployed at ejb-jar files.
"The ejb-jar file format is the contract between the Bean Provider and the Application Assembler, and between the Application Assembler and the Deployer. An ejb-jar file produced by the Bean Provider contains one or more enterprise beans that typically do not contain application assembly instructions. The ejb-jar file produced by an Application Assembler (which can be the same person or organization as the Bean Provider) contains one or more enterprise beans, plus application assembly information describing how the enterprise beans are combined into a single application deployment unit.
The ejb-jar file must contain the deployment descriptor (if any) in the format defined in Chapter 19. The deployment descriptor must be stored with the name META-INF/ejb-jar.xml in the ejb-jar file.
The ejb-jar file must contain, either by inclusion or by reference, the class files of each enterprise bean as follows:
• The enterprise bean class.
• The enterprise bean business interfaces, web service endpoint interfaces, and home and com-
ponent interfaces.
• Interceptor classes.
• The primary key class if the bean is an entity bean.
We say that a jar file contains a second file “by reference” if the second file is named in the Class-Path attribute in the Manifest file of the referencing jar file or is contained (either by inclusion or by reference) in another jar file that is named in the Class-Path attribute in the Manifest file of the referencing jar file.
The ejb-jar file must also contain, either by inclusion or by reference, the class files for all the classes and interfaces that each enterprise bean class and the home interfaces, component interfaces, and/or web service endpoints depend on, except Java EE and J2SE classes. This includes their superclasses and superinterfaces, dependent classes, and the classes and interfaces used as method parameters, results, and exceptions.
The Application Assembler must not package the stubs of the EJBHome and EJBObject interfaces in the ejb-jar file. This includes the stubs for the enterprise beans whose implementations are provided in the ejb-jar file as well as the referenced enterprise beans. Generating the stubs is the responsibility of the container. The stubs are typically generated by the Container Provider’s deployment tools for each class that extends the EJBHome or EJBObject interfaces, or they may be generated by the container at runtime."
-From Chapter 20, EJB Core Contracts Docuement
Chapter 20 of the JEE5 EJB Core Contracts document fairly succinctly describes how EJB3 applications must be packaged and deployed. Basically, Enterprise JavaBean applications should be deployed at ejb-jar files.
"The ejb-jar file format is the contract between the Bean Provider and the Application Assembler, and between the Application Assembler and the Deployer. An ejb-jar file produced by the Bean Provider contains one or more enterprise beans that typically do not contain application assembly instructions. The ejb-jar file produced by an Application Assembler (which can be the same person or organization as the Bean Provider) contains one or more enterprise beans, plus application assembly information describing how the enterprise beans are combined into a single application deployment unit.
The ejb-jar file must contain the deployment descriptor (if any) in the format defined in Chapter 19. The deployment descriptor must be stored with the name META-INF/ejb-jar.xml in the ejb-jar file.
The ejb-jar file must contain, either by inclusion or by reference, the class files of each enterprise bean as follows:
• The enterprise bean class.
• The enterprise bean business interfaces, web service endpoint interfaces, and home and com-
ponent interfaces.
• Interceptor classes.
• The primary key class if the bean is an entity bean.
We say that a jar file contains a second file “by reference” if the second file is named in the Class-Path attribute in the Manifest file of the referencing jar file or is contained (either by inclusion or by reference) in another jar file that is named in the Class-Path attribute in the Manifest file of the referencing jar file.
The ejb-jar file must also contain, either by inclusion or by reference, the class files for all the classes and interfaces that each enterprise bean class and the home interfaces, component interfaces, and/or web service endpoints depend on, except Java EE and J2SE classes. This includes their superclasses and superinterfaces, dependent classes, and the classes and interfaces used as method parameters, results, and exceptions.
The Application Assembler must not package the stubs of the EJBHome and EJBObject interfaces in the ejb-jar file. This includes the stubs for the enterprise beans whose implementations are provided in the ejb-jar file as well as the referenced enterprise beans. Generating the stubs is the responsibility of the container. The stubs are typically generated by the Container Provider’s deployment tools for each class that extends the EJBHome or EJBObject interfaces, or they may be generated by the container at runtime."
-From Chapter 20, EJB Core Contracts Docuement
Describe the purposes and uses of annotations and deployment descriptors - SCBCD Exam Objective EJB3 JEE5
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.
One of the things you've got to know about this objective is that deployment descriptors override annotations, so if there is a conflict between the two, the deployment descriptor wins. This makes it possible for developers to create components that work in a typical use, but can be customized for their particular environment at deployment time.
Also, annotations can be put on properties, or getters for the properties, but the two styles can't be mixed within the same class. At least, that was my experience with Hibernate - I can't think of why it would be any different in an EJB3.0 environment. I'll test it out, though.
Metadata Annotations and Deployment Descriptors
"One of the key enabling technologies introduced by J2SE 5.0 is the program annotation facility defined by JSR-175 [10]. This facility allows developers to annotate program elements in Java programming language source files to control the behavior and deployment of an application. Metadata annotations are a key element in the simplification of the development of EJB 3.0 applications. Metadata annotations are used by the developer to specify expected requirements on container behavior, to request the injection of services and resources, and to specify object/relational mappings. Metadata annotations may be used as an alternative to the deployment descriptors that were required by earlier versions of the Enterprise JavaBeans specification. While this document is written in terms of the usage of metadata annotations, it is not required that metadata annotations be used in an EJB 3.0 application. Developers who prefer the use of a deployment descriptor as an alternative to metadata annotations may define one for this purpose. The EJB 3.0 deployment descriptor is defined in the document “EJB Core Contracts and Requirements” [1] of this specification.
Deployment Descriptors
Deployment descriptors are defined by this specification as an alternative to metadata annotations or as a mechanism for the overriding of metadata annotations—for example to permit the further customization of an application for a particular development environment at a later stage of the development or assembly work flow. Deployment descriptors may be “sparse”, unlike the full deployment descriptors required by the EJB 2.1 specification. See “EJB Core Contracts and Requirements” [1]. Although it is not anticipated as a typical use case, it is possible for the application developer to combine the use of metadata annotations and deployment descriptors in the design of an application. When such a combination is used, the rules for the use of deployment descriptors as an overriding mechanism apply."
One of the things you've got to know about this objective is that deployment descriptors override annotations, so if there is a conflict between the two, the deployment descriptor wins. This makes it possible for developers to create components that work in a typical use, but can be customized for their particular environment at deployment time.
Also, annotations can be put on properties, or getters for the properties, but the two styles can't be mixed within the same class. At least, that was my experience with Hibernate - I can't think of why it would be any different in an EJB3.0 environment. I'll test it out, though.
Metadata Annotations and Deployment Descriptors
"One of the key enabling technologies introduced by J2SE 5.0 is the program annotation facility defined by JSR-175 [10]. This facility allows developers to annotate program elements in Java programming language source files to control the behavior and deployment of an application. Metadata annotations are a key element in the simplification of the development of EJB 3.0 applications. Metadata annotations are used by the developer to specify expected requirements on container behavior, to request the injection of services and resources, and to specify object/relational mappings. Metadata annotations may be used as an alternative to the deployment descriptors that were required by earlier versions of the Enterprise JavaBeans specification. While this document is written in terms of the usage of metadata annotations, it is not required that metadata annotations be used in an EJB 3.0 application. Developers who prefer the use of a deployment descriptor as an alternative to metadata annotations may define one for this purpose. The EJB 3.0 deployment descriptor is defined in the document “EJB Core Contracts and Requirements” [1] of this specification.
Deployment Descriptors
Deployment descriptors are defined by this specification as an alternative to metadata annotations or as a mechanism for the overriding of metadata annotations—for example to permit the further customization of an application for a particular development environment at a later stage of the development or assembly work flow. Deployment descriptors may be “sparse”, unlike the full deployment descriptors required by the EJB 2.1 specification. See “EJB Core Contracts and Requirements” [1]. Although it is not anticipated as a typical use case, it is possible for the application developer to combine the use of metadata annotations and deployment descriptors in the design of an application. When such a combination is used, the rules for the use of deployment descriptors as an overriding mechanism apply."
Match the seven EJB roles with the corresponding description of the role's responsibilities SCBCD Exam Objective.
Match the seven EJB roles with the corresponding description of the role's responsibilities
I've never understood the infatuation with JEE roles and such. I get the feeling that someone spent alot of time thinking these role things up, and nobody's had the guts to pull it out of the specification. I don't know. I guess being able to categorize the various hats people have to wear to bring a JEE EJB 3.0 application to fruition. It must have some value somewhere.
The seven EJB roles involved in bringing a JEE EJB application to fruition include:
Enterprise Bean Provider
Application Assembler
Deployer
EJB Server Provider
EJB Container Provider
Persistence Provider
System Administrator
The Enterprise JavaBeans architecture defines seven distinct roles in the application development deployment life cycle. Each EJB Role may be performed by a different party. The EJB architecture specifies the contracts that ensure that the product of each EJB Role is compatible with the product of the other EJB Roles. The EJB specification focuses on those contracts that are required to support the development and deployment of ISV-written enterprise beans. In some scenarios, a single party may perform several EJB Roles. For example, the Container Provider and the EJB Server Provider may be the same vendor. Or a single programmer may perform the two EJB Roles of the Enterprise Bean Provider and the Application Assembler. The following sections define the seven EJB Roles.
Enterprise Bean Provider
The Enterprise Bean Provider (Bean Provider for short) is the producer of enterprise beans. His or her output is an ejb-jar file that contains one or more enterprise beans. The Bean Provider is responsible for the Java classes that implement the enterprise beans’ business methods; the definition of the beans’ client view interfaces; and declarative specification of the beans’ metadata. The beans’ metadata may take the form of metadata annotations applied to the bean classes and/or an external XML deployment descriptor. The beans’ metadata—whether expressed in metadata annotations or in the deployment descriptor—includes the structural information of the enterprise beans and declares all the enterprise beans’ external dependencies (e.g. the names and types of resources that the enterprise beans use). The Enterprise Bean Provider is typically an application domain expert. The Bean Provider develops reusable enterprise beans that typically implement business tasks or business entities. The Bean Provider is not required to be an expert at system-level programming. Therefore, the Bean Provider usually does not program transactions, concurrency, security, distribution, or other services into the enterprise beans. The Bean Provider relies on the EJB container for these services. A Bean Provider of multiple enterprise beans often performs the EJB Role of the Application Assembler.
Application Assembler
The Application Assembler combines enterprise beans into larger deployable application units. The input to the Application Assembler is one or more ejb-jar files produced by the Bean Provider(s). The Application Assembler outputs one or more ejb-jar files that contain the enterprise beans along with their application assembly instructions. The Application Assembler can also combine enterprise beans with other types of application components when composing an application. The EJB specification describes the case in which the application assembly step occurs before the deployment of the enterprise beans. However, the EJB architecture does not preclude the case that application assembly is performed after the deployment of all or some of the enterprise beans. The Application Assembler is a domain expert who composes applications that use enterprise beans. The Application Assembler works with the enterprise bean’s metadata annotations and/or deployment descriptor and the enterprise bean’s client-view contract. Although the Assembler must be familiar with the functionality provided by the enterprise bean’s client-view interfaces, he or she does not need to have any knowledge of the enterprise bean’s implementation.
Deployer
The Deployer takes one or more ejb-jar files produced by a Bean Provider or Application Assembler and deploys the enterprise beans contained in the ejb-jar files in a specific operational environment. The operational environment includes a specific EJB server and container.
The Deployer must resolve all the external dependencies declared by the Bean Provider (e.g. the Deployer must ensure that all resource manager connection factories used by the enterprise beans are present in the operational environment, and he or she must bind them to the resource manager connection factory references declared in the metadata annotations or deployment descriptor), and must follow the application assembly instructions defined by the Application Assembler. To perform his or her role, the Deployer uses tools provided by the EJB Container Provider. The Deployer’s output is a set of enterprise beans (or an assembled application that includes enterprise beans) that have been customized for the target operational environment, and that are deployed in a specific EJB container.
The Deployer is an expert at a specific operational environment and is responsible for the deployment of enterprise beans. For example, the Deployer is responsible for mapping the security roles defined by the Bean Provider or Application Assembler to the user groups and accounts that exist in the operational environment in which the enterprise beans are deployed.
The Deployer uses tools supplied by the EJB Container Provider to perform the deployment tasks. The deployment process is typically two-stage:
• The Deployer first generates the additional classes and interfaces that enable the container to
manage the enterprise beans at runtime. These classes are container-specific.
• The Deployer performs the actual installation of the enterprise beans and the additional
classes and interfaces into the EJB container.
In some cases, a qualified Deployer may customize the business logic of the enterprise beans at their deployment. Such a Deployer would typically use the Container Provider’s tools to write relatively simple application code that wraps the enterprise bean’s business methods. EJB Server Provider
The EJB Server Provider is a specialist in the area of distributed transaction management, distributed objects, and other lower-level system-level services. A typical EJB Server Provider is an OS vendor, middleware vendor, or database vendor.
The current EJB architecture assumes that the EJB Server Provider and the EJB Container Provider roles are the same vendor. Therefore, it does not define any interface requirements for the EJB Server Provider.
EJB Container Provider
The EJB Container Provider (Container Provider for short) provides:
• The deployment tools necessary for the deployment of enterprise beans.
• The runtime support for the deployed enterprise bean instances.
From the perspective of the enterprise beans, the container is a part of the target operational environment. The container runtime provides the deployed enterprise beans with transaction and security management, network distribution of remote clients, scalable management of resources, and other services that are generally required as part of a manageable server platform.
The “EJB Container Provider’s responsibilities” defined by the EJB architecture are meant to be requirements for the implementation of the EJB container and server. Since the EJB specification does not architect the interface between the EJB container and server, it is left up to the vendor how to split the implementation of the required functionality between the EJB container and server.
The expertise of the Container Provider is system-level programming, possibly combined with some application-domain expertise. The focus of a Container Provider is on the development of a scalable, secure, transaction-enabled container that is integrated with an EJB server. The Container Provider insulates the enterprise bean from the specifics of an underlying EJB server by providing a simple, stan- dard API between the enterprise bean and the container. This API is the Enterprise JavaBeans compo- nent contract.
The Container Provider typically provides support for versioning the installed enterprise bean components. For example, the Container Provider may allow enterprise bean classes to be upgraded without invalidating existing clients or losing existing enterprise bean objects. The Container Provider typically provides tools that allow the System Administrator to monitor and manage the container and the beans running in the container at runtime.
Persistence Provider
The expertise of the Persistence Provider is in object/relational mapping, query processing, and caching. The focus of the Persistence Provider is on the development of a scalable, transaction-enabled runtime environment for the management of persistence.
The Persistence Provider provides the tools necessary for the object/relational mapping of persistent entities to a relational database, and the runtime support for the management of persistent entities and their mapping to the database.
The Persistence Provider insulates the persistent entities from the specifics of the underlying persistence substrate, providing a standard API between the persistent entities and the object/relational runtime. The Persistence Provider may be the same vendor as the EJB Container vendor or the Persistence Provider may be a third-party vendor that provides a pluggable persistence environment as described.
System Administrator
The System Administrator is responsible for the configuration and administration of the enterprise’scomputing and networking infrastructure that includes the EJB server and container. The SystemAdministrator is also responsible for overseeing the well-being of the deployedenterprise beans appli-cations at runtime.
I've never understood the infatuation with JEE roles and such. I get the feeling that someone spent alot of time thinking these role things up, and nobody's had the guts to pull it out of the specification. I don't know. I guess being able to categorize the various hats people have to wear to bring a JEE EJB 3.0 application to fruition. It must have some value somewhere.
The seven EJB roles involved in bringing a JEE EJB application to fruition include:
Enterprise Bean Provider
Application Assembler
Deployer
EJB Server Provider
EJB Container Provider
Persistence Provider
System Administrator
The Enterprise JavaBeans architecture defines seven distinct roles in the application development deployment life cycle. Each EJB Role may be performed by a different party. The EJB architecture specifies the contracts that ensure that the product of each EJB Role is compatible with the product of the other EJB Roles. The EJB specification focuses on those contracts that are required to support the development and deployment of ISV-written enterprise beans. In some scenarios, a single party may perform several EJB Roles. For example, the Container Provider and the EJB Server Provider may be the same vendor. Or a single programmer may perform the two EJB Roles of the Enterprise Bean Provider and the Application Assembler. The following sections define the seven EJB Roles.
Enterprise Bean Provider
The Enterprise Bean Provider (Bean Provider for short) is the producer of enterprise beans. His or her output is an ejb-jar file that contains one or more enterprise beans. The Bean Provider is responsible for the Java classes that implement the enterprise beans’ business methods; the definition of the beans’ client view interfaces; and declarative specification of the beans’ metadata. The beans’ metadata may take the form of metadata annotations applied to the bean classes and/or an external XML deployment descriptor. The beans’ metadata—whether expressed in metadata annotations or in the deployment descriptor—includes the structural information of the enterprise beans and declares all the enterprise beans’ external dependencies (e.g. the names and types of resources that the enterprise beans use). The Enterprise Bean Provider is typically an application domain expert. The Bean Provider develops reusable enterprise beans that typically implement business tasks or business entities. The Bean Provider is not required to be an expert at system-level programming. Therefore, the Bean Provider usually does not program transactions, concurrency, security, distribution, or other services into the enterprise beans. The Bean Provider relies on the EJB container for these services. A Bean Provider of multiple enterprise beans often performs the EJB Role of the Application Assembler.
Application Assembler
The Application Assembler combines enterprise beans into larger deployable application units. The input to the Application Assembler is one or more ejb-jar files produced by the Bean Provider(s). The Application Assembler outputs one or more ejb-jar files that contain the enterprise beans along with their application assembly instructions. The Application Assembler can also combine enterprise beans with other types of application components when composing an application. The EJB specification describes the case in which the application assembly step occurs before the deployment of the enterprise beans. However, the EJB architecture does not preclude the case that application assembly is performed after the deployment of all or some of the enterprise beans. The Application Assembler is a domain expert who composes applications that use enterprise beans. The Application Assembler works with the enterprise bean’s metadata annotations and/or deployment descriptor and the enterprise bean’s client-view contract. Although the Assembler must be familiar with the functionality provided by the enterprise bean’s client-view interfaces, he or she does not need to have any knowledge of the enterprise bean’s implementation.
Deployer
The Deployer takes one or more ejb-jar files produced by a Bean Provider or Application Assembler and deploys the enterprise beans contained in the ejb-jar files in a specific operational environment. The operational environment includes a specific EJB server and container.
The Deployer must resolve all the external dependencies declared by the Bean Provider (e.g. the Deployer must ensure that all resource manager connection factories used by the enterprise beans are present in the operational environment, and he or she must bind them to the resource manager connection factory references declared in the metadata annotations or deployment descriptor), and must follow the application assembly instructions defined by the Application Assembler. To perform his or her role, the Deployer uses tools provided by the EJB Container Provider. The Deployer’s output is a set of enterprise beans (or an assembled application that includes enterprise beans) that have been customized for the target operational environment, and that are deployed in a specific EJB container.
The Deployer is an expert at a specific operational environment and is responsible for the deployment of enterprise beans. For example, the Deployer is responsible for mapping the security roles defined by the Bean Provider or Application Assembler to the user groups and accounts that exist in the operational environment in which the enterprise beans are deployed.
The Deployer uses tools supplied by the EJB Container Provider to perform the deployment tasks. The deployment process is typically two-stage:
• The Deployer first generates the additional classes and interfaces that enable the container to
manage the enterprise beans at runtime. These classes are container-specific.
• The Deployer performs the actual installation of the enterprise beans and the additional
classes and interfaces into the EJB container.
In some cases, a qualified Deployer may customize the business logic of the enterprise beans at their deployment. Such a Deployer would typically use the Container Provider’s tools to write relatively simple application code that wraps the enterprise bean’s business methods. EJB Server Provider
The EJB Server Provider is a specialist in the area of distributed transaction management, distributed objects, and other lower-level system-level services. A typical EJB Server Provider is an OS vendor, middleware vendor, or database vendor.
The current EJB architecture assumes that the EJB Server Provider and the EJB Container Provider roles are the same vendor. Therefore, it does not define any interface requirements for the EJB Server Provider.
EJB Container Provider
The EJB Container Provider (Container Provider for short) provides:
• The deployment tools necessary for the deployment of enterprise beans.
• The runtime support for the deployed enterprise bean instances.
From the perspective of the enterprise beans, the container is a part of the target operational environment. The container runtime provides the deployed enterprise beans with transaction and security management, network distribution of remote clients, scalable management of resources, and other services that are generally required as part of a manageable server platform.
The “EJB Container Provider’s responsibilities” defined by the EJB architecture are meant to be requirements for the implementation of the EJB container and server. Since the EJB specification does not architect the interface between the EJB container and server, it is left up to the vendor how to split the implementation of the required functionality between the EJB container and server.
The expertise of the Container Provider is system-level programming, possibly combined with some application-domain expertise. The focus of a Container Provider is on the development of a scalable, secure, transaction-enabled container that is integrated with an EJB server. The Container Provider insulates the enterprise bean from the specifics of an underlying EJB server by providing a simple, stan- dard API between the enterprise bean and the container. This API is the Enterprise JavaBeans compo- nent contract.
The Container Provider typically provides support for versioning the installed enterprise bean components. For example, the Container Provider may allow enterprise bean classes to be upgraded without invalidating existing clients or losing existing enterprise bean objects. The Container Provider typically provides tools that allow the System Administrator to monitor and manage the container and the beans running in the container at runtime.
Persistence Provider
The expertise of the Persistence Provider is in object/relational mapping, query processing, and caching. The focus of the Persistence Provider is on the development of a scalable, transaction-enabled runtime environment for the management of persistence.
The Persistence Provider provides the tools necessary for the object/relational mapping of persistent entities to a relational database, and the runtime support for the management of persistent entities and their mapping to the database.
The Persistence Provider insulates the persistent entities from the specifics of the underlying persistence substrate, providing a standard API between the persistent entities and the object/relational runtime. The Persistence Provider may be the same vendor as the EJB Container vendor or the Persistence Provider may be a third-party vendor that provides a pluggable persistence environment as described.
System Administrator
The System Administrator is responsible for the configuration and administration of the enterprise’scomputing and networking infrastructure that includes the EJB server and container. The SystemAdministrator is also responsible for overseeing the well-being of the deployedenterprise beans appli-cations at runtime.
Identify correct and incorrect statements or examples about EJB programming restrictions
The JEE5 container, in which EJBs run, provides a variety of services to our EJBs. Many of the burdens of creating enterprise components are relieved from the developer through the EJB container. For example, the whole lifecycle of an EJB is managed and controlled by the EJB container, so you never actually invoke the constructor on an EJB - after all, actually instantiating an EJB is the job of the container. And of course, EJBs are inherently multi-threaded, so we don't start trying to spin off new threads, and handle multi-threaded access within our EJBs either. These are the types of restrictions that Sun is talking about when they made this objective - they want to ensure that developers not only know how to use EJBs, but how not to use EJBs as well!
Page 116 of the Jave EE, JSR-244, lists a variety of programming restrictions, some of which apply to EJBs, with others applying to other JEE containers. It's a good read, and it will certainly help you understand what Sun is getting at when they penned this objective.
"The Java EE programming model divides responsibilities between Application Component Providers and Java EE Product Providers: Application Component Providers focus on writing business logic and the Java EE Product Providers focus on providing a managed system infrastructure in which the application components can be deployed. This division leads to a restriction on the functionality that application components can contain. If application components contain the same functionality provided by Java EE system infrastructure, there are clashes and mis-management of the functionality.For example, if enterprise beans were allowed to manage threads, the Java EE platform could not manage the life cycle of the enterprise beans, and it could not properly manage transactions.
Since we do not want to subset the J2SE platform, and we want Java EE Product Providers to be able to use J2SE products without modification in the Java EE platform, we use the J2SE security permissions mechanism to express the programming restrictions imposed on Application Component Providers. In this section, we specify the J2SE security permissions that the Java EE Product Provider must provide for each application component type. We call these permissions the Java EE security permissions set. The Java EE security permissions set is a required part of the Java EE API contract. Portable applications will rely on only the set of permissions specified here."
Java EE applications should not attempt to load JDBC drivers directly. Instead, they should use the technique recommended in the JDBC specification and perform a JNDI lookup to locate a DataSource object. The JNDI name of the DataSource object should be chosen as described in Section EE.5.6, “Resource Manager Connection Factory References.” The Java EE platform must be able to supply a DataSource that does not require the application to supply any authentication information when obtaining a database connection. Of course, applications may also supply a user name and password when connecting to the database.
When a JDBC API connection is used in an enterprise bean, the transaction characteristics will typically be controlled by the container. The component should not attempt to change the transaction characteristics of the connection, commit the transaction, roll back the transaction, or set autocommit mode. Attempts to make changes that are incompatible with the current transaction context may result in a SQLException being thrown. The EJB specification contains the precise rules for enterprise beans.
Support for the new BLOB, CLOB, ARRAY , REF, STRUCT, and JAVA_OBJECT types not required. All parameter types (IN, OUT, and INOUT) must be supported.
To allow this ORB instance to be safely shared between components, portable components must restrict their usage of certain ORB APIs and functionality:
• Do not call the ORB shutdown method.
• Do not call the org.omg.CORBA_2_3.ORB methods register_value_factory
and unregister_value_factory with an id used by the container.
The Preferences API in the java.util.prefs package allows applications to s and retrieve user and system preference and configuration data. A Java EE application typically will not have the RuntimePermission("preferences") necessary to use the Preferences API. This specification does not define any relationship between the principal used by a Java EE application and the user
The EJB container and the web container are both required to support access to local enterprise beans. No support is provided for access to local enterprise beans from the application client container or the applet container.
portable Java EE applications must not use the following interfaces:
•javax.jms.ServerSession
• javax.jms.ServerSessionPool
• javax.jms.ConnectionConsumer
• all javax.jms XA interfa
The following methods may only be used by application components executing in the application client container:
• javax.jms.Session method setMessageListener
• javax.jms.Session method getMessageListener
• javax.jms.Session method run
• javax.jms.QueueConnection method createConnectionConsumer
• javax.jms.TopicConnection method createConnectionConsumer
• javax.jms.TopicConnection method createDurableConnectionConsumer
• javax.jms.MessageConsumer method getMessageListener
• javax.jms.MessageConsumer method setMessageListener
• javax.jms.Connection method setExceptionListener
• javax.jms.Connection method stop
• javax.jms.Connection method setClientID
A Java EE container may throw a JMSException (if allowed by the method) if the application component violates these restrictions.
Application components in the web and EJB containers must not attempt to create more than one active (not closed) Session object per connection. An attempt to use the Connection object’s createSession method when an active Session object exists for that connection should be prohibited by the container. The container may throw a JMSException if the application component violates this restriction. Application client containers must support the creation of multiple sessions for each connection.
-From javaeespec Chapter 7
Page 116 of the Jave EE, JSR-244, lists a variety of programming restrictions, some of which apply to EJBs, with others applying to other JEE containers. It's a good read, and it will certainly help you understand what Sun is getting at when they penned this objective.
"The Java EE programming model divides responsibilities between Application Component Providers and Java EE Product Providers: Application Component Providers focus on writing business logic and the Java EE Product Providers focus on providing a managed system infrastructure in which the application components can be deployed. This division leads to a restriction on the functionality that application components can contain. If application components contain the same functionality provided by Java EE system infrastructure, there are clashes and mis-management of the functionality.For example, if enterprise beans were allowed to manage threads, the Java EE platform could not manage the life cycle of the enterprise beans, and it could not properly manage transactions.
Since we do not want to subset the J2SE platform, and we want Java EE Product Providers to be able to use J2SE products without modification in the Java EE platform, we use the J2SE security permissions mechanism to express the programming restrictions imposed on Application Component Providers. In this section, we specify the J2SE security permissions that the Java EE Product Provider must provide for each application component type. We call these permissions the Java EE security permissions set. The Java EE security permissions set is a required part of the Java EE API contract. Portable applications will rely on only the set of permissions specified here."
Java EE applications should not attempt to load JDBC drivers directly. Instead, they should use the technique recommended in the JDBC specification and perform a JNDI lookup to locate a DataSource object. The JNDI name of the DataSource object should be chosen as described in Section EE.5.6, “Resource Manager Connection Factory References.” The Java EE platform must be able to supply a DataSource that does not require the application to supply any authentication information when obtaining a database connection. Of course, applications may also supply a user name and password when connecting to the database.
When a JDBC API connection is used in an enterprise bean, the transaction characteristics will typically be controlled by the container. The component should not attempt to change the transaction characteristics of the connection, commit the transaction, roll back the transaction, or set autocommit mode. Attempts to make changes that are incompatible with the current transaction context may result in a SQLException being thrown. The EJB specification contains the precise rules for enterprise beans.
Support for the new BLOB, CLOB, ARRAY , REF, STRUCT, and JAVA_OBJECT types not required. All parameter types (IN, OUT, and INOUT) must be supported.
To allow this ORB instance to be safely shared between components, portable components must restrict their usage of certain ORB APIs and functionality:
• Do not call the ORB shutdown method.
• Do not call the org.omg.CORBA_2_3.ORB methods register_value_factory
and unregister_value_factory with an id used by the container.
The Preferences API in the java.util.prefs package allows applications to s and retrieve user and system preference and configuration data. A Java EE application typically will not have the RuntimePermission("preferences") necessary to use the Preferences API. This specification does not define any relationship between the principal used by a Java EE application and the user
The EJB container and the web container are both required to support access to local enterprise beans. No support is provided for access to local enterprise beans from the application client container or the applet container.
portable Java EE applications must not use the following interfaces:
•javax.jms.ServerSession
• javax.jms.ServerSessionPool
• javax.jms.ConnectionConsumer
• all javax.jms XA interfa
The following methods may only be used by application components executing in the application client container:
• javax.jms.Session method setMessageListener
• javax.jms.Session method getMessageListener
• javax.jms.Session method run
• javax.jms.QueueConnection method createConnectionConsumer
• javax.jms.TopicConnection method createConnectionConsumer
• javax.jms.TopicConnection method createDurableConnectionConsumer
• javax.jms.MessageConsumer method getMessageListener
• javax.jms.MessageConsumer method setMessageListener
• javax.jms.Connection method setExceptionListener
• javax.jms.Connection method stop
• javax.jms.Connection method setClientID
A Java EE container may throw a JMSException (if allowed by the method) if the application component violates these restrictions.
Application components in the web and EJB containers must not attempt to create more than one active (not closed) Session object per connection. An attempt to use the Connection object’s createSession method when an active Session object exists for that connection should be prohibited by the container. The container may throw a JMSException if the application component violates this restriction. Application client containers must support the creation of multiple sessions for each connection.
-From javaeespec Chapter 7
Identify the APIs that all EJB 3.0 containers must make available to developers SCDBC Objective
Identify the APIs that all EJB 3.0 containers must make available to developers.
Here's another bullet from Section One of Sun's Certified Business Component Developer certification exam.
Now, I wasn't totally sure initially what they were talking about here, although it is fairly straight forward. As anyone that is paying attention knows, JSR 220, the EJB specification, is spread out over three documents, namely:
• EJB 3.0 Simplified API
• EJB Core Contracts and Requirements
• Java Persistence API
So, I initially thought that this objective really just wanted to test you on whether you understood this simple fact regarding the three key JSR documents, but I think the objective goes a little bit further than that.
I actually poked around the JSR 220 EJB Specification documents, but I couldn't find any specific parts that described the various APIs upon which an EJB container was dependent. So, I figured I'd head over to jcp.org and download the Java EE, JEE5 specification. Chapter 6, on page 113 (129) has all sorts of great information on the various APIs that a JEE5 application server must implement. Now, you have to be careful, because some of the APIs are designed for the web or JCA container, but putting that aside, it's a great reference.
http://jcp.org/en/jsr/detail?id=244
Required APIs
Java EE application components execute in runtime environments provided by the
containers that are a part of the Java EE platform. The Java EE platform supports
four types of containers corresponding to Java EE application component types:
application client containers, applet containers, web containers for servlets and JSP
pages, and enterprise bean containers. -pg 113
Notice how it lists four containers. I always forget about Client and Applet containers. Do RAR files not have a dedicated container? Hmmmm...I thought they did. Guess I'm wrong!
Now, the EJB container runs on top of the J2SE, or standard Java runtime environment, so all EJB components can access standard Java libraries. I guess that even includes Swing and AWT classes too, although I'm not too sure how a server side component might effectively use them, but regardless, all of the Java Standard Edition packages are available to your EJB components, including:
• Java IDL API
• JDBC API
• RMI-IIOP API
• JNDI API
• JAXP API
• JAAS API
• JMX API
Now, those are the APIs available by default. They are not optional in a standard Java environment. However, there are APIs that are optional at the JSE level, but NOT optional at either the JEE5 or EJB 3.0 level. Here's a good sorting of those required APIs:
EJB 3.0
JMS 1.1
JTA 1.1
JavaMail 1.4
JAF 1.1
Connector 1.5
Web Services 1.2
JAX-RPC 1.1
JAX-WS 2.0
JAXB 2.0
SAAJ 1.3
JAXR 1.0
Java EE Management 1.1
Java EE Deployment 1.2c
JACC 1.1
JSP Debugging 1.0
JSTL 1.2
Web Services Metadata 2.0
JSF 1.2
Common Annotations 1.0
StAX 1.0
Java Persistence 1.0
The following APIs are required by JEE5, most of which are required by the web container, but are not required by the EJB 3.0 container:
JSF 1.2
JSP Debugging 1.0
JSTL 1.2
Java EE Deployment 1.2c
Servlet 2.5
JSP 2.1
Does EJB 3.0 Need to Support CORBA Components? What about IIOP?
I've seen a few questions bandied around about whether EJB 3.0, JSR 220 requires any support for CORBA. I've heard some say it doesn't, and I've heard others argue the point. Here's what it says on page 36 of the EJB Core Contracts Requirements Document:
"To help interoperability for EJB environments that include systems from multiple vendors, the EJB specification requires compliant implementations to support the interoperability protocol based onCORBA/IIOP for remote invocations from Java EE clients. Implementations may support other remoteinvocation protocols in addition to IIOP."
So, indeed, new Enterprise JavaBeans, through their container, must have some support for the CORBA based IIOP protocols so J2EE/JEE clients using CORBA can invoke them.
"To help interoperability for EJB environments that include systems from multiple vendors, the EJB specification requires compliant implementations to support the interoperability protocol based onCORBA/IIOP for remote invocations from Java EE clients. Implementations may support other remoteinvocation protocols in addition to IIOP."
So, indeed, new Enterprise JavaBeans, through their container, must have some support for the CORBA based IIOP protocols so J2EE/JEE clients using CORBA can invoke them.
Characteristics of an Enterprise JavaBean and EJB 3.0 Technology
The first objective of the SCBCD exam includes a reference to the characteristics of Enterprise JavaBeans technology. Page 34 of the JSR 220: EJB Core Contracts and Requirements documents lists the key characteristics of an EJB. I think we'll find some easy questions on these points on the Sun Certified Business Component Developer Exam. I'll put some mocks on the topic together soon, but for now, here's the study material, as I said, page 34:
The essential characteristics of an enterprise bean are:
• An enterprise bean typically contains business logic that operates on the enterprise’s data.
• An enterprise bean’s instances are managed at runtime by a container.
• An enterprise bean can be customized at deployment time by editing its environment entries.
• Various service information, such as transaction and security attributes, may be specified
together with the business logic of the enterprise bean class in the form of metadata annota-
tions, or separately, in an XML deployment descriptor. This service information may be
extracted and managed by tools during application assembly and deployment.
• Client access is mediated by the container in which the enterprise bean is deployed.
• If an enterprise bean uses only the services defined by the EJB specification, the enterprise
bean can be deployed in any compliant EJB container. Specialized containers can provide addi-
tional services beyond those defined by the EJB specification. An enterprise bean that depends
on such a service can be deployed only in a container that supports that service.
• An enterprise bean can be included in an assembled application without requiring source code
changes or recompilation of the enterprise bean.
• The Bean Provider defines a client view of an enterprise bean. The Bean Provider can manu-
ally define the client view or it can be generated automatically by application development
tools. The client view is unaffected by the container and server in which the bean is deployed.
This ensures that both the beans and their clients can be deployed in multiple execution envi-
ronments without changes or recompilation.
The enterprise bean architecture is flexible enough to implement the following:
• An object that represents a stateless service.
• An object that represents a stateless service and that implements a web service endpoint.
• An object that represents a stateless service and whose invocation is asynchronous, driven by
the arrival of messages.
• An object that represents a conversational session with a particular client. Such session objects
automatically maintain their conversational state across multiple client-invoked methods.
• An entity object that represents a fine-grained persistent object.
Enterprise beans that are remotely accessible components are intended to be relatively coarse-grained
business objects (e.g. shopping cart, stock quote service). Fine-grained objects (e.g. employee record,
line items on a purchase order) should be modeled as light weight persistent entities, as described in [2],
not as remotely accessible components.
Although the state management protocol defined by the Enterprise JavaBeans architecture is simple, it
provides an enterprise bean developer great flexibility in managing a bean’s state.
The essential characteristics of an enterprise bean are:
• An enterprise bean typically contains business logic that operates on the enterprise’s data.
• An enterprise bean’s instances are managed at runtime by a container.
• An enterprise bean can be customized at deployment time by editing its environment entries.
• Various service information, such as transaction and security attributes, may be specified
together with the business logic of the enterprise bean class in the form of metadata annota-
tions, or separately, in an XML deployment descriptor. This service information may be
extracted and managed by tools during application assembly and deployment.
• Client access is mediated by the container in which the enterprise bean is deployed.
• If an enterprise bean uses only the services defined by the EJB specification, the enterprise
bean can be deployed in any compliant EJB container. Specialized containers can provide addi-
tional services beyond those defined by the EJB specification. An enterprise bean that depends
on such a service can be deployed only in a container that supports that service.
• An enterprise bean can be included in an assembled application without requiring source code
changes or recompilation of the enterprise bean.
• The Bean Provider defines a client view of an enterprise bean. The Bean Provider can manu-
ally define the client view or it can be generated automatically by application development
tools. The client view is unaffected by the container and server in which the bean is deployed.
This ensures that both the beans and their clients can be deployed in multiple execution envi-
ronments without changes or recompilation.
The enterprise bean architecture is flexible enough to implement the following:
• An object that represents a stateless service.
• An object that represents a stateless service and that implements a web service endpoint.
• An object that represents a stateless service and whose invocation is asynchronous, driven by
the arrival of messages.
• An object that represents a conversational session with a particular client. Such session objects
automatically maintain their conversational state across multiple client-invoked methods.
• An entity object that represents a fine-grained persistent object.
Enterprise beans that are remotely accessible components are intended to be relatively coarse-grained
business objects (e.g. shopping cart, stock quote service). Fine-grained objects (e.g. employee record,
line items on a purchase order) should be modeled as light weight persistent entities, as described in [2],
not as remotely accessible components.
Although the state management protocol defined by the Enterprise JavaBeans architecture is simple, it
provides an enterprise bean developer great flexibility in managing a bean’s state.
Identify the uses, benefits, and characteristics of Enterprise JavaBeans technology, for version 3.0 of the EJB specification
-Identify the uses, benefits, and characteristics of Enterprise JavaBeans technology, for version 3.0 of the EJB specification.
Here we go with the marketing hype!
That's what this objective is really all about - making sure the aspiring SCBCD candidates know the marketing hype around EJB3.0, and making sure they can spout off that marketing hype in a design meeting or in front of an architecture review board.
Page 8 of the JSR220 EJB 3.0 Simplified API document covers they hype pretty good, first in the introduction on page 9, and then again at the beginning of chapter 2 on page 13:
1.1 Overview
The EJB 3.0 release of the Enterprise JavaBeans architecture provides a new, simplified API for the
enterprise application developer. This API is targeted at ease of development and is a simplification of
the APIs defined by earlier versions of the EJB specification. The existing EJB 2.1 APIs remain avail-
able for use in applications that require them and components written to those APIs may be used in con-
junction with components written to the new EJB 3.0 APIs.
1.2 Goals of this Release
The purpose of the EJB 3.0 release is to improve the EJB architecture by reducing its complexity from
the enterprise application developer’s point of view.
EJB 3.0 is focused on the following goals:
• Definition of the Java language metadata annotations that can be used to annotate EJB appli-
cations. These metadata annotations are targeted at simplifying the developer’s task, at reduc-
ing the number of program classes and interfaces the developer is required to implement, and
at eliminating the need for the developer to provide an EJB deployment descriptor.
• Specification of programmatic defaults, including for metadata, to reduce the need for the
developer to specify common, expected behaviors and requirements on the EJB container. A
“configuration by exception” approach is taken whenever possible.
• Encapsulation of environmental dependencies and JNDI access through the use of annota-
tions, dependency injection mechanisms, and simple lookup mechanisms.
• Simplification of the enterprise bean types.
• Elimination of the requirement for EJB component interfaces for session beans. The required
business interface for a session bean can be a plain Java interface rather than an EJBObject,
EJBLocalObject, or java.rmi.Remote interface.
• Elimination of the requirement for home interfaces for session beans.
• Simplification of entity persistence through the Java Persistence API. Support for light-weight
domain modeling, including inheritance and polymorphisis
• Elimination of all required interfaces for persistent entities
• Specification of Java language metadata annotations and XML deployment descriptor ele-
ments for the object/relational mapping of persistent entities
• A query language for Java Persistence that is an extension to EJB QL, with addition of projec-
tion, explicit inner and outer join operations, bulk update and delete, subqueries, and
group-by. Addition of a dynamic query capability and support for native SQL queries.
• An interceptor facility for session beans and message-driven beans.
• Reduction of the requirements for usage of checked exceptions.
• Elimination of the requirement for the implementation of callback interfaces.
The EJB 3.0 release is focused on a simplification of the Enterprise JavaBeans architecture from the
developer’s point of view. This simplification has several main aspects:
• Simplification of the interface definition requirements for enterprise beans: elimination of
requirements for the specification of home and component interfaces in the EJB 3.0 program-
ming model.
• Simplification of the contractual requirements between the bean provider and the container:
elimination of the requirements for enterprise beans to implement the javax.ejb.Enter-
priseBean interfaces.
• Simplification of APIs for access to a bean's environment: definition of a dependency injection
facility and simpler look-up APIs.
• Introduction of Java metadata annotations to be used as an alternative to deployment descrip-
tors.
• Simplification of object persistence by the definition of a light-weight object/relational map-
ping facility based on the direct use of Java classes rather than persistent components.
Again, this has been very liberally taken from the EJB 3.0 Simplified API document. You should definitely go over it and see how Sun wants to position the EJB3.0 specification. Note that these points are repeated again in the EJB 3.0 Core Contracts document. You can be pretty sure that Sun wants you to be up and on top of these ideas.
Chapter 2, page 29 of the Core Contracts document also outlines the goals of EJB and the EJB 3.0 Specification. Any JEE or J2EE developer should be familiar with these, and be able to answer a question on:
The Enterprise JavaBeans (EJB) architecture has the following goals:
• The Enterprise JavaBeans architecture will be the standard component architecture for build-
ing object-oriented business applications in the Java™ programming language.
• The Enterprise JavaBeans architecture will be the standard component architecture for build-
ing distributed business applications in the Java™ programming language.
• The Enterprise JavaBeans architecture will support the development, deployment, and use of
web services.
• The Enterprise JavaBeans architecture will make it easy to write applications: application
developers will not have to understand low-level transaction and state management details,
multi-threading, connection pooling, or other complex low-level APIs.
• Enterprise JavaBeans applications will follow the Write Once, Run Anywhere™ philosophy of
the Java programming language. An enterprise bean can be developed once, and then
deployed on multiple platforms without recompilation or source code modification.
• The Enterprise JavaBeans architecture will address the development, deployment, and runtime
aspects of an enterprise application’s life cycle.
• The Enterprise JavaBeans architecture will define the contracts that enable tools from multiple
vendors to develop and deploy components that can interoperate at runtime.
• The Enterprise JavaBeans architecture will make it possible to build applications by combin-
ing components developed using tools from different vendors.
• The Enterprise JavaBeans architecture will provide interoperability between enterprise beans
and Java Platform, Enterprise Edition (Java EE) components as well as non-Java program-
ming language applications.
• The Enterprise JavaBeans architecture will be compatible with existing server platforms. Ven-
dors will be able to extend their existing products to support Enterprise JavaBeans.
• The Enterprise JavaBeans architecture will be compatible with other Java programming lan-
guage APIs.
• The Enterprise JavaBeans architecture will be compatible with the CORBA protocols.
The purpose of the EJB 3.0 release is both to continue to achieve these goals and to improve the EJB
architecture by reducing its complexity from the enterprise application developer’s point of view.
Here we go with the marketing hype!
That's what this objective is really all about - making sure the aspiring SCBCD candidates know the marketing hype around EJB3.0, and making sure they can spout off that marketing hype in a design meeting or in front of an architecture review board.
Page 8 of the JSR220 EJB 3.0 Simplified API document covers they hype pretty good, first in the introduction on page 9, and then again at the beginning of chapter 2 on page 13:
1.1 Overview
The EJB 3.0 release of the Enterprise JavaBeans architecture provides a new, simplified API for the
enterprise application developer. This API is targeted at ease of development and is a simplification of
the APIs defined by earlier versions of the EJB specification. The existing EJB 2.1 APIs remain avail-
able for use in applications that require them and components written to those APIs may be used in con-
junction with components written to the new EJB 3.0 APIs.
1.2 Goals of this Release
The purpose of the EJB 3.0 release is to improve the EJB architecture by reducing its complexity from
the enterprise application developer’s point of view.
EJB 3.0 is focused on the following goals:
• Definition of the Java language metadata annotations that can be used to annotate EJB appli-
cations. These metadata annotations are targeted at simplifying the developer’s task, at reduc-
ing the number of program classes and interfaces the developer is required to implement, and
at eliminating the need for the developer to provide an EJB deployment descriptor.
• Specification of programmatic defaults, including for metadata, to reduce the need for the
developer to specify common, expected behaviors and requirements on the EJB container. A
“configuration by exception” approach is taken whenever possible.
• Encapsulation of environmental dependencies and JNDI access through the use of annota-
tions, dependency injection mechanisms, and simple lookup mechanisms.
• Simplification of the enterprise bean types.
• Elimination of the requirement for EJB component interfaces for session beans. The required
business interface for a session bean can be a plain Java interface rather than an EJBObject,
EJBLocalObject, or java.rmi.Remote interface.
• Elimination of the requirement for home interfaces for session beans.
• Simplification of entity persistence through the Java Persistence API. Support for light-weight
domain modeling, including inheritance and polymorphisis
• Elimination of all required interfaces for persistent entities
• Specification of Java language metadata annotations and XML deployment descriptor ele-
ments for the object/relational mapping of persistent entities
• A query language for Java Persistence that is an extension to EJB QL, with addition of projec-
tion, explicit inner and outer join operations, bulk update and delete, subqueries, and
group-by. Addition of a dynamic query capability and support for native SQL queries.
• An interceptor facility for session beans and message-driven beans.
• Reduction of the requirements for usage of checked exceptions.
• Elimination of the requirement for the implementation of callback interfaces.
The EJB 3.0 release is focused on a simplification of the Enterprise JavaBeans architecture from the
developer’s point of view. This simplification has several main aspects:
• Simplification of the interface definition requirements for enterprise beans: elimination of
requirements for the specification of home and component interfaces in the EJB 3.0 program-
ming model.
• Simplification of the contractual requirements between the bean provider and the container:
elimination of the requirements for enterprise beans to implement the javax.ejb.Enter-
priseBean interfaces.
• Simplification of APIs for access to a bean's environment: definition of a dependency injection
facility and simpler look-up APIs.
• Introduction of Java metadata annotations to be used as an alternative to deployment descrip-
tors.
• Simplification of object persistence by the definition of a light-weight object/relational map-
ping facility based on the direct use of Java classes rather than persistent components.
Again, this has been very liberally taken from the EJB 3.0 Simplified API document. You should definitely go over it and see how Sun wants to position the EJB3.0 specification. Note that these points are repeated again in the EJB 3.0 Core Contracts document. You can be pretty sure that Sun wants you to be up and on top of these ideas.
Chapter 2, page 29 of the Core Contracts document also outlines the goals of EJB and the EJB 3.0 Specification. Any JEE or J2EE developer should be familiar with these, and be able to answer a question on:
The Enterprise JavaBeans (EJB) architecture has the following goals:
• The Enterprise JavaBeans architecture will be the standard component architecture for build-
ing object-oriented business applications in the Java™ programming language.
• The Enterprise JavaBeans architecture will be the standard component architecture for build-
ing distributed business applications in the Java™ programming language.
• The Enterprise JavaBeans architecture will support the development, deployment, and use of
web services.
• The Enterprise JavaBeans architecture will make it easy to write applications: application
developers will not have to understand low-level transaction and state management details,
multi-threading, connection pooling, or other complex low-level APIs.
• Enterprise JavaBeans applications will follow the Write Once, Run Anywhere™ philosophy of
the Java programming language. An enterprise bean can be developed once, and then
deployed on multiple platforms without recompilation or source code modification.
• The Enterprise JavaBeans architecture will address the development, deployment, and runtime
aspects of an enterprise application’s life cycle.
• The Enterprise JavaBeans architecture will define the contracts that enable tools from multiple
vendors to develop and deploy components that can interoperate at runtime.
• The Enterprise JavaBeans architecture will make it possible to build applications by combin-
ing components developed using tools from different vendors.
• The Enterprise JavaBeans architecture will provide interoperability between enterprise beans
and Java Platform, Enterprise Edition (Java EE) components as well as non-Java program-
ming language applications.
• The Enterprise JavaBeans architecture will be compatible with existing server platforms. Ven-
dors will be able to extend their existing products to support Enterprise JavaBeans.
• The Enterprise JavaBeans architecture will be compatible with other Java programming lan-
guage APIs.
• The Enterprise JavaBeans architecture will be compatible with the CORBA protocols.
The purpose of the EJB 3.0 release is both to continue to achieve these goals and to improve the EJB
architecture by reducing its complexity from the enterprise application developer’s point of view.
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.
Subscribe to:
Posts (Atom)
