Облегченная сервис-ориентированная архитектура: обзор шаблонов и принципов нового поколения решений SOAХесус Родригес (Jesus Rodriguez), Дон Демсак (Don Demsak), Декабрь 2009 г. Краткое содержание.В статье освещены некоторые наиболее часто встречающиеся проблемы традиционных сервис-ориентированных архитектур (service-oriented architectures, SOA), обсуждается решение этих проблем – с помощью более масштабируемых, функционально совместимых и гибких альтернатив, которые называются облеченными сервис-ориентированными архитектурами. ВведениеВ течение последних нескольких лет мы постоянно сталкивались с тем, что при традиционном подходе к сервис-ориентированной архитектуре не удавалось создать ценность для бизнеса и привнести гибкость — ключевые элементы ценностного предложения SOA. Возможно, причины этому можно отыскать в излишней объективной сложности традиционных техник SOA, в частности, протоколов SOAP, WS-* или корпоративных сервисных шин (ESB). Следовательно, альтернативные облегченные реализации SOA, поддерживаемые такими стилями архитектуры, как передача состояния представления (Representational State Transfer, REST) и веб-ориентированной архитектурой (Web-Oriented Architectures, WOA), постепенно оказываются более гибкими, чем традиционный подход SOA. SOA: архитектура без ограниченийПоследние несколько лет SOA являлась краеугольным камнем распределенных систем. По сути, заявленным фундаментальным преимуществом SOA было содействие гибкости ИТ за счет реализации возможностей бизнеса c помощью функционально совместимых интерфейсов, которые можно компоновать между собой для создания новых возможностей бизнеса. С архитектурной точки зрения, традиционные сервис-ориентированные системы обладают следующим набором характеристик:
Довольно просто, не правда ли? Идеальная инфраструктура SOA должна напоминать изображенную на рисунке 1.
Рисунок 1. Идеальная SOAНаверное, все читатели согласятся с тем, что на рисунке 1, по крайней мере в теории, представлена идеальная архитектура корпоративных приложений. К несчастью, крупные развертывания SOA показали, что в реальности все выглядит так: идеальная архитектура, имеющая огромные проблемы с управлением версиями, функциональной совместимостью, производительностью, масштабируемостью и управляемостью. Эти проблемы – прямое следствие недостатка ограничений в сервис-ориентированных системах. Использование стилей архитектуры, не накладывающих ограничения на предметную область, часто приводит к созданию сложных и неуправляемых систем. Вместо того чтобы упростить возможности SOA и сосредоточить внимание на важных аспектах, например на функциональной совместимости, производительности и масштабируемости, мы решили абстрагировать сложность с помощью большего числа инструментов и стандартов. В результате мы создали системы с теми же ограничениями, которые изначально стали причиной появления SOA. Из языка Ruby on Rails мы узнали мантру «соглашения по конфигурации» (“convention over configuration”) или «сущность против формальности» (“essence vs. ceremony”). Если устранить настройки и придерживаться соглашений (то есть стандартных способов выполнения действий), то можно устранить лишние уровни абстракции и тем самым избавиться от ненужной сложности систем. Используйте параметры, когда это необходимо, но не предоставляйте их только для того, чтобы обеспечить настройки, которые почти не будут использоваться. Мы не приводим в данной статье подробный анализ неудачных инициатив по внедрению SOA, однако считаем, что следует указать на некоторые факторы, которые следует принимать во внимание разработчикам при реализации крупных решений SOA. Учитывая объем статьи, мы решили сосредоточить внимание на следующих темах:
Ниже мы рассмотрим каждую из этих тем подробнее и исследуем альтернативные стили архитектуры, с помощью которых разработчики смогут реализовывать более надежные решения SOA. Протокол SOAP и иллюзия абстракции транспортовТекущее поколение решений SOA сформировалось вокруг концепций протокола Simple Object Access Protocol (SOAP). Этот протокол изначально был спроектирован для абстрагирования служб от транспортных протоколов более низкого уровня. На концептуальном уровне службы SOAP могут быть размещены с использованием различных транспортных протоколов, например HTTP и MSMQ. Несмотря на то что в теории идея выглядит прекрасно, на практике мы увидели, что отсутствие зависимости SOAP от транспорта обходится дорогой ценой. И эту цену можно снизить, если вам не требуется подобное отсутствие зависимости. Одно из лучших примеров ограничений, которое накладывает отсутствие зависимости от транспорта, – использование протокола HTTP с конечными точками служб, основанных на SOAP. Подавляющее большинство служб, основанных на SOAP, используют протокол HTTP в качестве транспортного протокола. Однако привязка HTTP в SOA задействует лишь малую часть спецификации HTTP, а именно метод POST и несколько заголовков. В результате службы SOAP, основанные на HTTP, не используют все преимущества протокола HTTP, благодаря которым он стал одним из наиболее популярных и масштабируемых транспортных протоколов за всю историю компьютерных систем. Одним из действительно положительных аспектов SOAP является использование XML, благодаря чему функциональная совместимость распределенных приложений существенно возросла. Однако мы все можем согласиться с тем, что протокол SOAP не соответствует изначально возложенным на него ожиданиям. Ситуация выглядит так: протокол SOAP создавался как простой протокол доступа к объектам (Simple Object Access Protocol), но, как мы успели убедиться, он не прост, не ориентирован на доступ к объектам и, возможно, не является протоколом. Неверное использование языка WSDLЯзык описания веб-служб (WSDL) – одна из основных спецификаций в портфеле SOA. Цель WSDL – описать возможности службы, в частности сообщения, которые могут отправляться и получаться службой, или способ кодирования этих сообщений с помощью протокола SOAP. На концептуальном уровне WSDL представляет эволюцию языков описания предыдущего поколения, например языка описания интерфейсов (IDL), который был ядром таких технологий распределенного программирования, как COM и CORBA. Следуя аналогичному шаблону, язык WSDL быстро стал крайне важным артефактом, используемым клиентскими приложениями для генерации «прокси»-представлений, с помощью которых абстрагируется обмен данными со службой. Несомненно, идея генерировать прокси-артефакты, основанные на языке описания веб-служб (WSDL), может облегчить взаимодействие клиента и службы в очень простых средах. Фундаментальная проблема этого подхода, равно как и его предшественников, заключается в том, что он вводит уровень связывания между клиентом и службой. В крупных сценариях SOA, с участием сотен служб и клиентов, подобный уровень зависимости между клиентом и службой обычно порождает серьезные проблемы с управлением службами и их версиями, что продемонстрировано на рисунке 2.
Рисунок 2. Зависимость WSDL – серьезная проблема в крупных реализациях SOAИспользовать ESB или нет?Поддержка беспроблемной интеграции разнородных специализированных бизнес-систем (LOB) как части бизнес-процессов была заявлена в числе особенностей будущих корпоративных сервис-ориентированных систем. Эта интеграция обычно обеспечивается благодаря набору общих шаблонов, составляющих основу того, что в индустрии ПО считалось одной из основ SOA: корпоративной сервисной шиной (ESB). Хотя и не существует формальных отраслевых стандартов, определяющих ESB, мы можем обнаружить по меньшей мере несколько общих черт разных продуктов ESB. Как правило, ESB абстрагирует набор фундаментальных возможностей, в частности сопоставление протоколов, хореографию служб, адаптеры бизнес-приложений, распределение, преобразования сообщений, а также срок их действия. Теоретически мы можем использовать эту сложную функциональную возможность, чтобы абстрагировать обмен данными между службами и системой, тем самым сделав ESB основой предприятия, как показано на рисунке 3.
Рисунок 3. Центральная корпоративная сервисная шинаНам, как архитекторам, должна безоговорочно понравитьсядиаграмма, представленная на рисунке 3. Несомненно, это идеальная модель, где сообщения отправляются центральному сервис-брокеру, а от него распределяются конечным службам. К сожалению, при работе с крупной SOA мы с большой долей вероятности обнаружим, что архитектура с центральной сервисной шиной вводит серьезные ограничения в таких аспектах, как управление, производительность и масштабируемость, поскольку вся инфраструктура интеграции действует в рамках проприетарной платформы. ESB из помощника может превратиться в проблему, ведущую к ухудшению гибкости, управляемости и масштабируемости SOA. Следовательно, нам придется начать создавать приложения, которые не полностью используют преимущества ESB, и архитектура вскоре будет напоминать изображенную на рисунке 4.
Рисунок 4. Реальная ситуация с ESB на крупном предприятии
Неприятности с WS-*После того как появилась первая волна спецификаций SOA, отдельные поставщики технологий начали предпринимать совместные усилия по встраиванию в модель SOAP/WSDL некоторых ключевых возможностей предприятия: безопасности, надежного обмена сообщениями и транзакций. Результатом этих усилий стала серия спецификаций, в частности WS-Security, WS-Trust и WS-ReliableMessaging, которые в индустрии ПО известны как протоколы WS-*. Спецификации WS-*, обладающие несомненной академической ценностью, не получили широкого применения в разнородных средах. Ограниченное применение WS-* на предприятии может в конечном итоге рассматриваться как следствие крайне большого числа спецификаций WS-*, разработанных за последние несколько лет. В настоящее время существует более ста версий протоколов WS-*, из которых лишь немногие были реально использованы в решениях SOA. Функциональная совместимость пока что является наиболее проблемной частью решений, основанных на WS-*, поскольку в различных наборах инструментов для веб-служб порой реализованы разные протоколы WS-*, разные версии одних и тех же протоколов либо же разные аспекты одной и той же спецификации. Помимо этого, реализация WS-* в основном была ограничена экосистемами .NET и Java, ввиду чего использование преимуществ развивающихся динамических языков в решениях SOA совершенно нецелесообразно (см. рисунок 5).
Рисунок 5. Проблемы с функциональной совместимостью WS-*Управление SOA или диктат SOA?Управление и управляемость должны стать центральной частью каждой SOA средних и крупных размеров. Мы по-прежнему реализуем возможности бизнеса посредством служб, но важно рассмотреть такие вопросы, как управление версиями служб, их развертывание, отслеживание и управление ими. Этот набор функциональных возможностей стал обыденным для платформ управления SOA, которые традиционно развивались на основе концепций, представленных в спецификации универсального обнаружения, описания и интеграции (UDDI). В зависимости от реализации мы можем столкнуться с тем, что платформы управления SOA иногда слишком ограничены для реального управления сложными веб-службами. Подобные типы проблем чрезвычайно распространены в решениях по управлению SOA и являются следствием того, что технологии веб-служб развивались быстрее по сравнению с платформами управления SOA. В технологиях управления SOA эти ограничения традиционно можно было обойти за счет использования централизованной модели, при которой службы виртуализуются в среде размещения, а политики применяются централизованно. Несомненно, подобную модель можно применять в средах небольшого размера, однако она представляет серьезные ограничения по функциональной совместимости, производительности и масштабируемости (см. рисунок 6).
Рисунок 6. Централизованные модели управления SOA – в крупных реализациях нецелесообразныВведение в облегченную сервис-ориентированную архитектуруНа концептуальном уровне SOA может быть очень мощным инструментом для создания реальной бизнес-ценности в корпоративных приложениях. Однако ввиду некоторых проблем, которые объясняются в предыдущих разделах, инициативы SOA превратились в проекты длительностью несколько лет и стоимостью в несколько миллионов долларов; в итоге они не обеспечивают обещанную гибкость. Несмотря на эти проблемы, при правильном внедрении сервис-ориентированная архитектура может стать значимым дифференциатором, создающим реальную бизнес-ценность для предприятия. Однако мы считаем, что применение облегченного, более гибкого подхода, использующего преимущества правильных методик реализации и новых стилей архитектуры, является обязательным для корректной реализации решений SOA. В оставшихся разделах статьи мы представим некоторые шаблоны и архитектурные методики, с помощью которых, по нашему мнению, можно решить некоторые проблемы, описанные выше. В основном мы сосредоточим внимание на следующих аспектах:
Использование Интернета: службы, соответствующие ограничениям RESTВ предыдущих разделах мы рассказали о некоторых ограничения базовых блоков, из которых строятся традиционные системы SOA, в частности, речь идет об XML, SOAP, WSDL и протоколах WS-*. Несмотря на то что веб-службы не зависят от транспортов, подавляющее большинство реализаций используют HTTP в качестве базового протокола. Эти службы, применяющие HTTP, должны (как минимум в теории) работать аналогично веб-системам. Тем не менее различные уровни абстракции, выстроенные нами поверх протокола HTTP, не позволяют этим службам полностью использовать возможности Интернета. Чтобы решить некоторые проблемы, в технологиях SOA начали применять стили архитектуры, более удобные для работы с Интернетом, в частности REST. REST описан в кандидатской диссертации Роя Томаса Филдинга (Roy Thomas Fielding), где указаны принципы, благодаря которым Интернет стал самой масштабируемой и функционально совместимой системой за всю историю программного обеспечения. По сути, системы, использующие REST, моделируются в виде ресурсов. Их адрес указывается в виде URI и доступ к ним можно получить посредством взаимодействий по HTTP, не содержащих сведения о состоянии. Следуя принципам REST, мы можем спроектировать архитектуру высокомасштабируемых служб, которые действительно используют преимущества принципов, на которых основан Интернет. Несомненно, стиль REST стал крайне привлекательной альтернативой веб-службам, основанным на SOAP/WS-*. Использование REST позволяет устранить некоторые ограничения традиционных веб-служб, в частности, проблемы с функциональной совместимостью и масштабируемостью. Ниже перечислены возможности служб, соответствующих ограничениям REST:
Простота с точки зрения потребителя и высокий уровень функциональной совместимости служб, соответствующих ограничениям REST, – это факторы, которые могут существенно повысить гибкость решений SOA следующего поколения. Функциональная совместимость протоколов WS-*Несмотря на значительный объем исследовательской работы, на котором основано семейство протоколов WS-*, можно согласиться, что их применение и получаемые в результате преимущества не соответствуют изначальным ожиданиям. Функциональная совместимость и сложность остаются серьезными проблемами, с которыми мы сталкиваемся при использовании протоколов WS-* на предприятии. Если говорить о функциональной совместимости протоколов WS-*, то, несомненно, лучшей из передовых практик является определение возможностей потенциальных потребителей наших служб. На основе этого мы можем определить, какие протоколы WS‑* лучше всего подходят к нашим конкретным сценариям. В крайне разнородных средах следует рассмотреть реализацию разных конечных точек службы, которые поддерживали бы разные возможности WS-*. Подобный подход может значительно повысить функциональную совместимость служб, учитывая, что различные клиенты смогут взаимодействовать с наиболее совместимой для них конечной точкой службы. Рассмотрим в качестве примера сценарий, обеспечивающий безопасность веб-службы, которую будут использовать клиенты, реализованные на .NET, Sun Metro, Oracle WebLogic и Ruby. В этом сценарии мы можем реализовать три конечные точки службы с различными настройками безопасности, основанными на возможностях клиентов, что показано на рисунке 7.
Рисунок 7. Шаблон множественных конечных точек службыДаже в сценариях, где решено использовать протоколы WS-*, методика, показанная на рисунке 7, помогает улучшить функциональную совместимость путем создания различных конечных точек, каждая из которых удовлетворяет требованиям к функциональной совместимости, выдвигаемым различными потребителями служб. Облегченные федеративные ESBКак было показано выше, централизованная ESB очень часто является одной из главных причин, по которым инициативы SOA терпят неудачу. Возможность централизации высокоинтеллектуальных функциональных возможностей, в частности маршрутизации и преобразования сообщений, а также потока сообщений, столь же привлекательна, сколь и невыполнима на предприятиях среднего и крупного масштаба. По сути, если мы опираемся на чистую концепцию центральной сервисной шины, то существенно ограничиваем возможности для масштабируемости, специализации корпоративных решений, использующих инфраструктуру SOA, а также для управления ими. После нескольких неудачных попыток реализации централизованных ESB на крупных предприятиях, в индустрии ПО произошел сдвиг в сторону более гибкого шаблона, в котором функциональные возможности разделены между множеством облегченных физических ESB, сгруппированных как федеративная сущность. Этот шаблон известен под названием федеративная ESB и представляет один из развивающихся стилей архитектуры для создания высокомасштабируемых решений ESB (см. рисунок 8).
Рисунок 8. Шаблон федеративной ESB
|
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)