Цель данной статьи заключается в том, чтобы помочь вам оценить значимость сервис-ориентированной архитектуры (SOA) и разработать план, применимый для оценки имеющейся у вас инфраструктуры и перехода на настоящую сервис-ориентированную архитектуру.

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

Предпосылки для разработки сервис-ориентированной архитектуры.

За последние 4 десятилетия архитектура программного обеспечения пыталась приспособиться к его возрастающей сложности. Но уровень сложности продолжает возрастать, а традиционные архитектуры уже, кажется, достигли предела своих возможностей в решении проблем. В то же время, сохраняются традиционные потребности IT-организаций, такие как быстрое реагирование на новые требования бизнеса, снижение стоимости IT для бизнеса, способность поглощать и объединять новых партнеров и новые группы потребителей, и это ещё неполный список. Как индустрия мы прошли через множество компьютерных архитектур, предназначенных для полностью распределенной обработки, языков программирования, созданных для работы с различными платформами, весьма сокращающие графики реализации, и несметное число связанных продуктов, разработанных для лучшей и более быстрой интеграции приложений. Однако комплексное решение продолжает ускользать от нас. Сейчас сервис-ориентированная архитектура (SOA) продвигается индустрией как новая стадия эволюции архитектуры программного обеспечения, которая поможет IT-организациям справиться с рядом стоящих перед ними задач. Возможно ли такое, даже если это уже обозначено и описано, применимо ли это в действительности? Тезис данной статьи таков: обещания SOA правдивы, и после того, как схлынет волна рекламы, и придет время обратиться от радужных ожиданий к реальности, то обнаружится, что SOA, по крайней мере, на сегодняшний день, лучшая основа как для адаптации существующих IT-ресурсов, так и для построения систем новых приложений.

С некоторых пор, существование технологий web-сервисов стимулирует дискуссию, развернувшуюся вокруг сервис-ориентированных архитектур (SOAs). Дискуссия началась давно, поскольку концепция была разработана уже более десятилетия назад, с тех пор как CORBA пообещала расширить возможности интеграции приложений на несопоставимых разнородных платформах. Проблемы интеграции таких приложений всегда возникали в основном из-за популярности множества различных (и даже не совместимых с CORBA) объектных моделей, поэтому многие инженеры увязли в решении технологических проблем, таких как неисполненное обещание разработки более устойчивой архитектуры, которая должна позволить простую, быструю и надежную интеграцию систем и приложений. Проблемы, однако, себя не изживают и с каждым годом становятся все сложнее.

Основные потребности бизнеса, такие как снижение стоимости, сокращение времени цикла, интеграция между корпорациями, B2B и B2C интеграция, больший коэффициент рентабельности инвестиций (ROI), создание адаптивных и быстро реагирующих бизнес моделей и т.д., заставляют нас искать лучшие решения, но все больше и больше мы убеждаемся в том, что разовые решения не избавят от основной проблемы. Проблема, в большинстве случаев состоит в отсутствии совместимой архитектурной основы, в пределах которой могут быстро разрабатываться, интегрироваться и повторно использоваться приложения. Более того, нам нужна архитектурная основа, предоставляющая совокупность компонентов и сервисов для быстрой и динамичной выдачи решений. О преимуществах отдельных технологий, таких как web-сервисы, было написано множество статей, но то, что действительно нужно, это архитектурный взгляд, не связанный с технологией. Рассмотрим некоторые фундаментальные проблемы, с которыми приходится сталкиваться в процессе поиска лучшей основы, поскольку способ решения этих проблем определит успех или неудачу процесса.

Проблема первая – сложность.

Что-то всегда остается неизменным, в особенности бизнес-проблемы, стоящие перед IT-организациями. Корпоративный менеджмент всегда выступает за более эффективное использование IT, больший ROI, интеграцию исторически автономных систем и быстрое освоение новых, но кое-что изменилось к настоящему времени. Учитывая тот факт, что информационные инфраструктуры стали более сложными, унаследованные системы теперь предпочтительнее использовать повторно, чем замещать их, потому что при ограниченных средствах стоимость замещения непомерно высока. Недорогой повсеместный доступ в Интернет дал возможность появления совершенно новых бизнес-моделей, которые должны быть, по крайней мере, оценены, с тех пор как конкуренция уже создает их.

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

