GWT and Spring MVC, is it worth it? - java

Is there any reason to use Spring MVC (or other similar frameworks) as a server for GWT RPC? As far as I can tell, 99.9% features of Spring will not be used. Yet, lots of people are looking for best ways to use them together.
Could someone please explain, what are the benefits of using MVC frameworks (on server) with GWT, when all you need on server side is business logic?

I don't see any generally good point in using Spring MVC or another enterprise Java MVC library (like Struts) together with a layer which - as you said - offers only business logic (and therefore can be kept as small and clean as possible).
But Spring itself is way more than just a web (MVC) framework layer and using the dependency injection or AOP features or the ORM API or the Scripting language Groovy (which works fine with Spring) can be a huge benefit for any application.

Spring is much more than just MVC.
Even when you do your UI with GWT, you still need some kind of backend logic.
Things like databases, transactions, security, additional services integrations (emails? SOAP?) and so on.
For this Spring or any other Java server side technology can be a good solution.

As daff said, Spring brings DI + AOP + transactions + many things...
It is useful to have those stuffs managed on your server side with Spring.
Furthermore, the library gwtrpc-spring offers a very convenient way to declare POJOS as rpc services, with the #Service annotation. It avoids declaration of each rpc servlets in the web.xml, as the scan for classes with #Service is automatic.
GWT is just a toolkit, not a framework. If Spring can ease your dev, just use it.

I tend to go for GWT + GIN on the client side and Guice on the server side.
But Spring could just as wel be used for persistance, transactions and organising your business logic on the server side.

Related

Spring features and significance?

Spring empowers POJO based programming.
It offers support for MVC out of the box
wires up code in less time.
How does it support layered architecture?
provides an abstraction layer to simplify development process(why is this a benefit and how does spring handle this?)
How does spring do that?
I read a lot of articles talking about the advantages of spring. But none of them explain in theory i.e. in words not code, how spring does that?
for example, one of the advantages says it empowers POJO programming? we can do that with plain java too, why is that a benefit or what's the opposite of POJO?
Kindly request everyone to address those 3 questions. THanks
in short:
spring was created a long time ago. it was probably compared to ejb2 that needed more setup code. POJO vs EJB vs EJB 3 Also spring does support pojos for example as return value in MVC-controllers. pojos dont have external dependencies so your application stays portable (non-functional requirement of an application).
yes you can easily (my opinion) create web applications.
at its core spring provides a container in which bean definitions are stored. when a service is requested that needs a dependecy, spring can look up whether it has a bean definition for that dependency, construct an instance of that bean and inject it in that service. That way you dont need to manually instantiate your service.
for example in web applications spring has abstractions for controllers, services and repositories. typically an application provides controllers so that caller can use your api. controllers should call services that handle your business logic. and services can call repositories that persist your data. that way you have a layered flow:
controllers --> services --> repository
this has the advantage that when you change e.g. your repository you dont have to make changes to your controllers.
spring provides many abstractions for common problems out-of-the-box (e.g. spring security) and empowers convention-over-configuration. That way you can reduce boilerplate code. less code -> less probability for a developer to make a mistake.
e.g. spring-security-oauth2: you can just set some properties in a .properties file and spring autoconfigures beans that solve the validation of an oauth-token when a user requests one of your controllers.

Which of these approaches is better for breaking Spring Boot applications into three tiers?

