Deploy Application Binaries (*.war) to OpenShift

RedHat OpenShift is a PaaS that provides a cloud hosting for your applications.

I'd like to share a practice that I use to deploy my Java application to OpenShift.

I only have experience with Tomcat 7 (JBoss EWS 2.0) cartridge and non-scalable applications, so I will talk about them. However this may be applied to other environments.

I use GitHub to store my application codebase, and I also use Gradle as a build tool.

If you use Maven for your builds and you have all your dependencies in public Maven repositories or these repositories that are accessible from OpenShift, then this blog post is likely not for you.

As of today OpenShift does not support Gradle as a build tool, and I have some of my dependencies in my private/local repositories that are not available from OpenShift, this is why I build my application locally and only deploy binaries to OpenShift.

When you create OpenShift application there is a Git repository that you may use to deploy your code. You can also use this Git as your primary source storage (or you can synchronize with your GitHub repo), but I don't do this.

This Git repo has specific directory structure and OpenShift auto-deployment rely on this structure, this is one of the reasons I don't use this Git repo as my primary code base -- I use multiple deployment targets for my project and OpenShift is only one of them.

The directory structure contains /webapps folder where you can put your *.war file and OpenShift will deploy it when you Git push.

If you do this, however, you will find soon that your Git repository will eat all your server-side disk quota (which is only 1GB for free). This is because remote Git repository will hold all revisions of your  binaries. My *.war file size is near 50MB -- this is typical for most small-to-medium Java applications. So after you do 20 deployments -- you will be out of free space.

Usually you don't need all these revisions of your binaries, so to fix this situation you first should delete your remote Git history and adopt some other practice for deployments.

Here is how I do this.

Delete old revisions of your binaries from your remote OpenShift Git repo

