Задача:
Нужно автоматизировать рабочее место пользователя, который имеет ноутбук и медленный 3G/edge и часто даже просто отсутствующий интернет. Пользователь должен не зависимо от наличия интернета редактировать свои простые документы и периодически заливать на сервер, заодно обновляя справочную информацию.
Доступа к ноутбуку пользователя не будет и даже если будет, то админить каждый ноут будет очень накладно по времени, т.к. может быть 100+ пользователей.
Требования:
1. Web-интерфейс, потому что он наиболее rich, кросс-платформенный и под него полно дизайнеров
2. Приложение должно легко устанавливаться и обновляться (одной кнопкой)
3. Приложение должно сохранять вводимые специалистом данные в in-process базу и по мере наличия интернета "синхронизироваться" с основной базой.
1 Вариант решения:
Написать приложение-сервис, которое хостит в себе веб-севис (Jetty) с сайтом (на Grails) и базу (H2 / Mongo).
Плюс, отдельное update-приложение, которое занимается обновлением сервиса — останавливает сервис, поднимать рядом новую версию сервиса, накатывать на базу миграции, проверяет работоспособность поднятого, удаляет старое и если что — все корректно откатывает и т.д.
Меня смущает такой способ обновления по нескольким причинам:
1. Сложность написания приложения без ошибок и трудность автоматизации тестирования обновления (время разработки может растянуться на неопределенный срок)
2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
2 Вариант решения:
(сразу скажу, что в Java опыта нет, но прилично пописал в .net, поэтому делайте скидку на случай бредовости решения)
Вместо сервиса сделать standalone-приложение, которое не только хостит в себе веб-сервер и базу, но и окно в котором хоститься браузер (ui-элемент), который в себе отображает хостящийся сайт.
Для обновления использовать Web Start (jnlp). База будет лежать рядом вне jnlp-файла.
При обновлении jnlp-приложения (на сколько я понимаю механизм уже хорошо отлажен) и первом запуске обновленного приложения будет проверяться версия базы и если нужно — накатываться миграции.
Тут все выглядит проще и надежнее (для меня):
— не нужно писать свой механизм обновления
— не нужно посылать пользователя в браузер по урлу localhost:xxxx — он просто работает с приложением
— не нужно писать сервис, который сложнее в администрировании, отладке и обновлении (могут требоваться перезагрузки)
— если что-то сломается, можно обновить jnlp файл, он автоматом обновится у пользователя и все заработает как надо (хотя фаза выяснения состояния сломанного приложения на ноуте пользователя все равно есть и может сильно все усложнять).

Вопросы:
1. На сколько рабочий 1 вариант решения?
1. На сколько состоятелен 2 вариант решения?
2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.

Здравствуйте, Keith, Вы писали:

K>1. На сколько рабочий 1 вариант решения?

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

K>1. На сколько состоятелен 2 вариант решения?

Получше, но если не писал GUI на Java ты затрахаешься.

K>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.

HTML 5 Rich UI. Пока связь есть работаем с сервером. Связь пропала начинаем работать с WebDB и Local Storage. Связь вернулась, синхронизуемся с сервером. GWT все это умеет из коробки.

Здравствуйте, Keith, Вы писали:

1 Вариант решения:
Немного не понял что означает приложение-сервис.
Допустим у вас будет приложение в виде сервера (Jetty) поднятого локально с сайтом (на Grails) и базой (H2 / Mongo).
Работать будет все время с локальной базой. По шедулеру, скажем раз в час, или по явной просьбе юзера производится синхронизация базы (если есть интернет).
Далее по шедулеру будет чекать новую версию. Если есть, то скачивается архив с сервером и sql сприпт обновления.
Удалось скачать? Если да то информируем пользователся, что есть новая версия, хотите обновить и перезапустить?
Далее выполняется скрипт обновления который:
1) делаем копию базы.
2) применяем скрипт обновления базы. -> если все ок считаем что скрипт рабочий
2) поднимает новую версию на копию базы (на другом порте)
3) дергает REST api основных сервисов для проверки работоспособности.
Если все ОК тогда
4) Тушим основной сервер.
5) делаем swap между основной версией севера/базы и копией.
Теперь у нас старая версия вместе со старой базой хранятся на всякий случай, если что-то пойдет не так, всегда можно будет вернуться к ним.
5) Поднимаем сервер.

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

