[Перевод] Управление API и SOA

Достижение начального успеха для Сервис-ориентированной Архитектуры (Service Oriented Architecture, SOA) определяется:

• созданием слабосвязанных соединений «потребитель-поставщик»,
• соблюдение принципа разделения ответственностей между потребителем и поставщиком,
• публикация набора повторно используемых, общих сервисов
• и обеспечение того, чтобы потребители приняли и стали использовать сервис.

Множество команд разработчиков создают и используют сервисы, но до сих пор идет мучительный подбор архитектуры, при которой сервисы будут широко использованы, с потенциалом для повторного использования внутренними командами разработки. Вместо создания согласованной сервисной архитектуры и демонстрации множественного использования одних и тех же сервисов, разработчики вновь и вновь не нарочно создают «Просто Набор Веб Сервисов» (Just a Bunch of Web Services (JBOWS)) или «Просто Набор REST Сервисов» (Just a Bunch of REST Services (JBORS)).

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

Управление SOA, API, и приложением может стать мостом между этими концепциями и улучшить архитектурную согласованность всего решения.

Когда вы будете решать, что использовать как лучшие практики для сервис-ориентированной архитектуры, определять дизайн RESTful сервисов, когда будете формировать план по управлению ими, четко определите, как ваши сервисы и API вместе будут укладываться в общую архитектурную картину.

Внешне, набор RESTful API просто специализированные версии веб-сервисов и предоставляют схожие технические возможности. Дизайн и REST API, и SOA сервисов предполагает раскрытие атомарной функциональности с помощью четко определенных интерфейсов. Публичный контракт (API) оконечной точки и сервисная оконечная точка служат базовыми единицами для построения ядра систем, и разработчики представляют свои решения путем управления доступа, агрегации, композиции и оркестровки взаимодействия оконечных точек. Успешное и расширяемое решение как для API, так и для SOA требует решить вопросы касающиеся:

• инфраструктуры доставки сообщений через интернет/интранет,
• управления на уровне сервисов,
• безопасности, во всех смыслах этого термина.

SOA и API имеют общие проблемы интеграции, расположения оконечных точек, определения модели сообщений, безопасности и качества сервиса. Управляемые API это «SOA реализованные как надо».

Управляемые API это:

• Имеющие активную модель оповещений и дающие возможность подписки.
• Поставляющиеся с соглашением о доступности (service-level agreement (SLA)).
• Надежные, с авторизацией и аутентификацией, защищенные.
• С возможностью мониторинга и монетизацией аналитики.

Большинство оконечных точек сервисов развернуто на платформах, которые не предоставляют возможностей по управлению, хотя сервисы должны демонстрировать характеристики управляемого API. Использование шаблона «Фасад» для API позволяет разработчикам создать слой по управлению адресами оконечных точек, мониторингу использования, обеспечивать соблюдение квот по использованию, ограничивать трафик, и авторизовать потребителей.

Объединение управления для SOA и API может позволить командам продуктивно использовать плюсы как SOA сервисов (повторное использование и эволюционная реализация), так и API (расширенная область действия и расцепленные интерфейсы)

Во многих организация реализация SOA выливается в точечную интеграцию сервисов, а не в построение реальной архитектуры. Примерно, как на картинке ниже, все связано со всем.

Для достижения желаемого состояния архитектуры, разработчики должны модифицировать существующие программы по управлению сервисами, для смягчения факторов риска и поддержки принципов SOA. Откладывание решения по централизованному управлению сервисами часто приводит к тому, что сервисы получаются узкоспециализированными, без возможности повторного использования, быстрое распространение множества реализаций бизнес домена (и это будет не следование принципу bounded domain context), что в конечном счете приводит к удорожанию поддержки всего решения.

Эффективные программы по управлению SOA контролируют разработку и функционирование сервис-ориентированных систем. Команды, реализующие управление SOA решений, используют предписания, процессы, измерения и организационные инициативы следующего рода:

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

