It is possible to do this by inspecting the bean's own annotations with code, i.e. method @PermitAll, @RolesAllowed, and class defaults. This works.
IMHO It would be nice if there was a JBoss method that would allow such method access checks though.
Wouldn't it be better if your fat client enabled/disabled menu items based on the roles the user has rather than the methods they can call. I mean really this is the same thing, only you do not have to go get method permissions.
Thanks for your input.
I trivialised my use case as enabling/disabling menu items for the sake of forum post.
My client is not so much a fat client as an automatic user interface which exposes business methods directly to the user. It generates forms and offers functionality with little or no client-side coding required. It creates wizards to gather parameters required to invoke business processes and interacts JBPM business processes with the user.
The user interface metadata, hints, such as "Group these fields visually" and "Show a full-size calendar here rather than a date control" are attached to the business methods on the bean and to parameters and passed to the client along with datasets. This allows rapid development of CRUD functionality and easy exposing of new useful-to-business code to the user.
I agree with what you are saying in general use but the client is agnostic to the session beans and entities it is working with. Many methods are exposed to the User rather than the client, hence checking if the User can access the Method, where the method is accessible to the user.
If you still think I am using the wrong strategy I am happy to debate :)
I would say this is an interesting use case. The problem with making client unaware of buisness components is that you then have to come up with ways to configure your client to do stuff with abstract notions of business objects. In that case what you have done with annotation inspecting is a solution. Another might be to create a method that all your buisness beans can implement that returns this data to your client. If you find another solution, please let us know. I would be interested in hearing how it turns out.
All my business beans do implement common methods as you describe.
These methods inspect access and different types of functionality offered by the session bean that only the bean knows about and return the full set of metadata about this to the client. One type of FunctionDef (representing an item of functionality) represents a method call to the business bean but there are other types.
The client also takes further hint-style annotation from the remote interface and groups of session bean methods follow patterns the UI recognises such as CRUD functionality.