Separating Services
Long before distributed applications and the Internet came to the forefront of technology, the layers of an application were thought best kept distinct and separate. Commingling of, for example, the data access and business logic led to “fragile” applications that were difficult to maintain and to understand. However, very few applications followed this approach—until the technology horizon changed and client/server and distributed computing became possible.
The term legacy application traditionally has been applied to mainframe-centric applications. However, many applications built in the past seven or eight years that wear the client/server and/or distributed label are also legacy applications because the logical layers of the applications were not separated in their design or implementation. Further exacerbating this situation is the nature of the unique graphical front end used to build many of these applications, which makes maintaining them more difficult. Again, who would have thought in 1996 that the predominant user interface of choice in the new millennium would be a Web browser? Even today we find the user interface choices still evolving as the advent of wireless devices such as cell phones and PDA (personal digital assistant) devices receives quite a bit of attention.
Although the concepts of layering functionality are easy to comprehend, we absolutely must make the application architecture extensible and isolate the logical layers of the application. There are three logical layers:
Presentation Services
Business Services
Data Services
Table 8-1 lists the scope and objective of each one.
The Presentation Services layer traditionally has been graphical in nature (for the typical reader of this book), but it also may take the form of a report or even an external feed to a particular interface. The GUI (graphical user interface) layer evolves with time. If the Presentation Services layer supported by a given application had been separate from the Business Services layer when originally designed, snapping on a new front end would have involved minimal pain. Unfortunately, for most applications a better solution was to scrap what was there and start over, and that's what many organizations did.
| Layer | Scope | Objectives |
|---|---|---|
| Presentation Services | Data presentation
Data acceptance Graphical user interface | Ease of use
Natural, intuitive user interactions Fast response times |
| Business Services | Core business rules
Application/dialog flow control Data integrity enforcement | Rigid enforcement of business rules
Preservation of investment in code Reduced maintenance costs |
| Data Services | Durable data storage and retrieval
DBMS (database management system) accessed via API Concurrency control | Consistent, reliable, secure database
Information sharing Fast response times |
The Business Services layer, and to some degree the Presentation Services layer, will likely be the most dynamic of all of the layers. Years of experience with software development have taught us that an application's rules and functionality change the most. And if the Business Services layer is isolated from the other two layers, changes to it will affect the application less. When possible, the Business Services layer should be void of all user interface and data access logic. I can't tell you how many lines of AWT (Abstract Windows Toolkit) and Swing code I have had to debug that were so intertwined with business logic that it was easier just to start over.
The Data Services layer often will be the most static aspect of the application. The data structures and their relationships are usually less effected by changes compared to the Business Services layer. Later in this chapter we explore the Data Access Services layer closely and segment it further, separating the logical request for data, such as a Structured Query Language (SQL) request, from the physical access technology, such as a Java Database Connectivity (JDBC). Constructing an application using good object-oriented design concepts can further insulate the layers. Note that the partitioning design presented in this chapter for the different layers relates to the shadow use-case called Architecture Infrastructure that was discussed in Chapter 4.