Программа управление SOA системами должна предоставлять руководства по всему жизненному циклу решения, включая: создание, тестирование, поддержка, удаление, управление и версионирование.

Инфраструктура по управлению SOA компонентов должна предоставлять инструменты и сервисы для поддержки программы управления. Они должны предоставлять механизмы по управлению и поддержки предписаний. Механизмы для внедрения чек-поинтов в различные фазы разработки ПО и возможности проверки, что сервисы, API и прочие проекты соответствуют предписаниям. Поддерживают автоматические и ручные этапы приемки, обработки исключительных ситуаций.

Некоторые политики управления SOA содержат рекомендации по управлению во время разработки и во время операционной деятельности. Реестр сервисов может помочь в управлении компонентов, находящихся как в разработке, так и в активном использовании.

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

Запуск таких дополнительных проектов, как оптимизация приложения, выявление скрытых бизнес-процессов или построение информационной архитектуры бизнеса – отличный механизм понимания динамики данных, декомпозиции бизнес-домена, определения какие из программ и сервисов должны поддерживать бизнес-процессы.

Очевидно, что на управление публичными контрактами значительное влияние оказывают цели и задачи бизнеса. Ведущие платформы по управлению API предоставляют возможность ведения аналитики и оценки ценности для бизнеса. Платформа должна обеспечивать сбор информации о подписке, использовании, предоставлять метрики эффективности, а также иметь интеграцию с биллинговыми и платежными системами.

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

Экономика API должна включать в себя замеры по полноте использования и нагрузке. Управление API в этом смысле включает в себя отслеживание API по использованию (по версии, по типу API) и нагрузке (по версии, по типу API), а также другие замеры и предписания. Через понимание использования и нагрузке на API – владельцы бизнеса и архитекторы API могут осознанно инвестировать в развитие, расширение инфраструктуры, оптимизировать структуру и полноту сервисов.

Для эффективного и продуктивного предоставления IT решений, команда разработчиков должна синхронизировать действия по управлению API и сервисов. Управление API включает в себя очевидный набор стадий развития (создание, публикация, сокращение, завершение поддержки, блокировка), каждый шаг которых может быть переопределен. Журналирование управления облегчает управление метаданными сервиса, дизайн, разработку, тестирование и оперативное вмешательство. Скриншот ниже показывает пересечение между двумя процессами управления:

Обобщенное описание требований

Документация и описание взаимодействия публичных контрактов или сервисов значительно влияет на то, насколько широко будут использованы возможности по потреблению, агрегированию, оркестровке или композиции API и сервисов через границы доменов организации. Сторонники API отказываются от тяжеловесных, формальных интерфейсов взаимодействия в сторону понятной для человека документации.

Лучшие практики REST начинают оказывать влияние на дизайн и описание систем. При создании RESTful API и SOA сервисов, следует обращать внимание на следующие моменты:

• Не раскрывать оконечные точки, которые предоставляют хрупкие модели данных и диктуют сложный шаблона взаимодействия.
• Качественно описать как контекст сессии и ее состояние влияют друг на друга.
• Качественно задокументировать модель сообщений.
• Описать пределы использования и вопросы безопасности (например, протоколы авторизации, как аутентифицировать пользователя).
• Скрыть детали реализации из внешних интерфейсов.

Документация по API и метаданных сервисов

Работающие SOA и API должны включать определение метаданных и предписания, которые помогают в идентификации, классификации и описании потенциальных потребителей. Метаданные должны помогать в формировании данных о сервисе или API. Предписания используются для того, чтобы можно было сопоставить метаданные с опубликованными сервисами и оконечными точками. Метаданные могут отвечать на следующие вопросы:

