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 уже давно не развивается. Посмотрим насколько это новшество приживется в практической деятельности разработчиков