aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Which is better for a general search call (ref PetStore) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Which is better for a general search call (ref PetStore)" Watch "Which is better for a general search call (ref PetStore)" New topic
Author

Which is better for a general search call (ref PetStore)

Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Should a search be initiated by a shopping cart or by the facade. ?

I have seen Pet store use the shopping cart model. I dont understand what the architecture gains by invoking it from two SFSB ? I would have gone and called it from Facade of the Petstore but again that makes the facade too fat if include all the different search calls.

Any thoughts.
Thanks
Dhiren
Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90
Dhiren,
I have seen three options now of how this could be tackled:
1. From SFSB (e.g. the shopping cart)
2. STSB + preserve search state on the Httpsession (or somewhere else)
3. STSB (do not preserve state)

In Cade's guide option 2 is used (fig 8-10)

I think the arguments for a specific option that you would consider are:
-> does the state for a 'search' need to be persisted? If yes, where?
-> Does the use of a SFSB eliminates the need to go to a datastore again?
If not then you might consider not to use a sfsb
-> where can the search data be persisted? (cookies?, session?, sfsb?)

I tend to agree with your obeservation..

This is probably one of the many "make a choice, state your assumptions and stick with it things" :roll:

regards,
J
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 445
I agree 100% with Josep.

It is a debatable issue and I feel SFSB is an overkill to preserve the Search Result.

Here is the route I am taking, with lot of assumptions:

Facade (Stateless Session Bean)-->Search Service (POJO)-->SearchDAO (POJO)

Key Assumptions:
- Search Results will not cached. System goes to DB everytime user clicks next
- No special container services like transaction, persistence etc is needed so Search Service is a POJO.
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Thanks Deepak and Josep,
From you inputs ,heres how i have decided to handle it.
Search is pretty complicated algorithm anso it could be time consuming to call it every time even using a DAO.
I think the SFSB shdould cache all results aand using the VLH create subsets and send it back.
No caching in the httpSession for light weight sessions.
Thanks
Dhiren
Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90
I think Parag also proposed that solution is another thread, and he scored 99%!! so, should be pretty safe to do it that way.
I am still having doubts on sfsb.
For example, at some point you have to look for cheaper flights. If you go for SFSB, you would have to assume that the cheaper flights would have to exist in the previous selected dataset.
Also, if you would cache all flights in a sfsb, you would also have to cache all seats..(or go to the db for seats separately from the flights).
Will be a resource intensive sfsb this way.
On the other hand, the set of flights will not be very large at any time anyway. (not great many flights will; fly from a to b in one day/period).
Marius Huianu
Greenhorn

Joined: Oct 12, 2004
Posts: 18
Look here at what is written in the Pet Store. The Segment, Flight, Equpment classes are somehow similar with Pet Store's catalog classes.

"Catalog entries are modelled as conventional classes. In this application, catalog entries provide an excellent example of when not to use enterprise beans. Catalog entries are simple, tabular data with little or no behavior. They do not need the services enterprise beans provide. For example, because they are read-only, they don�t require concurrent update management or transactions.

Modelling catalog entries as entity beans would create unnecessary overhead.

Modelling them as conventional classes meets all of their requirements in the simplest, most efficient way."

In addition, you can avoid database calls by caching segments, flights, and equipments.

Regards,
Marius


SCJP, SCBCD, SCEA
Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90
Marius,
I think this is as deepak proposes.

Only remark: Do you want to cache the data on the client/session?
This soultion will then than have a relation to how you solve the two types of clients?

J
[ January 17, 2005: Message edited by: Josep Andreas ]
Marius Huianu
Greenhorn

Joined: Oct 12, 2004
Posts: 18
Josep,

The cache will be kept in the business tier, thus it will be available to
both types of clients.


Regards,
Marius
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Marius ,
I agree with you. I dont intend to use Entity beans to do the actual search.

The cache will be kept in the business tier, thus it will be available to
both types of clients.

Its just the persistent of data for which I intend to use SFSB.
How else is it going to be cached in the business tier.

If I save if it a shopping cart Map only then can it be persisted at the business tier.
Like I said even though its read only data we have complicated algos to give the entire flights etc and it helps to cache that data so as DB calls are not called.
For cheapest flight thats a different DB call so it would need to be called when requested becuase it needs different inputs depending on what customer selected .
So that is the only reason I am using the EJB SB.
Is there any other place other then the session bean cart to cache the data in business tier I would except that technique as I am not keen to use EJB's for just simple caching workflow.
Thanks
Dhiren
Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90
I have been thinking about the same question:

From another thread:
http://www.coderanch.com/t/152921/java-Architect-SCEA/certification/Cleared-Part-II-III

"
Ganesh,
There are a lot of pluggable caching solutions out there, which are used in the business tier and which do not use ejbs. As far as I know, it can be just a simple POJO based component, which provides centralized service to all tiers. It can be fronted by a stateless session bean to provide a single access point, but thats not a big design choice as it can be done without a SLSB too.

Parag
"

I don't like to use pluggable caching solutions in my design....
My best guess is that if you wanted to provide caching, you would use a SFSB (more specifically VLH)

