This article is based on EJB3 in Action, Second Editionand the book will release on October 2011. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) ebooks and pbooks. MEAPs are sold exclusively through Manning.com. All print book purchases include an ebook free of charge. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information.

Working with Message-Driven Beans

Introduction

Message-driven beans (MDBs) are EJB components designed to consume asynchronous messages. Although MDBs are intended to handle many different kinds of messages, we’ll discuss MDBs that process JMS messages because that is what MDBs are most commonly used for.

JCA connectors and messaging

Although by far JMS is the primary messaging provider for MDBs, as of EJB 2.1, it is not the only one. Thanks to the Java EE Connector Architecture (JCA), MDBs can receive messages from any enterprise information system (EIS), such as PeopleSoft or Oracle Manufacturing, not just message-oriented middleware (MOM) that supports JMS.

Suppose you have a legacy application that needs to send messages to an MDB. You can do this by implementing a JCA-compliant adapter/connector that includes support for message inflow contract. Once your JCA resource adapter or connector is deployed to a Java EE container, you can use the message inflow contract to have an asynchronous message delivered to an endpoint inside the container. A JCA endpoint is essentially the same as a JMS destination —it acts as a server proxy to an MDB (a message consumer/listener in JMS terms). As soon as a message arrives at the end point, the container triggers any registered MDBs listening to the endpoint and delivers the message to it.

For its part, the MDB implements a listener interface that is appropriate to the JCA connector/message type and passes activation configuration parameters to the JCA connector and registers as a listener to the JCA connector. JCA also enables MOM providers to integrate with Java EE containers in a standardized manner using a JCA-compliant connector or resource adapter.

For more information on JCA, visit http://java.sun.com/j2ee/connector/

When to use Messaging and MDBs

Messaging and message-driven beans are powerful concepts but they are not right for every use-case. As a rule of thumb, you should use MDBs only if you require asynchronous processing, loose-coupling, and reliability. The and part in the previous sentence is very important. Unless you need all three of these characteristics, you probably don’t need MDB.

If you simply need asynchronous processing and not reliability or loose-coupling, you should opt to use the session bean @Asynchronous annotation. The @Asynchronous annotation is not loosely-coupled since you invoke the asynchronous session bean method directly from client code. It is less obvious that session bean asynchronous methods are also not reliable. If the container crashes in the middle of asynchronous processing, the session bean is simply lost. With message-driven beans, on the other hand, the JMS message is not removed from the middleware until the MDB finishes processing the message. If the MDB suddenly crashes before finishing processing, the message is simply reprocessed when the container is ready again.

Similarly, if all you need is loose-coupling, you should take a close look at CDI events. CDI events allow message consumers and producers to be separated through elegant type-safe object-based events. Like session bean asynchronous processing, the CDI event bus is not fault-tolerant and is also not asynchronous. Note that you can combine the @Asynchronous annotation with CDI events if you need to.

When you do need asynchronous processing, loose-coupling and reliability, however, MDBs are one of the best solutions around—which is why they are so popular for system integration. Let’s take a closer look at why this is the case next.

Why use MDBs?

Given the problems that plagued EJB 2, you might question the value of EJB 3 MDBs as opposed to using some other mechanism for consuming JMS messages. The truth is that MDBs have enjoyed a reasonable degree of success even in the darkest hours of EJB. We’ll now explain why you should take a serious look at MDBs.

Multithreading

Your business application may require multithreaded message consumers that can process messages concurrently and maximize message throughput. MDBs help you to avoid complexity because they handle multithreading right out of the box, without any additional code. They manage incoming messages among multiple instances of beans (in a pool) that have no special multithreading code themselves. As soon as a new message reaches the destination, an MDB instance is retrieved from the pool to handle the message, as shown in figure 1. This is popularly known as MDB pooling.

Simplified messaging code

The raw JMS code to retrieve messages mirrors the JMS code to send messages and can be pretty verbose and error prone. MDBs relieve you from coding the mechanical aspects of processing JMS messages—tasks such as retrieving connection factories or destinations, creating connections, opening sessions, creating consumers, and attaching listeners. All of these tasks are handled behind the scenes for you. In EJB 3, using sensible defaults for common circumstances eliminates most of the configuration. In the worst-case scenario, you’ll have to supply configuration information using simple annotations or through the deployment descriptor.