Мерж базы тоже должен быть таким, чтобы если отпадет интернет база не осталась в неконсистентном состоянии.
И его можно было продолжить с той же точки, когда интернет появится. Это отдельная тема, надо подумать..
Желательно больше информации о структуре базы.

K>>1. На сколько состоятелен 2 вариант решения?
А>Получше, но если не писал GUI на Java ты затрахаешься.

А в чем, собственно, проблема? Писал на WinForms, оно сильно отличается?
Тем более там приложение-то — одно окно с браузером (контрол) на все окно, а втури этого браузера уже сайт.

K>>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.
А>HTML 5 Rich UI. Пока связь есть работаем с сервером. Связь пропала начинаем работать с WebDB и Local Storage. Связь вернулась, синхронизуемся с сервером. GWT все это умеет из коробки.

1. А можно html 5 приложение запустить без интернета? Он локально кэширует страницы или все страницы упакованы в некий package?
2. На гугл неохота завязываться, он себя в последнее время плохо ведет.

Здравствуйте, GreenTea, Вы писали:

GT>1 Вариант решения:
GT>Немного не понял что означает приложение-сервис.

Имел ввиду такой сервис.

GT>Допустим у вас будет приложение в виде сервера (Jetty) поднятого локально с сайтом (на Grails) и базой (H2 / Mongo).
GT>Работать будет все время с локальной базой. По шедулеру, скажем раз в час, или по явной просьбе юзера производится синхронизация базы (если есть интернет).
GT>Далее по шедулеру будет чекать новую версию. Если есть, то скачивается архив с сервером и sql сприпт обновления.
GT>Удалось скачать? Если да то информируем пользователся, что есть новая версия, хотите обновить и перезапустить?
GT>Далее выполняется скрипт обновления который:
GT>1) делаем копию базы.
[поскипал]
GT>5) Поднимаем сервер.

Я общую схему понимаю, и шаги расписать сам могу, предусмотрев все на свете, проблема, на мой взгляд в том, что это слишком сложное решение.

GT>И его можно было продолжить с той же точки, когда интернет появится. Это отдельная тема, надо подумать..
GT>Желательно больше информации о структуре базы.

Структура базы вроде не сложная пока, но пути заказчика неиповедимы, поэтому ограничивать себя в этом не хотелось бы.
Пока что структура такая — несколько справочников, которые подтягиваются из центрального хранилища и набор иерархических документов,
которые создает пользователь. Это чем-то похоже на evernote.

А что на счет варианта №2?

Здравствуйте, Keith, Вы писали:

K>1. А можно html 5 приложение запустить без интернета? Он локально кэширует страницы или все страницы упакованы в некий package?

Можно. Оно выкачивает и кэширует все страницы указанные в кэш-манифесте.

K>2. На гугл неохота завязываться, он себя в последнее время плохо ведет.

HTML5 не имеет отношения к гуглу. Можно хоть руками на голом JS писать. Кстати, если взять extjs, то это будет даже удобно.

Здравствуйте, Miroff, Вы писали:

K>>1. А можно html 5 приложение запустить без интернета? Он локально кэширует страницы или все страницы упакованы в некий package?
M>Можно. Оно выкачивает и кэширует все страницы указанные в кэш-манифесте.
K>>2. На гугл неохота завязываться, он себя в последнее время плохо ведет.
M>HTML5 не имеет отношения к гуглу. Можно хоть руками на голом JS писать. Кстати, если взять extjs, то это будет даже удобно.

Я имел ввиду, что GWT не охота, хотя вариант интересный, учитывая, что GWT-сайт можно собрать в war и захостить где угодно, не завися от гугла.

