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:
- 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.
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.
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/
– Maniero
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.
– Thiago Silva
Actually it is to be more objective. I see how, but do not like to mess with the intention of third party questions.
– Maniero