2014-10-14 2 views
0

У меня есть богатое интернет-приложение, которое представлено в схеме SaaS (облако) через Интернет. Приложение развертывается через Java Web Start: пользователи нажимают на ссылку, указывающую на файл JNLP, на сайт провайдера (http://somesite.com/myapp/myapp.jnlp); то приложение загружается и локально кэшируется (с панели управления Java клиента я вижу, что приложение составляет около 40 МБ). Я ожидаю, что если никаких изменений на стороне сервера не произойдет, клиенты будут использовать кешированную версию. Возможная проблема может возникнуть при выпуске новой версии сервера: все клиенты (сотни) могут потенциально загрузить новую версию одновременно. Чтобы предотвратить эту проблему, я хотел бы изучить возможность использования веб-прокси в качестве кеша: первый клиент загружает из Интернета новую версию, другие клиенты загружают версию, кэшированную в веб-прокси. Возможно ли это? У меня есть некоторые сомнения в основном из-за того, что с панели управления Java -> Java cache viewer (Java 6 на Win XP) я вижу 1 приложение (40 МБ) в «представлении приложения», некоторые JAR при переключении в «Просмотр ресурсов», но когда я перехожу на место на диске, чтобы физически разместить кеш, я вижу много папок (большинство пустых) и .idx-файлов (без следов JAR). Идея состоит в том, чтобы сообщить веб-прокси (который является Forefront TMG) ​​кэшировать только набор файлов (какие из них?), Исходящие от сайта провайдера. я придаю очищенную версию OFTHE JNLP файла с возможностью кэширования, но я предполагаю, что они не имеют отношения к моему вопросу, так как они только сделка опции кэширования на клиенте (правильно?)Java Web Start и кэширование веб-прокси

<jnlp spec="1.0+" codebase="http://somesite.com/myapp/" href="http://somesite.com/myapp/WebStart.jnlp"> 
    <information> 
    <title>....</title> 
    <vendor>....</vendor> 
    <homepage href="http://somesite.com"/> 
    <description>....</description> 
    <icon href="http://....gif" kind="default"/> 
    <shortcut online="true" install="false"> 
     <desktop/> 
     <menu submenu="...."/> 
    </shortcut> 
    <offline-allowed/> 
    </information> 
    <security> 
    <all-permissions/> 
    </security> 
    <update check="timeout" policy="always"/> 
    <resources> 
    <java initial-heap-size="20971520" max-heap-size="536870912" java-vm-args="-XX:MaxPermSize=128m" href="http://java.sun.com/products/autodl/j2se" version="1.6.0_11+"/> 
    <jar href="http://......jar" download="eager" main="false"/> 
    ... some other JARs... 
    </resources> 
    <application-desc main-class="com.package....."> 
    <argument>-showSavePwd</argument> 
    <argument>-forcedHttpsLoginPort:443</argument> 
    <argument>-availableLanguages:en;fr;de;es;ja</argument> 
    <argument>-forceCountryByLanguage:false</argument> 
    </application-desc> 
</jnlp> 

Благодарность

ответ

0

Я использовал CloudFront для нашего CDN, и он работал хорошо уже почти 2 года (20+ обновлений приложений). Я хотел бы настроить JNLP так:

... 
    <resources> 
    <java initial-heap-size="20971520" max-heap-size="536870912" java-vm-args="-XX:MaxPermSize=128m" href="http://java.sun.com/products/autodl/j2se" version="1.6.0_11+"/> 
    <jar href="http://xyz.cloudfront.net/path/some.jar" download="eager" main="false" version="123"/> 
    ... some other JARs... 
    </resources> 
... 

http://xyz.cloudfront.net/ сконфигурирован с началом указывая на http://somesite.com/.

После этого CloudFront настроен на кеширование строк запроса, что позволяет механизму версии работать. После этой первоначальной конфигурации мне не пришлось ничего делать, чтобы она работала.