We have a java application deployed in JBoss on one of our client's servers. The application has to issue a web service call to a server completely outside of the network.
Unfortunately, our client's server is not exposed to the outside world and is not able to issue a web service request. The client has IIS running on another server and we thought to route our web service calls through IIS.
We are not a Microsoft shop so know very little about how to do this. We set up a Redirect but unfortunately, as soon as our web service hits IIS it automatically issues a 302 response. That is not what we want, we just want the web service call to pass through the IIS and be forwarded to the server hosting the web services. We then want the response coming back from the server be forwarded through the IIS to the client's application server. Essentially, we want IIS to serve as a pass through proxy.
Is there any way to set something like this up?
Any help will be greatly appreciated.
I think you want to set up IIS as a reverse proxy for your internal server. I had the same question and had better luck looking under reverse proxy information.
We are using IIS 8.5 and required IIS extensions for "Application Request Routing" and "URL Rewriting". Not as scary as it sounds, these are not unusual IIS features to install. The documentation rarely mentions web services specifically, but it seems to work for web services as it does for other web sites.
Good luck!
Application Request Routing would definitely be the way to go provided your running IIS 7 or later. We use it to implement proxies and reverse proxies extensively in our systems, handling both normal http and web service requests (caching of web services is a bit tricky).
A good starting point would be the following article by Ruslan Yakushev: http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing
Related
I have developed a Spring MVC app that can detect Ajax requests sent into my local environment 'localhost:8000/examplePath' with a json body being received as a mapped parameter. So, until here, all is fine.
My question is: Do i still need to deploy my application on a container 'Apache Tomcat/ HTTP Server for example' for my application to be accessible externally on a possible production environment, and if so why?
I want to better understand the necessity of such, if my backend 'Spring MVC app' can already receive and respond to ajax requests
Spring MVC creates a Web application that must be deployed to a Web Application Server to run. The server handles the low level stuff such as raw sockets and the HTTP protocol.
This is because you can't access from internet to your local environment, you need a public adress to access your application from everywhere only if you want to access it over internet otherwise can do it with a local network connection to access it.
If you want any container, you can do it easy with Pivotal. This a container platform for Spring apps.
I want to run a standalone java application on a remote server. It would not be accessible to clients, but would do background calculations and interact with a database and Secure Socket connection to a third party site. It would also interact with a php site.
Do I have to deploy this with JSP, or can I write a standalone application? If so, how would I deploy a standalone java application (jar file) on a remote server? I understand that I must have them install a jvm on the server (not a problem) but then how would I deploy it (if possible). Would I start it with a command line?
I know I have much to learn, but I am not sure how I would access the command line on a remote server. Through the cPanel?
Thanks.
First of all, you'll want to set up some firewall rules to allow access to that server. I'm hoping that you don't expose that server naked to the Internet.
If all you need is database access exposed on the Internet, I don't see why it can't be a secured web app deployed on a servlet/JSP engine and accessed via a web server. You can leverage basic auth for security, JDBC access to the database from the server, and servlets as controllers to accept requests in a nice REST API.
It'll save you the complications of sockets and inventing your own protocol (use HTTP), starting and stopping the application (now it's just a web server/servlet engine), and deployment (send a WAR file).
Does it really must be a 'standalone' application? I think that in your case the best match would be to use Spring container to load your application within some server (tomcat?) and expose services via standard controllers - with Spring you only have to add some annotations on services methods actually.
Then, your php site can interact with these controllers using for example ajax requests.
If your application is written already, you can easily transform it to run within Spring container. It's very non-invasive and promotes usage of POJOs.
We have developed a web service in Java and have published the wsdl. This is done over http. Now we have to provide it over a secure connection i.e. https. The web service application is hosted on webspehere and we have the certificate used in websphere for https.
I am looking for the steps to update the java code and wsdl so that we can publish web service over https.
You should not need to update any Java code or WSDLs. This is all a function of the server configuration. The server is already listening on regular HTTP, presumably on port 80. A listener needs to be added for HTTPS, presumably on port 443 - and mapped to the same web context as your existing application.
Alternatively, this can be done outside of the web server (WebSphere, in your case) by fronting it with something like Apache HTTP Server or a dedicated load balancer that supports SSL/TLS offloading - which can be more efficient.
Since this really isn't a programming question, I'd recommend opening a new question at http://serverfault.com for details on how to configure WebSphere or something related to the configuration I proposed above.
I am working on a web start client in java. I need to connect to other servers than from were the client is downloaded from. I thought I need to sign my jars but this (http://download.oracle.com/javase/tutorial/deployment/deploymentInDepth/signing.html) document describes that:
Accessing services on web sites other than the RIA's own domain – In the past, RIAs could only communicate with the server from which they were launched. The Java Plug-in software and the Java Web Start software now support cross-domain policy files. If a third-party site has set up cross-domain policies and allows access from other domains, your unsigned RIAs can invoke services from this site.
What does this mean and how do I set this up and what are cross-domain policy files?
Thanks.
Here is a blog post describing using crossdomain.xml with Java.
Basically, you need to put a crossdomain.xml file on the server of the web service you want to call, which allows the domain that your app will be launched from.
For my web application, I am thinking about using the Spring framework. Initially, I was thinking of having different actions like create user or login, but now I have to expose some functionality to other applications. Should I create a web service that I call from my application and others do as well, or create an action from Spring and then just have others call the web service? It seems like I should minimize the different ways to call something, but does it make sense to call a web service that is running on the same application server as my main app? Would this be a bad idea from a performance stand point?
Update
I was concerned that Tomcat wouldn't be able to serve both the static or dynamic pages on port 80 (so users could go to www.example.com/welcome.jsp instead of www.example.com:8080/welcome.jsp), as well as a web service but I guess it doesn't matter as both are just served as requests from Tomcat. I'm guessing this means I'll have to change Tomcat to run on port 80 and other applications will have access the web service via this port. Or I could leave Tomcat running on port 8080 and put Apache in front on Tomcat on port 80 and Apache will serve the requests to Tomcat. Is that correct?
I'd put the common business logic in a "business service" and :
call it from an action in your web app
expose it as a web service for other applications
To me, there is nothing bad with this approach and it's pretty easy and clean to implement it with Spring. Actually, I would find ugly to expose this business service as web service only and to call it from the web app (and I'm pretty sure that this will be more complicated to implement on the web app side). You have different "usage contexts", just expose the adequate interface for them.
(EDIT: I'm answering a question of the OP posted as comment below)
You can deploy the web application and the web service in the same WAR (but this is just a deployment choice, you could package the business logic in a JAR and use it in several WARs). Regarding the port, I'm not sure to understand your question. Traditionally, you'll use a web server (e.g. apache) in front of your application server. If you don't, you can always choose to run you app server on port 80. Actually, in both case you are free to use whatever port you want. Using port 80 is just convenient.
Yes, your update is correct.