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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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