3-х звенная архитектура
Есть СУБД, сервер приложений, само клиентское приложение.
Вопросы с организацией связи между сервером и клиентом:
1. Протокол передачи данных на основе XML. Т.е. сервер формирует некую выборку данных в XML-ном виде, потом эти данные сжимаются и передает на клиента. Клиент в таком же виде передает данные на сервер, плюс в виде XML передает на сервер имена вызываемых процедур/функций (не SQL) с типом, количеством и значениями параметров.
Вопрос: насколько оптимальна такая схема обмена данными? Если какие либо схемы попроще, понадежней и т.п.?
2. Прием и отображение табличных данных на клиенте.
Тут 2 варианта:
а) полностью вся работа с данными идет на сервере, а клиент только получает таблицы (в виде XML) и отображает их
Достоинства:
- вся логика сосредоточена в одном месте
Недостатки:
- большой трафик
- придется писать свою модель отображения данных, при этом заморачиваться с кешированием (что бы запрашивать с сервера только видимую для пользователя часть данных и хранить в кеше 1-2 страницы для ускорения отображения)
б) На клиенте предусмотреть свою локальную БД (акцесс, sqlite), которая будет синхронизироваться с сервером. При этом для каждой сущности кроме ее ID вводить время изменения. Сервер же хранит и выдает данные по запросу, в зависимости от времени изменения.
Достоинства:
- небольшой траффик
- возможность локально работать (при подключении к серверу синхронизировать данные)
- не надо ничего писать своего, для отображения данных (подойдут стандартные объекты)
Недостатки:
- придется писать 2 логики работы с данными (на сервере и на клиенте)
- довольно сложный процесс синхронизации.
Кто разрабатывал подобные системы, поделитесь соображениями.
а) полностью вся работа с данными идет на сервере, а клиент только получает таблицы (в виде XML) и отображает их
Достоинства:
- вся логика сосредоточена в одном месте
Оправдан ли такой способ в плане производительности серверной части?
Недостатки:
- большой трафик
сами себе противоречите
....потом эти данные сжимаются....
Так что не думаю что трафик будет больше обычного sql-трафика
- придется писать свою модель отображения данных, при этом заморачиваться с кешированием (что бы запрашивать с сервера только видимую для пользователя часть данных и хранить в кеше 1-2 страницы для ускорения отображения)
В написании своей модели отображения данных думаю нет проблемы, а вот с кэшированием...впринципе запрос 1-й страницы данных с сервера не так затратен в плане производительности как запрос всего, но... Если мы всю выборку будем хранить на сервере это вызовет лишнюю и неоправданную жратву оперативы на серваке. Если мы будем на сервере для нового кэша делать новую выборку то страницы могут просто не сойтись и пользователь "потеряет" строки.
б) На клиенте предусмотреть свою локальную БД (акцесс, sqlite), которая будет синхронизироваться с сервером. При этом для каждой сущности кроме ее ID вводить время изменения. Сервер же хранит и выдает данные по запросу, в зависимости от времени изменения.
Достоинства:
- небольшой траффик
Не думаю что это оправдано, всё равно кэш обновлять столько же трафика как и простые запросы +дополнительный расход системных ресурсов на синхронизацию
- возможность локально работать (при подключении к серверу синхронизировать данные)
Данные могут потерять свою актуальность задолго до синхронизации, не думаю что хорошая идея.
- не надо ничего писать своего, для отображения данных (подойдут стандартные объекты)
Это не такуй уж и плюс, по сравнению с разработкой системы безотказной синхронизации.
Недостатки:
- придется писать 2 логики работы с данными (на сервере и на клиенте)
Ctrl+C Ctrl+V
- довольно сложный процесс синхронизации.
полностью согласен + как решать спорные вопросы (например один пользователь в офлайне изменил данные по клиенту, а другой пользователь удалил этого клиента - чей кэш прав)?
Клиентов не так уж и много будет, и они не будут постоянно в онлайне сидеть
Так что не думаю что трафик будет больше обычного sql-трафика
При способе "б" траффик все же меньше получается
Вот как раз есть проблемы, как постранично тащить данные, в какой момент данные запрашивать и т.д. Пока не представляю как это можно реализовать...
Алгоритм тут примерно следующий: у сервера запрашивается его текущее время, и от этого времени пляшем, т.е. с клиента уходят данные на сервер только те, которые были изменены (в раеле это несколько записей БД получается), с сервера на клиента несколько десятков строк (данных других клиентов), против п. "а", когда надо тянуть все абсолютно (постранично, но все рано тянуть)
Каким образом? Данные напрямую удаляться не будут, будет выставляться только признак возможности отображения.
Ну как сказать... если учесть большой гимор и недопонимание как отображать в реальном времени данные с сервера, то скорее большой плюс
Немного сложнее будет, но унифицировать объекты по работе с данными можно будет.
по последней дате изменения - кто последний, тот и папа
К времени сервера привязка. Т.о. исключаем расхождение во времени между 2-мя компами, часовые пояса и т.п.
А что значит статус записи?
почему не хочешь заюзать любой промышленный ремоутинг?
Если бы я знал что это, то наверно поддался на уговоры...
А что значит статус записи?
При наличии локальной БД привязка ко времени сервера - большой гемор. Даже без локальной - тоже самое. Уж поверь. Любая завязка "на время" отымеет тебе мозги так что мало не покажется.
Статус записи - текущее состояние объекта. Например если запись отправлена на сервер - локальный оператор не может ее модифицировать. И т.д. Справочник состояний так же храниться на локальной БД и может быть синхронизирован - что позволяет гибко менять логику поведения огромной сети машин без вояжа по стране.
wcf, json.net, rmi и т. д.
Другими словами серелизация объектов?
ЗЫ: скорей всего в Qt будет делаться, посему "ремоутинг" несколько не применимо будет
Клиентов не так уж и много будет
[/quote]
Тогда и проблема трафика и проблема производительности серверной части уходят на второй план.
[QUOTE=oxotnik333]
К времени сервера привязка
[/quote]
<<А если у пользователя севшая батарейка на биосе? :) М.б. идея kot_ статусы для записей (отредактирована/добавлена и т.д.) лучше (клиент->сервер)? Но как быть с синхронизацией в другую сторону сервер->клиент?
Ну и создание начального кэша тоже добавляет вопрос. Впринципе если пользователи в офлайне только добавляют записи и всё, то это не проблема, а если он захочет отредактировать запись, которой нет в кэше?
З.Ы. на QtScript можно сделать очень гибкую и функциональную систему;)
Проблема трафика исключетельно в интересах клиентов (многие через жопорез сидят)
<<А если у пользователя севшая батарейка на биосе? :) М.б. идея kot_ статусы для записей (отредактирована/добавлена и т.д.) лучше (клиент->сервер)? Но как быть с синхронизацией в другую сторону сервер->клиент?
Ты не понял насчет серверного времени: сервер выдает свое время, и для программы клиента это будет являться ее внутренним временем, т.е. ко времени машины клиента само приложение обращаться не будет.
Ну и создание начального кэша тоже добавляет вопрос. Впринципе если пользователи в офлайне только добавляют записи и всё, то это не проблема, а если он захочет отредактировать запись, которой нет в кэше?
Если ее нет, то и редактировать нечего будет. Сначала обновляемся с сервера, потом редактируем что получили. Если нет соединения с сервером, сиди соси палец.
Статус записи - текущее состояние объекта. Например если запись отправлена на сервер - локальный оператор не может ее модифицировать. И т.д. Справочник состояний так же храниться на локальной БД и может быть синхронизирован - что позволяет гибко менять логику поведения огромной сети машин без вояжа по стране.
Извини за тупость, но чет я плохо понимаю принцип действия.
Какой нибудь жизненный пример можешь привести?
Выдать всем по 3Г модемчику?))
Ты не понял насчет серверного времени: сервер выдает свое время, и для программы клиента это будет являться ее внутренним временем, т.е. ко времени машины клиента само приложение обращаться не будет.
Да понял я всё вот и говорю если нет соединения с сервером то как отслеживать новые/изменённые записи, какое время брать за стартовое? Выход - в кэше хранить статусы записей.
Если ее нет, то и редактировать нечего будет. Сначала обновляемся с сервера, потом редактируем что получили. Если нет соединения с сервером, сиди соси палец.
В этом случае вся идея офлайн работы встаёт под вопрос. Или каждый раз кэшировать(обновлять/синхронизировать) все данные необходимые для офлайн работы.
В этом случае вся идея офлайн работы встаёт под вопрос. Или каждый раз кэшировать(обновлять/синхронизировать) все данные необходимые для офлайн работы.
Это вопрос...
С другой стороны можно поставить для измененных в оффлайне записей время большее (не важно какое) чем последнее время, полученное с сервера, тогда ври онлайне, клиент отправляет данные, измененные в последенй оффлайн сессии, а сервер их у себя раскладывает уже со своим временем, ну и на клиента это время попадает и он запоминает его. Если с нескольких клиентов данные одинаковые меняются, то сохраняются те, кто последний подцепился к серверу. Как то так...
Это система для автоматизации бизнесс-процессов в конторе. Что то среднее между 1С и документооборотом.
Какой нибудь жизненный пример можешь привести?
Ну на пример. У меня обмен должен идти в обе стороны - с клиента на сервер, с сервера на клиент. Работа идет в пакетном режиме. Под пакетом понимается XML-файл определенной струкуры. Пакеты бывают нескольких типов - грубо говоря пакет с данными и пакет синхронизации. Пакет с данными модифицирует данные, пакет синхронизации - только меняет статусы. Система оперирует сущностями - типа клиента, документа, платежа и т.д. Каждая сущность подчиняется какому то набору правил - например документ может быть создан - его статус 0. Документ подготовлен к отправке - его статус -1. Документ отправлен на сервер - его статус - 2. Документ принят сервером - его статус 3 и так далее. В каждом статусе есть набор действий-переходов - например со статуса 0 документ может получить статус либо 1, либо 7 (удален оператором), либо 8 (требует корректировки на сервере), либо ... либо.
Со статусом 2 документ может получить только статус 3. И так далее. Соответственно есть набор операций (создать, открыть, редактировать, печатать и пр.)и для каждого статуса этот набор ставится в соответствие. Битовые маски и прочая фигня. Идея я надеюсь понятна?
Ты не понял насчет серверного времени:
"не советую - съедят" (с)Стругатские.
Кстати описанная мной система легко работает на любом типе сети начиная с флешконет заканчивая оптоволокном.
То есть что-то типа такого:
http://v8.1c.ru/doc8/
Так? Если оно, то проще рассуждать, да и есть с чего "сплагиатить"...
http://v8.1c.ru/doc8/
Так? Если оно, то проще рассуждать, да и есть с чего "сплагиатить"...
Если ты еще не понял, то меня интересуют технические детали организации и передачи данных, от одинэс этого никак не получишь, ибо закрытый код. Саму 1С использовать моветон, ибо тогда все превращается в банальную поддержку этого продукта и много на этом не поднимешь, и ко всему этому при распределенных офисах настраивать все это взаимодействие большой геморой и работа больше для админа. Единственное что можно оттуда почерпнуть это интерфейс пользователя, но этот вопрос больше на заказчике лежит.
В общем пока буду прорабатывать вариант 2.а.
Остается открытым вопрос по актуальности протокола обмена данными через XML структуру... возможно в Qt найдутся объекты, которые после некоторого допила можно будет приспособить напрямую, без XML прокладки.
Ну так вначале надо же понять, что за тип программы. Технические детали могут различаться в зависимости от типа программы.
Про закрытый код:
http://www.opennet.ru/prog/sml/55.shtml
Я понимаю ход твоих мыслей, потому и не советую использовать 1С.
Технические детали то как раз боле менее универсальные в подобной архитектуре. Тем более что на эту архитектуру можно потом насадить любую логику.
Странный ты человек. Попросил выбрать из двух вариантов, а потом потом рассуждаешь об универсальности технических деталей. Например, если упростить детали, то Вконтакте использует вариант 2а, а Mercurial - вариант 2б. И оба используют правильный способ.
Оба варианта имеют право на существование, и в конечном итоге выполнят свою цель, вне привязки к логике бизнес-процесса. Т.е. для них обоих бизнес-модель может быть любая, оба варианта являются "универсальным" механизмом по работе с данными.
А вот реализацией они различаются. Я хотел узнать плюсы и минусы каждой реализации ну и пути решения.
Еще попутно хотел узнать другие "универсальные" варианты по передачи/синхронизации данных.
Бизнес-логику сейчсас рассматривать бессмысленно, т.к. ее еще надо из заказчика выудить, а пока я не в курсе что там конкретно будет, но на пердасу данных это никак не влияет.
ЗЫ: это примерно тоже самое что и платформа 1С, в которой можно написать бухгалтерию или кадры или документооборот. Логика разная, а ядро постоянно.