JavaDB:Introduction to layered architectures
Work in progress
This chapter is work in progress. Remove this section when the page is production-ready.
This chapter introduces the concept of layered architecture for a simple Java application. The idea is to use abstraction layers to inoculate client code from changes in other classes.
We use Java interfaces to create abstraction layers. In the lecture example, we show a simple application for retrieving data about students from some data storage. The point of the lecture is to show you a strategy for keeping your code small and simple by focusing on the abstractions in the system.
The data about students are stored in some kind of storage (e.g. a database). But when we write the application, we don't want to concern ourselves with the details of what technology is used for storing and retrieving the student data. We instead focus on the abstraction of a StudentStorage.
For this, we use an interface called
StudentStorage which only delcares two simple methods, one for fetching a
List<Student> of all students, and one for fetching one single
Student based on an ID provided as an argument.
Of course, we need a concrete class which implements the interface for doing the actual work of fetching the
Student objects from e.g. a database.
But we use a storage object of the interface type, and we get it from a so called factory class,
StudentStorageFactory. This class implements a simple factory (it is a so called design pattern) which decides what concrete class to use for the student storage.
The factory, in its first simple version simply instantiates a
StudentStorageDB object and returns a reference to it of
StudentStorage type (the interface type).
In this way, our small application doesn't know and doesn't need to concern itself with knowing too much about the way in which the feting of data takes place. It can focus on the abstraction of a storage with the two simple methods.
If we, later on, change the way in which the student data is changed, we only need to change the factory but never the application class, since it only uses the interface type.
So our simple application only needs to import a few classes concerned with storage. If we switch from using databases to cloud storage of the data, or perhaps file storage, the application isn't affected. The factory would simply return a reference to an object of some other class which implements the interface. Since we are programming against an interface, we only use the methods declared in the interface, and it is up to the new class to implement the fetch all students and fetch student by id methods using some new technology.
This is an introduction to layered architecture. We can call the abstractions (interface types) layers and think about it as barriers protecting our application from changes in lower layers (for instance changes in classes closer to the hard ware or technologies such as database connectivity).
There are some usage of JDBC (Java database connectivity) in the example, but you don't need any prior knowledge of JDBC to understand the basic idea of the lecture. It is good, however, if you read up on (or refresh your knowledge) on Java interfaces. We have a chapter dedicated to interfaces in our book Programming with Java.
Note that our use of the word "layer" refers to abstractions within one application, often implemented using interfaces and packages for loose coupling between classes and separation of concerns.
There is a related term (sometimes used interchangeably with layers) called "tiers". In our view, tiers are used to achieve the same thing but takes things up one notch. Tiers, in our understanding, refer to components which can reside on different hardware and are communicated with using the network (and some protocol).
In theory, we could use our simple example with tiers. In that case, we'd communicate with the Storage component using some network protocol, e.g. JSON or XML over HTTP. We'd still get separation of concerns and the other benefits (we are protected from changes in lower tiers/layers).
The way we use the terms, "layers" refer to using interfaces and packages in the same application (running in the same process on the same JVM) and "tiers" when we call components over the network (giving the possibility to put components on a dedicated server for scalability).
Slides and videos
- Java - Tiers (6 parts), Introduction to layers (PDF)
- Java - introduktion till lagrad arkitektur (Swedish) (6 parts), Introduction to layers (PDF)
The example application from the lecture can be found here: (github). If you want to download it as a zip file you can use this link using a browser. To build, unzip and go down into the presentation-sources directory. Then do:
$ javac org/henrikard/student/main/Main.java && java -cp .:org/henrikard/student/resources/sqlite-jdbc-126.96.36.199.jar org.henrikard.student.main.Main
- DZone - When to Use Interfaces in Your Application
- Oreilly - Software architecture patterns - Layered architecture (requires login via e.g. gmail etc) - you can read it without loggin in using
w3m -dumpbut you'll miss the fancy diagrams and pictures
- Java.sys-con - Componentizing Applications with Layered Architecture
- UR1.ca link to google books - Enterprise Java Programming with IBM WebSphere
- - uml-diagrams.org - multi-layered-application example
- andromda.sourceforge.net - Application Architecture