Привет господа.
Такая вот задача. Нужно скажем сделать распределнный склад. JavaWebStart & Hibernate (Oracle предполагается) в каком-то объеме я уже освоил. Вроде все хорошо, пока у удаленных клиентов есть связь с центальным сервером.
Но вот встает вопрос, если этой связи нет (и будет через две недели предположим), а работать нужно!? Есть у кого-нибуть опыт решиния подобной задачи? Как поступали в этом случае?

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

Задача создать единое информационное пространстро коммерческого холдинга, может кто-нибуть занимаеться подобным? Буду рад подключиться к разработке, или делиться своим (сейчас ничего нет).

В принципе какого-то стандартного решения такой задачи на сегодня я не знаю.
В данной ситуации основная проблема - это проблема целостности данных.

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

Обычно уникальное значение генерится на SQL-сервере (SEQUENCE в ORACLE, IDENTITY в MS SQL). В режиме офлайн такая ситуация должна быть разрешена другим способом.
Например может быть использован алгоритм типа генерации GUID, который использует данные компьютера пользователя.

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

Вообщем, задачка сама по себе очень интересная. Если найдешь какие-либо материалы по данной тематие - буду признателен, если опубликуешь.

Удачи.

Если будет что опобубликовать, то обязательно ;)

Но меня еще беспокоит вопрос, как в этом случае поступать с базой?! Каждой группе клиентов ставить свою базу, которая будет обслуживать их на момент отсутсвия связи!? Или вообще каждому клиенту ставить базу типа hlsql (pure java)!? И пусть работает со своей базой данных ;)

Вскоре меня заинтересует вопрос о производительности. Если к примеру номенклатура десятски тысяч наименований, можно ли как-нибуть этот справочник кэшировать!?

Цитата

Но меня еще беспокоит вопрос, как в этом случае поступать с базой?! Каждой группе клиентов ставить свою базу, которая будет обслуживать их на момент отсутсвия связи!? Или вообще каждому клиенту ставить базу типа hlsql (pure java)!? И пусть работает со своей базой данных ;)

Здесь уже многое зависит от средства разработки для клиентской части.
В Delphi или в .NET существует механизм сброса данных из буфера на диск в виде файлов. Т.е. можно работать автономно с тем набором, который уже есть. И только потом махом синхронизировать данные с SQL. Но вот тут есть как раз проблемы целостности, о которых я говорил выше.
Руками такое организовать в принципе не сложно - необходимо просто RecordSet (DataSet) или что там еще научить хранить данные локально, загружать их из локальной копии. Ну само собой получать данные с SQL и отправлять изменения. Это действительно немного усилий требует.
Вот и работает пользователь с локальными данными, пока не нажмет заветную кнопочку .

Если это связь между офисами "то потухнет, то погаснет", а внутри сети проблем со связью нет, то может стОит подумать о синхронизации SQL-серверов. В данном случае достаточно несложно просто сделать правило, по которому новые ID раздаются по какому-либо правилу, которое позволяет делать их разными для каждого офиса.

Цитата

Вскоре меня заинтересует вопрос о производительности. Если к примеру номенклатура десятски тысяч наименований, можно ли как-нибуть этот справочник кэшировать!?

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

Если данные меняются на сервере, то сервер информирует об изминениях клиента передачей ID удаленных/измененных/добавленных записей. Ну и дальше они синхронизируются. Это небольшой трафик.

Если на клиенте - он посылает изменения на сервер.

Чтобы избежать большого трафика старайся организовывать запросы, которые имеют ограничения в каком-либо виде.

Вообщем-то и все советы, которые сейчас в голову пришли.

Антон, а тебе с каким базами приходилось работать!?
Ты выше говоришь о синхронизации SQL серверов... Этой темы я еще не касался. Почитаем какие возможности есть у Оракла и Вайрбирда (интербейз)
И как в данном случае менять структуру базы? Создавать механизм который будет автоматом запускать какие-то скрипты ;(

Так ява у тебя это не основной профиль?

Достаточно близко мне приходилось работать с
MS SQL Server, ORACLE, Sybase, Interbase (FireBird), SQLBase
Не могу сказать, что знаю про них все, но основные моменты проходил.

По поводу синхронизации серверов - здесь все достаточно серверозависимо.
В основном используется репликация. Которая, повторюсь, очень
серверозависимая. И есть не во всех серверах. Здесь единственное,
что может помочь - это читать документацию. Долго и нудно.
А также пробовать и пробовать.

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

У меня основной профиль - построение систем масштаба предприятия.
Я последние 7-8 лет работаю в фирмах, которые занимаются офшорным
программированием, а потому сталкиваться приходится практически со
всем, что появляется новенького. И иметь о каждой технологии представление.
Есть кое-какие предпочтения - JAVA, Delphi, ORACLE, C under Unix - но
это не всегда осуществимо

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

Конечно, скорость разработки в этом случае ниже, чем у узкого специалиста,
но мне зато видно шире

понятно ;)