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.