Enterprise architecture vs. BPM

В блоге Анатолия Белайчука появилась заметка Граница между инструментарием EA и BPMS. Желание провести такую границу абсолютно уместно. Не выполненных обещаний архитектуры предприятия, BPM сообщество  просто не потянет. С другой стороны, накопленный Enterprise architecture опыт реальной деятельности в компаниях, тоже не стоит сбрасывать со счетов. Тем более, что ошибки у корпоративных архитекторов и специалистов по управлению бизнес процессов одинаковы: Читать далее Enterprise architecture vs. BPM

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

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

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

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

HATEOAS

Этот страшный заголовок является аббревиатурой Hypermedia as the Engine of Application State. Википедия указывает указывается на заметку блоге REST APIs must be hypertext-driven , принадлежащую Рою Филдингу. Слабо понятное сокращение скрывает совершенно великолепную архитектурную идею:

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

Филдинг говорил об этом применительно к архитектурному стилю REST (Кстати, он его и придумал). Из примеров реализации такой архитектуры мне на память приходят автоответчики, сценарии которых задаются в виде voiceXML страниц. Ну, а вспомнил я об этом, раздумывая об архитектуре BPM систем.

Dynamic business application

Способна ли ваша компания запускать новые продукты быстрее, чем ваше ИТ разрабатывает новые бизнес-приложения? Обычно ответ является отрицательным. Время вывода на рынок нового продукта или услуги не может быть меньше, чем время на разработку или на приобретение и развертывание нового приложения. Длинные циклы внесения изменений в ИТ системы являются существенным тормозом в стремлении предприятий гибко реагировать на меняющиеся потребности рынка.
Причина проблемы кроется в том, что используемые сегодня пакеты бизнес-приложений создавались для реализации типовых стандартных сценариев, создавались на основе требований сформулированных для текущей ситуации и не были предназначены для изменений. Дальше читаем Forrester The Dynamic Business Applications Imperative если найдем в бесплатном доступе

Direct Graph Markup Language

Был вчера на конференции Enterprise developer conference. О конференции чуть позже, сначала про DGML.

Microsoft встроил в Visual Studio функционал построения графических моделей из проектных репозиториев, разработав попутно для этого XML-based язык описания ориентированных графов. Какие объекты использовать в качество узлов графа(сборки, неймспейсы или классы) решать архитектору. Думаю, без больших проблем можно использовать и другие объекты. Или же просто нарисовать такую картинку как эта

В общем-то, идея вполне симпатичная, тем более что GraphVis уже давно не развивается. Посмотрим насколько это новшество приживется в практической деятельности разработчиков