2.7.2. Сервіси 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. посібника.
2.7.3. Веб-сервіс Java Enterprise Edition (Java EE)
Цей сервіс містить набір специфікацій, документації для мови Java, які необхідні при роботі з мережними програмами та севісними засобами:
динамічно генеровані веб-сторінки (Java Server Pages);
веб-сервіси;
компоненти повторного застосування – Enterpirse Java Beans;
сервіс обміну повідомленнями (Java Message Queue);
інші сервісні технології.
Веб-сервіс (веб-служба) – ідентифікується рядком URI (Unified Resource Identifier, універсальний ідентифікатор ресурсів), ресурси котрої (властивості та методи) описані за допомогою спеціальної мови. Доступ до ресурсів здійснюється через протокол SOAP (Simple Object Access Protocol), який представляє собою XML-запити, що передаються за допомогою інтернет-протоколу високого рівня (найчастіше HTTP). За своєю архітектурою веб-сервіси нагадують класи об’єктно-орієнтованих МП (і в межах Java EE генеруються на основі класів) але є і певні відмінності.
Ключовим поняттям цього веб-сервісу є повідомлення (message), яке складається з однієї чи кількох змінних. Замість методів класів у веб-сервісах використовуються операції, які визначаються вхідним і вихідним повідомленнями. Після виклику операції змінні, що входять до вхідного повідомлення, отриманого по протоколу SOAP, інтерпретуються як параметри відповідного методу класу, який лежить в основі сервісу. Після завершення роботи методу формується вихідне повідомлення, що містить повернуте методом значення, яке після цього за допомогою SOAP відправляється клієнту. Така архітектура сервісу дозволяє викликати його методи асинхронно.
Спілкування з веб-сервісом здійснюється за допомогою протоколу SOAP. Для виклику операції веб-сервісу, визначеної у його WSDL-описі, використовується XML-запит, що називається SOAP– envelope і складається у загальному випадку з заголовку (SOAP– header; може бути порожнім) і тіла запиту (SOAP-body). Заголовок може містити додаткову інформацію стосовно запиту, таку як його пріоритетність, термін обробки і т.п. У тілі міститься одна чи декілька операцій веб-сервісу з відповідними параметрами.
Взаємодія Веб-сервісу через протокол SOAP. Веб-сервіс (веб-служба) ідентифікується рядком URI (Unified Resource Identifier, універсальний ідентифікатор ресурсів), ресурси котрої (властивості та методи) описані за допомогою спеціальної мови. Доступ до ресурсів такої системи здійснюється через протокол SOAP (Simple Object Access Protocol, простий протокол доступу до об’єктів), який представляє собою особливим чином сформульовані XML-запити, що передаються за допомогою інтернет-протоколу високого рівня (найчастіше HTTP). За своєю архітектурою веб-сервіси нагадують класи об’єктно-орієнтованих МП (і в межах Java EE генеруються на основі класів), проте є і певні відмінності [16].
Ключовим поняттям для веб-сервісу є повідомлення (message), яке складається з однієї чи кількох змінних. Замість методів класів у веб-сервісах використовуються операції, які визначаються вхідним і вихідним повідомленнями. Після виклику операції змінні, що входять до вхідного повідомлення, отриманого по протоколу SOAP, інтерпретуються як параметри відповідного методу класу, який лежить в основі сервісу. Після завершення роботи методу формується вихідне повідомлення, що містить повернуте методом значення, яке після цього за допомогою SOAP відправляється клієнту. Така архітектура сервісу дозволяє викликати його методи асинхронно.
Протокол SOAP. Спілкування з веб-сервісом здійснюється за допомогою протоколу SOAP. Для виклику операції веб-сервісу, визначеної у його WSDL-описі, використовується XML-запит, що називається SOAP- envelope і складається у загальному випадку з заголовку (SOAP-header; може бути порожнім) і тіла запиту (SOAP-body). Заголовок може містити додаткову інформацію стосовно запиту, таку як його пріоритетність, термін обробки і т.п. У тілі міститься одна чи декілька операцій веб-сервісу з відповідними параметрами.
Приклад запиту, який викликає операцію сервісу MyService.someMethod(32.5, true), приведено нижче, там же приведене й SOAP-повідомлення, повернуте сервісом.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:q0="http://webservice.demo" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<q0:someMethod>
<q0:arg0>32.5</q0:arg0>
<q0:arg1>true</q0:arg1>
</q0:someMethod>
</soapenv:Body>
</soapenv:Envelope>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<someMethodResponse xmlns="http://webservice.demo">
<someMethodReturn>Nothing to see here</someMethodReturn>
</someMethodResponse>
</soapenv:Body>
</soapenv:Envelope>
Сервлети та мова WSDL. Для доступу до веб-сервісів використовуються сервлети – Java-програми, які виконуються на стороні серверу і розширюють його функціональність. Сервлети широко застосовуються в технології Java EE, зокрема, в них перетворюються сторінки на мові JSP. Базова функціональність сервлетів закладена у їхній можливості обробки HTTP-запитів GET і/або POST. Згідно до специфікації веб-програм, існує можливість задавати (за допомогою конфігураційних XML-файлів) межі дії окремих сервлетів (servlet mapping). Рішення, який з доступних сервлетів застосовувати, приймається на основі аналізу URL-адреси запиту. Наприклад, веб-сервіси, які розташовані у директорії /services проекту, оброблюються стандартним сервлетом Apache Axis. За допомогою нього, зокрема, можна отримати WSDL-опис сервісу, розташований за адресою /services/[назва сервісу]?wsdl. Цей же сервлет виконує парсінг відправлених на сервер SOAP-повідомлень, їхню передачу відповідному Java-класу і складання SOAP-повідомлень з результатами роботи. Таким чином Axis забезпечує повну функціональність веб-сервісу [17]..
Мова WSDL. Для опису загальнодоступних ресурсів веб-сервісу використовується мова WSDL (Web Service Definition Language) на основі XML; середовище програмування Eclipse дозволяє автоматичне створення таких описів на основі класів Java. У мові визначені наступні основні типи даних:
рядки (xsd:string),
цілі числа (xsd:int, xsd:long, xsd:short, xsd:integer, xsd:decimal), числа з плаваючою комою (xsd:float, xsd:double),
логічний тип (xsd:boolean),
послідовності байт (xsd:base64Binary, xsd:hexBinary),
дата і час (xsd:time, xsd:date, xsd:g),
об’єкти (xsd:anySimpleType).
В якості змінних для повідомлень також можна використовувати послідовності, створені з фіксованої кількості змінних простих типів (це відповідає методам з декількома вхідними параметрами). Типовий WSDL-файл має наступну структуру.
<wsdl:definitions […]>
<!-- Декларація типів, що використовуються в сервісі -->
<wsdl:types>
<element name="someMethod">
<complexType>
<sequence>
<element name="arg0" type="xsd:double"/>
<element name="arg1" type="xsd:boolean"/>
</sequence>
</complexType>
</element>
<element name="someMethodResponse">
<complexType>
<sequence>
<element name="someMethodReturn" type="xsd: string"/>
</sequence>
</complexType>
</element>
</wsdl: types>
<! -- Декларації повідомлень -->
<wsdl: message name="someMethodResponse">
<wsdl:part element="impl:someMethodResponse" name="parameters">
</wsdl:part>
</wsdl:message>
<wsdl:message name="someMethodRequest">
<wsdl:part element="impl:someMethod" name="parameters">
</wsdl:part>
</wsdl:message>
<!-- Декларації операцій -->
<wsdl:portType name="MyService">
<wsdl:operation name="someMethod">
<!-- Вхідне повідомлення -->
<wsdl:input message="impl:someMethodRequest" name="someMethodRequest">
</wsdl:input>
<!-- Вихідне повідомлення -->
<wsdl:output message="impl:someMethodResponse" name="someMethodResponse">
</wsdl: output>
</wsdl:operation>
</wsdl:portType>
<!-- Декларація прив’язки до SOAP -->
<wsdl:binding name="MyServiceSoapBinding" type="impl:MyService">
<wsdlsoap:binding […]/>
<!-- Знову декларації операцій -->
<wsdl:operation name="someMethod">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="fahrenheitToCelsiusRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="fahrenheitToCelsiusResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<!-- Декларація веб-сервісу -->
<wsdl:service name="MyServiceService">
<wsdl:port binding="impl:MyServiceSoapBinding" name="MyService">
<wsdlsoap:address location=[…]/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Спочатку декларуються типи, які будуть використовуватися в сервісі. Приведений нижче WSDL-опис належить веб-сервісу MyService з єдиним методом
String someMethod(double arg0, boolean arg1),
на основі чого було згенеровано два типи даних, які відповідають вхідним та вихідним аргументам методу. Ці типи застосовуються в описах someMethodRequest і someMethodResponse – вхідного та вихідного повідомлень для операції someMethod.
Операції декларуються в описі інтерфейсу сервісу (декларація wsdl:portType) і далі в описі прив’язки сервісу до SOAP (декларація wsdl:binding), причому у другому випадку також оговорюється спосіб виклику (<wsdlsoap:body use="literal"/>). За рахунок цього дозволяється при виклику операції використовувати ті ж назви параметрів, що й у методі класу. В кінці WSDL-файлу знаходиться власне декларація веб-сервісу (<wsdl:service>), у якій міститься інформація щодо його розташування (параметр location).
Середовище Eclipse підтримує зручне графічне зображення WSDL-файлів; файл, що відповідає веб-сервісу MyService, показаний на рис. 2.4.
Рис. 2.4. Схема сервісу, отримана за допомогою Eclipse
В межах веб-сайта ІТК виконується завдання для звернення до веб-сервису шляхом натиснення на відповідну технологію. Сайт видає відповідь у наступній формі (рис.2.5)
Ви зараз знаходитесь у: Технології » Веб-сервіси » Приклад
Назва файлу:webservices.zipРозмір:2243.88 КбДата модифікації:Fri Nov 11 20:14:08 2011Опис:
Програма з графічним інтерфейсом, яка використовує простий веб-сервіс з додавання і віднімання цілих чисел. Для запуску розпакуйте зміст архіву у будь-яку директорію і запустіть на виконання файл WSLoader.jar. На машині має бути встановлено сервер програм GlassFish (його можна безкоштовно завантажити на сайті Oracle). Для більш детального опису програми див. інструкцію з використання.
Завантажити. Натиснувши на завдання – завантажити, буде такий результат (рис.2.5):
Рис.2.5. Вихідні результати сайту
Механізми взаємодії з веб-сервісами. Середовище програмування Eclipse (а також інші середовища, призначені для роботи з мережевими прикладними програмами, такі як MS.NET) забезпечують можливість створення клієнтів для веб-сервісів на основі їхнього WSDL-опису. При цьому приховується більша частина чорнової роботи із забезпечення функціонування клієнту, наприклад, складання коректних SOAP-запитів та парсінг повернутих сервісом SOAP-повідомлень – ці дії виконуються клієнтською частиною технології Apache Axis. Для забезпечення роботи клієнта створюється 5 Java-файлів:
– локатор сервісу (service locator), який виконує знаходження веб-сервісу;
інтерфейс локатору;
– стаб для SOAP-прив’язки (SOAP binding stub) – клієнтський стаб, призначений для складання і парсінгу SOAP–повідомлень;
– інтерфейс сервісу;
– проксі-клас, який реалізує цей інтерфейс; використовує клієнтський стаб та локатор для доступу до операцій веб-сервісу.
Наприклад, для вищезгаданого сервісу MyService автоматично створені класи та інтерфейси будуть називатися MyServiceServiceLocator, MyServiceService, MyServiceSoapBindingStub, MyService, MyServiceProxy (в порядку їх опису вище). Звернення до операції MyService.someMethod буде виглядати подібним чином:
My Service svc = new MyServiceProxy ();
Try {
System.out.println (svc.someMethod(32.5, true));
} catch (Remote Exception e) {
System.err.println("Error occurred while accessing the web service");
e.printStackTrace();
}
Таким чином, проведено аналіз підходів до забезпечення взаємодії різнорідних програм і сучасних середовищ та наведені принципи взаємозв’язку різнорідних і різномовних програм через інтерфейс, в якому дається опис параметрів і типів даних для передачі іншим програмам. Розглянуті варіанти операцій звернення програм між собою. Дано зміст і призначення нового способу реалізації зв’язків між середовищами розробки Visual Studio та Eclipse на прикладі програм із компонентів, написаних на різних МП. Надані приклади підтверджують принцип об’єднання середовищ MS.Net і Eclipse.