Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

» Распределённые системы

Автор: RWSergey
Дата сообщения: 30.05.2003 04:20
Для начала такой вопрос: допустим имеется сервер баз данных
по волею судеб разлучённый с клиентом на довольно большое растояние.
Локалка туда неходит, можно только модемом, ну если повезёт то
оптоволокном по ~ 2Мбит (ну это в лучшем случае), вобщем связь непостоянная а если постоянная то медленная. (Во загнул да ).

Каким образом можно решить данную задачу, если
1. взят трёхзвенную архитектуру приложения.
2. не устанавливать СУБД у удалённого клиента.

Какие есть решения, предложения, советы (при условии выполнения этих двух условий).

Ну и какие решения есть вообще для решения данной проблемы.

Что на это говорит народная мудрость
Автор: Serjik
Дата сообщения: 30.05.2003 04:52
работай через терминал или цитрикс
Автор: Mickey_from_nsk
Дата сообщения: 30.05.2003 07:01
Можно в качестве клиента работать через веб, а логику приложения реализовать на Web-сервере.
Автор: v0yager
Дата сообщения: 30.05.2003 09:33
Для решения задачи нужна дополнительная информация. Хотя пару типичных вариантов можно предложить и по имеющимся сведениям (вместе со схемами выбора).

Давай вначале я задам пару вопросов на будущее (если дискуссия продолжиться), а потом перейду к общим вариантам.
Вопросы на вырост Отвечать на них мне не обязательно, но для себя это сделать все равно нужно:

Общее описание прикладной задачи (если подобная информация является конфиденциальной, то вопрос можно проигнорировать, при этом будет сложнее выбрать решение).
Время, отведенное на выполнение проекта
Предполагаемый размер БД
Интенсивность обмена пользователя с системой
Типичные задачи клиента (ввод новых данных, поиск, аналитическая обработка данных, ...)
Наличие постоянного соединения между клиентом и системой
Количество одновременных соединений клиентов с системой
Требования по безопасности (уровень секретности данных)
Требование к наличию возможности работать с приложением без соединения с сервером
Платформа для клиента, сервера

При наличии ответов на эти вопросы можно будет уточнить варианты решения. Пока общая схема:

Так ка БД стоит на месте и никуда не двигается, то все варианты будут отличаться на уровне клиента:

1. Тонкий клиент (веб-браузер, HTTP)
2. GUI клиент (SOAP, свой протокол поверх HTTP или TCP/IP)
3. Терминальные службы (MS Terminal Server, Citrix Metaframe, etc.)

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

GUI клиент с SOAP: не требует постоянного соединения (часть работы можно делать в офф-лайне), богатые возможности (и скорость) интерфейса, хорошо масштабируется, при использовании SSL обеспечивает адекватную защиту данных, дружит с проксями и другими подобными особями , интенсивность обмена данными пользователя и системы ограничена пропускной способностью канала связи. При наличии неподконтрольных проблем со связью (левая АТС в райцентре, например) можно реализовать дополнительную функциональность по защите/восстановлению после обрывов связи.

GUI клиент со своим протоколом: совпадает с SOAP версией за исключением более сложной сетевой подсистемы и усложнением реализации обмена клиент-сервер, потенциальные сложности с сетевой охраной

Терминальные службы (далее ТС): требует постоянного соединения, дороже (по сравнению с 1,2) масштабируется, при использовании VPN обеспечивает адекватную защиту данных, не всегда дружит с проксями и другими подобными особями , интенсивность обмена данными пользователя и системы НЕ ОГРАНИЧЕНА пропускной способностью канала связи. При использовании ТС обмен идет на уровне "снимком экрана" и клавиатуры/мыши, обмен между приложением на ТС-сервере и БД может быть существенно больше, чем пропускная способность канала связи клиент-система.

При этом не стоит забывать, что при использовании ТС приложение по работе с данными (клиента типа 1 или 2) все равно нужно делать. В отдельных случаях в качестве клиента можно использовать что-то типа Excel с VBA.