1. First you need to do a git clone or a git pull to fetch recent version of your remote repo. Lets name the folder you've cloned to as OLD_REPO. You will need this to restore your git hooks that are in the .openshift subfolder, and maybe some other configs except your binaries (see step 8 below). 
2. SSH connect to your OpenShift instance.
3. cd ~/git/.git/objects
4. rm -rf *
5. cd ..
6. rm refs/heads/master
7. Do a fresh git clone from remote OpenShift Git. It will tell you that you've cloned empty repository -- this is correct, your remote repository now clean. Lets name your new clone folder as NEW_REPO.
8. Copy contents of OLD_REPO to the NEW_REPO. You should copy all except .git folder, because NEW_REPO will already contain itself .git folder.
9. Delete NEW_REPO/webapps/*.war -- these are your previous binaries:
   git rm webapps/*.war

At this stage you will have empty remote Git repository and local clone with latest revision of what you've had in remote before deleting it except your binaries.

Way to deploy new binaries

To deploy new binaries you have to copy them manually to OpenShift. I do this using SCP command.

I created a shell-script upload-war.sh with the following content:

scp $PROJECT_X_WORKSPACE_DIR/project-x/project-x-web/build/libs/*.war $PROJECT_X_OPENSHIFT_ADDRESS:~/app-root/data/webapps/ROOT.war

As you see I use environment variables to tell the script where my local binary is located and where should I place them in remote OpenShift. PROJECT_X_OPENSHIFT_ADDRESS is the username@address you use when connect to OpenShift by SSH.

My project has only one target *.war artifact and I copy it to remote data folder under the ROOT.war name. In OpenShift the data folder is the place where you store your custom files.

After I copied the file I have to tell OpenShift to deploy it.

To do this I modify build action hook which is located here: NEW_REPO/.openshift/action_hooks/build to make it look like this:

#!/bin/bash

# This is a simple build script and will be executed on your CI system if

# available.  Otherwise it will execute while your application is stopped

# before the deploy step.  This script gets executed directly, so it

# could be python, php, ruby, etc.

cp $OPENSHIFT_DATA_DIR/webapps/* $OPENSHIFT_REPO_DIR/webapps/

Here $OPENSHIFT_DATA_DIR and $OPENSHIFT_REPO_DIR are OpenShift built-in environment variables.

Add this script to version control, commit and push to OpenShift remote.

When you commit this hook will copy the binary you copied earlier and deploy it. So next time when you will release new version, just run upload-war.sh and do some dummy commit/push to the OpenShift remote and thats it.

Running BIRT Reports in Tomcat

Context: You have database and you need to do data analysis: draw charts, build some tables, calculate totals, etc. You want it all to be available over the web and secured with a password.

Your database is any JDBC-supported database (I use MySQL 5.1.49).

Your server is running any OS where Java can run (I use Ubuntu Linux 10.10 available through SSH).

I will show how to implement this using Eclipse BIRT 3.7.

Developer Environment

1. Download "Eclipse IDE for Java and Report Developers" package here.
   Unzip to install.
2. Design new report (I created sales.rptdesign). This is really straightforward.

JDBC Driver. You will need MySQL JDBC driver to create Data Source for report. I got mysql-connector-java-5.1.17-bin.jar here.

Installing the driver in BIRT designer is easy using "Manage drivers..." dialog. But you will probably have problems deploying it to the runtime.

Fonts. You probably won't have any problems with fonts in BIRT designer. And again you will likely have problems with fonts in runtime.

Connection Profile Store. With BIRT 3.7 you can use Connection Profiles to hold database connections. After you've finished designing and testing your report, double click report Data Source to bring properties dialog and create new connection profile store in there. Save it to some file (I saved to planet33_v2.xml).
Here's what I have in there:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<DataTools.ServerProfiles version="1.0">
    <profile autoconnect="No" desc=""
        id="ecc3bc60-d4fd-11e0-957a-e0e31b9a34ee" name="planet33_v2"
        providerID="org.eclipse.datatools.enablement.mysql.connectionProfile">
        <baseproperties>
            <property
                name="org.eclipse.datatools.connectivity.db.connectionProperties"
                value="" />
            <property name="org.eclipse.datatools.connectivity.db.savePWD"
                value="true" />
            <property name="org.eclipse.datatools.connectivity.drivers.defnType"
                value="org.eclipse.datatools.enablement.mysql.5_1.driverTemplate" />
            <property name="jarList"
                value="/usr/local/share/mysql-connector-java-5.1.17-bin.jar" />
            <property name="org.eclipse.datatools.connectivity.db.username"
                value="your_username" />
            <property name="org.eclipse.datatools.connectivity.db.driverClass"
                value="com.mysql.jdbc.Driver" />
            <property name="org.eclipse.datatools.connectivity.db.databaseName"
                value="planet33_v2" />
            <property name="org.eclipse.datatools.connectivity.db.password"
                value="your_password" />
            <property name="org.eclipse.datatools.connectivity.db.version"
                value="5.1" />
            <property name="org.eclipse.datatools.connectivity.db.URL"
                value="jdbc:mysql://127.0.0.1:3306/planet33_v2" />
            <property name="org.eclipse.datatools.connectivity.db.vendor"
                value="MySql" />
        </baseproperties>
        <org.eclipse.datatools.connectivity.versionInfo>
            <property name="server.version" value="5.1.49" />
            <property name="technology.name.jdbc" value="JDBC" />
            <property name="server.name" value="MySQL" />
            <property name="technology.version.jdbc" value="4.0.0" />
        </org.eclipse.datatools.connectivity.versionInfo>
        <driverreference>
            <property name="driverName" value="MySQL JDBC Driver" />
            <property name="driverTypeID"
                value="org.eclipse.datatools.enablement.mysql.5_1.driverTemplate" />
        </driverreference>
    </profile>
</DataTools.ServerProfiles>

Note: I bet you can use JDNI data sources here (and I suppose this is even preferable because of connection pooling, etc.). Please, drop a few lines in comments below with instructions how you do this.

You can now edit XML source of you report and replace /report/data-sources with something like this:

<data-sources>
    <oda-data-source extensionID="org.eclipse.birt.report.data.oda.jdbc.dbprofile"
        name="Planet33 V2 Data Source" id="359">
        <property name="OdaConnProfileName">planet33_v2</property>
        <property name="OdaConnProfileStorePath">../conf/planet33_v2.xml</property>
    </oda-data-source>
</data-sources>

Several things to mention here:

• planet33_v2.xml (Connection Profile Store)
• Check all properties and change them according to your connection.
• Note the jarList property, there you should specify path(s) to where your JDBC drivers located (I copied driver that I've downloaded to /usr/local/share/mysql-connector-java-5.1.17-bin.jar).
• When you create connection profile store file from designer it places property with name="org.eclipse.datatools.connectivity.driverDefinitionID". You should remove this property because of this issue.
• sales.rptdesign (The Report)
• You should keep value of ida-data-source@id attribute the same that was in your design.
• Value of OdaConnProfileName should match value of DataTools.ServerProfiles/profile@name attribute from planet33_v2.xml.
• Note that OdaConnProfileStorePath is relative path (see below). But you can keep it absolute if you want. 

Server Environment

(Note: I recommend to configure Tomcat instance on your developer machine first to make it easier to verify report settings, and then transfer the entire $CATALINA_HOME to production server. Of course, you can do all these steps on production server directly.)

1. Download Apache Tomcat (any Java application server should be fine).
   Unzip to some folder (I used /usr/local/share/apache-tomcat-5.5.33/) -- this will be $CATALINA_HOME.
2. Download BIRT "Runtime" package here.
   Copy birt.war (BIRT Web Viewer application) to $CATALINA_HOME/webapps.
3. Edit $CATALINA_HOME/catalina.sh and paste these lines somewhere after JAVA_OPTS variable initialized (this prepares workspace for DTP plugin):
   

   java_io_tmpdir=$CATALINA_HOME/temp
   org_eclipse_datatools_workspacepath=$java_io_tmpdir/workspace_dtp
   mkdir -p $org_eclipse_datatools_workspacepath
   
   JAVA_OPTS="$JAVA_OPTS -Dorg.eclipse.datatools_workspacepath=$org_eclipse_datatools_workspacepath"
   
   

4. Start Tomcat by running $CATALINA_HOME/startup.sh. After this BIRT Report Viewer application should be available by http://localhost:8080/birt. Also birt.war should be now extracted to $CATALINA_HOME/webapps/birt -- this will be $BIRT_HOME. You can now delete $CATALINA_HOME/webapps/birt.war.
5. Copy planet33_v2.xml to $CATALINA_HOME/conf as (remember OdaConnProfileStorePath property in sales.rptdesign file?).
6. Copy your sales.rtpdesign file to $BIRT_HOME.

At this point you should be able to execute the report by simply following the address http://localhost:8080/birt/frameset?__report=sales.rptdesign&__dpi=600.

Note the __dpi URL parameter -- it controls DPI of chart images rendered in HTML/PDF. You will probably want to modify like this it to increase image quality. Also note that if you set chart output format to SVG you will get vector graphics quality in PDF output.

Security

There are obvious reasons why you may want to keep your reports secure.

Besides that keep in mind that in BIRT Web Viewer application all reports sources (*.rptdesign files) available to user by request. Try navigating to http://localhost:8080/birt/sales.rptdesign and you'll see what I mean. I think this is a good reason, why you should use connection profile store (or at least JNDI data sources), because that files not available through HTTP.

Implementing simple (HTTP BASIC AUTH) security with Tomcat is pretty simple.

First, modify $BIRT_HOME/WEB-INF/web.xml, by adding this (you can change role names as you want):

<!-- Define a security constraint on this application -->
<security-constraint>
  <web-resource-collection>
    <web-resource-name>Entire Application</web-resource-name>
    <url-pattern>/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <!-- This role is not in the default user directory -->
    <role-name>manager</role-name>
  </auth-constraint>
</security-constraint>             
<!-- Define the login configuration for this application -->
<login-config>
  <auth-method>BASIC</auth-method>
  <realm-name>BIRT Report Viewer</realm-name>
</login-config>
<!-- Security roles referenced by this web application -->
<security-role>
  <description>
    The role that is required to log in to the BIRT Report Viewer
  </description>
  <role-name>manager</role-name>
</security-role>

You may also do the same for $CATALINA_HOME/conf/web.xml to secure all applications in this Tomcat instance.
Second, you should edit $CATALINA_HOME/conf/tomcat-users.xml to define user login and password.

Thats all, you're secured :) This is should be fine for most cases, but I would recommend you to read about HTTPS if your data is extremely secure.

Deploy to server

1. Copy Tomcat to the server:
   Tip: Use scp command in terminal to transfer files from your machine to the server over SSH:
   scp /usr/local/share/apache-tomcat-5.5.33 dmitrygusev@planet33.ru:/usr/local/share/
2. Copy JDBC Driver to the server:
• Copy this driver to the same path as specified in the jarList property from planet33_v2.xml file.
• DO NOT COPY this driver to $BIRT_HOME/WEB-INF/lib, because it may lead to ClassNotFoundException.

Fix file permissions. When you copy files over scp you may need to chmod them to grant read/execute access. This should fix it:

chmod a+r /usr/local/share/mysql-connector-java-5.1.17-bin.jar
chmod -R a+r /usr/local/share/apache-tomcat-5.5.33/
chmod a+x /usr/local/share/apache-tomcat-5.5.33/bin/*.sh

Now you should be able to start tomcat and run reports on the server.

Fonts. BIRT PDF output doesn't work good for Russian fonts out-of-the-box, because of licensing issues with fonts. One simple solution to fix this is:

1. Get the *.ttf font files you need (you can copy them from any Windows installation, look in c:\Windows\Fonts). These 8 files should be enough in most cases (these are "Arial" and "Times New Roman" fonts):
   
   arialbd.ttf  arialbi.ttf  ariali.ttf  arial.ttf
   timesbd.ttf  timesbi.ttf  timesi.ttf  times.ttf
2. Copy these files to /usr/share/fonts/truetype (or any other place that is referenced from fontsConfig.xml).
3. Don't forget to fix file permissions:
   chmod a+r /usr/share/fonts/truetype/*.ttf
4. Reference the fonts from *.rptdesign (or configure font-aliases):
   /report/styles

   <style name="report" id="4">
       <property name="fontFamily">"Arial"</property>
       <property name="fontSize">9pt</property>
   </style>
   

5. Restart Tomcat:
• $CATALINA_HOME/bin/shutdown.sh
• $CATALINA_HOME/bin/startup.sh

Russian Localization. I used this method to do it. Although you may want to try BIRT Language Packs.

Troubleshooting.

• Neither the JAVA_HOME nor the JRE_HOME environment variable is defined
  At least one of these environment variable is needed to run this program
  
  You should define JAVA_HOME variable. Execute this command before running Tomcat's *.sh files in terminal:
  
  export JAVA_HOME=/usr/bin/java

• If you get OutOfMemoryError you may want to give JVM more memory. Edit $CATALINA_HOME/bin/catalina.sh to include this (see this thread on stackoverflow, and read more about JVM memory settings):
  
  JAVA_OPTS="$JAVA_OPTS -Xms512m -Xmx512m -XX:MaxPermSize=256m"

• If you got OutOfMemoryError you most likely couldn't restart Tomcat using $CATALINA_HOME/bin/shutdown.sh script.
  
  To kill Tomcat instance use htop command in terminal. In htop interface select Tomcat process (this is /usr/lib/java), press 'k', select 9 SIGKILL in "Send signal" area, and press Enter. To exit htop press 'q'.
• Executing report never stops. Tomcat process consumes all CPU resources.
  
  I've seen this situation when used charts in report and they were on page break. I fixed this by moving charts to other place (far from page break). Changing page size to avoid page breaks also fixes this issue.

Пример Java-приложения, построенного на Open Source решениях

Не смог придумать лучшего названия :)

Эту презентацию я готовил для девятой встречи JUG во Владимире, которая состоялась 25 декабря 2008. Запись презентации будет доступна чуть позже на сайте JUG, а пока я решил выложить слайды.

Рассматриваемое приложение - один из заказных проектов KeyIntegrity. Его особенность в том, что он полностью реализован на Java OpenSource-решениях. Вот лишь некоторые из них:

• Apache Tapestry5
• Apache Maven2
• Apache Tomcat
  
• Eclipse BIRT
• JPA/Oracle Toplink
  

В презентации дается обзор архитектуры готового решения и разбирается дизайн проекта. В частности: общий дизайн web-приложения, подсистема доступа к данным, генератор отчетов и так далее. Кстати, предыдущий пост "Single Sign-On в интеграционных проектах IIS и Java" также относится к этому проекту.

В презентации также приводится несколько метрик проекта: сроки, количество занятых в разработке людей, метрики по коду и так далее.

Я бы отнес этот проект к категории "маленьких", но, несмотря на его размер, он оказался очень интересным в плане реализации.

Как обычно не обошлось без тонкостей использования OpenSource-решений в production. Например:

• реализации JPA могут работать не стабильно если используется pool соединений (то есть почти всегда) и с приложением не работают более 8 часов (настройки MySQL по умолчанию), например, ночью когда нет активных пользователей;
• использование AJP13 в Tomcat с настройками по-умолчанию через некоторое время приводит к отказу работы системы;
• и другие.
  

Самое интересное, что в открытых источниках я не нашел решений этих проблем. Часть ответов я привожу в презентации (в слайдах или в записи). Но, к сожалению, большинство, все-таки, остается за кадром.

Часть вопросов по доступу к данным закрылось библиотекой keyintegrity-orm-jpa (небольшая обертка для JPA), которую пришлось написать для этого проекта. О ней также есть информация в слайдах. Скорее всего удастся выпустить эту библиотечку под Apache License v2, но это уже только в следующем году (обязательно напишу про это отдельную новость).

В общем я очень доволен как себя показала Tapestry5 с её встроенной поддержкой IoC. Всем рекомендую посмотреть этот Web Framework, тем более, что недавно вышел финальный релиз.

Также остались только хорошие впечатления от BIRT - в очередной раз удалось реализовать все, что нужно, включая русскую локализацию для Web Viewer'а.

• Презентация (572 КБ)
  

Single Sign-On в интеграционных проектах IIS и Java

Описание проблемы

Для одного из наших проектов нужно было разработать несколько новых компонентов для существующего решения - web-портала.

Портал написан на ASP (даже не ASP.NET) с MS SQL Server 2000 и до сих пор поддерживается - периодически выходят новые версии.

Одним из требований заказчика была поддержка функции Single Sign-On между существующими и разрабатываемыми компонентами.

В этом посте я хочу рассказать о тем чем я руководствовался при разработке архитектуры решения и как в итоге был реализован механизм SSO. Забегая вперед, отмечу, что данное решение может подойти для интеграционных проектов, в которых есть необходимость организовать SSO между существующими web-приложениями (ASP/PHP) и вновь разрабатываемыми на Java EE компонентами.

Выбор инструмента

Платформа

Из соображений лицензионной чистоты и снижения лицензионных отчислений было принято решение разрабатывать новые компоненты с использованием стека Open Source решений и, в частности, на платформе Java. Если кому-то интересно почему Java - обращайтесь в комментарии - это не тема для данного поста :)

В последнее время мне очень нравится Open Source линейка OpenX, поддерживаемая открытым сообществом dev.java.net во главе с Sun Microsystems. Особенно привлекает NetBeans, который является по-настоящему мощной и, поправьте если я не прав, первой в мире и единственной бесплатной Open Source RAD для разработки Java-приложений (включая Java ME/SE/EE), чем не может похвастаться ни одна другая IDE (включая Eclipse и IDEA).

Eclipse, как IDE, мне нравится больше NetBeans, особенно JDT и его Java Editor, который в разы превосходит NetBeans по функциональности. Но Eclipse очень сильно проигрывает NetBeans в плане RAD. Многие знают, что на базе Eclipse есть разные реализации RAD (от IBM, ориентированная на линейку WebSphere; от SAP для NetWeaver), но все они платные и, поэтому, не идут ни в какое сравнение с NetBeans.

Что мне особенно нравится у NetBeans - это набор его WYSIWYG-редакторов GUI и различные мастера конфигураций, которые очень сильно сокращают время разработки. Именно этим мы и хотели воспользоваться.

Single Sign-On

На тот момент я был знаком лишь с одним фреймворком, поддерживающим SSO - это JOSSO.

JOSSO позволяет организовать SSO между веб-приложениями, физически расположенными в рамках одного сервера приложений. После того, как пользователь прошел аутентификацию в одном из "партнерских" приложений JOSSO, серверный агент JOSSO запоминает его логин и членство в ролях. При последующих обращениях пользователя к партнерским приложениям, агент автоматически пытается аутентифицировать пользователя, избавляя его от повторного ввода пароля. Эта схема работает на Tomcat. Существуют агенты и для других серверов приложений.

Но именно из-за того, что JOSSO не поддерживает Glassfish, я побоялся остановить на нем свой выбор - Glassfish еще слишком молодой и не имеет большой поддержки со стороны Open Source сообщества.

В линейке OpenX есть продукт Open SSO, поддерживающий Glassfish, но реализованного агента для IIS у этого продукта не было.

У JOSSO есть агент для IIS, но, как потом выяснилось, и JOSSO, в дополнение к вышесказанному, и Open SSO под Single Sign-On понимают немного другую схему аутентификации - схему основанную на токенах.

В этой схеме приложение, проводя процедуру аутентификации пользователя, получает у Identity Provider'а токен - сессионный ключ. Этот ключ может передаваться между партнерскими приложениями, например, через Cookies. В такой схеме, имея сессионный токен пользователя, приложение самостоятельно может запросить у централизованного сервиса права пользователя и провести процедуру авторизации.

В нашем случае это означало бы полностью переписать функции аутентификации и авторизации портала по новой схеме, что было бы крайне нежелательно, так как требовало бы больших усилий при разработке и применении новых обновлений портала. Кроме того ASP и MS SQL Server 2000 - это устаревшие технологии и никаких новых стратегических компетенций мы бы не получили с этого проекта.

Исходя из всего вышесказанного было принято решение в качестве сервера приложений выбрать Apache Tomcat - наиболее распространенный и широко поддерживаемый открытым сообществом Open Source сервер приложений (я знаю, что там только web-контейнер, нам больше не надо :). Решение было принято из расчета на то, что если и можно сделать SSO на Java, то на Tomcat это решение заработало бы с вероятностью 99.999%.

Описание решения

В основе найденного решения лежит The Apache Tomcat Connector - "мостик", который используется для запуска Tomcat за web-серверами, такими как Apache HTTPD и Microsoft IIS.

В этой схеме весь HTTP-трафик пользователя проходит через web-сервер (в нашем случае IIS) и передается Tomcat'у, который обрабатывает запрос и возвращает результат.

Это возможно за счет ISAPI-фильтра, который отвечает за перенаправление всех HTTP-запросов. Такое перенаправление возможно за счет поддержки Tomcat'ом бинарного протокола AJP13, по которому происходит эта передача. Возможно другие сервера также поддерживают AJP13 и для них можно организовать аналогичную схему - я не пробовал, но если у кого-то получится, большая просьба отметиться в комментариях.

Особенности решения

Аутентификация пользователей в портале ASP осуществляется путем сохранения информации об имени пользователя и его членства в ролях, которая сохраняется в объекте ASP Session (сессия приложения).

Если бы аутентификация осуществлялась стандартными средствами, например, HTTP Basic Authentication, то в Java EE приложении имя пользователя можно было бы получить через интерфейс HttpServletRequest.getRemoteUser(...).

Но так как сессия лежит за границами протокола HTTP, из Java непосредственно нельзя получить к ней доступ. Однако в HTTP-заголовках передаются Cookies, в которых сохраняются сессионные ключи приложений (JSESSIONID, PHPSESSIONID, ASPSESSIONIDxxx).

Благодаря этому мы можем обратиться к приложению по протоколу HTTP, передав сессионный ключ и попасть в контекст нужной сессии, где нам будет доступна вся необходимая информация.

Реализация

Для этого в партнерское приложение достаточно добавить страницу sessioninfo.asp следующего содержания:

UserID=<%=Session("UserID")%>
UserType=<%=Session("UserType")%>

Соответственно, из Java приложения, чтобы получить информацию о пользователе (в данном случае это его идентификатор и тип, на основании которых можно сделать запрос к БД и получить всю дополнительную информацию, если это необходимо), достаточно обратиться по адресу, например, http://localhost/asp-portal/sessioninfo.asp и рас-parse-ить результат:

01: <%@ page contentType="text/html; charset=iso-8859-1" language="java" %>
02: <%@ page import="java.net.*"%>
03: <%@ page import="java.io.*"%>
04: <%@ page import="java.util.Properties"%>
05: 
06: <%
07:         Cookie[] cookies = request.getCookies();
08:         
09:         String value = "";
10:         
11:         for (int i = 0; i < cookies.length; i++) {
12:                 Cookie cookie = cookies[i];
13:                 value += cookie.getName() + "=" + cookie.getValue() + ";";
14:         }
15:         
16:         URL url = new URL("http://localhost/asp-portal/sessioninfo.asp");
17:         
18:         URLConnection c = url.openConnection();
19:         
20:         c.setRequestProperty("Cookie", value);
21:         
22:         InputStreamReader in = new InputStreamReader(c.getInputStream());
23: 
24:         Properties p = new Properties();
25:         p.load(in);
26: 
27:         in.close();
28: %>

При таком подходе на каждый запрос к Java-компоненту идет обратный дополнительный запрос к ASP-порталу. Вопрос производительности для нас не был критичным, но в несколько миллисекунд обратный запрос укладывался.

Остается отметить, что чтобы браузер передавал Cookies Java-приложению они должны быть в одном домене (URL) с порталом. Для других проектов это может быть ограничением, но в нашем случае это было скорее требованием.

Источники информации

Инструкцию по настройке Tomcat и IIS можно найти здесь: How To Configure IIS 6.0 and Tomcat with the JK 1.2 Connector. Мне пришлось немного изменить описанный сценарий, моя установка отказалась принимать приведенный там в примере файл workers.properties и я написал свой, руководствуясь вот этой документацией.