Architecture for a JSF Application with Android APP

Asked

Viewed 1,353 times

15

I am in the planning part of a web application that I will develop for a Client. It will be Cruds and some report, nothing too complicated.

At the moment I’m designing 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 Customer wants me to develop also an Android APP to be used in conjunction with the web application.

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

Initially I thought to work with "mini services", ie create a service that will be called in a Url (/lancarHoras). This service expects a JSON with the data of the object I want to persist, processes this 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" that service.

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

  • Thiago, welcome. The staff is considering that your question is seeking opinions and voting to close it. Stackoverflow is a good platform for objective questions and answers but is not suitable for asking for opinions. Can you modify the question to ensure that objective answers and no opinions are posted? The subject is interesting, but as the question is written, it is leaving open for each to express his or her opinion. If you know English, here’s how to improve a slightly more subjective question: http://blog.stackoverflow.com/2010/09/good-subjective-bad-subjective/

  • I don’t see how to improve the question to make it more objective. If this is the case and you are not within the rules can be closed or even deleted.

  • Actually it is to be more objective. I see how, but do not like to mess with the intention of third party questions.

3 answers

5


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

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

Note that no matter who the VIEW is, it will call the server and communicate via 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 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 Beans Managed will be called and with that you will not need to expose your business server to the world, only to 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 done in JSF will no longer be valid (validation of input, access to a given method if you have not logged in, etc.), because you will need to have a validation of these rules also in APP.


Solutions

I see some solutions to this kind of problem:

  1. You could have all the business rules on a server and your views be entirely 'dumb'. So-and-so tried to access a method and is not logged in, the server would return 401 and the view would understand that a login would be required.
  2. Have a server halfway through (something like a session controller). 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 for a given URL a login is necessary, whether the guy is logged in, and whether he has permission to access this feature. The advantage of this approach is that your service server would only concern itself with business rules and not with security issues.


Decommission your service

Another detail you have to always keep in mind is: don’t 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 business could mean changing the view. Ideally create a VO for this.

public PessoaVO(){}

This guy would be the object returning decoupled so his business layer of the visualization layer.

  • 1

    +1, except for the last comment. In the situation mentioned, I imagine that a change in the server code will imply a change in the app and the webapp, that is, the same change would be made three times. Or four, if a VO is involved. If the API is public, then you’re right, but otherwise, I would avoid adding another layer.

  • In this case I will disagree. There are several cases where the business rule can vary without varying the VIEW. Today I work on a totally decoupled VIEW server and in several cases I do not need to make changes in VIEW to implement various actions. Not every server change will be reflected in the view.

  • How to "Beautiful" the access to private methods?

  • What would shield a private method?

1

You’re going the right way. Use Rest

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

And to take the Json and convert into java objects, use Gson google.

  • Only one addendum, so you don’t have problems with converting the object or list to json, don’t do bidirectional mappings.

  • @joelbarbosa, I’ll take a look at the links! I must go that way myself!

  • @user947, you say A have an object B between its attributes and B have a list of A?

0

An alternative to the use of Jersey is the Spring MVC, which besides an excellent implementation of features for API’s Rest, has several other features to compose its solution among them packages for integration with social networks like facebook and twitter.

The process of serializing and deserialize your objects is a critical point for the performance of your application/service (depending on the volume of data of your products). As for this aspect it is important that you meet Jackson (rival of GSON).

https://spring.io/guides/gs/rest-service/

http://docs.spring.io/spring/docs/3.0.0.M3/reference/html/ch18s02.html

https://github.com/FasterXML/jackson

Browser other questions tagged

You are not signed in. Login or sign up in order to post.