Добавлено:
В GUI клиенте со своим протоколом можно реализовать более эффективный с точки зрения траффика обмен. Это при условии, что нужно обмениваться большими объемами бинарных данных. Можно также использовать комбинированный подход к протоколу обмена: SOAP для управляющего канала и свой бинарный (в том числе и поверх HTTP) для передачи BLOB'ов.
Автор: diezel
Дата сообщения: 30.05.2003 09:46
Взгляни-ка вот сюда.
http://www.swd.ru/qnx/press/stories/korneev.pdf
Весьма неплохой пример распределенного приложения,
другое дело, что задачи весьма специфические
Автор: RWSergey
Дата сообщения: 02.06.2003 05:23
Пришу пардона за долгое молчание, был отлучён от интернета


v0yager
Попытаюсь ответить



Цитата:
Время, отведенное на выполнение проекта

Гдето около полугода


Цитата:
Предполагаемый размер БД

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



Цитата:
Интенсивность обмена пользователя с системой


Цитата:
Типичные задачи клиента (ввод новых данных, поиск, аналитическая обработка данных, ...)

Каждый пользователь заходит в систему со своими провами: некоторый выполняют приимущественно Select и insert, некоторый select и update поиск производят практически все.


Цитата:
Наличие постоянного соединения между клиентом и системой


Цитата:
Требование к наличию возможности работать с приложением без соединения с сервером


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


Цитата:
Количество одновременных соединений клиентов с системой

Вообще с системой будут работать человек 20 - 50 точно сказать пока сложно.
А вот скока активных конектов, Это вопрос Если про он-лайн говорить то стока и получается, а вот про офф-лайн щас и нескажу поэтому и спашиваю.


Цитата:
Платформа для клиента, сервера

Сервер скорей всего будет Линуксовый и СУБД там будет ORACLE(Скорее всего)
А клиент Windows.

Так что вот, решения требующие постоянный коннект отринем, а вот про GUI клиент с SOAP ,поподробнее бы где узнать (хоть как расшифровываются абравиатуры).
Автор: v0yager
Дата сообщения: 02.06.2003 10:03
ОК, двигаемся дальше.

Подведем промежуточные итоги:

Система клиент-сервер, в основном ориентированна на ввод данных, требуется встроенная система безопасности, с низкими требованиями к масштабируемости (20-50 пользователей), желательно с возможностью работать в офф-лайне, времени на разработку - 6 мес. Серверная платформа - предположительно Linux, клиентская - точно Windows. Опыт создания распределенных приложений - в процессе получения


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

Успех/неуспех попытки создать приложение с поддержкой работы в оффлайне в значительной степени зависит от требований к схеме работы с данными (сегментации данных). Если пользователь модифицирует "свои" данные и посылает запросы на получение общих статических (или редко изменяемых) данных, то с офф-лайном легче. Если нужно посылать запросы поиска (изменения) по всему массиву данных - будет сложнее.

Дополнительные вопросы:

Нарисуй схему данных и проведи ее анализ в разрезе действий одного типичного пользователя. Попробуй описать (в следующем посте) распределение затрат времени пользователя по категориям операций:
1. работа со "своими" данными
2. работа (чтение) с общими "статическими" данными
3. работа (чтение) с "чужими" изменяемыми (не статическими) данными.

Как территориально распределяются пользователи? По одному, группами по n-m человек? Если группами, то есть ли в удаленных офисах администраторы? Если группами, то есть ли возможность установить связь с удаленным офисом и выполнять администрование удаленно?

Насколько жестки требования к безопасности? Нужно ли вести журнал аудита? Насколько детально?

К техническим аспектам:

Поддержку офф-лайн в твоем случае можно сделать как минимум двуми методами:

1. Вспомогательная локальная база данных на клиенте, используется для кеширования и хранения (накопления) промежуточных данных, сихронизация с основной базой - ВЫПОЛНЯЕТСЯ НЕПОСРЕДСТВЕННО ПРИЛОЖЕНИЕМ. Локальная и основная БД могут быть разными, между собой они непосредственно не взаимодействуют.

2. Вспомогательная локальная база данных на клиенте, используется для хранения и обработки подмножества данных из основной БД, сихронизация с основной базой - ВЫПОЛНЯЕТСЯ МЕХАНИЗМАМИ БАЗЫ ДАННЫХ - РЕПЛИКАЦИЕЙ. Локальная и основная БД должны поддерживать между собой репликацию (непосредственно или с помощью доп. продуктов).

Если нет опыта работы с репликацией или есть несовместимость по репликации локальных и основной БД, то вариант 2 лучше отложить.

