ВМоисеев
Пожалуйста, не горячитесь. Не сбивайтесь на ликбез и не стремитесь показать знания общих вопросов. Не обижайтесь, а покажите изюминки именно Вашего подхода к построению информационных систем. Имейте ввиду - среди Ваших коллег уже есть вполне убежденные (и вполне вменяемые ) в том, что системы на основе распределённых сервисов имеют право на существование.
Думаю, что вызов метода удаленного сервиса (располагающегося в локальной и/или глобальной сети) с возвратом результата или ошибки, это то что минимально необходимо для построения подобных систем. Какая инфраструктура предоставляет подобный минимум - вопрос вторичный, правда, если дело не касается взаимодействия гетерогенных инфраструктур. В данном вопросе я определенные надежды возлагаю на моно.
Иногда этот вызов может быть транзитивным (у меня так) - между сервисом, генерирующим сообщение-запрос, и сервисом, генерирующим сообщение-ответ, может находится промежуточный сервис. Сообщения шифруются. Промежуточный сервис не должен иметь воэможности шифрования. Следствие - сообщения (у меня) это byte[]. Работа с защищенными каналами в практическом плане - бо-о-о-льшая возня.
В некоторых задачах, где на нижнем уровне имется локальная сеть или всего один компьютер, а транспортный канал (интернет) работает не стабильно, работа с единой точкой входа не представляется возможной.
С Вашим подходом обязательно ознакомлюсь, очень интересно.
Попробую раскрыть особенности нашей архитектуры:
Основная часть системы - это метабаза. Метабаза представляет собой дерево объектов
(Решение -> Проект -> Сущность -> Команда-> Параметр). Также в метабазе хранятся описание источников данных, роли и пользователи.
По умолчанию, в качестве ролей и пользователей используются группы и пользователи Windows. Но можно настроить свой провайдер, например, хранить пользователей и их роли в какой либо СУБД.
Каждый из объектов метабазы имеет свой ACL.
Источник данных – представляет собой объект, в котором хранятся необходимые данные (Провайдер, Строка соединения и другие параметры) для подключения к СУБД или другим источникам данных.
Для того чтобы, обращаться к данным - каждый из объектов (Решение -> Проект -> Сущность -> Команда) может иметь одну или несколько ссылок на источник данных.
Ссылка на источник данных представляет собой объект в котором помимо самой ссылки на источник может хранится часть строки соединения к источнику данных.
Если, например, у команды нет ссылок на источники данных, то используются ссылки на источники из сущности, если и там нет то из проекта, и в конце если нет нигде то из решения. Если у объекта больше чем одна ссылка на источник и пользователь имеет к ним доступ, то используется ссылка с наибольшим приоритетом.
У ссылки на источник данных может быть одно или несколько соединений. Соединение – объект метабазы которой может храниться часть строки соединения к источнику данных.
Соответственно если их несколько, ты выбирается соединение с наибольшим приоритетом доступное данному пользователю.
Обращение сервису представляет вызов метода Execute где одним из параметров является строку запроса (которая собственно и определяет что мы хотим получить) следующего вида:
[Ссылка на источник данных].[Соединение].[Решение].[Проект].[Сущность].[Команда]
Строка запроса может иметь и такой вид (наиболее часто используемый):
*.*.[Решение].[Проект].[Сущность].[Команда]
- в таком случае источник данных и соединение выбирается автоматически в зависимости от прав пользователя и приоритета объектов. Естественно, чтобы запрос к сервису выполнился у пользователя должен быть права на решение, проект, сущность и команду. А также права и на параметры команды, которые он хочет задать, иначе будут использоваться для значения параметров по умолчанию.
Пример можно посмотреть по
ссылке
Мне кажется он, достаточно наглядно показывает преимущества нашего подхода.
