Ослабленная связь

В вычислительной технике и проектировании систем система слабосвязанная — это одна из

в котором компоненты слабо связаны (имеют разрывные связи) друг с другом, и, таким образом, изменения в одном компоненте меньше всего влияют на существование или производительность другого компонента.
в котором каждый из его компонентов имеет или использует мало или совсем не знает определений других отдельных компонентов. Подобласти включают связь классов . , интерфейсов, данных и сервисов ^[1] Слабая связь является противоположностью жесткой связи.

Преимущества и недостатки

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

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

В интеграции

Слабая связь в более широком проекте распределенной системы достигается за счет использования транзакций, очередей, обеспечиваемых промежуточным программным обеспечением, ориентированным на сообщения , и стандартов совместимости. ^[2]

Четыре типа автономии, которые способствуют слабой связи: автономия ссылок , автономия времени , автономия формата и автономия платформы . ^[3]

Слабая связь — это архитектурный принцип и цель проектирования сервис-ориентированных архитектур . Одиннадцать форм слабой связи и их аналоги с сильной связью перечислены в: ^[4]

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

Промежуточное программное обеспечение Enterprise Service Bus (ESB) было изобретено для достижения слабой связи во многих измерениях. ^[5] Однако перепроектированные и неправильно расположенные ESB также могут иметь противоположный эффект и создавать нежелательную тесную связь и центральную архитектурную горячую точку.

Архитектура, управляемая событиями, также направлена на обеспечение слабой связи. ^[6]

Методы уменьшения связи

Слабую связь интерфейсов можно улучшить, публикуя данные в стандартном формате (например, XML или JSON ).

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

Слабую связанность сервисов можно улучшить, сократив информацию, передаваемую в сервис, до ключевых данных. Например, сервис, отправляющий письма, наиболее пригоден для повторного использования, когда передается только идентификатор клиента и получается адрес клиента внутри сервиса. Это отделяет службы, поскольку службы не нужно вызывать в определенном порядке (например, GetCustomerAddress, SendLetter).

В программировании

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

Примером жесткой связи является ситуация, когда зависимый класс содержит указатель непосредственно на конкретный класс, обеспечивающий требуемое поведение. Зависимость не может быть заменена или ее «сигнатура» изменена без внесения изменений в зависимый класс. Слабая связь возникает, когда зависимый класс содержит указатель только на интерфейс, который затем может быть реализован одним или несколькими конкретными классами. Это известно как инверсия зависимостей . Зависимость зависимого класса связана с «контрактом», указанным в интерфейсе; определенный список методов и/или свойств, которые должны предоставлять реализующие классы. Таким образом, любой класс, реализующий интерфейс, может удовлетворить зависимость зависимого класса без необходимости изменения класса. Это обеспечивает расширяемость разработки программного обеспечения. Новый класс, реализующий интерфейс, может быть написан для замены текущей зависимости в некоторых или всех ситуациях, не требуя изменения зависимого класса; новые и старые классы можно свободно менять местами. Сильная связь не позволяет этого сделать.

Это UML- диаграмма, иллюстрирующая пример слабой связи между зависимым классом и набором конкретных классов, обеспечивающих требуемое поведение:

Для сравнения на этой диаграмме показан альтернативный вариант с сильной связью между зависимым классом и поставщиком:

Другие формы

Языки компьютерного программирования, в которых понятия либо о функциях как о базовом модуле (см. Функциональное программирование ), либо о функциях как об объектах, представляют собой превосходные примеры слабосвязанного программирования. В функциональных языках есть шаблоны продолжений , замыканий или генераторов. См. Clojure и Lisp как примеры функциональных языков программирования. Объектно-ориентированные языки, такие как Smalltalk и Ruby, имеют блоки кода, а Eiffel — агенты. Основная идея состоит в том, чтобы объективировать (инкапсулировать в объект) функцию, независимую от любого другого включающего понятия (например, отделить объектную функцию от любого прямого знания включающего объекта). См. «Функция первого класса» для получения более подробной информации о функциях как объектах, что квалифицируется как одна из форм функции первого класса.

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

Телефонные номера являются отличным аналогом и могут легко проиллюстрировать степень этого разделения.

Например, одна организация предоставляет другой номер телефона для выполнения определенной работы. Когда набирают этот номер, вызывающая сущность фактически говорит: «Пожалуйста, сделайте для меня эту работу». Развязка или слабая связь сразу бросаются в глаза. Субъект, получающий номер, может не знать, откуда взялся этот номер (например, ссылка на поставщика номера). С другой стороны, вызывающий абонент отделен от конкретных знаний о том, кому он звонит, где он находится, а также от знания того, как внутри страны действует получатель вызова.

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

Связь между слабосвязанными компонентами может основываться на множестве механизмов, таких как упомянутый асинхронный стиль связи или синхронной передачи сообщений . стиль ^[7]

Связь элементов измерительных данных

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

Добавление новых элементов данных в сообщения
Изменение порядка элементов данных
Изменение названий элементов данных
Изменение структур элементов данных
Пропуск элементов данных

См. также

Ссылки

^ Слабая связь: недостающие части веб-сервисов Дуга Кея
^ Паутассо К., Уайльд Э., Почему Сеть слабосвязана? Архивировано 12 октября 2021 г. в Wayback Machine , Proc. WWW 2009 г.
^ Ф. Лейманн «Свободная связь и архитектурные последствия». Архивировано 2 октября 2016 г. в Wayback Machine , основной доклад ESOCC 2016.
^ Н. Джосуттис, SOA на практике. О'Рейли, 2007 г., ISBN 978-0-596-52955-0 .
^ М. Кин и др., Шаблоны: реализация SOA с использованием корпоративной сервисной шины , IBM, 2004 г.
^ Как EDA расширяет SOA и почему это важно Джек ван Хоф
^ Миэль, Грегуар. «Шаблоны микросервисов: синхронная и асинхронная связь» . Шаблоны микросервисов: синхронная и асинхронная связь . греег . Проверено 18 февраля 2022 г.

[1] Слабая связь: недостающие части веб-сервисов Дуга Кея

[2] Паутассо К., Уайльд Э., Почему Сеть слабосвязана? Архивировано 12 октября 2021 г. в Wayback Machine , Proc. WWW 2009 г.

[3] Ф. Лейманн «Свободная связь и архитектурные последствия». Архивировано 2 октября 2016 г. в Wayback Machine , основной доклад ESOCC 2016.

[4] Н. Джосуттис, SOA на практике. О'Рейли, 2007 г., ISBN 978-0-596-52955-0 .

[5] М. Кин и др., Шаблоны: реализация SOA с использованием корпоративной сервисной шины , IBM, 2004 г.

[6] Как EDA расширяет SOA и почему это важно Джек ван Хоф

[Mielle-7] Миэль, Грегуар. «Шаблоны микросервисов: синхронная и асинхронная связь» . Шаблоны микросервисов: синхронная и асинхронная связь . греег . Проверено 18 февраля 2022 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]