Появление концепции сервисно-ориентированной архитектуры (service-oriented architecture, SOA) стало закономерным шагом на пути поиска решения одной из самых насущных и сложных проблем ИТ-индустрии - проблемы интеграции приложений.
Практически любое предприятие работает сегодня с распределенной ИТ-инфраструктурой, которая объединяет разнородные платформы и прикладные решения, включая и унаследованные приложения. Кроме того, для современного предприятия весьма актуальна задача поддержки взаимосвязей с партнерами в рамках корпоративных информационных систем, а также обеспечения на уровне инфраструктуры адекватной реакции на процессы слияния или приобретения компаний. Все это порождает дополнительные требования и создает дополнительные сложности в задачах интеграции, которые, по мнению аналитиков, остаются в числе главных приоритетов ИТ-менеджеров.
Предпосылки
Как решается задача интеграции приложений? Традиционный подход - построение промежуточного программного слоя того или иного типа. Оптимальной для объединения разнородных платформ и решений выглядела технология взаимодействия распределенных объектов CORBA, позволявшая инкапсулировать бизнес-логику приложений, выполняющихся на разных платформах и созданных с использованием разных языков программирования, организовав связь между ними на базе строго описанных интерфейсов. Аналогичные возможности - правда, с естественным ограничением гетерогенности - предлагала корпорация Microsoft в рамках своей компонентной модели DCOM. Однако этим решениям не хватало универсальности; даже применение CORBA сильно зависело от реализации в продуктах разных поставщиков, появлялись новые объектные модели, не поддерживающие CORBA, интеграция по-прежнему реализовывалась на достаточно низком уровне, практически исключая возможность динамичного изменения связей между приложениями в ходе выполнения. Важно и то, что все предлагаемые средства интеграции фокусировались на технологических особенностях реализации приложений и не позволяли учитывать специфику бизнес-процессов, в которых эти приложения использовались.
В то же время новые потребности бизнеса диктуют и новые условия интеграции. Динамичность ИТ-среды, ее нацеленность на решение бизнес-задач, необходимость быстрых изменений в ответ на изменение этих задач - эти характеристики приобретают ключевое значение при проектировании или реформировании корпоративных ИТ-инфраструктур. В этих условиях отдельные, "точечные" решения по интеграции настолько усложняют и саму инфраструктуру, и процесс управления ею, что становятся абсолютно неприемлемыми. Представим себе, к примеру, что в компании существует несколько приложений, каждое из которых интегрировано со всеми остальными посредством соответствующих интерфейсов. Если таких приложений - n, то всего потребуется n(n-1) интерфейсов. С добавлением всего лишь одного нового приложения появится 2n новых интерфейсов, для которых потребуется соответствующее документирование, тестирование и поддержка. В примере на рис. 1 пять взаимодействующих приложений порождают 20 интерфейсов, а добавление шестого приложения потребует еще 10. При этом придется вносить модификации в код каждого из существующих приложений для учета новых интерфейсов и проводить соответствующее тестирование. Чтобы избежать этого, нужна модель интеграции, которая позволит максимально упростить процесс добавления новых приложений и минимизирует число интерфейсов взаимодействия.
 |
