Exocortex

In keeping with my adventures with Microsoft technologies, my latest task required me to venture into IIS-territory. Specifically, I had to connect Tomcat with IIS, so that web applications hosted by Tomcat are routed through IIS. On top of that the communication between the browser and IIS needs to be secure. (The communication between IIS and Tomcat happens within the network, so can be insecure.)

This has been done to death by many folks all around the world, so I really have not a lot to add to it. I am going to keep this short and refer primarily to web sites that I found extremely useful. (Thanks to them also, btw.)

First, a simple graphic to show what I am trying to achieve, just in case things are still not entirely clear:

[Image created using this awesome tool by Steve Hanov at this site and then cropped using another awesome tool called Pixlr that is available at the site here.]

As can be seen, the browser needs to connect to IIS through a secure channel. Internally, IIS communicates with Tomcat using the AJP 1.3 protocol. And just to make things interesting there is a firewall sitting on the machine where Tomcat is running.

IIS and Tomcat can be connected together by an ISAPI filter called Tomcat Connector. This is the only Apache-approved way to connect the two. The filter comes in the form of a DLL from Apache. Instructions on how to do this can be obtained from this site. The instructions are pretty good. However, I still have a few comments to add:

1. Make sure that you download the appropriate DLL for your particular machine architecture. If you have a 64-bit machine you need to download the 64-bit version, and that too, for the right architecture (IA64/AMD).
2. In the IIS Admin link above, it is not very clear where to attach the ISAPI filter. It would seem from the text that you need to attach the filter to the ‘Default Web Site’ or the site that will host the jakarta virtual directory. Conceptually, that seems to make sense, but for some reason that did not work out. I added the filter to the ‘Web Sites’ item under IIS. I believe this means that the filter applies to all web sites. It is not a problem for me as, as I will have only one site anyways.
3. Make sure that the directory that contains the ISAPI filter, the properties files and where logs are to be written have the right permissions for the appropriate operations for the IUSR_<machineName> and IWAM_<machineName> users. I gave both those users Read & Execute, List Folder Contents, Read, Write permissions for both those and also propagated the permissions down the directory structure (only for the directory containing the filter components). This probably should be made more robust by figuring out who needs exactly what.
4. The symptoms of the filter not loading properly are:
   • Obviously, things don’t work!
   • The arrow beside the ISAPI filter will be red and pointed downwards (should be green and pointing upwards).
   • The ISAPI filter does not generate any log files in the directory specified.
   • IIS does not generate any log files under C:\WINDOWS\system32\LogFiles\W3SVC1 or wherever the IIS log file directory is set to be.

Tomcat has an in-built AJP Connector that listens on port 8009. In the firewall, make sure there is an exception that allows traffic through port 8009.

To test the above setup replace the usual URL to the web application, http://<machine_name>:8080/<Context>, with
http://<machine_name>/<Context>.

Once this is working, we need to set up SSL for the web site hosted by IIS. The idea is to establish a certificate, signed by a well-known certificate authority like VeriSign or Thawte and turn on the SSL requirement for the web site. The process is fairly simple and is again explained well here. The only thing that I want to point out is that for development purposes, obtaining a properly signed certificate is a lengthy and costly option. One can generate a self-signed certificate and use it for the web site.

There are many ways to create a self-signed certificate and install it for the web site in IIS but Microsoft has a very simple command line utility to do that. This tool (SelfSSL) is part of the IIS Resource Kit. This kit can be downloaded from here.

The download and installation of the Resource Kit is trivial. After the install, you can start SelfSSL by going to Start -> All Programs -> IIS Resource Kit -> Self SSL.

The command line utility has a very good help that shows up immediately when you start the program. I used the following command:

prompt> selfssl /V:365

to issue a security certificate (valid for 365 days) for the site number 1 hosted by IIS. I think the main thing to remember is the site number. In my case, I have only one site hosted by IIS, so leaving the default for option /S worked out.

