I want my JAVA play server to act as a man in the middle server, so that requests sent in are them forwarded to another, different server. Responses from this server are sent back to the initial requester.
I imagine this is a pretty standard user care, but I cannot find any code for Play 2.5 that does this. There is some other similar question around here, sadly it is for an older version of Play.
I would also like to be able to log all incoming /outgoing requests. All requests are http://
All communications are over rest (or are just plain Gets). I'm not familiar with play framework and its CompletionStage stuff. Can i Please have some code that at least begins to put me in the right direction, I'm not looking for 10,000 mile high architecture stuff
:)
(Ideally answers will also cover scala, just because that is more comprehensive.)
I recommend having both servers communicate over rest. So the middle man server calls the processing server via rest. However there are other options like soap and RPC
Related
I have a client software that is written in C++/C# and a database. Now I don't want the client to access the database directly, so I thought about placing an application server in the middle. This one should get a short request from the client, ask the database for new data, do some filtering (that can't be done in sql) and then return the data to the client.
My search for this kind of software brought me to Glassfish or Tomcat but my problem in understanding is, that these always want to talk http with html/jsp. Because most of my data is encrypted anyways, I don't need such plain text protocols and would be totally happy with something that just takes a byte stream.
On the other hand would it be nice to have a server handle the thread pool for me (don't want to implement all that from scratch).
After more than a day of searching / testing I'm even more confused than at the beginning (ejb, beans, servlet, websocket, ... so many things to google before understanding just the simplest tutorials).
TL;DR: how do I get Tomcat/Glassfish to just open a socket and create a new thread for every request, without any HTML/CSS/JSP involved?
Jetty and Tomcat are so called servlet container and thus primarly targeted at HTTP exchanges. Glassfish is an application server that uses a servlet container as one of its modules. I would stop thinking in that direction - that's all more like web applications and web services - some levels too high what you are asking for.
I think you should more look into sth. like Netty which is merley a "high performance protocol" server. Take a look at the documentation here (even some sort of tutorial there which might fit your use case).
GlassFish is an "enterprise application server", targeting the Java EJB specification. That's surely overdone for your purpose. You can give Tomcat a try. It is a "servlet container", targeting Java Servlet specification. Servlets have one purpose: listening to an incoming URL (request), executing Java code and returning a response, usually over HTTP.
For sure, you may start your own (plain) ServerSocket, for example using a ServletContextListener (which will be started once your application starts). But you should go for a higher protocol to send the data, like Hessian and Burlap, which is implemented in both, Java and C++ and easy to set up.
This question might sound a bit abstract,answered (but did my search didn't stumble on a convenient answer) or not specific at all ,but I will try to provide as much information as I can.
I am building a mobile application which will gather and send sensory data to a remote server. The remote server will collect all these data in a mySQL database and make computations (not the mysql database ,another process/program) . What I wanna know is :
After some updates in the database , is it doable to send a response from a RESTful Server to a certain client (the one who like did the last update probably) ,using something like "a background thread"? Or this should be done via socket connection through server-client response?
Some remarks:
I am using javaEE, Spring MVC with hibernate and tomcat (cause I am familiar with the environment though in a more asynchronous manner).
I thought this would be a convenient way because the SQL schema is not much complicated and security and authentication issues are not needed (it's a prototype).
Also there is a front-end webpage that will have to visualize these data, so such a back-end system would look like a good option for getting the job done fast.
Lastly I saw this solution :
Is there a way to 'listen' for a database event and update a page in real time?
My issue is that besides the page I wanna update the client's side with messages from the RESTful server.
If all these above are unecessary and a more simple client-server application will prove better and less complex please be welcome to inform me.
Thank you in advance.
Generally you should upload your data to a resource on the server (e.g. POST /widgets and the server should immediately return with a 201 Created or (if creation is too slow and needs to happen later) 202 Accepted status. There are several approaches after that happens, each has their merits:
Polling - The server's response includes a location field which the client can then proceed to poll until a change happens (e.g. check for an update every second). This is the easiest approach and quite efficient if you use HTTP caching effectively and the average number of checks is relatively low.
Push notification - Server sends a push notification when the change happens, report's generated, etc. Obviously this requires you to store the client's details and their notification requirements. This is probably the cleanest approach and also easy to scale. In the case of Android (also iOS) you have free push notifications available via Google Cloud Messaging.
Set up a persistent connection between client and server, e.g. using a Websocket or low-level TCP connection. This should yield the fastest response times, but will probably be a drain on phone battery, harder to scale on the server, and more complex to code.
We have one customer who sends us thousands of web service requests per minute, and what we're seeing with all of their requests specifically is that the HTTP body comes across the wire, then there is a 150-250ms pause, and then the SOAP body is sent.
Being that the header knows the size of the request, I can rule out that this delay is caused by processing needed to generate the request itself.
Based on the user agent, I can determine that they're using Java 1.5, with HttpsUrlConnection. I don't have access to their code (yet), but I'm wondering if people have seen this behavior or not with poorly written code?
My side: A set of Apache web servers, that are front-ended with load balancers, firewalls, ... those web services take requests and use mod_proxy to send them back to Tomcat application servers.
(Again, this behavior is only seen with this one client, so I have doubts that something on my side is causing this...)
Ended up being a router on my customer's edge was completely saturated/overloaded, adding 400ms+ of latency.. So looks like something where the complete request couldn't be sent quick enough. We have reproduced this same behavior adding 400ms of latency with tcpproxy.
Sometimes it's the most obvious explanation, I guess...
I'm starting to develop what should become a client-server Application using Hibernate, Spring and Eclipse RCP (for the client). This is the first time I'm designing an application from the beginning so I'm just making my first steps.
I have set up Spring on both client and server using RMI for remoting (but I wouldn't mind using something else if there was a clear advantage). So right now I'm able to call exposed services of the server from different clients to get information from the database. What I haven't done is get any kind of authentication in place, so basically the server just answers to the different clients without knowing anything about them, there is not concept of a session yet. Of course this has to change since I need different user to have different roll and so on, but right now the problem I'm facing is getting the server to notify the client when certain thing happen.
My idea to solve this problem was to have a queue of events at the Server and have the clients get them every 3 second or so. The server would then identify the client by it's session token and send the appropriate events. Yet my partner in this project is concerned that this technique (polling) might waste too much bandwidth unnecessarily.
So to bring it to the point. What are the standard techniques for a server to notify a client about changes using Spring? Please notice that I'm not developing a web application and that this is only intended to be used withing a private network. That is one of the difficulties I've been facing: every single tutorial about Spring security or remoting assumes you are making a web application, but I really don't want to get lost into the details of Spring MVC and web applications in general.
Any resources would be appreciated. A good and long tutorial on the matter would be great.
EDIT: Hmm, it looks like JMS might be what I'm looking for.
As I understand, the issues you are facing is identifying a client in request and correlate different client request i.e. have something like a session.
Spring also support RMI over HTTP protocol (Using Hessian and its own HTTP Invokers). Check out this link (Section 17.3). Now once you have transport as HTTP, it has inherent Basic Authentication and session which can be leveraged to get around the issues you are facing.
This is just a pointer. I would be curious to know how eventually you resolved your problem.
could you please give me a sample code on how an Http Server(Java) receives the request of a client(android)? I mean the client sends the request via Httppost, how the server takes the content of these requests in order to see the context and reply? I am trying to built a chat application.
Thank you in advance!
The server-side of HTTP is usually implemented using the protocol stack provided by a web container. You would then implement your application's server-side as servlets. There are numerous tutorials on this.
If that's the way you want to proceed, look at one of the standard web containers; e.g. Tomcat, Jetty, Glassfish, etc. The source code for all of these is available for you to browse, though I should warn you that they are all complicated under the hood.
Assuming that your HTTP service is going to be delivering JSON or XML (rather than HTML) to clients, you may want to look into using a RESTful framework.
Have a look at ServerSocket. Keep in mind that accept() blocks and, as you will probably run it in a service, you will want to time it out and check for the completion of the service. That should probably run in its own thread as should the responders to requests.
From there, you can open input and output streams to receive the request and write the response. There are any number of packages that can help you with the interaction, or you can roll your own, but it doesn't seem like you've done a lot of homework. Perhaps some searching, reading, and more specific questions would more you along more quickly.