Regards,
J
[ January 17, 2005: Message edited by: Josep Andreas ]
jono
Greenhorn

Joined: Dec 22, 2004
Posts: 25
I think the Catalog in PetStore and the use of POJOs is valid for the search option.

I have a related question which is complicating the issue for me:
- I am struggling to define the algorithm used to search for the list of flights satisfying the initial criteria. Is this too low a level?

- Assuming it's not, I am assuming that Segment(defined as the end-to-end flight including multiple actual "flights") is only created to facilitate user searches and the System does not predfine segments. Do you agree?

Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 445
Originally posted by jono:
I think the Catalog in PetStore and the use of POJOs is valid for the search option.


Yes I agree. Use of lightweight classes is recommended. Caching search result based on VLH design pattern is overkill because from usability standpoint user should be able to find what he/she is looking for in first 10/20 Segments (Combination of Legs or Complete 1 way Flight).


I have a related question which is complicating the issue for me:
- I am struggling to define the algorithm used to search for the list of flights satisfying the initial criteria. Is this too low a level?


Yes you are correct. This is complex. It falls under complex subject of Transportation Logistics. It is not simple to define how flight paths would connect with each other to form a segment.


- Assuming it's not, I am assuming that Segment(defined as the end-to-end flight including multiple actual "flights") is only created to facilitate user searches and the System does not predfine segments. Do you agree?



But here is what I feel can be a valid assumption and my POJO concept fits in here.

Since this is going to be an online application, the search engine cannot execute the complex logic (to find the segments with leg(s)) every time a user (or Agent) visits the site to prepare an Itinerary. It will be wastage of server resources to find the connecting flight combinations at real time and too keep the response time below 5 sec for Agents and below 10 seconds for 28 KBPS dialups.

To provide faster access and quicker response times, the flight data should be in such a form (may be de-normalized) that it could be accessed quickly. So all possible combinations of Source and Destinations should be present in the database in searchable format. The preparation of this dataset will be a very complex job, which can be done by some admin daemon programs that run once three months to forecast the flights for next quarter.
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
I have a related question which is complicating the issue for me:
- I am struggling to define the algorithm used to search for the list of flights satisfying the initial criteria. Is this too low a level?

Deepak
Is it incorrect to give an assumption that implementators would implement the transportation Algorithms. I think its too low level to show the algorithm details in architecture. Justing giving the algorithm in a note would be enough. I just give in a note the algorithm name and say that the developer will implement it at implementation. Is that too little detail do u think ?

Thanks
Dhiren
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 445
Originally posted by Dhiren Joshi:

Deepak
Is it incorrect to give an assumption that implementators would implement the transportation Algorithms. I think its too low level to show the algorithm details in architecture. Justing giving the algorithm in a note would be enough. I just give in a note the algorithm name and say that the developer will implement it at implementation. Is that too little detail do u think ?

Thanks
Dhiren



No you are absolutely correct. I am also stating a similar assumption. Transportation Route Logistics is not in scope and is assumed to be represented in some form in the database.

That's the point I was trying to stress on in my last post.
Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90
Deepak,
If you don't use SFSB for search. Do you still use a SFSB (shopping cart) to store the itinerary before payment? or is the unpaid itinerary stored?
thanks,J
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 445
Originally posted by Josep Andreas:
Deepak,
If you don't use SFSB for search. Do you still use a SFSB (shopping cart) to store the itinerary before payment? or is the unpaid itinerary stored?
thanks,J


Josep,

I am not planning to use any SFSB. I am not convinced that I need one.

I have seen in the past that VLH design pattern doesnot scale well. I think the search criteria and data organization to support the search needs to be organized properly.

Yes, I am planning to save the unpaid itinerary in the database. It is very common in airline industry. Typical reservations done via Travel Agents is kept in hold state for few days without involving payments.

At the end of Prepare Itinerary, a composite transfer object (VO or TO), which is maintained in HTTPSession or Swing local memory is passed onto business delegate for persistence.

BusinessDelegate(POJO)-->SessionFacade(SLSB)-->XXXService (POJO)--> CompositeEntity-->DependentBO

The Change Itinerary use case clearly states that user searches for itineraries and then picks a segment to change.

How do you plan on supporting this? Are you planning to allow changes to paid itineraries?
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Yes, I am planning to save the unpaid itinerary in the database. It is very common in airline industry. Typical reservations done via Travel Agents is kept in hold state for few days without involving payments.



Deepak ,
So how do u intend to reslove the case where itineraries need to be cleaned. Agreed its there in practical applications, but it does become pretty complicated to implement it here.
The use case of prepared itinerary always goes to pay for itineray.
Ideally in shopping carts its content is stored in session and gets cleaned up per client sessions.
I am leaving it an implementation option instead of architecting exclusively for this requirement.
Whats your thoughts
Thanks
Dhrien
Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90
Deepak,
thanks very much, you helped me a lot!
I understand the verious options now
Regards,
J
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Deepak,
i have a question, we u look at the uses point, u would see that for prepare and change a necessary use case is always executed. how would u avoid that for getting called for unpaid. Does it imply that unpaid can not be saved .. ?
please give your suggestions.
Thanks
Dhiren
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Which is better for a general search call (ref PetStore)