The service layer is the nucleus of the application; it is where the business logic resides. The business logic encapsulates the rules that define the working application and it is where a significant amount of development time is spent. Enhancements, changing requirements, and ongoing maintenance will usually require modifications to the service layer. Business rules may include such operations as restricting access to specific roles, security constraints, calculations, validations, compliance checks, and logging, to name a few.
Some typical business logic examples could include the following:
- Only administrators can change the country assigned to a user
- Administrators can only change a user to a country in their own geographical region
- If payment is made in a currency other that USD, an exchange rate premium of 5 percent must be added
- An Australian zip code must be exactly four digits
- Reassigning an invoice to the Canadian affiliate can only be performed during East Coast business hours
- Each new invoice must be logged onto a separate file, if not originating from one of the five largest business clients
The core business rules we will be implementing in this chapter are far simpler:
- A user must be authenticated prior to accessing any resources
- Only a 3T administrator can maintain the 3T configuration
- Users may only update and add task logs for themselves
It is important to have clearly defined entry points for service layer operations. This will again be achieved through Java interfaces that define the operations exposed by the service layer. Clients of the service layer will interact with the business logic through these interfaces, not the implementing classes.
For similar reasons, it is important that the service layer itself is decoupled from the underlying DAO implementation. We have already achieved this by ensuring that our DAO layer exposes its persistence operations through interfaces. The service layer should know nothing about how the persistence layer is implemented and there should not be any persistence operations coded within the service layer classes.
Enterprise application clients come in many different forms, most commonly web browsers and web services. However, there may be other types of clients; for example, standalone servers using RMI. In all cases, the service layer must be as independent as possible of the client implementation. As such, the service layer should never incorporate presentation logic and should know nothing about how the data is used. The following diagram illustrates where the service layer sits in the overall application structure:
The service layer interacts with the data access layer via domain objects. There is a clear demarcation of roles with this design. The DAO layer is responsible for interacting with the database and the service layer has no knowledge of how this is done. Likewise, the DAO layer has no interest in how the domain objects are consumed. This is the role of the service layer where business logic controls decide what can and should be done with the domain objects.
A well-architected service layer should have a simple interface that allows any type of request handling layer to work with the underlying application business logic. If a list of Company entities are requested from the service layer, the exposed interface method that provides this functionality does not need to know whether the list is being used to render a web page, to execute a web service call, or to send an e-mail with an attached Excel spreadsheet. The request handling layer will be discussed in detail in the following chapter.