We are trying to split a big monolithic J2EE application into a set of modules to provide unified business logic for all web application clients.
Our goal is to have smaller and more specialized business modules that can be used in any combination by many distinct web applications. This way we expect the applications get easier to maintain individually (compared to the now heavily coupled monolithic one).
We are planning to arrange it like the following diagram:
Where Web Apps call module services on the upper layer to handle business logic through method calls (RMI was the intended protocol but we are open to other options).
J2EE makes it easy to arrange services on three tiers like this through EJB remote beans.
But we are also trying to setup these modules as spring boot applications (using the Spring Boot JPA Starter) because it makes development much more convenient.
My initial plan was to implement the modules with Spring Boot and expose a thin layer of EJB beans as proxies to spring beans with the actual implementation of the service. EJB beans would have spring beans injected using the SpringBeanAutowiringInterceptor class as in spring v4 documentation.
But since this kind of integration was removed from spring v5 I don't know how to proceed.
They are also considering "EJB as an effectively deprecated technology now" as stated in the issue above. But for my use case I can't find a good enough alternative.
So far I have thought of the following options:
Using a custom interceptor as the issue suggests. But it looks like reinventing a discarded old wheel (if that analogy makes any sense).
Spring remoting is an alternative but it's challenging to make it work with Wildfly JNDI for RMI configuration and trying to looks like re-implementing EJB remoting.
Spring Integration I think will add too much complexity and overhead for this simple task.
Message based integration (JMS, MQTT, etc...) may not fit well because of the synchronous nature of what we are trying to achieve.
REST API calls would add a lot of boilerplate code (for serialization and deserialization of objects into JSON, endpoints configuration and so on) and also add some ovehead because the HTTP handling.
Our goals, in this order of priority, are:
Make this integration as solid and fail-proof as possible.
Make calls to business logic from the web layer to the service layer as simple as possible.
Have as little overhead as possible.
With all that said which of those five options mentioned (or maybe another one I haven't considered) would be the best way and why?

For performance, Spring webservices or pure restful jersey even if i use MVC?

im using spring MVC and webflow to create a game server and serve some web pages to the users. Thing is, the javascript game will also make multiple ajax calls to restful services on the same server for some game logic. While the web page serving performance is not critical, the restful service calls need to be as efficient as possible (efficient as in response time).
For performance of the services, would it be better to use pure JAX-RS (jersey) web service calls without the spring ws overhead (since i understand the spring layer could affect performances negatively) or would it be the same if i used the spring webservices framework instead and maintain integration with the rest of the spring family?
thanks!
There aren't many clear benchmarks out there, but take a look here:
http://www.techempower.com/benchmarks/
It clearly shows the overhead of using Spring. Compared to Servlets that serve JSON manually Spring is "slower". Personally, I don't think that Spring cuts development time, unless you are very much familiar with it. Creating a simple servlet that will act as a REST API is very simple. Take a look at the servlet code from the benchmark:
Servlet benchmark
I don't think Spring per se will affect performance negatively. Where did you hear that?
Spring web services are "contract first" SOAP services. If you're saying that you don't want to pay the overhead of SOAP, XML, marshalling and unmarshalling, then you have a valid point. That's true whether you use Spring to implement the services or not.
REST is HTTP, so it's a natural for AJAX calls.
I believe Spring 3.0 supports REST, so it's not a "Spring or not Spring" choice:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/new-in-3.html#d0e1188

RESTful web services framework comparison with Spring MVC REST support

In one of our projects we are using the spring mvc. The spring mvc has inherent support for REST web services. I am looking forward to some insight/suggestions on how does Springs mvc's REST support fare when compared with the other popular framework like RESTEasy, RESTlet,JAX-RS etc.
The first big differentiator is that Restlet and RESTEasy both provide implementations of JAX-RS. You can write JAX-RS code that either of those frameworks could run and not have to change anything. Spring MVC is a separate API that doesn't implement JAX-RS. It does provide most of the same functionality from what I've seen. Of course, Restlet also provides its own non-JAX-RS based API which is nice too.
I found this seemingly thorough comparison of Spring MVC and JAX-RS at InfoQ that might interest you. I would say, if you are already using Spring MVC and it meets your needs in the REST department, stick with it until you find a need to look for something else.

How do I easily expose CRUD operations, via a Java based Web Service, on an existing data model?

I have an existing domain model annotated with JPA annotations that I would like to easily expose CRUD operations on via Web Services. I already have DAOs to perform CRUD operations on all of my entities in my domain.
Does anyone know of an way to do this that does not involve a tremendous amount of effort?
It depends on how my operations and services and what you call "a tremendous amount of effort." You're likely to be disappointed if doing anything more than pushing a button and having your wishes come true is too much.
But there are three parts to your problem:
Writing DAOs that expose the CRUD operations. I'd recommend an interface-based approach.
Exposing these as "contract-first" web services, either SOAP or REST.
Mapping HTTP requests and responses to your API.
I'd recommend Spring, because it'll help with DAOs, web services, and mapping. But I don't know if it'll be as effortless as you want it to be.
You can use Apache CXF in combination with Spring ROO to achieve this.
Please see this post for more details: http://forum.springsource.org/showpost.php?p=284028&postcount=4
Throw some annotations on that DAO, like #WebService and #WebMethod and use your JAX-WS implementation of choice. You can use JAX-WS Commons Spring for Spring integration.

Categories