Попинайте архитектуру, заодно и подскажите чего-нить...
От: _Sphinx_ Россия http://www.rogov.su
Дата: 25.12.06 19:19
Оценка:
Всем привет! Решил посоветоваться с народом, чувствую, что недостаточно хорошо разбираюсь в теме...

Предполагается создание многомодульной системы. Технологически предполагается, что вся система (как минимум — основные интерфесы и проч.) будут под .NET. Модули разделяются на несколько категорий, например, модуль (в данном случае, они называются службами) упаковки данных, служба шифрования, служба передачи данных по сети и т.д. и т.п. в общем, категорий много, самих служб — еще больше. Службы могут пользоваться друг другом. Например, если сетевой службе надо передать, то она может (и должна) зашифровать данные с помощью службы шифрования, упаковать с помощью службы упаковки и потом самостоятельно отправить... То, какие службы пользуются какими и для каких целей — настраивается динамически в параметрах каждой службы. Т.е. если имеется несколько разных служб шифрования, реализующих, например, разные алгоритмы, то должна быть возможность банально из списка выбрать нужную и ей пользоваться. Хранение конфигурации и способ ее изменения — сугубо личное дело каждой службы. Помимо служб есть еще и приложения — т.е. GUI с которыми и работает пользователь. Они также пользуются службами (например, для распаковки данных). Интерфейсы служб разных типов и т.д. описаны в одном большом и общем ядре...

Графически это можно представить примерно так:


Предлагается следующее:
Каждой службе присваивается некий уникальный идентификатор. Во время установки, служба регистрируется в ядре. Во время регистрации указывается общая информация о службе: ID, категория и т.п. После этого к службе можно обращаться по ее идентификатору. В ядре есть менеджер этих самых служб, который знает все о своих службах, умеет их запускать, останавливать и т.д... Работать это должно примерно так: в ядре описыватся базовый интерфейс службы указанной категории. В службе реализуется класс, который реализует этот интерфейс. Во время запуска службы, создается экземпляр этого класса... Дальше, думаю, понятно... Когда кому-то (службе или приложению) нужно обратиться к другой службе, она обращается к менеджеру служб и просит его дать указатель (ссылку или т.п.) на объект этой службы. Менеджер смотрит — если служба уже запущена (загружена), то возвращает имеющийся указатель, если нет — запускает и возвращает. Таким образом, в памяти всегда загружены только те, службы, которые реально кем-то использовались, и каждая — только один раз.

Дальше, ядро само по себе штука большая... Ввиду специфики проекта, есть набор стандартных задач, которые трудно классифицируемы, и есть идея реализовать их в ядре и дать возможность другим службам и приложениям ими пользоваться. Этакий собственный мини-API (мини-фреймворк). На одной машине может работать много служб и много приложений. А ядро, как понятно, должно быть одно на всех...

Вот, теперь вопросы:
1. Мне кажется, что я что-то придумал неправильно... Подскажите
2. Что вообще в такой архитектуре плохого, а что — хорошего. Какие могут реально возниктнуть проблемы?
3. Как лучше реализовать ядро? Была мысль сделать его системной службой (Windows Service), но я сервисов никогда толком не писал, и никак не пойму, подойдет мне это или нет. Если нет, то как тогда это лучше сделать?
4. Службы я предполагаю сделать как отдельные .NET сборки и грузить каждую в свой AppDomain для повышения надежности. Стоит так делать или нет? Если нет, то как стоит и почему?
5. А может у вас есть идея как такую же задачу вообще по-другому решить? Поделитесь, пожалуйста...

Заранее всем спасибо
ICQ: 203-009-172
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.