use case handled by 2 session facades?

[Saha Kumar]

Hello All,

Is it an acceptable design practice to have a use case span 2 session facades? I feel many times one or more use cases are handled by a session facade, but not the other way around.

Thanks in advance.

-Saha

[Thomas Taeger]

Hello Saha,

Originally posted by Saha Kumar:
I feel many times one or more use cases are handled by a session facade, but not the other way around.

That sounds right. But I would not say a session facade "handles" a usecase nor realizes it, a session facade is just an intrance, best suited as the counterpart for BusinessDelegates that themselves do no really handle anything as well.

Originally posted by Saha Kumar:
a use case span 2 session facades?

What would it mean? Which example? Getting kilometer points from another server that normally acts for another session facade and main usage?

If the realization of a usecase is entered by a session facade and this session facade uses / calls another session facade, then 1) I would not call that "a use case span 2 session facades", and 2) technically I would extract the work of the called second session facade to what I would call a handler, and this handler then would be called from the first and the second session facade.

My understanding in short:
- For best decoupling session facades should not call each other.
- A session facade should be used from the outside world only (BD ...).
- Session facades do not realize anything, they just decouple and dispatch to handlers that do the real work.
- At least commonly needed behaviour should be moved to a handler behind those session facades.

Thomas
[ April 18, 2006: Message edited by: Thomas Taeger ]

[Saha Kumar]

Thanks, Thomas for the great explanation.

I actually have something like:

controller->SearchBD.search->SearchFacade.search
controller->ItineraryMgrBD.confirm->ItineraryMgrFacade.confirm

This is an example of initiating the steps for the prepare itinerary UC via 2 session facades.

I'm glad you brought up the case where one facade calls another. That was also a question I had. Somehow it didn't seem the correct way to handle it. Thanks again.

-Saha
[ April 18, 2006: Message edited by: Saha Kumar ]

[kri shan]

Hi Thomas, Is it possible to view your site - http://www.classic-and-class.com/ via Englsh language ? Any option is there ?

[Thomas Taeger]

Hi Kri,

Originally posted by kri shan:
Is it possible to view your site - http://www.classic-and-class.com/ via English language ? Any option is there ?

no, sorry, my website is just made for my customers in Germany. It would be too expensive to provide an English option as well, for the few not German speaking potential customers.

Also all my J2EE ... courses in www.evalulearn.com are in German only.

Thomas
[ April 18, 2006: Message edited by: Thomas Taeger ]

[Thomas Taeger]

Hi Saha,
there must be a typo in:

Originally posted by Saha Kumar:
controller->ItineraryMgrBD.confirm->ItineraryMgrBD.confirm

Could you please re-edit it (using the pencil symbol)?

Thomas

[Saha Kumar]

Thanks, Thomas for the catch. -Saha

[Thomas Taeger]

Thanks, Saha, for reediting the two example lines (numbered by me):

Originally posted by Saha Kumar:
[1.] controller->SearchBD.search->SearchFacade.search
[2.] controller->ItineraryMgrBD.confirm->ItineraryMgrFacade.confirm

In [1.] I feel the names ...Search... being to generic for a business delegate and for a (allways business specific) SessionFacade too.

Probabely the first Session Facade is used for something like searching and ordering and paying, so I would give it that business name, not just search because searching is only one part of what it offers.

For "a usecase spanning two facades" see my former posting too.
More detailed now:
- Here the one and same "controller" calls business methods on two session facades,
- but we think of the usecase being near to the User (the Actor), and
- thereby nearer to the controller than to the two session facades
that just offer convenience shortings to the realizations.
- For one "use" there is just one usecase active at a time,
- and this one usecase I imagine to be active within the "left-most" participant, in your case within the controller.

Thomas

[Saha Kumar]

Hello Thomas,

I was lazy not to be more specific when it came to naming the controller. Thanks for pointing it out.

In determing how many facades to make, I just made a list of all methods that may be needed by the user. I then grouped like methods into facades. That is why I ended up in one case with a UC spanning 2 facades. Does this violate UML design process?

Thanks in advance.
-Saha

[Saha Kumar]

Hello All,

I want to add the following to my last post:

One idea is to have one facade for flight searching, and another facade to manage itinerary: save, pay, etc.

These facades do not cleanly map to the UCs. That is my question: do these facades violate UML design methodology?

Thanks in advance.

-Saha

[Thomas Taeger]

Originally posted by Saha Kumar:
One idea is to have one facade for flight searching, and another facade to manage itinerary: save, pay, etc.

Is it for business reasons or for technical ones like "logged-in or not"?
FBN is interested in enabling searching just as a first step for selling, that is their business, and not for charity. In my opinion only charity would justify providing a separate facade for searching - from this business point of view.

Originally posted by Saha Kumar:
do these facades violate UML design methodology?

