Front controller calls

Hey all
At the moment my front controller servlet determines where my JSP calls come from via hidden html fields, sort of like this:
<input type="hidden" name="jspSource" value="addToFavorite" />But I've also seen people take this route:
<form action="/controllerServlet?action=<addToFavorite>Are there any conventions here I should follow? I find that my method works well, but I need a bunch of if clauses in the controller to determine where the call comes from, like this if(jspSource.equals("addToFavorite"))

Just always use the same parameter. I usually use two parameters:
action - this determines what servlet / jsp to invoke
subaction - this determines what the servlet should do and what the jsp should display.
Example:
action - repository
subaction - deletefile

Similar Messages

Front Controller Pattern and issues

Hi,
I've implemented the front controller pattern using a Servlet and some JSP pages. The issue I have is that if the JSP page button is clicked, the controller handles the request and performs the proper forwarding.
But for instance, if I type in the URL for the page directly without going through the servlet in the FORM tag then obviously the servlet cannot process the request.
Here's a more concrete example: I have an informational page that you get to by first logging in. But if I type the name of the page directly, http://localhost/employerInfo.jsp I am taken directly to this page, even though I should have logged in first.
I believe there's a way to do this, but I'm completely stumped as to how.
Any information or insight is greatly appreciated.
Thanks,
John

Hey John,
What you need to do is not to access the employerInfo.jsp directly but call the servlet.
You can map a servlet to a URL. For example, using your example below you can call: http://localhost/myservlet?action=openEmployeeInfo
Now your servlet can retreive the action using String x = request.getParameter("action"); You can test if x.equals("openEmployeeInfo") then get the information from a db or something else. Set the info on a context like request, session or servlet context and then forward to the jsp page using the request dispatcher.
RequestDispatcher rd = request.getRequestDispatcher("/employeeInfo.jsp");
rd.forward(request, response);
If you have more questions, post here again.

Musings: MVC Front Controller/Command and Controller Strategy

Hi,
I am currently taking my first shot at implementing the Front Controller pattern, the Command and Controller Strategy flavor, in Java. When applying the pattern, my chosen point of focus is achieving as much isolation as possible of Client-specific implementation details from the rest of the framework (Web-based framework Clients, Swing-based framework Clients, queueing-based framework Clients, etc.) However, I am running into a lot of (apparent?) inconsistencies when it comes to CCS discussions "out there", so I have a feeling that perhaps I have misunderstood the Front Controller/Command and Controller Strategy pattern. Maybe the MVC gurus out there would have some thoughts on the matter.
My issues:
1.) Some CCS discussions seem to assign View presentation (sometimes called "dispatch", or "rendering", or "forwarding"?) to an ApplicationController. It seems puzzling to me, since only a concrete FrontController should include any knowledge of a concrete View structure. Shouldn't only a FrontController perform a logical-to-physical resource mapping, thus encapsulating knowledge whether a particular View is a separate, stand-alone Web page or a compound, argument-driven Swing object, and how to "present it" (by either redirecting to a Web page, or bringing a particular Swing object into the foreground)?
2.) Some CCS discussions seem to introduce Client-specific implementation details at the ApplicationController level, for example "HTTP requests" or "HTTP responses". It seems puzzling to me, since I feel that every part of the framework, except for a concrete FrontController, should be completely independent of the nature of a Client making a request. Instead, I created a generic Request object w/arguments and have a concrete FrontController translate any client-specific details into such a generic Request, before delegating to an ApplicationController.
3.) In the light of the (2.) above, I am not sure what constitutes a "response" from an ApplicationController back to a FrontController. It seems to me that the only universal "response" is a LogicalViewEnumeration: what View to present once a command has been completed, in many cases a "don't care", or a "show the requestor", or a "show a home page" (not every request has to result in changing a View). Well, perhaps a LogicalViewEnumeration as well as possible View arguments (?).
4.) In the light of the (3.) above, I suspect that any failures in Request delegation, or Command execution, should be perhaps propagated back to a FrontController by exceptions only, since, say, a WebFrontController might want to show a click-through error page, when a SwingFrontController might prefer to show an error dialog box, a LogicalErrorViewEnumeration might not make sense at all in the context of a particular Client, for example a queueing Client.
5.) In the light of the (4.) above, there is the question of an appropriate Request interface (into an ApplicationController), an appropriate Response interface (back into a FrontController), as well as an appropriate ViewArguments interface (into a FrontController and later into a View). The problem with generic Requests is that they can be created with nonsensical argument combinations, so shouldn't Requests be abstract and force proper arguments in concrete subclasses, through explicit constructors (in a sense, degenerate Commands)? The problem with Responses and ViewArguments is that... well, I have not found any formal discussion anywhere as to what those should look like. In most samples I have encountered, Responses include Client-specific implementation details, as mentioned in (2.), above.
6.) Some CCS discussions seem to introduce a Flow Manager at the ApplicationController level. It seems puzzling to me, since the whole point of the Command and Controller Strategy flavor seems to be centralization of business logic execution within self-contained Command objects. Shouldn't Requests get associated with Handlers (objects capable of actually carrying out Requests) and transformed into Commands inside an ApplicationController, thus Commands themselves return appropriate LogicalViewEnumeration back to an ApplicationController, back to a FrontController? Let's consider a ShowMyShippingAddress request coming into the framework: unless such a Request is eventually treated as a Command returning a particular LogicalViewEnumeration, it is suddenly a Flow Manager "acting" as a business logic driver. I guess the question here is: except for a few special cases handled by a particular ApplicationController (authentication, error conditions, default behavior, etc.), should flow management be considered stand-alone, or always delegated to Commands?
7.) Some CCS discussions seem to include an extra Request argument that specifies an ApplicationController to use (Request.Action="create", Request.Controller="account", Request.Username="me-me-me"), instead of using a Router inside of a FrontController to resolve to a particular ApplicationController through a generic action (Request.Action="createAccount", Request.Username="me-me-me"). I am not sure about the reason for such a design decision: why should a Client or a FrontController be allowed to concern itself with an implementation-level structure of the framework? Wouldn't any framework state -dependent ApplicationController resolution issues be best handled inside a Router, used by a FrontController to resolve [obtain] an appropriate ApplicationController, thus preventing Clients from ever forcing the framework into a possibly inconsistent behavior?
Any comments appreciated...
Thanks,
Gary

gniemcew wrote:
1.) Some CCS discussions seem to assign View presentation (sometimes called "dispatch", or "rendering", or "forwarding"?) to an ApplicationController. It seems puzzling to me, since only a concrete FrontController should include any knowledge of a concrete View structure. Shouldn't only a FrontController perform a logical-to-physical resource mapping, thus encapsulating knowledge whether a particular View is a separate, stand-alone Web page or a compound, argument-driven Swing object, and how to "present it" (by either redirecting to a Web page, or bringing a particular Swing object into the foreground)?It is hard to tell without reading the actual discussion, but my guess is that the posters were either conflating or being loose with the distinction between a FrontController and an ApplicationController. The former is (normally) intimately tied to the actual view being used (HTTP, Swing, etc.) whereas the ApplicationController typically is not. Both are involved in dispatch and event processing. The former normally renders a view whereas the latter does not.
gniemcew wrote:
2.) Some CCS discussions seem to introduce Client-specific implementation details at the ApplicationController level, for example "HTTP requests" or "HTTP responses". It seems puzzling to me, since I feel that every part of the framework, except for a concrete FrontController, should be completely independent of the nature of a Client making a request. Instead, I created a generic Request object w/arguments and have a concrete FrontController translate any client-specific details into such a generic Request, before delegating to an ApplicationController.Generic is fine. However, you can become generic to the point where your Request and Response interfaces are only acting as "marker" interfaces (think of java.io.Serializable). Writing a truly generic controller is possible, but personally, I have never found the effort justified.
gniemcew wrote:
3.) In the light of the (2.) above, I am not sure what constitutes a "response" from an ApplicationController back to a FrontController. It seems to me that the only universal "response" is a LogicalViewEnumeration: what View to present once a command has been completed, in many cases a "don't care", or a "show the requestor", or a "show a home page" (not every request has to result in changing a View). Well, perhaps a LogicalViewEnumeration as well as possible View arguments (?).A given service (if you ascribe to SOA) should be the fundamental unit in your architectural design. A good application controller would be responsible for determining how to dispatch a given Command. Whether a Command pattern is used or whether service methods are invoked directly from your FrontController, the ApplicationController should enforce common service aspects. These include authentication, authorization, auditing, orchestration, validation, logging, error handling, just to name a few.
The ApplicationController should ideally offload these aspects from a given service. The service would indicate how the aspects are to be applied (e.g., strong authentication required, x role required, fetching of existing process state, etc.) This allows services to be developed more quickly and to have these critical aforementioned aspects developed and tested centrally.
Your FrontController, in contrast, is responsible for transforming whatever input it is designed to receive (HTTP form data posts, XML-RPC, etc.) and ensure that it honors the contract(s) that the ApplicationController establishes. There are no cut-and-dry decisions though about when a given piece of functionality should be ApplicationController or FrontController. Take error handling. Should I emit just a generic ServiceException or allow the FrontController to decide what to do with a more concrete checked exception? (The FrontController, in any case, should present the error to the user in a manner dictated by the protocol it serves).
gniemcew wrote:
4.) In the light of the (3.) above, I suspect that any failures in Request delegation, or Command execution, should be perhaps propagated back to a FrontController by exceptions only, since, say, a WebFrontController might want to show a click-through error page, when a SwingFrontController might prefer to show an error dialog box, a LogicalErrorViewEnumeration might not make sense at all in the context of a particular Client, for example a queueing Client.See above. Yes. However, the ApplicationController could easily 'hide' details about the failure. For example, any number of exceptions being mapped to a generic DataAccessException or even more abstractly to a ServiceFailureException. The ApplicationController could indicate whether the failure was recoverable and/or populate information necessary to speed up production support (e.g., mapping exceptions to error codes and/or providing a primary key in an error audit log table for support to reference). A given FrontController would present that information to the user in the method that makes sense (e.g., error dialog for Swing, error page for HTML, etc.)
gniemcew wrote:
5.) In the light of the (4.) above, there is the question of an appropriate Request interface (into an ApplicationController), an appropriate Response interface (back into a FrontController), as well as an appropriate ViewArguments interface (into a FrontController and later into a View). The problem with generic Requests is that they can be created with nonsensical argument combinations, so shouldn't Requests be abstract and force proper arguments in concrete subclasses, through explicit constructors (in a sense, degenerate Commands)? The problem with Responses and ViewArguments is that... well, I have not found any formal discussion anywhere as to what those should look like. In most samples I have encountered, Responses include Client-specific implementation details, as mentioned in (2.), above.See comment on marker interfaces above. Nothing, however, stops you from requiring a certain sub-type in a given service method. You can still pass in the interface and validate the proper type by an assert statement (after all, in the vast majority of situations, the proper service method should get the proper instance of a given Request object). IMO, the FrontController would create the Command instance which would be passed to the ApplicationController which would dispatch and invoke the proper service method. A model response would be received by the FrontController which would then render the appropriate view.
gniemcew wrote:
6.) Some CCS discussions seem to introduce a Flow Manager at the ApplicationController level. It seems puzzling to me, since the whole point of the Command and Controller Strategy flavor seems to be centralization of business logic execution within self-contained Command objects. Shouldn't Requests get associated with Handlers (objects capable of actually carrying out Requests) and transformed into Commands inside an ApplicationController, thus Commands themselves return appropriate LogicalViewEnumeration back to an ApplicationController, back to a FrontController? Let's consider a ShowMyShippingAddress request coming into the framework: unless such a Request is eventually treated as a Command returning a particular LogicalViewEnumeration, it is suddenly a Flow Manager "acting" as a business logic driver. I guess the question here is: except for a few special cases handled by a particular ApplicationController (authentication, error conditions, default behavior, etc.), should flow management be considered stand-alone, or always delegated to Commands?There are distinct kinds of flow management. For example, orchestration (or BPM) is properly at either the service or ApplicationController layers. However, determining which view to display is properly at the FrontController layer. The ApplicationController should receive a Command (with a populate Request) and return that Command (with a populated Response). Both the Request and Response are fundamentally model classes (within MVC). The FrontController is responsible for populating the Request and/or Command and rendering the Response and/or Command. Generic error handling is usually centralized for both controllers.
gniemcew wrote:
7.) Some CCS discussions seem to include an extra Request argument that specifies an ApplicationController to use (Request.Action="create", Request.Controller="account", Request.Username="me-me-me"), instead of using a Router inside of a FrontController to resolve to a particular ApplicationController through a generic action (Request.Action="createAccount", Request.Username="me-me-me"). I am not sure about the reason for such a design decision: why should a Client or a FrontController be allowed to concern itself with an implementation-level structure of the framework? Wouldn't any framework state -dependent ApplicationController resolution issues be best handled inside a Router, used by a FrontController to resolve [obtain] an appropriate ApplicationController, thus preventing Clients from ever forcing the framework into a possibly inconsistent behavior?I am not 100% sure of what you are getting at here. However, it seems to be the method by which commands are dispatched. They are in effect allowing a FrontController to dictate which of n ApplicationControllers should receive the request. If we allow a FrontController to directly invoke a service method, then the ApplicationController is simply a centralized framework that should always be invoked for each service method (enforced via AOP or some other mechanism). If there is a single, concrete ApplicationController which handles dispatch, then all FrontControllers communicate directly with that instance. It is really just a design decision (probably based on your comfort level with concepts like AOP that allow the ApplicationController to exist solely behind the scenes).
I might have totally missed your questions, but those are my thoughts on a Monday. Best of luck.
- Saish

Front Controller in Web Logic

I am currently working on a front controller.
WHat i whant to do is pass all call to object on my server through this controller
like this
a get for /Info.jsp is caught by the /* servlet url pattern
next i will handle and check things.
Finally a want t pass the user the Page.
This causes a loop.
Anybody any ideas on how to solve this in web logic

I think what you need to do is make sure that your scripts are not stored in the root path of your application.
In your example you are using the root context to trap all requests incoming, processing that request and then presumably trying to forward or redirect to the /login.jsp page after initial processing. Unfortunately requests sent to /* are intercepted and passed to your controller so the attempt to forward to /login.jsp loops back through your server repeatedly.
Perhaps if you map your controller servlet to a different context to the one where you store your scripts you will then be able to forward successfully
e.g map the context /members/* to your controller, but store your scripts in the /private context - /private/login.jsp . Then provide a mapping in your controller between script name and actual script location, do a lookup and forward accordingly.
if you make sure that all your links within your application point through /members/ they will always be processed through your controller. For example the login page would be accessed as /members/login.jsp but after processing in your controller you do a look up and see that login.jsp is in private so you forward your request to /private/login.jsp .
Well, thats how I would approach it anyway ....

Front Controller Servlet

Hello friends.
I need to implement a Front Controller servlet. I will then forward the request to other servlets. So, even I the client explicitly requests the servlet, say /Dummy, I want the request to pass through /FrontController first.
If I map FrontController to /*, and Dummy to /Dummy, then the letter will override the more general mapping. Also, the first mapping (/*) will spoil all other URL requests, such as /index.htm, etc.
Please, give a hint.

Is it possible at all?
When a servlet is called (any servlet), another servlet intercepts it first, and then forward the request to the called servlet.

Difference between MVC & Front- Controller

Hi All,
could anyone help me out in differenciating the MVC & Front controller patterns.
regards
Karthik

When should an application use the Front Controller
patern and when should they use MVC? This boils down to scope of the problem domain and requirements.
The Front Controller seems largely like a subset of
MVC.Yes.
Is there a situation where the Front Controller
is more advantageous to use than MVC?Where its lighter weight pays off, i.e where you do not have a conventional model, e.g with streaming prototcol handlers or with fast readers. MVC is most useful for a N-Tier J2ee application offering CRUD type functionality.

Bring Excel 2007 to the front when called from LabView v9 in Windows 7

I am building a duplicate system using Windows 7, LabView v9 and Excel v2007. The original system used WinXP, Excel 2007 and LabView v8.6. The issue is that the original system was able to bring Excel to the front when called from Labview using the property node -application-> visible. This new configuration runs Excel, loads the data, runs the macros but does not bring Excel to the front. The icon blinks in the Win7 taskbar and when selected displays over LabView. If I minimize the Labview window, Excel is there. This leads me to conclude that Excel is visible, as requested but will not come to the front until selected from the taskbar. The only differences, besides the versions, is the original system template files used the .xls extension in and was run in Excel in compatible mode. At the customers request, the new system uses the .xlsm extension on the Excel template files. I have tried using application.visible = True in the macro as well. Could be a setting in Labview? Could be a setting in Excel? Could be .xls vs. .xlsm? Or an issue with Windows 7 and the newer version of Labview.
HP workstation - Labview v9 - Windows 7 - Excel 2007 sp2
Thank you in advance
Stephen
Solved!
Go to Solution.

I will try the windowstate change. Were these done in succession? (i.e. property node -> property node -> property node) Or were they done along the way such as call the ActiveX open and a property node then in a worksheet modification area etc. so there was some time between calls?
I am not sure about the API since the discussion there is with regard to DDE. (Taken from the link document: If you want to call a DLL that contains ActiveX
objects, use the Automation
Open VI with the Property
Node and the Invoke
Node.). I am calling Excel as an application not as a library call unless I am mistaken, which I could certainly be. Are you thinking that once Excel is active through the Automation Open VI that a DLL call to set the application visible would work? I may be trying this already but in Excel through the use of the macro I call from LabView. It contains application.visible = True at the beginning before reading files and plotting data.
I may try sprinkling Property node with application->visible in various locations in the LabView diagram as I do update cells after the call to the plot macro. The puzzle for me is the blinking Excel icon in the task bar. This means active and running but not visible or something wrong as well. There are a few #VALUE cells if not all test in the system are run. Again not a problem in Excel 2007-WinXP-LV8.6
Thank you again one and all.

Front Controller Pattern

I'm going to implement the front controller pattern. As it is implemented in the blueprints (Pet Store), requestmappings.xml and screendefinitions.xml are only read upon start up. Thus, the web application has to be restarted to carry out changes.
I'd like the possibility to perform changes to these files without restarting the app. How should I go about? As I don't want to read the file for every request, I need some kind of cache. But this cache should have some kind of automatic updating mechanism when the files are changed.
Has anyone done something like this for large web applications?

I've used a similar approach for this (kitv.co.uk), the project not the website, which is pretty heavy weight application, interactive digital Television over IP.
My design used the command pattern (GOF 233), which is (IMHO) a better solution to implement the front controller.
I created an action/command to perform a reload, this re-initialises my request/response handlers (equivelent to the ScreenFlowManager). The re-initialise is really just an alternative wrapper as the initial load.

Page/front controller

Does JSF implement front controller pattern or page controller pattern?
In this article http://websphere.sys-con.com/read/46516.htm I read that it implements page controller but sincerely I am not able to see JSF fit in this pattern...Do you think it is true? But, above all....why?:P
thanks

I hate to do this to you but check this link for the debate: http://mail-archives.apache.org/mod_mbox/struts-user/200603.mbox/%[email protected]%3E
There is no doubt that JSF uses the Front Controller design pattern, but gives you "page controller" funcationality to.

Splitting up the Spring front controller servlet into more than one file

In a multi-developer environment, it's obviously a bit of a pain to all use the same front controller xml file for mapping requests. Therefore does anyone know of a way we could split this into many files, for example one for each logically distinct application?
Many thanks

Hi,
What are these files did you want to delete? As I know, the trusted installer group owns many system files and will deny you access to move or delete. incorrect deletion of these files will cause serious problem. If you want to delete these files, you can
take the owner of these files and guarantee administrator permissions with icacls command, it can reduce amount of your work.
How to Handle NTFS Folder Permissions, Security Descriptors and ACLs in PowerShell
http://blogs.technet.com/b/josebda/archive/2010/11/12/how-to-handle-ntfs-folder-permissions-security-descriptors-and-acls-in-powershell.aspx
And according to your description, do you want to convert an internal hard drive to external? if so, how did you perform this action? here is an article you can refer to:
http://www.computershopper.com/peripherals/howto/build-your-own-external-hard-drive
NOTE
This
response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you.
Microsoft
does not control these sites and has not tested any software or information found on these sites.
Yolanda Zhu
TechNet Community Support

MVC: Tell a controller class which controller called it

I have to controller pages (page1.do and page2.do) that both shall use the same controller class (CL_CTR).
Can I tell in DO_REQUEST of the controller class whether page1.do or page2.do called the controller class?

Hi Daniel,
To call page1(2).do's from do_request you first put the following in DO_INIT.
data: page1details type ref to cl_bsp_controller2.
page1details ?= create_controller( controller_name = 'page1details.do'
controller_id = 'subcntlr1_id' ).
similarly you should do the same for page2.
Then in DO_REQUEST.
data: subcontroller1 type ref to cl_bsp_controller2.
subcontroller1 ?= get_controller( controller_id = 'subcntlr1_id' ).
call_controller( subcontroller1 ).
I hope this helps.
If it doesn't work let me know.
Regards
Amit
Message was edited by: amit kumar

MVC: Controller called twice in application

I have a situation that I am hoping is not that strange to some of you. The app that I am working on is fairly simple. A table is created using user-input from an input field and a function module in the controller class. This table is then sent to the view and used to populate a tableview. Once a user has chosen a row and clicked submit, the controller is called again. What is supposed to happen, of course, is that I use the row that was selected against the previously created internal table. My problem is that the data in the internal table is lost by the time the user clicks the submit button.
After a little debugging, I've learned that even on the original painting of the view, the controller is called a second time. When the controller is called a second time (without any user interaction yet) all data is 'refreshed.' The view reverts to intitial and my internal tables are cleared.
There is only one controller and one view in this application. Main.do and Main.htm.
Does anyone have an idea as to why the dispatch_input in Main.do would be called a second time, even after the view has been painted on screen and the user has yet to submit anything?
I appreciate any guidance you can give!

Hello Theresa Dancy,
Welcome to SDN Forums...
I suggest you to use the <b>Application Class</b> for storing values.
The main function of Application Class is a BSP Application is to store values in it.
There can be only one application class for one bsp application.
You can find the application class field in the properties of the BSP Application.
Refer this link for more information on Application Class...
http://help.sap.com/saphelp_nw04/helpdata/en/21/8cec3ada87e076e10000000a11405a/content.htm
Reward points for useful answer by clicking the star on the left side of the screen.
Regards,
Maheswaran.B
Message was edited by: Maheswaran B

Extra zero "0" in front of caller ID numbers

Hi all,
I was wondering if anyone has seen this before.. and if so how can I reslove it.
When people call my numer from a moble there's always an extra zero in front of the number.. e.g. 007712345678
So when I try to return the call it fails due to it being a wrong number.
This is also the same when I call 1471.. the extra zero is there too?
Thanks

An update
Mon 7 Oct : Contacted by support agent to arrange an Engineers visit for Tues between 8am - 1pm
Tues 8 Oct 8:07am : Engineer arrived at 8:07am. Explained issue and engineer called my number from his BT mobile. He saw the additional zero. He then called 1471 and the additional zero was there also.
He then ran line tests etc and all seemed good. He went out for a while and spoke on his mobile to colleagues as he hadn't seen or heard of this type of fault before. He asked was my number a BT number or was it transferred from another supplier to BT. I said yes.. it was originally a sky number. He said it seemed like a software / exchange issue and they would need to investigate it further and left.
Tues 8 Oct 10:40am: Text received to say fault was fixed / closed.
Tues 8 Oct 2:40pm: Re-opened fault. Fault not fixed - Zero still there
Wed 9 Oct: Multiple calls to landline from BT engineers working on line. They confirmed they could see the zero when looking at their systems inside the exchanges and that it was some type of network/software fault and would require further investigation.
Thurs 10 Oct: Call from BT support call centre to arrange an Engineers visit. Visit arranged for Sat 12 Oct between 8am - 1pm
Sat 12 Oct 10:17am: Text received to say fault was fixed / closed.
Sat 12 Oct 10:25am: Checked line and fault still there. No Engineer had called. Reopened fault online. Dialled 151 from my BT line and was greeted by SKY Talk customer support?
Dialled 0800 800 151 and got through BT Call centre. Asked why fault had been closed again? She didn't know. She is trying to find out if Engineer will actually be visiting today or not. Due to call back within 2 hours.
To be continued..........................

Front controller/database - architecture question

Hello! Thanks for checking out my question! I am pretty new to web services/servlets and jdbc.
I am implementing an application that essentially is an index of reports. I have an index page where a user can click on one of 6 available reports, go to an input page to customize the information being sent into the different queries and then the results of that query will be displayed on the next page. I have two controller servlets.. one for the input pages and another for the output of the queries. I am just curious as to if there should be anything I need to be cautious about when I am coding this. We expect to have no more than 500 users (that is a very high estimate) on the page at a particular time.
My real question is how do I divide the database calls into the program? Should I have a bean for each jsp result page that handles the queries or should I the queries being handled in the controller request? The result of the query is a cachedResultSet and we already have connection pooling set up so the actual database request will only last a short time. I'm just not sure on the best practice as far as these kinds of things go. Do I need to serialize any requests? Should I consider that when I'm writing the servlets/beans/jsps? Thanks in advance for any kind of answers. Have a great day!

Hello,
I worked on something similar to this, here's what I did in a nutshell:
One controller servlet takes requests which describes a query. It delegates the request a specific request handling servlet/session ejb pair. Every servlet/ejb pair then handles the request and dispatches the appropriate response.
There was a lot a similar functionality in the way responses were handled by the ejbs and this could all be encapsulated in a base handler ejb that was subclassed.
This worked well for my problem but I have also used struts to accomplish similar tasks, although I still think struts is a bit too heavy weight for most of my work.
I think you can use a similar pattern with oridanry beans an JDBC to accomplish your task.
We expect to have no more than 500 users (that is a very high >estimate) on the page at a particular time.I suspect most platforms will accomadate your users but what platform are you deploying your application on?
Do I need to serialize any requests?I don't think so, but why do you ask, will your application be distributed over multiple servers?

Protocol Router for Rich Client Front Controller

Hello,
I would like to support multiple client types in my J2EE application - Web Client and Rich Client (Swing Application).
Java BluePrints (Designing Enterprise Applications
with the J2EETM Platform, Second Edition) suggests using a Protocol Router for centralized control in case of supporting multiple client types with multiple controllers - http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html.
I have several doubts with this approach and will appreciate very much any help with clarifying the following:
1) How does a Rich Client communicate to Protocol Router? Using HTTP? That means then that each request/response has to be wrapped in HTTP Request/Response object. It may impact the performance and make the communication between Rich Client and back-end slower.
2) If rich client communicates with Protocol Router through HTTP, what is the difference between Fron Controller for Web Client and for Rich Client?
3) The J2EE Tutorial on the other hand, shows direct connection from Application (Rich) Client to EJB layer - http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Ebank.html.
It will be greatly appreciated to know how would you address the above doubts.
Best Regards.

1) How does a Rich Client communicate to Protocol
Router? Using HTTP? Yes, HTTP . You are right about performance issues. That protocol router seems to me like like overengineering. Anyway, I think a WEB service could be better choice. It's a standart way how to wrap remote requests in HTTP.
2) If rich client communicates with Protocol Router
through HTTP, what is the difference between Fron
Controller for Web Client and for Rich Client?I think the difference is in types of requests. WEB client would request
WEB pages, SWING client doesnt need WEB pages. It would request contents
of list boxes and things like that.
I would suggest you to use EJB's with session facade pattern. Provide WEB service style access to your app. Many app. servers provide feature to expose SLSB as WEB services. Thus you will support almost any types of clients (.NET, Perl, whatever). You can also use WEB service to connect from you'r SWING client. If later you are not satisfied with performance, you can switch to RMI. If you use BusinessDelegate pattern then you will need to change BusinessDelegate only, just one class.
I have written an example EJB based app. which can be accessed by SWING client using RMI or SOAP, WEB client, .NET client and CORBA.
You can get it from:
http://www.datapro.lv/~mariso/ejb.html
feel free to ask questions, if you have any
Maris Orbidans

Front controller calls

Similar Messages

Maybe you are looking for