Book.od.ua Книги для вашего бизнеса



Одесская библиотека бизнес литературы
полезные книги для бизнеса

1.5. Слабое связывание

Одним из наиболее популярных терминов в области интеграции корпоративных приложений является термин слабое связывание. Дуг Кэй (Doug Куге) посвятил этой вездесущей концепции целую книгу. Преимущества слабого связывания были известны давно, однако ключевое место эта концепция заняла благодаря растущей популярности архитектур на основе Web-служб.
Основной принцип слабого связывания состоит в уменьшении числа допущений, которые делают друг о друге взаимодействующие стороны (компоненты, приложения, службы, программы, пользователи). Несмотря на то что наличие дополнительной информации об участниках и используемом протоколе позволяет повысить эффективность общения, получаемое при этом решение крайне неустойчиво к изменениям.
Наглядным примером сильного связывания является вызов локального метода, осно­вывающийся на огромном числе допущений между вызываемой и вызывающей подпрограммами. Оба метода должны выполняться в одном и том же процессе (например, виртуальной машине) и быть написаны на одном и том же языке программирования (по крайней мере, использовать общий промежуточный язык или байт-код). Вызывающий метод передает вызываемому методу заранее известное число параметров определенного типа. Вызов локального метода происходит мгновенно, т.е. вызываемый метод получает управление сразу же после осуществления его вызова. Вызывающий метод может продолжить свое выполнение только после завершения работы вызываемого метода (таким образом, вызов локального метода является примером синхронного взаимодействия). Выполнение вызывающего метода будет продолжено с оператора, следующего непосредственно после вызова метода. Мгновенный характер взаимодействия между вызываемым и вызывающим методами позволяет исключить возможность нарушения безопасности. Все эти предположения способствуют разработке хорошо структурированных приложений, функциональность которых разделяется между множеством вызывающих друг друга методов. Наличие большого числа простых методов обеспечивает возможность их повторного использования и как следствие - гибкость приложения.
Большое число подходов к интеграции приложений основывается на реализации удаленного взаимодействия с использованием семантики вызова локального метода. Данная стратегия получила название вызов удаленной процедуры (Remote Procedure Call - RPC) или вызов удаленного метода (Remote Method Invocation - RMI) и была поддержана разработчиками различных популярных платформ и инфраструктур: CORBA [51], Microsoft DCOM, .NET Remoting, Java RMI и, наконец, Web-служб в стиле RPC. Реализация удаленного взаимодействия с использованием семантики вызова локального метода имеет два очевидных преимущества. Во-первых, семантика синхронного вызова метода очень хорошо известна разработчикам приложений. Во-вторых, использование одинакового синтаксиса вызова локальных и удаленных методов позволяет отложить принятие решения о том, какие компоненты должны выполняться локально, а какие - удаленно, вплоть до развертывания приложения.
К сожалению, удаленное взаимодействие несовместимо со многими предположениями, касающимися вызова локального метода. Более того, использование одинаковой семантики для вызова локального и удаленного методов ошибочно и может привести к нежелательным результатам. Еще в 1994 году Вальдо (Waldo) и его коллеги из Sun Microsystems предупреждали о том, что ''методы работы с объектами, взаимодействующими в распределенной системе, существенно отличаются от методов работы с объектами, взаимодействующими в общем адресном пространстве'' [50]. Следует ли приложению использовать только те удаленные службы, которые написаны на одинаковом с ним языке программирования? Вызов удаленного метода может потребовать на несколько порядков больше времени, чем вызов локального метода. Должен ли вызывающий метод ожидать завершения выполнения вызываемого метода? Что если в результате сбоя в сети вызываемый метод окажется временно недоступным? Как долго следует ждать? Можно ли быть уверенным в том, что мы вызываем нужный нам, а не ''подставной'' метод? Как исключить возможность подслушивания? Что произойдет в результате изменения сигнатуры (списка принимаемых параметров) вызываемого метода? Следует отметить, что в случае поддержки удаленного метода третьей стороной (например, бизнес-партнером) подобные изменения выходят за пределы нашего контроля. Можно ли допустить сбой вызова метода или необходимо попытаться подобрать параметры, позволяющие осуществить вызов? Становится очевидно, что удаленное взаимодействие нельзя организовывать в соответствии с теми же допущениями, что и локальный вызов метода.
Результатом применения архитектур, основанных на сильном связывании, при интеграции удаленных приложений являются неустойчивые, трудно поддерживаемые и плохо масштабируемые решения. Многие из ''пионеров'' Web-служб убедились в этом на собственном горьком опыте.


Понравился материал? Поделитесь с друзьями!

<< Предыдущая статьяСледующая статья >>
1.4. Роль интеграционных шаблонов проектирования. Продолжение. 1.6. Пример простой интеграции





Убедительная просьба при использовании любых материалов Одесской электронной бизнес-библиотеки ставить активную ссылку на наш сайт. По всем вопросам касательно сайта пожалуйста пишите на почту
      Карта сайта