2

I am having some problems devoloping an application based on EJB 3 technology.

I would like to use a Facade Pattern in the Session beans to decouple my client (a web application) from my Entity Beans.

I am using a SFSB to manage the user session.

So I have a FacadeLoginRemote remote interface, which exposes to the client the methods doLogin(), doLogout(), etc... Currently this SFSB also includes some other methods such as getCourse(int id), getResource(int id). Not all the users can actually get the course and get the resource, so the Facade perform some checks before returning the values to the client.

I would like to split the Facade, putting the methods getCourse() and getResource() in a special class for them, but leaving to the FacadeLoginRemote the functions of checking users privileges.

If I make some different SLSBs I will expose them to the client. So the client would have the possibility to connect directly to them avoiding checks from the FacadeLoginRemote.

Am I wrong? Is there any way to do this?

Thanks in advance,

Andrea

Andrea
  • 3,627
  • 4
  • 24
  • 36

1 Answers1

2

First one word of advice; if you are building a web application, then it's more typical to have the web tier and the business tier within the same application. There is no need for remoting in that case. Your session beans will run in the same JVM as the web tier.

That's not to say there aren't any legitimate reasons to use remote interfaces (there are plenty), but reading your problem description it seems to me that you might be better off using local beans.

Or is the web application you speak of a remote application hosted by someone else on their servers, and do they consume services from your EJB beans?

In Java EE, the authentication can be done in the web module. Especially if you are using local beans, this authentication (the security principal) will be propagated automatically to the EJB beans. You can annotate your EJB beans to require a specific security role. If the user isn't authenticated, she doesn't has that role and service will be rejected.

In that case it doesn't matter if the client tries to connect directly to the beans having the getCourse() etc methods.

I do wonder how you implemented the doLogin() in your EJB. My guess is that you did something custom there, as unfortunately to the best of my knowledge EJB3 does not have a straightforward way to do a programmatic login via a specific method on a specific bean. Security is mostly declarative, and authentication details will then have to be provided by the client when accessing any bean. E.g. when you request beans from a remote JNDI, you have to provide those details with the initial JNDI connection to the remote server.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
  • Yes, you are right about the web and business tier. They work on the same JVM. I used remote interfaces just because I am considering to develop a possible desktop or mobile client application too. And so the JVM will be different. As you guessed, I implemented the `doLogin()` to do some custom auth operations and my goal was to propagate this auth to the other beans. I will check the EJB annotations about security. Thanks for your answer. – Andrea Jan 10 '11 at 07:45
  • You're welcome. Also note that it's very easy to provide both a remote and local interface for the same beans. Use the local interfaces for code running in the same JVM and let external code use the remote interfaces. To minimize redundancy, both interfaces can inherit from a base interface class or from each other. Using local interfaces is also typically *much* more efficient. – Arjan Tijms Jan 10 '11 at 22:04