For Requests handling, struts 2 uses FilterDispatcher whereas Spring uses Servlet(dispatcher servlet) for dispatching the requests. What difference does this make? I mean they are doing the same job that is handling the incoming requests but using different strategies, one is using servlet other is using filter dispatcher.
Struts2 and spring mvc are different web frameworks that follow mvc design pattern. The architecture of both differs. Since they are different frameworks, they have different ways of achieving the same thing i.e. request handling. You can read more about FilterDispatcher here.
Related
The common tasks of web application framework(ex: Django or Laravel or .NET or beego):
request / response abstraction
session state
user authentication & authorisation
page templating
URL mapping
DB access
security
caching
MVC design pattern implement above common tasks, as shown below:
URL mapping is handled by Controller component of MVC. Controller routes requests to handlers. Ex: http.ServeMux is the controller from GOLang package
request / response abstraction is performed by Controller by registering the handlers, written by web developer, as shown below:
sm := http.NewServeMux() // in GoLang
sm.Handle("/", productHandler)
session state is handled by the handler code written by web developer
Page templating is handled by templating engine(view component) of MVC
user authentication & authorisation is handled by the handler code written by web developer
DB access is handled by model component of MVC.
security and caching is handled by handler code written by web developer
Is this the right understanding on MVC design pattern to implement common tasks of web application framework?
There are many definitions of the MVC pattern. It was evolving over time and it was used differently in different frameworks and contexts.
When it was invented, there was no HTTP protocol and the request/response part wasn't present. There were some other ways in which the user request was handled. With time, new template engines were invented and HTTP becomes dominant protocol on the web.
MVC is considered to be a pure presentation pattern since it mainly orchestrates views and model(whatever model is representing). Also, one of the main reasons why MVC is invented is separation of concern. It is important to keep it clean, short and to let other layers take care of logic.
The common task of the web application framework is to serve as IoC container (Inversion of control) and let its component worry about specific responsibilities. So if it is a web framework, it will probably have session, cookie, MVC... components.
Controller methods are just an implementation of HTTP interface. URL Mapping can be considered as an argument to controller method.
Request/response are handled by web component (servlet in Java)
Session state is handled by session component and can be configured by developer e.g. session expire time or session cookie type or even session type (database, in memory)
Correct
Usually, there is a proven auth component in the framework, but it can be written manually (not recommended)
DB access is handled by a persistence layer like JDBC in Java. Model in MVC is responsible for data that should be presented on the screen or submitted by the user.
Same as 5
SETUP
At present I have a controller heavy spring MVC application. Its components are heavily guarded with spring security. Most of the datamodel fetching, form binding etc... is done within controllers.
I however see great value addition in using spring web flow.
However I would like to use web flow in a specific way.
First of all I would like the web flow to be like traffic police directing web requests to appropriate controllers inside every state (Along with form binding objects, request, session params etc...).
I would like the controller to ultimately determine direction of web flow like successful login or goto registration page. However it is web flow that will consume the decision and facilitate the transition to the next state.
This next state will in turn leverage mvc by invoking appropriate controllers.
This way spring web flow is just like a facilitator and does not contain too much decision making logic & business logic invocation calls.
This is important for me since controllers can get heavy with respect to services it invokes and can potentially invoke them in a multi-threaded approach. All this cannot be done in spring web flow definitions
QUESTION
My question is very simple and basic. Is Spring Web Flow designed to perform like this on top of Spring MVC?
Is it possible to designate just this traffic regulation and state flow functionality to web flow while preserving most of the control and service invocation logic inside the controller?
--Am I understanding anything wrong here? I want to get these questions cleared before
embarking along this path.
This may be a little late for you, but I'm not sure webflow will give you exactly what you want to achieve. You want a router, and that's not really what webflow was designed for. Webflow is used more for multi-page form type flows, and using it for much more risks running into the limitations of the framework. Webflow cannot be used to intercept all web requests -- only those initiated through the flow mechanism, and it has very strong opinions on what state transition is (for example, form/bean validation is the default, although it can be overridden if required).
It's not that it can't be used as a router, it's just that it's not designed for this so you're likely to find impedance from its form based design goals.
In Spring Integration, handlers and interceptors look like they basically achieve the same thing. There are even some 'duped' implementations, such as MessageTransformingChannelInterceptor and MessageTransformingHandler, which as far as I can tell provide the same functionality with different semantics.
Is there a time when one is appropriate and not another? If it's a matter of preference then I'm guessing that there'd be some sort of convention?
Thanks,
Roy
My general rule of thumb is to use interceptors sparingly; and typically, only for "passive" things like logging, wire tap etc.
Some users like to do message validation in interceptors; especially if they want to apply the same validation to multiple channels, perhaps with a global interceptor with an appropriate channel pattern.
The transforming interceptor was created in a very early iteration of the framework (2008) and we should probably remove (at least) the only mention of it in the reference (in the XML section).
Handlers
Handler means a Class which handles with certain thing.
For example, in the Spring framework, a HandlerMapping is used to map requests to specific controllers or handlers based on the URL pattern or request method.
Handler is responsible for processing a request and generating a response while a Filter is responsible for modifying or inspecting a request or response
Interceptors
Interceptors share a common API for the server and the client side.
Interceptors are often used to implement cross-cutting concerns such as transaction management, security, or logging.
Interceptors are part of Spring's AOP framework and are used to intercept method calls to Spring beans. They allow you to add behaviour to a method call before or after it is executed. Interceptors can be configured using annotations or XML configuration. Interceptors are used to intercept method calls to Spring beans.
I have a restful web service written using Spring WebMVC that will mostly be used to orchestrate other services. In some cases these services are on the same server, in some cases they are not. I have a few requests (GET and POST) that will be direct pass throughs to another service. Is there a way to blindly forward all GET and POST data from a request for certain URLs without knowing anything about the data in the request?
Ideally, I would like to be able to say all requests for http://server1/myService/user/... should forward to http://server2/user/... with all of the GET and POST parameters forwarded with it.
For the services on the same server, if they're being served by the same Spring MVC application, you could use RedirectViews and/or the "redirect:" prefix.
For those on another server, the best thing I can think of would be to use a servlet filter, similar to the approach suggested by this post: spring mvc redirect path and all children to another domain
I am developing web application, also in my product we are also providing financial-non financial mobile services.
Going in details.
In my web application, there is nothing like maintaining flows step by step , simple all CRUD operations and currently we are using Spring MVC which fits to our requirement but for mobile based services, we are providing like message bus support to exchange piggy back information between client and server and we have custom code to implement the solution.
Also our mobile based services need to be exposed over different protocols like SOAP,REST along with need of decoupling of communication packets from services.
All above problems we solved using SPRING MVC only.
My Question is
Is it worth to use Spring Integration framework to replace custom code solution to implement message bus with Spring Integration and if so, what will be the flow for my web application?
If I am using Spring Integration for my web application, how it will render HTTP request to SI?
Is Spring Integration is right choice for any standalone web based application?
Spring Integration is modeled on the Enterprise Integration Patterns and can be best thought of as support Message Driven Architecture. Spring MVC's history and origins is in providing a solution for the MVC pattern akin to Struts, exposing Models and Controlling Views, supported by Services, primarily in a linear fashion. One of the cores of Spring MVC was allowing the dynamic population of a Model that would be accessed by a JSP page (View). All of these things being Web App orientated and ending their.
With the evolution of services (Web, RESTful), Spring MVC has filled a gap and continually expanded to support HTTP access to services, though this is an expansion of its duties, rather than first origins. Meanwhile, Spring Integration was designed with the view of handling Messages and a messages interaction with services, independent of the protocol that it was accessed on. To enable different protocols, different endpoints are available to expose the same service. For example, I can have my crud services built in a POJO, exposed through a Service Activator, and now available to a number of different protocols including REST via HTTP, WebServices, Twitter, XMPP chat services, RMI, TCP, etc. etc.
in short, Spring MVC == HTTP access, Spring Integration == Message access (from HTTP, File, DB, etc.)
to expose a service via HTTP in Spring Integration, use the HTTP endpoints. Typically in a Request/Response (say a Read from a database) you'll want to use the <int-http:inbound-gateway/> and it would look something like this;
<int-http:inbound-gateway request-channel="request.channel" reply-channel="reply.channel"
path="/myService" supported-methods="GET"/>
<int:channel id="request.channel"/>
<int:service-activator input-channel="request.channel" ref="myService"/>
<int:channel id="output.channel"/>
(a key point to remember to is the following...
<bean class="org.springframework.integration.http.inbound.UriPathHandlerMapping"/>
this helps map the path attribute of the inbound-gateway to the servletdispatcher)