HATEOAS: реализация функций в RESTful API

Я не знаю кто и когда придумал аббревиатуру HATEOAS, означающую Hypermedia As The Engine Of Application State. Выглядит она страшно, а звучит непонятно. В общем разбираться с тем что это такое и зачем оно нужно совершенно не хочется. Из-за этого потенциал, заложенный в архитектурный стиль REST и позволяющий создавать довольно интересные программные интерфейсы остается не раскрытым. Но обо всем по порядку. Continue reading →

Реклама

Почему не все сервисы одинаково полезны

inversionВ программировании известен такой архитектурный паттерн как Inversion Of Control. Суть его в следующем. Традиционно, повторно используемый код оформлялся в виде функций, которые впоследствии вызывались из основной программы. Функции оформлялись в виде статических библиотек, динамических библиотек или вообще в виде сервисов. Приходил программист. Брал функциональные требования, реализовывал бизнес-логику в виде отдельной программы, которая при необходимости вызывала эти самые функции. Inversion Of Control переставляет все с ног на голову. Мы пишем готовую программу, внутри которой реализуем повторно используемый функционал. При этом мы предусматриваемые некоторые точки расширения, в которых вызываются функции, реализующие бизнес-логику. В качестве примера можно привести функцию обработки сообщений главного окна приложения Windows именуемую MainWndProc(). В объектно-ориентированном программировании приложение часто наследуется от некоторого базового класса. Continue reading →

Масштабируемость RESTful web-сервисов

Representational State Transfer это не только эффективный стиль для архитектуры данных и приложений. Безусловно, очень удобно, когда у каждого информационного ресурса есть неизменный URL.  Такую гиперссылку можно сохранить или переслать коллеге, избавив информационные системы от повторного поиска. Но придумывался REST, как впрочем и HTTP, не только для этого. Основная задача этой архитектуры заключалась в построении масштабируемых многоуровневых приложений. Не смотря, на очевидность и простоту этой архитектуры, очень многие разработчики корпоративных информационных систем её не понимают (или делают вид, что не понимают). Поэтому, очередной взгляд на эту архитектуру. На этот раз с точки зрения инфраструктуры. Continue reading →

Мобилизация корпоративных информационных систем и дилемма инноватора

Если бы лет пять назад вы спросили программиста, будет ли в будущем его приложение работать на андроиде то, в лучшем случае, он счел бы вас эксцентричным фанатом «Звездных войн». Сегодня вопрос предоставления сотрудникам доступа к корпоративной информационной системе с мобильных устройств звучит вполне обыденно. Вопрос не в том, предоставлять ли такой доступ, а скорее — как это сделать. Очевидный ответ на него: разработать для приложений мобильные клиенты – мне представляется нечестным и трудно реализуемым. На протяжении последних пятнадцати лет мы регулярно переписываем свои корпоративные системы. Сначала мы переписывали их в архитектуру клиент-сервер, потом переписывали на Java, затем готовили к проблеме 2000. С появлением серверов приложений мы снова их переписывали. Continue reading →

Одна из ошибок при переходе от инхауса к аутсорсингу

На неделе выступал перед довольно масштабной аудиторией наших разработчиков. Так как развитием ИТ систем в нашей компании занимается несколько сотен человек, то недостатка в слушателях не было. Выступая, затронул новую для себя тему. Похоже, об этом я еще нигде не рассказывал.
Итак, зачем компании нужна сервис-ориентированная архитектура Continue reading →