Of course an alternate approach is to go back to what was done with EJB 2.x to support unittestability - place all of the methods into another object, and make the SLSB a mere facade for that object. Then each SLSB method would look like: void doSomething(int var) { new RealObject(var).doSomething() } Unfortunately, this approach generates unneeded garbage. Personally, I vote for passing the values along from method to method. Less chance of unintentional bugs later on. And besides, by adding fields (whose values change) to an SLSB you are in effect adding state to what should be a stateless object. And as Andrew pointed out, you will be bit by this during maintenance (most likely several months/years down the line when someone inadvertently assumes that the field actually hold real state, and not pseudo-state). And besides, IDEs are pretty good about helping you manage method signatures. For example, say you wanted to add a second parameter to your facade method, and you dutifully add the parameter to the call_internal method invocation - Eclipse will flag the method call and provide suggested changes, including adding the parameter to the call_internal method. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171134#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...