Архитектура распределенных систем программного обеспечения. Учебное пособие издано при поддержке образовательной программы Формирование

• Название: Учебное пособие издано при поддержке образовательной программы Формирование
• Анкор: Архитектура распределенных систем программного обеспечения
• Дата: 13.01.2023
• Размер: 1 Mb.
• Имя файла: mdwrbook.docx
• Тип: Учебное пособие; #885216
• страница: 20 из 36

Сетевые службы

1. Определение сетевых служб

Очень часто сетевой службой называют приложение, котороеможет быть доступно другим приложениям через Интернет. Более точное определение может быть таким: самодостаточное модульноебизнес приложение, имеющее открытый стандартизованныйинтерфейс, ориентированный на Интернет. Упор делается на согласованность со стандартами Интернета, от службы требуется открытость, то есть интерфейс, посредством которого она становится доступной в Интернете, должен быть опубликован. Однако некоторые вопросы остаются (что такое самодостаточность, модульность?).
Консорциум World Wide Web (W3C) дает такое определение: программное приложение, идентифицируемое с помощью универсального ресурсного идентификатора, интерфейс и способ связывания которого могут быть определены, описаны и выявлены как артефакты XML. Сетевая служба поддерживает прямое взаимодействие с другими программными агентами, используя обмен XML-сообщениями на базе Интернет-протоколов.
Этим определением поясняется, что значит доступность службы (определение, описание, выявление), а что значит ее ориентированность на Интернет. Здесь же указывается, что сетевая служба должна быть "службой" в смысле, похожем на трактовку этого термина традиционными платформами промежуточных слоев. Она должна быть достаточно точно описана, чтобы для связывания и взаимодействия с ней можно было писать клиентские программы. Сетевые службы могут интегрироваться в более сложные распределенные приложения. Консорциум W3C также настаивает на том, чтобы в определение сетевых служб был включен язык XML. Этот язык в настоящее время также широко распространен, как и протокол HTTP, и сетевые серверы.

2. Сетевые службы и интеграция приложений

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

заказчик третья сторона

адаптеры заказчика

система управления рабочим потоком (WfMS)

внутренний запрос
внутренняя инфраструктура



адаптер WfMS
брокер сообщений

"глобальный" поток работает здесь

поставщик
адаптеры поставщика

оптовый склад

адаптеры оптового склада
возможность взаимодействия обеспечивается комбинацией брокера сообщений и адаптеров

внутренняя инфраструктура

внутренняя инфраструктура

Рис.4.1.Интеграцияприложенийразличныхпредприятийвыполняетсятакже,каки интеграция систем внутри отдельного предприятия. Технически возможная, она редко применяется на практике из-за недостатка доверия и необходимости большей автономности.

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

промежуточный слой для интеграции промежуточных платформ
поставщик




Рис. 4.2. Отсутствие центральной промежуточной платформы приводит к необходимостивзаимодействияпопринципу"точка-точка",приэтомразличные стороны (возможно) взаимодействуют с использованием разных программных платформ.

Другой причиной непригодности традиционного подхода является неверность многих предположений, делавшихся при внутренней интеграции приложений предприятий. Одно из таких предположений заключалось в том, что многие акты взаимодействия внутри предприятия обычно являются короткими, в то время как взаимодействия с внешними партнерами могут требовать более длительных транзакций (часов или дней). Длительность взаимодействия препятствует применению традиционных протоколов типа 2PC, поскольку они блокируют ресурсы на слишком большой срок, делая невозможным параллельное выполнение других операций.

Развитие глобальной сети привело к появлению и массовому принятию новых стандартов, протоколов (HTTP), форматов (XML). Однако сами по себе эти стандарты не решили всех проблем. Для интеграции приложений на новом уровне потребовалось развить архитектуру программных систем, основанную на понятии "службы", перестроить протоколы взаимодействия интегрирующих слоев и разработать новые дополнительных стандарты.

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

С точки зрения использования сетевые службы не отличаются от служб программных систем промежуточных слоев, за исключением того, что к ним можно обращаться через Интернет и из других предприятий. Службы являются слабо связанными системами, поскольку в общем случае они определяются, разрабатываются и управляются разными компаниями. Развитие такого подхода приводит к тому, что все начинает восприниматься как служба, а различные службы автономны и не зависят друг от друга.

Невсе,чтодоступночерезИнтернет,представляетсобойсетевую службу. Сетевая служба – это не набор страниц в Интернете, а программное приложение с общеизвестным и стабильным программным интерфейсом.

Традиционные протоколы (например, 2РС) проектировались в предположении, что работа будет осуществляться внутри предприятий. Эти протоколы предполагали наличие центрального транзакционного координатора, который обладает возможностями блокировать ресурсы по собственному усмотрению. Протокол подтверждения 2РС должен быть модифицирован, чтобы приобрести возможность работать в полностью распределенном окружении и более гибко проводить блокировки ресурсов. Аналогичным образом требуется переработать все протоколы взаимодействия и координации, улучшая и другие свойства системного программного обеспечения, например, надежность.

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

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

информацией проводятся на основе единых стандартизованных протоколов, разработанных так, чтобы децентрализованно обеспечивать все свойства традиционных протоколов. Сетевые службы сами исполняют эти протоколы и скрывают от программистов все сложные проблемы интеграции приложений (Рис. 4.3).

заказчик

	сетевая служба
внутренний запрос внутренняя инфраструктура

стандартизованныеязыкиипротоколы

избавляютотнеобходимостииметь несколькоразныхпромежуточных инфраструктур (нужна только инфраструктура сетевых служб)
поставщик


сетевая служба



внутренняя инфраструктура

взаимодействие,основанное на децентрализованных протоколах
оптовый склад

сетевая служба
внутренняя инфраструктура

внутренняяфункциональность доступна в виде службы

Рис.4.3.Архитектура,ориентированнаянасетевыеслужбы,модернизированные

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

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

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