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

MQ+Message Broker+WBIAdapters - проверенное решение
SIB+ESB+JCAAdapters+WPS(по необходимости)
...
По поводу используемых баз данных. Любой продукт "любит" базы данных от родного вендора. Для IBM это DB2, хотя может работать и на Oracle, MSSQL.

А какую БД использует MQ?? Пришел тестовый диск, попробовали поставить - все было очень прозрачно, следов установки ДБ2 не обнаружили. Правда, опыта работы с ней нет вообще...
Но интересно - в каком месте MQ использует БД? И как можно ее заставить работать на Оракле??? Смотрение в сторону MQ как раз обуславливается тем, что она готова работать и на Оракле тоже, в отличие, скажем, от БизТалк.

AwfulДля CIM (если речь идет Common Information Model) у вендоров есть специальные продукты. У SAP это MDM, у Oracle тоже что-то. У IBM не помню, чтобы был такой продукт, но можно реализовать на описанных выше продуктах.

Да, речь идет именно об этих СИМ-моделях. У Оракла пока что не нашел я продукта, поддерживающего СИМ-модели...

Awful:)
Как я уже писал и исходя исключительно из имеющейся у меня практики - BPEL лучше использовать при создании SOA решений (из предположения, что SOA это не только веб сервисы).
А SOA предполагает (это не общая точка зрения) возможность участия бизнес консультантов в процессе реализации бизнес процессов в прикладной системе. И BPEL более удобен для высокоуровнего описания процессов (причем акцент на "долго живущих" и wokflow), которое будет понятно для консультантов. Щас конечно вендоры еще и арис сверху надстраиват, а то бедным консультантам с BPEL все таки сложно.

Поэтому, если делать голую интеграцию, то лучше на голой Java

Вы знаете, я почитал интересное обсуждение в одной из веток SQL.RU, ссылка на которое имеется выше, и сделал для себя несколько интересных (вроде бы правильных) заключений.
В разрабатываемой нами системе по всей видимости нет необходимости чего-то рисовать, привлекать бизнес-аналитиков для рисования бизнес-процессов. Более того, разрабатываемая система не предполагает ПОСТОЯННОГО участия человека в процессе интеграции.
Предполагается простейшая ситуация (пусть описываю грубо, но пусть будет таким образом). Есть, скажем, система закупки, которая опирается на данные о наличии того или иного товара. Эта информация имеется в системе складского учета. НО эти две АС никак не связаны, кроме как девочкой, которая открывает два АРМа и путем копи-паст сверяет данные из двух систем. Так вот! Предполагается, что на основе разрабатываемой платформы юзверю не прийдется тыкаться во все подряд АС на предприятии. Как минимум, вновь внедряемые системы будут использовать данные из других АС. Причем, о других АС они ничего не должны знать. Есть некая прослойка, которая знает все о всех. Новая система задает этой прослойке (информационной магистрали) вопрос, на который получает ответ. Сама магистраль уже будет перенаправлять запрос к нужной системе.
Ессно, требуется начальная настройка этой магистрали-прослойки. Дописывание адаптеров к новым системам. Адаптация старых систем (чтоб, в идеале, они тоже могли пользоваться этой самой шиной данных).
Речь идет о, так сказать, интеллектуальной маршрутизации запросов/ответов. И маленькой подсистемке подписки на события. Я, если честно, не вижу здесь работу для бизнес-аналитика. Чтоб рисовать бизнес-процессы. Если, конечно, я все правильно понял.

ПС: АС - автоматизированная система

Awful
Первый вариант однозначно выигрывает по цене и надежности. Второй выигрывает в технологиях и перспективах, но проигрывает в сложности.


Ну что ж, тогда временно его и возьмем во внимание.

А если не сложно - то что такое WBIAdapters?

И не в курсе ли Вы случайно, какие аппаратные требования у первой связки, хотя бы ориентировочно? Возможно ли поставить эту самую связку на одном кластере рядом с учетной системой на Оракле (впринципе железо подбиралось для учетной системы с небольшим запасом).

Awful
MQ не использует БД, данные на диске хранятся

Как жеж так... А как же система подписки, очереди, и проч и проч? А восстановление при сбое? Это что ж - в текстовых файлах надо ковыряться? Интересно... Опять же - в описании на сайте IBM сказано, что в каком-то виде MQ таки работает с БД, в частности, с Ораклом. И вот интересно - в каком же виде и для чего ей может понадобиться Оракл? Из серии того, что имеется возможность прямого доступа к данным?

