I want to expose a Java application via IIS. I found an answer in Running a java web application in IIS that refers to the isapi redirector. However what also seems to work for me is to set up IIS URL rewriting rules. E.g. I have set up a rewrite rule that matches ^java/(.*) and rewrites it to http://localhost:8080/{R:1}
I am a programmer and not a web server administrator, so I do not understand the implications of one versus the other. Which is the preferred approach and why? URL rewriting seems simpler to setup since it involves less 'moving parts' and less configuration.
In my experience I've had to use the ISAPI redirector when the following conditions are met:
Company/System policy doesn't allow to expose another HTTP port on the server (i.e. 8080/tcp), and IIS already owns 80/tcp, so another server can not be bound to this or any HTTP port. In this case IIS and the Java server communicate through the AJP port, and the workers files have to be configured to redirect only to the context of the Java application.
[Optional] For performance reasons, static content (html, js, css, jpg, ...) has to be hosted on IIS and only the dynamic content is left for the Java server. Again this calls for some careful workers configuration and selective deployment of content on each servers.
If you don't have to meet any of these conditions, and if Company/System policy doesn't enforce that all requests go through IIS, then a URL rewriting rule is probably OK.
Related
I have two different APIs. They each have their own .war file and are both running on the same tomcat instance.
Strangely, I am able to reach one API with requests like this: https://(ip-address):443/(path1)
but the other responds only to this: http://(ip-address):8090/(path2)
Also complicating things is that, when I deploy the second war to a certain other tomcat instance on another server, it will respond to https 443 requests.
Any idea how this is possible?
This is strange, because at different times either the war or tomcat works as intended (by using https), so it is unclear whether to blame the war or tomcat.
Applications can declare they need confidential connections (HTTPS). Look at the WEB-INF/web.xml inside.
So one of the applications might use both because there is no constraint defined, the other may just respond to https as the container is responsible to ensure secured communication. I'd be more surprised to hear that one of the applications responds to http only.
From https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Introduction:
One or more such Connectors can be configured as part of a single Service, each forwarding to the associated Engine to perform request processing and create the response.
Check in your server.xml whether you have several services with http and https connectors that are mapping to different engines, and whether the applications are deployed distributed on these different engines. That could explain one application responding to http only, while the other is responding to https only.
I'm considering using gRPC for a b2b API and I can't quite figure out if gRPC server can run on top of another http2 capable web server?
In the examples provided on the official site the gRPC API is always running on its internal netty based server on a particular port.
So, if let's say I have several gRPC applications it looks like I'd have to run them on separate ports.
But I would like to have a single API entry point (a web server like jetty on a single port 443) that would manage the URLs and map them to the particular gRPC service implementation.
Is it possible with gRPC?
No, grpc-java cannot respond to RPCs as a servlet.
Servlet containers supporting HTTP/2 are very new and gRPC hasn't investigated them much yet. It does seem feasible to use the async servlet APIs to implement a gRPC server (as an alternative to the Netty server), except possibly for trailers. It's not 100% clear how to send trailers when the server is HTTP/2, since a common technique with HTTP/1 was for the servlet to manually perform chunked encoding which does not exist in HTTP/2. In any case, it isn't implemented.
Edit: An issue is now open GitHub.
I have multiple Java web applications deployed on the same server (Wildfly).
They all should use a single WebSocket implementation to send messages (object, not plain text) to the user.
Edit: WebApp1-3 are the applications with the business logic. The only purpose of WebApp4 is to update a Primefaces panel in the browser based on the messages generated by the other WebApps. Sorry for the missleading illustration.
WebApp1
WebApp2 --> ??? --> WebApp4 (WebSocket-Server) --> JS/Browser
WebApp3
Which is the best way/pattern/implementation to make WebApp4 available to the other applications? (RMI, JMS, WebSocket, WebService, ....?)
My advice, for a general way of exposing services, is to expose REST services since they are simpler than SOAP web service and easily allow interoperability (if in the future a PHP or a RUBY webapp needs to consume your services it's much easier with a REST interface than with one base on RMI or JMS). The content of the REST service may vary, I suggest you to look at XML or JSON as a way of transmitting information over http REST services.
If all webapps are in the same server, you should forward requests from one to another. From the point of view of webapps 1-3, they would not need to be aware of whether their incoming requests were coming from webapp 4 or from outside (to which it appears that they are not connected). Of course, you are free to alter requests before forwarding them - or to drop them altogether, for example if authentication fails.
To do this in tomcat: https://stackoverflow.com/a/8951090/15472
When forwarding requests, the external client is completely unaware of the existence of webapps 1-3 -- as far as the client is concerned, it has sent a request to webapp 4, and it will think it is receiving a response from that same server.
You may need to configure your web server to allow these kinds of calls, but I am unfamiliar with WildFly.
By default, the Java web apps that I develop runs on http.
Suppose, if I want my web app to run on https, is there something specific that I should do as a developer? Or it it totally a network-guy task and un-related to developer?
Basically I want to know the steps to host a Java web application on https.
You don't need any programmatic changes in your web-application, You need to configure SSL with your web/app server
Glassfish SSL Conf
Tomcat SSL Conf
Jetty SSL Conf
JBoss SSL Conf
It depends on what J2EE(Web Container) you are using,
But there should be no developer changes required.
For tomcat you can click here.
The other answers are correct, but I want to add just one tip: sometimes a website serves some pages as http and others as https, usually in the mistaken belief that this will somehow improve performance since https is supposedly harder on the server, best to serve as much un-encrypted http as possible.
Don't do this! It's such a waste of developer effort since you now have to plan all your http -> https transitions, and perhaps even your https -> http transitions. You risk introducing security holes with the transitions (oops, anyone with session cookie can make the transition!). I recommend just doing all 100% https in this scenario. Crypto will never be a significant performance bottleneck, since it's perfectly scalable (more servers, more processors, more threads, etc, always help crypto, you won't be so lucky with the database!).
To enable HTTPS on sever and to make specific application accessible only through secured mode i.e https please do following
Create KeyStores and Add Certificates to the key store [ Links can be found from above answer :) ]
Add the following to your web.xml
Restricted URLs
/appname/*
CONFIDENTIAL
you can add various patterns like /appname/login*,/appname/service* etc..
I currently have a java applet sitting on my Apache server (in the htdocs directory). The applet is a web crawler and takes a very long time to process before delivering results (I guess applets get very limited resources).
I would like to push the crawling work onto the server but I don't have any idea how to do this. I know that I can make a Servlet maybe using Tomcat or something like that but I don't know what would be involved.
Do I need to install Tomcat (or is this part of Apache)?
Is this something that can be done in several hours (the first time)? Or will this take me some time to do?
Currently my applet is at http://mySite.ca:4005/crawler/. I only have access to port 4005 (other users get the other ports). Would Tomcat play nice Apache? Can I direct requests to http://mySite.ca:4005/crawler/ to tomcat and allow Apache to handle the rest of the requests (ie: requests to http://mySite.ca:4005/otherPage/)?
I don't really care about the applet/GUI code that I have written, my main objective is to get the webcrawler running with some arguments (input from user) and then display the results (output to user).
Do I need to install Tomcat (or is this part of Apache)?
Tomcat is not part of Apache HTTPD, you need to install it separately.
Check Tomcat homepage for details.
Note that you could also use other servers to run servlets, e.g. Jetty
Is this something that can be done in several hours (the first time)? Or will this take me some time to do?
This depends on your familiarity with computers and your particular operating system. I would do it in couple of minutes. :-P
Currently my applet is at http://mySite.ca:4005/crawler/. I only have access to port 4005 (other users get the other ports). Would Tomcat play nice Apache?
In general, Tomcat has been designed to be integrated with Apache HTTPD, see the documentation about connectors and connectors website for details.
I'm not sure about assigning different ports to different users, I do not think this is the proper way to do this. What exactly are you trying to achieve here?
Can I direct requests to http://mySite.ca:4005/crawler/ to tomcat and allow Apache to handle the rest of the requests (ie: requests to http://mySite.ca:4005/otherPage/)?
Yes you can. Check the Connectors guide and Apache HTTPD Location directive for details.
I would advise you to use plain HTTP to communicate between your applet and servlet.