Рубрика: Software architecture

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

Одна из немногих книг по интеграции корпоративных информационных систем Enterprise Integration Patterns появилась в конце 2003 года. По большому счету других, сколь либо серьезных исследований данного вопроса с того времени и не появилось. Автор книги Gregor Hohpe поддерживает одноименный сайт Enterprise Integration Patterns на котором можно посмотреть основные паттерны. Впрочем, описаны они довольно кратко и лучше читать книгу. Тем более что она переведена на русский язык как Шаблоны интеграции корпоративных приложений.

При всем искреннем уважении к Грегору Хопу, должен отметить, что о паттернах корпоративной интеграции речь идет только в первых нескольких главах книги, написанных такими уважаемыми людьми как Мартин Фаулер и др. Авторы выделяют четыре основных паттерна интеграции: файловый обмен, общая база данных, вызов удаленной процедуры и обмен сообщениями. Основную часть книги как раз и занимают паттерны обмена сообщениями. Messaging, безусловно, мощный и эффективный подход как при интеграции так и при разработке корпоративных систем. Однако сценарии интеграции корпоративных приложений это не только и не столько messaging. Это и файловый обмен и синхронный вызов сервисов и доступ разных приложений к общей базе данных. И в описании подходов к интеграции чувствуется определенный пробел. Чтобы не перегружать слово паттерны, я буду использовать термин сценарии интеграции приложений и постараюсь постепенно заполнить возникший пробел.
Читать далее Сценарии интеграции приложений

Adaptive Case Management + Semantic Web

Развитие идей предыдущего сообщения другими словами.

Традиционный кейс менеджмент – это практика, предполагающая сбор в единой папке всех документов, относящихся к определенному случаю. Помните, были такие картонные папки с надпись «Дело №…». Adaptive case management позволяет нам ассоциировать с некоторым конкретным случаем (делом) не только документы, но и людей, процессы, сообщения, любые информационные ресурсы. Т.к. мы люди умные, то не будем физически подшивать эти ресурсы в папку, т.е. засовывать их внутрь, а соберем в кейсе гиперссылки на необходимые нам ресурсы: контент, карточку сотрудника, страницу бизнес-события и экземпляра бизнес-процесса.

Однако, простые гиперссылки не обладают семантикой. Т.е. ссылка на человека не будет отличаться от ссылки на документ. Это плохо. Поэтому мы будем использовать семантические ссылки, т.е. ссылки помеченные определенной меткой(тэгом). Например, ссылка на исполнителя кейса будет иметь тэг «case worker», а ссылка на инициирующее создание кейса событие будет иметь тэг «trigger». Естественно, нам не помешает механизм обратных ссылок, присутствующий в блогах, wiki и других социальных инструментах.

Это все! Очень простая и вполне законченная логическая архитектура ACM построена

Юзабилити глазами архитектора

При попытке охарактеризовать архитектурный стиль RESTful чаще всего мне в голову приходит термин usability. Конечно, я понимаю, что у этого термина совершенно другой смысл. Юзабилити ассоциируют с эргономикой и удобством пользователя. Есть замечательное по своему пафосу выражением «интуитивно понятный интерфейс», т.е. при выборе операции ты полагаешься не столько на знание возможностей инструмента, сколько на свою интуицию. В этой логике наиболее востребованной кнопкой должна быть ни «да» или «нет», а «может быть».

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

PS: Кстати, case management является довольно юзабильным подходом. Вы можете включить в кейс данные, людей, процессы, события так, как если бы они являлись объектами одного и того же типа. Логически кейс — это папка, которая объединяет все что угодно. В традиционном case management вы можете подшить в папку только документы. В advanced case managemnt-е  вы помещаете в кейс совершенно произвольные объекты, в том числе процессы, людей и события.

Другими словами:
ECM, Enterprise content management  – организация разнородного неструктурированного контента, используемого в деятельности предприятия
BPM, Business process management — объединение различных задач в согласованную последовательностей действия для достижения результата
Enterprise 2.0 (Social software) – объединение сотрудников в временные рабочие группы
Adaptive case management – объединение контента, процессов, сотрудников и событий, связанных с конкретной задачей.

Платформа управления заданиями

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

Прошло много времени. Мы были заняты другими делами: новые проекты, финансовый кризис и т.д. В общем, о сервис-ориентированной архитектуре все стали понемногу забывать. Читать далее Платформа управления заданиями

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

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

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

Enterprise architecture в Клубе Архитекторов Microsoft

Вчера выступал и, что более содержательно, слушал чужие доклады и обсуждения, в Клубе Архитекторов Microsoft. Несколько наблюдений по горячим следам Читать далее Enterprise architecture в Клубе Архитекторов Microsoft

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 систем.