На сколько легко писать приложение чистом HTML 5 + JS , которое работает то с локальной базой, то с удаленным сервисом?
Видимо, нужно написать два DAL'а — один для локального хранилища, другой для сервисов удаленной базы и в процессе работы проверять интернет и разруливать куда писать.
А кэш обновляется сам, когда размер страницы меняется или по времени?
А миграции к структуре локального хранилища из коробки есть? Или нужно самому вести историю миграций?

Здравствуйте, Keith, Вы писали:

K>Я имел ввиду, что GWT не охота, хотя вариант интересный, учитывая, что GWT-сайт можно собрать в war и захостить где угодно, не завися от гугла.
Google уже фактически бросил GWT. Сейчас его поддержкой активно занимается Vaadin.
http://googlewebtoolkit.blogspot.ru/2012/09/gwt-survey.html

Здравствуйте, Keith, Вы писали:

K>Я имел ввиду, что GWT не охота, хотя вариант интересный, учитывая, что GWT-сайт можно собрать в war и захостить где угодно, не завися от гугла.

Лично мне GWT не нравится из-за чрезмерной переусложненности и завязанности на вендора.

K>На сколько легко писать приложение чистом HTML 5 + JS , которое работает то с локальной базой, то с удаленным сервисом?

Не особенно сложно, но лучше все же использовать какую-нибудь библиотеку.

K>Видимо, нужно написать два DAL'а — один для локального хранилища, другой для сервисов удаленной базы и в процессе работы проверять интернет и разруливать куда писать.

Я бы сделал один слой доступа к данным внутри которого разруливал все вопросы синхронизации локального и удаленного хранилища.

K>А кэш обновляется сам, когда размер страницы меняется или по времени?

Почитай спеку, там есть разные режимы.

K>А миграции к структуре локального хранилища из коробки есть? Или нужно самому вести историю миграций?

Самому. А вообще из локальной базы легким движением руки делается no sql хранилище которое при правильном использовании не требует миграций.

Здравствуйте, Keith, Вы писали:

K>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.

Серверная часть стандартная, в ней вопросов нет. Как я вижу проблема именно с UI. Попробуйте посмотрет в сторону Adobe Flex/AIR. Интерфейс там программировать на много приятнее чам на HTML/JS и уж тем более чем на Java. Сама технология по своей идее очень похожа на HTML/JS. С одной стороны вы получите интерфейс не хуже десктопного, с другой нет проблем с кроссбраузерностью и обновлениями, т.к. все работает во Флэш Плеере. Сама Флекс СДК — бесплатная, платные только среды разработки. Я с Флекс Билдером работал, есть еще для идеи надстройка.

K>А что на счет варианта №2?

Я его не очень понял. Веб стартовое приложение с окном браузера, допустим понятно, но еще нужен сервер + веб приложение, правильно я понимаю? Их тоже закачивать вебстартом? Я честно говоря слабо такое представляю. Ничего вроде не упрощается, все проверки при обновлении апликухи/базы остаются.

по поводу варианта 1 понимаю что сложно.. Да и 1 север на 1 клиента поднимать как то стремно. Чтобы проще, надо делать десктопную апликуху. Может стоит посмотреть в сторону osgi. Тогда, если правильно разбить на модули (бандлы), то можно будет отдельные изменившиеся бандлы подгружать в реальном времени и обновлять без перезапуска всего приложения. GUI swing на джаве писать не так уже и сложно, был опыт. Также можно обратить внимание на java fx.

Здравствуйте, noofiz, Вы писали:

K>>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.

N>Серверная часть стандартная, в ней вопросов нет. Как я вижу проблема именно с UI. Попробуйте посмотрет в сторону Adobe Flex/AIR. Интерфейс там программировать на много приятнее чам на HTML/JS и уж тем более чем на Java. Сама технология по своей идее очень похожа на HTML/JS. С одной стороны вы получите интерфейс не хуже десктопного, с другой нет проблем с кроссбраузерностью и обновлениями, т.к. все работает во Флэш Плеере. Сама Флекс СДК — бесплатная, платные только среды разработки. Я с Флекс Билдером работал, есть еще для идеи надстройка.

