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

Сервис должен обладать следующими свойствами:

Единая точка входа для всех приложений, которые взаимодействуют с источниками данных.

Уровень абстракции для доступа к данным.

Хороша проработанная расширяемая система прав доступа.

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

Автоматический выбор источника данных в зависимости от прав пользователей.

Механизм кэширования результатов.

Централизованные логи и статистка.

Мониторинг производительности.

Авто генерация кода.

Возможность писать плугины для подключения различных источников данных.

Уровень абстракции для доступа к данным и права доступа храниться в метабазе (СУБД). К одной метабазе можно подключить несколько сервисов. Метабаза представляет собой дерево объектов (проекты, сущности, команды, параметры, источники данных и т.д.). У каждого объекта для контроля прав доступа есть свой ACL.

Процесс разработки будет выглядеть приблизительно так:


Определение источников данных и создание их в метабазе.

Создание архитектуры приложения в терминах метабазы: проекты, сущности, команды, параметры и привязка к источникам данных.

Создание ролей, пользователей.

Раздача прав для доступа к различным объектам метабазы.

Авто генерация кода: классы на основе описания в метабазе.

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

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

мод pvsВнутри компании разрабатываются приложения, которые взаимодействуют с различными источниками данными (Oracle, SQL Server, Web-Service и т.д.).
Так не бывает, всегда есть основная БД (какая ?)

Бывает. У нас очень большое кол-во различных покупных и своих систем. Основной СУБД, наверное, все-таки является Oracle, но есть много систем и на SQL Server, плюс веб-севрисы, LDAP. Как правило нашим приложениям нужны данные сразу из нескольких систем одновременно.

WJ2 pvs
То, о чем Вы говорите - это BPM+SOA. Или скорее SOA+BPM. Слышали что-то об этом?

Да это и есть SOA. Про SOA не только слышал, но и использую :) а вот c BPM на практике плохо знаком..

Только метаданные в базе конечно не хранятся. Для этого - сервер приложений.
Спасибо за ссылку, почитаю. А почему бы не хранить метаданные в базе? Метаданные совсем не маленькие по объему, к тому же их может менять большое кол-во разрабочтиков одновременно. Здесь как-раз и напрашивается база данных.

WJВам не кажется, что вы загоняете проблему в узкие рамки - только организация доступа к данным.
Может стоит посмотреть на задачу шире?


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

В идеале наша архитектура так и будет делать выглядить :) В качестве платформы будет использован .NET, в частности для сервиса WCF. Для метабазы Oracle или SQL Server на выбор.

Ну вот как раз и есть хороший повод познакомиться:) Можно начать здесь . А можно и прямо здесь, где находитесь:)
На самом деле - и это не только мое личное мнение, но и мнение многих ведущих аналитиков - SOA без BPM - это как оркестр без дирижера.
Спасибо за сссылку - уже начал знакомиться :)

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