I have a requirement where client sends an HTTP requests, our application processes it and generates response and sends back the HTTP response. The request and response need to be persisted on JMS queues. In order for us to leverage Spring integration in this scenario, can we use spring integration HTTP gateways in place of our current MVC controllers ? Would I need separate gateways for each different uri mapping ? Can the HTTP gateway be integrated with JMS channels ? I would appreciate some ideas on the high level architecture using Spring Integration for this scenario.
Thanks.
The fastest on-ramp would probably to inject a Messaging Gateway (<gateway/>) into your existing controller; if you are simply archiving the request/response, you just need a simply gateway method that returns void and in the Spring Integration flow, wire the <gateway/> to a <jms:outbound-channel-adapter/>.
Related
We want to build a rest API to service high request volumes. I'm planning to build it using Spring Reactive(WebFlux) or using Spring Boot Async. We have multiple different clients who will be invoking our service.
Do I need to worry about different clients who will be consuming this service? Meaning if I build the API using Reactive or Async, will all the clients be able to consume this seemlessly?
Meaning if build a reactive Rest API, will the client using RestTemplate be able to consume or do they need to use WebClient only?
Yes, your (not non blocking) clients will still be able to consume a reactive service.
I have a few synchronous microservices working on production using Spring Boot 2.X version. Soon, we need to implement a gateway if the number of instances of each microservice is going to be increased. I read that Zuul was in a maintenance phase and was replaced by Spring Cloud Gateway which is by default asynchronous technology. My question is, can I still implement Spring Cloud Gateway with my microservices?
Yes, you can use Spring Cloud Gateway without any doubts.
Basically, asynchronous technology means that your resources/threads on Api Gateway won't be blocked waiting for the response from downstream services and that increases a throughput.
Now, once your blocking services complete their internal logic they respond back to Api Gateway using an originally opened connection. Api Gateway in turn responds back to your client.
I am building a microservice using spring webflux and netty. Internally I use web client to make rest api calls. How can I control rate at which I can call rest api via webclient? I guess backnpressure is only for a single request/reply and does not work across multiple request to my microservice. Amy pointers will be appreciated.Thanks.
Resilience4j has support for non-blocking rate limiting with Reactor.
See: https://resilience4j.readme.io/docs/examples-1#decorate-mono-or-flux-with-a-ratelimiter
I have a written a microservice using Spring 5 WebFlux and trying to consume a non-reactive REST API through it. Is it possbile to consume a non-reactive service using a reactive webclient?
Yes, this is possible. From the server's point of view, this is just a regular HTTP client. WebClient does support streaming and backpressure, but this doesn't change things at the HTTP level.
The backpressure is dealt with at the TCP flow-control level, so the HTTP protocol stays the same.
I have to invoke a couple of rest web service from my spring boot application. I am planning to use the Camel to configure the flow and other EIP use cases. Some of the endpoints are using oAuth2 authentication. I am planning to use the Spring oAuthResttempalte. All the examples on the internet are either using restlet, CXF or camel-http.
Camel Rest Consmer
I am not able to find a single example with just spring resttemplate. Did anyone implement Camel Rest consumer using Spring Resttemplate?
Some of the Examples on the internet use a jetty server to consume a rest endpoint. Why do you need a jetty server for simple rest consumer?
Did anyone implement Camel Rest consumer using Spring Resttemplate?
I'm not aware of that and it's unlikely to found something in that direction because Camel already have bult-in components to consume rest endpoints.
Some of the Examples on the internet use a jetty server to consume a rest endpoint. Why do you need a jetty server for simple rest consumer?
I believe that jetty was used as a consumer not a producer endpoint. So you won't need the "server". Or maybe you saw an example using jetty acting as a server to serve an OAuth endpoint?
If you excuse my approach, I'd suggest to remain with Camel HTTP/Rest capabilities to consume REST APIs using OAuth. I've found this example on Gist:
from("direct:authService").tracing()
.setHeader(Exchange.HTTP_PATH)
.simple("<auth service context>/oauth2/token")
.setHeader("CamelHttpMethod")
.simple("POST")
.setHeader("Content-Type")
.simple("application/x-www-form-urlencoded")
.setHeader("Accept")
.simple("application/json")
.setBody()
.constant("grant_type=client_credentials&client_id=<client id>&client_secret=<client sec>")
.to("https4://<remote auth service url>")
.convertBodyTo(String.class)
.log("response from API: " + body())
.choice()
.when().simple("${header.CamelHttpResponseCode} == 200")
.unmarshal().json(JsonLibrary.Jackson, AccessResponseToken.class)
.setHeader("jwt").simple("${body.access_token}")
.to("direct:<some direct route>")
.otherwise()
.log("Not Authenticated!!!");
If you want to stick into OAuthRestTemplate you may implement a Processor or a bean to wrap those calls and return to your route the authorization token.