Exocortex

IE and its weirdnesses….

Document modes and compatibility modes:

1. http://blogs.msdn.com/b/ie/archive/2008/08/27/introducing-compatibility-view.aspx
2. http://msdn.microsoft.com/en-us/library/cc288325%28VS.85%29.aspx
3. http://blogs.msdn.com/b/askie/archive/2009/03/23/compatibility-view-button-displays-on-web-pages-with-x-ua-compatible-tag-in-internet-explorer-8.aspx

This one was interesting….

Recall that I am working on a project where I had to set up a web application on Apache Tomcat that users can connect to through IIS (an through a secure channel).

In the application, there is a requirement to open up a URL connection to another secure site (essentially a URL starting with https). I got this weird exception message: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.

As usual, a simple Google search led to an article that talks about this very problem. Turns out that the Java Secure Socket Extension of the Java runtime in which Tomcat runs (and hence the web application) cannot connect to the external secure site as the runtime has not been told that the external site is trusted. The fix for this is to store the certificate from this external site in a place which the runtime can access. So the next time around the URL is being accessed, the runtime will allow it.

Following the instructions in the above article I got to generate a certificate store that then needed to be put in a place where the runtime can see. There was a small hiccup here. I thought that the <JDK_HOME>\jre\lib\security is where the certificate store (a file called jssecacerts) needs to reside. Actually it was <JRE_HOME>\lib\security which obviously makes more sense.

Now the world is back to normal…..

P.S: The link to the Sun Java documentation about security certificate stores and all is broken. Here is the correct link and here is the link to the specific section on customizing certificate stores.

Powered by ScribeFire.

I had written about ESRI’s Java Web ADF a long time back when I first started this blog. In that entry, the description was pretty much a rehash of the material from ESRI’s web site. Since then I have had some more experience with this API and after months and months of procrastination I finally took it upon myself to write it up.

I must add this caveat though: what I will write here is my understanding of the system and not based on the excellent (sarcasm intended) documentation that you generally get from Java Web ADF resource center. So, as is always the case in these situations, feedback is essential (and definitely well appreciated).

Let me start with a graphic:

[As usual this graphic was created using Steve Hanov's online drawing tool and edited using the Pixlr online photo editor.] 

I agree the graphic is not very professional and actually pretty cartoonish but I think it is good enough to give a mental picture of the discussion that follows.

On the right end of the above graphic, we can see the ArcGIS server. Although it might seem from the graphic that the SOC is the only component of the ArcGIS server, it is not entirely true. Another component of the server ecosystem is the SOM. I have simplified the diagram a bit and have not shown the SOM or the physical machine(s) that host those components. These facts are not relevant to this discussion.

The goal of any application that integrates ESRI’s ArcGIS Server is to offload geospatial computation to the server side. (Just to be clear, in this discussion the web application (normally hosted by a web application container like Tomcat) is the “client” that requests geospatial computations to the ArcGIS Server that is the “server”. In this discussion we are not going to talk about the DHTLM-JavaScript-CSS based user interface client that resides on a (human) user’s browser.) These geospatial computations are encapsulated by combinations of various ArcObjects.

Since the web application resides in a different process space than the ArcGIS Server (be it on the same machine or on a different machine as shown in the above graphic) how can we get hold of the ArcObjects? Well, ESRI exposes ArcObjects using Microsoft’s DCOM technology. So if you are familiar with DCOM programming (which I am not, so I am not going to dwell on it too much) then you get hold of the DCOM-based ArcObject proxies and invoke the relevant methods directly.

In my case, my web application is a Java based one. One way to make the Java code to invoke methods on ArcGIS hosted ArcObjects is by the use of SOAP. A method invocation is encapsulated in a SOAP message and then transmitted down the wire to the ArcGIS Server which converts the SOAP message to a call on an ArcObject and finally sends the response back to the caller, again using SOAP. We could easily have used DCOM’s in-built serialization protocol if that is supported in Java.

The ADF is made up of 2 primary packages: com.esri.adf.web.data and com.esri.adf.web.faces. The latter package is focused more on the front-end components that make up the web application and is not really the topic of discussion here. The former package can be thought of as containing all the “domain” objects that make up a geospatial application. These domain objects are quite intelligent in the sense that they are aware of where to get data and computation services from and how to manage their own lifecycles. These “intelligent domain” objects come preprogrammed with servicing the most standard geospatial computations. Essentially, these objects are preprogrammed with all the logic necessary to invoke SOAP requests to the ArcGIS Server and marshall and unmarshall data.

In the typical development scenario, the geospatial part of the web application consists of a combination of one or more objects from the com.esri.adf.web.data package. Classes like WebContext, WebMap, WebToc, WebQuery etc all have preprogrammed logic that knows how to interact with the ArcGIS Server to service standard operations like panning a map, zooming in and out, spatial queries etc.

Sometimes, the typical usage may not be enough. During that time one might want to manipulate the ArcObject proxies directly. These come in the package com.esri.arcgisws. Just to be clear, my guess is that the objects in the com.esri.adf.web.data package use the proxies in the com.esri.arcgisws package.

Hopefully the explanation above will help one understand how all the different packages are weaved together in the ESRI Java Web ADF ecosystem.

Powered by ScribeFire.

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.

These articles summarize it well:

http://www.huffingtonpost.com/2009/11/15/google-street-view-funny_n_357433.html?slidenumber=%2Bq3e80pV2EY%3D
http://www.huffingtonpost.com/2010/02/09/people-in-scuba-gear-chas_n_455787.html