Идея приложения:

Допустим, что основное время пользователь тратит на ввод новых данных, поиск выполняется редко, но по всему массиву данных. Тогда можно установить локальную БД (например, бесплатный MSDE 2000) и создать GUI приложение (обычное приложение с формами из 2-х уровневой арх. клиент-сервер). Для ввода данных приложение будет работать с локальной БД, для поиска - соединяться с основной БД. Разумеется, соединяться не напрямую (см. дальше). По заданному расписанию (автоматически или по команде пользователя) приложение будет соединяться с основной системой и передавать новые данные, синхронизировать справочники. Доступ к данным основной БД от удаленного пользователя - через SOAP к своим бизнес-объектам в основной системе.

P.S.

SOAP - simple object access protocol, информации в интере, MSDN Library более чем достаточно. Ключевое слово - "SOAP".

Возможный инструмент создания подобного приложения - MS VS.NET, есть все необходимое, язык программирования принципиального значения не имеет. Поддержка создания распределенных приложений есть и в других инструментальных пакетах, но там я тебе помочь не смогу.
Автор: Pupsik
Дата сообщения: 02.06.2003 10:08
v0yager

Цитата:
GUI клиент с SOAP: не требует постоянного соединения (часть работы можно делать в офф-лайне),

RWSergey

Цитата:
...поиск производят практически все...


Цитата:
Так что вот, решения требующие постоянный коннект отринем, а вот про GUI клиент с SOAP ...

Интересно, а как планируется вести поиск, если СУБД offline?
Иметь локальную копию?
Или поиск нужен от случая к случаю?
Insert и update накопить на клиенте большого ума не надо...
А вот с select'ом как быть? Как часто он бывает нужен?


Добавлено

Цитата:
SOAP ...
Возможный инструмент создания подобного приложения

Delphi


Добавлено

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

Судя по этому база будет ого-го!?
Про локальную копию можно забыть?
Автор: v0yager
Дата сообщения: 02.06.2003 10:51
Pupsik

Цитата:
Интересно, а как планируется вести поиск, если СУБД offline?
Иметь локальную копию?
Или поиск нужен от случая к случаю?
Insert и update накопить на клиенте большого ума не надо...
А вот с select'ом как быть? Как часто он бывает нужен?

данных о распределении затрат времени пользователя по операциям от RWSergey пока нет, делать выводы еще рано. От этих данных, как ты правильно заметил, будет очень многое зависить. Если перед вводом каждой строки нужно делать поиск по всей основной БД - об оффлайне можно забыть.

Пока же я предполагал, что пользователь существенно больше тратит времени на ввод данных, чем на поиск (20 - 50 чел, "...но каждый месяц будет прибывать по нескольку тысяч, а то и сотен тысяч записей в разные таблицы" )

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

Цитата:
SOAP ...
Возможный инструмент создания подобного приложения
Delphi


Тоже вариант. Если ты обратил внимание, то VS.NET я упомянул только в P.S. И только для того, что бы сказать RWSergey, что вне этой среды я ему существенно помочь не смогу. Хотя выбор инструмента для него пока не принципиален, вопросов без ответов и так хватает.


Цитата:
Судя по этому база будет ого-го!?
Про локальную копию можно забыть?


Не обязательно. Речь ведь не идет о ПОЛНОЙ локальной копии. Даже в случае репликации можно настроить горизонтальное разбиение данных (например, по ключу ID-OF-REMOTE-OFFICE). А при custom-алгиритмах синхронизацию можно делать еще более "персонализированной" (учитывать роли/права пользователя, время суток, день недели...).
Автор: RWSergey
Дата сообщения: 02.06.2003 12:41
v0yager

Цитата:
К техническим аспектам:

Реплекацию я рассматривал с самого начала и здесь теория ясна поэтому я и писал раньше одно из условий задачи
Цитата:
2. не устанавливать СУБД у удалённого клиента.  


Pupsik

Цитата:
Судя по этому база будет ого-го!?
Про локальную копию можно забыть?


Конечно если вести речь о полной копии, то это уже задача репликации.


Цитата:
Возможный инструмент создания
сейчас действительно неважен, я пытаюсь найти теорию. Конечно чтобы воплотить теорию тоже нужно, чтоб руки из нужного места росли, но до реализации ещё дойдём.