Awful
У Oracle http://www.oracle.com/master-data-management/index.html
Это что - просто средство консолидации данных?
В нашем случае, это не цель.
Целью является предоставление ответа на запрос. Причем процедура получения ответа может подразумевать набор операций по обработке. Тобишь, интересуют не голые данные из многих БД, но и некая логика их обработки. Реализованная УЖЕ в имеющемся "зоопарке" :) От разных производителей.

ПС: опять же, стянуть все данные из всех систем в один сервер Оракла - это ему приговор наверное будет...


Или я что-то таки неправильно понял?

Petro123
Т.е. (в теории) изменился БП (сообщить технику о приходе на склад такого-то продукта).
Открывается БП в редакторе, разрывается стрелка поступления товара, вставляется квадрат и свойства Сообщить... и т.д.

А иначе зачем весь сыр-бор интеграции?

В том-то и дело. В нашем случае предполагается, что ничего никому не надо сообщать. Человек работает со своей системой. Например, бухучета. И, благодаря тому, что система складского учета разослала всем информацию о поступлении товара, то человек за бухучетом видит все изменения на складе. Или другая схема. Когда человек в бухучете хочет узнать, сколько у него сладких булочек на складе. Задает вопрос своей учетной системе - та переадресует вопрос в "прослойку", прослойка озадачивает систему учета, которая у нее прописана ответственной за тип запрашиваемой информации, после чего возвращает информацию в бухучет (без сохранения информации в системе бухучета - справка для каких-то текущих расчетов).

Вобщем, основная цель - то, что введено один раз, должно быть доступно во всех остальных суб-приложениях. Или "смежных" приложениях.

WJСила аналитика не в рисовании, а как раз в "интелектуальной маршрутизации". Нужен аналитик или нет - это вопрос скорее организационный (или политический). А вот нужен инструмент или нет - это уже вопрос выживания.

Что ж... Соглашусь с Вами. Что УДОБНОЕ представление (абстракция) этих самых маршрутов в виде бизнес-процессов с графиками движения - чрезвычайно удобно...

Petro123 Vadim RomanenkoПС: опять же, стянуть все данные из всех систем в один сервер Оракла - это ему приговор наверное будет...
Или я что-то таки неправильно понял?
приговора не будет. Только называться будет по другому - КИС (другой класс систем).
Правда счас она уже немодная :) на некоторое время )
PS. Да и потом "стянуть все данные из всех систем" - это как?
- копируя?
- перемещая?
ЗЫ. Всё таки надо определиться, "трогаем" мы зоопарк систем или нет.

ПС относилось к предложению посмотреть на Oracle MDM. На первый взгляд показалось, что это система для сбора данных на один сервер с многих путем прямого доступа к БД. А это нас особо не интересует. Потому и написал - что непонятно, на шо воно трЭба... Стянуть - подразумевалось конечно скопировать. может - просто неправильно понял, что такое Оракл МДМ.

Petro123 Vadim Romanenko
Например, бухучета. И, благодаря тому, что система складского учета разослала всем

======== т.е. как ОНА разослала? Кто её научил? Вы переписали её?
======== ДОписали её - адаптер, который будет слушать магистраль и складывать данные в бухучет

Когда человек в бухучете хочет узнать, сколько у него сладких булочек на складе. Задает вопрос своей учетной системе - та переадресует вопрос в "прослойку", прослойка озадачивает систему учета

====== каким образом? Как можно озадачить торговлю и склад 1С, если непереписывать её?
====== Я говорил о добавлении еще и новых систем. В которых предполагалось выполнение неких общесистемных требований. На примере пытался показать некий алгоритм работы :))

Вобщем, основная цель - то, что введено один раз, должно быть доступно во всех остальных суб-приложениях. Или "смежных" приложениях.

совет - почитайте выше ссылку на ветку. Там есть примеры объединения "не трогая приложения".
Не изобретайте велосипедов.

Параллельно с чтением ответов тут, читаю и ветку по ссылке. Но там 15 страниц, я пока добрался только до 5...

WJ2 Vadim Romanenko
Смотрите Вы в правильную сторону. BPM+SOA. Если основная потребность в интеграци, то ориентироваться на system2system BPMS, которые, в большинстве своем, уходят корнями в EAI. Сейчас у многих из них существенно подтянулась human2human часть.
Вы можете столкнуться с довольно высоким ценовым барьером для некоторых продуктов. Если ценовая составляющая играет существенную роль, то возможны более легковесные решения. Правда, в этом случае возможно придется чем-то поступиться.

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