Reverse Proxy Java - java

I am working with a Java web application and I would like to have a reverse proxy masking some of my internal endpoints.
Requirements:
The reverse proxy maps need to be modifiable at runtime e.g if we move some components to another server we should be able to modify the mapping such that new requests are routed to this endpoint.
This must be embeddable to a standard servlet container like Jetty.
Most of the Java Reverse Proxies out there such as J2EP require mapping information available prior to starting the application.

Undertow provides an embeddable reverse proxy server that can be changed programatically at runtime.
If you want to operate at a higher level via an API then there is Backflow. It supports adding/removing proxy backends using REST calls.

As far as I can see, http://www.membrane-soa.org/service-proxy/ supports all your requirement:
Membrane has a WebUI where you can add and remove proxy connections at runtime, e.g. forward incoming request on port 80 for a virtual host to a target host:port
Membrane can be run as standalone application or deployed in an application server.
Membrane is an Open Source project under the ASF 2.0 License

Related

How can I make GRPC server run on another web server (not netty)

Grpc Server seems to be implemented using netty. Is there a way to use other implementations ?
Netty is the only supported server. You can either have two separate ports (one for your other server, one for gRPC) or could reverse proxy from your other server to the Netty server.
There is work underway (tracking issue) to allow serving using the Servlet API, so then any Servlet Container could be used. But there are restrictions, like the needing to be the root ('/') webapp. It is far enough along to test it and provide feedback, but there also may be some gaps in the implementation.

Mapping different ports to Java servlets