Robust message processing

Reliability is a critical hallmark of MDBs. All MDBs use transactions and message acknowledgement by default. What this means is that messages are not removed from the message server unless an MDB message listener method completes normally. If an unexpected error occurs during message processing, the transaction is marked for rollback and the message receipt is not acknowledged. Because MDBs use JTA transactions, any database changes made during message listener processing is also automatically rolled back. As a result, the un-acknowledged message can be re-processed by the MDB cleanly without your having to do any work. In case of successful message processing, database changes are committed and the message is removed from the message server in an atomic fashion.

Starting message consumption

To start picking up messages from the shipping request queue, someone needs to invoke the appropriate method in your code. In a production environment, it is not clear how this will be accomplished. Starting message consumption thought a user-driven manual process obviously is not desirable. In a server environment, almost every means of executing the method on server startup is highly system dependent, not to mention awkward. The same is true about stopping message processing manually. On the other hand, registered MDBs would be bootstrapped or torn down gracefully by the container when the server is started or stopped.

Summary

Messaging is an extremely powerful technology for the enterprise, and it helps build loosely integrated reliable systems. JMS allows you to use message-oriented middleware (MOM) from enterprise Java applications without being bound to vendor-specific APIs. Using the JMS API to build a message consumer application can be time consuming, and message-driven beans (MDBs) make using MOM in standardized manner through Java EE extremely easy and robust.

• EJB Interview Questions
• Managing transactions in EJB 3.0
• Using CDI with EJB 3.0
• J2EE Books

Download Securing EJB Application Sample Code

• Securing EJB Application Sample Code

Security

Implementing the EJB security is one of the challenging task in J2EE projects. While talking about securing EJB Applications, we essentially talk about Authentication and Authorization. Authentication involves the process of verifying the user who is accessing a system. The most common way of providing online authentication for users is to supply credentials in the form of username and password and then asking the user to provide them before accessing the system. Not every user should be give access to various parts of a a system and Authorization refers to the process of ensuring whether the authenticated user has the required privilege to access a particular area in system.

• Buy head first EJB

It is worthwhile to understand the relationship between users, user groups and roles before delving into the details of EJB security. For easier maintenance of security model, the responsibilities of various users within an organization will be identified and they will segregated into various user groups. For example, one set of users in an organization will own the responsibility of carrying out admin set of tasks and they can be identified and made to fall into admin user group. Similarly users performing management oriented activities may fall in the manager user group. Let us assume that the developer wants to write an enterprise bean containing business methods representing admin and management set of functionality. He may not be aware of the users and the user groups in the target environment. So, let us say that we write business methods adminOperations() and managementOperations(), then will somehow provide an indication that the method adminOperations() can be accessible by users owning the ‘admin’ role and the method managementOperations() can be accessible by users owning the ‘manager’ role. The role provides an abstract representation here, and in the target environment each role has to be mapped against the user groups which already exists in the operational environment.

Declarative Security

In this section, we will look into the concept of Declarative Security. By specifying this form of security for an Enterprise bean, we instruct the container that we are delegating the responsibility of security to the Container. EJB allows security elements to be specified at the class level and also at the method level.

Annotations

The various annotations that can be used with Enterprise beans are defined in the forthcoming sections. Note that it is also possible to define the security constraints for an Enterprise bean in a deployment descriptor. If the security elements are defined both in annotations and in deployment descriptor, the one specified in deployment descriptor takes precedence.

DeclareRoles annotation

This annotation can be specified at the class level and this will accept the list of allowed roles that an enterprise bean expects. Note that this annotation is optional, meaning that it is not necessary to declare the list of annotations before using it.

@DeclareRoles({"admin" "super-admin"})
public class ManagementBean{
}

RolesAllowed annotation

This annotation can be applied at the method level which will take an array of allowed roles for the method to execute. For example, in the below snippet we have declared roles ‘admin’ and ‘super-admin’, and in the delete() method we have only allowed users who belong to the role ‘super-admin’ to perform the delete operation.

