Основы проектирования корпоративных систем - Сергей Зыков

Как упоминалось ранее, важным средством взаимодействия клиента и сервера при реализации технологии WCF являются транзакции. При этом сценарии поведения на основе этих транзакций могут быть реализованы различными способами. Транзакции бывают двух типов: многошаговые бизнес-процессы и так называемые короткие транзакции, которые, в отличие от первого типа, завершаются достаточно оперативно и затрагивают относительно небольшое количество объектов и связей, зависимостей или ограничений целостности. WCF поддерживает второй вид транзакций, короткие транзакции. Рассмотрим, для чего используется атрибут Operation Behaviour и его свойство Transactionscope Requirement. Это свойство определяет, будет ли операция выполняться в режиме так называемых транзакций, или будет ли транзакция завершаться автоматически (Transaction Scope Complete) при окончании работы метода, или же ее можно будет завершить. В таком случае потребуется поддержка механизма взаимодействия, который реализуется на основе сессий. Важным аспектом взаимодействия между клиентскими и серверными частями приложений по технологии WCF является сериализация и десериализация. Сериализация – это процесс преобразования графа объектов в поток байтов, т. е. в последовательный поток формата XML Info Set. Таким образом, сериализация является эффективным способом сохранения состояния объектов, которое может храниться в базе данных или файле. В WCF состояние объектов хранится исключительно в XML Info Set. Особенность в том, что здесь, в отличие от XML, не задается конкретного формата данных. Используется процесс кодировки, преобразования сообщения WCF в поток байт, во внутреннее представление процесса, и существуют различные виды кодировки, которые доступны в WCF. Всего таких представлений пять. Это двоичный формат, текстовый формат, формат Message Transmission Optimization Mechanism (MTOM), формат, связанный с Java Script, Java Script Object Notation, и формат POX, Plain Old XML, связанный с традиционным XML. При этом выбор кодировки зависит от конкретной ситуации, от конкретных требований ПО по надежности, производительности, интероперабельности, масштабируемости и т. д.

Рассмотрим методы сериализации WCF в сравнении. Произведем сравнение механизмов сериализации, которые реализуются процедурами Data Contract Serializer, Net Data Contract Serializer, XML Serializer и Data Contracts JSON Serializer. Стандартным сериализатором является первый из них, Data Contract Serializer. Он преобразует внутренние типы WCF во внешнее представление XSD, которое является платформенно-независимым. То есть, по сути, не несет связанных с. NET элементов и поэтому может использоваться для взаимодействия со сторонними приложениями, скажем, с приложения, реализованными на основе Java. Для того чтобы этот сериализатор работал с классом, класс необходимо снабдить атрибутом Data Contract, а свойство или поля, которые используются для сериализации, необходимо снабдить атрибутом Data Member. Следующий вид сериализации, Net Data Contract Serializer, близок к первому, но отличается возможностью добавления информации о внутренних типах CLR к тем возможностям, которые имеются у сериализатора по умолчанию. В отличие от первого вида, он используется для. NET приложений и при этом осуществляет взаимодействие между частями этого приложения, причем только одного. NET приложения. Третьим классом, который отвечает за сериализацию, является XML Serializer. Это стандартный сериализатор. NET, который появился еще на уровне Framework 2.0 и сохранился в Framework 3.0. Он позволяет реализовать стандартный механизм сериализации, т. е. работать со стандартными типами. NET, имеет возможность настройки XML-представления, позволяет настраивать выход XML, который генерирует сервис, и работает со стандартными сервисами формата ASP.NET. При этом существуют три основных подхода к использованию данного вида сериализации. Можно использовать стандартную сериализацию, а также атрибуты, связанные с XML: XML Attribute, XML Element. Кроме того, можно использовать интерфейс IXML Serializer, который позволяет организовать взаимодействие с XML-форматом. Еще один важный вид сериализации Data Contract JSON Serializer, который поддерживает стандартную нотацию объектов в формате Java Srcipt.

Важным понятием, характерным для технологии WCF, является понятие host или servicehost. По сути, данное понятие определяет процесс, который несет ответственность за обработку и контекст выполнения веб-сервиса. Это процесс операционной системы, который управляет выполнением сервиса и контекстом, отвечает за старт сервиса, остановку этого сервиса, а также предоставляет важные базовые функции управления сервисом. Хостом сервиса WCF может выступать любой процесс ОС. Такие приложения, как Internet Information Service, Windows Process Activation Service, имеют встроенную поддержку хостинга, т. е. внутреннюю инфраструктуру, которая этот хостинг реализует. Кроме этих подходов можно использовать другой сервис, любой Windows Service, а также любое приложение с пользовательским интерфейсом или консольное приложение для того, чтобы осуществить поддержку хостинга. В зависимости от того, что именно является хостом сервиса, его конфигурация и настройка осуществляются в целом единообразно. Выбор хостинга зависит от требований к приложению, его быстродействию, устойчивости, масштабируемости и т. д. Каждый хост WCF требует реализации трех функциональных элементов: это объект класса ServiceHost, конечная точка и запуск прослушивания сообщений на сервере или процедуры listen.

Перейдем к более подробному описанию среды хостинга Windows (Process) Activation Services или W(P)AS, которая является стандартной средой хостинга (рис. 12.2). Она встроена в новые операционные системы – Windows Vista и серверную ОС Windows Server 2008, поддерживает ряд возможностей, которые раньше были доступны только через Internet Information Service. W(P)AS позволяет размещать сервисы в гибкой среде, которая не требует обязательного использования протокола HTTP. Предположим, что есть однонаправленное взаимодействие с некоторым сервисом и конечный пользователь этого сервиса, который довольно часто находится в отсоединенном от сервиса состоянии. В данном случае в качестве транспортного уровня лучше использовать MSMQ, чем HTTP, который не сохраняет состояния. Или, допустим, у сервиса много клиентов, с которыми он часто обменивается небольшими по размеру сообщениями. В этом протокол HTTP также подходит в меньшей степени, и выгоднее использовать протокол TCP. При этом желательно поддерживать множественность протоколов. Такую возможность дает W(P)AS, эта среда многопротокольная, здесь не требуется обязательное использование протокола обмена HTTP, т. е. осуществляется возможность работы в гибкой среде. Эта возможность поддерживается за счет реализации шаблона Listener Adapter, который абстрагирует слушателей, осуществляющих взаимодействие с процессами, от клиента, от процессов управления.