This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes do we need to always access the business tier Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "do we need to always access the business tier" Watch "do we need to always access the business tier" New topic
Author

do we need to always access the business tier

Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
In a given situation where
1. we are given a list of flights.
2. customer selects flights he wants. (This request IMO should not go to the business tier at all). I dont think at this point the shopping cart shd even be involved as it would be a big network overhead. Such simple selections are generally maintained by view helpers and requets processor.

any thoughts...
Thanks
Dhiren
Sebastiao Santos
Greenhorn

Joined: Jun 12, 2003
Posts: 5
I think that if you view helpers could serve to all clients (web and application), it could work !
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 443
Originally posted by Dhiren Joshi:
In a given situation where
1. we are given a list of flights.
2. customer selects flights he wants. (This request IMO should not go to the business tier at all). I dont think at this point the shopping cart shd even be involved as it would be a big network overhead. Such simple selections are generally maintained by view helpers and requets processor.

any thoughts...
Thanks
Dhiren


I think we will have to go to the business tier (and finally to the database) to get the seat availability once the customer has selected the flight (both arrival & departure).

See Customer is moving step by step with some amount of think time in between various steps.

First he/she picks the flights and then he/she picks the seat(s). There is a theoretical possibility that the flight shown in the search may not have the seats available on click of the next.

To handle this problem of "optimal concurrency", we should go to the business tier.

Also I do not think these kind of results should be cached anywhere. This information should always be requested from the business tier, which should bring this fresh from the database.

It becomes even more complex if you consider a scenario where one Itinerary has many segments, each segment has many legs and each leg is associated to a unique flight.

The search would require you to get the seat availability on all the legs of one segment.

For example: Customer wants to go from Boston to Atlanta.

This would be one segment. But the system does not have a direct flight between Boston & Atlanta, so system proposes Boston to New York, and New York to Atlanta. These would be two legs within a segment.

Now if user selects this segment (and hence two legs), the seat availability check would be needed on both the legs of the segment. All this cannot be cached in HTTP session or even in SFSB.

To support both the web customers and the Agents (which can come directly from SWING APP to business tier for performance reasons), I feel this check should be fresh after selection of the flight.

Hope this helps
Parag Doshi
Ranch Hand

Joined: Jun 29, 2004
Posts: 317
I feel that you can go one step further and specifically differentiate between the two by saying, you can cache the flight results and page them thru for the client, but when they make the selection of flight, the seat selection comes from the DB.

HTH
Parag
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Thanks for all your suggestions.
I was referring to the part where just selecting flight without yet having the need to select seats. In the use case it is one action and I dont think it necessary to go to the business tiers.
for the other calls these are very good suggestions for handling the requests.
Thanks
Dhiren
Parag Doshi
Ranch Hand

Joined: Jun 29, 2004
Posts: 317
Originally posted by Dhiren Joshi:
Thanks for all your suggestions.
I was referring to the part where just selecting flight without yet having the need to select seats. In the use case it is one action and I dont think it necessary to go to the business tiers.
for the other calls these are very good suggestions for handling the requests.
Thanks
Dhiren


Dhiren,
It all depends on where u want to cache your flight results. If you feel that your HTTPSession can handle the flight results, then, yeah, you wouldnt be going to the business tier for retrieving the flight results as they are available on the web tier itself. Also factor in the fact that with increasing number of users, your HTTPSession would soon be bloated, plus if you are gonna load balance the web servers, wouldnt you want to keep your HTTPSessions as light weight as possible?

Just wanted to know your thoughts on these..

Parag

Parag
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 443
Originally posted by Parag Doshi:


Dhiren,
It all depends on where u want to cache your flight results. If you feel that your HTTPSession can handle the flight results, then, yeah, you wouldnt be going to the business tier for retrieving the flight results as they are available on the web tier itself. Also factor in the fact that with increasing number of users, your HTTPSession would soon be bloated, plus if you are gonna load balance the web servers, wouldnt you want to keep your HTTPSessions as light weight as possible?

Just wanted to know your thoughts on these..

Parag

Parag


Parag/Dhiren,

You make excellent points here about. And I am tempted to add my two cents here:

In a typical "usable" search process, the customer should be able to find a match within first 5 to 10 search results.

Each line item within the search result will comprise of complete segment. (Segment->Legs->Flights).

Business tier should expose methods which should return the search result based on the page size requested by the Client.

The web client may request 10 and Swing client may request 20 segment line items in the search results at a time.

Now it depends on the client how they present the search result.
- Web client may display 5 and cache 5 in HTTP Session to be displayed on click of Next
- Swing client may display 10 and cache 10 in its local cache to be displayed on click of Next

As far as caching of complete search result set, which may contain say 100 segment line items:

(a) HTTP Session is not an option and it may not scale.
(b) Business Tier can cache it but then we need SFSB for it.

So I would prefer not to cache the search result any where and to go to the database to get the next set of search result.

I have seen from usability labs that typical user never goes beyond first or second page (unless you are in google).

Thanks,
Deepak
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: do we need to always access the business tier
 
Similar Threads
How many business delegate components??
Prepeare Itinerary - a question
Security question
Caching SFSB handle
Fast Lane in class diagram