@DeclareRoles({"admin" "super-admin"})
public class ManagementBean{

	@RolesAllowed({"super-admin"})
	public void delete(){
	}
}

PermitAll annotation

This annotation can be applied at the class level or at the method level. This instructs the container that a user belonging to any role is allowed to access the operation. When applied at the class level, this annotation will propagate to all the business methods in the enterprise bean.

@DeclareRoles({"admin" "super-admin"})
public class ManagementBean{

	@RolesAllowed({"super-admin"})
	public void delete(){
	}

	@PermitAll
	public void viewOperation(){
	}
}

For example, in the above code, we have annotated the method ‘viewOperation’ with the @PermitAll annotation. This ensures that this method can be accessible by any user.

DenyAll annotation

This annotation can be applied both at the class and the method level. When applied at the class level, all the business methods within the enterprise bean cannot be accessible at all.

@DeclareRoles({"admin" "super-admin"})
public class ManagementBean{

	@RolesAllowed({"super-admin"})
	public void delete(){
	}

	@DenyAll
	public void deleteAll(){
	}
}

Demonstration

In this example, we will provide with an example illustrating the usage of declarative security in ejbs. We will take the example of task management. Tasks can be created, assigned, completed and then deleted. We will identify four distinct roles here: ‘admin’, ‘manager’, ‘team-lead’ and ‘developer’. For illustration purposes, let us assume that only a manager can create a task, a team-lead can assign a created task to a developer and the developer can complete a task once it is completed. Special privileges are given to admin for deleting tasks.

Task Entity Model

We will define the model for Task Entity in this section. The listing for the Task Entity model is given below.

package net.javabeat.articles.ejb3.security.annotations;

