WJПервый вариант может устроить только не очень активных пользователей, поэтому давайте говорить только о втором.

Так, на всякий случай... Вы не путаете, случайно, обмен иежду приложениями с конкурентной сетевой обработкой внутри приложения ?
WJКаждый ведет свою группу атрибутов. Но СУБД-то три. Полный справочник где хранится?

Если обобщенное представление никем не используется, то, очевидным образом, нигде кроме "центра интеграции" оно и не существует.

WJА то я так и не добился ответов на большинство своих вопросов к сторониикам BPM в паралельной ветке...Может просто плохо искали? Что-то ж Вам ответить пытались;-)[/quot]
Да ничего я не искал - просто читал, что отвечают. Получилось три ответа:
- потому-что
- когда-нибудь пригодится
- XML - это круто
Интересно, дающие такие ответы когда-нибудь писали технико-экономическое обоснование ?

процИнтеграция на уровне данных:
Только чтение:
ничего лучше view пока не придумали. использование функций во view позволяет делать любые преобразования "на лету"
Полный доступ:
1. прямая запись в "чужие" таблицы - используется в простых случаях
2. удаленный вызов "чужих" процедур - задействуется "чужая" бизнес логика - лучший вариант но кто-то должен эти процедуры написать
3. синхронизация изменений по триггерам - похоже на 2 только способ вызова другой
все 3 способа транзакционны и это главное
4. асинхронная синхронизация по сообщениям - возможна но надежность низкая

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

2 проц.
Примерно об этом наборе действий речт и идет. Но, поскольку подразумевается получение в итоге некоторого "инструмента", то предполагается, что "типовые" операции должны быть "скрыты" - например, на уровне описания связей. Что-бы не переписывать каждый раз одно и тоже, заменяя только имена объектов. Ну и всякие мелочи, вроде загрузки-выгрузки данных(для поддержки унаследованных приложений), очереди (иногда без них никак) и пр.

WJВнутри приложения - это было бы слишком просто:) А интеграция на таком уровне, чтобы юзер и не заметил, что он работает в данный момент не с одним приложением, а с другим или с двумя разными? Вы об этом и не мечтаете, да?

Это совершенно другая задача - интеграция на уровне приложений. Для нее есть соответствующие инструменты. Дело не в мечтаниях - я просто в данном случае над другой задачей работаю. При достаточно точно определенном функциональном делении потребность в интеграции на уровне приложений возникает редко - результатами работы друг друга пользуются, а вот что-бы "один за другого" работу делал, это уже ближе к экзотике.
WJЕсли бы оно не использовалось обобщенно, то вопрос об интеграции и не вставал бы. Так и жили бы на разных улицах.

Если есть приложение использующее обощенное представление (т.е. обощенное представление создано из объекта данного приложения) - там оно и будет храниться. А где, собственно, проблема ?
WJИметь знания и уметь передать знания - это разные науки.
Сей очевидный факт я оспаривать не буду. Только отмечу, что они таки пытались передавать...

MainframeНасколько мне известно реализация пока нет.
По-моему, все-таки есть. И, возможно, не единственное...

Evil_GuestА если посмотреть на эту тему
Тему СОА тут уже обсуждали, в частности, в ходе обсуждения бизнес-процессов. Безусловно, какое-то место для СОА на рынке гарантировано. Сколько это будет в %%, 75 как пишут по Вашей ссылке или более другое значение - время покажет. Удобство - удобством, но при существующей политике той-же SAP никакие сервисы на рынок СМБ ее не выведут - "не по зубам" СМБ решения от SAP.

iscrafmСУБД и есть на сегодня единственная стандартизованная точка соприкосновения.
Ну все... сейчас сторонники XML-интеграции заведут свою шарманку...

АБ"База данных -- а что база данных? Файлы, байты, диски -- везде одно и то же."
У СУБД имеется то, чего нет и пока, IMHO, не предвидится у других систем - язык работы с данными , т.е. SQL. Все остальные вынуждены похвалятся "мощными визуальными средствами"...