As you can see from the preceding code, there is no indication about the location of the server where the EJBs are running. If you don't want to specify this by code, the simplest thing you can do is add the jboss-ejb-client.properties file in the client's classpath.

The contents of the jboss-ejb-client.properties file are as follows:

endpoint.name=client-endpoint
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default 
remote.connection.default.host=localhost
remote.connection.default.port = 4447

And here's some explanation to this file—the optional endpoint.name property represents the name that will be used to create the client side of the endpoint. If it is not specified, it will default to config-based-ejb-client-endpoint.

The remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED property enables the encryption of the XNIO connection, otherwise plain text will be used. (In Chapter 11, Securing JBoss AS 7 Application, we will discuss using SSL to secure the connection between the client and the server.)

The remote.connections property can be used to define a list of logical names that will be used for connection purposes by the remote.connection.[name].host and remote.connection.[name].port attributes. If you'll define more than one connection, as in the following example, the connections will be split across the various destinations:

remote.connections=host1,host2 
remote.connection.host1.host=192.168.0.1
remote.connection.host2.host=192.168.0.2
remote.connection.host1.port = 4447
remote.connection.host2.port = 4547

The default port used by the remoting framework is 4447. You can, however, set a custom port using the CLI interface. For example, in order to set it to 4457, you can issue the following command:

/socket-binding-group=standard-sockets/socket-binding=remoting/:write-attribute(name=port,value=4457)

If you are running this example from a client that is located on the same machine as the application server, the remoting framework will silently allow communication between the client and your EJBs classes. On the other hand, for a client located on a remote system, you would require to provide authentication for your requests. In order to add an application user, launch the add-user.sh (or add-user.bat) script that is located under JBOSS_HOME/bin:

Here's a transcript of a user creation example:

What type of user do you wish to add?
 a) Management User (mgmt-users.properties)
 b) Application User (application-users.properties)
(a): b

Enter the details of the new user to add.
Realm (ApplicationRealm) :
Username : ejbuser
Password :
Re-enter Password :
What roles do you want this user to belong to? (Please enter a comma separated l
ist, or leave blank for none) :
About to add user 'ejbuser' for realm 'ApplicationRealm'
Is this correct yes/no? yes
Added user 'ejbuser' to file 'C:jboss-as-7.1.1.Finalstandaloneconfigurationapplication-users.properties'

The previous user will be added for you in the application-user.properties file located in your configuration folder.

This file contains the default security realm named ApplicationRealm. This security realm uses the following format to store passwords:

username=HEX( MD5( username ':' realm ':' password))

With the password I've just entered, the fill will contain the following entry:

ejbuser=dc86450aab573bd2a8308ea69bcb8ba9

Now insert the username and password information into jboss-ejb-client.properties:

remote.connection.default.username=ejbuser
remote.connection.default.password=ejbuser123          

Now, with all the previous information in the right place, you will be able to connect to your EJB application from a client that is not residing on the same machine as the server.

To create a timer, the bean invokes one of the create methods of the TimerService interface. These methods allow for either single-action, interval, or calendar-based timers to be created.

The simplest way of getting a TimerService instance is to use resource injection. For example, in the TheatreBox singleton EJB, we will use the @Resource annotation to inject a TimerService object:

@Resource
TimerService timerService;
long duration= 6000;

The duration specifies the time (in ms) when the single timer is fired. The method that will fire the timer will use the TimerService instance to invoke the createSingleActionTimer, passing the duration and an instance of the TimerConfig class as an argument, which may optionally contain some basic information (such as a description of the timer).

public void createTimer(){
    timerService.createSingleActionTimer(duration, new TimerConfig());
}

Next, we will create a callback method named timeout and use the @Timeout annotation on top of the method. In the timeout method, we could, for example, reinitialize our singleton by invoking the setupTheatre method. Nothing fancy; however, this should give you an idea of how to get working with a single action timer.

@Timeout
public void timeout(Timer timer){
  logger.info("Re-building Theatre Map."); 
  setupTheatre();
}

If you want to schedule timed notifications at fixed intervals, the simplest way is to use the @Schedule annotation. The @Schedule annotation takes a series of comma-delimited settings to express a time or set of times, much as the Unix cron utility does. Each setting corresponds to a unit of time such as an hour or minute. A simple repeating event occurring every minute can be expressed using the @Schedule annotation as follows:

@Schedule(second="0", minute= "*", hour= "*")

You can find some more details about building the time string at http://docs.oracle.com/javaee/6/tutorial/doc/bnboy.html.

For the purpose of our example, we will create a stateless session bean that will act as an automatic buying system and therefore buy tickets at our ticketing store. So we will add one competitor in our quest for the best seat at the theatre!

@Stateless 
public class AutomaticSellerBean
{
  private final static Logger logger = Logger.getLogger(AutomaticSellerBean.class.getName()); 
  
  @EJB private TheatreBox   theatreBox;

  @Resource
  private TimerService timerService; [1]

