Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Разработка информационных систем Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
 Архитектура разработки  [new]
pvs
Member

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

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

  • Единая точка входа для всех приложений, которые взаимодействуют с источниками данных.
  • Уровень абстракции для доступа к данным.
  • Хороша проработанная расширяемая система прав доступа.
  • Приложение для управления сервисом, как для администратора, так и для разработчика.
  • Автоматический выбор источника данных в зависимости от прав пользователей.
  • Механизм кэширования результатов.
  • Централизованные логи и статистка.
  • Мониторинг производительности.
  • Авто генерация кода.
  • Возможность писать плугины для подключения различных источников данных.

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

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

  • Определение источников данных и создание их в метабазе.
  • Создание архитектуры приложения в терминах метабазы: проекты, сущности, команды, параметры и привязка к источникам данных.
  • Создание ролей, пользователей.
  • Раздача прав для доступа к различным объектам метабазы.
  • Авто генерация кода: классы на основе описания в метабазе.
  • Разработка приложения, где для доступа к данным используются классы, сгенерированные на предыдущем этапе.

    Хотелось бы услышать мнения по поводу такой архитектуры. Существует ли уже что-нибудь подобное.
  • 7 ноя 07, 04:59    [4882750]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    Alexsalog
    Member

    Откуда:
    Сообщений: 4119
    Сервер приложений. Притом есть готовые (и много).
    7 ноя 07, 05:49    [4882772]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    мод
    Guest
    pvs
    Внутри компании разрабатываются приложения, которые взаимодействуют с различными источниками данными (Oracle, SQL Server, Web-Service и т.д.).

    Так не бывает, всегда есть основная БД (какая ?)
    7 ноя 07, 09:22    [4883018]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    WJ
    Member

    Откуда: Москва
    Сообщений: 1233
    2 pvs
    То, о чем Вы говорите - это BPM+SOA. Или скорее SOA+BPM. Слышали что-то об этом?
    7 ноя 07, 09:39    [4883083]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    iscrafm
    Member [заблокирован]

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

    существует. Только метаданные в базе конечно не хранятся. Для этого - сервер приложений.

    мод
    Так не бывает, всегда есть основная БД (какая ?)

    еще как бывает
    7 ноя 07, 10:28    [4883306]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    Mainframe_старый
    Guest
    iscrafm
    Только метаданные в базе конечно не хранятся. Для этого - сервер приложений.

    еще как бывает


    Еще как бывает, это правда. А вот почему не хранить метаданные в базе ?
    7 ноя 07, 10:32    [4883331]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    iscrafm
    Member [заблокирован]

    Откуда:
    Сообщений: 35350
    Mainframe_старый
    А вот почему не хранить метаданные в базе ?

    из соображений практичности. У нас они хранятся в "объектном" виде, исключается множество действий по преобразованию.
    7 ноя 07, 10:47    [4883447]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    Mainframe_старый
    Guest
    iscrafm
    У нас они хранятся в "объектном" виде, исключается множество действий по преобразованию.

    А что значит "объектный" вид ? Откровенно сказать, мне казалось, что удобнее, чем в базе хранения метаданных не придумать ...
    7 ноя 07, 10:53    [4883484]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    iscrafm
    Member [заблокирован]

    Откуда:
    Сообщений: 35350
    Mainframe_старый
    iscrafm
    У нас они хранятся в "объектном" виде, исключается множество действий по преобразованию.

    А что значит "объектный" вид ? Откровенно сказать, мне казалось, что удобнее, чем в базе хранения метаданных не придумать ...

    объект метаданных - это некоторый посредник между СУБД и клиентами, которые работают с СУБД через него. Он содержит в себе информацию:
    - в какой СУБД размещены его данные
    - структура данных
    - описание методов чтения, обновления, удаления и т.п.
    - параметры шифрования и сжатия данных
    и т.д. и т.п.
    Выдумывать для этого монстрообразную структуру таблиц, индексов, связей и т.п. - имхо, нереально. Вернее реально конечно, с этого начинали... но на определенном уровне сложности этой структуры и закончили, надоело заниматься мазохизмом. Сейчас все просто.
    Когда сервер приложений предоставляет свой контент клиенту, он просто читает описание объектов метаданных и без всяких преобразований создает физических провайдеров методом Assign (образно).. Чтобы приложения перенести на другой сервер,достаточно скопировать один файл...да много плюсов конечно в сравнении с хранением в БД (точнее в реляционной БД).
    7 ноя 07, 11:20    [4883709]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    WJ
    Member

    Откуда: Москва
    Сообщений: 1233
    Вам не кажется, что вы загоняете проблему в узкие рамки - только организация доступа к данным.
    Может стоит посмотреть на задачу шире?
    pvs
    Внутри компании разрабатываются приложения, которые взаимодействуют с различными источниками данными (Oracle, SQL Server, Web-Service и т.д.). Для облегчения разработки предлагается разработать универсальный сервис для доступа к различным источникам данных.
    Здесь сервисно-ориентированная архитектура просто доктором прописана. Приложения (не зависимо от того, какую СУБД они пользуют) могут представлять интерес не только как источники данных. Если не уже сейчас, то очень скоро захочется обращаться не только к данным, но и к функциям тех или иных приложений. К примеру, у вас есть отдельное приложение, которое (кроме чего-то еще) формирует и печатает платежное поручение. Можно обратиться не к данным, а непосредственно к функции, которая напечатает платежку. Обратиться через веб-сервис. Когда обратиться? На том шаге бизнес-процесса, на котором это требуется. Кому обратиться? Сотруднику, входящему в ролевую группу, назначенную для этого шага (или в случае, когда шаг назначается конкретному исполнителю - он и обратится). Точнее - не он, а BPM-система сделает это за него. При этом, исполнитель не задумывается над тем, к какому приложению обратилось приложение. Он работает с одним экраном - композитным приложением, которое может на одном шаге обращаться к разным приложениям и к разным СУБД как через веб-сервисы, так и напрямую.
    В данном случае BPM играет роль дирижера, который управляет механизмами обращений и взаимодействий, встраивая имеющиеся приложения в бизнес-процессы.
    7 ноя 07, 11:44    [4883908]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    pvs
    Member

    Откуда:
    Сообщений: 11
    мод
    pvs
    Внутри компании разрабатываются приложения, которые взаимодействуют с различными источниками данными (Oracle, SQL Server, Web-Service и т.д.).

    Так не бывает, всегда есть основная БД (какая ?)


    Бывает. У нас очень большое кол-во различных покупных и своих систем. Основной СУБД, наверное, все-таки является Oracle, но есть много систем и на SQL Server, плюс веб-севрисы, LDAP. Как правило нашим приложениям нужны данные сразу из нескольких систем одновременно.
    7 ноя 07, 13:05    [4884525]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    pvs
    Member

    Откуда:
    Сообщений: 11
    WJ
    2 pvs
    То, о чем Вы говорите - это BPM+SOA. Или скорее SOA+BPM. Слышали что-то об этом?


    Да это и есть SOA. Про SOA не только слышал, но и использую :) а вот c BPM на практике плохо знаком..
    7 ноя 07, 13:09    [4884547]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    WJ
    Member

    Откуда: Москва
    Сообщений: 1233
    pvs
    WJ
    2 pvs
    То, о чем Вы говорите - это BPM+SOA. Или скорее SOA+BPM. Слышали что-то об этом?


    Да это и есть SOA. Про SOA не только слышал, но и использую :) а вот c BPM на практике плохо знаком..
    Ну вот как раз и есть хороший повод познакомиться:) Можно начать здесь. А можно и прямо здесь, где находитесь:)
    На самом деле - и это не только мое личное мнение, но и мнение многих ведущих аналитиков - SOA без BPM - это как оркестр без дирижера.
    7 ноя 07, 13:14    [4884579]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    pvs
    Member

    Откуда:
    Сообщений: 11
    Только метаданные в базе конечно не хранятся. Для этого - сервер приложений.

    Спасибо за ссылку, почитаю. А почему бы не хранить метаданные в базе? Метаданные совсем не маленькие по объему, к тому же их может менять большое кол-во разрабочтиков одновременно. Здесь как-раз и напрашивается база данных.
    7 ноя 07, 13:15    [4884588]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    pvs
    Member

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


    WJ

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


    В идеале наша архитектура так и будет делать выглядить :) В качестве платформы будет использован .NET, в частности для сервиса WCF. Для метабазы Oracle или SQL Server на выбор.
    7 ноя 07, 13:31    [4884726]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    pvs
    Member

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

    Спасибо за сссылку - уже начал знакомиться :)
    7 ноя 07, 13:33    [4884745]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    АБ
    Member

    Откуда: Тверская-Ямская
    Сообщений: 1168
    ну и до кучи стоит еще познакомиться с терминами composite application и mashup.
    7 ноя 07, 14:09    [4885025]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    Mainframe_старый
    Guest
    Вообще говоря, если нужны сразу данные из разных баз данных, то это другая проблема, и архитекура SOA или там BPM - это частный вопрос (в армках этой задачи). У вас задача встает по-другому - как интегировать данные на лету, причем на высоком уровне абстракции, не загоняя в одну веб-службу несколько запросов к разным базам, причем жестких запросов, а сделать гибкий подход. Это уже область интеграции данных по требованию. Если возможно, в такие дебри лучше себя не загонять и обойтись более простой постановкой задачи. У Американцев занимается этим группа Alen Halevay, у наших - Антипин К.В., Фомичев А.В., Гринев М.Н., Кузнецов С.Д., Новак Л.Г., Плешачков П.О., Рекуц М.П., Ширяев Д.Р.. Оперативная интеграция данных на основе XML: системная архитектура BizQuery//Труды Института системного программирования РАН 2004 г. http://www.citforum.ru/internet/xml/bizquery/
    7 ноя 07, 14:10    [4885031]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    Awful
    Member

    Откуда:
    Сообщений: 51
    с BPM это жестко все таки, достаточно ESB будет
    а лучше вот это
    http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/aqualogic/data_services/
    или
    http://www-111.ibm.com/ecatalog/Detail.wss?locale=ru_RU&synkey=J106029J33633I56
    у других тоже вроде есть
    7 ноя 07, 16:17    [4886098]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    Lunx
    Member

    Откуда:
    Сообщений: 539
    Прочитал про искру. Точно то же самое мне рассказывали кашисты. Они как раз позиционируют свой продукт (Летограф что-ли) как интегральное управляющее ядро для всех ИТ систем, при этом у них даже что-то типа сертифицированного ODBC драйвера для SAP есть. Я вообще никак к каше не отношусь (не реклама), но идея делать интеграцию на workflow кажется мне разумной. Вообще - правильно начинать с workflow - это систематизирует.
    7 ноя 07, 16:47    [4886430]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    iscrafm
    Member [заблокирован]

    Откуда:
    Сообщений: 35350
    Lunx
    что-то типа сертифицированного ODBC драйвера для SAP есть.

    c SAP работаем через IDOC. Напрямую к базам через ODBC думаю не стоит в такую систему влазить. имхо.
    7 ноя 07, 16:54    [4886504]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    WJ
    Member

    Откуда: Москва
    Сообщений: 1233
    Awful
    с BPM это жестко все таки, достаточно ESB будет
    а лучше вот это
    http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/aqualogic/data_services/
    или
    http://www-111.ibm.com/ecatalog/Detail.wss?locale=ru_RU&synkey=J106029J33633I56
    у других тоже вроде есть
    BPM - жестоко, а голая ESB - это в самый раз?:) Легких путей не ищем, так? А как с ролевыми группами, с единой точкой входа и т.д.?
    7 ноя 07, 17:06    [4886622]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    мод
    Guest
    pvs
    Бывает. У нас очень большое кол-во различных покупных и своих систем. Основной СУБД, наверное, все-таки является Oracle, но есть много систем и на SQL Server, плюс веб-севрисы, LDAP. Как правило нашим приложениям нужны данные сразу из нескольких систем одновременно.

    Каждая покупная система работает со своей БД и только ваши собств. с разными. Я бы сделал БД оракле основной и прицепил к ней все остальные. Т.о. ваши приложения видели бы только одну БД. Т.е. использовать оракле как ср-во интеграции.
    7 ноя 07, 17:19    [4886767]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    АБ
    Member

    Откуда: Тверская-Ямская
    Сообщений: 1168
    Lunx
    правильно начинать с workflow - это систематизирует
    Есть и более весомый довод: у большинства бизнес-руководителей workflow вызывает самый живой интерес. Объясняется это тем, что схема бизнес-процесса в типовой BPM-системе соответствует той "картинке" бизнеса, которую они рисуют в голове или на клочке бумаги. Workflow предлагает сделать эту картинку исполняемой, т.е. без искажений довести ее до каждого исполнителя - фантастика! Это порождает энтузиазм с их стороны, выливающийся в поддержку проекта - и моральную, и бюджетную. Заручившись этим энтузиазмом, ИТ получает шанс "заодно" реализовать и необходимую инфраструктуру в виде SOA и ESB. Как советуют умные люди, "если хотите реализовать SOA - не называйте то, что вы собираетесь сделать, SOA". То же справедливо по отношению к любой "прогрессивной" ИТ-архитектуре: ищите аргументы для бизнеса. В случае SOA такие аргументы - BPM и процессный подход к управлению.
    7 ноя 07, 17:23    [4886806]     Ответить | Цитировать Сообщить модератору
     Re: Архитектура разработки  [new]
    pvs
    Member

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

    Основоные покупные системы у нас, как правило, взаимодействуют с друг другом и работают не только со своей СУБД.
    8 ноя 07, 02:38    [4888231]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
    Все форумы / Разработка информационных систем Ответить