Типичные ошибки в понимании СОА

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

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

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

Наиболее распространенная реализация SOA — это спецификации веб-сервисов (Web services), которые базируются на наборе открытых стандартов HTTP, SOAP, WSDL и UDDI. Другим, не менее широко распространенным подходом к реализации является использование MOM-систем (Message Oriented Middleware), которые активно предлагаются вендорами для реализации в крупных корпоративных и операторских системах (IBM WebSphere MQ, Sonic MQ, спецификации JMS и т.д.).
 
7 типичных заблуждений относительно SOA
 
SOA дает полное описание системной архитектуры
Главное заблуждение, относительно SOA: то, что она описывает архитектуру ИТ-системы организации. Что, правильно внедрив SOA, компания автоматически сможет улучшить функционирования своей ИТ-инфраструктуры. В реальности, SOA является не архитектурой ИТ-системы, а архитектурным шаблоном, по которому может быть построена ИТ-архитектура, как хорошая, так и плохая. Использование шаблона позволит построить архитектуру наиболее эффективно с точки зрения топологии, связей компонентов и механизмов взаимодействия. Например, элементы SOA будут включать потребителей сервисов, описания сервисов, реализации сервисов, и возможно сервисную шину для их взаимодействия. Таким образом, будут описаны архитектурные элементы или иначе блоки, из которых будет построена система.
Главная опасность, подстерегающая человека, считающего что SOA – это системная архитектура, заключается в том, что высока вероятность разочарования при покупке коробочного SOA-решения вследствие того, что оно не решает само по себе задачу, стоящую перед ИТ. В любом случае, перед архитекторами, инженерами и людьми, отвечающими за развитие инфраструктуры компании, будет стоять задача построения архитектуры системы, с использованием SOA-принципов и инструментария.
Напрашивается вопрос: зачем же нам использовать SOA-подход, если он не дает готового решения задачи построение системной архитектуры. Краткий ответ можно сформулировать так: архитектура, построенная в соответствии с принципами SOA, будет легче доступна к внесениям изменений и расширению функциональности, будет проще интегрироваться с другими системами. Платой за использование SOA является небольшое снижение производительности и более сложное обеспечение информационной безопасности системы в целом.
Легаси-системы можно легко включить в SOA
В презентациях, посвященных SOA и продуктам интеграции на базе принципов SOA, практически всегда присутствуют слайды про плавную миграцию от существующих легаси-систем к компонентам и сервисам. Однако миграция существующих систем и встраивание их в SOA-инфраструктуру является очень сложной задачей и, несмотря на наличие инструментов, затраты на её проведение могут оказаться насколько большими, а выигрыш от полученной функциональности настолько мал, что решение о целесообразности интеграции легаси-систем в SOA-инфраструктуру должно приниматься отдельно и с полным пониманием предстоящих сложностей.
Основной трудностью является большой объем работы по подстройке к жестким интерфейсам и построению коннекторов, которые бы обеспечивали представление функциональности системы в виде сервисов.
Для принятия решения об использовании легаси-системы в SOA-инфраструктуре рекомендуется ответить на следующие вопросы:

1. Определены ли уже потребители сервисов, которые будет предоставлять легаси-система?
2. Возможно ли технически представить функциональность в виде сервисов?
3. Какое время и какие специалисты потребуются для «выдергивания» сервисов из легаси-системы?
4. Какие изменения придется внести в саму легаси-систему?
5. Как внесенные изменения повлияют на текущих пользователей легаси-системы?
6. Какова стоимость данных работ, каковы риски и насколько долго можно будет использовать полученную функциональность?

SOA — это набор стандартов. Использовал стандарт – получил SOA
Заблуждением является то, что как только в системе были использованы стандарты для веб-сервисов, JMS, SOAP, WSDL или других стандартов в контексте SOA, то получившаяся система автоматически получилась построенной в соответствии с SOA. Это категорически не правильно. Ключевым для SOA является набор принципов, а не конкретные стандарты.
Особенностью стандартов является также то, что они до сих пор не устоялись и продолжают эволюционировать. В особенность это касается WSCL, WS-Coordination, BPEL, WS-Security, SAML, WS-Transaction, WS-Reliability.
Руководствуйтесь SOA-подходом и выбирайте инструменты для реализации архитектуры. Стандарты — это обязательный, но не единственный инструмент. Какие стандарты выбрать зависит от архитектуры и функциональности.
SOA — это технический термин
Вендоры, продвигающие свои продукты, обычно используют термин SOA для описания своих технологий, поэтому возникает ощущение что сервисно-ориентированная архитектура — это исключительно технический термин.
Однако, SOA описывает стратегию управления, регулирования и развития ИТ-инфраструктуры. SOA делает более прозрачными бизнес-процессы и упрощает их изменения в соответствии с потребностями компании. Можно сформулировать список того, что SOA дает для бизнеса:

