18
Взаимодействие и обмен сообщениями
Обзор
Одним из ключевых факторов, оказывающим влияние на дизайн приложения, особенно распределенного приложения, является дизайн инфраструктуры связи для каждой части приложения. Компоненты должны взаимодействовать, например, передавать пользовательский ввод в бизнес-слой и затем обновлять хранилище данных через слой доступа к данным. Когда компоненты физически располагаются на одном уровне, между ними возможно прямое взаимодействие. Однако при развертывании компонентов и слоев физически на разных серверах и клиентских компьютерах, как это происходит в большинстве сценариев, необходимо продумать, как обеспечить эффективное и надежное взаимодействие компонентов этих уровней.
Как правило, приходится выбирать между прямым взаимодействием (таким как вызов методов между компонентами) и связью посредством обмена сообщениями. В связи посредством обмена сообщениями множество преимуществ, таких как возможность разделения компонентов. Уменьшение связанности компонентов не только улучшает обслуживаемость, но также может обеспечить гибкость, что упростит изменение стратегии развертывания в будущем. Однако в связи с обменом сообщениями возникают такие проблемы, как производительность, надежность и безопасность.
В данной главе представлены рекомендации, которые помогут правильно выбрать подход к реализации связи; понять, как добиться наилучших результатов от выбранного подхода, и предугадать возможные проблемы в области безопасности и надежности. Однако основная часть этой главы посвящена проектированию подходящего механизма связи посредством обмена сообщениями. Здесь приводятся рекомендации по асинхронному и синхронному взаимодействию, выбору формата данных, обеспечению производительности, безопасности, возможности взаимодействия и выбору технологии реализации.
Общие принципы проектирования
При проектировании стратегии связи для приложения необходимо учесть, как влияет на производительность взаимодействие между слоями и уровнями. Поскольку любое взаимодействие через логические или физические границы повышает издержки на обработку,
проектирование должно обеспечить эффективную связь за счет сокращения обращений к сети и уменьшению объемов данных, передаваемых по сети. Разрабатывая стратегию связи, руководствуйтесь следующими рекомендациями:
Продумайте стратегии связи при пересечении границ. Продумайте все границы и то, как они влияют на производительность связи. Например, процесс компьютера, компьютер и переходы между управляемым и неуправляемым кодом – все это границы, которые могут пересекаться при взаимодействии компонентов приложения или внешних сервисов и приложений.
Используйте связь посредством обмена сообщениями при пересечении границ процесса. Для обеспечения максимальной производительности используйте
Windows Communication Foundation (WCF) и TCP или протокол именованных каналов.
Используйте связь посредством обмена сообщениями при пересечении физических границ. Используйте WCF для организации связи через физические границы с удаленными компьютерами. Используйте Microsoft Message Queuing для обеспечения надежной одноразовой доставки сообщений.
Обеспечьте максимальную производительность и скорость ответа при доступе к удаленным слоям. При взаимодействии с удаленными слоями используйте слабо детализированные методы взаимодействия посредством обмена сообщениями для сокращения требуемого объема информационного обмена, а также по возможности применяйте асинхронное взаимодействие, чтобы избежать блокировки UI или перехода его в состояние «не отвечает».
Для форматов данных, передаваемых через границы, учтите возможности сериализации. Если необходимо обеспечить возможность взаимодействия с другими системами, используйте сериализацию XML. Не забывайте, что сериализация XML обусловливает дополнительные издержки. Если производительность является основным фактором, используйте бинарную сериализацию, потому что она более производительна и размер получаемых в результате сериализованных данных меньше, чем у их XML-эквивалента.
Обеспечьте защиту сообщений и конфиденциальных данных при взаимодействии. Используйте шифрование, цифровые сертификаты и средства обеспечения безопасности канала.
Реализуйте механизмы, обеспечивающие идемпотентность и коммутативность.
Обеспечьте, чтобы код приложения мог выявлять и обрабатывать сообщения, поступающие более одного раза (идемпотентность), и множество сообщений, поступающих в произвольном порядке (коммутативность).
Рекомендации по реализации связи посредством обмена сообщениями
Связь посредством обмена сообщениями позволяет предоставлять сервис вызывающим сторонам через интерфейс сервиса, доступный для вызова клиентами путем передачи XMLсообщений по транспортному каналу. Как правило, вызовы посредством обмена сообщениями выполняются с удаленных клиентов, но интерфейсы сервисов, основанные на сообщениях, могут поддерживать и локальные вызовы. Связь посредством обмена сообщениями лучше всего подходит для следующих сценариев:
Реализация бизнес-системы, представляющей промежуточное звено в долгосрочных инвестициях; например, при создании сервиса, который будет предоставлен для использования партнерами в течение длительного времени.
Реализация крупномасштабных систем, которые должны предлагать высокую доступность или взаимодействовать через ненадежные сети. В этом случае механизм хранения и передачи сообщений может обеспечить более высокую надежность.
Создание сервиса, который требуется изолировать от остальных используемых им и использующих его сервисов. Применение интерфейсов сервисов на основе сообщений, раскрывающих детали реализации интерфейса клиентам, упрощает использование сервиса любыми клиентами без необходимости создания специальных реализаций для отдельных клиентов.
Работа с реальными бизнес-процессами, использующими асинхронную модель.
При использовании связи на основе сообщений руководствуйтесь следующими рекомендациями:
Предусмотрите то, что подключение будет доступно не всегда, и что может понадобиться сохранять сообщения с последующей их передачей, когда подключение становится доступным.
Продумайте, как обрабатывать ситуацию, когда ответ на сообщение не поступил. Для сохранения состояния взаимодействия бизнес-логика может протоколировать отправленные сообщения для последующей обработки на случай, если ответ не получен.
Используйте подтверждения о получении для обеспечения правильной последовательности передачи сообщений.
Используйте стандартные протоколы, такие как HTTP для связи через Интернет и TCP для связи по внутренним сетям. Реализуйте собственный механизм связи только в случае, если ни одна стандартная комбинация конечной точки, протокола и формата не отвечает заданным требованиям.
Если время ответа на сообщения является критичным для взаимодействия, используйте синхронную модель программирования, при которой клиенты
ожидают ответа на каждое сообщение. Или, если клиенты могут продолжать выполнение, пока ожидают ответ, используйте асинхронную модель.
При проектировании стратегии связи посредством обмена сообщениями также необходимо учесть специальные вопросы, которые могут оказывать влияние на стабильность, возможность повторного использования, производительность и общий успех дизайна. Более подробно эти вопросы рассматриваются в следующих разделах:
Сравнение асинхронного и синхронного взаимодействия
Связывание и связность
Форматы данных
Возможность взаимодействия с другими системами
Производительность
Управление состоянием
Сравнение асинхронного и синхронного взаимодействия
Делая выбор между синхронным и асинхронным стилем взаимодействия, учитывайте основные преимущества и недостатки. Синхронное взаимодействие лучше подходит для сценариев, в которых должен быть гарантирован порядок поступления вызовов, или если требуется ожидать ответа на вызов. Асинхронное взаимодействие применяется в сценариях, в которых большое значение имеет время отклика или невозможно гарантировать доступность точки назначения. Выбирая между синхронным и асинхронным взаимодействием, руководствуйтесь следующими рекомендациями:
Для обеспечения максимальной производительности, слабого связывания и сокращения издержек системы используйте модель асинхронного взаимодействия. Если некоторые клиенты могут выполнять только синхронные вызовы, заключите существующие асинхронные методы сервиса в компонент, осуществляющий синхронное взаимодействие с клиентом.
Если необходимо обеспечить гарантированный порядок выполнения операций, или при использовании операций, зависящих от результатов выполнения предыдущих операций, используйте синхронную модель.
Для асинхронных вызовов внутри процесса используйте средства платформы (такие как версии Begin и End методов и обратные вызовы) для реализации асинхронных вызовов методов. Для асинхронных вызовов вне процесса, таких как вызовы через физические уровни и границы, используйте обмен сообщениями или асинхронные запросы сервисов.
Если вы выбрали асинхронное взаимодействие и не можете гарантировать возможность сетевого подключения или доступность точки назначения, избежать утери сообщений поможет механизм сохранения сообщений с последующей доставкой. При использовании стратегии сохранения с последующей отправкой организовывайте сохранение сообщений на