С флешем проблема в "интерфейсе не хуже десктопного", нужен интерфейс как в вебе, чтобы больая картинка в фоне, контрлы не стандартного вида и пр.
И, естественно, чтобы дизайнеров было легко найти и они стоили не слишком дорого.

Здравствуйте, GreenTea, Вы писали:

K>>А что на счет варианта №2?
GT>Я его не очень понял. Веб стартовое приложение с окном браузера, допустим понятно, но еще нужен сервер + веб приложение, правильно я понимаю? Их тоже закачивать вебстартом? Я честно говоря слабо такое представляю.

Да, и веб-сервер с сайтом будут хоститься в том же приложении с окном браузера.
Т.е. состав приложения такой:
1. Standalone-приложение: втроенный веб-сервер с сайтом, встроенная база. Все это внутри jnlp, который и обновляется.
2. Файл базы с данными. Лежит рядом и не обновляется.
При запуске приложения проверяется версия базы и если она более древняя, то накатываются миграции.
Процесс обновления ложится полностью на Web Start, который стабилен и отлажен.
Мне остается только собирать новые версии приложений и выкладывать "в паблик", чтобы Web Start сам обновил приложение по возможности.

GT>Ничего вроде не упрощается, все проверки при обновлении апликухи/базы остаются.
Проще тем, что:
— нет приложения-сервиса, которое писать и админить далеко не так просто как standalone.
— нет самописного механизма обновления, который долго писать/отлаживать и ошибки в котором стоят очень дорого.

GT>по поводу варианта 1 понимаю что сложно.. Да и 1 север на 1 клиента поднимать как то стремно.
GT>Чтобы проще, надо делать десктопную апликуху.
Я тоже так считаю.

GT>Может стоит посмотреть в сторону osgi.
Смотрел, но сходу не понял как оно работает.
Вроде менеджера пакетов на стороне клиента, который может подтягивать указанные в конфиге зависимости?
Можете на пальцах описать как его тут можно прикрутить?

GT>Тогда, если правильно разбить на модули (бандлы), то можно будет отдельные изменившиеся бандлы подгружать в реальном времени и обновлять без перезапуска всего приложения.
Ну мне не обязательно без перезагрузки, можно и при запуске приложения обновится, если есть что обновить.
И разные пакеты подтягивать мне не обязательно и даже проще было бы с одним пакетом типа jnlp.

GT>GUI swing на джаве писать не так уже и сложно, был опыт. Также можно обратить внимание на java fx.
А с WinForms в .net можете сравнить?
Вообще, gui должен быть на html — это одно из главных требований, поэтому и предполагается внутри десктопного приложения хостить веб-сервер с сайтом.

Здравствуйте, Keith, Вы писали:

K>1. Standalone-приложение: втроенный веб-сервер с сайтом, встроенная база. Все это внутри jnlp, который и обновляется.
Небольшая поправка — jnlp будет отдельно от основного jar-файла, котороый уже будет содержать в себе все необходимое.
Я в Web Start только разбираюсь...

Здравствуйте, Keith, Вы писали:

K>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
Все данные хранятся в СУБД, синхронизация данных — берём symmetricds. Должна быть возможность загрузить чистую базу с сервера, если вдруг поломалась клиентская.
Изменение структуры БД — liquibase/аналоги.
Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.

Здравствуйте, ., Вы писали:

K>>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
.>Все данные хранятся в СУБД, синхронизация данных — берём symmetricds.

Спасибо за symmetricds — очень интересная штука.

.>Должна быть возможность загрузить чистую базу с сервера, если вдруг поломалась клиентская.

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

.>Изменение структуры БД — liquibase/аналоги.

О, еще одна интересная библиотека, спасибо!

.>Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
.>Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.

А механизм для обновлений какой использовать? Свой писать или Web Start / аналоги ?

