Метка: EAI

Услуга интеграции приложений для оператора связи

Делаю презентацию для одной из предстоящих конференций. Собирая картинку по наличию услуги интеграции приложений от отечественных системных интеграторов понял, что услуга такая практически отсутствует. Нет, безусловно, любой аутсорсер готов синтегрировать вам что угодно с чем угодно, но это наверняка будет заказная разработка, т.е. путешествие по граблям. Вы можете совершить его самостоятельно, не прибегая к услугам системного интегратора, что будет дешевле.

Потребности оператора связи в интеграции приложений можно условно разбить на следующие группы: Продолжить чтение «Услуга интеграции приложений для оператора связи»

Сервисная шина и очереди сообщений

В Москве с 1958 года существовала 3-я улица Строителей, но в 1963 году её переименовали — теперь это улица Марии Ульяновой, а дом 25 по этой улице — хрущёвская пятиэтажка. В Ленинграде (Санкт-Петербурге) 3-ей улицы Строителей не существовало никогда…


Я снова про интеграцию приложений. Читал сегодня отечественный стандарт межведомственного документооборота ГОСТ Р 53898-2010 И стандарт вроде бы «правильный» на XML-е писанный и поля там всякие полезные на 53-х страницах приведены и все дела. Помнится, в конце прошлого века я всячески ратовал за появление стандартов электронных сообщений на страницах журнала Компьютера в заметке Фактор Internet в развитии систем «клиент-банк» В конце прошлого века все выглядело оптимистичней, чем в начале нынешнего. Дот-комы еще не рухнули, небо было выше, трава зеленее, социальные сайты вызывали доверие, а Филдинг еще не защитил диссертацию с названием Representational State Transfer. Что же случилось за десять с небольшим лет и почему идея стандартизации формата электронного документа больше меня не прикалывает? Да ничего важного, просто парадигма интеграции приложений изменилась. Продолжить чтение «Сервисная шина и очереди сообщений»

Приложение управления бизнес-приложениями

Чтобы понять рекурсию нужно понять рекурсию

Много слов сказано для обоснования полезности промежуточного ПО, интеграционных сред, систем управления бизнес-процессами. И количество «оппортунистических» связей между приложениями они сокращают, и интеграционные решения унифицируют и сквозные бизнес-процессы, включающие несколько приложений, реализуют.  Всё это, безусловно, важно. Но не это главное.

Уже не один год существует класс информационных систем называемый application management. Эти системы позволяют удаленно развертывать и конфигурировать приложения, мониторить состояние системы, диагностировать ошибки, управлять квотами и т.д. Развитие облачных вычислений (cloud computing) дало дополнительный импульс application management. Насколько мне известно, в Windows Azure при наступлении определенных событий, например превышении загрузки процессора выше определенной черты или увеличении количества входящих сетевых запросов, можно автоматически поднять еще одну виртуальную машину и развернуть на ней дополнительный экземпляр приложения.

