Уровень сложности: средний Алекс Лоув Койманс, руководитель проектов, Международная организация технической поддержки (ITSO) в Центре Паукипси
Ник де-Грееф, старший ИТ-архитектор, Международная организация технической поддержки (ITSO) в Центре Паукипси
Даниэль Райш, старший сертифицированный ИТ-архитектор, Международная организация технической поддержки (ITSO) в Центре Паукипси
Эран Йона, ИТ-архитектор, Международная организация технической поддержки (ITSO) в Центре Паукипси
16.09.2009
Первое издание (август 2006). Данное руководство касается WebSphere Application Server for z/OS Version 6.02, WebSphere Message Broker V6.0 for z/OS, WebSphere Process V6 for z/OS, WebSphere ESB V6 for z/OS, CICS Transaction Server V3.1, CICS Transaction Gateway V5 и V6, DB2 UDB for z/OS V8, IMS Transaction Manager, IMS Connect. Документ создан или модифицирован 5 сентября 2006 года.
Без сомнения, сервис-ориентированная архитектура (SOA) – одна из важнейших тем повестки дня любого ИТ-специалиста. SOA дает новое представление о процессах проектирования, разработки и управления приложениями и в то же время предъявляет новые требования к обеспечивающей инфраструктуре.
В данном справочном руководстве описаны задачи, возникающие при внедрении SOA в части реализации ИТ-инфраструктуры, и методы их решения с помощью платформы IBM System z и операционной системы z/OS. Эффективная реализация SOA требует от поддерживающей среды исключительно высокого качества обслуживания, а пользователям необходимы безопасность, высокая готовность и простота управления сервисами. Перечисленные требования являются фундаментальными характеристиками System z и z/OS, превращая их в идеальную платформу для информационных систем сервис-ориентированной архитектуры.
В настоящем издании приведен обзор SOA, описана эталонная модель сервис-ориентированной архитектуры, а также показано, каким образом IBM System z и z/OS отвечают требованиям SOA. В заключение предлагается подход к настройке имеющихся приложений на сервис-ориентированную модель и приводятся несколько сценариев интеграции.
Глава 2. Эталонная модель SOA
В предыдущей главе мы описали характер современных задач управления, а также те свойства SOA, благодаря которым она позволяет решать эти задачи. Как мы отметили, требования, предъявляемые к сервис-ориентированной архитектуре, не ограничиваются функциональной стороной, реализуемой с помощью приложений; большое значение также имеют характеристики ИТ-инфраструктуры.
В данной главе мы рассмотрим компоненты SOA, а также условия их развертывания с учетом нефункциональных требований, накладываемых на сервис-ориентированную архитектуру задачами управления.
Для начала мы обратимся к эволюции подходов к интеграции приложений. Мы рассмотрим эталонную модель SOA корпорации IBM, на которую будем ссылаться на протяжении всего последующего изложения. В заключение мы перечислим требуемые характеристики развертывания, что послужит основой для объяснения преимуществ и ценности платформы z/OS.
2.1 Эволюция подходов к интеграции приложений
Существует множество точек зрения на процесс эволюции подходов к программированию, результатом которого стало появление SOA в ее нынешнем облике. Одна из этих точек зрения отражена на рис. 2-1 (подробнее см. Ресурсы, [5]).
SOA возникла на основе двух независимо развивавшихся, но связанных по смыслу направлений разработки:
- эволюции подходов к программированию в направлении многократного использования кода;
- эволюции интероперабельности программ в виде смещения фокуса к усилению интеграции приложений.
На рисунке 2-1 показан процесс эволюции этих двух направлений в сторону SOA.
Рисунок 2-1. Эволюция к SOA
2.1.1 Эволюция подходов к программированию
Раньше программисты стремились создавать структурированные программы, выделяя функциональные блоки в процедуры. Эти процедуры были тесно связаны друг с другом и редко допускали вызов из других приложений. При этом организация взаимодействия и доступа к ресурсам часто представляли собой более сложную задачу, чем реализация бизнес-логики.
Принятие идей модульного программирования повысило степень структурированности программ и одновременно сделало возможным использование кода другими приложениями, а объектно-ориентированное программирование расширило возможности такого использования. Наконец, компонентная разработка стала воплощением технологий проектирования и программирования, обеспечивающих использование кода другими приложениями и устранение индивидуально-зависимых межпроцедурных связей, затрудняющих достижение совместимости.
Недавно IBM в продолжение этого процесса анонсировала новые технологии SDO (Service Data Objects) и SCA (Services Component Architecture), которые легли в основу сервис-ориентированной модели программирования, упрощающей составление программ и позволяющей разрабатывать компонентные приложения.
2.1.2 Развитие интероперабельности
В то же время все чаще возникала необходимость обеспечить межпрограммное взаимодействие, что потребовало повышения интероперабельности. Программное обеспечение промежуточного слоя, отвечающее за передачу сообщений, освободило программиста от большинства задач, связанных с организацией взаимодействия, и внесло дополнительный вклад в ослабление связанности между компонентами приложений. Следующим шагом в интеграции приложений стали брокеры, содержащие инструменты для трансформации и агрегации сообщений.
SOA предоставляет разработчикам прикладных программ стандартизированные способы организации межпрограммного взаимодействия и многократного использования сервисов на всех уровнях, вплоть до уровня бизнес-сервисов.
Благодаря этому программисты могут высвободить значительную часть своего времени, которое они раньше расходовали на решение задач низкоуровневого взаимодействия и управления системой, и сконцентрировать усилия в поле бизнес-проблем.
Согласование бизнес-процессов стало новым элементом в технологии интеграции, позволяющим специалистам по бизнес-моделированию составлять процессы из автоматизированных и неавтоматизированных сервисов.
2.2 Технологии, поддерживающие SOA
Перед тем как перейти к рассмотрению эталонной модели SOA, перечислим технологии, используемые на сегодняшний день для ее реализации.
2.2.1 Web-сервисы и связанные с ними технологии
Web-сервисы – это набор спецификаций, определяющих стандарт межсистемного взаимодействия. Благодаря Web-сервисам приложения могут взаимодействовать на основе строго формализованных интерфейсов. Интерфейсы скрывают особенности реализации сервиса, благодаря чему приложения, основанные на различных технологиях и выполняемые на разных платформах, могут входить в состав композитных приложений более высокого уровня.
Web-сервисы предусматривают использование таких технологий, как XML и протокол HTTP, и являются фактическими стандартами для реализации SOA. Наиболее важные стандарты Web-сервисов сейчас находятся в процессе обсуждения.
Язык описания Web-сервисов WSDL основан на XML. Интерфейс каждого сервиса определяется соответствующим документом WSDL. WSDL-документ имеет широкие возможности многократного использования и должен размещаться так, чтобы быть легко доступным для разработчиков приложений.
Стандартный протокол обмена сообщениями, используемый в Web-сервисах, называется SOAP (Simple Object Access Protocol). С его помощью определяются форматы запросов, направляемых к сервису, и получаемых от него ответов. Необходимо заметить, что SOAP не выполняет транспортных функций. В качестве транспортного протокола на сегодняшний день используются HTTP или JMS.
В технологии Web-сервисов используется несколько протоколов обеспечения безопасности. Спецификация безопасности Web-сервисов, обычно называемая WS-Security, основана на маркерной архитектуре защищенных коммуникаций. Сюда входят также спецификация WS-Policy, определяющая правила взаимодействия сервисов, и спецификация WS-Trust, определяющая доверительную модель защищенного обмена. Применятся также и ряд других спецификаций.
Спецификация Web-сервисов включает аспекты качества обслуживания. В части обработки транзакций это WS-Coordination, WS-BusinessActivity и WS-AtomicTransaction. Спецификация WS-ReliableMessaging определяет протоколы обмена сообщениями с гарантированной надежностью.
2.2.2 Корпоративная сервисная шина (ESB)
Взаимодействие между Web-сервисами в среде SOA осуществляется на основе корпоративной сервисной шины, выполняющей для сервисов роль общей распределительной сети. ESB, являющаяся центральным звеном среды SOA, должна быть исключительно надежной, высокодоступной и высокозащищенной.
ESB позволяет создавать сервисные интерфейсы как для новых, так и для имеющихся прикладных функций. Эти интерфейсы могут быть созданы либо непосредственно, либо с помощью так называемых адаптеров.
Кроме того, ESB может выполнять транспортировку и маршрутизацию сообщений между потребителями и поставщиками сервисов.
Как правило, ESB обеспечивает следующие функции:
- поддержка транспортировки сообщений между сервисами по нескольким протоколам, таким как JMS и HTTP;
- трансформация и маршрутизация сервисных запросов;
- обработка событий;
- поддержка стандартов сервисов (Web-сервисов);
- поддержка новых основанных на сервисах приложений и благодаря этому – новых технологий, таких как J2EE, .NET и т.п.;
- поддержка всех имеющихся приложений, моделей программирования и форматов данных.
2.3 Эталонная модель SOA
Эталонная модель SOA корпорации IBM, представленная на рисунке 2-2, включает все структурные элементы, описанные в предыдущем разделе. В дополнение к основным функциональным структурным элементам SOA включает:
- поддерживающие структурные элементы, обеспечивающие возможность интеграции с имеющейся информационной системой и информационными системами организаций-контрагентов;
- структурные элементы, обеспечивающие дополнительные функции управления и мониторинга;
- инфраструктурные сервисы, отвечающие нефункциональным требованиям.
Рисунок 2-2. Эталонная модель SOA корпорации IBM
Эталонная модель SOA корпорации IBM, изображенная на рисунке 2-2, описывает ключевые сервисы, предоставляемые всеобъемлющим SOA-решением масштаба предприятия, в число которых входят:
- сервисы разработки;
- сервисы инноваций и оптимизации бизнеса;
- корпоративная сервисная шина (ESB);
- сервисы взаимодействия;
- сервисы процессов;
- информационные сервисы;
- сервисы доступа;
- сервисы взаимодействия с контрагентами;
- сервисы бизнес-приложений;
- инфраструктурные сервисы;
- сервисы управления ИТ-сервисами.
Подробнее эти структурные элементы описаны в следующих разделах.
2.3.1 Сервисы разработки
Сервисы разработки – это существенный компонент любой масштабной интеграционной архитектуры. Они позволяют специалистам, вовлеченным в процесс разработки приложений для организации, создавать собственные элементы приложений в соответствии со своими знаниями, опытом и роли в организации.
Данные сервисы предоставляют следующие возможности специалистам:
- бизнес-аналитики могут анализировать требования, предъявляемые бизнес-процессами, с помощью инструментов моделирования, позволяющих изображать процессы и имитировать их ход;
- программные архитекторы могут моделировать структуры и поведение системы;
- специалисты по интеграции могут создавать оригинальные схемы взаимодействия в интеграционном решении;
- программисты могут реализовывать новую бизнес-логику, не будучи ограниченными требованиями относительно используемой платформы.
Сервисы разработки обеспечивают возможность совместной работы, в том числе совместной разработки приложений, и управления ресурсами для всех перечисленных категорий специалистов. Унифицированная платформа разработки имеет общий репозиторий и содержит набор функций, охватывающих все аспекты процесса разработки (например, средства управления версиями, управления проектами и так далее).
2.3.2 Сервисы инноваций и оптимизации бизнеса
Сервисы инноваций и оптимизации бизнеса позволяют осуществлять мониторинг на основе объединения операционных и процессных матриц для эффективного управления системами и процессами (как информационно-технологическими, так и бизнес-процессами).
Это достигается благодаря всестороннему набору сервисов, отвечающих за сбор и представление данных уровня как информационных систем, так и процессов. Получаемые представления, относящиеся к уровням управления, администрирования и другим, используются для управления системными ресурсами и бизнес-процессами.
Общей чертой сервисов разработки и сервисов инноваций и оптимизации бизнеса является способность передавать данные и статистику периода исполнения в среду разработки, что позволяет проводить анализ и многократный реинжиниринг процессов, реализуя таким образом непрерывный цикл их улучшения.
2.3.3 Корпоративная сервисная шина (ESB)
Центральным звеном эталонной модели SOA является корпоративная сервисная шина (ESB). Этот архитектурный компонент обеспечивает все аспекты взаимодействия, необходимые для использования реализованных сервисов. ESB обеспечивает следующие фундаментальные сервисы:
- транспортные сервисы – базовый уровень взаимодействия;
- сервисы событий, позволяющие системе реагировать на конкретные события, являющиеся частью бизнес-процесса;
- промежуточные сервисы, такие как трансформационные и валидационные, позволяющие избежать сильной связанности между взаимодействующими сервисами системы.
Однако главная ценность концепции ESB в том, что она позволяет реализовать инфраструктуру для SOA таким образом, что будут учтены все нужды современной организации: обеспечить надлежащие качество обслуживания и управляемость, а также возможность работы и необходимые условия для интеграции в гетерогенной среде.
Рисунок 2-3. Корпоративная сервисная шина
ESB должна допускать замену одной реализации сервиса другой без какого-либо влияния на процесс обслуживания потребителей данного сервиса. Для этого сервисные интерфейсы, определенные SOA, должны быть реализованы так, чтобы клиентский код мог обращаться к сервису вне зависимости от того, где этот сервис находится и какой используется коммуникационный протокол.
На рисунке 2-3 изображено высокоуровневое представление корпоративной сервисной шины.
ESB является не единственным инфраструктурным компонентом SOA. И хотя в конкретных случаях детали реализации могут различаться, существует еще несколько часто используемых инфраструктурных компонентов, роль которых связана с ESB.
- Директория бизнес-сервисов, представляющая для участвующих в SOA систем таксономию и детализацию сервисов. Для того чтобы выполнять маршрутизацию сообщений между сервисами, ESB, очевидно, требуется определенный минимум маршрутной информации, который может быть обеспечен директорией пространства имен ESB или более простым средством, таким как таблица маршрутизации. Помимо предоставления маршрутной информации роль директории бизнес-сервисов заключается и в том, чтобы обеспечить детализацию сервисов, доступных для реализации бизнес-функций, определенных таксономией. Директория должна соответствовать открытому стандарту UDDI, либо может быть реализована в более простой форме, например в виде каталога сервисов периода проектирования, возможно с использованием технологии совместной работы. Такие каталоги выполняют лишь одну из главных функций директории бизнес-сервисов: декларирование доступности сервисов и поддержание их многократного использования в ходе деятельности по разработке ПО в организации.
- Согласование бизнес-сервисов, используемое для настройки последовательности сервисных взаимодействий как для краткосрочных, так и для долгосрочных бизнес-процессов.
- Шлюз ESB, используемый для организации контролируемой точки внешнего доступа к сервисам в тех случаях, когда ESB не поддерживает прямой доступ. В крупных организациях целесообразно выделить шлюз ESB в отдельный компонент. Шлюз можно также использовать для объединения сервисных шин в рамках организации.
Дополнительную информацию о ESB можно найти в справочнике (Ресурсы, [2]).
2.3.4 Сервисы взаимодействия
Сервисы взаимодействия обеспечивают возможности, необходимые для предоставления конечным пользователям доступа к ИТ-функциям и данным с учетом их индивидуальных нужд и предпочтений.
2.3.5 Сервисы процессов
Сервисы процессов – это сервисы контроля и управления, обеспечивающие интеграцию и автоматизацию бизнес-процессов, в которые вовлечены сотрудники, потоки данных, приложения, различные системы и платформы. Данные сервисы объединяют процессы в единое согласованное приложение.
2.3.6 Информационные сервисы
Информационные сервисы обеспечивают функции, требующиеся для объединения, репликации, интеграции, анализа и трансформирования источников данных. Функции могут быть реализованы различными способами. Эти сервисы предоставляют доступ к репозиториям данных посредством различных технологий – доступа к хранимым процедурам как к Web-сервисам, наделения нереляционных репозиториев данных стандартизованными интерфейсами, – а также других механизмов доступа, предоставляющих информацию как сервис.
2.3.7 Сервисы доступа
Сервисы доступа обеспечивают взаимодействие между унаследованными приложениями, пакетированными приложениями и хранилищами данных в организации. Эти сервисы обеспечивают доступ к функциям и данным имеющихся приложений, позволяя таким образом заново использовать их и встраивать в функциональные потоки бизнес-процессов.
2.3.8 Сервисы бизнес-приложений
Сервисы бизнес-приложений представляют собой рабочие модули, включаемые в интегрированную систему для обеспечения функционирования новых прикладных компонентов. Эти компоненты поддерживают новую бизнес-логику, необходимую для адаптации бизнес-процессов к новым потребностям организации.
2.3.9 Сервисы взаимодействия с контрагентами
Во многих организациях бизнес-процессы предусматривают взаимодействие с внешними партнерами и поставщиками. Интеграция собственных информационных систем с информационными системами контрагентов повышает эффективность цепочки создания прибавочной стоимости. Сервисы взаимодействия с контрагентами обеспечивают управление документами, протоколами и взаимодействием, необходимое для автоматизации процессов сотрудничества с другими организациями.
2.3.10 Сервисы управления ИТ-сервисами
Сервисы управления ИТ-сервисами обеспечивают функции безопасности, руководства, управления информационными системами, автоматизации и согласования на уровне сервисов, а также виртуализации. Как правило, инфраструктура для SOA и приложений в рамках этой архитектуры реализуется на основе нескольких различных платформ и технологий и потому является существенно более сложной, чем инфраструктура традиционных автономных приложений.
2.3.11 Инфраструктурные сервисы
Инфраструктурные сервисы предоставляют необходимые возможности для масштабирования, обеспечения производительности, безопасности, а также виртуализации ресурсов. Они включают технические средства и программное обеспечение для развертывания требуемых бизнес-сервисов и сервисной инфраструктуры. Производственная среда, как правило, требует высочайших уровней качества обслуживания, и инфраструктурные сервисы обеспечивают необходимое качество.
Многие инфраструктурные сервисы и сервисы управления ИТ-сервисами выполняют функции, непосредственно привязанные к конкретным техническим средствам или системным реализациям; другие содержат функции, взаимодействующие непосредственно с интеграционными сервисами, входящими в состав другого архитектурного элемента, с помощью ESB. Как правило, в это взаимодействие вовлечены сервисы, связанные с обеспечением безопасности, администрированием и управлением информационными системами.
2.4 Развертывание компонентов SOA
В предыдущих разделах был приведен подробный обзор обязательных и факультативных структурных элементов SOA.
В данном разделе рассматриваются характеристики развертывания сервис-ориентированной архитектуры. Развертывание в данном случае связано с выбором конкретных технических и программных средств для реализации того или иного компонента и факторами, которые при этом следует принять во внимание.
2.4.1 Соответствие эталонной модели SOA требованиям к ИТ
Постановка в соответствие архитектурным элементам конкретных технических и программных средств в первую очередь определяется функциональными и нефункциональными требованиями. Структурные элементы, составляющие эталонную модель SOA, определяются таким образом, чтобы обеспечивать соответствие этим требованиям.
Данные требования были перечислены в разделе 1.4 «Что же такое SOA на самом деле?».
Эталонная модель SOA отвечает всем указанным требованиям.
Соответствие ИТ задачам управления
Сервисы процессов обеспечивают контроль над ходом бизнес-процессов, скомпонованных из ИТ-сервисов и неавтоматизированных операций. Они максимально приближают ИТ-процессы к бизнес-процессам, используя интеграцию с неавтоматизированными операциями, а также предоставляют средства для контроля и коррекции процессов. Сервисы взаимодействия с контрагентами обеспечивают возможность интеграции бизнес-процессов с процессами организаций-партнеров.
Инфраструктурная поддержка перечисленных функций основана на сервисах управления ИТ-сервисами, позволяющих осуществлять контроль ИТ-сервисов на должном уровне детализации. Инфраструктура должна также обеспечивать масштабируемость, включая динамическое выделение ресурсов тем процессам, которые в этом нуждаются по условиям функционирования.
Обеспечивая тесную согласованность ИТ-сервисов с бизнес-процессами и, кроме того, располагая средствами для интегральной оценки и управления данными сервисами и процессами на уровне как бизнеса, так и ИТ, SOA дает более точное соответствие ИТ задачам управления, чем удавалось достигнуть другими способами.
Простота интеграции
Многие интеграционные проекты до сих пор реализуются на основе проприетарных интеграционных технологий. Чтобы обеспечить независимость от производителя, а также бесшовную интеграцию как с новыми, так и с имеющимися платформами, новые информационные системы и коммуникационные протоколы должны быть основаны на открытых стандартах.
Простота интеграции достигается благодаря использованию стандартизованной интеграционной платформы. Такая платформа делает возможной интеграцию набора разнообразных ИТ-ресурсов, имеющихся в организации, с вновь разработанными приложениями и новыми бизнес-процессами. Стандарты, на которых эта платформа основана, такие как Web-сервисы, позволяют выполнять бесшовную интеграцию с информационными системами организаций-контрагентов, а также с перспективными информационными системами.
ESB – это магистраль, обеспечивающая взаимодействие ИТ-сервисов на основе стандартов. Другие структурные элементы предоставляют доступ к этим сервисам через ESB на основе тех же стандартов либо используют конвертирующие сервисы, входящие в компонент «сервисы доступа», либо трансформационные и конвертирующие сервисы ESB.
Целостный взгляд на ИТ-ресурсы и административное управление ими
Потребность в интегрированном взгляде на ИТ-ресурсы и административном управлении ими возникла из необходимости обеспечить соответствие информационных технологий процессам создания прибавочной стоимости. Административное управление обеспечивает структурированное представление для расстановки приоритетов в достижении бизнес-целей и создания ИТ-стратегии.
Необходимость в административном управлении ИТ-ресурсами возникла раньше, чем появилась концепция SOA, однако она становится здесь более выраженной, поскольку интеграция многочисленных приложений угрожает превратить ИТ-среду в неуправляемое переплетение связей (см. рис. 1-3). Реализовать в полной мере преимущества SOA можно только лишь уделив достаточное внимание административному управлению; в противном случае эта архитектура станет лишь еще одним способом интеграции приложений (см., например, Ресурсы, [3], [4]).
Сервис-ориентированная архитектура обладает рядом свойств, поддерживающих представление автоматизированных бизнес-процессов на уровне управления. Концепция SOA, в частности благодаря обеспечиваемой компонентом «сервисы процессов» концентрации на управлении бизнес-процессами, позволяет бизнес-аналитикам моделировать процессы и декомпозировать их, выделяя автоматизированные и неавтоматизированные составляющие. При этом процессы можно конструировать и реализовывать их с точки зрения задач управления. Сервисы процессов и бизнес-моделирования позволяют использовать имеющиеся ИТ-ресурсы в новых процессах. Менеджер, располагающий такими сервисами, способен принимать решения на уровне всей организации с учетом многократного использования сервисов и, как следствие, поддерживающих их информационных систем. Функции мониторинга бизнес-процессов позволяют контролировать как реализованные процессы, так и любые изменения в них, вызванные изменением требований бизнеса.
Инфраструктурные сервисы управления ИТ-сервисами обеспечивают поддержку описанной модели функционирования организации благодаря возможностям управления и мониторинга сервисов информационных систем с учетом поддерживаемых этими системами бизнес-процессов.
Многократное использование ИТ-ресурсов
Имеющиеся ИТ-ресурсы, будь то прикладные программы или данные, могут быть использованы многократно, для чего их следует сделать доступными для стандартных приложений в составе композитного бизнес-процесса с помощью сервисов процессов. Таким образом, сервисы доступа обеспечивают многократную отдачу от инвестиций, сделанных в ИТ-ресурсы.
Эти сервисы должны быть максимально надежными и эффективными, для чего следует оптимизировать платформу, на которой они базируются. Поскольку многократное использование ресурсов повышает интенсивность нагрузки на соответствующие программы и оборудование, требования к качеству обслуживания возрастают.
2.4.2 Качество обслуживания и другие требования к инфраструктуре
В разделе 1.3 «Влияние на ИТ» мы обсудили влияние современных требований бизнеса на ИТ. В предыдущем разделе мы рассмотрели, как эталонная модель SOA обеспечивает соответствие функциональным требованиям. Есть также ряд менее явных нефункциональных требований, возлагаемых на SOA.
Экономическая эффективность и прозрачность могут быть достигнуты лишь в том случае, если инфраструктура и среда управления сервисами обеспечивают средства оценки ИТ-затрат с достаточной степенью детализации и для всех компонентов, составляющих инфраструктуру. Это предъявляет особые требования к инфраструктурным сервисам и сервисам управления ИТ-сервисами. Указанные структурные элементы должны содержать средства оценки требований конкретных сервисов и компонентов и предоставлять их в виде сводных отчетов для менеджеров.
Бизнес-процессы требуют известной надежности. Информационные системы должны обеспечивать достаточную надежность для поддержки соответствующих им бизнес-процессов.
Надежность складывается из следующих аспектов, обеспечиваемых инфраструктурными сервисами:
- предсказуемой и постоянной производительности, соответствующей требованиям бизнес-процессов. Это особенно важно в случае SOA, так как обеспечиваемые ею сервисы могут использоваться различными потребителями с растущей интенсивностью. В зависимости от колебаний спроса от сервисов могут требоваться различные характеристики;
- мощности, тесно связанной с постоянством производительности. ИТ-инфраструктура должна быть масштабируемой, чтобы быть в состоянии удовлетворить возрастающие потребности в таких условиях, как пиковые объемы транзакций, а также поддерживать, например, функционирование в ходе маркетинговых кампаний, когда из-за большого числа обращающихся в компанию потенциальных потребителей может значительно увеличиться нагрузка как на системы взаимодействия, так и на системы основной обработки данных, входящие в состав общей сервис-ориентированной информационной системы;
- надежности и стабильности операционной среды. Здесь мы говорим о технической надежности, определяемой средним временем наработки на отказ, а также о способности к восстановлению после отказа без прерывания процесса обработки данных. В рамках SOA готовность сервиса зависит от всех компонентов, обеспечивающих его функционирование. Это увеличивает требования к готовности тех операционных сред, на базе которых размещаются сервисы;
- целостности. Слабая связанность, характеризующая SOA, может иметь следствием утрату контроля над целостностью транзакций, в которых задействованы несколько сервисов по поддержке бизнес-процесса. Поэтому должны использоваться специальные технологии, поддерживающие целостность транзакций;
- безопасности. Условия безопасности, которым должна отвечать SOA, предъявляют особые требования к технологической платформе, на которой эта архитектура развертывается. Информационные системы и ИТ-инфраструктура должны обеспечивать уровень безопасности, достаточный для поддерживаемых ими бизнес-процессов. Меры по обеспечению безопасности включают использование всех необходимых сервисов, таких как аутентификация, авторизация, предотвращение отказов, обеспечение конфиденциальности, криптографическая защита, защита персональных данных и других.
 |
2.5 Характеристики развертывания: подведение итогов
В данной главе мы показали, каким требованиям должна отвечать среда развертывания SOA, а также как эталонная модель SOA и операционная среда, в которой эта архитектура развертывается, обеспечивают соответствие данным требованиям. Технологии, поддерживающие SOA и операционную среду, должны обеспечивать:
- экономически эффективную вычислительную платформу;
- функции отчетности, журналирования и аудита;
- постоянную и предсказуемую производительность;
- предоставление вычислительных мощностей по требованию;
- основанную на стандартах интеграционную платформу;
- централизованное управление платформой;
- многократное использование ИТ-ресурсов;
- надежную информационную среду;
- целостность;
- безопасность.
Указанные атрибуты составляют третий уровень нашей диаграммы, как показано на рис. 2-4.
Рисунок 2-4. Характеристики развертывания SOA
Нефункциональные требования должны быть обеспечены инфраструктурой, являющейся фундаментом для архитектуры. В следующей главе мы покажем, как развертывание компонентов SOA на платформе z/OS позволяет соблюсти все предъявляемые требования.
| 