Рисунок 1. Приоритеты CIO.

Другая проблема – избыточное программирование, не допускающее многократного использования.

Рассмотрим банк, имеющий самодостаточные функциональные прикладные системы(silos), не взаимодействующие с другими системами внутри банка. Первая из этих программ может быть сконструирована для отдельного направления бизнеса внутри банка, так же как вторая, третья и т.д. и быть отдельным изолированным проектом. Так, например, функция получения баланса счета является повторяемой в системах банкоматов, в системе, осуществляющей операции по обслуживанию удаленного клиента, в системе расчетов по кредитным картам, даже если они использовали данные тех же счетов в тех же базах данных. Теперь предположим, что банк должен разработать Интернет-сервис банковских расчетов в реальном времени, или систему выдачи ссуд для своих клиентов в реальном времени, чтобы остаться конкурентоспособным. Новая система будет только усугублять проблему избыточного программирования, до тех пор, пока уже существующий код не станут использовать повторно.

Настоящий убийца интеграции – многочисленные интерфейсы.

Рассмотрим также n(n-1) интеграционную проблему. Все организации сталкиваются с теми или иными проблемами интеграции различного свойства, возможно из-за корпоративного поглощения, новых бизнес альянсов или просто из-за необходимости связать существующие системы. Если n- системы приложений могут быть непосредственно взаимосвязаны, они создадут n(n-1) связи или интерфейсы. На рисунке 2 каждая стрелка представляет интерфейс.

Рисунок 2. Непосредственная связь n приложений.

Следовательно, если другая прикладная система А n+1 должна быть интегрирована, это потребует генерации, документирования, тестирования и поддержки 2n новых интерфейсов. На диаграмме выше набор из пяти приложений требует двадцать прямых интерфейсов, добавление шестого приложения потребует десяти новых интерфейсов! Кроме того, код каждого существующего приложения должен быть модифицирован для включения новых интерфейсов, что приводит к существенным затратам на тестирование.

Как только вы начинаете искать оптимальное решение, которое производит минимальное число интерфейсов (n) для n приложений, с добавлением только одного нового интерфейса для каждой дополнительной системы, вы находите, что этого не может быть при непосредственной связи между приложениями.

Что же дальше?

За последние четыре десятилетия практика разработки программного обеспечения пережила несколько моделей программирования, отличающихся друг от друга. Каждый переход был сделан, чтобы справиться с более высокими уровнями сложности программного обеспечения и запускать набор приложений через составные части, компоненты или сервисы. Совсем недавно Java-технологии привнесли кроссплатформенное программирование, а XML-технологии привнесли кроссплатформенные данные с самоописанием. В настоящее время с помощью web-сервисов было преодолено ещё одно препятствие, и теперь приложения можно связывает вне зависимости от используемой объектной модели. Используя простую, основанную на XML схему сообщений, Java-приложения могут обращаться к DCOM, CORBA и даже COBOL-приложениям. Например, CICS или IMS-транзакции на базовом устройстве в Сингапуре могут быть запрошены COM-приложениями под управлением Lotus Script, выполняющимися на Domino-сервере в Мюнхене. И примечательно то, что, скорее всего запрашивающее приложение не имеет представления, где будет выполняться транзакция, на каком языке она написана, или по какому маршруту будет отправлено сообщение. Сервис запрошен – ответ обеспечен.

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

Они включают в себя:

1. Повсеместные, низкозатратные сетевые инфраструктуры на основе открытых стандартов, технологии, создаваемые для распределенной среды, более способствующие принятию web-сервисов, чем CORBA и DCE.
2. Степень признания и технологическую зрелость, чтобы действовать в «сетецентрическом» мире, который требует способности к взаимодействию в процессе достижения критических бизнес целей, таких как распределенное сотрудничество.
3. Согласие с тем, что взаимодействии, не требующее больших затрат, лучше всего достигается через открытые Интернет-стандарты и аналогичные технологии.
4. Зрелость сетевых технологий (таких как TCPIP), инструментария (IDE, UML), платформ (J2EE платформы), аналогичных методик (OO, сервисы), предоставляющих инфраструктуру, необходимую для обеспечения аппаратного взаимодействия, основанного на принципах слабосвязанности.

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

