Файл: Инфрам.pdf

74 осуществить поиск в базе данных. Когда поиск закончен, она посылает результат вместе с идентификатором терминала подсистемы редактиро- вания и выдачи.
Рис. 2.15. Архитектура системы на основе портов непрямой конфигурации
Рис. 2.16. Информационно-поисковая система прямой конфигурации
2.8.3. Архитектуры, основанные на потоках данных
По сути, эти архитектуры являются современным вариантом рас- смотренных архитектур, управляемых портами сообщений. В общем случае архитектуры, основанные на потоках данных, представляются как совокупность процессов, каждый из которых принимает данные из различных источников, а также возвращает данные в другие источники или хранилища данных. Процессы проектируются независимо друг от друга. Такие архитектуры давно используются и изображаются с помо- щью диаграмм потоков данных (DFD-диаграммы). Метамодель диа- граммы потоков данных приведена на рис. 2.17.

75
Рис. 2.17. Метамодель диаграммы потоков данных
Как разновидность таких архитектур рассматриваются архитектуры типа каналы и фильтры, в которых процессы называются фильтрами, а потоки направляются через каналы.
2.8.4. Архитектуры независимых компонентов
Программные системы такой архитектуры состоят из независимо ра- ботающих компонентов, время от времени общающихся друг с другом.
Компонент, называемый клиентом, выдает запрос для выполнения како- го-либо действия к другому компоненту, называемому сервером. Такое отношение называется клиент-серверным. Интерфейс сервера должен быть собран в одном месте и четко определен. Преобладание таких от- ношений характерно для клиент-серверной архитектуры. Классическая двухуровневая архитектура клиент-сервер постоянно усложнялась до- бавлением новых уровней. Отдельный уровень может управлять проце- дурами (сервер приложений), другой - данными (сервер баз данных в трехуровневой архитектуре).
Значительную роль в разработке систем на основе архитектуры не- зависимых компонентов сыграл международный консорциум OMG
(Object Management Group) [5]. Дело в том, что в мире существует гро- мадное количество готовых к использованию информационно- вычислительных ресурсов. Они создавались в разное время, для их раз- работки использовались разные подходы. Почти всегда при разработке новой информационной системы можно найти подходящие по своим функциям уже работающие готовые компоненты. Проблема состоит в том, что при их создании не учитывались требования интероперабель- ности. Эти компоненты не понимают один другого, они не могут рабо- тать совместно. Желательно иметь механизм или набор механизмов, которые позволят сделать такие независимо разработанные информаци- онно-вычислительные ресурсы интероперабельными.
Одно из наиболее признанных решений проблемы унаследованных систем основывается также на объектно-ориентированном подходе. Ос- новной задачей OMG является разработка архитектуры и методов реа- лизации программного обеспечения, которое в объектно- ориентированном стиле позволило бы выполнить интеграцию сущест- вующих и заново разрабатываемых (не обязательно объектно- ориентированных) информационно-вычислительных ресурсов. OMG регулярно выпускает спецификационные документы, которые становят- ся фактическими промышленными стандартами. Основными состав- ляющими подхода OMG являются базовая объектная модель (Core
Object Model), эталонная модель архитектуры OMA (Object Management

76
Architecture) и более приближенная к реализации общая архитектура брокера объектных заявок CORBA (Common Object Request Broker
Architecture).
На рис. 2.18 приведена эталонная модель метаобъектного средства
OMG. На нижнем уровне находятся отдельные объекты. Объектные типы определяют общие свойства схожих объектов. Объектные типы в свою очередь являются экземплярами метаобъектной модели. С помо- щью этой метамодели описываются архитектуры OMG/CORBA,
Microsoft/COM и Java/RMI [26].
Рис. 2.18. Эталонная модель метаобъектного средства OMG
Идея CORBA довольно проста. Она заключается в следующем. Во- первых, в каждый объект, который должен быть включен в интегриро- ванную объектную систему, добавляется специальный программный код, обеспечивающий принципиальную возможность взаимодействия объектов. Этот код генерируется автоматически за счет использования определенного OMG языка определения объектных интерфейсов IDL
(Interface Definition Language). В исходный текст программы включают- ся спецификации интерфейса на языке IDL. Затем этот текст должен быть обработан специальным прекомпилятором, который и генерирует дополнительный программный код. Заметим, что на сегодняшний день в документах OMG определены правила встраивания конструкций IDL в далеко не все языки программирования, но, по крайней мере, опреде- лены правила встраивания для таких популярных языков как С и С++.
Во-вторых, для реального взаимодействия должным образом настро- енных объектов предполагается наличие специального программного обеспечения, называемого в документах OMG брокером объектных зая- вок ORB (Object Request Broker). Брокер объектных заявок должен су- ществовать и на стороне вызывающего объекта, и на стороне вызывае- мого объекта. Основная задача ORB состоит в том, чтобы доставить заявку на вызов метода вызываемого объекта и возвратить результаты выполнения метода вызываемому объекту.
В настоящее время CORBA является индустриальным стандартом, описывающим высокоуровневые средства поддержки взаимодействия объектов в распределенных гетерогенных средах. Этот стандарт специ- фицирует инфраструктуру взаимодействия компонентов на представи- тельском уровне и уровне приложений модели OSI, позволяя рассмат- ривать все приложения в распределенной системе как объекты. Практи- ка показывает, что большинство объектов одновременно исполняют роль и клиентов и серверов, позволяя тем самым с помощью CORBA, строить гораздо более гибкие системы, чем системы клиент-сервер, ос- нованные на двухуровневой и трехуровневой архитектуре.