Не трудно провести аналогию между системами application management и интеграционными средами и BPMS. Только вторые управляют содержательной частью бизнес-приложений. Обычно, с  бизнес-приложениями работают люди. Но по мере роста и развития информационной системы предприятия все чаще возникает необходимость заменить этих людей автоматизированными системами. Сценарии таких ситуаций следующие:

  1. Управление вводом данных. Когда возникает необходимость за ограниченный промежуток времени ввести в систему несколько десятков тысяч записей, люди становятся бессильны. До определенной степени можно расширять штат низкооплачиваемых сотрудников, занимающихся вводом, но это довольно затратный подход. Намного проще: загрузить данные подготовленные внешним приложением, например, переложить задачу ввода каких-либо запросов на партнеров и клиентов (системы self-service). Другой пример управления вводом данных – автоматическое добавление записей по событию. Многие сервисные службы создают инциденты не только по запросам пользователей, но и на основании событий систем мониторинга. (Подробнее об обработки событий см. ниже)
  2. Управление справочниками. Большинство бизнес-приложений используют справочники. Когда в различных системах ведутся разные справочники одних и тех же объектов, задача управления этими системами становится крайне сложной. Как только количество используемых систем превысит десяток – время задуматься о централизованном ведении справочников, а задачу управления справочниками возложить на интеграционную среду.
  3. Управление рабочими процессами (workflow). Сейчас трудно найти систему, внутри которой не было бы функций workflow. Однако такие workflow начинаются и заканчиваются «внутри» системы. Разделение труда между подразделениями предприятия, возможно и повышает его производительность, но в качестве цены за это формирует высоченные барьеры между подразделениями. В то же время, бизнес-процессы любого предприятия являются общими. Иногда в процессе участвуют не только подразделения одной компании, но и подразделения компаний-партнеров. Рабочии процессы – это единая сеть, требующая координации и согласованной работы. Идея бизнес-сервиса, как рабочего процесса, управляемого информационной системой была изложена мной в сообщении Программный интерфейс к бизнесу
  4. Обработка событий. На фоне всеобщего увлечения сервис-ориентированной архитектурой (SOA), управляемая событиями архитектура (even-driven architecture, EDA) осталась практически незамеченной. Однако, построение адаптивной информационной системы компании требует именно такого подхода. SOA сервисы интересны только в той степени, в которой они помогают компании реагировать на те или иные бизнес-события. Можно написать сотню сервисов, ни одним из которых никто и никогда не воспользуется. Событийный подход вносит смысл в информационную систему компании. Заставляет нас задумываться над вопросом «зачем», для каких случаев, мы разрабатываем тот или иной сервис. Перехват и маршрутизация событий, пожалуй, наиболее значимая ценность, привносимая  интеграционными средами в корпоративный ИТ-ландшафт.
  5. Обработка исключений. Однако не все события поддаются автоматической обработке. Рано или поздно возникает ситуация не предусмотренная ни в требованиях к решению, ни в спецификации взаимодействий, ни в техническом задании. Огромная ошибка заключается в том, чтоб рассматривать такую ситуацию как ошибку, записать сообщение в системный лог и остановить бизнес-процесс. С каждой такой ситуацией должен кто-то разбираться. Появившиеся ошибки это та самая обратная связь от эксплуатации к развитию, помогающая своевременно корректировать бизнес-процессы и модернизировать приложения. Вопреки распространенному мнению интеграционная среда не является «системой без пользователей». Наоборот, это система для наиболее подготовленных и эрудированных пользователей, способных анализировать исключительные ситуации как с точки зрения ИТ, так и с точки зрения бизнеса и своевременно принимать адекватные решения.

Я надеюсь, что некоторые из изложенных мною соображений, расширят арсенал аргументов в пользу использования интеграционных сред в ИТ-инфраструктуре компаний. Комментарии и дополнения, как всегда, приветствуются.

Интеграция приложений

Среда интеграции приложений – программная платформа, предназначенная для развертывания большого количества композитных [микро]приложений в стиле SOA. Существуют два основных подхода к интеграции приложений: асинхронная интеграция приложений при помощи message-oriented middleware или же просто асинхронного взаимодействия между приложениями посредством обмена файлами или записями в общей базе данных и синхронная интеграция посредством сервисной шины. Недостатком первого подхода является сложная логика интеграции из-за необходимости синхронизации состояний объектов в различных системах. Второй подход требует обеспечения высокой надежности и масштабируемости решений.

Сервис-ориентированная архитектура (SOA) – стиль разработки, минимизирующий внесение изменений в унаследованные системы за счет повторного использования существующего функционала. Ключевой момент SOA заключается в реализации каждого бизнес-процесса в виде отдельного слабосвязанного компонента. В традиционных бизнес-приложениях множество бизнес-процессов реализуются в едином монолитном решении, что затрудняет локализацию проблем, существенно повышает вызванный внесением изменений риск нарушение работоспособности и как следствие требует более тщательного проектирования, разработки изменений и, как правило, проведение полного регрессионного тестирования.
Сервисная шина (ESB) – отдельный класс платформ интеграции приложений реализующий, в отличии от традиционных интеграционных сред, не только асинхронное, но и синхронное взаимодействии. Современные сервисные шины строится на базе решений JavaEE application server
Сервер приложений (JavaEE application server) – программная платформа, предназначенная для эффективного использования серверных ресурсов (процессы, оперативная память, пулы соединений, очереди и пр.) при исполнении множества java-приложений, реализованных в виде сервисов.

SOA сервис – слабосвязанный программный компонент, предназначенный для повторного использования. В отличии от традиционных интеграционных компонент, разработанных с учетом интерфейсов интегрируемых систем и используемых для интеграции только этих систем, сервис может использоваться любыми другими новыми приложениями.
Stateless протокол – протокол взаимодействия между клиентом и сервером, запрещающий сохранение на сервере состояния клиентского соединения. Таким протоколом, например, является протокол web-сервисов HTTP. В отличии от протоколов работы с базой данных, сохраняющих состояние клиентской сессии, stateless протоколы допускают высочайшую степень масштабирования за счет возможности установки дополнительных серверов, включаемых в общую систему балансировки нагрузки.