Develop Reference

Spring boot - Threads / Feign-Client / Messaging / Streamlistener

We struggle to find a solution for the following scenario:
Situation
Receive a message via Spring Cloud Streamlistener
Invoke a REST-Service via Feign-Client
We have configured several Feign-RequestInterceptor to enrich
request header data.
We want to avoid passing every request header on the method call and like the central configuration approach of the request interceptors.
Problem:
How to access data from a specific message, which contains informations, that need to be added to every request call via the Feign-RequestInterceptor.
We don't have a Request-Context, as we come from a message.
Can we be sure , that the message consumption and the REST call is happening on the same thread? If yes, we could use the NamedThreadLocal to store the information.

Yes, unless you hand off to another thread in your StreamListener, the rest call will be made on the same thread (assuming you are using RestTemplate and not the reactive web client).

RPC over STOMP using Spring, and correctly handling server side errors propagated to clients

I need to implement RPC over STOMP, where the client runs with javascript in a browser, and the server side is implemented using Spring messaging capabilities.
While using #MessageMapping is fine for normal messaging, I find using #SendToUser quite limitating for implementing RPC because the client has an hard time to understand which reply is associated with which request in a scenario when multiple simultaneous requests are being made from the client.
Of course there is no problem when just only one request is made, and the client waits for its reply, but problems arise when the client has to keep track of multiple "open" rpc calls.
I've managed to make the system mostly fine by associating an ID with every request, i.e.: the client sends an id together with the message, and the server replies with a special message wrapper that contains this id, so the client is able to associate asynchronous replies with requests.
This works fine but has several limitations:
I have to develop code that needs to understand this structure, and that defies the uitlity to have simple annotated methods
when the server side code generates an Exception the Spring #MessageExceptionHandler get called and the correct Exception is returned to the client, but the request id is lost because the handler has no (easy) way to access it.
I know that with rabbitmq we can add "reply-to" header to every request that needs to be associated with a special reply (the rpc response), and this is implemented by creating a special temporary queue that the user is automatically subscribed to, but how may I use this scheme in Spring? Also, that would tie me a specific broker.
How may I elegantly implement a correct RPC call in Spring that correctly handles server side exceptions?
I find this a general problem and I think Spring could benefit greatly to implement it natively.

This not exactly what you demand, but maybe you can attempt something like this :
Path variables in Spring WebSockets #SendTo mapping
You define an ID on your client and send id to the queue /user/queue/{myid}
On the serveur side you will have a class who looks like this :
#MessageMapping("/user/queue/{myid}")
public void simple(#DestinationVariable String id, Object requestDto) {
simpMessagingTemplate.convertAndSendToUser(userId, "/user/queue/" + id, responseDto);
}
This solution can work with the same principle as the rabbit mq solution you mention.
Hope this helps.

If you do not need the exception/reason on the client, but only want to know which message failed you could send ack messages for successful messages. For successful messages you always have easy access to the message id / headers. By the absence of the ack message the client knows which message has failed.
Of course this comes at the costs of sending all the ack messages and knowing the timout of requests. Also additional code is required to keep track on the client side, but this can be done using a middleware and would end up in an ok-ish dev experience for the business logic.

What is WSDL equivalent in restful WS . If nothing,how consumer generates required client side classes?

Say ,i have producer in java and consumer in dot net. Producer has a method that takes
Employee as method parameter and creates employee in db.
For SOAP based ws, dot net client will hit WSDL and creates the stubs (including employee data representation in dot net). Now it can fill
the object and send to producer.
I am not sure how it will work in restful webservices as there is no WSDL. How rest consumer will get to know what are the operations
exposed by producer without any WSDL contract and how dot net consumer will get stubs (like employee data object) so that it can simply fill it and send across?
I know there is WADL(parallel to WSDL) in rest but looks like its not very prominent and not a standard as of now.
I am not getting how client side code will generate EmployeeData class so that it can fill it and send to producer? Will client manually create extra class (instead of proxy EmployeeData that used to be generated on the basis of WSDL using utilities available at client side)? Even if client has to do it manually, how client will know what is the class definition of EmployeeData class without wsdl or wadl?

