случай недоступности системы или сети в локальных кэшах. В качестве альтернативы можно применить Message Queuing. Этот механизм в случае недоступности или сбоя системы или сети обеспечит помещение сообщений в очередь для их последующей доставки. Message Queuing может осуществлять транзакционную доставку сообщений и поддерживает надежную одноразовую доставку. Если необходимо обеспечить взаимодействие с другими системами и платформами на уровне предприятия или осуществлять обмен электронными данными, используйте BizTalk Server. Он обеспечит надежный механизм доставки.

Связывание и связность

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

Для обеспечения слабой связанности используйте основанную на сообщениях технологию, такую как ASP.NET Web services (ASMX) или WCF, и данные с самоописанием и общепринятые протоколы, такие как HTTP, REST и SOAP.

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

Форматы данных

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

Желательна поддержка бинарной сериализации для обеспечения лучшей производительности.

При выборе формата данных для канала связи руководствуйтесь следующими рекомендациями:

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

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

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

Собственные объекты применяются в случаях, когда ни один из других вариантов не удовлетворяет требованиям, или при взаимодействии с компонентами, которые ожидают использования собственного объекта. Такие объекты обусловливают меньшие издержки, чем объекты DataSet, и поддерживают и бинарную, и XMLсериализацию. Собственные объекты, используемые для передачи данных по каналам связи, являются объектами передачи данных (data transfer objects, DTO), в которых содержатся данные, извлеченные из бизнес-сущностей.

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

Возможность взаимодействия с другими системами

Основными факторами, оказывающими влияние на возможность взаимодействия приложений и компонентов, являются доступность подходящих каналов связи и форматов и протоколов,

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

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

Продумайте вопросы управления версиями для интерфейсов и контрактов. Необходимость в изменении сервисов может возникнуть из-за изменения бизнестребований, технологических требований или по другим причинам. В случаях, когда изменения приводят к несовместимости интерфейса, контракта сообщений или данных, создавайте новую версию, которая будет доступна клиентам наряду со старой версией. Старую версию смогут использовать клиенты, не нуждающиеся в новой функциональности, предоставляемой новым интерфейсом. Более подробно эти вопросы рассматриваются в статье «Service Versioning» (Контроль версий сервисов) по адресу http://msdn.microsoft.com/en-us/library/ms731060.aspx.

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

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

Производительность

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

По возможности, не передавайте лишние данные в удаленные методы и максимально сократите объем передаваемых по сети данных. Это обеспечит сокращение задержки сети и издержек на сериализацию. Кроме того, для взаимодействия между процессами и компьютерами избегайте применения детализированных интерфейсов, потому что в этом случае клиент вынужден выполнять множество вызовов метода для осуществления одной логической единицы работы. Применяйте шаблон Façade, он обеспечит слабо детализированную оболочку для существующих детализированных интерфейсов.

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

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

Если для обеспечения возможности взаимодействия требуется применение XML, используйте структуры, основанные на атрибутах, а не на элементах.

Управление состоянием

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

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

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

При проектировании ASMX-сервиса для хранения состояния используйте класс ApplicationContext (Контекст приложения), потому что он обеспечивает доступ к стандартным хранилищам данных области определения приложения и сеанса.

При проектировании WCF-сервиса используйте расширяемые объекты, предоставляемые платформой для управления состоянием. Эти расширяемые объекты обеспечивают возможность сохранять состояние в различных областях определения, таких как хост сервиса, контекст экземпляра сервиса и контекст операции. Обратите внимание, что все эти состояния удерживаются в памяти и не хранятся длительное время. Если требуется обеспечить длительное сохранение состояния, можно использовать механизм длительного хранения, введенный в .NET Framework 3.5, или реализовать собственное решение.

Контрактно-ориентированное проектирование

Традиционно разработчики создавали сервисы, применяя подход сначала код (code first), при котором проектирование сервиса выполняется на основании требований и предоставляется интерфейс, соответствующий коду и требованиям. Однако подход сначала контракт (contract first) приобретает всю большую популярность, поскольку обеспечивает снижение несовместимости, которая возможна между несопоставимыми системами и широкой номенклатурой клиентов.

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