A facade or session facade is a design pattern of J2EE, therefore it can not violate anything of UML. But in my opinion they violate the sense of the Session Facade design pattern (see the book of Deepak Alur et al.: "Core J2EE Patterns").

Thomas

[Saha Kumar]

Thomas,

You have a good point. I will slightly regroup into different facades.

If you have the time, could you respond to the following:

I have a TO which is composed of multiple objects. Should I show the TO composition in the sequence diagrams, or should the TO details be put in the class diagram?

I have read many posts where the TO is not included in the class diagram, but wonder if TO composition is too detailed for a sequence diagram.

Thanks in advance.

-Saha

[Thomas Taeger]

What a "TO" is the abbrivation for? To be polite I would define it once before using the abbrivation.

And more important: Please open a new thread with that topic - remember to give it a good name, please ...
Thomas
[ April 19, 2006: Message edited by: Thomas Taeger ]

[Saha Kumar]

Hello Thomas,

My understanding in short:
- For best decoupling session facades should not call each other.
- A session facade should be used from the outside world only (BD ...).
- Session facades do not realize anything, they just decouple and dispatch to handlers that do the real work.
- At least commonly needed behaviour should be moved to a handler behind those session facades.

I have session facades as you describe above which call handler POJOs. Keeping in mind that we should not have one facade call another, how is the security protection enforced when moving from one use case to the next?

Example:

UseCaseOneSessionFacade -> UseCaseOneHandler -> UseCaseTwoHandler

UseCaseTwo requires that the user be logged in before it runs. If J2EE container managed security is used, how can pojo UseCaseTwoHandler be protected?

Is there a way without making the handlers EJB Session beans?

Thanks in advance.

-Saha

[s khosa]

Should we even be mentioning that if we are using ContainerManaged Security? Since container would have access to request object it can always decided whether the user request is in Role or not. This is an implicit service task that container would perform for any call in your system whether its for POJO1 or POJO2. Even we really have to show something of that sort, we would be indicating that in class diagram through some sort of security manager class( e.g SecurityManager class used by EJB container.

I hope i understood the issue correctly.

Thanks

[Saha Kumar]

Hello s khosa,

Thank you for the reply...glad to hear from you. When you speak of request object, you mean (in Struts for example) the actionClass.do web resource? Its true you can protect it via web.xml params; but what happens if the customer waits a long time to choose which credit card to use, and the session times out? The itinerary cannot be paid until the user logs in again. Thinking about it again, maybe it would be enough to protect the resource which persists the payment. I just think there may need to be some additional checks other than just once during the user's request.

-Saha

[s khosa]

well ...lets assume the session has timed out...what will happen is the your User.isinRole() method can throw an error...maybe null pointer...and you should have code in their to redirect him to login page again...and i think container security manager class will do it on its own. Login page is configured in web.xml

Hope this makes sense.

PS: Looks like you are pretty close to finishing your assignment..:-)..I still have not started mine..:-)

[Saha Kumar]

s khosa,

I am not too far due to questions I have. One day maybe...

Regards,
Saha

[Thomas Taeger]

Hello Saha, hello all,
besides your other interesting discussions the following line best shows that the relationshop of usecases and handlers / realizations are overstressed:

Originally posted by Saha Kumar:
UseCaseOneSessionFacade -> UseCaseOneHandler -> UseCaseTwoHandler

"UseCaseOneSessionFacade" makes sense.

But "UseCaseOneHandler" and "UseCaseTwoHandler" in my oppinion do not make sense.

A handler offers something that multiple Session Facades or usecases may use (most often causing to access a database). So "UseCaseOneHandler" is a contradiction within itself.

Thomas

[Vagner Freitas]

Hi Thomas and All

When you said:

Is it for business reasons or for technical ones like "logged-in or not"?
FBN is interested in enabling searching just as a first step for selling, that is their business, and not for charity. In my opinion only charity would justify providing a separate facade for searching - from this business point of view.

What do you think if I want to implement a Value List Handler as a Session Fa�ade? In this situation it is better have a separate fa�ade for searching, isn't it?

Vagner Freitas

[Saha Kumar]

Hello Thomas,

I have the following flow:

UseCaseOneFacade -> UseCaseOneServiceApp -> UseCaseTwoServiceApp

because as we know, our use cases may call other use cases.

The serviceApp design is described in the 'Core J2EE Patterns' book.

Is this pattern incorrectly used in the flow above? As far as I know, the facade is only for the client's use and should be preceded by a businessDelegate.

-Saha

[Thomas Taeger]

Hello Vagner,

Originally posted by Vagner Freitas:
... implement a Value List Handler as a Session Fa�ade? In this situation it is better have a separate fa�ade for searching, isn't it?

yes, better separate them, because the both J2EE Design Patterns are quite different. I would not let a Session Facade handle the portioning of a huge list of values.

Thomas