  @Schedule(dayOfWeek = "*", hour = "*", minute = "*", second = "*/60",year="*", persistent = false) [2]
  public void automatiCustomer()
  {
     int seatId = findSeat();
        
       if (seatId == -1) {
         cancelTimers();
         logger.info("Scheduler gone!"); 
         return ; // No more seats
       }
          
         theatreBox.buyTicket(seatId); [3]
             
           logger.info("Somebody just booked seat number "+seatId +1); 
  }

  private int findSeat() {
    ArrayList<Seat> list = theatreBox.getSeatList();
    for (Seat s: list) {
      if (!s.isBooked()) {
        return s.getId() -1;
      }
    }
    return -1;
  }
  private void cancelTimers() {    [4]
    for (Timer timer : timerService.getTimers()) {
      timer.cancel();
    }
  }
}

The first thing we should account for is the resource injection of the Timer object [1] that will be used in the cancelTimers method [4] to cancel all the scheduling when the theatre is fully booked.

Next, pay attention to the Schedule annotation [2] we are using that will fire a nonpersistent timer each minute.

When the action is fired, the automaticCustomer method starts scanning the theatre seats for an available seat. (Nothing too complex; findSeat starts looking from the first available seat.)

Finally, if there are seats still available, the buyTicket method [3] of the TheatreBox singleton will be used to short circuit the purchase of the seat (obviously, we won't need to check the money for our automatic customer).

If you don't care about the async result, you can just have your async method return void. For this purpose, we will add a new method named bookSeatAsync to TheatreBookerBean and simply tag it as @Asynchronous.

@Asynchronous
public void bookSeatAsync(int seatId) {

  Seat seat = theatreBox.getSeatList().get(seatId);

  if (seat.isBooked()) {
    throw new SeatBookedException("Seat Already booked!");    }

  if (seat.getPrice() > money) {
    throw new NotEnoughMoneyException("You don't have enough money to buy this ticket!");  }

  logger.info("Booking issued");
  theatreBox.buyTicket(seat);

  money = money -seat.getPrice();
        
   logger.info("Booking successful");

}

As you can see, this method does not return anything; we will need to use some other instruments to check if the transaction was completed successfully. For example, we can check from the theatre list if the seat has been booked successfully.

The other available option consists of returning a java.util.concurrent.Future object that can later be inspected by our clients so that they know the outcome of our transaction:

@Asynchronous
public Future<String> bookSeatAsync(int seatId) {

  Seat seat = theatreBox.getSeatList().get(seatId);
  if (seat.isBooked()) {
    return new AsyncResult<String>("Seat "+seatId+" Already booked!");
  }
  if (seat.getPrice() > money) {
    return new AsyncResult<String>("You don't have enough money to buy this ticket!");
  }

  logger.info("Booking issued");
  theatreBox.buyTicket(seat);
  money = money -seat.getPrice();

  return new AsyncResult<String>("Booked seat: "+seat+" - Money left: "+money);
}

In this case, calls to the asynchronous bookSeatAsync method simply result, behind the scenes, in a Runnable Java object being created that wraps the method and parameters you provide. This Runnable object is given to an Executor object that is simply a work queue attached to a thread pool.

After adding the work to the queue, the proxy version of the method returns a Future implementation that is linked to Runnable that is now waiting on the queue.

When Runnable finally executes the bookSeatAsync method, it takes the return value and sets it to Future, making it available to the caller.

When dealing with Future objects, the client code needs to be adapted. As a matter of fact, in standard synchronous calls we used exceptions to intercept some events, such as when the customer does not have enough money to complete the transaction. When using Future calls, there's a change in this paradigm. The call to the asynchronous method is detached from the client; however, we have the option to check if the Future work has been completed with the isDone method issued on the Future return value.

For this purpose, let's add a bookasync command that will issue asynchronous booking and a mail command that will simulate the reading of the outcome by e-mail:

Future<String> futureResult = null; [1]
. . . . .
else if (command.equals("bookasync")) {

  String text = IOUtils.readLine("Enter SeatId ");
  int seatId = 0;
         
    try {
      seatId = Integer.parseInt(text);
    } catch (NumberFormatException e1) {
            
      logger.info("Wrong seatid format!");
      continue;
    }
    try {
      Thread.sleep(10000); // Simulate time consuming task
    } catch (InterruptedException e) {
       
      e.printStackTrace();
    }     
                        
    futureResult = book.bookSeatAsync(seatId-1); [2]
    logger.info("Booking issued. Verify your mail!"); 
  } 
  else if (command.equals("mail")) {
    
      if (futureResult == null || (!futureResult.isDone())) { [3]
      logger.info("No mail received!");
      continue;
    }
    else {
      try {
        String result = futureResult.get();
        logger.info("Last mail received: "+result);
           
      } catch (InterruptedException e) {        
          e.printStackTrace();
      } catch (ExecutionException e) {         
          e.printStackTrace();
      }
      continue;
    }
}

As you can see from the previous code snippet, we issue an asynchronous booking [2] and bind it with the futureResult instance [1]. We have introduced a pause of 10 seconds to complete the booking so that later on we can check if the work has been completed by checking the isDone method [3] of the futureResult object.

Here is a snapshot of our richer client application: