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?

Similar Messages

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 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.

Oracle database architecture documentation

Hi,
Any one can send oracle 9i/10g database architecture documentation.

What do you mean by Architecture documentation? Concepts about Oracle architecture?
Did you go through the documentation?
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/toc.htm
Please post such questions in Database-General forum. This forum is for reporting issues with Oracle documentation.

Architecture question: Integrating AJAX and STRUTS

I'm slowly growing in familiarity with STRUTS and I have the basics of AJAX down, certainly as far as the request-response-parse-do something useful with the data paradigm goes.
My question is more about best practices in using an AJAX enable front-end with a STRUTS-based back-end.
In a nutshell, each user action is handled by a STRUTS action subclass. Requests are picked up by the STRUTS front controller and passed on to the handler for processing. The handler is then able to tell the controller which jsp/resource to send back to the user.
With AJAX, we are (generally) making specific data requests. We are essentially asking for data based on a set of parameters passed through on the request.
In the case of a dynamic search table (containing no business logic), the AJAX request is simply asking for a set of results that match some parameters supplied in the criteria form.
What should handle that data request?
I was thinking about a specific "data-server" set of classes which STRUTS can pass AJAX requests to.
NOTE: I'm thinking about this from the perspective of a new development, not tacking on to an existing application.
Thoughts, anyone?

So let me broaden the question slightly? What are the
best practices for implementing an AJAX solution with
STRUTS? I have looked around on the net but not found
anything that constructive yet.
Suggestions and/or pointers welcome.I have played around with AJAX just to understand how the technology works and how ajax can be integrated into a j2ee (or any other for that matter) web application. I havent worked on a project which has analyzed the best practises/pitfalls of ajax and implemented a solution.
Having said that, here's my take -
Ajax, as far as I know and have seen is a 'view' thinggy - enhanced user experience, lesser clicks, blah blah. The underlying XMLHttpRequest technology is just another way to hit the server with a request. And as I said before, once the server receieves a request, it really doesnt/shouldnt matter where and how the request originated from - it could a tunelled http request (as from an applet/swing app), a normal http request from a browser or a XMLHttpRequest (read ajax). The server validates incoming params if any and performs business logic.
And here's when the similarity ends. The response (or the view) is entirely dependent on the 'requestor'. For browsers, the server would emit html, wap for cellphones, objects to a swing/applet program (possibly).
The point I am trying to make is that this (the view part) is where you'll have to concentrate on tweaking (using the so called best practises) for ajax requests. For instance, there are a set of ajax tags already that you could reuse in your jsps which help developers build cool ajax enabled apps.
(See http://ajaxtags.sourceforge.net/)
There however are a few standard best practises for using ajax itself (and this is at a general ajax as a technology level) - see for example
http://www-128.ibm.com/developerworks/library/j-ajax1/?ca=dgr-lnxw01Ajax
ram.

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.

Oracle Database Architecture Understanding

Hello everyone,
I am a newbie in Oracle arworld, and I want to learn ORACLE. A few months ago, I started to learn Oracle Database Architecture, and read a book. However, I forget much of that books after weeks ago, and read again forget again.. I could not make tangible Oracle DB in my mind. This situation really degrades my performance while working. For example a simple example; the books says;
Data Files:Every Oracle database has one or more physical data files, which contain all the database data. (physical storage structure)
Data Blocks: At the finest level of granularity, Oracle Database data is stored in data blocks.(logical storage structure)
Here, my mind is mixing. Both store data, so what is the difference. I want to go details of Oracle, in order to be successful. Please help me and suggest something to do.
Thank You

I do not believe you will find MOS Docs that describe the architecture. Have you checked the docs ? What specific information are you looking for ?
Introduction to Oracle Database
Introduction to Oracle Database
HTH
Srini

Oracle VM Server for SPARC - network multipathing architecture question

This is a general architecture question about how to best setup network multipathing
I am reading the "Oracle VM Server for SPARC 2.2 Administration Guide" but I can't find what I am looking for.
From reading the document is appears it is possible to:
(a) Configure IPMP in the Service Domain (pg. 155)
- This protects against link level failure but won't protect against the failure of an entire Service LDOM?
(b) Configure IPMP in the Guest Domain (pg. 154)
- This will protect against Service LDOM failure but moves the complexity to the Guest Domain
- This means the there are two (2) VNICs in the guest though?
In AIX, "Shared Ethernet Adapter (SEA) Failover" it presents a single NIC to the guest but can tolerate failure of a single VIOS (~Service LDOM) as well as link level failure in each VIO Server.
https://www.ibm.com/developerworks/mydeveloperworks/blogs/aixpert/entry/shared_ethernet_adapter_sea_failover_with_load_balancing198?lang=en
Is there not a way to do something similar in Oracle VM Server for SPARC that provides the following:
(1) Two (2) Service Domains
(2) Network Redundancy within the Service Domain
(3) Service Domain Redundancy
(4) Simplify the Guest Domain (ie single virtual NIC) with no IPMP in the Guest
Virtual Disk Multipathing appears to work as one would expect (at least according the the documentation, pg. 120). I don't need to setup mpxio in the guest. So I'm not sure why I would need to setup IPMP in the guest.
Edited by: 905243 on Aug 23, 2012 1:27 PM

Hi,
there's link-based and probe-based IPMP. We use link-based IPMP (in the primary domain and in the guest LDOMs).
For the guest LDOMs you have to set the phys-state linkprop on the vnets if you want to use link-based IPMP:
ldm set-vnet linkprop=phys-state vnetX ldom-name
If you want to use IPMP with vsw interfaces in the primary domain, you have to set the phys-state linkprop in the vswitch:
ldm set-vswitch linkprop=phys-state net-dev=<phys_iface_e.g._igb0> <vswitch-name>
Bye,
Alexander.

Architecture question, global VDI deployment

I have an architecture question regarding the use of VDI in a global organization.
We have a pilot VDI Core w/remote mysql setup with 2 hypervisor hosts. We want to bring up 2 more Hypervisor hosts (and VDI Secondaries) in another geographic location, where the local employees would need to connect desktops hosted from their physical location. What we don't want is to need to manage multiple VDI Cores. Ideally we would manage the entire VDI implementation from one pane of glass, having multiple Desktop Provider groups to represent the geographical locations.
Is it possible to just setup VDI Additional Secondaries in the remote locations? What are the pros and cons of that?
Thanks

Yes, simply bind individual interfaces for each domain on your web server,
one for each.
Ensure the appropriate web servers are listening on the appropriate
interfaces and it will work fine.
"Paul S." <[email protected]> wrote in message
news:407c68a1$[email protected]..
>
Hi,
We want to host several applications which will be accessed as:
www.oursite.com/app1 www.oursite.com/app2 (all using port 80 or 443)
Is it possible to have a separate Weblogic domain for each application,all listening
to ports 80 and 443?
Thanks,
Paul

Running MII on a Wintel virtual environment + hybrid architecture questions

Hi, I have two MII Technical Architecture questions (MII 12.0.4).
Question1: Does anyone know of MII limitations around running production MII in a Wintel virtualized environment (under VMware)?
Question 2: We're currently running MII centrally on Wintel but considering to move it to Solaris. Our current plan is to run centrally but in the future we may want to install local instances local instances of MII in some of our plants which require more horsepower. While we have a preference for Solaris UNIX based technologies in our main data center where our central MII instance will run, in our plants the preference seems to be for Wintel technologies. Does anybody know of any caveats, watch outs or else around running MII in a hybrid architecture with a Solarix Unix based head of the hybrid architecture and the legs being run on Wintel?
Thanks for your help
Michel

This is a great source for the ins/outs of SAP Virtualization: https://www.sdn.sap.com/irj/sdn/virtualization

Architectural question

Little architectural question: why is all the stuff that is needed to render a page put into the constructor of a backing bean? Why is there no beforeRender method, analogous to the afterRenderResponse method? That method can then be called if and only if a page has to be rendered. It seems to me that an awful lot of resources are waisted this way.
Reason I bring up this question is that I have to do a query in the constructor in a page backing bean. Every time the backing bean is created the query is executed, including when the page will not be rendered in the browser...

Little architectural question: why is all the stuff
that is needed to render a page put into the
constructor of a backing bean? Why is there no
beforeRender method, analogous to the
afterRenderResponse method? That method
can then be called if and only if a page has to be
rendered. It seems to me that an awful lot of
resources are waisted this way.There actually is such a method ... if you look at the FacesBean base class, there is a beforeRenderResponse() method that is called before the corresponding page is actually rendered.
>
Reason I bring up this question is that I have to do
a query in the constructor in a page backing bean.
Every time the backing bean is created the query is
executed, including when the page will not be
rendered in the browser...This is definitely a valid concern. In Creator releases prior to Update 6 of the Reef release, however, there were use cases when the beforeRenderResponse method would not actually get called (the most important one being when you navigated to a new page, which is a VERY common use case :-).
If you are using Update 6 or later, as a side effect of other bug fixes that were included, the beforeRenderResponse method is reliably called every time, so you can put your pre-rendering logic in this method instead of in the constructor. However, there is still a wrinkle to be aware of -- if you navigate from one page to another, the beforeRenderResponse of both the "from" and "to" pages will be executed. You will need to add some conditional logic to ensure that you only perform your setup work if this is the page that is actually going to be rendered (hint: call FacesContext.getCurrentInstance().getViewRoot().getViewId() to get the context relative path to the page that will actually be displayed).
One might argue, of course, that this is the sort of detail that an application should not need to worry about, and one would be absolutely correct. This usability issue will be dealt with in an upcoming Creator release.
Craig McClanahan

BPEL/ESB - Architecture question

Folks,
I would like to ask a simple architecture question;
We have to invoke a partner web services which are rpc/encoded from SOA suite 10.1.3.3. Here the role of SOA suite is simply to facilitate communication between an internal application and partner services. As a result SOA suite doesn't have any processing logic. The flow is simply:
1) Internal application invokes SOA suite service (wrapper around partner service) and result is processed.
2) SOA suite translates the incoming message and communicates with partner service and returns response to internal application.
Please note that at this point there is no plan to move all processing logic from internal application to SOA suite. Based on the above details I would like get some recommedation on what technology/solution from SOA suite is more efficient to facilate this communication.
Thanks in advance,
Ranjith

You can go through the design pattern called Channel Adapter.
Here is how you should design - Processing logic remains in the application.. however, you have to design and build a channel adapter as a BPEL process. The channel adapter does the transformation of your input into the web services specific format and invoke the endpoint. You need this channel adapter if your internal application doesn't have the capability to make webservice calls.
Hope this helps.

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.

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

Front controller/database - architecture question

Similar Messages

Maybe you are looking for