Presentation layer in 3-tier architecture

Question

My question is about various ways of implementing presentation layer in 3-tier architectures

When we talk about a 3-tier web application, it is assumed that the presentation layer is browser-oriented, and hence communicates with logic tier through HTTP protocol

I'd like to know, how presentation layer is going to communicate with logic tier, in case if the presentation layer is going to be a standalone application with its own GUI, rather than browser-based

For example, Java servlets get HTTP requests from our browser, but what about if I want to design a specific desktop application to communicate with servlets ? How my app is going to communicate with logic tier ? Which protocol is used ?

Answer 1

I guess you're misunderstanding the problems. You can say in this case the presentation layer is splitted in 2 small layers:

• Files that handle the view (JSP, Facelets, etc).
• Files that control the interaction between user and the view (Servlets, @Controller from Spring MVC, @ManagedBean from JSF, etc).

Apart from these, you can have your business logic layer (usually Service classes) and your data access layer (DAOs or whatever you feel better to call them).

If you put this in the perspective of creating GUI desktop applications, your presentation will have a similar structure:

• Classes that handle the view
• Controller classes that handle the interaction between the user and the view.

In this scenario, it usually happens that these classes are the same, but note that they are for presentation purpose and should relate with your business logic layer.

what about if I want to design a specific desktop application to communicate with servlets?

You probably mean about a client application that consumes Web Services. The Web Services (consumed by XML, JSON or plain text) could be part of a services layer that should be consumed in the business logic layer or in the presentation layer of the application, depending on what the web service returns. Still, I would find better consuming the web service layer from the business logic layer and let the presentation layer to handle its purpose: presentation logic only.

To show an example:

Presentation layer
      |
      | <<communicates>>
      |
      v
Business logic layer
      |
      | <<communicates>>
      |
      v
Web Service Layer
      |
( the cloud ) <<communicates data using XML, JSON, etc...>>
      |
      v
Web Server that resolves the Web Service call
      |
      | <<communicates>>
      |
      v
WS Business logic layer
      |
      | <<communicates>>
      |
      v
WS Data access layer
      |
      | <<communicates>>
      |
      v
Data Sources (database, files, etc)

---

From comments:

Still it's unclear how business logic layer of my application is going to communicate with web service layer.

Posting a very simple skeleton sample from a Web Application Project that will consume a Web Service.

Servlet class (adapted from StackOverflow Servlet wiki) (part of presentation)

@WebServlet("/hello")
public class AServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
        //Displaying the view.
        request.getRequestDispatcher("/WEB-INF/hello.jsp").forward(request, response);
    }

    @Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
    String name = request.getParameter("name");
    String age = request.getParameter("age");
    Person person = new Person(name, Integer.parseInt(age));
    PersonBL personBL = new PersonBL();
    personBL.savePerson(person);
}

PersonBL class (part of Business Logic Layer)

public class PersonBL {
    //omitting configurations and all non-code related stuff for explanation purposes
    @WebServiceRef(wsdlLocation="http://localhost:8080/helloservice/hello?wsdl")
    private static PersonWebService personWS;

    public void savePerson(Person person) {
        //since is business logic layer, it can hold validations for the data
        //before calling the web service
        //for explanation purposes, no business logic will be added
        //...
        //here it will contain the logic to call the web service
        PersonPort personPort = personWS.getPersonPort();
        personPort.savePerson(person);
    }
}

Now, posting the skeleton of the Web Service:

PersonPort class (the implementor of the Web Service)

@WebService
public class PersonPort {
    @WebMethod
    public void savePerson(Person person) {
        PersonWSBL personWSBL = new PersonWSBL();
        personWSBL.savePerson(person);
    }
}

PersonWSBL class (business logic layer in Web Service)

public class PersonWSBL {
    public void savePerson(Person person) {
         //it can contain business rules to apply before executing the operation
         //for example purposes, there won't be any rules to apply
         //...
         PersonDAO personDAO = new PersonDAO();
         personDAO.savePerson(person);
    }
}

PersonDAO class (data access layer)

public class PersonDAO {
    public void savePerson(Person person) {
        //logic to save the person in database or somewhere else
    }
}

As you can notice, there's no magic in communicating the presentation with the business logic layer. Of course, this skeleton can be enhanced by using other set of technologies, but it just to illustrate the main idea.

Note: The skeleton of the Web Service was adapted from here Creating a Simple Web Service and Client with JAX-WS.