This installed the certificate for my web site (that is the front to my main web app hosted by Tomcat). Going back to the IIS properties for that site (under the Directory Security tab), I now see that all buttons of the Secure Communications section are active. You can view the certificate. To turn on the requirement for secure communication with the web site click the Edit button and select the options Require Secure Channel (SSL) and Require 128-bit Encryption.

Now your web site will only respond to https:// requests and throw an exception for http:// requests. (You do not have to restart IIS after this change.)

Powered by ScribeFire.

This is probably something very obvious to those who prefer living on the wild side (i.e .NET and the whole MS way of doing things) but this came as a little bit of a surprise to me. Shouldn’t have been surprised given the folklore and mythology surrounding development in the MS world….

Anyway, recently I downloaded some code (which came with source also, thankfully) in EXE format (yes I know it is dangerous, but it came from a reputable host (well, that is another story)). The idea was to run it on a different machine. It ran perfectly on my machine but when I tried to run the code on the other machine I got this weird error message:

Retrieving the COM class factory for component with CLSID {60434CA9-132A-11D5-B14F-00C04F79D784} failed due to the following error: 80040154.

The CLSID was different of course. After some digging around I understand that the problem is that the DLL that I had downloaded is meant for 32-bit systems but I am running them on a 64-bit machine. So the OS is unhappy….After some more digging around I found this post on the ASP.NET site. The solution is quite simple: rebuild the executable but this time explicitly tell the VS IDE to build an EXE for an x86 platform. Now take this EXE and run it on a 64-bit machine. Everything works fine. Go figure…..

Powered by ScribeFire.

Of late, I have had the incredible fortune of working with ASP.NET MVC and developing .NET web applications. ASP.NET MVC by itself is actually not too bad. Reminds me of Grails (probably similar to Rails also, but I don’t know much about Rails). While working with anything of this nature and specially with experience in a similar stack in the Java world, there will always be a tendency to draw parallels. For example, Grails is a web application development framework that uses Spring as a container (that is dependency injection based), Hibernate as an ORM tool, Spring MVC (?) as the web framework etc; what are the counterparts in the ASP.NET framework?

I don’t want to make this post a full-blown comparison study yet. Instead, let me take it one piece at a time. Clearly, in any web application database connectivity is a critical part. Nowadays, this is done through some ORM solution. In Grails, it is handled through Hibernate (behind the scenes, GORM is the actual technology that you have to interface with as a developer). In the .NET world there are 2 options (that I know of) to do ORM – NHibernate and Microsoft’s ADO.NET Entity Framework. NHibernate is fairly easy to understand, at least conceptually, as it is similar to Hibernate. However, ADO.NET Entity Framework is somewhat different (of course, coming from the Microsoft camp). Through this post I will try to understand what the differences are.

To get the most obvious out of the way, one can use NHibernate directly. NHibernate is the .NET counterpart of Hibernate. From the looks of it, it seems similar to Hibernate, I haven’t delved into it too much to be able to know the differences. However, this much is clear — the purpose of the tool is the same as that of the Java counterpart and basic concepts are the same. Probably the only thing missing is a counterpart for annotations and hence all mappings are carried out through .hbm.xml files. Not a big deal…(actually there is something called Fluent that solves this problem quite interestingly).

After going through the help topics, this blog and this interview (ACM Queue), it seems that ADO.NET EF is Microsoft’s offering for ORM. The EF consists of an Entity Data Model (EDM), Object Services, Language Integrated Query (LINQ) and a few other miscellaneous stuff. The EDM essentially defines an object model that is created out of the “conceptual” data model rather than the “logical” data model (approach taken by most ORM tools including NHibernate). This has the advantage of separating out “logical” level details from the mappings. The “logical” level bindings are handled by the framework behind the scenes. The Object Services includes data source management, transactions, and other services. LINQ defines an abstract query algebra that can be used to query any collection. This query algebra is then implemented by various languages in the .NET world and even more interestingly have been integrated into those languages as first-class language constructs. LINQ implementations take care of another major issue, that of type matching. SQL types and the language type differences and conversions are all handled transparently by the LINQ implementations.

Hopefully, my understanding of the ADO.NET Entity Framework is correct. It might go through some more edits….

Powered by ScribeFire.