Some background on the problem that needed to be solved - I have a UDDI registry (java based set of services) on the application server. Test service registry calls to: http://localhost:8080/uddi/inquiry work perfectly fine. In this case the service calls are accessing the registry directly.
The goal is to have the service calls from user community come into IIS and these calls would look something like: http://localhost/uddi/inquiry. In production of course we can substitute the IP for localhost.
Solving the Problem
A lot has been written on the web about solving this problem but everything I read didn't seem to work or was based on a different version of IIS or used another software add-in, such as APE by Helicon. We didn't want to add another piece of software into the mix.
This is how I solved this problem:
First, download and install ARR from Microsoft -- http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ed922306-0d35-4764-8c2c-a378b54e90e1.
Application Request Routing (ARR) is a IIS module from MS that forwards HTTP requests to application servers. After ARR installs successfully you will notice a number of new features in your IIS management console. For the problem at hand, the Server Farms functionality is a key component to the solution.
The second step is to create a new server farm - right click on server farms and select Create Server Farm:


In this example my server farm is all on one physical server -- Systinet and IIS are on the same server. As you set up the new server farm you will be asked a series of questions. In the second panel of the Server Farm set up wizard - enter server address (in this example localhost) then press the add button. After the new server is added, select the advanced settings link. Then open the application request routing link and change the port to 8080. Then press finish. See screen shot below.

The third step in the process - you have to set up routing rules for the new server farm. In the IIS management console select the new server farm you just created and double click on the Routing Rules (note you have to be in Feature View to see these options):

When you get into the Routing Rules area be sure to select the option that reads Use URL Rewrite to inspect incoming requests and assuming you are not using SSL deselect the option that reads Enable SSL offloading. You may accept all other defaults on this page.
Save the Routing Rules by selecting Apply in the Action pane on the right.
For the last step in the process select URL Rewrite in the Action pane on the right. The URL Rewrite screen should look something like the screen shot below. Be sure that your Action Type is Route to Server Farm and the pattern match is set up correctly.

From the URL Rewrite screen select Add Rules option and add a Blank rule. The Edit Inbound Rule screen will then be displayed. Set up the inbound rule to look like the screen below:

Apply the changes and you are done!
I verified my work by creating a VB.Net test application that makes UDDI calls to the registry. If I connect to the registry with the following connection string - Dim myConn As New Microsoft.Uddi.UddiConnection("http://localhost:8080/uddi/inquiry") the application is accessing Systinet directly and it works fine but does not use IIS.
However, if I use this connection string (notice the absence of port number in connection) -
Dim myConn As New Microsoft.Uddi.UddiConnection("http://localhost/uddi/inquiry") I am accessing the registry via IIS and the request is successfully routed to Systinet on port 8080 via the Server Farm and URL Rewrite Rules that were established above.
I hope this helps....
-npv
Below is an update to this blog entry -- setting up SSL in an IIS server farm - 02-10-2010
The steps that I took to use SSL to protect my web service -- Systinent UDDI -- are defined below.
First, you will need to create your CSR (certificate Signing Request) in IIS. The steps for requesting and installing the certificate are straight forward and well documented. One item of caution however, make sure the certificate name which will translate to "issue to" in IIS, matches the site you are calling. For example; in my test environment I intend to call: https://nick-dell/uddi/inquiry therefore the name of the cert should be nick-dell.
After you have requested and installed the certificate (this is installed at the root level in IIS), your next step is to be sure that the company that has issued your certificate has their root certificate installed in your trusted root store. This will complete the chain of trust between your certificate and the issuing authority. The company that issues the certificate will have instructions on doing this. In general, the company issuing the certificate will give you a link to their root certificate. You will install the cert on your IIS machine. Be sure you install it into the trusted root store.
At this point your certs are installed and the trust chain is established. The next steps will configure IIS and the server farm to use the certificate you just installed. The first step in this process is to bind your certificate to the web site. In my case, this was not intuitive in that I did not have a web site per se, I was calling a web service on another server -- in this case the certificate has to be bound to IIS's default web site. Right click on the default web site and select edit bindings; see screen print below:
The next screen will allow you to bind your certificate to to the https port - 443. Screen shot below:
At this point in the process the SSL certificate is bound to your IIS site. Again, the cert is bound to the default web site not to the server farm.
We are almost done configuring the web site. The next steps involve changes to the web server farm that we set up in the beginning of this post. In the current version of IIS there is no way to edit the properties of a server in the server farm so you have to delete the server and re-add with the new properties.
If you have been following this post from the beginning; your next step will be to remove the server from the IIS farm. If you are installing from scratch then obviously there will be no server to remove. See delete of server screen shot on left:When the server is removed a new server must be re-added with the appropriate Application Request Routing rules established. See Screen shot below:
My web service was listening on 8080 and 8443 so the server in the farm is put on the same ports. The calls into IIS will come in on the standard 80 and 443.
The last item you should check is the routing rules that we created earlier in the process. Select your server farm and then select routing rules. Make sure that the check box for SSL off loading remains unchecked. In addition, the if you have established URL rewrite rules as I deomstrated above; the "Scheme" for the rule should remain as http not https.
The final item I will mention is the requirement to support SSL and non-SSL traffic. IIS makes this very easy option to set. Select SSL settings for the the default web site. You will then see a check box that if selected will require the use of SSL. If you want to support both SSL and non-SSL calls to the site then leave this unchecked.
Your IIS proxy should now work with X.509 certificates.
As always I hope this helps ...
-npv




