do we need to always access the business tier

[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

[Sebastiao Santos]

I think that if you view helpers could serve to all clients (web and application), it could work !

[Deepak Pant]

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]

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]

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]

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]

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