| Рис. 1. Прямая интеграция приложений |
Еще одна серьезная проблема - избыточность программных компонентов и сложность их многократного использования. В [1] приводится пример программной инфраструктуры банка, включающей в себя несколько групп приложений для различных направлений банковской деятельности, которые были разработаны в рамках никак не связанных между собой проектов. В результате, с большей долей вероятности возможна ситуация, когда одна функция (скажем, получение баланса по вкладу) реализована многократно в системе автоматизации банкоматов, в системе поддержки филиалов и в системе расчетов по кредитным картам, - даже если все эти системы используют одни и те же данные о счете из общей базы данных. А теперь предположим, что банк намерен разработать новые системы, например, для обслуживания клиентов в Internet или выдачи ссуд в режиме on-line. Расширение функциональности программной среды банка повлечет за собой дополнительную избыточность, если в этой среде отсутствуют механизмы многократного использования компонентов, поддерживающих различные задачи бизнеса.
Все эти интеграционные проблемы и привели к появлению идеи сервисно-ориентированной архитектуры (service-oriented architecture, SOA). Для разрешения этих проблем простого набора технологий уже недостаточно. Нужен общий, архитектурный подход, концепция архитектуры программной среды предприятия, в которой возможна адекватная потребностям бизнеса динамика разработки, интеграции и эксплуатации приложений. Идея SOA заключается в создании архитектурной платформы, которая обеспечит быструю консолидацию распределенных компонентов - сервисов - в единое решение для поддержки определенных бизнес-процессов. Различные определения сервисно-ориентированной архитектуры сегодня дают и аналитики, и производители программных систем. Они не всегда совпадают в частностях, но общий смысл их един - SOA предлагает новый подход к созданию распределенных инфраструктур, в которых программные ресурсы рассматриваются как сервисы, предоставляемые по сети.
Характеристики SOA
Приведем формальное определение сервисно-ориентированной архитектуры, которое сформулировано специалистами корпорации IBM [1]: "SOA - это прикладная архитектура, в которой все функции определены как независимые сервисы с вызываемыми интерфейсами. Обращение к этим сервисам в определенной последовательности позволяет реализовать тот или иной бизнес-процесс". С точки зрения разработчиков, ту же мысль можно передать несколько иными словами: SOA - это компонентная модель, в которой разные функциональные единицы приложений, называемые сервисами, взаимодействуют по сети посредством интерфейсов. Расшифруем данные определения.
- Все функции приложений определены как сервисы. В качестве сервиса может выступать как целое приложение, так и отдельные его функциональные модули. Сервисами могут быть прикладные функции, реализующие определенную бизнес-логику, бизнес-транзакции, состоящие из нескольких функций более низкого уровня, и системные функции, отражающие специфику различных операционных платформ.
- Все сервисы независимы друг от друга. Они выполняют определенные действия по запросам, полученным от других сервисов, и возвращают результаты. Все детали этого полностью скрыты: в концепции SOA сервисы - это "черные ящики".
- В интерфейсе сервиса определены параметры и описан результат. Иными словами, интерфейс определяет суть сервиса, а не технологию его реализации. На архитектурном уровне для обращения к сервису не имеет значения, является он локальным (реализован в данной системе) или удаленным (внешний по отношению к ней), какой протокол используется для передачи вызова, какие компоненты инфраструктуры при этом задействованы. SOA предполагает наличие единой схемы обращения к сервису независимо от того, находится ли они в том же самом приложении, в другом адресном пространстве многопроцессорной системы, на другой аппаратной платформе в корпоративной intranet-сети или в приложении в системе партнера.
Интерфейсы - ключевые элементы SOA. Они должны быть нейтральными к специфике реализации сервиса, которые определяются аппаратной платформой, операционной системой, языком программирования. Подобный нейтралитет обеспечивает универсальность взаимодействия сервисов в разнородной среде, а сервисы, интегрированные посредством таких интерфейсов, являются слабо связанными (loose coupling). Слабая связанность обеспечивает простую и быструю адаптацию системы в целом к изменениям в структуре и принципах реализации сервисов. Таким образом, для SOA характерна гибкость, способность реагировать на изменения в бизнес-процессах динамично и без сложных трансформаций на интеграционном уровне.
Сервисы в SOA могут представлять собой простые или сложные объекты, процессы, охватывающие некоторое множество объектов, процессы, которые в свою очередь состоят из нескольких процессов, или даже некий комплекс приложений, которые в совокупности приводят к получению единого результата. Важно, что с точки зрения архитектуры сервис (независимо от внутренней структуры и языка реализации) выглядит как единое целое. Возможно, что из соображений производительности предпочтительнее окажется реализация сервисов, более сложных по организации, чем простые объекты.
Многие авторы подчеркивают, что идея SOA не нова и, по существу, не связана с конкретными технологиями реализации, что ее зачатки угадываются уже в CORBA и в программном обеспечении промежуточного слоя на базе обмена сообщениями (message oriented middleware), что ее нельзя отождествлять с Web-сервисами, которые представляют собой совокупность технологий и стандартов. Все это верно, однако именно появление Web-сервисов сделало SOA реальностью. Язык описания интерфейсов в CORBA не обеспечивает той независимости от платформ, которая требуется для построения SOA, а потому данная модель позволяет реализовать только сильно связанную интеграцию компонентов. С появлением XML был открыт путь к созданию нейтральных к платформе реализации интерфейсов. Основанный на XML язык описания Web-сервисов WSDL и использование XML для обмена сообщениями между сервисами обеспечивают тот универсальный механизм взаимодействия разнородных компонентов, без которого невозможно реализовать SOA.
Однако верно и то, что Web-сервисы - это совокупность технологий для описания сервисов, взаимодействия между распределенными сервисами и создания каталогов сервисов, которые позволяют строить частные решения по интеграции приложений. Эти технологии, эволюционируя, могут в перспективе оказаться вытесненными другими, более прогрессивными решениями, что не изменит общей сущности SOA, хотя, возможно, внесет коррективы в подходы к ее реализации. SOA - концепция, которая не дает точного описания, как именно должны взаимодействовать сервисы, но говорит о том, как добиться того, чтобы они понимали друг друга и могли быть интегрированы. Различие между SOA и Web-сервисами - это различие между стратегическим подходом к процессам интеграции приложений и конкретной тактикой этой интеграции (с той лишь оговоркой, что на данный момент именно эта тактика, по всей видимости, является оптимальной).
Вместе с тем, SOA рассматривается не только как архитектура для развертывания и выполнения распределенных прикладных решений, но и как модель программирования, в которой приложения строятся исходя из того, что они должны предоставлять в сетевой среде сервисы другим приложениям с помощью описания и публикации соответствующих интерфейсов. Таким образом, одним из основных требований к реализации SOA является включение в нее среды разработки, которая будет базироваться на стандартной компонентной платформе, обеспечивать многократное использование создаваемых программных модулей и поддерживать интеграцию унаследованных систем.
Платформа реализации SOA
Как отмечают аналитики компании ZapThink, которая специализируется на вопросах SOA, и заказчикам, и поставщикам необходимо осознать следующий принципиальный момент: SOA - это не очередной вариант распределенной вычислительной среды, который, достигнув стадии зрелости, будет существовать параллельно с другими возможными вариантами [2]. В перспективе любая архитектура ИТ-среды - клиент-серверная, многозвенная, построенная на базе шины сообщений и т.д. - должна рассматриваться в контексте ориентации на сервисы. SOA - это более высокий уровень абстракции, который дает возможность объединить различные архитектурные стили и модели организации распределенных систем на разных платформах с помощью слабо связанных интерфейсов и асинхронного взаимодействия между ними.
По прогнозам ZapThink, ближайшие три года будут периодом совершенствования стандартов и продуктов, которые поддерживают SOA, при этом другие подходы к построению распределенных сред продолжат развиваться независимо. К 2007-2008 году большинство программных продуктов уже смогут предложить интерфейсы Web-сервисов, и значительная часть ИТ-решений будет сервисно-ориентированной. Аналитики ZapThink считают, что победное шествие SOA как общепризнанной архитектуры для построения сложных, распределенных программных инфраструктур начнется не ранее 2008 года, и только к началу следующего десятилетия можно ожидать, что альтернатив сервисно-ориентированному подходу не останется.
Однако, чтобы получить архитектуру для реальных приложений, концепцию SOA необходимо детализировать. SOA - это не только интерфейсы для описания сервисов. Необходимо понять, как организован поток работ между сервисами в приложении для решения определенной бизнес-задачи. SOA должна отображать бизнес-процессы в программные компоненты не только с учетом внутренних процессов, но и с учетом взаимодействия с партнерами. Необходимы механизмы задания и контроля политик для связи между сервисами, в том числе, формальных соглашений об уровне обслуживания. Кроме того, взаимодействие между сервисами обязывает соблюдать определенные правила защиты информации и должно происходить в надежной среде. Отсюда задачи обеспечения безопасности в SOA.
Программные компоненты для решения всех этих задач образуют платформу реализации SOA. В ZapThink выделяют пять основных групп функций программных продуктов, необходимых для построения SOA: это функции защиты, управления, поддержки процессов, интеграции и инструментария. Для того, чтобы получить работоспособные приложения в архитектуре SOA, обязательным для этих компонентов является следование открытым стандартам (прежде всего, стандартам Web-сервисов) и принципам сервисной ориентации, таким как слабая связанность, инкапсуляция содержания, асинхронность взаимодействия.
Пять категорий программных решений - это пять сегментов рынка программного обеспечения, которые со временем станут частью единого рынка средств для реализации SOA. В то же время, эти основы SOA являются частью "экосистемы" современного рынка программного обеспечения, которая начинает постепенный переход к глобальной поддержке принципов ориентации на сервисы. ZapThink приводит впечатляющую диаграмму ( рис. 2 ), которая иллюстрирует взаимосвязи между различными группами программных продуктов (и соответствующими сегментами данного рынка), их положение относительно платформы реализации SOA сейчас и в ближайшей перспективе.
На белых блоках диаграммы представлены устоявшиеся рынки программного обеспечения, которые сейчас трансформируются в связи с переходом компаний к поддержке SOA в своих продуктах. Все более широкая адаптация SOA в конечном итоге приведет к исчезновению этих сегментов рынка, по крайней мере, в том виде, в каком они существуют сейчас.
Зеленые блоки символизируют рынки систем, связанных с Web-сервисами. Они также находятся в переходном состоянии, поскольку появились сравнительно недавно и с течением времени станут частью других сегментов рынка сервисно-ориентированных систем. В некоторых случаях этот переход уже фактически завершен, например, для такой категории продуктов, как СУБД, рассчитанные на непосредственную работу с XML-данными. Поставщики этих решений проявляли большую активность в 2002 году, но уже к середине 2003 года большинство из них либо вообще вышли из игры, либо были приобретены другими компаниями, либо переориентировали свою деятельность на другие стратегические направления, такие как оперативные хранилища данных или системы управления контентом.
В желтых блоках диаграммы указаны сегменты рынка, которые, по прогнозам ZapThink, останутся независимыми от рынков систем для реализации SOA, даже когда произойдет окончательная консолидация остальных секторов под флагом платформы реализации SOA. И, наконец, красные блоки показывают базовые сегменты рынка систем для реализации SOA.
SOA по версии "Голубого гиганта"
Рынок средств реализации SOA еще только формируется, а потому ни один из современных поставщиков программного обеспечения пока не может предложить решений с полным спектром необходимой функциональности [2]. Аналитики ZapThink выделяют несколько компаний, которые уже имеют солидный продуктовый багаж в тех областях, на базе которых развивается переход к SOA, и уже проделали немалую работу по поддержке в своих системах стандартов Web-сервисов и принципов SOA в целом. Среди них компании НР, IBM, Microsoft и Computer Associates, а также ряд игроков с более сфокусированной направленностью, включая BEA Systems, Ascential Software, Sybase, Progress Software, webMethods, Software AG.
Особую роль аналитики отводят IBM и Microsoft. Эти компании своим активным участием в процессах стандартизации Web-сервисов уже сделали очень многое для становления этого рынка, и сейчас способны задать индустрии нужный вектор развития благодаря цельным продуктовым стратегиям, которые они предлагают для поддержки SOA.
IBM предлагает четырехуровневый подход к адаптации принципов SOA [3]. Каждый из уровней может включать несколько этапов жизненного цикла сервиса, которых также четыре: создание (build), развертывание (deploy), использование (use), управление и защита (manage and secure).
Четыре этапа жизненного цикла сервиса
Создание сервисов подразумевает как построение бизнес-модели будущего приложения в SOA, так и непосредственную разработку сервисов как многократно используемых компонентов с общими, публикуемыми интерфейсами. Для этого разработчики должны иметь инструментарий, обеспечивающий поддержку принципов SOA и необходимых стандартов для проектирования модели приложения, разработки сервиса в целом и входящих в него объектов, а также тестирования приложения в сервисно-ориентированной среде. Для SOA необходима модель компонентной разработки, которая позволит создавать не только новые сервисы, но и включать в единую сервисно-ориентированную среду уже существующие на предприятии приложения и программные модели. Средства разработки, предлагаемые IBM, обеспечивают интеграцию в SOA программных компонентов, реализованных в архитектуре CORBA или в среде с промежуточным слоем на базе WebSphere MQ, унаследованных приложений, управляемых с помощью монитора транзакций CICS, и т.д.
Перспективной для SOA может быть новая архитектура разработки на базе моделей (Model-Driven Architecture, MDA), предложенная консорциумом OMG. В этой архитектуре, которая поддерживается в ряде продуктов семейства IBM/Rational, разработка приложений начинается с создания независимой от специфики реализации модели приложения, на базе которой потом автоматически генерируется модель для конкретной платформы и коды приложения. Высокий уровень абстракции при проектировании приложений в MDA хорошо согласуется с подходами SOA, представляющей приложения как сервисы, взаимодействующие для реализации определенного бизнес-процесса.
На этапе развертывания новые сервисы и существующие ресурсы, преобразованные в сервисы, должны быть помещены в управляемую среду выполнения. Стадия использования предполагает сборку приложения из сервисов в соответствии с созданными на первом этапе моделями бизнеса и соответствующей программной системы, а также тестирование по параметрам качества программного обеспечения, производительность, масштабируемость и т.д. И, наконец, когда приложение помещено в работающую сервисно-ориентированную среду и становится доступно пользователям, необходим постоянный мониторинг использования и безопасного доступа к критичным ресурсам, а также контроль соответствия параметрам, заданным в политиках для данного приложения или в соглашениях об уровне обслуживания.
Четыре уровня адаптации SOA
Переход к SOA - сложный процесс, который связан не только с серьезными трансформациями ИТ-инфраструктуры, но и с изменениями во взаимосвязях между бизнес-процессами и ИТ. IBM предлагает выполнять такой переход поэтапно, беря за отправную точку тот уровень адаптации принципов SOA, который наиболее соответствует состоянию дел на предприятии. Для каждого уровня предлагается не только соответствующий набор инфраструктурных программных решений, но и комплекс консалтинговых услуг, включая обучение.
Уровень 1. Реализация отдельных Web-сервисов. Это начальный уровень развертывания SOA, на котором технологии Web-сервисов используются для разработки новых приложений или преобразования существующих, например, для интеграции с помощью WSDL-интерфейсов систем, написанных на С++, Cobol и Java. Здесь компании должны реализовать этапы создания и развертывания сервисов. Для создания предлагается инструментарий WebSphere Studio Application Developer, а также набор средств Emerging Technology Toolkit, который позволяет разработчикам опробовать новые решения в области Web-служб. Развертывание Web-сервисов поддерживается сервером приложений WebSphere Application Server.
Вместе с тем, SOA рассматривается не только как архитектура для развертывания и выполнения распределенных прикладных решений, но и как модель программирования, в которой приложения строятся исходя из того, что они должны предоставлять в сетевой среде сервисы другим приложениям с помощью описания и публикации соответствующих интерфейсов. Таким образом, одним из основных требований к реализации SOA является включение в нее среды разработки, которая будет базироваться на стандартной компонентной платформе, обеспечивать многократное использование создаваемых программных модулей и поддерживать интеграцию унаследованных систем.
Платформа реализации SOA
Как отмечают аналитики компании ZapThink, которая специализируется на вопросах SOA, и заказчикам, и поставщикам необходимо осознать следующий принципиальный момент: SOA - это не очередной вариант распределенной вычислительной среды, который, достигнув стадии зрелости, будет существовать параллельно с другими возможными вариантами [2]. В перспективе любая архитектура ИТ-среды - клиент-серверная, многозвенная, построенная на базе шины сообщений и т.д. - должна рассматриваться в контексте ориентации на сервисы. SOA - это более высокий уровень абстракции, который дает возможность объединить различные архитектурные стили и модели организации распределенных систем на разных платформах с помощью слабо связанных интерфейсов и асинхронного взаимодействия между ними.
По прогнозам ZapThink, ближайшие три года будут периодом совершенствования стандартов и продуктов, которые поддерживают SOA, при этом другие подходы к построению распределенных сред продолжат развиваться независимо. К 2007-2008 году большинство программных продуктов уже смогут предложить интерфейсы Web-сервисов, и значительная часть ИТ-решений будет сервисно-ориентированной. Аналитики ZapThink считают, что победное шествие SOA как общепризнанной архитектуры для построения сложных, распределенных программных инфраструктур начнется не ранее 2008 года, и только к началу следующего десятилетия можно ожидать, что альтернатив сервисно-ориентированному подходу не останется.
Однако, чтобы получить архитектуру для реальных приложений, концепцию SOA необходимо детализировать. SOA - это не только интерфейсы для описания сервисов. Необходимо понять, как организован поток работ между сервисами в приложении для решения определенной бизнес-задачи. SOA должна отображать бизнес-процессы в программные компоненты не только с учетом внутренних процессов, но и с учетом взаимодействия с партнерами. Необходимы механизмы задания и контроля политик для связи между сервисами, в том числе, формальных соглашений об уровне обслуживания. Кроме того, взаимодействие между сервисами обязывает соблюдать определенные правила защиты информации и должно происходить в надежной среде. Отсюда задачи обеспечения безопасности в SOA.
Программные компоненты для решения всех этих задач образуют платформу реализации SOA. В ZapThink выделяют пять основных групп функций программных продуктов, необходимых для построения SOA: это функции защиты, управления, поддержки процессов, интеграции и инструментария. Для того, чтобы получить работоспособные приложения в архитектуре SOA, обязательным для этих компонентов является следование открытым стандартам (прежде всего, стандартам Web-сервисов) и принципам сервисной ориентации, таким как слабая связанность, инкапсуляция содержания, асинхронность взаимодействия.
Пять категорий программных решений - это пять сегментов рынка программного обеспечения, которые со временем станут частью единого рынка средств для реализации SOA. В то же время, эти основы SOA являются частью "экосистемы" современного рынка программного обеспечения, которая начинает постепенный переход к глобальной поддержке принципов ориентации на сервисы. ZapThink приводит впечатляющую диаграмму ( рис. 2 ), которая иллюстрирует взаимосвязи между различными группами программных продуктов (и соответствующими сегментами данного рынка), их положение относительно платформы реализации SOA сейчас и в ближайшей перспективе.
На белых блоках диаграммы представлены устоявшиеся рынки программного обеспечения, которые сейчас трансформируются в связи с переходом компаний к поддержке SOA в своих продуктах. Все более широкая адаптация SOA в конечном итоге приведет к исчезновению этих сегментов рынка, по крайней мере, в том виде, в каком они существуют сейчас.
Зеленые блоки символизируют рынки систем, связанных с Web-сервисами. Они также находятся в переходном состоянии, поскольку появились сравнительно недавно и с течением времени станут частью других сегментов рынка сервисно-ориентированных систем. В некоторых случаях этот переход уже фактически завершен, например, для такой категории продуктов, как СУБД, рассчитанные на непосредственную работу с XML-данными. Поставщики этих решений проявляли большую активность в 2002 году, но уже к середине 2003 года большинство из них либо вообще вышли из игры, либо были приобретены другими компаниями, либо переориентировали свою деятельность на другие стратегические направления, такие как оперативные хранилища данных или системы управления контентом.
В желтых блоках диаграммы указаны сегменты рынка, которые, по прогнозам ZapThink, останутся независимыми от рынков систем для реализации SOA, даже когда произойдет окончательная консолидация остальных секторов под флагом платформы реализации SOA. И, наконец, красные блоки показывают базовые сегменты рынка систем для реализации SOA.
SOA по версии "Голубого гиганта"
Рынок средств реализации SOA еще только формируется, а потому ни один из современных поставщиков программного обеспечения пока не может предложить решений с полным спектром необходимой функциональности [2]. Аналитики ZapThink выделяют несколько компаний, которые уже имеют солидный продуктовый багаж в тех областях, на базе которых развивается переход к SOA, и уже проделали немалую работу по поддержке в своих системах стандартов Web-сервисов и принципов SOA в целом. Среди них компании НР, IBM, Microsoft и Computer Associates, а также ряд игроков с более сфокусированной направленностью, включая BEA Systems, Ascential Software, Sybase, Progress Software, webMethods, Software AG.
Особую роль аналитики отводят IBM и Microsoft. Эти компании своим активным участием в процессах стандартизации Web-сервисов уже сделали очень многое для становления этого рынка, и сейчас способны задать индустрии нужный вектор развития благодаря цельным продуктовым стратегиям, которые они предлагают для поддержки SOA.
IBM предлагает четырехуровневый подход к адаптации принципов SOA [3]. Каждый из уровней может включать несколько этапов жизненного цикла сервиса, которых также четыре: создание (build), развертывание (deploy), использование (use), управление и защита (manage and secure).
Четыре этапа жизненного цикла сервиса
Создание сервисов подразумевает как построение бизнес-модели будущего приложения в SOA, так и непосредственную разработку сервисов как многократно используемых компонентов с общими, публикуемыми интерфейсами. Для этого разработчики должны иметь инструментарий, обеспечивающий поддержку принципов SOA и необходимых стандартов для проектирования модели приложения, разработки сервиса в целом и входящих в него объектов, а также тестирования приложения в сервисно-ориентированной среде. Для SOA необходима модель компонентной разработки, которая позволит создавать не только новые сервисы, но и включать в единую сервисно-ориентированную среду уже существующие на предприятии приложения и программные модели. Средства разработки, предлагаемые IBM, обеспечивают интеграцию в SOA программных компонентов, реализованных в архитектуре CORBA или в среде с промежуточным слоем на базе WebSphere MQ, унаследованных приложений, управляемых с помощью монитора транзакций CICS, и т.д.
Перспективной для SOA может быть новая архитектура разработки на базе моделей (Model-Driven Architecture, MDA), предложенная консорциумом OMG. В этой архитектуре, которая поддерживается в ряде продуктов семейства IBM/Rational, разработка приложений начинается с создания независимой от специфики реализации модели приложения, на базе которой потом автоматически генерируется модель для конкретной платформы и коды приложения. Высокий уровень абстракции при проектировании приложений в MDA хорошо согласуется с подходами SOA, представляющей приложения как сервисы, взаимодействующие для реализации определенного бизнес-процесса.
На этапе развертывания новые сервисы и существующие ресурсы, преобразованные в сервисы, должны быть помещены в управляемую среду выполнения. Стадия использования предполагает сборку приложения из сервисов в соответствии с созданными на первом этапе моделями бизнеса и соответствующей программной системы, а также тестирование по параметрам качества программного обеспечения, производительность, масштабируемость и т.д. И, наконец, когда приложение помещено в работающую сервисно-ориентированную среду и становится доступно пользователям, необходим постоянный мониторинг использования и безопасного доступа к критичным ресурсам, а также контроль соответствия параметрам, заданным в политиках для данного приложения или в соглашениях об уровне обслуживания.
Четыре уровня адаптации SOA
Переход к SOA - сложный процесс, который связан не только с серьезными трансформациями ИТ-инфраструктуры, но и с изменениями во взаимосвязях между бизнес-процессами и ИТ. IBM предлагает выполнять такой переход поэтапно, беря за отправную точку тот уровень адаптации принципов SOA, который наиболее соответствует состоянию дел на предприятии. Для каждого уровня предлагается не только соответствующий набор инфраструктурных программных решений, но и комплекс консалтинговых услуг, включая обучение.
Уровень 1. Реализация отдельных Web-сервисов. Это начальный уровень развертывания SOA, на котором технологии Web-сервисов используются для разработки новых приложений или преобразования существующих, например, для интеграции с помощью WSDL-интерфейсов систем, написанных на С++, Cobol и Java. Здесь компании должны реализовать этапы создания и развертывания сервисов. Для создания предлагается инструментарий WebSphere Studio Application Developer, а также набор средств Emerging Technology Toolkit, который позволяет разработчикам опробовать новые решения в области Web-служб. Развертывание Web-сервисов поддерживается сервером приложений WebSphere Application Server.
Еще один вариант - сугубо внутренние изменения в бизнесе. Например, дом моды принимает решение расширить свою розничную сеть с помощью бутиков по принципу "магазин в магазине". При этом основная часть бизнес-операций компании останется без изменений, но в ее собственной программной системе должны быть учтены новые условия соглашений об аренде. В данном случае серьезному пересмотру может подвергнуться внутренняя система компании, но, благодаря SOA, это никак не отразится на взаимодействии с поставщиками.
И, наконец, еще один возможный и наиболее серьезный тип изменений в бизнесе - вертикальные изменения. Например, компания отказывается от продаж собственного ассортимента одежды и переходит исключительно на аренду помещений. Это приведет к серьезной структурной перестройке, поскольку появляются новые взаимосвязи в бизнесе, новые процессы и ПО. Однако использование SOA-инфраструктуры, формируемой исходя из задач бизнес-процессов, а не программных приложений, позволяет на уровне архитектуры четко определить, какие компоненты должны быть добавлены, модифицированы или удалены, чтобы отразить изменения в ведении бизнеса компании.
Большинство изменений в SOA - задача не разработчиков, а архитекторов программных систем. В компетенции разработчиков остается создание функциональных модулей, которые будут определены в качестве сервисов, но задачи сопряжения этих сервисов в единое целое для реализации бизнес-процесса должны решаться на уровне моделирования.