Scenario
I'm writing a small health check module (jar) that allows users to retrieve information via a JAX-RS REST service. Other applications that use JAX-RS can import this module and benefit from it. The module will use the JAX-RS implementation defined by the consuming application.
Problem
I want to be able to run the health check module on a different port. This will allow us to easily block access to it via the firewall. Is it possible to have multiple ports that server HTTP requests? If so can I map these to different JAX-RS Services easily
If I can't get around this I have been thinking about embedding a small http server into the health check module.
I'm not familiar with TC Server, but since it's based on Tomcat (AFAIK), you could try to configure an extra HTTP Conector for your custom port (http://tomcat.apache.org/tomcat-6.0-doc/config/http.html). The problem then, is that your JAX-RS endpoints may allow incoming requests on both ports, so the problem remains the same. Then you could also add a Valve (http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter) to filter clients based on their IP Address. All this is server configuration, not something based on your module, though.
But IMHO, the cleanest and safest solution would be to secure your JAX-RS Endpoints with authentication mechanisms (your data should be encrypted over an SSL connection anyway).

Programmatically changing haproxy configuration file

Is there any java program or api to change the content of the configuration file of the haproxy? for example to append/remove few configuration dynamically.
Run a thalassa server on the same machine as HAProxy and call its http api from your Java program. It defines restful POST and DELETE interfaces for registrations, which are dynamically configured backends.
append documentation
remove documentation
Inspired by the Answer of allonhadaya I tried out thalassa.
Pearson Eduction who are the main contributes build a complete stack around:
https://github.com/PearsonEducation
So in your example you would probably use three of their components
Thalassa (Service Directory Service)
Thalassa Http Client
Thalassa Aqueduct
The Service Directory is the central service manager. With the application itself (if it is a node application there are predefined compontens) or with the Thalassa HTTP Client you register your service (application) at the service directory. In your case with your existing java application, using the HTTP standalone client might be a good way to start.
Thalassa Aqueduct ist the bridge to the HA-Proxy. It connects the Service Directory with the HA-Proxy configuration. At the moment it has (only) some REST Methods to also configure the HA-Proxy Frontends and Backends. But a quite OK Webinterface to see how many connections are handled and balanced right now.

What are the specific uses of Java Application Server that cannot be done with web servers?

I am a little confused about the roles of a java application server and its differences from a web server.
I found many sites explaining the same difference between the two but not to my satisfaction.
So please explain me about the two following cases:-
1)App. Server and its difference with web server:
From these two links:
Difference between an application server and a servlet container?
What is the difference between application server and web server?
web server: It handles everything through http protocol by accepting requests from clients and sending
responses to them with the help of its servlet container(e.g Apache Tomcat)
App. Server: An application server supports the whole of JavaEE like JMS,JPA,RPC etc.
Now what I am confused with is that how can I use a lot of JavaEE APIs like JMS,JPA etc. with my Tomcat
by adding their jar files in my web application ?
Does that mean that if I use an appliation server I don't have to add those jar files?(I don't think so)
2)The roles of an appl. server (This is very important to me)
From Wikipedia
http://en.wikipedia.org/wiki/Application_Server
An application server provides services such as security,transaction support etc.
"The term is often used for web servers which support the JavaEE" -- It sounds like if we add the required jar files of JavaEE APIs a web server becomes an appl. server.What about it.
Now my question is how an application server performs the tasks of security control or transaction management by itself ?
E.g. in my web application using Spring framework I am providing security by using spring-security and transaction management by using #Transactional annotation and all those things you know.
So does the appl. server have anything to do with my security or transaction management or it has its own ways ?
Forgive my ignorance.
Using Spring, you're in fact embedding some kind of Java EE container inside your application. But even when using Spring, if you need JTA support (because you need distributed XA transactions), you'll need to use an additional transaction manager. If you need JMS, you'll need to install an additional JMS broker. If you need connection pooling, you'll need to use an additional connection pool. Sometimes it's as simple as adding additional jars to the classpath and properties or XML files. Sometimes it's harder.
A Java EE app server comes with everything bundled. You have less flexibility, but you don't need to install, configure and make everything work by yourself.
When you use the Java EE framework, that is a specification. So the application server, if it is Java EE compliant, needs to implement this. So once it is implemented the specification, then it will address Security,transaction etc because it is mentioned in the spec. So it is a contract. Whereas, in a web server, it will just pull out your static resource. There is no need for handling other stuff.
In case of the Spring framework, the framework knows how to handle transaction, security etc. So particularly the developer need not look into these aspects which are implemented by the Application Server in the other scenario.
how an application server performs the tasks of security control or transaction management by itself
It is rather the specification that address these issues, not the application server. So, the duty of the app server is to implement these.
So, if your application is Java EE compliant, then these areas will be addressed and the implementation would have been done by the app server.
May be this is oversimplification,
A web server is basically a HTTP server serving contents over http protocol. So a web server is simply about serving the contents over http protocol. A typical example would be Apache web server. This is simply a file server.
Now the question is where does the web server gets the contents from ? Possible sources are
Static contents (the contents like images/css etc) which are not generated on request but statically served.
Dynamic contents: Simply put, the contents to be served are generated upon the user request.
For the static contents, the web server does not need anything as it simply reads the file and serves it.
For dynamic contents, the web server might need help of additional components which will generate the contents to be served.
Here the Application Server comes into picture.
Now these additional components referred earlier, might interact with database or some other system etc.
In a web environment where your website is exposed to huge number of users (intended/unintended), you need typical services like transaction/security/concurrency etc. so that the user get expected responses and do not see inconsistencies in the behavior of the application.
An application server has inbuilt abilities to manage transaction/security/concurrency/resource management. generally these are referred as Managed services and environment offered by them is called Managed Environment where these basic services are managed by the application server and programmer does not have be bother for them.
Application Server needs web servers or we can say Web servers use Application server's services to generate dynamic contents.
For example, JBoss uses Tomcat as inbuilt web server. Whereas web logic has its own web server. Tomcat again can be called as application server (in principle) as it also offers managed environment for servlets (it manages concurrency and instance pool of servlets/JSPs ).
Coming your your example of Spring:
An Application server will come inbuilt with transaction/security etc whether you need it or not. The Spring offers a very nice way handling this. Spring has all these things BUT you use what you need. Not just these, but just a Java Web Sever like Tomcat is sufficient to build a full fledged services that needs an application server.

How to implement communication between Java EE applications in the same way Apache HTTPD talks to Tomcat/JBoss using AJP?

I've been working on access management solution for an application (Java EE).
Here is what I have currently: In the application I have a filter that checks whether specific HTTP headers are set and authenticates the user based on these values. The application is never exposed directly to the users, but deployed behind Apache HTTPD that performs SSL client certificate verification. In case verification passes it rewrites some data from certificate to HTTP headers and send request to the JK worker that is handled by application server (JBoss).
What I'd like to do reuse the mechanism described above to be able to deal with alternative methods of pre-authentication. For instance I need SAML so I was wondering about implementing a component that would handle SSO (using SAML or OpenID) then set the HTTP headers (like above) and forward request for processing to JBoss. How that differs from the current implementation described above is that the new authentication mechanism would be implemented in Java rather than as another Apache module.
My questions is how to handle communication from one Java EE application to another Java EE application in the same way Apache HTTPD and Tomcat/JBoss communicates using AJP? Is there any service like that in JBoss?
Similar question I've just managed to find: Is there an implementation of AJP protocole in Java?

Categories

Resources