import java.io.Serializable;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class TaskEntity implements Serializable {

    private static final long serialVersionUID = 1L;
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String name;
    private String description;
    private String assignee;
    private String status;

    public String getAssignee() {
        return assignee;
    }

    public void setAssignee(String assignee) {
        this.assignee = assignee;
    }

    public String getDescription() {
        return description;
    }

    public void setDescription(String description) {
        this.description = description;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getStatus() {
        return status;
    }

    public void setStatus(String status) {
        this.status = status;
    }

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (id != null ? id.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
		if (!(object instanceof TaskEntity)) {
			return false;
		}
		TaskEntity other = (TaskEntity) object;
		if ((this.id == null && other.id != null) || (this.id != null && !this.id.equals(other.id))) {
			return false;
		}
		return true;
    }

    @Override
    public String toString() {
        return "net.javabeat.articles.ejb3.security.annotations.TaskEntity[id=" + id + "]";
    }

}

Note that the above class is modeled as an Entity bean so that the task’s information can be persisted in the database. The task has properties such as task id, name, description, assignee and status. Note that we have used JPA annotations to instruct that above class is an Entity class.

Task Entity Remote interface

We will introduce the remote interface for the Task Entity in this section, the code for the same is given below.

package net.javabeat.articles.ejb3.security.annotations;

import java.util.List;
import javax.ejb.Remote;

@Remote
public interface TaskEntityFacadeRemote {

    void createTask(String name, String description);

    void assignTask(Long taskId, String assignee);

    void completeTask(Long taskId);

    List getAllTasks();

    void deleteAllTasks();

    void create(TaskEntity taskEntity);

    void edit(TaskEntity taskEntity);

    void remove(TaskEntity taskEntity);

    TaskEntity find(Object id);

    List findAll();

}

Other than the regular CRUD operations that can be applicable to any entity, this interface provides services for creating task, assigning task, completing task, listing all the tasks and deleting tasks.

Task Entity Remote Implementation

The implementation for the above remote interface is given below. Note that the below implementation takes new support such as dependency injection and annotations. The implementation class declares the list of roles through the annotation @DelcareRoles at the class level. The entity manager entity will be injected by the EJB Container with the help of annotation @PersistenceContext.

package net.javabeat.articles.ejb3.security.annotations;

import java.util.List;
import javax.annotation.security.DeclareRoles;
import javax.annotation.security.PermitAll;
import javax.annotation.security.RolesAllowed;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
@DeclareRoles(value={"admin", "manager", "team-lead", "developer"})
public class TaskEntityFacade implements TaskEntityFacadeRemote {

    @PersistenceContext
    private EntityManager em;

    @RolesAllowed("manager")
    public void createTask(String name, String description) {

        TaskEntity newTaskEntity = new TaskEntity();
        newTaskEntity.setName(name);
        newTaskEntity.setDescription(description);
        newTaskEntity.setStatus("NEW");

        em.persist(newTaskEntity);
    }

    @RolesAllowed("team-lead")
    public void assignTask(Long taskId, String assignee){

        TaskEntity taskEntity = find(taskId);
        taskEntity.setAssignee(assignee);
        taskEntity.setStatus("ASSIGNED");
        em.persist(taskEntity);
    }

    @RolesAllowed("developer")
    public void completeTask(Long taskId){

        TaskEntity taskEntity = find(taskId);
        taskEntity.setStatus("COMPLETED");
        em.persist(taskEntity);
    }

    @RolesAllowed("admin")
    public void deleteAllTasks(){

        List allTasks = findAll();
        if (allTasks != null){
            for (TaskEntity aTask : allTasks){
                remove(aTask);
            }
        }
    }

    @PermitAll
    public List getAllTasks() {
        return em.createQuery("select object(o) from TaskEntity as o").getResultList();
    }

    public TaskEntity findByName(String name){
        return null;
    }

    public void create(TaskEntity taskEntity) {
        em.persist(taskEntity);
    }

    public void edit(TaskEntity taskEntity) {
        em.merge(taskEntity);
    }

    public void remove(TaskEntity taskEntity) {
        em.remove(em.merge(taskEntity));
    }

    public TaskEntity find(Object id) {
        return em.find(TaskEntity.class, id);
    }

    public List findAll() {
        return em.createQuery("select object(o) from TaskEntity as o").getResultList();
    }

}

Since in our example case, only a manager is allowed to create a task, hence the method ‘createTask()’ is annotated with @RolesAllowed with the role ‘manager’. The method assignTask can be executed by an user who owns the role ‘team-lead’. Similarly the methods completeTask() and deleteAllTasks() are assigned with ‘developer’ and ‘admin’ roles. The annotation @PermitAll is used against the method ‘getAllTasks()’ indicating that a user belonging to any role can access this operation.

Persitence configuration

The persistence configuration information file for persisting the Task Entity bean is given below.

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="TaskManager-ejbPU" transaction-type="JTA">
    <provider>oracle.toplink.essentials.PersistenceProvider</provider>
    <jta-data-source>jdbc/sample</jta-data-source>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties>
      <property name="toplink.ddl-generation" value="drop-and-create-tables"/>
    </properties>
  </persistence-unit>
</persistence>

Note that we are using the Oracle’s TopLink as the persistence provider although any JPA compliant provider can be used. The ddl generation policy is ‘drop and create’ which means that before every execution the database objects will be dropped and re-created.

Security configuration

We will discuss the security configuration in this section. Note that in the enterprise bean we have defined only roles and not users. The Enterprise beans that will be getting deployed in the target environment will have a list of users and user groups configured. So, the roles defined in the Enterprise beans have to be mapped against the user groups in the target environment.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 EJB 3.0//EN" "http://www.sun.com/software/appserver/dtds/sun-ejb-jar_3_0-0.dtd">
<sun-ejb-jar>
  <security-role-mapping>
    <role-name>admin</role-name>
    <group-name>admin-group</group-name>
  </security-role-mapping>
  <security-role-mapping>
    <role-name>team-lead</role-name>
    <group-name>team-lead-group</group-name>
  </security-role-mapping>
  <security-role-mapping>
    <role-name>developer</role-name>
    <group-name>developer-group</group-name>
  </security-role-mapping>
  <security-role-mapping>
    <role-name>manager</role-name>
    <group-name>manager-group</group-name>
  </security-role-mapping>
  <enterprise-beans/>
</sun-ejb-jar>

In the above configuration file, we have mapped the roles ‘admin’, ‘team-lead’, ‘developer’, ‘manager’ to the groups ‘admin-group’, ‘team-lead-group’, ‘developer-group’ and ‘manager-group’ respectively. Note that creation of user and user groups will vary across application servers.

Application client

The application client is given below. It does the job of invoking various services defined in the enterprise beans like creating, assigning and completing tasks.

package taskmanager;

import java.util.List;
import javax.ejb.EJB;
import net.javabeat.articles.ejb3.security.annotations.TaskEntity;
import net.javabeat.articles.ejb3.security.annotations.TaskEntityFacadeRemote;

public class Main {

    @EJB
    private static TaskEntityFacadeRemote taskEntityFacade;

    public static void main(String[] args) {

//        deleteAllTasks();

//        createTasks();
        Long taskIds[] = viewAllTasks();
//
//        assignTasks(taskIds, "abc");
//        viewAllTasks();
//
//        completeTasks(taskIds);
//        viewAllTasks();
    }

    private static void deleteAllTasks(){

        taskEntityFacade.deleteAllTasks();
    }

    private static void createTasks(){

        taskEntityFacade.createTask("Create new feature", "To create a new feature for some project");
        taskEntityFacade.createTask("To fix performance issue", "To fix performance issue");
    }

    private static Long[] viewAllTasks(){

        Long[] taskIds = new Long[2];

        System.out.println("View All Tasks");
        List allTasks = taskEntityFacade.getAllTasks();
        for (int index = 0; index < allTasks.size(); index ++){

            TaskEntity aTaskEntity = allTasks.get(index);

            String str = aTaskEntity.getId() + ",";
            str = aTaskEntity.getName() + ",";
            str = str + aTaskEntity.getDescription() + ",";
            str = str + aTaskEntity.getStatus() + ",";

            taskIds[index] = aTaskEntity.getId();
            System.out.println(str);
        }
        return taskIds;
    }

    private static void assignTasks(Long[] taskIds, String assignee){

        for (int index = 0; index < taskIds.length; index ++){

            Long taskId = taskIds[index];
            System.out.println("Task Id is " + taskId);
            taskEntityFacade.assignTask(taskId, assignee);
        }
    }

    private static void completeTasks(Long[] taskIds){

        for (int index = 0; index < taskIds.length; index ++){

            Long taskId = taskIds[index];
            taskEntityFacade.completeTask(taskId);
        }
    }
}

Note that when invoking an EJB method that is secured, a dialog box will be shown prompting for username and password. The username and the password will be compared with the users that are already configured in the application server.

Programmatic Security

In most of the situations, it is sufficient for applications to take the advantage of declarative security services provided by the container. However, in certain other situations, this may not be the case. For example, let us assume the scenario of a registered user downloading files from a portal. The download operation has to check whether the user belongs to the group of registered users for which case the declarative security case is sufficient. Now, let us assume that we want to prevent the user from downloading resource that has exceeded the maximum limit of ten. Now we run into a dynamic condition and based on that we allow or deny a particular operation to the user. This is where the programmatic security comes into picture.

Demonstration

We will take the example of user trying to perform various operations on a blog for illustrating programmatic security. Considering the operations – replying to a post in the blog and downloading files from the blog. A user is allowed to reply to a post only when he is a registered user and the number of posts created by the user is more than 10. Similarly for the download operation, other then being a registered user, the user has to be a premium user to perform the download operation.

User Entity

The user entity model is given below. Note that we have made use of JPA annotations to indicate that this model is a JPA entity.

package net.javabeat.articles.ejb3.security.programatic;

import java.io.Serializable;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity(name="User")
@Table(name = "T_USER")
public class User implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String userId;
    private boolean isPremiumUser;
    private int postsCount;

    public boolean getIsPremiumUser() {
        return isPremiumUser;
    }

    public void setIsPremiumUser(boolean isPremiumUser) {
        this.isPremiumUser = isPremiumUser;
    }

    public int getPostsCount() {
        return postsCount;
    }

    public void setPostsCount(int postsCount) {
        this.postsCount = postsCount;
    }

    public String getUserId() {
        return userId;
    }

    public void setUserId(String userId) {
        this.userId = userId;
    }

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (id != null ? id.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        if (!(object instanceof User)) {
            return false;
        }
        User other = (User) object;
        if ((this.id == null && other.id != null) || (this.id != null && !this.id.equals(other.id))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return "net.javabeat.articles.ejb3.security.programatic.User[id=" + id + "]";
    }

}

We have declared ‘userId’, ‘isPremiumUser’ and ‘postsCount’ as the properties for the User Entity.

User Remote Interface

The remote user interface for performing various operations such as replying to a posting and downloading resources from a blog is given below.

package net.javabeat.articles.ejb3.security.programatic;

import java.util.List;
import javax.ejb.Remote;

@Remote
public interface UserFacadeRemote {

    void deleteAllUsers();

    void create(User user);

    void create(String userId, boolean premiumUser, int postsCount);

    void downloadAttachment(Long userId);

    void edit(User user);

    void remove(User user);

    User find(Object id);

    List findAll();

    void replyPost(Long userId, String comment);
}

Note that other than the service methods for creating users, replying to a post and downloading resources, it contains the regular functionalities for performing CRUD operations. Note that we are not going to provide real-time implementations for the service methods.

User Interface Implementation

The implementation class for the above remote interface is given below. Note that the declared role for this class is ‘registered_role’. Note that through dependency injection, we have injected the objects EntityManager and SessionContext. In the replyPost() method, other than checking whether the user invoking the method belongs to the desired role, additional check is performed for the number of created posts.

package net.javabeat.articles.ejb3.security.programatic;

import java.security.Principal;
import java.util.List;
import javax.annotation.Resource;
import javax.annotation.security.DeclareRoles;
import javax.annotation.security.RolesAllowed;
import javax.ejb.SessionContext;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
@DeclareRoles({"registered_role"})
public class UserFacade implements UserFacadeRemote {

    @PersistenceContext
    private EntityManager em;

    @Resource
    private SessionContext context;

    public void deleteAllUsers(){

        List allUsers = findAll();
        if (allUsers != null){
            for (User user : allUsers){
                remove(user);
            }
        }
    }

    public void create(String userId, boolean premiumUser, int postsCount) {

        User newUser = new User();
        newUser.setIsPremiumUser(premiumUser);
        newUser.setPostsCount(postsCount);
        newUser.setUserId(userId);

        em.persist(newUser);
    }

    public void create(User user) {
        em.persist(user);
    }

    public void edit(User user) {
        em.merge(user);
    }

    public void remove(User user) {
        em.remove(em.merge(user));
    }

    public User find(Object id) {
        return em.find(User.class, id);
    }

    public List findAll() {
        return em.createQuery("select object(o) from User as o").getResultList();
    }

    @RolesAllowed("registered_role")
    public void replyPost(Long userId, String comment){

        Principal principal = context.getCallerPrincipal();
        System.out.println("Name " + principal.getName());
        if (context.isCallerInRole("registered_role")){

            User userObject = find(userId);
            if (!(userObject.getPostsCount() > 10)){
                throw new SecurityException("Post creation not allowed");
            }else{
                // All creating posts
            }
        }
    }

    @RolesAllowed("registered_role")
    public void downloadAttachment(Long userId){

        Principal principal = context.getCallerPrincipal();
        System.out.println("Name " + principal.getName());
        if (context.isCallerInRole("registered_role")){

            User userObject = find(userId);
            if (!(userObject.getIsPremiumUser())){
                throw new SecurityException("Downloading allowed only for premium users");
            }else{
                // Allow to download the attachment
            }
        }
    }
}

For the downloadAttachment() operation, we are checking if the invoking user is a registered user and if the user is a premium user. We are making use of the Context object here to find out if the invoking user is in the desired role through the ‘isCallerInRole()’ method. Other methods of interest in the Context object with respect to the Security is the getCallerPrincipal() method which provides an encapsulatation of the user credentails that is created in the EJB container.

Conclusion

This article started with explaining the various security aspects supported by EJB Security. It then explained the declarative security model with the list of annotations supported, which was then followed by a demonstration. Since declarative security model may not be flexible and suitable in all scenarios, programmatic mode of security is also explained with the help of an example.

also read:

• EJB Interview Questions
• Managing transactions in EJB 3.0
• Using CDI with EJB 3.0
• J2EE Books