session facade and VLH

[Giju George]

What's the best way to implement a Session facade along with a Value List Handler. I am planning to use this design for the search option. what I came across was :-
BD->SFSB(facade)-> VLH->DAO-> ....
I have made the bean stateful, because then it can hold a reference to the VLH. The VLH might be a POJO.
An extract from Core Design patterns :-

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

What's confusing me is, I have read in many places that the VLH should be implemented as a session bean. And even in the core design patterns, further down it explains like this :-

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, and it is much coarser grained.

So, what's the best way to implement the VLH??? . I don't want to design with too many beans with no apparent reason

[Annick BOEL]

Sorry, no answer by still other questions concerning the same topic.
1/ What's your feeling about the need to return to the database or not for each page, or to get the entire resultset in one pass and to scroll to list only?
2/ What will be the kind of objects returned? In Petstore the objects returned are of type Page that are whether Category or Product or Item. In our case it won't be only flights but rather more complex objects, ie sequence of connecting flights from one city to another.
3/ How could the list be presented in the case of a round-trip and the necessity to display both outbound and return FlightSequence objects. How does'it it impact the design?
4/ Is there neccessity to deal with the relationship between city and the many airports that can serve a city, or should it be considered as something hidden by the searching mechanism used, ie the SQL request that will be performed by the DAO, which we don't have to deal with either.
5/ Transactional requirements for this search? In Petstore transcation attribute is required!!!
I'm scratching my head about those 5 points. What's your feeling?
Thanks
Annick

[Giju George]

Hi Annick,

1/ What's your feeling about the need to return to the database or not for each page, or to get the entire resultset in one pass and to scroll to list only?

I would consider storing everything in a list and then iterating throught it. Because subsequent requests will always be a subset of the very first request in prepare itinerary.

2/ What will be the kind of objects returned? In Petstore the objects returned are of type Page that are whether Category or Product or Item. In our case it won't be only flights but rather more complex objects, ie sequence of connecting flights from one city to another.

3/ How could the list be presented in the case of a round-trip and the necessity to display both outbound and return FlightSequence objects. How does'it it impact the design?

I would still consider returning something like a flightVO, and all the complexity of connecting flights etc will be hidden inside the VO implemented by a DAO.Whether it's inbound, outbound or both, it still have to display the same records like :flightno, date, city etc. And this can be stored inside 2 lists (inbound and outbound) and the flightVO will then contain these lists.
There should be some intelligent way to iterate through this lists, but I would rather document it, rather than just cluttering the sequence diagrams

I havn't really thought about this before, but does my logic makes sense ???

4/ Is there neccessity to deal with the relationship between city and the many airports that can serve a city, or should it be considered as something hidden by the searching mechanism used, ie the SQL request that will be performed by the DAO, which we don't have to deal with either.

I prefer leaving it with the search mechanism. If try to implement all these, we gonna end with an extremely complex system.

5/ Transactional requirements for this search? In Petstore transcation attribute is required!!!

Search is for read-only data. Also petstore is using Fast lane reader and VLH pattern. So I prefer leaving it as Required.

The only concern is the "Seats", because if the data is cached then the user may be getting stale data. I mean seats taken by someone else.

[Vishwa Bandhu]

George,

I agree with you. I am almost ready to submit myne and I use the strategy for VLH. But again I do have the same confusion from the Core Design PAtterns.

I plan to save the VLH for the web users in the SFS but for the remote clients, the VLH is sent via serialization and as remote clients hanlde their session by themselves. My thinking is the size of this VLH won't be huge as these are returning flight search result for a small airline(limited no of flights)

I don't think at the architecture and design level we need to be specific how each method is implemented, meaning we don't have to specify how the search results are presented for connecting from city to city. What do you think?

[Ajai]

Giju,

And this can be stored inside 2 lists (inbound and outbound) and the flightVO will then contain these lists.

Why two lists? Can you not keep a flag in each TO which indicates the same so that when you display results you know whether it is in/outbound?Any specific motivation for keeping two lits?


Vishwa,

My thinking is the size of this VLH won't be huge as these are returning flight search result for a small airline(limited no of flights)

Even I thought like that earlier,but after visiting AA i saw one result was quite huge (20-30 records). I though that providing an iterator may help in this kind of rare situtaions.


Thanks..

[Giju George]

Ajai,

Why two lists? Can you not keep a flag in each TO which indicates the same so that when you display results you know whether it is in/outbound?Any specific motivation for keeping two lits?

I can, but I prefer returning just ONE Transfer Object whether for inbound, outbound or both. And that's what I want to show in the sequence diagram, returning something like "flightTO". I want to make it simple.

Does that make any sense Ajai ???

[Ajai]

Giju,

I hope you mean the same when you refer to FlightTO/VO.
If yes , then as per core J2EE Patterns you should be returning something like List which contains xxxTO objects.I think you are doing the same.
But to indicate whether a flight belongs to outbound /inbound ,my idea was to keep another param in TO like isRoundTrip rather than keeping seperate lists like inbound/oubound.


Thanks

[Giju George]

I hope you mean the same when you refer to FlightTO/VO.
If yes , then as per core J2EE Patterns you should be returning something like List which contains xxxTO objects.I think you are doing the same.
But to indicate whether a flight belongs to outbound /inbound ,my idea was to keep another param in TO like isRoundTrip rather than keeping seperate lists like inbound/oubound.

Yes, I mean exactly what you said. I understood your concept of using flags. But where do u actually store the data?. Both inbound and outbound will have two separate set of data, and you are just returning one TO. Are you planning to extend the TO to cater for this ?