Здравствуйте, Keith, Вы писали:

K>Здравствуйте, Keith, Вы писали:

K>>1. Standalone-приложение: втроенный веб-сервер с сайтом, встроенная база. Все это внутри jnlp, который и обновляется.
K>Небольшая поправка — jnlp будет отдельно от основного jar-файла, котороый уже будет содержать в себе все необходимое.
K>Я в Web Start только разбираюсь...

Я с веб стартом не работал, но.. надеятся что он магическим образом все обновит не стал бы. А если новая версия окажется не рабочая (изза ошибка программиста)? То откатить на старую не получится же.
"При обновлении jnlp-приложения (на сколько я понимаю механизм уже хорошо отлажен) и первом запуске обновленного приложения будет проверяться версия базы и если нужно — накатываться миграции." А если накатить миграции не удалось (по ошибке программиста) а новая версия уже не может работать со старой базой? jnlp не спасет от всего этого.. Ваша задача не стандартная. Не думаю что есть стандартный инструмент для решения нестандартной задачи.

osgi поможет, если приложение будет разрастаться, не обновлять его целиком. А так же может обновлять бандлы без перезапуска всего приложения (бывает ему все же не удается), тогда уже надо перезапускать.
Между бандлами явно прописываются зависимости, чтобы osgi контейнер их разрулил при апдейте. Например если обновляется бандл B и от него зависит A, то A приостанавливается, B обновляется, и A перезапускается уже ссылаясь на новую версию B. Между собой бандлы взаимодействуют через специальные интерфейсы. Мы на работе пишем веб приложение на osgi, все круто сейчас, но стоила эта архитектура большой крови. Т.к. в идеале используемые либы и фреймворки должны быть osgi-ные, а это не всегда так. Приходится извращаться. Еще много либ, неявно полагают что работают с одним класслоадером, в osgi же каждый бандл имеет свой. Если у вас мало опыта в java я бы не стал браться реализовывать первый проект на osgi, это надо хорошо шарить во внутренней структуре jvm. Так же надо неслабо голову поломать по поводу того как именно / по какому принципу разбивать приложение на бандлы. Можно бить горизонально, можно вертикально, можно по диагонали

В javafx у меня опыта совсем не много. По идее в нем можно рисовать очень красивые интерфейсы, а рендерится будет видеокартой. Разметка конечно не html, но вот только что загуглил http://docs.oracle.com/javafx/2/webview/jfxpub-webview.htm, т.е. можно делать html вставки.. С возможностью взаимодействия джаваскрипта на html страницах с апликухой на javafx, в обоих направления. Возможно таким макаром получится реализовать весь интерфейс.

Здравствуйте, Keith, Вы писали:

K>Здравствуйте, ., Вы писали:

K>>>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
.>>Все данные хранятся в СУБД, синхронизация данных — берём symmetricds.
K>Спасибо за symmetricds — очень интересная штука.
Мы использовали — работает. Но мы допиливали под наши условия. Идея там правильная для некоторых типов приложений, но надо хорошо продумать что там с чем будет обмениваться, использовать приёмы построения распределённых систем.

.>>Должна быть возможность загрузить чистую базу с сервера, если вдруг поломалась клиентская.
K>Потеря данных критична для бизнеса, т.е. базу нужно в таком случае чинить.
Это таки редкая вещь, если субд спроектирована правильно, целостность поддерживается. Это случается не чаще, чем поломалось-потерялось железо.
Рекомендуйте пользователям синхронизироваться почаще, и как-то хорошо давайте знать, что пока не ушло на сервер — критичным для бизнеса быть не должно, ибо клиентское железо сделать надёжным невозможно.

.>>Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
.>>Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.
K>А механизм для обновлений какой использовать? Свой писать или Web Start / аналоги ?
Веб-старт в принципе работает... но глючный он какой-то и старый. Можете с него начать, но, думаю, несложно будет перейти на что-то своё.

Здравствуйте, GreenTea, Вы писали:

