• Post Reply Bookmark Topic Watch Topic
  • New Topic

Stateless Or Pojo?

 
James Ellis
Ranch Hand
Posts: 205
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am fairly new to EJB and learning EJB 2.x (for the certification). I can see why a stateless session bean would be used instead of a POJO when you have a remote client, but if I have a local client what benefits would a stateless session bean give me over a plain old java object? Seems like all the pooling stuff is just extra overhead for the app server, since threading shouldn't matter since the bean has no state.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35719
412
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
James,
The stateless local bean provides you the benefits of the EJB container - security, transaction support, etc.
 
Deepak Bala
Bartender
Posts: 6663
5
Firefox Browser Linux MyEclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeanne Boyarsky:
James,
The stateless local bean provides you the benefits of the EJB container - security, transaction support, etc.


Yep, if you dont want security, transactions, automatic instance pooling etc etc you should rethink using EJBs
 
James Ellis
Ranch Hand
Posts: 205
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK definitely still an EJB newbie and I'm sure this will sound stupid...but security from what?

Also, can you give me a real life business case when you'd need a transaction that doesn't involve some sort of state? If you are just fetching data from a database, you wouldn't need a transaction, and if you are writing to the database I am having difficulty picturing a real life business case when it would be better to do this from a stateLESS bean instead of a stateFULL bean...
 
Deepak Bala
Bartender
Posts: 6663
5
Firefox Browser Linux MyEclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
but security from what?


Example: You dont want your employee to invoke the method setSalary() but you want your manager to be able to do it.

For database writes you would need transactions to lock tables and provide "ACID". Whether your bean should be statful or stateless depends on the scenario.
 
James Ellis
Ranch Hand
Posts: 205
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Example: You dont want your employee to invoke the method setSalary() but you want your manager to be able to do it.


OK I hear this kind of talk about security all the time and I've never quite thought it made much sense. Maybe because I focus mostly on web applications...but why would an employee ever be logged into the portion of a site that would allow them to call setSalary()?
 
Deepak Bala
Bartender
Posts: 6663
5
Firefox Browser Linux MyEclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Ellis:


OK I hear this kind of talk about security all the time and I've never quite thought it made much sense. Maybe because I focus mostly on web applications...but why would an employee ever be logged into the portion of a site that would allow them to call setSalary()?


If the employee is a programming geek and knows the JNDI lookup for the bean and can access the methods that can affect a production database... yikes. Hypothetical situation but may happen. Your application may have admin roles and methods which only admins should be able to invoke. Security is useful then. You are right in that the user should never be given a link to "setSalary.do?sal=200000" but nothing will can stop him/her from putting it into their address bars.

First line of defense is to configure the security for URLs declaratively. Then set security for beans if neccessary.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35719
412
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Ellis:
Also, can you give me a real life business case when you'd need a transaction that doesn't involve some sort of state?

A classic example is transferring funds between accounts in a bank. This is a real life example too.

Sample request: Transfer $50 from account A to account B. There is no state as I passed in everything you need to know in the one call. The stateless session bean needs to make at least two database calls to complete the request. One to subtract $50 from account A and the other to add $50 from account B. You need a transaction because the user won't be pleased if you subtract the money and then crash.

This scenario applies to almost all situations that involve two database updates. Another example is to perform some action and then update a database log table.
 
James Ellis
Ranch Hand
Posts: 205
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the employee is a programming geek and knows the JNDI lookup for the bean and can access the methods that can affect a production database... yikes. Hypothetical situation but may happen. Your application may have admin roles and methods which only admins should be able to invoke. Security is useful then. You are right in that the user should never be given a link to "setSalary.do?sal=200000" but nothing will can stop him/her from putting it into their address bars.

First line of defense is to configure the security for URLs declaratively. Then set security for beans if neccessary.


If you have configured security for URLs declaratively (as you suggested)...then the link to "setSalary.do?sal=200000" wouldn't do anything since the URL itself would be blocked.


If the employee is a programming geek and knows the JNDI lookup for the bean and can access the methods that can affect a production database as you suggested...than that must mean they can create code...for instance an Employee object. If they have access to create an Employee object, they probably have access to create an Administrator object (whose object would not be blocked from calling setSalary()). So in this case...setting security on the beans wouldn't do anything. I am having trouble picturing a scenario when setting security on beans would really do anything...

[ April 30, 2007: Message edited by: James Ellis ]
[ April 30, 2007: Message edited by: James Ellis ]
 
Deepak Bala
Bartender
Posts: 6663
5
Firefox Browser Linux MyEclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have configured security for URLs declaratively (as you suggested)...then the link to "setSalary.do?sal=200000" wouldn't do anything since the URL itself would be blocked.


My point exactly

To access any EJB objects and their functions you need to be assigned the appropriate roles. These roles would not be available just for everyone and you need to login to represent the principal corresponding to these roles.

A practical example is this: A session bean can read data from a database from a table. It reads the columns "User name" and "Last name" for any given user but does not allow you to invoke methods that also read sensitive information like "Password" or "Credit card number" from the database. If you want a Collection of Objects that also hold this information you could log in as the admin. This bean is accessible across many applications and only some of those applications are allowed to view the sensitive data.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!