Возвращаюсь к теме интеграции корпоративных информационных систем, начатой в конце июня этого года с сообщения об интеграции посредством СУБД. Как и обещал, рассказываю про более эффективные способы интеграции данных. Вообще, причина возникновения этой темы обусловлена современными(правильней сказать уже не столь современными) технологиями управления базами данных. Вернее двумя ограничениями этих технологий. Читать далее Сценарии интеграции приложений (2)
Рубрика: SOA
Приложение управления бизнес-приложениями
Чтобы понять рекурсию нужно понять рекурсию
Много слов сказано для обоснования полезности промежуточного ПО, интеграционных сред, систем управления бизнес-процессами. И количество «оппортунистических» связей между приложениями они сокращают, и интеграционные решения унифицируют и сквозные бизнес-процессы, включающие несколько приложений, реализуют. Всё это, безусловно, важно. Но не это главное.
Уже не один год существует класс информационных систем называемый application management. Эти системы позволяют удаленно развертывать и конфигурировать приложения, мониторить состояние системы, диагностировать ошибки, управлять квотами и т.д. Развитие облачных вычислений (cloud computing) дало дополнительный импульс application management. Насколько мне известно, в Windows Azure при наступлении определенных событий, например превышении загрузки процессора выше определенной черты или увеличении количества входящих сетевых запросов, можно автоматически поднять еще одну виртуальную машину и развернуть на ней дополнительный экземпляр приложения.
Не трудно провести аналогию между системами application management и интеграционными средами и BPMS. Только вторые управляют содержательной частью бизнес-приложений. Обычно, с бизнес-приложениями работают люди. Но по мере роста и развития информационной системы предприятия все чаще возникает необходимость заменить этих людей автоматизированными системами. Сценарии таких ситуаций следующие:
- Управление вводом данных. Когда возникает необходимость за ограниченный промежуток времени ввести в систему несколько десятков тысяч записей, люди становятся бессильны. До определенной степени можно расширять штат низкооплачиваемых сотрудников, занимающихся вводом, но это довольно затратный подход. Намного проще: загрузить данные подготовленные внешним приложением, например, переложить задачу ввода каких-либо запросов на партнеров и клиентов (системы self-service). Другой пример управления вводом данных – автоматическое добавление записей по событию. Многие сервисные службы создают инциденты не только по запросам пользователей, но и на основании событий систем мониторинга. (Подробнее об обработки событий см. ниже)
- Управление справочниками. Большинство бизнес-приложений используют справочники. Когда в различных системах ведутся разные справочники одних и тех же объектов, задача управления этими системами становится крайне сложной. Как только количество используемых систем превысит десяток – время задуматься о централизованном ведении справочников, а задачу управления справочниками возложить на интеграционную среду.
- Управление рабочими процессами (workflow). Сейчас трудно найти систему, внутри которой не было бы функций workflow. Однако такие workflow начинаются и заканчиваются «внутри» системы. Разделение труда между подразделениями предприятия, возможно и повышает его производительность, но в качестве цены за это формирует высоченные барьеры между подразделениями. В то же время, бизнес-процессы любого предприятия являются общими. Иногда в процессе участвуют не только подразделения одной компании, но и подразделения компаний-партнеров. Рабочии процессы – это единая сеть, требующая координации и согласованной работы. Идея бизнес-сервиса, как рабочего процесса, управляемого информационной системой была изложена мной в сообщении Программный интерфейс к бизнесу
- Обработка событий. На фоне всеобщего увлечения сервис-ориентированной архитектурой (SOA), управляемая событиями архитектура (even-driven architecture, EDA) осталась практически незамеченной. Однако, построение адаптивной информационной системы компании требует именно такого подхода. SOA сервисы интересны только в той степени, в которой они помогают компании реагировать на те или иные бизнес-события. Можно написать сотню сервисов, ни одним из которых никто и никогда не воспользуется. Событийный подход вносит смысл в информационную систему компании. Заставляет нас задумываться над вопросом «зачем», для каких случаев, мы разрабатываем тот или иной сервис. Перехват и маршрутизация событий, пожалуй, наиболее значимая ценность, привносимая интеграционными средами в корпоративный ИТ-ландшафт.
- Обработка исключений. Однако не все события поддаются автоматической обработке. Рано или поздно возникает ситуация не предусмотренная ни в требованиях к решению, ни в спецификации взаимодействий, ни в техническом задании. Огромная ошибка заключается в том, чтоб рассматривать такую ситуацию как ошибку, записать сообщение в системный лог и остановить бизнес-процесс. С каждой такой ситуацией должен кто-то разбираться. Появившиеся ошибки это та самая обратная связь от эксплуатации к развитию, помогающая своевременно корректировать бизнес-процессы и модернизировать приложения. Вопреки распространенному мнению интеграционная среда не является «системой без пользователей». Наоборот, это система для наиболее подготовленных и эрудированных пользователей, способных анализировать исключительные ситуации как с точки зрения ИТ, так и с точки зрения бизнеса и своевременно принимать адекватные решения.
Я надеюсь, что некоторые из изложенных мною соображений, расширят арсенал аргументов в пользу использования интеграционных сред в ИТ-инфраструктуре компаний. Комментарии и дополнения, как всегда, приветствуются.
Программный интерфейс к бизнесу
На страницах этого блога мы уже довольно много дискутировали на тему взаимодействия бизнеса и ИТ, выясняли кто является этим самым бизнесом, где проходит граница и как осуществлять сближение ИТ и бизнеса. Все это осуществлялось в контексте управления бизнес-процессами и, как я думаю, было призвано повысить уровень этой самой управляемостью.
Сегодня я хочу поделиться достаточно провокационной, но в то же время довольно банальной идеей о выравнивании ИТ и бизнеса. В сервис-ориентированной архитектуре было модно рассуждать о бизнес-сервисах. Что такое обычный сервис понять довольно легко. Но для SOA нужны не обычные, а бизнесовые сервисы. Чем бизнес-сервис отличается от простого, т.е. технологического сервиса разобраться намного сложнее. Не буду повторять абстрактные рассуждения маститых авторов об ощутимой ценности для бизнеса такого сервиса. Лучше сразу дам свое (не верное с точки зрения SOA(!) определение бизнес-сервиса.
Итак, бизнес- сервис – это доступный через программный интерфейс компонент, функции которого реализуются бизнес-подразделением компании. Т.е. бизнес-сервис — это черный ящик с некоторым программным интерфейсом внутри которого сидят люди и обрабатывают ваши запросы. Примером такого сервиса является приложение Human Task – программный компонент в который вы отправляете задачи, а из него получаете… ну как правило сообщения о том, что задача решена. ИТ-отдел подвергнутый ITSM-у – являет собой другой пример бизнес-сервиса. Вернее набора сервисов, таких как управление инцидентами, управление изменениями и т.п. Естественно, при условии, что эти процессы предоставляют программные интерфейсы. Думаю, вы легко найдете и другие примеры.
Рискну предположить, что управляемость состоящего из бизнес-сервисов предприятия будет существенно выше, чем у традиционного современного предприятия. Ну а о выравнивании отношений между бизнесом и ИТ просто и говорить не приходится
PS: Сегодня и здесь шутят BPM and ECM – The War Begins
Платформа управления заданиями
Несколько лет назад, мы достаточно много говорили о сервис-ориентированной архитектуре. Напомню, что основная идея этого подхода заключается в разделении компонент корпоративной информационной системы на две группы. Первая группа состоит достаточно стабильных, предназначенных для повторного использования компонент, называемых сервисами. Сервисы реализуют базовый функционал и меняются не очень часто. Часто меняющийся функционал должен быть отделен от сервисов и вынесен в группу приложений второго типа.
Прошло много времени. Мы были заняты другими делами: новые проекты, финансовый кризис и т.д. В общем, о сервис-ориентированной архитектуре все стали понемногу забывать. Читать далее Платформа управления заданиями
Конференция BPM-2010
Обновленная версия презентации на конференции BPM-2010
[slideshare id=4169600&doc=bpm-acm-100519231202-phpapp02]
Чуть позже добавлю комментарии
О странностях отношений между SOA и BPM
Бойтесь своих желаний
Если с высоты птичьего полета посмотреть на развитие hype-ов SOA и BPM, и сделать это с некоторой долей юмора, то ситуация будет выглядеть так.
Сначала появилась сервис-ориентированая архитектура. SOA базируется на идее выделения типовых бизнес-операций в отдельные компоненты – сервисы. Проникнувшись этой идеей, ИТ-шники направились в двух направлениях: создавать сервисы и «продавать» идею бизнесу. В первом начинании они, безусловно, преуспели существенно больше чем во втором. Уже в начальные годы шествия SOA мы услышали от ИТ отделов множество репортов о десятках разработанных сервисов.
Затем на сцену вышла идея управления бизнес-процессами (BPM). Одним из составляющих этого движения явилось появление систем управления бизнес-процессами (BPMS). Непременным атрибутом таких систем является движок для оркестровки сервисов, т.е. разработки некоторых «больших» бизнес-процессов из «маленьких» подпроцессов-сервисов.
А потом появился Adaptive Case Management (он же dynamic case management по версии Forrester и он же advanced case management по версии IBM). Одну из основных идей этого течения я бы озвучил так: «BPMS нам не нужен! Дайте нам сервисы, и мы сами будем складывать из них бизнес-процесс, адаптируя его под каждый конкретный случай по своему разумению». Т.е. бизнес проснулся (сам или же разбуженный вендорами – не так важно) и наконец, осознал все преимущества сервис-ориентированного подхода. И не просто осознал, но уже желает самостоятельно, на лету собирать из кубиков лего-сервисов необходимые ему процессы.
А разве не об этом мечтали несколько лет назад первопроходцы SOA?! 😉
Glassfish ESB v2.2
Вообще-то, версия 2.2 интеграционной шины GlassFishESB появилась еще в январе 2010 года. Но, по целому ряду причин, переходим мы на неё только сейчас. Переходим из-за того, что в это релиз вошел ряд критичных для нас исправлений. Но рассказать я хочу как раз не об исправлениях, а о появившемся в 2.2 новом функционале. Читать далее Glassfish ESB v2.2
Интеграция приложений
Среда интеграции приложений – программная платформа, предназначенная для развертывания большого количества композитных [микро]приложений в стиле SOA. Существуют два основных подхода к интеграции приложений: асинхронная интеграция приложений при помощи message-oriented middleware или же просто асинхронного взаимодействия между приложениями посредством обмена файлами или записями в общей базе данных и синхронная интеграция посредством сервисной шины. Недостатком первого подхода является сложная логика интеграции из-за необходимости синхронизации состояний объектов в различных системах. Второй подход требует обеспечения высокой надежности и масштабируемости решений.
Сервис-ориентированная архитектура (SOA) – стиль разработки, минимизирующий внесение изменений в унаследованные системы за счет повторного использования существующего функционала. Ключевой момент SOA заключается в реализации каждого бизнес-процесса в виде отдельного слабосвязанного компонента. В традиционных бизнес-приложениях множество бизнес-процессов реализуются в едином монолитном решении, что затрудняет локализацию проблем, существенно повышает вызванный внесением изменений риск нарушение работоспособности и как следствие требует более тщательного проектирования, разработки изменений и, как правило, проведение полного регрессионного тестирования.
Сервисная шина (ESB) – отдельный класс платформ интеграции приложений реализующий, в отличии от традиционных интеграционных сред, не только асинхронное, но и синхронное взаимодействии. Современные сервисные шины строится на базе решений JavaEE application server
Сервер приложений (JavaEE application server) – программная платформа, предназначенная для эффективного использования серверных ресурсов (процессы, оперативная память, пулы соединений, очереди и пр.) при исполнении множества java-приложений, реализованных в виде сервисов.
SOA сервис – слабосвязанный программный компонент, предназначенный для повторного использования. В отличии от традиционных интеграционных компонент, разработанных с учетом интерфейсов интегрируемых систем и используемых для интеграции только этих систем, сервис может использоваться любыми другими новыми приложениями.
Stateless протокол – протокол взаимодействия между клиентом и сервером, запрещающий сохранение на сервере состояния клиентского соединения. Таким протоколом, например, является протокол web-сервисов HTTP. В отличии от протоколов работы с базой данных, сохраняющих состояние клиентской сессии, stateless протоколы допускают высочайшую степень масштабирования за счет возможности установки дополнительных серверов, включаемых в общую систему балансировки нагрузки.