• Общее представление (например, имя, описание)
• Атрибуты жизненного цикла (версия, зависимости от версий других сервисов, статус разработки/поддержки)
• Классификация (базовый сервис, составной, инфраструктурный, бизнес)
• Атрибуты оконечной точки (протокол, адрес, WS-* спецификации)
• Модель данных (схема JSON, RAML, XML, WSDL, версия, семантика, проверки)
• Требования и предписания на уровне сервиса (доступность, отзывчивость, безопасность, пропускная способность, емкость)
• Диспетчеризация (перенаправление, очередность, кэширование, трансформации)
• Зависимости (API, сервисы, базы данных, расположение, фреймворки)
• Физические зависимости (платформа для приложения, безопасность, управление)
• Модель бизнес-процессов (UML диаграммы, бизнес классификации)
• Информация о взаимодействии (потребители, поставщики, утилизация)
• Статистика используемости (количество пользователей, доступность, пропускная способность, пики по времени)
• Бухгалтерия и методы стимуляции (плата за показы, подписка, размеры возвратов)

Метаданные позволяют задать формальное описание оконечной точке, обеспечить доступность/обнаруживаемость и повторное использование другими командами. Многие организации не используют все перечисленные опции, просто упрощают логику сервисов. Они работают над тем, чтобы создать единый сервис или API, которые позволят выполнить критические сценарии бизнеса, пересматривают систематизацию метаданных, и увеличивают возможности по повторному использованию для внутренних команд разработки.

Баланс в управлении

Для достижения продуктивного баланса между мягким направлением действий и тотальным контролем необходимо принимать во внимание всевозможные препятствия и культуру разработки внутри группы разработчиков. Действия, сопряженные с реализацией SOA/API, часто могут тормозить из-за:

• Недостаточного образования, знаний, и поддержки со стороны знающих людей
• Недоверие или недостаток общения внутри организации
• Противоречивые стимулы
• Плохой дизайн самих по себе SOA/API
• Недостаток метрик
• Недостаток управления

Руководство является необходимым, но, если процессы управления являются обременительными, они будут вызывать недовольство и сопротивление. Процессы должны выглядеть натурально или автоматизированы при любом удобном случае. Например, соответствие каким-то правилам может проверяться автоматически при чекине или во время регистрации сервиса в системе. Ищите инструменты, которые могут органично встроится в рабочий процесс разработчиков, чтобы они могли легко и просто получать информацию от системы, что какая-то часть результата их работы не соответствует предписаниям и необходимо исправление. Системы управления контрактами (Contract management systems) могут иметь неоценимое значение в управлении потребления ресурсов, запросов на улучшение сервиса, в процессе управления жизненным циклом разработки, и версионировании API.
Успешные большие и малые SOA решения, API-ориентированные решения масштаба предприятия – основываются на широком повторном использовании сервисов и информации во всех областях бизнеса, сквозь все домены и группы разработчиков. Успешное управление включает в себя:

• Организация централизованного ревью дизайна системы
• Усилить контроль за информационными моделями и способами их реализации
• Реализация контроля за соблюдением предписаний
• Создание общего соглашения об использовании сервисов
• Инвентаризация возможностей приложений и интеграционных возможностей
• Реализовать процесс пересмотра управления API для своевременного отражения изменений в каталоге возможностей ПО и сервисов.
• Расширить управление жизненным циклом ПО для сохранения сервис-ориентированности.

---

Данным постом, я хочу привлечь внимание к использованию и проектированию API в ваших продуктах. В этой статье рассказывается о том, что SOA это не просто набор сервисов, это нечто большее, точно так же можно спроецировать эту мысль и на другие области разработки: создание настольных приложений, фреймворков, библиотек и так далее. От удобности и непротиворечивости API в некотором роде зависит успех вашего предприятия. 

Так как на наш взгляд эта тема очень актуальная и будет все более актуальна, мы в GoSharp решили организовать конференцию на эту тему и ждем заявок от тех, кому есть что сказать по теме проектирования, развития и поддержке API. 

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.