77 2.8.5. Сервис-ориентированные архитектуры (SOA)
В последнее время быстро набирает вес и де-факто становится стан- дартом для создания распределенных приложений технология Web- сервисов [20]. В основе SOA лежат принципы многократного использо- вания функциональных элементов информационных технологий, лик- видации дублирования функциональности в программной системе, унификации типовых операционных процессов, обеспечения перевода операционной модели компании на централизованные процессы и функциональную организацию на основе промышленной платформы интеграции.
Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соот- ветствии с SOA, часто реализуются как набор веб-сервисов, интегриро- ванных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.).
В принципе архитектуру этого типа можно отнести к архитектуре независимых компонент. Основное достоинство такого рода сервисов – это простота создания. Упрощается и взаимодействие между компонен- тами, поскольку основным транспортным протоколом является http.
Приложение может без проблем работать не только в Intranet-, но и в
Internet-сетях. Кроме того, эта технология не привязана к какой-либо одной платформе, что открывает возможность создания распределенных приложений в гетерогенных средах. Технология интегрирована с техно- логией DOT.NET.
Ключевой аспект, который отличает Web-сервисы от протоколов пе- редачи двоичных данных в моделях программирования таких, как
CORBA и DCOM: Web-сервисы – это технология работы с сообщения- ми, в которой передача сообщений основана на XML (SOAP), и сами
Web-сервисы описываются на XML (WSDL). Логическим продолжени- ем технологии Web-сервисов стала архитектура, ориентированная на сервисы (SOA).
Ее появление является следствием новых задач и потребностей, воз- никающих при создании и эксплуатации современных информационных систем: оперативное реагирование на изменение требований и быстрая адап- тация к новым задачам; оптимизация управления бизнес-процессами; эффективное обеспечение внешних взаимодействий.
К основным характеристикам SOA, отличающим ее от других архи- тектур информационных систем, следует отнести: распределенность; слабосвязанные интерфейсы (отсутствие жестких связей между элементами системы), что упрощает конфигурирование системы и координирование работы ее элементов; базирование архитектуры на международных открытых стандартах;

78 возможность динамического поиска и подключения нужных функ- циональных модулей; построение систем с расчетом на процессы с использованием серви- сов, ориентированных на решение определенных бизнес-задач.
Метамодель SOA (рис. 2.19) включает следующие модели: модель политик (PM) определяет политики, связанные с архитекту- рой, в основном она представляет собой ограничения, накладывае- мые на поведение агентов и сервисов, в том числе ограничения, свя- занные с требованиями безопасности и качества обслуживания; модель, ориентированная на сервисы (SOM), сосредоточена на дей- ствиях, выполняемых сервисами; модель, ориентированная на ресурсы (ROM), сосредоточена на сис- темных ресурсах; модель, ориентированная на сообщения (MOM), сосредоточена на сообщениях, их структуре, способах транспортировки и других ком- понентах, никак не связанных с причинами обмена сообщениями и их семантикой.
Рис. 2.19. Метамодель SOA
Важную роль в этой архитектуре отводится управлению Web- сервисами, к основным функциям которого относятся развертывание, конфигурирование, обеспечение безопасности, а также функции мони- торинга и диагностики. Уже реализуется скоординированное движение к обеспечению управления Web-сервисами как ресурсом. Стандарт, к которому стремится большинство поставщиков, – это Web Services for
Distributed Management (WSDM). В стандарт входит набор Web- сервисов и операций, которые должна будет обеспечивать каждая реа- лизация Web-сервиса, – операции для конфигурирования, мониторинга и других задач управления.
При необходимости внести изменения в интерфейс сервиса и про- вайдер, и пользователи Web-сервиса должны изменить свои среды од- новременно, что может оказаться затруднительным. Однако имеется возможность (и она реализована) ввести "посредника" между потреби- телем сервиса и его провайдером, что существенно повышает адапти- руемость и масштабируемость систем.

79
В сервисной архитектуре просматриваются черты традиционных ар- хитектур. С помощью сценарных языков типа BPEL можно описывать новые сервисы или описывать бизнес-процессы с участием сервисов
(виртуальная машина). Системы, реализованные в других стандартах
(например, CORBA) легко интегрируются в SOA (соответствующий инструментарий имеется).
SOA представляет собой не только основу для новых информацион- ных технологий, но также и новую системную философию. Постепен- ный переход от мэйнфреймов к конфигурациям типа "клиент-сервер" и далее к SОА означает глубокие изменения в функциональности систем, и, следовательно, создает новые возможности в областях применения информационных технологий. SOA имеет все шансы заменить со вре- менем монолитные корпоративные системы, сложные как во внедрении, так и в модернизации.

80