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)
Related
I have a system (kind of aggregator) that integrates with hundreds of different SOAP services - most of them do the same business functionality, but each service having different data structure in SOAP request & very few having 2 API calls to complete one transaction.
The present service integration workflow is
create stubs from WSDL
map data to the generated stub api
setup a new endpoint to fire this api
I see this a repeated, unintelligent work & requires development effort for every new service integration.
Was there different approaches to integrate with lot many systems? Any libraries that can generate soap requests based on configurations, or I have to rely on some Java SOAP, Spring lirbaries to create custom SOAP xml request from my own configurations? I see Spring's WebServiceGatewaySupport for webservice client but requires stubs created from wsdl?
Is it wise to define soap request xml as templates for every service, generate xml with input data?
Other ways I thought was to develop each integrations as independent microservice layered under an API gateway that routes each requests to specific service. But this design approach will have hundreds of services running, consuming more resources (in case of Spring boot).
Generate stubs & deposit the jar to disk, load this jar with a classloader & use the stubs using reflection - not so simple, I believe.
Use of serverless looks promising but is not possible immediately.
This is my first question on StackOverflow and I hope someone can help me. :-)
I am planning to build a web-application (backend) with spring roo. For the backend I will use Spring and Hibernate/JPA. In the future I will implement a web client (JSF/Primefaces), a mobile client (Android) and a Windows App.
With spring roo it is easy to create a layered architecture with domain classes, repositories and services. This part is fun.
But now I am thinking about remoting and how to connect all the clients (web, mobile, windows) with my backend.
1.) What do you prefer for the remoting between client and backend? SOAP-Web Services or a REST-API (e.g. with JSON).
2.) If REST-API: How should the API look like for authentication/login functionality? REST is resource-oriented but how do you implement authentication with REST API?
At the moment I think a REST-API is a good idea. Because I am using spring it is easy to create a Spring MVC controller with REST support. But is this the correct way to implement a REST API for all the three devices? The web client e.g. should be implemented with JSF and Primefaces and I don´t use spring MVC for the web layer.
3.)Can I nevertheless use Spring MVC controllers to build the REST API (together with JSF in the web layer)? Or is there a better way?
1.) What do you prefer for the remoting between client and backend? SOAP-Web Services or a REST-API (e.g. with JSON).
I don't have too much experience with SOAP-WS, but I have a ton of experience with REST-APIs using JSON. There are many implementations for mobile, web and server side clients that are fairly simple to implement.
2.) If REST-API: How should the API look like for authentication/login functionality? REST is resource oriented but how to implement authentication with REST API?
If you are already using spring, I recommend securing your API with Spring Security. You can use spring security even if you don't end up going with Spring MVC for your API implementation. There are many ways to secure a rest API with spring security, but I the simplest is to send the basic auth header with every request to a secure URI
3.)Can I nevertheless use Spring MVC controllers to build the REST API (together with JSF in the web layer)? Or is there a better way?
Spring MVC Controllers will work fine, but I would recommend going with RestEasy or Jersey. I find them to be more flexable.
I agree with #mad_fox. Additionally, i want to add another option regarding your question#2. If you dont want to use Spring security, you can write your own token based authentication mechanism using spring and basic java interceptors.
You can store the token in your browser local storage.
I have started to write two web application projects
RESFful API for mobile clients using Spring REST API
GWT WebApp Server for web clients using Servlets
My problem is that both web applications are using the same database and that I think that instead of having two web applications I actually should have started this project using just one web application that handles the requests for web and mobile clients.
The problem I got now is that I don't have any idea how I could "merge" those two guys and whether I should stick to Spring REST API or if I should use RestyGWT.
GWT Server-Project using Servlets
RESTful Server using Spring
All projects (in the middle of a major refactoring mission)
Is there a way that would allow me to launch the web application as a whole and have access to the REST API from my mobile clients and to the Servlets from my web clients?
It depends on your business logic implementation. If you have it in a separate module/package, then it should be easy to merge your two applications.
You will have to rework the mappings in web.xml and how you pass the input/output data to the business logic methods from both the REST implementation and your servlet code.
Personally I will recommend a single approach such as only going with the REST based approach that you already have and migrate your servlet functionality to it.
What are the advantages of using Spring Rest Web Services over Core Servlet ?
As we know Spring Rest Web Services also use Servlet internally.
REST is a special kind of web service. Whether this is the right thing for your application varies. If it is you should use a framework/library that is designed for REST to make coding simpler. You might also want to have a look at JAX-RS.
If you need a non-REST web service Servlet may be an option, but there are other options, too.
REST is not a type of Web Service - it is an Architecture and specification - JAX-RS. Spring has its own REST implementation libraries primarily based on its MVC controller. I would recommend you not to go for Spring Rest Web Services until you have any Spring specific requirement (Though I cant think of any such requirement which cant be solved by other light wait JAX-RS implementations). Jersey is the most light weight JAX-RS reference implementation by Sun/Oracle which, has support for Spring as well which, can be plugged in on requirement basis.
We have a web application using Jersey and Spring's rest template. Does anyone know of a tool that can scan a code base and produce a report that lists all exposed endpoints and also internal references to those endpoints?
You may also take a look at Swagger, a framework for describing, producing, consuming, and visualizing RESTful web services.
Swagger supports multiple REST frameworks and also JAX-RS based on Jersey.
From their GitHub Wiki:
The Swagger framework simultaneously addresses server, client, and documentation/sandbox needs for REST APIs. As a specification, it is language-agnostic. It also provides a long runway into new technologies and protocols beyond HTTP.
With Swagger's declarative resource specification, clients can understand and consume services without knowledge of server implementation or access to the server code. The Swagger UI framework allows both developers and non-developers to interact with the API in a sandbox UI that gives clear insight into how the API responds to parameters and options. Swagger happily speaks both JSON and XML, with additional formats in the works.
Jersey can provide a WADL report at the /application.wadl URI. It doesn't document complex types but at least gives you a list of endpoints.
See https://wikis.oracle.com/display/Jersey/WADL