2

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 ?

mangusta
  • 3,470
  • 5
  • 24
  • 47

1 Answers1

3

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.

Community
  • 1
  • 1
Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
  • Thanks for reply. I guess I need the ways of communication between presentation and business logic layers in your scheme above. How is that accomplished ? – mangusta Jun 10 '13 at 23:00
  • @mangusta that depends on your application design. You can consider this scenario as two applications: the first one that acts as the presentation application that will have the presentation layer and its own business logic layer (GUI, Web Application, Mobile application, it doesn't really matter as long as its purpose is presentation). Then, from your business logic layer of this app you will communicate to a web service application. Note that communication between presentation and business logic layer will depend on the technology you choose. – Luiggi Mendoza Jun 10 '13 at 23:04
  • Ok, I see. Still it's unclear how business logic layer of my application is going to communicate with web service layer. You mean that, even though if we're going to use a desktop application, we will communicate with a server part through HTTP ? – mangusta Jun 10 '13 at 23:08
  • @mangusta answer updated showing an skeleton of the proposed example. – Luiggi Mendoza Jun 10 '13 at 23:32
  • : ) so you assume that servlet is part of application's presentation layer, although it's a bit misleading because servlet is located on a server, not user machine : ) – mangusta Jun 11 '13 at 06:44
  • and also, servlet receives GET and POST requests, which are usually associated with browser access. is the desktop application going to use GET and POST to communicate with servlets ? – mangusta Jun 11 '13 at 06:50
  • @mangusta the problem is that you have wrong concept. A Desktop application **does not** interact with a Servlet, instead it consumes a service. The Service can be a local service, a service in the LAN or a Web Service. In case of Web Services, even if its implemented by a Servlet, it's not like the Desktop Application directly communicates with the Servlet. – Luiggi Mendoza Jun 11 '13 at 14:05
  • @mangusta one more thing: Servlets are not part of the business logic layer, that's for sure. – Luiggi Mendoza Jun 11 '13 at 14:08
  • Okay, let's put the question this way. How application's business logic layer is going to communicate with Web Service ? What is the protocol ? – mangusta Jun 11 '13 at 19:56
  • @mangusta in case of web services, is HTTP (soap or rest or another, is over HTTP). – Luiggi Mendoza Jun 11 '13 at 20:27