Hello All I have value list handler pattern implemented and I understand that the ValueListHandler is required to be used by the client for multiple invocations for returning results. The recommendation if we are using enterprise beans is to front the value list handler with another session bean (Proxy)
This value list handler just satisfies one use case. but i have other use case too.
I created a Session Facade object and have this value list handler session bean reference (Proxy) inside the same class
Also signature definition of other use cases exists in the same facade which are stateless compared to VLhandler proxy one which will be stateful session bean
Now question is How should the Session facade be implemented 1. Stateless Session Facade containing stateful session bean VL Handler proxy and other Stateless Session bean reference
2. Stateful Session Facade containing stateful session bean VL Handler proxy and other Stateless Session bean reference
If you have to use SFSB for the VL, the second solution seems to be the only choice, because it's impossible to acccess the same stateful VL through SLSB.
Joined: Jun 08, 2005
Hi thanks for your reply
For me the confusion is why is it impossible to use SLSB as a facade which includes a SFSB.
Say if the Facade is implemented as a SLSB and my SFSB-VLHandler is going to be returned on the first call to the facade to the client and there after can the client not use the SLSB-VLHandler to make calls to get results rather than calling SLSB facade again?
Joined: Jul 06, 2007
If the VL Bean reference is returned at the first call to the Session Facade, what is the differece between this approach and call VL SFSB directly without invovling the SessionFacade?
I think Facade is just a kind of proxy and delegate so Facade is not necessary if your background beans are not complicate.
Joined: Jun 08, 2005
Thanks again But i prefer a facade as it provides an interface to the business layer So if i use a facade can it be SL holding a reference to SF and other SL session beans?
Stateful Session Bean Strategy When an application uses enterprise beans in the business tier, it may be preferable to implement a session bean that uses the ValueListHandler. In this case, the session bean simply fronts an instance of a ValueListHandler. Thus, the session bean may be implemented as a stateful session bean to hold on to the list handler as its state, and thus may simply act as a facade or as a proxy.
Since the Value List Handler is a session bean, it may appear as a specialized Session Facade. However, in isolation, it is a specialized session bean rather than a specialized Session Facade. A Session Facade has other motivations and characteristics (explained in the Session Facade pattern), and it is much coarser grained.
The conversational nature of your Value List Handler forces the implementation strategy of your Session Facade:
Stateless Session Facade Strategy When implementing the Session Facade, you must first decide whether the facade session bean is a stateful or a stateless session bean. Base this decision on the business process that the Session Facade is modeling. A business process that needs only one method call to complete the service is a nonconversational business process. Such processes are suitably implemented using a stateless session bean. A careful study of the use cases and scenarios enables you to determine the Session Facade definitions. If the use case is nonconversational, then the client initiates the use case, using a single method in the Session Facade. When the method completes, the use case completes too. There is no need to save the conversational state between one method invocation and the next. In this scenario, the Session Facade can be implemented as a stateless session bean. Stateful Session Facade Strategy A business process that needs multiple method calls to complete the service is a conversational business process. The conversational state must be saved between each client method invocation. In this scenario, a stateful session bean may be a more suitable approach for implementing the Session Facade. In both the Stateless Session Facade and the Stateful Session Facade strategies, the business object's role can be fulfilled in different ways, as explained next.
You can only have a Stateful Session Facade when you are using a Value List Handler.
What may be worth considering is having two facades (two interfaces) one stateful - the other stateless.
I suppose that you have your reasons for not sending the entire list to the client (dropping the requirement for the value list handler) or offering methods on the stateless session facade that give the client equivalent functionality for accessing sub-lists that can be generated from scratch?
Originally posted by Mohamed Farouk: why is it impossible to use SLSB as a facade which includes a SFSB
It is the nature of an SLSB instance that it "forgets" everything (which includes the reference to the SFSB that is holding your Value List Handler) once it returns any results to the client. The next time a method is called on it, it is dealing with a totally different client - there is nothing to be gained by remembering client specific information.
The next time you make a method call on the SLSB your are dealing with a totally different SLSB instance, not the one that created the SFSB with the Value List Handler. The instance that created the SFSB/VLH is now serving a different client, twiddling its thumbs in the instance pool or it may already have been destroyed. If you need to maintain a connection with the same instance then you need to use an SFSB - that is what they are there for. However SFSBs aren't popular because they tie up server resources until the client releases them; and for 99% of the time that the SFSB is bound to client it isn't doing much of anything (other than maintaining state which consumes the server resources) and it can't be used for anything or anybody else (another client will need a separate instance which holds a separate state). A single SLSB instance can be shared between multiple clients because it doesn't have to remember anything about the client � you only need multiple SLSB instances if you are simultaneously processing method calls from multiple clients � between method calls the SLSB instance can wander from one client to the next.
Originally posted by Mohamed Farouk: Thanks again But i prefer a facade as it provides an interface to the business layer So if i use a facade can it be SL holding a reference to SF and other SL session beans?
Hi, ofcourse you can, but remember:
In this case, when you first call the Facade to get a SF VL reference, Later you will deal with this VL directly, without further interaction with the Facade.