Сервіси WCF МS.NET з контрактами

Windows Communication Foundation (WCF) — програмний фреймворк, призначений для обміну даними між застосуваннями вхідними даними, що входять до складу .NET Framework. Він є логічним розвитком попередніх технологій компанії Майкрософт, зокрема Веб-сервісів, .Net Remoting і DCOM.

В основі WCF лежить SOA, яка полягає в тому, що на сервері працює деяка кількість сервісів, що являють собою групу операцій, визначених у деякому інтерфейсі, і які одержують деякі абстрактні вхідні/вихідні параметри. Усе це описується за допомогою WSDL (Web Service Description Language) і може бути виставлене назовні через, так називані mex-endpoints (Metadata Exchange Endpoints). Це дозволяє одержати «мета дані” сервісу, підключивши до цього інтерфейсу; одержати опис сервісу і всіх його операцій і згенерувати відповідний прокси-класс для заданої мови або платформи. Сервіс описується в мові WCF, а використовувати його можна з Java/Python/Ruby і тощо. Клієнти у свою чергу мають на своєму боці прокси-классы, що містять посилання на відповідні операції на стороні сервісу. Таким чином, викликаючий локальний метод класса-прокси, завдає вилучений виклик методу на сервісі.

В межахWCF MS.Net дія технологія і фабрики програм для декількох веб-служб, а також фабрика сервісів. Основу технології містить схеми, “рецепти”, методи і засоби побудови фабрик різного призначення.

Фабрика програм включає набір корисних ресурсів, блоків коду, документації, зразків застосувань, автоматизованих інструментів і патернів VSIP для створення на їх основі різних пакетів. Група p&p Microsofts створює рекомендації, схеми і методи, а також стандарти їх виконання розробниками готової продукції.

Фабрика сервісів дає рекомендації для використання сервісів при проектуванні і конструюванні, які накопичуються у Global Bank. К ним відносяться ASP.Net для використання у WCF.

Дані фабрики програм і сервісів базуються на готовому наборі програмних елементів і різного роду сервісів, специфічних для MS.Net.

Функціонування WCF залежить від так званих кінцевих крапок (endpoint), що складає зв'язування "Address – Binding – Contract", "ABC". Кожна складова відіграє важливу роль:

"Address" містить місце розташування кінцевої крапки за абсолютною або відносною адресою;

"Binding" задає прив'язку і визначать транспорт, на основі якого буде відбуватися взаємодія. В об'єктній моделі WCF є ряд класів-прив'язок (BasicHttpBinding за HTTP, NetTcpBinding за транспортом TCP і т.д.;

"Contract" задає контракт, на основі якого буде відбуватися взаємодія клієнта і сервісу і визначає контракт з відповідними операціями сервісу, який будує клас-проксі на клієнті.

Як правило, на сервісній стороні задається множина кінцевих крапок. Крім того, можливо розмістити трохи сервісів на сервісній стороні. У результаті, сервісна сторона розподіленого застосування буде виглядати як сукупність кінцевих крапок. Клієнт у цьому випадку створює з'єднання з тією кінцевою крапкою, що потрібна саме йому. Приклад схеми з'єднання сервісу і клієнтів показаний на рис 1.1.

Рис.1.1. Приклад з'єднання сервісу і клієнтів.

Для побудови розподілених засобів як WCF або .Net Remoting) використовується принцип слоеного пирога, кожений шар якого відповідає за свій конкретний рівень абстракції і не знає нічого про нижчележащих рівні. Тобто інфраструктура WCF складається з двох головних рівнів: Service Model Layer і Channel Layer. Перший рівень ближче до самого сервісу клієнта і відповідає за перетворення методу і його параметрів у повідомлення для передачі більш низькому канальному рівневі. Канальний рівень (Channel Layer) ікапсулюють у собі канал передачі даних, які може бути безліч: канали, що використовують як транспорт TCP, Http, Named Pipes і т.д. Кожний з цих рівнів містить підуровни, і ви можете вклинитися в кожний з них для яких власних нестатків.

Контракти в WCFявляє собою опис повідомлень, переданих конечним службам з поверненням. Конечна крапка повинна специфікуватися, які операції вона може виконувати і формат очікуваних даних. Сукупність цих специфікацій і є контракт.

WCF містить контракти трьох видів:

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

Контракт даних – визначає формат даних, якими сервіси будуть обмінюватися. Це відноситься як до запиту на сервіс, так і до октету сервісу. Якщо використані примітивні типи – int, string, etc. то контракт не потрібнй, тому що .Net розуміє як серіализувати і десеріализовати типи, але якщо використані комплексні типи – Customers, Order, etc. Неоходіио вказати про принцип серіалиалізації і десерілизації цих об'єктів.

Контракт повідомлень – цей тип контракту, що використовується для того щоб одержати більший контроль над заголовками SOAP пакета.

Приклад опису повідомлення мовою XML.

<?xml version=»1.0» ?>

<env:Envelope xmlns:env=»

http://www.cbsystematics.com»>

<!—Конверт протоколу SOAP à

<env:Header>

<!— Заголовок протоколу SOAP à

</env:Header> <env:Body>

<!—Тело протоколу SOAP à

</env:Body> </env:Envelope>

Для забезпечення інтероперабельні контрактів з широким діапазоном систем, використовуються мови WSDL і XSD, тоді програма працює з типами CLR і необхідно відобразити одну систему типів на іншу. Ця задача вирішується в три етапи.

Спочатку при написанні коду служби постачається клас з визначеними в WCF атрибутами [ServiceContract], [OperationContract], [FaultContract], [MessageContract] і [DataContract].

При написанні клієнтського коду в сервісі даються деталі контракту за допомогою Visual Studio або утиліти svcutil.exe, що викликає інфраструктурну конечною крапку сервісу для повертання мета даних, необхідних для генерації WSDL документа з отриманням них від атрибутів.

На етапі виконання, \клієнт викликає який метод, визначений в інтерфейсі сервісу, WCF серіализує типи CLR і виклик методу у формат XML і посилає повідомлення в мережу відповідно до прив'язки і схемою кодування, погодженим за допомогою WSDL. При цьому беруть участь чотири конструкції: дві з боку .NET і дві з боку XML. З боку .NET мається тип CLR, що визначає структури даних і функціональні можливості, але щось зробити він може лише після того, як буде створений об'єкт цього типу. З боку XML задається XSD-опис структури даних, але повідомлення починає існувати лише після того, як буде створений екземпляр XML (XML Instance). Приклад опису WCF сервису підготовлений і апробований студентом Радецьким І , що нведений в Додатку 3. посібника.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Сервісно-орієнтована архітектура (SOA)	\|	Веб-сервіс Java Enterprise Edition (Java EE)

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.004 сек.