• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Web application architecture
 

Web application architecture

on

  • 377 views

How to build robust web applications by isolating different areas of concern into different layers. The typical four-layer architecture is presented (the presentation layer, the service layer, the ...

How to build robust web applications by isolating different areas of concern into different layers. The typical four-layer architecture is presented (the presentation layer, the service layer, the persistence layer and the domain model) along with an in-depth discussion on the role and responsabilities of each single layer.

Statistics

Views

Total Views
377
Views on SlideShare
374
Embed Views
3

Actions

Likes
2
Downloads
0
Comments
0

1 Embed 3

http://ease-the-computation.haunted.io 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Web application architecture Web application architecture Presentation Transcript

    • Web application architecture Ilio Catallo – Politecnico di Milano ilio.catallo@polimi.it
    • Outline ¤  Layered web applications ¤  Domain model ¤  Service layer ¤  Persistence layer ¤  User interface layer ¤  Web layer 2
    • Layers of abstraction
    • Web applications are made of layers ¤  Web applications are broken down into a series of layers, so that each problem domain is isolated in its own layer ¤  Example: the problem of persisting data is isolated in the persistence layer Layers are a discrete, orthogonal area of concern within an application 4
    • Web applications are made of four layers ¤  Typical Java-based web applications have at least four layers of abstraction Service layer Persistence layer Presentation layer Domainmodel 5
    • Communication between layers ¤  Communication between layers is from top to bottom Service layer Persistence layer Presentation layer Domainmodel talks to… talks to… 6
    • Execution flow through layers ¤  Thinking in layers can help conceptualize the flow through an application Service layer Persistence layer Presentation layer Domainmodel “down into persistence” “back up to the user interface” 7
    • Isolating layers increases flexibility and testability ¤  Isolating problem domains (e.g., data persistence) into separate layers increases flexibility and testability ¤  Flexibility: Implementations of each layer can vary independently ¤  Testability: Decreasing the coupling between areas make it easier to test each part 8
    • Minimize dependencies between layers ¤  The isolation is accomplished by minimizing the amounts of dependencies between the layers ¤  It is a best practice to ensure that a layer is required only by one or two more other layers ¤  Rules of thumb: ¤  If a layer has too many dependencies, introduce another layer that incorporates all the dependencies ¤  avoid having one single layer required by many different parts of the application (apart for the domain model) 9
    • Layers are not physically isolated ¤  Remember: Even if layers are conceptually isolated, they are not necessarily physically isolated Service layer Persistence layer Presentation layer Domainmodel 10
    • Interface as layer contract ¤  The Java interface is the key enabler to build an application with layers ¤  The interface is a contract for a layer ¤  It enforces correct layer usage ¤  It hides the implementation details 11
    • Interfaces enforce correct layer usage ¤  When deciding how to structure our layers, we should try to identify a clear API for our system ¤  The API will be exposed through a Java interface ¤  Example: Service layer APIs public interface FlightService { List<SpecialDeal> getSpecialDeals(); List<Flight> findFlights(String queryString); } 12
    • Interfaces hide implementation details ¤  Defining interfaces and programming to interfaces provide low coupling between layers ¤  Interfaces hide clients from implementations at layer boundaries 13
    • Programming to interfaces ¤  Programming to interfaces: bind your code to interfaces instead of concrete/specific subclass implementations ¤  Example: you should write instead of List<T> myList = new ArrayList<T>(); ArrayList<T> myList = new ArrayList<T>(); myList is bound the the List interface myList is bound the the ArrayList implementation 14
    • Programming to interfaces ¤  In the second case, changing implementation for myList means changing all the code ¤  Conversely, in the first case changing the implementation will not break the rest of the code LinkedList<T> myList = new LinkedList<T>(); List<T> myList = new LinkedList<T>(); 15
    • DI containers fully realize implementation abstraction ¤  Take-home message: Interfaces provide low coupling between layers ¤  Problem: the full benefits could be hindered because the instantiation of concrete type is still required ¤  Solution: Spring DI container helps realizing the promise of implementation abstraction ¤  Because it handles the creation of the object instead of your application code 16
    • Domain model 17
    • Domain model ¤  The domain model is the most important layer in the application as it contains the business logic of the application Service layer Persistence layer Presentation layer Domainmodel 18
    • Domain model ¤  In other words, the domain model is the code representation of the business problem we are trying to solve Service layer Persistence layer Presentation layer Domainmodel 19
    • The domain model is made of domain objects ¤  The domain model consists of a network of interconnected domain objects A C B D 20
    • A domain object is a problem domain concept ¤  Each domain object corresponds to a concept from the application problem domain A C B D 21
    • A domain object is a problem domain concept ¤  That is, domain objects are specific to the application’s problem domain A C B D 22
    • Domain objects are the “nouns” of the application ¤  A popular technique to determine the domain model is to use the nouns in use case descriptions as domain objects A C B D 23
    • Domain objects are the “nouns” of the application ¤  In other words, the nouns that are used when describing the problem domain suggest domain objects A C B D 24
    • Airline travel web application ¤  Example: Airline travel web application ¤  Application concepts: ¤  Airport ¤  Flight ¤  FlightLeg ¤  SpecialDeal ¤  … 25
    • Airport class ¤  Airport class: public class Airport { private String name; private String airportCode; public Airport(String name, String airportCode) {...} // other getters } 26
    • FlightLeg class ¤  FlightLeg class: public class FlightLeg { private Airport departFrom; private Date departOn; private Airport arriveAt; private Date arriveOn; public FlightLeg(Airport departFrom, Date departOn, Airport arriveAt, Date arriveOn) {...} // other getters } 27
    • Flight class ¤  Flight class: public class Flight { private List<FlightLeg> legs; private BigDecimal totalCost; public Flight(List<FlightLeg> legs, BigDecimal totalCost) {...} public boolean isNonStop() {...} public long getTotalTravelTime() {...} // other getters } 28
    • Airline travel web application ¤  Hence, the resulting domain model is as follows: AirportFlightLegFlight 29
    • Domain model ≠ set of relationships ¤  It is important to note that business logic does not mean just a set of relationships between objects AirportFlightLegFlight 30
    • Domain objects have state and behavior ¤  As well as storing data, a domain model object should implement the business logic that operates on the data ¤  Domain objects should have both state and behavior Flight FlightLeg Airport state behavior 31
    • Assign behavior to domain objects ¤  Calculated values or derived answers should be answered by the object you are talking about ¤  Examples: ¤  Flight.getTotalTravelTime() (calculated value) ¤  Flight.isNonStop() (derived answer) 32
    • Anemic domain model ¤  Remember: classes contain state and behavior, do not forget to take advantage of that for your domain model ¤  A domain model that contains only state and relationships (but no behavior) is usually called an Anemic Domain Model 33
    • Take advantage of object oriented features ¤  Putting the business logic inside the domain objects makes it possible to harness the full power of OOP ¤  Examples: ¤  Inheritance ¤  Polymorphism ¤  Think about how to apply such common OO features to help solve the business problems 34
    • How to determine domain objects’ behavior ¤  To determine the behavior of each class in the domain model, we must identify its: ¤  Responsibility: what the class does, knows, or decides ¤  Collaborations: the other classes that it invokes in order to fulfill its responsibilities 35
    • Domain model ¤  The domain model is a layer that largely permeates the other layers Service layer Persistence layer Presentation layer Domainmodel 36
    • The domain model is a vertical layer ¤  The domain model is a vertical layer, as all the other layers have dependencies on the domain model Service layer Persistence layer Presentation layer Domainmodel 37
    • The domain model is the core of the application ¤  That is, even though each layer is responsible for its problem domain, all the layers live to serve the domain model Service layer Persistence layer Presentation layer Domainmodel 38
    • The domain model is an independent layer ¤  However, the domain model has no dependency on any other layer Service layer Persistence layer Presentation layer Domainmodel 39
    • Domain objects do not need dependency injection ¤  In general, the domain model will not need dependencies injected Service layer Persistence layer Presentation layer Domainmodel 40
    • Service Layer
    • Service layer ¤  The service layer exposes the use cases of the application to the user Service layer Persistence layer Presentation layer Domainmodel 42
    • The service layer calls the domain objects ¤  The service layer does so by coordinating calls to the domain objects A C B D Servicelayer 43
    • Façade pattern ¤  The service layer provides easy access to the use cases through the façade pattern A C B D Façade client classes 44
    • Single entry point ¤  The service layer represents the single entry point for the business logic A C B D Façade client classes 45
    • Exposing the service layer ¤  The business logic can then be exposed in different ways ¤  Web applications ¤  Web service ¤  Desktop application ¤  … ¤  This thanks to the fact that, no matter the mean, it is always the same business logic to be executed 46
    • Service layer methods are transactional ¤  Ideally, each application suse case should represent a single transactional unit of work that either succeed or fails ¤  Since the service layer is the single entry-point, we can apply security and transactional requirements ¤  By doing so, they become part of the core of the application 47
    • Airline travel web application ¤  Example: Airline travel web application ¤  FlightService interface: public interface FlightService { List<SpecialDeal> getSpecialDeals(); List<Flight> findFlights(String queryString); } 48
    • Methods are coarse grained and stateless ¤  Each method in the service layer should be coarse grained and stateless ¤  Coarse grained: a single method call will accomplish the entire use case ¤  Stateless: multiple calls into the method may happen concurrently without side effects 49
    • Service layer ¤  The service layer should never have a dependency on the presentation layer Service layer Persistence layer Presentation layer Domainmodel 50
    • Service layer ¤  However, the service layer depends on the persistence layer Service layer Persistence layer Presentation layer Domainmodel 51
    • Persistence layer
    • Persistence layer ¤  The persistence layer is responsible for interfacing with the underlying persistence mechanism Service layer Persistence layer Presentation layer Domainmodel 53
    • Persistence layer ¤  The persistence layer knows how to store and retrieve domain objects from the data store Service layer Persistence layer Presentation layer Domainmodel 54
    • Independency from the data store ¤  It does it in such a way that the service layer does not know which underlying data store is used Service layer Persistence layer Presentation layer Domainmodel 55
    • The persistence layer isolates persistence concerns ¤  That is, the persistence layer isolates the application from changes in the persistence mechanisms Service layer Persistence layer Presentation layer Domainmodel 56
    • Independency from the data store ¤  Example: switching from JDBC to Hibernate Service layer Persistence layer Presentation layer Domainmodel 57
    • Airline travel web application ¤  Example: Airline travel web application ¤  AccountRepository interface: public interface AccountRepository { Account findByUsername(String username); Account findById(long id); Account save(Account account); } 58
    • The service layer depends on the persistence layer ¤  Only the service layer has a dependency on the persistence layer Service layer Persistence layer Presentation layer Domainmodel talks to… 59
    • The service layer is a coordination layer ¤  the service layer coordinates the persistence layer and the domain model Service layer Persistence layer Presentation layer Domainmodel talks to… 60
    • Persisting domain objects ¤  The service layer ensures that the appropriate domain objects are loaded and persisted in the use case Service layer Persistence layer Presentation layer Domainmodel talks to… 61
    • Domain objects are unaware ¤  The domain objects are un unaware of being persisted Service layer Persistence layer Presentation layer Domainmodel 62
    • Web layer
    • User interface and web layer ¤  We can further detail the architecture by splitting the presentation layer into a web layer and a user interface layer Service layer Persistence layer Web layer Domainmodel User Interface layer 64
    • Web layer ¤  The web layer has two responsibilities: ¤  It acts as the glue between the service layer and HTTP ¤  It drives the user through the correct pages in the order Service layer Persistence layer Web layer Domainmodel User Interface layer 65
    • Keep the web outside the business logic ¤  The HTTP world is populated with strange creatures: ¤  Request parameters ¤  Headers ¤  Cookies ¤  … ¤  These aspects are not business logic specific, and thus should be kept isolated from the service layer 66
    • Keep the web outside the business logic ¤  The web layer hides the details of the web world from the business logic Service layer Persistence layer Web layer Domainmodel User Interface layer HTTP request? I don’t really know what you’re talking about… 67
    • The web layer is an integration layer ¤  The web layer converts the incoming HTTP requests to something that can be handled by the service layer… Service layer Persistence layer Web layer Domainmodel User Interface layer Don’t worry… I’ve got you covered! 68
    • The web layer is an integration layer ¤  …and then transforms the result from the service layer into a response for the user interface Service layer Persistence layer Web layer Domainmodel User Interface layer Here’s the data you need to render the UI… 69
    • The web layer exposes the use cases to the web ¤  The web layer exposes the use cases to the web ¤  The web layer should be kept thin ¤  It does not contain any business logic ¤  It is just a bridge between the world of the web and the service layer ¤  The web layer is a proxy that connects to the service layer and exposes it to the end user 70
    • The web layer handles the navigation logic ¤  The web layer handles the navigation logic, i.e., driving the user through the correct pages in the correct order ¤  The navigation is bound to the web layer only ¤  there is not any navigation logic in the service layer or in the domain model 71
    • The web layer determines the user experience ¤  By guiding the user through the site, the web layer determines the user experience ¤  The web layer typically contains some state to help guide the user through the correct path ¤  Conversely, many of the layers, e.g., service layer, assume much more of a stateless role 72
    • Web layer’s dependencies ¤  The web layer depends on: ¤  The service layer: The web layer will delegate its processing to the service layer ¤  The domain model: the web layer will convert the information sent from the web to domain objects that can be used in the service layer 73
    • User Interface layer
    • User interface layer ¤  The user interface layer is responsible for presenting the application to the end user Service layer Persistence layer Web layer Domainmodel User Interface layer 75
    • User interface layer ¤  The user interface layer renders the response generated by the web layer into the form requested by the user’s client Service layer Persistence layer Web layer Domainmodel User Interface layer 76
    • Same response, different renderings ¤  This layer renders the response generated by the web layer into the type requested by the user’s client ¤  Examples: ¤  A web browser will probable request a HTML page ¤  A web service may want an XML (or JSON) document ¤  Another client could request a PDF document 77
    • many view technologies are available ¤  There exist a plethora of of view technologies ¤  JSP pages ¤  JSF pages ¤  Velocity ¤  But… ¤  The navigation logic and the need of calling the service layer does not change with the specific view technology ¤  That is why the user interface and a web layer are split 78
    • User interface layer’s dependency ¤  The user interface layer typically has dependencies on the domain model ¤  Sometimes it is convenient to directly expose and render the domain model ¤  This is useful when we start to use forms in our application, as it makes possible to objectify form fields directly into domain objects 79
    • References
    • References ¤  S. Ladd, K. Donald, Expert Spring MVC and Web flows, Apress Publications ¤  M. Deinum, K. Serneels, Pro Spring MVC: with Web flows, Apress Publications ¤  Chris Richardson, POJOs in Action, Manning Publications 81
    • References ¤  Martin Fowler, Anemic Domain Model, http://www.martinfowler.com/bliki/ AnemicDomainModel.html ¤  Stackoverflow, What Does it Mean to “Program to an Interface”? http://stackoverflow.com/questions/383947/what-does- it-mean-to-program-to-an-interface 82