Hardware inputs for architects

[D. Rose]

Hi,

I have a question for practising architects. Generally it is good to have updated h/w knowledge as well ( to recommend the mcahine configurations). How do you keep yourself uptodate? Any good links etc?
Also sometimes it is needed to make recommendations about which appserver to use etc if it is totally new system and if these choices are not already made.
Are there any good books/magazines/links to help in this area?

[Joseph Zhou]

For the hardware, we have two servers for web tier, that means the web servers are clustered. How can we make the state to be maintained in such an environment? I don't think stateful session bean can across clustering, but any other way, cookies, URL rewriting, or DB are not J2EE recommended.

[Ramon Gill]

Hi D,
Can't help you much here. I think most of us are in the hands of consultants. IBM guys recommending their own machines, etc.

Joseph,
The CIO says 2 web servers and 1 application server. This could also be interpreted as 2 HTTP servers and 1 application server that includes 1 web container and 1 EJB container. This would mean no clustering and probably use of local interfaces for performance gains.

any comments?

Ray

[sankha das]

Hi,
yes the dual HTTP Servers have been mentioned for increased scalability and failover management. Failure in 1 web server box will or should redirect users to the other box with no waittime.
In real life however, we look at existing conditions and decide as to what level of scalability we wanna achieve. This will also tend towards managing sessions in the web tier instead of SFSB which can easily be handled for a web client. For application clients, however we need to pass the session information to and fro for every request. However, the benefit of local interfaces can be achieved as pointed before. As an architect, you need to focus on aspects you think are important and design accordingly.

[Joseph Zhou]

Hi Ray,
The web and application co-locating may not a valid choice, otherwise, why we need the two web server? Also, the scalability and performance is explicit required, so the hardware listed seems used to support load balancing on web tier, fail over also could be supported. Sankha gives a good description about maintain session state in web tier, the con is browser could refuse cookies and URL rewriting could slow down UI. I think we can also use DB to maintain the session state. The con is we need to clear up some unused or unfinished �Flight shopping cart� after the departure time is passed.

[Ramon Gill]

Hi everyone,
I was pointing out that this is another case of the assignment being open to interpretation. We need to state assumptions about the choices for the servers. I think a case can be made for a number of solutions.

Ray

[sankha das]

Hi,
Sun left the implementation exercise to the architect themselves. How best to use the 2 webservers and the single appserver is ones own choice. But as Joseph points out, they aren't meant to be co-located. Now once we have separate boxes, we need to address things like managing session, clustering(best implemented with Hardware choices mentioned in the assignment but again depends on the architect whether to design for failover or not), caching etc for each tier. To re-iterate my previous post, session data can be maintained at webtier level, which was precisely what I assumed for my assignment. The pros could be easy scalability in design, can do away with burdensome SFSB and local interface use for application clients. But we need to make sure session data at web tier is at the minimum. I reckon to store only data related to user preference and navigation details only. Application specific data(like itinerary) could be send and stored at the DB level. And yes, for some minimum loss of functionality we may not decide to store in DB actually. The assignment nowhere speaks about maintaining clients itinerary, in which case worst come worst client will have to start storing items in his/her itinerary in case of failure all over again. Perfectly legal assuming we make the above assumption of not persisting client itinerary state.
I would not prefer DB to maintain the session state as Joseph points out
"need to clear up some unused or unfinished �Flight shopping cart� after the departure time is passed."
Once again this is an architectural decision and if implemented needs to be reflected and supported in the design choice. the hardware options have been given for more design decisions but I am sure Sun won't fail anyone for not using an hardware component and documenting its unusefulness.

Thanks
Sankha Subhra Das

[Joseph Zhou]

Hi Sankha,
If we ignore the hardware provided, the Architecture will be simpler but the scalability will not very good, but the good scalability is mention several times in the assignment.

[Joseph Zhou]

Hi D. Rose,
Do you think the web tier clustering design is mandatory or optional?

[sankha das]

Joseph,
Scalability is a required feature in the architecture design but Clustering, Load Balancing, Failover is NOT. Though it would be highly recommended to include these facets in the architecture, in practice these are "good-to-have" features. Also with these arise the necessity to ensure required respose time, failover management handling, logging and web session/transaction management if any. Sun's original intention might well be to allow clustering/failover specifying the two boxes but as an architect you should always think about fitting your architecture to the hardware and NOT hardware to the design.

Thanks
Sankha Subhra Das

[Joseph Zhou]

Hi Sankha,

Thanks for your reply. What I want to say is: SFSB may not suit for clustered environment, please see my post at "shopping cart for FBN" laterly. For round robin solution, obviously no. For hardware balancing, it seems requiring DB for directing the correct server for maintaining the session, if we already use DB for session, why we still need SFSB? It like a real world concern, but it affect if we can use SFSB in our design. I know nobody will will fail us if we use SFSB...

[sankha das]

Joseph,
you are absolutely right when you say SFSB is not apt for clustered environment. I dont wanna point the pitfalls of SFSB here but you can refer the article by Tyler Jewell wherein he discusses the true purpose of SFSBs, where they belong in a J2EE design, and the situations where they should not be used. http://www.onjava.com/pub/a/onjava/2001/10/02/ejb.html

Yes you can achieve load balancing either from your DB or Web/Application Container. The mere fact the Sun prefers to see use of SFSB's should not bias your design choice.

When it comes down to the debate between servlet session and stateful session bean, the servlet session wins out in my mind, except for one point that people always resort to: If you store conversational state in your
HTTPSession then you can't reuse your EJB's for other types of clients.
Very Very true indeed. So herein you hafta think about your TA's. How are they gonna maintain their sessions ?

Sun's choice of hardware gives us a hint trying to identify where the "most appropriate" place for your conversational state should be located. I'm not arguing for completely server side or client side, rather, the state should be located at the tier that does transactional or request demarcation.

For web applications, HttpSession is often enough. If you want the benefits of a SFSB, you can go ahead and design the same. However, all depends on what and how much of session data you wanna store at client. In my design, I have used session data to store only navigational and user preference data. This makes things simple and save increased memory requirements on the server through use of SFSB. I could have gone ahead and added another DB component to synchronise the session state in web tier from time to time. Maybe I left it for next version of the design. Only pitfall, disconnected client will need to restart the booking process all over again but for a 3 page site(login, search and booking), it won't necessarily turn off users.
So bottomline, go ahead and design you think would be necessary to support all requirements and point the design choice(among alternatives obviously) in your assumptions section.

Thanks
Sankha Subhra Das

[Joseph Zhou]

Hi Sankha,

Your detailed reply is a great help, thanks a lot. Currently, the application UI also could be a Web Start client, just like the UI, it also uses http to connect to back end, so I think we can have HttpSession too.