I have a service with many controller methods. My task is to "split" this service into microservices.
The microservices themselves will be deployed on other machines. Nginx redirect by location.
The main problem is that there is one location, http://mydomain/myservice/srv/data that receives different types of requests.
And the logic after is called based on the value in the a field in the request body.
For example, two requests:
<request type="getname" val="1"/>
<request type="balance" val="1"/>
The first request must be forwarded on http://mydomain/myservice1/data/name and the second on http://mydomain/myservice2/data/balance
Question: Are there any libraries for such purposes?
UPD: I am writing simple jar based on RouteLocator (spring cloud); is there perhaps another way of doing this? Spring cloud not is the stack we're familiar with.
You may have a look to spring integration, it implements most of the enterprise integration patterns, including content based routing
I think the approach of proxying the request based on different request types in the body is not a good way to proxy. The URI ultimately should be responsible for what kind of request it is serving and response it should be responding to.
The client has all the necessary information on the request type and therefore where to send the request. From that fact, I would refactor the resource that you have to different resources that handles the different request types and determine an explicit schema for the payloads for each one.
To summarize, the implementation would look like the following:
Refactor server logic for different types of requests to their own resource URIs
Move the logic of where to send the request into the client, perhaps utilizing something like a factory pattern
Related
I am using the Jersey implementation of JAX-RS spec to develop RESTful web services. There is a url that can uniquely identify a resource. Is there a way to let know the user of the RESTful services, the possible actions that can be performed on the resource? For example,
Resource name - host1
http://localhost:8080/state-fetcher/rest/object/host1/actions
This should give me all the possible actions that can be performed on the resource - {actions: [GET, POST, DELETE]}
Thanks!
Use the OPTIONS HTTP method on the resource. You will get the allowed methods in Allow header, for example: Allow: GET, HEAD, PUT and in a payload you will find the fragment of wadl associeted with the specified resource.
A RESTful service itself is inteded to be self- descriptive! If the user performs a request, the REST service should send back a list of possible links, which can be performed next, along with the response. That's the motivation and general concept of a RESTful serivice. If you provide a graphical WebClient, you just need to provide the initial link (e.g. http:\example.com\restful), and the response sends back a list of valid links which just needs to be visualized within the GUI. Usually the webservice only provides those links which are accessible in terms of the users role. (This is not a security feature!!! It just prevents that unecessary links are displayed) Otherwise the OPTION method of the HTTP protocol provides information concerning the supported protocol methods.
I understand that with GWT RequestFactory, server-side calls are all made to a RequestFactoryServlet. I'd like to write a GWT application (using RequestFactory) that looks to a cookie to determine which base URL all server-side calls are made to.
So, I'd have 3 different WAR files deployed to 3 different Tomcat instances living on 3 different physical servers, mapped to 3 different IP addresses (URLs). Each WAR would have a RequestFactoryServlet defined and would be capable of servicing requests from the same GWT client.
But, on the client-side, if a widgetType cookie has a value of red, I want all server-side requests to go to:
http://red.example.com/RequestFactoryServlet#doGet
If widgetType=blue, then I want all server-side requests to go to:
http://blue.example.com/RequestFactoryServlet#doGet
If widgetType=orange, then I want all server-side requests to go to:
http://orange.example.com/RequestFactoryServlet#doGet
So, in summary, the client-side cookie (widgetType) determines which RequestFactoryServlet on which WAR/server/URL the HTTP requests get sent to and processed by.
Is this possible? If not, why and is there anything that I can do here? If it is possible, how is it possible (what code/techniques/etc do I need to utilize)? Thanks in advance!
Same-Origin potential issues put aside, all you need is to initialize your RequestFactory with a custom RequestTransport. The easiest is to extend DefaultRequestTransport and initialize its setRequestUrl depending on the cookie value.
I am coding a Tomcat application and am authenticating against Google's oauth2 services. I was originally going to write a simple Filter to do the authentication but there is no way to set the user principal in a Filter. From my understanding you have to have the Filter call an implemented HttpServletRequestWrapper and set it inside of that class as seen in this post
I'm pretty sure Tomcat only instantiates one Filter of each type you may have defined and all requests go through this single object down the Filter chain (correct me if I'm wrong).
In the linked to code, is it correct for the code to call
next.doFilter(new UserRoleRequestWrapper(user, roles, request), response);
where every request is instantiating a new UserRoleRequestWrapper? Should this Filter instead have one request wrapper instatiated that gets shared amonsgst all requests? I'm having a hard time finding documentation on the specs of classes such as these.
I don't think that a Filter is what you're looking for. Doesn't seem right for this purpose... Filters weren't created for such use cases; they were created for pre/post processing requests and responses, with emphasis on manipulating the actual request/response data, rather than other aspects of the client-server communication (such as security). Remember, authenticating a user may have further repercussions than just handling HTTP request cycles. Security ties into the JavaEE framework in a lower level than HTTP cycles.
If you want to authenticate against oauth2, you should be far better off implementing some sort of a JAAS implementation for it, and plug it into Tomcat.
I have a class that I want to hook and redirect HTTP requests in.
I also have a loader class already written, but all it does it replace the functions that contain the HTTP requests I want to change.
Is there a way to hook HTTP requests in Java so that I can redirect them all more easily?
Sort of like a proxy-wrapper.
Clarification:
The app sends out a GET or POST request to a URL.
I need the content to remain the same, just change the URL.
DNS redirects won't work, the Host HTTP header needs to be correct for the new server.
PS: This is a Desktop App, not a server script.
A cumbersome but reliable way of doing this would be to make your application use a proxy server, and then write a proxy server which makes the changes you need. The proxy server could be in-process in your application; it wouldn't need to be a separate program.
To use a proxy, set a couple of system properties - http.proxyHost and http.proxyPort. Requests made via HttpURLConnection will then use that proxy (unless they specifically override the default proxy settings). Requests made using some other method like Apache HttpClient will not, i think, be affected, but hopefully, all your requests are using HttpURLConnection.
To implement the proxy, if you're using a Sun JRE, then you should probably use the built-in HTTP server; set up a single handler mapped to the path "/", and this will pick up all requests being sent by your app, and can then determine the right URL to send them to, and make a connection to that URL (with all the right headers too). To make the connection, use URL.openConnection(Proxy.NO_PROXY) to avoid making a request to the proxy and so getting caught in an infinite loop. You'll then need to pump input and output between the two sockets.
The only other way i can think of to do this would be to override HttpURLConnection with a new handler which steers requests to your desired destination; you'd need to find a way to persuade the URL class to use your handler instead of the default one. I don't know how you'd do that in a clean way.
While an older post, this should give some ideas of some kinds of bytecode injects which can be peformed: Java Programming: Bytecode Injection. Another tool is Javassist and you may be able to find some links from the Aspected-oriented programming wiki article (look at the bytecode weavers section).
There are some products which extensively dynamically modify code.
Depending upon what is desired, there may be ... less painful ... methods. If you simply want to 'hook' HTTP requests, another option is just to use a proxy (which could be an external process) and funnel through that. Using a proxy would likely require control over the name resolution used.
you can use servlet filters which intercept the requests, the requests can further be wrapped, redirected, forwarded or completed from here.
http://www.oracle.com/technetwork/java/filters-137243.html
Do you control all of the code? If so, I suggest using Dependency Injection to inject the concrete implementation you want, which would allow you to instead inject a proxy class.
If you can change the source code, just change it and add your extra code on each HTTP request.
If you can't change the source code, but it uses dependency injection, perhaps you can inject something to catch requests.
Otherwise: use aspect-oriented programming and catch to URL class, or whatever you use to do HTTP requests. #AspectJ (http://www.eclipse.org/aspectj/doc/next/adk15notebook/ataspectj.html ) is quite easy and powerful.
I am wondering how I can use google protocol buffers to accept a request and send a response back to a client? I am thinking about writing a servlet which will take a request.
Is the following trail of thought the correct way to implement this:
1. Have a .proto file which is the message definition for the incoming request.
2. Write a servlet which accepts this request, does various tasks like querying database
and then sends a response. Will this response require a separate .proto message definition with all the fields that make up the response?
3. Will the client just invoke the doGet() method of my servlet and pass the request, it should then return a response as a protobuff object?
Any suggestion or idea will be very much appreciated.
Typically you'd want a request message and a response message, yes. You'd also probably want a method name to describe the action - that's certainly how the built-in PB services work.
The client wouldn't invoke doGet() - it would make a request (probably a POST rather than a GET) and your servlet would receive it.
Now, ideally you could have a general "ProtocolBufferServlet" which could service the requests by handing them off to services implementing the appropriate interfaces.
I suggest you look at the documentation for Protocol Buffer services and the Java services generated code for more information. You could implement an RpcChannel which worked over servlets, or get the client to make the HTTP post directly. You'd probably use dependency injection of some kind at the server side to tell the servlet what was implementing the service.
HI,
I have this up and running. I ended up posting a http request as a post to my servlet. I was able to take the request protocol buffer, read the request, do some processing and then send back a response. It was actually really simple once I got it working. We used the 1 .proto file to define the request and response message structure.