One important concept of REST is HATEOAS or Hypermedia as the Engine of Application State. What this means is that your client interacts with the REST service through hypermedia links that the service hands it.
Your REST web service has an entry point, say http://yourhost.com/rest. Your client will start by sending the request to that URL. Your service will respond with a resource that describes some or all the accessible resources and how to access them. You keep discovering and following links. This is how the API is published (and discovered).
Here's an awesome video describing this concept: Hypermedia APIs.
Through HATEOAS you can make your service API completely discoverable by just following hypermedia links.
There is no concept of top down/bottom up design in REST.
REST is about resources, not about method calls, which is basically what a WSDL describes.
Even if client has to do it manually, how client will know what is
the class definition of EmployeeData class without wsdl or wadl?
It won't need to create an EmployeeData class. Say you needed to create a new Employee, you would send a GET request to /employees which would possibly return a response containing how to do that. That might be an XHTML response like so (among other things)
<form class="new-employee" action="/context/employees" method="PUT" >
<input type="text" name="employee_name" />
<input type="text" name="employee_age" />
<input type="submit" name="submit" />
</form>
The response contains the exact format you need to follow to create a new employee. You need to submit the form to /context/employees with an HTTP PUT request containing those form parameters. This is HATEOAS. The hypermedia link is the /context/employees. The engine is following this link with a PUT request. The application state is that after this request, a new employee will exist.

Assuming that you're using the Json based WS - there is some tools that helps:
there are json parsers that can turn json, or json schema files into POJO classes, and put some annotations used by Json parsing libraries - take a look here: http://www.jsonschema2pojo.org/
I don't know any automated tool that can generate server stub in terms of all API calls etc. but there is a nice library to consume it - https://github.com/square/retrofit - you have to still put patches and methods signatures into interfase, but it's a way more convinient that playing with "pure" java.
There are also some quite nice tools helping to generate and format documentation for WS - one I like most is swagger: https://helloreverb.com/developers/swagger
There is no (or at least I don't know about it) tool that allow to generate stub, data classes etc. as it can ve usually done with WSDL file.

Pass object as arument in RESTful web service

I am creating a simple RESTful web service with simple types successfully. Now I want to pass an object as argument for web service and get the object as response. My scenario is, Parse the XML message as object by using Jaxb and send the object as request for web service. After that in server side it process the requested object and generates the response xml file and send back it as object.
In URL path i give
"http://localhost:8080/SampleWS/rest/checkXML/username=visolve&password=visolve"
for simple type. But in object I don't know how to give the object reference in URL. Please help me how to solve my problem..
Regards
Bathakarai

Just define a very good-looking domain object. JAXB and JAX-RS will do the rest.
JAXB.
#XmlRootElement
class Regards {
#XmlElement
private long sincerely;
}
JAX-RS.
#Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
#POST
#Path("/sincerely")
#Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Response sincerely(final Regards regards) {
regards.setSincerely(System.currentTimeMillis());
return Response.ok(regards).build();
}

Though you could certainly include the entire XML content in your URL, I would probably shy away from it.
Think of it this way: if you encode the XML in the URL you're potentially adding more work on both ends. Now the server and client will both need to know how to build the URL properly, and check to make sure everything lines up correctly. What if, in the future, you need to offer a JSON or YAML view of the same content? Now your URL might need to include the content-type as well. What about character-encoding?
All this to say, HTTP provides a terrific transport mechanism which already addresses these concerns. Include the XML as the entity body of the HTTP message, and use the HTTP header to identify what content-type you're sending, character-encoding, etc. This will work both ways (the server and client both can send the XML back/forth), and makes better use of HTTP.
Here's a related link which might help with some of the details. And another.
On a side note, please, please, please tell me you don't plan on sending user-credentials in plain text across an unencrypted link.

Redirect/Forward SOAP Web Service Requests to another Web Service

I have a use case that required all calls to NewWebService are routed to OldWebService, if the SOAP request does not validate against NewWebService's XSD and WSDL. NewWebService is located on ServerA and OldWebService is on ServerB.
Abstractly, I know I need some mechanism that will allow me to take a SOAP request that hits NewWebService, send it to OldWebService, then return the SOAP result back to the client. My limited experience with spring-ws is making it difficult to decide how to accomplish that.
My first thought was to build a SOAP client into the NewWebService that calls the OldWebService whenever the payload cannot be validated. Is this the best solution, or is there a better way to allow the NewWebService to act as a pass-through for certain requests?

My solution was to write a custom SoapRequestFilter that implements a javax.servlet.Filter and a new class that extends HttpServletRequestWrapper. Since HttpServletRequestWrapper implements the HttpServletRequest interface, extending the wrapper allows you to copy the HttpRequest and act on the stream without consuming the object and causing issues downstream.
Once I had the filter and wrapper, I was able to parse the endpoint and payload from the HttpRequest. If the request needed to be redirected, I created a new HttpUrlConnection to the old SOAP WebService and set the InputStream from that response to the OutputStream of the HttpResponse.

I think Apache Camel can help you in an efficient way.
You can take a look at its proxy example, it's simple and easy to fulfill your requirement.
http://camel.apache.org/cxf-proxy-example.html