Layered Architectures The objectives of this chapter are: To understand the principles and importance of Layered Architectures To explain the structure of application development in Java

You may have realized that Cohesion is one of the most important aspects of Object Oriented Software Development Classes have few, well defined responsibilities Each class's responsibilities should be logically related When classes are developed in this manner, the complexity of a system shifts from the classes to the communication between objects Classes are not complex How objects communicate becomes more complex so it must be managed Managing communication between objects now becomes an added responsibility for the system Understanding the communication between discrete components is defined as architecture Many design patterns specifically address these types of problems Cohesion

Unfortunately, calling oneself a "Software Architect" is a new "in" term. Many people call themselves software architects, but do not develop architectures Architectures must be defined early within the development process; however, they must remain flexible. The initial architecture is almost always wrong, if it cannot be adjusted, the project will fail. Early architectures can be regarded as "rough cuts". They aren't correct, but they drive the process forward. Most successful architectures are based upon a layered approach The Gartner 3-layer model is a good starting point Layers are logical Each layer has a defined purpose The communication between layers is well-defined Architecture

The Gartner group has identified 3 types of logic which exist within the typical business application Presentation: How is data presented to the User Application: How is data processed Data Management: How is data stored and retrieved In order to have flexibility between the layers, the layers must be loosely coupled rather than tightly coupled. The Gartner 3-layer Model -Revisited Presentation Logic Application Logic Data Management Logic

It is important to remember that each layer is logical "Presentation" is a high level layer The presentation layer can be composed of many sub-layers, each of which having a lower level of abstraction Breaking down high level layers into logical sub layers is the essence of N-Tier architecture: N-Tier Presentation Logic Application Logic Data Management Logic Gui System Log Gui Controllers Transaction Processing AuditingSecurity Data Access Input Validation User Management Persistence Management Business Rules

The previous slide shows that architectures can have high level components and low level components. Architecture is always higher level than code As one goes deeper into the architecture, one will eventually identify objects. In order for this approach to work, the communication between each layer must be defined. One must define how the communication is to occur Are the layers deployable within an Intranet? Are the layers deployable across the Internet? One must define what is to be communicated (each layer must have an interface) Which layers are coupled? What are the functional requirements of a layer? What messages are sent between layers? Communication between Layers (Tiers)

Many people remember the old days of spaghetti code Subroutine calls from everywhere, to everywhere This is a symptom of focusing ones attention at a very low level of abstraction This happens when one is focused on the code and not the design Unfortunately, it is possible to create spaghetti objects Every object communicates with every other object Coupling is too high If the domain model contains cohesive objects, coupling is likely to remain low. Hint: keep your objects cohesive If the communication between layers is defined at the high level, the coupling between layers is likely to remain low Hint: define communication between layers at a high level of abstraction Cohesion and Coupling issues

If the communication between layers is defined at the high level, the implementation should follow suit. Objects communicate through messages. There should be messages (methods) which match the high level definitions of the interface But how do we map high level messages into low level actions? Controller objects fulfil this purpose. Controller objects have a high level interface Controller objects don't actually do the work to fulfil the interface Controller objects delegate the responsibility of fulfilling a request to other objects Controllers coordinate other objects Each layer will have one or more controller objects The interface for the layer is defined by the interface implemented by the layer's controller objects. Implementing Layer Communication

Layer Example Employee Info User clicks employee name in employee list diplayEmployeeInfo(id = 5) Employee Manager > getEmployee(id = 5) EmployeeList Listener > getObject("Employee", id=5) EmployeeTable SqlGenerator generateSql(id=5) executeSQL() resultSet EmployeeBuilder buildEmployeeObject(resultSet) Table Manager > EmployeeList DBController > displayEmployee

When an application executes, objects are stored in memory When the application terminates, those objects disappear Most business entities require persistence They must be accessible upon successive executions of the application Object persistence could be implemented using object serialization Many businesses have invested large amounts of money in relational (sql) databases It is possible to put objects into a database The data within a class model is often equivalent to a 3 rd normal form data model (inheritance must be addressed) Dealing with Object Persistence

Object Persistence: Layers Application Layer Process Employee Objects Data Access Layer Map Objects to Relational DB (generate SQL) Map Relational Tables to Objects (generate SQL) Database Connectivity Layer Manage connections to database possibly connection pool getObject() storeObject() insert select update delete This layer only ever deals with Objects. NO SQL This layer maps between the object world and the relational DB world This layer manages data