GT>Я с веб стартом не работал, но.. надеятся что он магическим образом все обновит не стал бы.
GT>А если новая версия окажется не рабочая (изза ошибка программиста)?
GT>То откатить на старую не получится же.

Не получится, но разработчик может выложить исправленное приложение и оно автоматом обновится. В теории, я пока только разбираюсь с Web Start.

K>"При обновлении jnlp-приложения (на сколько я понимаю механизм уже хорошо отлажен) и первом запуске обновленного приложения будет проверяться версия базы и если нужно — накатываться миграции."
GT>А если накатить миграции не удалось (по ошибке программиста) а новая версия уже не может работать со старой базой?

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

GT>jnlp не спасет от всего этого..

Да, но он спасет от написания своего механизма обновления, который, на мой взгляд, довольно тяжело написать и отладить самостоятельно.

GT>Ваша задача не стандартная. Не думаю что есть стандартный инструмент для решения нестандартной задачи.

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

GT>osgi поможет, если приложение будет разрастаться, не обновлять его целиком. А так же может обновлять бандлы без перезапуска всего приложения (бывает ему все же не удается), тогда уже надо перезапускать.
GT>Между бандлами явно прописываются зависимости, чтобы osgi контейнер их разрулил при апдейте. Например если обновляется бандл B и от него зависит A, то A приостанавливается, B обновляется, и A перезапускается уже ссылаясь на новую версию B. Между собой бандлы взаимодействуют через специальные интерфейсы. Мы на работе пишем веб приложение на osgi, все круто сейчас, но стоила эта архитектура большой крови. Т.к. в идеале используемые либы и фреймворки должны быть osgi-ные, а это не всегда так. Приходится извращаться. Еще много либ, неявно полагают что работают с одним класслоадером, в osgi же каждый бандл имеет свой. Если у вас мало опыта в java я бы не стал браться реализовывать первый проект на osgi, это надо хорошо шарить во внутренней структуре jvm. Так же надо неслабо голову поломать по поводу того как именно / по какому принципу разбивать приложение на бандлы. Можно бить горизонально, можно вертикально, можно по диагонали

Да, это я, похоже, не осилю без опыта в Java.

GT>В javafx у меня опыта совсем не много. По идее в нем можно рисовать очень красивые интерфейсы, а рендерится будет видеокартой. Разметка конечно не html, но вот только что загуглил http://docs.oracle.com/javafx/2/webview/jfxpub-webview.htm, т.е. можно делать html вставки.. С возможностью взаимодействия джаваскрипта на html страницах с апликухой на javafx, в обоих направления. Возможно таким макаром получится реализовать весь интерфейс.

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

Здравствуйте, ., Вы писали:

K>>>>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
.>>>Все данные хранятся в СУБД, синхронизация данных — берём symmetricds.
K>>Спасибо за symmetricds — очень интересная штука.
.>Мы использовали — работает. Но мы допиливали под наши условия. Идея там правильная для некоторых типов приложений, но надо хорошо продумать что там с чем будет обмениваться, использовать приёмы построения распределённых систем.

А можно вкратце как там разруливается синхронизация структуры с циклическими зависимостями?
Оно умеет само внутри одной транзакции снимать foreign key'и, заливать данные, восстанавливать foreign key'и?
Как происходит разруливание конфликтов при, например, иземнении структуры или основных таблиц типа справочников?
Вообще — тема очень интересная, но очень сложная, удивлен, что кто-то написал такую либу для любых структур данных..
У микрософта есть Sync, но тот очень громоздкий и примитивный — все на тригерах, структуру обновлять нельзя и если что-то сломается, то хрен починишь.

.>>>Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
.>>>Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.
K>>А механизм для обновлений какой использовать? Свой писать или Web Start / аналоги ?
.>Веб-старт в принципе работает... но глючный он какой-то и старый. Можете с него начать, но, думаю, несложно будет перейти на что-то своё.

Спасибо за мнение, решил пока с ним разобраться, а дальше буду смотреть...