v0yager

Цитата:
Как территориально распределяются пользователи?

Филиал это группа человек с разными правами.



Цитата:
работа со "своими" данными

Ндааа чо-то я как то сразу об этом неподумал. Филиал действительно может видить только тех абонентов с которыми они работают (и только они). а это существенно сужает справочник абонентов загружаемый на филиал.
Но тем не мение будет производится не только insert но update ранее введённых (расчитанных) значений.

Вся серьёзная аналитическая работа, требующая всего массива данных, будет производится в центральном офисе где связь с СУБД идет по локалке.
Автор: v0yager
Дата сообщения: 02.06.2003 13:44
RWSergey

Репликация снимается. Расшифруй, пожалуйста, утверждение:

Цитата:
2. не устанавливать СУБД у удалённого клиента.

Что при этом подразумевается? Вообще никакой БД в удаленном офисе или без полной копии?


Цитата:
Филиал это группа человек с разными правами.

Кто и как будет управлять безопасностью? Права нужно контроллировать на уровне приложения или на уровне данных?

Промежуточные итоги (итерация #2):

Система клиент-сервер, в основном ориентированна на ввод данных, пользователи объединены в рабочие группы, в пределах группы используются (вставка, изменение) чаще всего "свои" данные, массивная работа со всеми данными - в центре, требуется встроенная система безопасности, с низкими требованиями к масштабируемости (20-50 пользователей), желательно с возможностью работать в офф-лайне, времени на разработку - 6 мес. Серверная платформа - предположительно Linux, клиентская - точно Windows.

Цитата:
...Но тем не мение будет производится не только insert но update ранее введённых (расчитанных) значений.

Для того, что бы реализовывать свои custom алгоритмы синхронизации в таблицы нужно внести служебные поля: CreateTime, ModifyTime. При планировании синхронизации "измененных" (а не "созданных") данных зараннее продумай процедуру разрешения конфликтов. Пример, создана строка с ID=1, передана в центр, на следующей день - в нее в несли изменения, запустили сихронизацию - а в центре эта строка тоже изменена. Кто "прав"? Правила разрешения таких конфликтов должны быть простыми и известными ВСЕМ пользователям.

Следующее уточнение: в схеме данных должно быть учтено наличие удаленных офисов. Либо использовать в качестве РК GUID, либо вводить во все таблицы (синхронизируемые) составные ключи с ID-УДАЛЕННОГО-ОФИСА. Вариант с диапазонами значений (типа 1 - 100000 офис А, 100001 - 900000 офис Б, ...) лучше не использовать. Иначе при внесении данных из разных удаленных групп будут перекрытия.

Автор: Mamay
Дата сообщения: 02.06.2003 19:31

Цитата:
например, бесплатный MSDE 2000

он бесплатный только для разработки !!! не для разработки его использовать нельзя !!!

Добавлено
Еще есть такая штука как Borland MIDAS которая поддерживает модель портфеля - тобишь локальной копии которая от случая к случаю может коннектится к серверу и передавать/принимать обновления! Но это долгая сказка - хотя в твоем случае очень даже ничего!

Добавлено
И последнне - такие системы практически изжили себя. Тобишь - сейчас они неактуальны! По той простой причине - что в онлайне это делается и бистрее и элегантнее!
Автор: RWSergey
Дата сообщения: 03.06.2003 05:28
Mamay
Поисни

Цитата:
И последнне - такие системы практически изжили себя. Тобишь - сейчас они неактуальны!

Какие системы имелись введу. Я ж не от хорошей жизнь об офф-лайне интересуюсь, была бы возможность в он-лайне связываться так бы и делал.

Цитата:
онлайне это делается и бистрее

Иногда такой он-лайн бывает, что неясно где быстрей то

А ты давно распред. системами занимаешся, MIDAS там и всё такое.???


v0yager

Цитата:
Репликация снимается. Расшифруй, пожалуйста, утверждение

Я имел ввиду что знаю как реализовать такую систему с помощью репликаций и хотел бы узнать чтонибудь в обход оной. Система планируется на базе РСУБД ORACLE которая прекрасно может это делать. Но чтобы это организовать нужно ставить сервер ORACLE на филиале, а я бы хотел этого избежать.


Цитата:
Вообще никакой БД в удаленном офисе или без полной копии?

Не желательно но я не знаю как лучше и любые советы приму к сведению



Цитата:
Кто и как будет управлять безопасностью? Права нужно контроллировать на уровне приложения или на уровне данных?

эээээ Это надо обдумать. Oracle сам умеет это очень неплохо делать. но тогда при входе в систему должен осуществлятся коннект к серверу чтоб пройти авторизацию. А также нужно шифровать логин и пасс при передачие на сервак. Правильно я понимаю???


Цитата:

Промежуточные итоги (итерация #2):  
 
Система клиент-сервер, в основном ориентированна на ввод данных, пользователи объединены в рабочие группы, в пределах группы используются (вставка, изменение) чаще всего "свои" данные, массивная работа со всеми данными - в центре, требуется встроенная система безопасности, с низкими требованиями к масштабируемости (20-50 пользователей), желательно с возможностью работать в офф-лайне, времени на разработку - 6 мес. Серверная платформа - предположительно Linux, клиентская - точно Windows.


Вполне точно


Цитата:
в схеме данных должно быть учтено наличие удаленных офисов.

Естественно, но заведено будет отдельным полем. (ID абонента это уникальное значение)
Автор: v0yager
Дата сообщения: 03.06.2003 15:55
Mamay

Цитата:
он бесплатный только для разработки !!! не для разработки его использовать нельзя !!!

Зачем столько восклицательных знаков ? MSDE можно бесплатно использовать не только для разработки. Сомневающимся сюда http://www.microsoft.com/sql/howtobuy/msdeuse.asp.

Цитата:
И последнне - такие системы практически изжили себя. Тобишь - сейчас они неактуальны!

Онлайн предоставляет больше возможностей, чем офф-лайн, кто ж с этим спорит? У RWSergey есть вполне конкретная задача, в которой обеспечить постоянный онлайн сложно (либо вообще невозможно). Может ему нужно организовать удаленный офис в деревне Гадюкино? Возможности для онлайна нет, так что, отказаться от проекта?

RWSergey

Ситуация уточняется. Двигаемся дальше.

Для офф-лайна тебе в удаленном офисе нужна локальная БД. Что в ней будет - пока не принципиально. Но она точно нужна. Так что можеш начинать выбирать. MSDE (он таки бесплатен), Interbase, ... Вариантов много, так что подобрать подходящее решение, думаю, удастся.


Пункт 1. Дальше нужно определиться, кто, как и по какому расписанию будет выполнять синхронизацию с центром. Варианты:
1. система, автоматически по расписанию или наступлению заданного события (набрано ХХХ данных)
2. администратор, на основании утвержденных процедур и правил
3. пользователь с соответствующими правами, на основании утвержденных процедур и правил

Пункт 2. Кроме синхронизации необходимо решить, требуется ли пользователям поиск по ВСЕМ данным (центральная БД) или только по СВОИМ+СПРАВОЧНИКИ? Если нужен поиск по центральной БД, то как они будут соединяться с ней?

Пункт 3. Пока вырисовывается следующие два варианта (делай поправку на символьную графику , вид от удаленного клиента:

Клиент --->
...Локальный сервер бизнес-логики --->
......{локальная БД,
......центральный сервер бизнес-логики ---> центральная БД}

Клиент --->
...{Локальный сервер бизнес-логики ---> локальная БД},
...{Центральный сервер бизнес-логики ---> центральная БД}

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


О системе безопасности

С большой степенью вероятности тебе подойдет смешанная модель безопасности: ролевая (контроль функций) + упрощенная дискретная (контроль доступа к данным).

Ролевая составляющая ответственна за решения "может ли пользователь роли Х выполнить операцию Y", упрощенная дискретная "если пользователь из роли Х может выполнить операцию Y, то может ли он выполнить ее над данными Z".

Это пока общая схема.

Пункт 4. При реализации СБ нужно определиться с технологиями:
- использовать системные возможности (>= MS WIN 2K PRO + MS WIN 2K SRV DC, или что-то другое с похожими возможностями) + свои отдельные модули
- написать полностью свою прикладную систему безопасности с хранением данных в БД

В любом случае часть СБ тебе придется делать самому (как минимум контроль доступа к "строкам" таблиц).

Если есть желание использовать по максимуму системные возможности, то для ролевого контроля на серверах бизнес-логики (middleware) можно использовать >=WIN 2K + COM+ rolebase security или .NET rolebase security. Учетные записи при этом будут храниться в Active Directory (решение имеет свои радости и печали )

О других платформах ничего сказать не могу, хотя и там, навервное, есть аналоги.

При полностью своей разработке все данные СБ будут храниться в локальной БД и, при необходимости, синхронизироваться с центром.

После того, как ты определишся с выбором по пунктах 1-4, можно будет двигаться дальше.
Автор: RWSergey
Дата сообщения: 05.06.2003 06:05
v0yager

Как я понимаю получается пока два решения по доступу к данным
1. репекация
2. некая облекчённая фриварная субд на удалённых участках.

Цитата:
Пункт 1.

Думаю лучше на автомате. Поробую снизить админскую работу до минимума.


Цитата:
Пункт 2.

Получается что только по СВОИМ+СПРАВОЧНИКИ если по всем то тока репликация остаётся. Да и не нужно 1 участку знать что делает другой.


Цитата:
Пункт 3.

Поясни чото недопанял схему, что {} обозначают.


Цитата:
О системе безопасности

Да думаю этого пока достаточно.


Цитата:
Пункт 4.

Здесь думаю надо подумать.
Если бы работать в он-лаине то можно воспользоваться системой безопасности в Oracle которая. А так придётся чтото своё делать. ???

Автор: v0yager
Дата сообщения: 05.06.2003 15:51
RWSergey

Цитата:
Как я понимаю получается пока два решения по доступу к данным
1. репекация
2. некая облекчённая фриварная субд на удалённых участках.

Метод доступа к данным при использовании офф-лайн режима, на самом деле, один. Это доступ к локальной БД. Методы синхронизации между локальной и центральной базами данных - вопрос отдельный. Какой метод тебе больше подойдет, тот и выберешь.

Выбор же платформы для локальной БД пока не важен, главное, что бы тебе было удобно ее использовать (из программы) и администрировать.

Пока давай выделим два вопроса: "какие данные нужны локально" и "как синхронизировать локальные данные с центром".

Цитата:
Пункт 2.

Получается что только по СВОИМ+СПРАВОЧНИКИ если по всем то тока репликация остаётся. Да и не нужно 1 участку знать что делает другой.

Если сегменты данных для участков изолированны - то это только к лучшему. Обращаю снова твое внимание - репликация к количеству локальных данных прямого отношения не имеет (см. выше).

Кроме того, можно реальзовать поиск по центральной БД из удаленного офиса без локального кеширования данных. Об этом - дальше.

Цитата:
Пункт 3.
Поясни чото недопанял схему, что {} обозначают.

(исходя из твоего первого поста - архитектура трехзвенная):

в первом случае: клиент обращается только к локальному серверу бизнес-логики (ЛСБЛ), а дальше ЛСБЛ работает с локальной БД и, при необходимости, центральным сервером бизнес-логики (который, в свою очередь, работает с центральной БД).

во втором случае: клиент обращается как к ЛСБЛ, так и напрямую к центральному серверу бизнес-логики.

Некоторые различия между этими вариантами я описал в предыдущем посте. Рекомендую остановиться на первом варианте.

Цитата:
Пункт 4.

Здесь думаю надо подумать.
Если бы работать в он-лаине то можно воспользоваться системой безопасности в Oracle которая. А так придётся чтото своё делать. ???

В трехзвенной архитектуре (да и без нее собственно) одной системой безопасности БД не обойдешся. Часть (см. мой предыдущий пост) придется делать самому.

Если у тебя по всей компании (с учетом удаленных офисов) развернут Active Directory, то можешь рассматривать вариант создания интегрированной системы безопасности (сервисы ОС + свои модули).

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

Пока все. Куда и как двигаемся дальше?

Автор: Mamay
Дата сообщения: 05.06.2003 16:21
Ладно с msde я ошибся - признаю читал между строк!

MIDAS`ом и щас занимаюсь!

если что я в irc.lucky.net на канале #delphi

Милости просим !!!

Автор: RWSergey
Дата сообщения: 11.06.2003 04:09
Проподу на недельку.
У меня дочь родилась 3800, 55. Во как ))
Автор: v0yager
Дата сообщения: 11.06.2003 08:36
RWSergey

Поздравляю. Как только снова сможешь думать о распределенных системах и забыть на время о памперсах/пеленках - возвращайся. Продолжим.

Удачи!
Автор: Mamay
Дата сообщения: 13.06.2003 13:56
RWSergey
Мои поздравления!
Автор: RWSergey
Дата сообщения: 21.06.2003 07:03
Всем привет спосибо за отзывы, ценю.

Чтоже вернёмся к нашим "баранам".

v0yager

Цитата:
Кроме того, можно реальзовать поиск по центральной БД из удаленного офиса без локального кеширования данных

Можно но клиент в он-лайне должон быть. ??


Цитата:
клиент обращается только к локальному серверу бизнес-логики (ЛСБЛ), а дальше ЛСБЛ работает с локальной БД и, при необходимости, центральным сервером бизнес-логики (который, в свою очередь, работает с центральной БД).


А если так : клиент обращается только к локальному серверу бизнес-логики (ЛСБЛ), а дальше ЛСБЛ работает с локальной БД и, при необходимости с центральной БД.


Цитата:
О системе безопасности


Вот здесь у меня совсем слабовато. Как Active Directory можно использовать для организации безопасности программы. Мож где почитать об этом можно?? (Электронно).
Автор: v0yager
Дата сообщения: 21.06.2003 16:18
RWSergey

Цитата:
Кроме того, можно реальзовать поиск по центральной БД из удаленного офиса без локального кеширования данных...

Можно но клиент в он-лайне должон быть. ??


Клиент при этом общается с локальным сервером бизнес-логики. ЛСБД, при необходимости (!если запрос не может быть разрешен локально!), делает запрос в центр. С точки зрения центра, клиент не в он-лайне.


Цитата:
А если так : клиент обращается только к локальному серверу бизнес-логики (ЛСБЛ), а дальше ЛСБЛ работает с локальной БД и, при необходимости с центральной БД.


Тоже вариант. Но не рекомендую. Причин тому много, остановимся пока на безопасности и сопровождаемости.

Безопасность: открывать доступ напрямую к БД из Сети (даже с VPN) - не лучшая идея. Слишком много угроз безопасности, защитить бизнес-объект с десятком-другим методов намного дешевле и проще, чем сервер БД. Дополнительно в бизнес-логику можно встроить гибкие (возможно сложные, с аудитом) правила проверки безопасности - котроль по IP, времени суток, дне недели, ID удаленного офиса, параметрах запроса и т.д.

Сопровождаемость: при наличии промежуточного слоя с бизнес-объектами степень зависимости ПО удаленных офисов от центра снижается. Допустим, изменилась структура центральной БД либо бизнес-правила обработки запросов. При прямом соединении удаленных офисов с центральной БД нужно обновлять ПО во всех удаленных офисах. При соединении через центральный сервер бизнес-логики - только его (в большинстве случаев, хотя могут быть и исключения). Стоимость сопровождения в случае с работой через центральный сервер бизнес-логики ниже, скорость внесения изменений в систему - выше.


Цитата:
Как Active Directory можно использовать для организации безопасности программы.

Одна из первых задач, которую нужно решить при разработке системы безопасности, это "Где будут храниться учетные записи пользователей?" Варианты: БД, ActiveDirectory, текстовые файлы, и т.п. С AD можно работать через ADSI, хранить списки пользователей, определения групп, данные о членстве пользователей в группах. Теперь ложка дегтя: AD - с точки зрения DTC не транзакционный ресурс (нельзя объединить модификацию БД и AD в одну транзакцию), в общем случае нельзя при backup'е ("почти" одновременном) AD и БД (и последующем восстановлении) гарантировать целосность и непротиворечивость данных. ADSI для прикладных систем безопасности хорошо применять тогда, когда на предприятии ОЧЕНЬ много учетных записей пользователей и на всем предприятии УЖЕ РАЗВЕРНУТ AD. Тогда стоимость управления каталогом пользователей будет ниже, чем при хранении отдельного каталога в БД (регистрация новых пользователей, пароли и т.д.).

В твоем случае, с большой степенью вероятности, для хранения каталога пользователей системы лучше использовать БД.

Что касается "почитать", то в обобщенном виде мне подобная информация не встречалась. Если на что-то наткнусь - пришлю.

Страницы: 1

Предыдущая тема: Delphi: EOutOfResources


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.