PartII - security in web or ejb tier
bob-davis
Greenhorn
Posts: 2
posted 14 years ago
First of all, I am not going to use J2EE security in the assignment. Why? Do to the fact of the users being able to add themselves at runtime (create profile). IMHO this is where the J2EE security falls short. One has to write a custom RealmAccessor to handle managing users at runtime.
So I decided I would take the route of the Petstore and have a very thin entity bean (username/password) that represents a "logon" in the system. So now I have the question as to where do I guard my resources. In the web tier or in the ejb tier?
Just wanted to get some other opinions on my approach.
Also is anyone using an EJBController pattern similar to the Petstore? I am going with a simple BusinessDelegate-SessionFacade where the SessionFacade is a SFSB that holds the currently logged in user among other things.
Thoughts?
So I decided I would take the route of the Petstore and have a very thin entity bean (username/password) that represents a "logon" in the system. So now I have the question as to where do I guard my resources. In the web tier or in the ejb tier?
Just wanted to get some other opinions on my approach.
Also is anyone using an EJBController pattern similar to the Petstore? I am going with a simple BusinessDelegate-SessionFacade where the SessionFacade is a SFSB that holds the currently logged in user among other things.
Thoughts?
Dinesh Sadhvani
Greenhorn
Posts: 5
posted 14 years ago
This is pretty interesting. Well I have looked at the EJBController pretty close in our project last year. There are some advantages with using this design:-
-> Higher Abstraction
-> Web-tier is more clearly separated from presentation-tier.
->Scalability is forced as you keep transactions demarcated at EJB / business-tier but not right from Web-tier.
But one should also see the possible limitations:
->Does a extra Controller all that much for me?
as I already have a Controller in Web-tier(Struts, Action Servlet).
-> It may hinder users in case of transactions being passed around from non-EJB environments if supported in future.
We decided not to go with this approach as it seemed overkill and we used a simple Business Delegates which use Service Locators and obtain the appropriate Service.
-> Higher Abstraction
-> Web-tier is more clearly separated from presentation-tier.
->Scalability is forced as you keep transactions demarcated at EJB / business-tier but not right from Web-tier.
But one should also see the possible limitations:
->Does a extra Controller all that much for me?
as I already have a Controller in Web-tier(Struts, Action Servlet).
-> It may hinder users in case of transactions being passed around from non-EJB environments if supported in future.
We decided not to go with this approach as it seemed overkill and we used a simple Business Delegates which use Service Locators and obtain the appropriate Service.
