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
Wednesday, August 27, 2008
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.
Subscribe to:
Posts (Atom)