В перспективе, однако, есть ещё более существенные возможности. Во-первых, распределенные вычисления, которые представляют собой гораздо больше, чем просто приложение со большим количеством MIPS (миллион команд в секунду), для вычисления решения; это также обеспечит структуру, посредством которой огромное число сервисов может динамично располагаться, перемещаться, уравновешиваться и управляться как необходимо приложениям, которые всегда гарантированно и надежно доступны, не взирая на загрузку системы. Это, в свою очередь, делает очевидной потребность в концепции вычислений по требованию, которые должны быть осуществимы в любой конфигурации, от простого кластера серверов до сетей из 1024-узлов Service Packs2 (SP2s). Пользователь нуждается в решении проблемы и хочет применять соответствующие вычислительные ресурсы – ни больше, ни меньше – оплачивая только те, которые действительно используются.

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

Требования к сервис-ориентированной архитектуре.

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

Поддержка всех требуемых типов или «стилей» интеграции. Она включает в себя:

1. Взаимодействие с пользователями – обеспечение единой пользовательской среды;
2. Связность приложений – коммуникативный слой, который лежит в основе всей архитектуры;
3. Интеграция процессов – хореография сервисов и приложений;
4. Интеграция информации – объединяет и пересылает корпоративные данные;
5. Разработка с перспективой интеграции – создание и развертывание новых приложений и сервисов;
6. Учет роста освоения и перемещения средств - это сделает возможным один из самых важных аспектов развития архитектуры: способность увеличивать ROI. Бесчисленные интеграционные проекты не удались из-за их сложности, высокой стоимости и неприемлемых графиков реализации;
7. Среда разработки, формирующаяся вокруг стандартных компонентов структуры; возможность многократного использования модулей и систем; перенос унаследованных средств в новую структуру, своевременное внедрение новых технологий.

8. Применений новых вычислительных моделей, особенно новых портальных моделей клиента, распределенных вычислений и вычислений по требованию.

Сервис-ориентированная архитектура – это не только web-сервисы.

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

Но для начала нужно уяснить, что web-сервисы – это еще не сервис-ориентированная архитектура. Web-сервисы – это набор технологий, куда входят XML, SOAP, WSDL и UDDI, которые позволяют нам создавать программные решения для конкретных проблем сообщений и проблем интеграции приложений. Логично предположить, что со временем эти технологии достигнут зрелости, а впоследствии они могут быть вытеснены более эффективными или более устойчивыми, но в настоящий момент делают свое дело. По крайней мере, они являются подтверждением того, что концепция SOA наконец-то может быть реализована. Так из чего же на сама деле состоит сервис-ориентированная архитектура?

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

Все сервисы независимы. Работают они по принципу «черного ящика»: внешние компоненты не знают, как сервисы выполняют свои функции, они просто получают ожидаемый результат.

В общепринятом понимании, интерфейс можно вызвать; на уровне архитектуры несущественно локальные они (внутри системы), или удаленные (внешние по отношению непосредственно к системе), неважно какая схема связи или протокол используется для инициализации запроса, или какие компоненты инфраструктуры требуются для установления соединения.

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

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

Управление включает в себя большое количество функций, в том числе и:

1. Безопасность – авторизация запроса, кодирование и декодирование как необходимо, проверка достоверности и т.д.
2. Развертываемость – позволяет сервису быть заново развернутым (перемещенным) по сети для выполнения, резервирования для готовности и др.
3. Регистрация – для отслеживания действий, измерений и т.д.
4. Динамическая ремаршрутизация – при сбоях или для балансировки нагрузки.
5. Сопровождение – управление новыми версиями сервисов.

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

По материалам сайта ibm.com/developerworks/

Комментарии