Comments 6
Цикл статей будет теоретический?
Будете рассматривать какие-то конкретные технические схемы?
Очень интересна тематика отказоустойчивости интеграционных решений.
Будете рассматривать какие-то конкретные технические схемы?
Очень интересна тематика отказоустойчивости интеграционных решений.
Если хватит времени и сил, то и теорию и примеры практического применения опишу, в том числе, хитрые, как межсерверные вызовы веб-сервисов с применением лонг-пулинга и случаи интеграции с метапрограммированием.
Если уж речь пошла про N(N-1) связей в случае двухсторонних коннекторов — то наверное стоит рассказать и про централизированную интеграцию через ESB/подобное, и вообще поподробней рассказать о различных топологиях интеграции.
Согласен, но просто все сразу не успеваю. Я сделал классификацию толькл факторов и методов, а еще нужна классификация архитектур: (1) базе сервисов — SOA, (2) архитектура с общей шиной — ESB, (3) интеграция с использованием репликаций БД, (4) событийно-ориентированная, (5) потоковая, (6) сигнальная или message-oriented, (7) интеграция на базе броекров запросов, (8) не знаю деже, стоит ли сюда включать облачную (это не столько архитектура, как технология), ну и старые: (9) файл-серверная, (10) клиент-серверная. Потом топологии взаимодействия рассмотреть: звезда, иерархия, кольцо, сеть, шина. Принципы зваимодействия: pool, push, message, event, hub, broker, multicast, bus. Кстати, нет же ж ни кгде толковой методички, где все вопросы по интегрции собраны и при этом было все сжато и кратко, только по существу. Все это разбросано по разным источникам, каждый только за свою архитектуру проповедует, поэтому тут еще на страницы 3 нужно дописать. Если еще есть коррективы, прошу добавлять, хочется собрать по архитектуре и программной инжинерии такой полный обзор.
Поступили вопросы по теме от Оскара Бостонова, ответы публикую:
Я рассматриваю только информационные системы. Единого определения нет, и это потому, что задачи интеграции всегда очень разные, иногда хватает раз в сутки передать одно число из системы в систему, а иногда нужно в приближении к реальному времени синхронизировать таблицу из 900 ячеек между 2500 пользователями, часть из которых находится в одной системе, а часть в другой, еще и обсчитывая что-то на сервере.
Интеграция — это любое взаимодействие между системами с помощью общих для них форматов данных или форматов вызовов, когда происходят прямые межсистемные запросы или обмен данными, в т.ч. через пользователя (выгрузил в файл, потом загрузил в другую систему) или репликации СУБД. Более точные определения есть для понятий «интеграция на уровне данных», «интеграция на уровне вызовов».
Бизнес-процессы это часть информационной модели, а информационная система поддерживает хранение, передачу и обработку всех данных модели, не зависимо от того, представлены ли бизнес-процессы декларативными структурами в базе данных или интерпретируемыми скриптами или откомпилированным программным кодом.
Я различаю эти две архитектуры по способу взаимодействия (но это единственный взгляд на вопрос):
1. Событийное взаимодействие (принцип push): одна сторона устанавливает продолжительное соединение с другой стороной, т.е. первый признак это взаимодействие с установлением соединения, а второй — это подписка на события, т.е. односторонняя подписка или обоюдная и потом по соединению приходят события сразу как они происходят на удаленной стороне.
См. так же http://en.wikipedia.org/wiki/Push_technology
2. Сигнальное взаимодействие (принцип pull): одна сторона хочет узнать о состоянии другой, и периодически делает запросы, т.е. нет постоянного соединения, а сигналы поступают через периодические вызовы.
См. так же http://en.wikipedia.org/wiki/Pull_technology
Это задача глобальной онтологии, она одновременно и абсолютно необходима и абсолютно недостижима. Если вопрос про интеграцию информационных систем, то это значит, что нам нужна универсальная информационная модель реальности, подходящая для всех возможных задач, но это противоречит понятию модель, как упрощенному представлению чего либо, а значит есть мера упрощенности (более детализировано, менее детализировано, или акцент на разных аспектах). Так вот для одних задач нужны совсем простые модели или очень обобщенные, а для других сложные или очень детализированные, а если у нас будет одна модель, то мы будем решать все задачи на информационной модели не адекватной решаемой задаче.
С другой стороны, я не исключаю возможности создания универсальной модели в которой каждый объект имеет несколько связанных «аспектов» (подмоделей, представлений или проекций). Или проекция полной модели на каждую задачу происходит динамически в момент выполнения.
1) Какое определение вы используете для терминов ИНТЕГРАЦИЯ и ИНТЕГРАЦИЯ ИНФОРМАЦИОННЫХ СИСТЕМ?
Я рассматриваю только информационные системы. Единого определения нет, и это потому, что задачи интеграции всегда очень разные, иногда хватает раз в сутки передать одно число из системы в систему, а иногда нужно в приближении к реальному времени синхронизировать таблицу из 900 ячеек между 2500 пользователями, часть из которых находится в одной системе, а часть в другой, еще и обсчитывая что-то на сервере.
Интеграция — это любое взаимодействие между системами с помощью общих для них форматов данных или форматов вызовов, когда происходят прямые межсистемные запросы или обмен данными, в т.ч. через пользователя (выгрузил в файл, потом загрузил в другую систему) или репликации СУБД. Более точные определения есть для понятий «интеграция на уровне данных», «интеграция на уровне вызовов».
2) Что вы понимаете под ИНФОРМАЦИОННОЙ СИСТЕМОЙ только программно-аппаратную часть или бизнес-процессы тоже?
Бизнес-процессы это часть информационной модели, а информационная система поддерживает хранение, передачу и обработку всех данных модели, не зависимо от того, представлены ли бизнес-процессы декларативными структурами в базе данных или интерпретируемыми скриптами или откомпилированным программным кодом.
3) Чем отличается событийно-ориентированная и сигнальная архитектура?
Я различаю эти две архитектуры по способу взаимодействия (но это единственный взгляд на вопрос):
1. Событийное взаимодействие (принцип push): одна сторона устанавливает продолжительное соединение с другой стороной, т.е. первый признак это взаимодействие с установлением соединения, а второй — это подписка на события, т.е. односторонняя подписка или обоюдная и потом по соединению приходят события сразу как они происходят на удаленной стороне.
См. так же http://en.wikipedia.org/wiki/Push_technology
2. Сигнальное взаимодействие (принцип pull): одна сторона хочет узнать о состоянии другой, и периодически делает запросы, т.е. нет постоянного соединения, а сигналы поступают через периодические вызовы.
См. так же http://en.wikipedia.org/wiki/Pull_technology
4) Не рассматриваете ли вы вопрос семантической интеграции и глобальной целостности данных?
Это задача глобальной онтологии, она одновременно и абсолютно необходима и абсолютно недостижима. Если вопрос про интеграцию информационных систем, то это значит, что нам нужна универсальная информационная модель реальности, подходящая для всех возможных задач, но это противоречит понятию модель, как упрощенному представлению чего либо, а значит есть мера упрощенности (более детализировано, менее детализировано, или акцент на разных аспектах). Так вот для одних задач нужны совсем простые модели или очень обобщенные, а для других сложные или очень детализированные, а если у нас будет одна модель, то мы будем решать все задачи на информационной модели не адекватной решаемой задаче.
С другой стороны, я не исключаю возможности создания универсальной модели в которой каждый объект имеет несколько связанных «аспектов» (подмоделей, представлений или проекций). Или проекция полной модели на каждую задачу происходит динамически в момент выполнения.
Sign up to leave a comment.
Интеграция информационных систем