Architecture for a JSF Application with Android APP

15

I'm in the planning part of a web application that I'm going to develop for a Client. There will be CRUDs and some report, nothing too complicated.

At the moment I'm writing an architecture so that this application can evolve well without much rework.

I intend to use JSF, Hibernate and Bootstrap (for now that's enough). In the not too distant future it may be that the Client wants me to also develop an Android APP to be used in conjunction with the web application.

Doubt comes now. What is the best way to "organize" the project so that if I have to evolve it in the future, be easy. For example, the web application may have a working hours record that can be registered in both the web app and Android APP.

Initially I thought about working with "mini services", ie creating a service that will be called in a URl (/ lancarHoras). This service expects a JSON with the object data that I want to persist, processes that data and responds to the "screen" with an OK or ERROR. That way it would be easy to evolve in the future, an Android APP for example would only "consume" this service.

Is it worth working like this? Is there any other better way to work in this case?

    
asked by anonymous 03.01.2014 / 19:58

3 answers

5

Using Rest is the best solution. An architecture model that I know works out is:

Server (with business rules) < ------ VIEW

Note that no matter who the VIEW is, it will call the server and communicate with JSON, for example.

The problem starts with the following question: who will control the session? Should the user be logged in to delete a record? What happens if someone calls this method without a login?

Note that when exposing the business server you will always have to shield access to private methods.

Business Server and a View Server

When using JSF only you have the advantage of having the following architecture:

Server <----- View (JSF Mobile e Web)

Only your managed beans will be called and you will not have to expose your business server to the world, just for the web server.

Business Server and Two Different Views

The problem will appear when you do the architecture below:

View (App nativo) -----> Server <----- View (JSF Web)

Note that all your validation in JSF will no longer be valid (input validation, access to a particular method if you have not logged in, etc.), since you will need to validate these rules also in APP.

Solutions

I see some solutions to this kind of problem:

  • You could have all the business rules on a server and your views are entirely 'dumb'. So-and-so tried a method and is not logged in, the server would return 401 and the view would understand that a login would be needed.
  • Have a server in the middle path (something like a session handler). See the example below:

    View (App nativo) -----> View Rules Server <----- View (JSF Mobile e Web)
                                    |-----> Server
    

    This View Rules Server would receive all HTTP calls and validate whether a given login URL is required, whether the face is logged in and whether it is allowed to access this feature. The advantage of this approach is that your services server would only concern itself with the business rules themselves and not with security issues.

  • Disconnect your service

    Another detail you have to always keep in mind is: do not return your business object directly to the view.

    If you have the class below:

    @Entity
    public Pessoa(){}
    

    Avoid returning it directly to the view. Any change in the deal could mean changing the view. The ideal would be to create a VO for this.

    public PessoaVO(){}
    

    This guy would be the returning object by decoupling his business layer from the preview layer.

        
    04.01.2014 / 00:51
    1

    You're going the right way. Use Rest

    To consume Webservice using Rest, use the Jersey API, which is the JavaEE reference implementation.

    And to get Json and convert to java objects, use Google's Gson .

        
    03.01.2014 / 21:00
    0

    An alternative to using Jersey is the Spring MVC which, in addition to an excellent implementation of APIs Rest features, has several other features to compose your solution among them packages for integration with social networks like facebook and twitter.

    The process of serializing and deserializing your objects is critical to the performance of your application / service (depending on the volume of data in your products). On this aspect it is important that you meet the Jackson (rival of GSON).

    link

    link

    link

        
    31.01.2014 / 18:58