in this case, if you look the BDM, you'll see that the shopping cart is persisted (some entities are missing, of course).
Scalability problems are typically due to the misapplication of stateful and stateless session beans. The choice of using stateful or stateless session beans must depend upon the business process being implemented. A business process that needs only one method call to complete the service is non-conversational business process. Such processes are suitably implemented using a stateless session bean. A business process that needs multiple method calls to complete the service is a conversational business process. It is suitably implemented using a stateful session bean.
However, some designers choose stateless session beans, hoping to increase scalability, and they may wrongly decide to model all business processes as stateless session beans. When using stateless session beans for conversational business processes, every method invocation requires the state to be passed by the client to the bean, reconstructed at the business tier, or retrieved from a persistent store. These techniques could result in reduced scalability due to the associated overheads in network traffic, reconstruction time, or access time respectively.
When I expect too many simultaneos clients (considering requests per second) I usually avoid using SFSB. There are other solutions (POJOs inside HTTP Session).
If I assume that memeory is no more a constraint in today's world, then SFSB goes well as an architectural decision.
Sun Enterprise 10000 Server - For large-scale, mission-critical applications, such as high-volume OLTP, server consolidation, data warehousing, and decision support, the Sun Enterprise 10000 e10K server, also known as Starfire, helps lower Total Cost of Ownership (TCO) across your IT organization. Mainframe-like Dynamic System Domains enable the Sun Enterprise 10000 server to host multiple workloads, automatically adapting to your needs as your application environment changes. With support for up to 64 CPUs, 64 GB of shared memory, and more than 100 TB of storage, the Sun Enterprise 10000 server powers many of the world's most demanding, mission-critical application environments
Let me share my thought on DAO.
Around 70-80% of the customer/user will use the site for searching the flights. So I think Fast Lane reader will be ideal for searching the flights (read only data). As per blueprint, they are recommending accessing DAO directly from client/web tier. I am not too certain of directly accessing DAO from client tier. In the current scenario, even for search, I will use Stateless session bean � to DAO call. I do not see any reason for using entity bean for search. What do you suggest?
For creating/reserving seat, IMO it is good to use BMP (using DAO). By doing this we can utilize the infrastructure provided by Application server such as transaction management/data sharing. It is also advisable to use DAO since it is not a good idea to model entity bean for each of the domain classes (Segment/Flight/Equipment)
Originally posted by Bobby Sh:
MY thoughts are as below:
- I have divided the design in two parts:
1. Search : Once the user submit the search Criteria, a value list containing all the flights details will be returned using SLSB.
I assume that the UI will provide the feature like sorting(sort by price/time table/airline) and paging (show the result set in page fashion) the search result. Now the logic of sorting/ paging will be implemented in following way:
- The swing client will be able to sort/ 'Page the result set' at the client tier.
- The same logic for web user will be implemented in web tier in the session scope.
This way, the swing application will be faster than web client by avoiding network traffic.
Now when the user has selected the flight to book,
A VO will be sent to EJB layer, adding customer related detail.
2. Reservation : Session Facade will be used to interact with all interfaces using
bean-managed transaction. This way the transaction can be rolled back if anything goes wrong (seat is no more available, TransMaster has returned failure during authentication)
<> your justification for using BMP is incorrect. You can do all that using CMT as well. i.e. Rolling back transactions etc.
I have a question for you though....why cant you put both into a single facade ? Whats your objective or having 2 seperate facade both SLSB(s). Since you are using SLSB how does it matter if you are using 1 SLSB or two.
Why NOT to use SFSB
There would be users who would login and search for flight and will not confirm the iternary at that time, (for the reasons like they would like to check other website or deal). In such case if I am using SFSB, these EJB will eat App server memory till the session time out.
This is exactly what I mentioned before why I am using both a SLSB as a facade containing business logic and an SFSB (only for confirmed iternaries) for logged-in users try to pay for prepared iternaries.For all other cases e.g. searching, pricing etc, we need not use SFSB. SFSB in my case will only be created once the user 'confirms' to the price and tries to checkout after seats are available. Hope I am clear
Originally posted by Bobby Sh:
Why are you calling 'SLSB --> create SFSB -> ReservationSFSB.' is that SLSB a facade?
But in this scenario, I would consider SFSB as facade 'cause this is hiding the complexity of ITransMaster, IternaryDAO, etc. I am just wondering why are you calling SFSB from SLSB. is there any advantage that I am missing?
Secondly, Are you guys using any Entity bean (with DAO) or directly DAO without using Entity Bean?
Looking at the cade book's case study, I do not see any Entity Bean.
Do you see any advantage of using one over another ?
SFSB is just a structure used to store reservation information of the iternary it is not a facade. SLSB (Facade) will have those methods to invoke Transmaster and other DAOs. SLSB will create SFSB at an appropriate time and pass the handle of SFSB to the web-tier. Then onwards only this handle (which represents the state of reservation) is passed across tiers. thats it. This makes my facade v. light weight.It will only have workflow related calls.
Is httpsession used to store client information?
If so...then why SFSB facade?
If not, Why 2 SFSB ?