Traditional Buy Versus Build Analysis

Auction Example Horizontal Services

Saying that every application requires the same types of horizontal services sometimes is too much of a generalization. However, you can usually find the same common services in most enterprise applications. For our auction site, we will cover the following horizontal services:

• Logging service

• E-mail support

Although we could have made a case for the properties service, we chose to implement the properties using the bean components and their respective JNDI environments. We don't have a great deal of configuration or property information and, therefore, didn't feel the need for an entire service related to obtaining property information. This is sometimes the case with horizontal services. You must evaluate the requirements for each individual application. The naming, messaging, persistence, and security have all been covered in previous chapters, so we will not be covering them here.

The next several sections describe what each of two horizontal services will do for the auction site, and we will go into some depth about how we develop the horizontal services that we need.

Auction Logging Service

All systems need the ability to log information about what events are taking place inside the application. These events can be things such as a debug statement that helps a developer debug a problem, an invalid login attempt by a user , or when there's some type of unrecoverable system exception. Normally, you can group the types of things to log into four categories:

• Debug messages

• General information messages

• Warning messages

• Errors or critical messages

Although there are a few other classifications that might be used, these are the most common types of messages that need to be logged. Many applications might log using the println method on the System.out stream like this:

 System.out.println( "Some debug message" ); 

However, hopefully after reading the section "Why Are Horizontal Services Needed?" in this chapter, you understand why this is not the best way to approach the solution.

In a distributed environment, this approach is even worse . You might want all the messages from the Web tier to be logged to the same place as the application tier . This typically can't happen with the println method because normally they are running in different containers and have different default output locations. You might also need to change where the log messages are going dynamically (without bringing the server down). This is definitely much harder to do if you are using println s. Not every application needs to log messages from all tiers into the same storage location. So you might consider making this a feature that can be turned on and off depending on the application.

The idea here is that we want to build a logging API that will be simple for the clients that need to log messages and also give us the flexibility to change where the log messages go and also change which type of log messages actually get logged. We might want to turn off debug messages for a production environment for performance reasons. We would like to have the ability to do this without having to recompile the source code.

Logging Support Provided by an EJB Server

Many EJB servers provide some type of logging support. Because logging didn't exist as part of the core Java language until the 1.4 version, the support for logging has generally been proprietary.

Note

The Java SDK 1.4 (code-named Merlin) will include a logging API as part of the core Java language. The Java Specification Requests (JSR-47) on the Sun Web site discusses what's going to be included in the logging API. You can find the JSR for logging at the following URL:

http://java.sun.com/aboutJava/communityprocess/jsr/jsr_047_log.html

The Java Logging API is only in beta at this time, and it is discussed briefly later in this chapter.

There's nothing wrong with using the EJB server provider's logging service or a third-party solution as long as you build a common set of APIs on top of it and your components use these interfaces and not the provider's. In this way, you will only need to modify the logging SPI when switching to a different EJB vendor. We'll get into the APIs for the logging service later, in the section "Building the Auction Logging Service."

Auction E-Mail Support Service

Another requirement for a typical enterprise application is to send and receive e-mail messages. More often than not, sending e-mail messages is supported more than receiving them, but it's possible to receive an e-mail message and programmatically parse it and possibly take an action based on information within it. You might also just store it into a database for another application to process it. For our auction example, we are only going to be concerned with sending e-mail messages when an auction participant wins an auction or when they become a trailer in an auction. Keep in mind that because we are only building a horizontal service here, we should not have vertical-specific functionality in this service.

What we are building is a service that can send e-mail messages. This horizontal service doesn't care about the purpose of the e-mail message. That's up to the vertical components to determine.

E-Mail Support Provided by an EJB Server

Many EJB servers provide some type of support for sending e-mail messages through the JavaMail API. Using JavaMail to send e-mail messages is actually part of the J2EE and therefore required for a compliant EJB server. The problem is that JavaMail is quite extensive , and you probably don't want each client to have to learn the API and figure which methods they should be using.

Therefore, what you really should do is provide a light, thinner set of APIs on top of the JavaMail APIs and let your client components use these interfaces. For example, you might not want to support attachments for a first release. This might be difficult to prevent if each client component has access to the JavaMail API. However, if you provide a layer on top of this, you can remove this capability so that the client component can't use it, and then add that functionality in later when you're ready for it. We'll see how to do this later when we start defining the e-mail APIs for the auction example.

Sending Pager Messages

We want to touch on the functionality of sending pager messages only briefly. E-mail is just one form of notification. You might also need to support sending pager messages when certain events happen in the system. For example, you might need to send an e-mail and a page to an administrator if the system goes down. The administrator might be responsible for ensuring that the system is restarted. If you only plan for certain types of notifications, you will paint yourself into a corner when a new one is necessary. This really goes to the point of building a resilient application. You definitely want to ensure that your design is flexible enough to handle new requirements with little change to the overall system. You obviously can't anticipate everything, but you should try to make the attempt at uncovering possible new features. Be on the lookout for upcoming requirements, look at the project plan, and think about the future business needs of the product. You can save yourself some pain later by doing the proper planning early in the life cycle.