Design Pattern
Urgent!! Please help!!!
Is it possible for a Session Bean which implements Session Facade pattern to call an Entity bean directly? Our Client insists that a True Session Bean (which does not implement Session Facade pattern) can only
call an Entity Bean and not a Session Bean which implements Session Facade. In effect they want us to introduce a layer of Session Bean between Session Facade Bean and Entity Bean.
Thanks in anticipation
[470 byte] By [
AndrewF1] at [2007-9-26 19:11:28]
Hi,
Sounds a bit confusing but, if you look at some example J2ee applications such as the petstore application, you will see that it is common for a session bean acting as a session facade to call an entity bean or beans directly.
The client application or web tier then talks to the session bean rather than the entity bean.
The configuration is like this:
client app --<network> Session Bean1 > Entity Bean
From your description it sounds as though you are trying to avoid having another session bean between the exiting session bean and the entity bean i.e. :
client app --<network> Session Bean1 > Session Bean2 > Entity Bean
The thing to note is that the "Session facade" pattern is a more abstract description of how to organise the interaction.
In fact both of the examples i have shown use the session facade pattern.
In the first example Session Bean1 is acting as a session facade to the client app.
In the second example Session Bean1 is acting as a session facade to the client app
AND
Session Bean2 is acting as a session facade to Session Bean1.
In fact the most common way of using session beans , that i have encountered , is the first example.
I haven't come across many applications with two layers of session beans.
Keith Bishop
I think it is acceptable to expand upon the abastraction model of a session facade, and have session facedes for other single session facades, with the deeper facades being more granual as to their workflow?
If an application is large and complex, there may be hundreds of workflow secarios, each with their own session facade. One could group the many session facades together under a higher level workflow, via another session facade.
Example: Viewing of a customer profile is done by both the customer and an application administrator. A view profile session facade would have a workflow something like -- verify rights, lookup profile, get information, etc. Now, we may have two contexts from which to expose that facade, a custmoer or an application administrator. One could group all customer work types and all administrator worktypes together under an appropriate facade for each. Meaning, as a customer, I must login first before accessing a profile. Whereas an administrator must login, access an administrators page, find a customer, and then access the profile.
In other words, one could group small self contained workflows under larger workflows.
Or, and I just off base?
bRi