• Выделение в структуре ИТ-систем сервисов, которые участвуют в безнес-процессах и сопоставляются целям компании
• Управление каталогом сервисов
• Методология внедрения сервисов
• Управление сервисами
• Инструменты для мониторинга и отслеживания качества предоставляемых услуг
• Управление на основе политик
• Отслеживание SLA для цепочки от провайдера к потребителю.

Внедрение SOA в компании обязательно должно включать в процесс управленцев, определяющих бизнес-процессы компании.
Использование SOA-стандартов обеспечит совместимость
Совместимость между провайдером сервиса и потребителем сервиса может быть достигнута ТОЛЬКО при взаимопонимании на синтаксическом и семантическом уровнях. Совместимость на синтаксическом уровне достигается за счёт использования общих форматов, таких как CSV, XML, plain text и др.
Совместимость на семантическом уровне достигается, когда взаимодействующие стороны одинаково понимают значения тех или иных строк, полей, тэгов и элементов передаваемых данных. Например, сервис «Термометр», определяющий температуру за окном может выдавать число в текстовом ответе по HTTP или в виде XML-документа по запросу через TCP. Синтаксическая совместимость будет достигнута, когда приложение-клиент сможет выделить число из ответа сервиса. Семантическая совместимость будет достигнута, когда обе стороны будут знать, что это число — температура и что она указана в градусах Цельсия, а не градусах Фаренгейта. Серьезный шаг на пути к совместимости — использование мета-описаний. То есть стандартов позволяющих описать передаваемые данные, например, XML схема и WSDL. Тем не менее, данные стандарты могут использоваться лишь как вспомогательный инструмент, а окончательное решение о семантическом соответствии принимается разработчиком или инженером по интеграции.
Реестр сервисов позволит осуществлять автоматический поиск и подключение к сервисам
На данный момент, в подавляющем большинстве реализации выбор сервисов и подключение к ним определяется на стадии дизайна системы (или клиентской части). Автоматическое обнаружение и автоматическая композиция сервисов пока что является слишком сложной задачей, реализация которой приносит больше ошибок и времени по их ликвидации, чем упрощения работы за счёт автоматизации.
В теории потребитель сервиса обращается к репозиторию за получением списка адресов, по которым можно получить интересующий его сервис. Если список состоит из более чем одного адреса, клиент может выбирать между ними на основе каких-либо собственных принципов (по цене, качеству или надежности). Такие реализации возможны.
Ещё более сложным является описание функциональности сервиса на основе некоторой онтологии. В таком случае, клиент, используя работу с онтологиями, может определять какие сервисы ему подходят для решения своей задачи. Например, приложение решает задачу бронирования билетов по маршруту между двумя точками. Эта задача решается путем поиска сервисов по бронированию авиа-, железнодорожных  и автобусных билетов. Маршрут выстраивается так, чтобы билеты на всех его шагах были доступны и могли быть забронированы. К сожалению, подобные сценарии с автоматическим поиском и использованием сервисов по бронированию пока что остаются лишь в теории, а на практике подключение таких сервисов осуществляется вручную на стадии дизайна и тестировании системы.
Тестирование SOA-системы проводится аналогично тестовым испытаниям других систем
Тестирование в SOA-системе является сложно решаемой задачей. Главной трудностью является тестирование совместной работы и взаимодействия компонентов. В особенности сложно тестировать системы, находящиеся в разных зонах ответственности, например, когда различные группы компонентов расположены в разных компаниях, совместно предоставляющих услуги.
Наиболее полное тестирование должно проводиться в клиентских интерфейсах, так чтобы проверить всю цепочку используемых провайдеров и инфраструктурной части.
Гибкость бизнес-процессов таит в себе ещё одну потенциальную опасность, связанную с тестированием и качеством работы. Если инструменты по реорганизации бизнес-процессов (и последовательности использования сервисов) доступны архитекторам, администраторам или даже маркетологам, а не зашиты жестко в систему, то вносимые изменения могут породить потенциальные ошибки в работе.
Подобные опасности должны решаться путем корпоративной политики и четким прописыванием процедуры внесения изменений в работу SOA-системы. Так ни одно внесение изменений не должно проходить без последующего тестирования на работоспособность тех частей и интерфейсов, которые могли быть затронуты проведенными модификациями.
Выводы
Мы уверены, что сервисно-ориентированная архитектура предлагает наилучший подход для достижения совместимости, гибкости и легкой модернизируемости системы. Однако подходить к построению SOA-инфраструктуры надо с реализмом, дабы потенциальные сложности не привели проект к провалу.