Здравствуйте! 
Создаем мы своими силами свой велосипед под название КИС. Она решает задачи связанные с торговлей и мелкосерийным производством... В принципе - получается,  и уже эксплуатируются некоторые подсистемы... Проблема в дистрибуции программы клиентам. Их у нас только в офисе штук 250 и еще в удаленных городах(деревнях) где про широкополосной интернет еще не слышали. Там крепостное право только вчера отменили  Есть диал-ап который через пень-колода работает. Поэтому WebStart нам не подходит. Сейчас проект весит около 9 метров и пока он прокачается уходит много времени. Люди нервничают. А по рабочим метам не набегаешся. Поэтому решили пойти таким путем... Мы прямо в базе данных организовали таблицу куда записываем скомпилированные классы с их атрибутами,путями и контрольной суммой. У клиентов есть только маленький загрузчик который сверяет версии классов по CRC32 и в случае необходимости подгружает новые или заменяет устаревшие классы. Базы реплицируются в ночное время... Вроде работает  

maxlab
Классы то запаковываются чем-нибудь (думаю что да, но как-то не упомянуто.. а с учетом описанной проблемы это странно...) ?

WebStart  также проверяет версии jar'ов и подгружает только обновленные. Клиентское приложение можно оформить в виде набора jar'ов ( main и набор компонентов ).  Чем мельче jar'ы, тем меньше избыточных пересылок при обновлениях. 

Это сообщение отредактировал(а) COVD - 7.5.2008, 19:18

Слышал про какой-то pack200 или что-то такое, специально заточен под компрессию class-файлов, типа до 10 раз сжимает. Не используете?

kkorsakoff
Пишут, что жмет на 60% сильнее gzip. За счет модификации байт-кода.

Берёте какую-нибудь систему установки вроде wise, ставите через web-start приложение, оно (система установки) это дело записывает. Делаете установщик и на компакт его. А потом с помощью webstart будут обновляться отдельные (небольшие, думаю) архивы.

Пока ничем не пакуются классы... смысла нет. Потому что, загрузчик приложения никак с сетью не взаимодействует. Он тянет классы из таблицы на локально установленном PostgreSQL. А вот репликация баз - это уже другая тема . Т.е приложение распространяется так... Я готовлю проект в нетбинсе, специальной тулзой обрабатываем папку build и заливаем ее в таблицу сервера головного офиса. Ночью все базы реплицируются и удаленные клиенты имеют свежую копию уже в своем урюпинске... мухосранске и т.д...  

ночь в Крыжополе - это день в Мухосранске, если в мировом масштабе.

Ну... эта... до мега-транс-меж-континентально-интернациональной корпорации мы пока не дотягиваем, мягко говоря.... Часовой пояс один  

день добрый, а не лучше ли писать 3-х звенное EE приложение с тонким клиентом, что решит проблемы "дохлого канала" удаленных партнеров?

С удовольствием... Но пока квалификации не достаточно. Мы ява-технологии активно используем-изучаем-пишем только полтора года. С J2SE еще до конца не разобрались...   Закончим толстого клиента... возьмемся за тонкого  И в таком подходе, в наших условиях, есть большой плюс. К тому времени все процессы будут формализованы-оптимизированы-описаны и структура базы данных устаканится.

Тонкий клиент - это браузер. Его обновлять, действительно, не надо. Но тонкий клиент обычно предьявляет более высокие требования к качеству связи с сервером, чем толстый, потому что он по определению только показывает то, что присылает сервер. Конечно, применение javascript добавляет мозгов тонкому клиенту и позволяет снизить интенсивность обмена с внешним сервером.  

и


Нужно делать то, что сможет отдельно работать (без связи). А тонкий клиент при перебоях - гиблая идея.