when frontcontroller is used, one of the benifits is single point of contact to simplify certain things such as enforing a uniform security policy,but i saw someone use multiple frontControllers within a single ejb application, don't know what the rational behind it,i think anyone that study mark cade's case study will notice such usage, any comments? thanks a lot
Multiple Front Controllers within a single web application is a very valid architecture. This is known as Hierarchical Model View Controller (HMVC) as opposed to just MVC. The individual Front Controllers extend from a common base Controller, thus forming a hierarchy. This is what Web Frameworks like Struts and WebWork are based upon. Why would you want to use multiple controllers? For the same reasons one would use multiple Facades or mulitiple Business Delegates... to separate responsibilities and better organize your code. Time for a simple example. Imagine you are making a fairly large website with both secured and unsecured pages. Does it really make sense to have a single controller for both types of resources? The security policy is just going to cause additional overhead for the unsecured pages where it is unnecessary and offers no benefits. It makes more sense to have one controller for the secured pages and one for the unsecured pages. Now imagine you are working on a very large J2EE web application with separate teams coding the various subsystems. HMVC becomes very benefical in this case. Each team can extend their subsystem's Front Controller from a well-tested base Controller so as to minimize code dependencies between the teams. Each team can work independently of one another with the Team Leads coordinating with the project's Technical Lead and Architect for direction. Of course this also means that the base controller needs to be tightly controlled so as to not introduce subtle bugs into the entire project. [ September 11, 2002: Message edited by: Chris Mathews ]
Chris, I agree with what you said, but the frontController hirerachy is applicable to "large" ejb application, application such as PetStore is a sample implementation,which is of medium size, and it uses MainServlet as the ONLY frontcontroller,so I think when I am considering the frontController for the SCEA part2, similar frontController could be adopted as a design strategy,I am sort of take it for granted that such usage is sound till i think of the Marke Cade study case, the project is of the same size and nature as petstore and scea part2's,but I saw very different design of FrontController: instead of one simple FrontController servlet, three are used: CustomerController, OrderController and CatalogController, it is obvious that your theory seems can't explain its usage, no specific different security poliyies are required for different parts of the application,it is not large, so I am now wondering what is the typical design strategy for FrontController for a typical estore application. thanks a lot
I can't really comment much on Mark Cade's book because I don't own a copy (though I read a few chapters in the local bookstore). What I will say is that when you write articles and books many times you use small examples to illustrate important concepts. It may not make sense in the concept of such a small application as you describe from Cade's book, but it could make alot of sense when viewed in the context of a much larger application. It sounds to me as if Cade created a separate Controller for each Use-case (again this is just speculation and I could be far off-base). This could very well be a valid approach, it all depends on the context.
the reason i talk much about mark's study case is mark is the guy who is the director of the seca,he at some degree is the one who tell you what sun is expecting about seca part2 solution, at least two of the ranchers here mention that they attended a conference last year by mark ( fastpath for seca) they follow the path and guideline given on the conference and one guy score 99%(herve attia),the other 91%(Kod Tan), and herve is comments on the book is it is just a part of the what is given on the conference, for him, seems the book does't has anything new. personally,I know that this is just SCEA solution,and to pass it with a good score is now what i want, so follow some gudieline, and don't think in a broad sense, since if look it in a large context, EJB is is itself questionble in terms of design, basically it is not OOP,it is functional( sessionBean) and data( entity bean) is seperated from Bean,anyway, that is off the topic. the reason for mark's seperate frontcontrollers, I think maybe is out of the consideration of decoupling between component and package. thanks
Most people who have completed parts 2 & 3 are not giving Sun's Study Guide good reviews. It's starting to look like a quick source of revenue for Sun. The study guide, the notes from Java One, and the sylabus from Sun's Course SL-425 are all seperate entities.
Hi Guowei, It may not be necessary to worry about front controller in such low level, so long as you know how to use it. even though in reality, developer will follow Mark's solution, as it will allow concurrent development, eliminate dependency among developers. Lipman SCJP SCJD SCEA
Those are the largest trousers in the world! Especially when next to this ad:
SKIP - a book about connecting industrious people with elderly land owners