Передмова

Замовники замовників попросили замовників xsd файлидля структур, що передаються Web-сервісами, що реалізуються. Замовники у відповідь запропонували замовникам замовників зробити WSDL-ки. Т.о. Несподівано «на рівному місці» виникла необхідність зробити не просто xsd-схеми для валідації даних, а «цілі WSDL-ки». Зазвичай WSDL використовуються для SOAP, а у нас REST ...

Раніше я вже писав про

Вступ

Термін Web-сервіси зазвичай асоціюється з operation- або action-based сервісами, що базуються на SOAP або WS* стандартах, таких як WS-Addressing або WS-Security. Термін REST Web-сервіси зазвичай відноситься до resource-based архітектури Web-сервісів, що передають XML через HTTP. Кожен із цих архітектурних стилів має власне місцеАле до недавнього часу WSDL стандарт не підтримував обидва ці стилі. WSDL 1.1 HTTP binding був неадекватний для опису взаємодії з допомогою XMLпо HTTP, т.ч. був формального способу описати REST Web-сервисы з допомогою WSDL. Публікація стандарту WSDL 2.0 (який був розроблений з урахуванням необхідності опису REST Web-сервісів) у статусі рекомендації World Wide Web Consortium (W3C) дала мову для опису REST Web-сервісів.

REST - архітектурний стиль, що трактує Web як resource-centric додаток. Практично, це означає, що кожен URL в RESTful додатку є ресурсом. URL-і просто розуміти та запам'ятовувати. Наприклад, книгарня може визначити URL http://www.bookstore.com/books/ для списку книг, що продаються, і http://www.bookstore.com/books/0321396855/ для деталей про конкретну книгу з ISBN 0321396855. Це контрастує з action-centric додатками, які зазвичай мають довгі складношифовані URL і описують дії, які необхідно виконати, наприклад http://www.bookstore.com/action/query?t=b&id=11117645532&qp=0321396855 . Параметри запиту використовуються для вибору потрібних даних. Використовуючи приклад книгарні, вказівка ​​параметра subject обмежує тематику книги. Наприклад фізика або детективи або, наприклад, URL http://www.bookstore.com/books/?subject=computers/eclipse — запит повертає список книг про платформу Eclipse.

Термін REST вигадав Roy Fielding у своїй кандидатській дисертації. Він розглядав гіперпосилання як засіб для зміни (зберігання) стану програми. Гіперлінки зберігаються в ресурсах програми та є методом зміни стану програми, редиректу з одного стану до іншого. Зазвичай гіперлінки (X)HTML призначені для використання людьми, вони не використовувалися в XML, який був призначений для машинної обробки. Так само як і (X)HTML, REST Web-сервіси використовують гіперлінки в XML.

Традиційні Web-програми отримують доступ до ресурсів за допомогою HTTP GET або POST операцій. RESTfull програми працюють з ресурсами в стилі «create, read, update, and delete (CRUD)» використовуючи повні можливості HTTP протоколу (POST, GET, PUT та DELETE).

Ще одне важливе зауваженняпро REST додаток: RESTful додатки повинні бути stateless. Це означає, що програма REST не зберігає жодного стану сесії на стороні сервера. Вся інформація, необхідна виконання запиту, передається у самому запиті. (Тому на запити сервер повинен відповідати однаково прим. перекладача). Відповідно, клієнт може кешувати отримані ресурси, що може значно прискорити швидкість роботи програми там, де сервіс явно дозволяє це. Щоб дізнатися більше про REST, див посилання на статтю.

WSDL та REST

WSDL містить усі деталі про веб-сервіс, включаючи:

URL веб-сервісу
Механізми комунікації, які розуміє веб-сервіс
Операції, які може виконувати веб-сервіс
Структура повідомлень веб-сервісу

Клієнти можуть використовувати ці деталі для взаємодії з сервісом.

WSDL 2.0 був оголошений рекомендацією W3C у червні 2007. Ця версія стандарту WSDL була випущена для вирішення проблем стандарту WSDL 1.1, багато з яких були виявлені організацією Web Services Interoperability (WS-I). Крім того в WSDL 2.0 покращено підтримка HTTP bindings.

WSDL сам є XML - підмножиною, що формально описує веб-сервіс. Розглядайте WSDL опис веб-сервісу як його API контракт із клієнтом. У WSDL вказується адреса, допустимі способи передачі, інтерфейсу і типи повідомлень веб-сервісу. Коротше кажучи, опис WSDL містить всю інформацію, необхідну для клієнта для використання веб-сервісу.

Застосовність WSDL виходить за межі його використання як контракт API. Будучи формальним визначенням, WSDL може бути використаний софтом, що спрощує реалізацію веб-сервісів для таких операцій як:

• Генерування вихідного кодуклієнтської програми та сервера для веб-сервісу різними мовами програмування
• Публікація веб-сервісу
• Динамічне тестування веб-сервісу

Більшість програмних засобівдля роботи з веб-сервісами включають підтримку WSDL 1.1. Останнім часом зростає кількість засобів розробки веб-сервісів, які підтримують WSDL 2.0. Проект Apache Web services складається із двох підпроектів, які в даний час підтримують WSDL 2.0. Woden – парсер-валідатор WSDL 2.0 на базі Java. Apache Web Services проект також надає XSL (XSLT) трансформацію WSDL 2.0 під назвою WSDL 2.0 pretty printer, Що забезпечує кращу людину читання документа WSDL. Axis2 популярний engine веб-сервісів (теж від Apache), що реалізує генерацію клієнтського та серверного Java коду з документа WSDL 2.0.

Опис REST веб-сервісу за допомогою WSDL 2.0

Ви створюєте книгарню, яка з просунутим URL: http://www.bookstore.com . Ви вже створили дві служби REST Web:

• book list — сервіс отримує список книг, що продаються у вас.
• book details - сервіс отримує інформацію про конкретну книгу.

Відповідь повертається у документах XML.

Елемент interfaceвизначає список операцій веб-сервісу, включаючи опис вхідних, вихідних повідомлень та повідомлень про помилки для операцій, а також порядок передачі.

Елемент bindingвизначає, чи кошти комунікації клієнта з веб-сервісом. У разі REST веб-сервісів, як засіб комунікації вказується HTTP.

Елемент service асоціює адреси веб-сервісу з конкретними інтерфейсами (interface) та засобами комунікації (binding). (Тобто задає відповідність URL операції веб-сервісу та елементу binding).

Прив'язуємо book list до HTTP

Елемент bindingзадає прив'язку веб-сервісу до конкретного протоколу передачі. Для прив'язування book list сервісудо HTTP потрібно вказати значення http://www.w3.org/ns/wsdl/http для атрибуту typeелемента binding.

Елемент bindingможе опціонально посилатися на interface. Залишіть атрибут interfaceпорожній. Ви створите його у наступному розділі. Якщо interfaceасоційований з bindingтоді bindingелемент може опціонально визначати дочірній елемент operation, що є дзеркальним для interface operationелемент. Вам потрібно створити заглушку елемента operationта заповнити посилання на operationпізніше після створення interface.

Існує 4 HTTP communication методу

• DELETE

Book list сервіс читає запит та відповідно оперує за допомогою HTTP GET. Встановіть метод GETдля operatioin елемент, використовуючи атрибут метод з WSDL 2.0 HTTP namespace. Для використання цього атрибуту, потрібно спочатку визначити namespace http://www.w3.org/ns/wsdl/http в елементі description.

Book list сервіс binding визначений на наступному лістингу. Вкажіть тепер bindingв елементі endpoint: tns:BookListHTTPBinding.

The bookstore's book list service.

Визначення book list service operation

Якщо ви збираєтеся побачити, як адреса і комунікація з book list web service. Далі ви визначите, що book list service operation, які описують what the book list service does.

Отже, ви навчилися задавати address та задавати binding (спосіб комунікації) для веб-сервісу. Далі необхідно задати service operation, що визначає, що робить book list веб-сервіс.

Елемент interface та його дочірній operation елемент використовуються для визначення сервісних операцій. У випадку з book list ви визначаєте одну операцію getBookList, яка повертає список книг.

Потім визначте три атрибути елемента operation:

Pattern

Використовується для вказівки шаблону обміну повідомленнями message exchange pattern(MEP) для операції. MEP визначає послідовність повідомлень для операції та їх направлення. У цьому випадку необхідно вказати значення http://www.w3.org/ns/wsdl/in-out, щоб вказати, що веб-сервіс отримує одне вхідне повідомлення проханням про список книг, і надсилає одне вихідне повідомлення зі списком книг. Для підтримки цього MEP вкажіть дочірні елементи inputі outputдля елемента operation. Ці елементи використовують елементи, описані в XML schema, що визначають структури повідомлень. Подробиці у наступному розділі.

Style

Використовується для надання додаткової інформації про роботу. Вкажіть значення http://www.w3.org/ns/wsdl/style/iri , що накладає обмеження на вміст вхідних елементів, такі як вимога, що це тільки використовувати XML schema елементи.

wsdlx:safe

wsdlx:safe: З WSDL extensions namespace, цей atribut declares that this operation is idempotent. Цей тип роботи залежить від зміни ресурсу і може бутизаписаний багато разів з самими результатами. Для використання цього елемента, зазначте WSDL extensions namespace http://www.w3.org/ns/wsdl-extensions on description element.

Цей атрибут з WSDL extensions namespace. Він визначає, що операція є idempotent. Ця операція не модифікує ресурс, тому може бути багаторазово викликана з однаковими результатами. Щоб використовувати цей елемент, потрібно оголосити namespace WSDL extentions http://www.w3.org/ns/wsdl-extensions у кореневому елементі (елементі description).

Ви можете знайти визначені Message Exchange Patterns, styles та wsdlx:safe визначення за посиланням WSDL 2.0 Part 2: Adjuncts

Нижче наведено визначення book list сервісу з доданим описом interface. Після додавання interface тепер можна змінити binding operation елемент, щоб вказати посилання на описані interfaceі Operation.

RESTful HTTP binding для book list service. The bookstore's book list service.

Визначення повідомлень сервісу book list operation

Веб-сервіс book list використовує два повідомлення: вхідне та вихідне. Ви повинні описати структури цих повідомлень, щоб клієнтські програми знали, що надсилати на адресу сервісу і що очікувати назад.

WSDL 2.0 підтримує багаторазові типи систем для перегляду вмісту вмісту, але XML schema is only one in use. Ця секція не залежить від XML schema. XML schema is used у багато інших applications, як WSDL 1.1, і є багато good articles about it. Цей розділ високихlights як використовувати XML schema for book list REST Web service and how to used additional attributes defined by WSDL 2.0 to annotate a schema attribute.

WSDL 2.0 підтримує безліч систем визначення типів, але на практиці використовується лише XML schema. Ця стаття не вдається до деталей XML schema. XML schema використовується в багатьох інших програмах, наприклад, WSDL 1.1, і є багато хороших статейпро нього. (). У цьому розділі демонструється застосування XML schema стосовно конкретного прикладу REST сервісу book list, а також використання додаткових атрибутів визначених у WSDL 2.0 для анотації schema атрибута.

Щоб описати 2 повідомлення для book list, необхідно описати 2 глобальні елементи.

• getBookListє вхідне повідомлення. Він містить послідовність елементів, включаючи кожен параметр запиту, дозволений для сервісу: uthor, title, publisher, subjectі language. Всередині повідомлення getBookList можуть використовуватися тільки елементи, тому що вибраний IRI style для interface operation.
• bookListє вихідне повідомлення. Він містить послідовність book елементів. Кожен book елемент у свою чергу містить title та url атрибути. Атрибут title не потребує пояснень. Атрибут url це лінк на сервіс book details, що повертає детальну інформаціюпро конкретну книгу.

Ваше визначення атрибуту url використовує у свою чергу два атрибути з WSDL extensions namespace. Атрибути wsdlx:interface та wsdlx:binding задають interface та binding для сервісу. Програмне забезпечення може використовувати цю інформацію для автоматичного знаходження сервісу. Для використання цих атрибутів вкажіть WSDL extentions namespace для елемента schema. Також увімкніть book details namespace з його опису WSDL 2.0.

XML schema для book list сервісу наведена нижче.

Request element для book list service. Відповідь елемент для book list service.

Для посилання на input та output елементи, ви повинні імпортувати схему у ваш документ WSDL. Для імпортування зземи, використовуйте schema import елемент у розділі types як показано на лістингу нижче. Крім того, необхідно додати посилання на getBookList і Booklist елементи в interface operation input і output елементах і додати простору імен book list XML schema в кореневий елемент WSDL.

Готовий WSDL для book list веб-сервісу.

Це WSDL 2.0 опис зробленого bookstore service listing for obtaining book information. Ця операція відновить список книг. RESTful HTTP binding для book list service. The bookstore's book list service.

Примітка перекладача

Я дозволив собі не перекладати summary та посилання. І те, й інше дивитися в автора. в оригінальній статті. Треба сказати мову оригіналу дуже важка. Проте, сподіваюся, стаття виявиться корисною.

Заголовок топіка – це справді питання, т.к. я сам не знаю, що це і вперше спробую попрацювати з цим у рамках цієї статті. Єдине, що можу гарантувати, що код, поданий нижче, працюватиме, проте мої фрази будуть лише припущеннями та здогадками про те, як я сам усе це розумію. Отже, поїхали.

Вступ

Почати треба з того, навіщо створювалася концепція веб-сервісів. До моменту появи цього поняття у світі вже існували технології, що дозволяють програмам взаємодіяти на відстані, де одна програма могла викликати якийсь метод в іншій програмі, яка при цьому могла бути запущена на комп'ютері, розташованому в іншому місті чи навіть країні. Все це скорочено називається RPC (Remote Procedure Calling – віддалений виклик процедур). Як приклади можна навести технології CORBA, а Java – RMI (Remote Method Invoking – віддалений виклик методів). І начебто у них добре, особливо у CORBA, т.к. з нею можна працювати будь-якою мовою програмування, але чогось все ж таки не вистачало. Вважаю, що мінусом CORBA є те, що вона працює через якісь свої мережеві протоколизамість простого HTTPщо пролізе через будь-який firewall. Ідея веб-сервісу полягала у створенні такого RPC, який засовуватиметься в HTTP пакети. Так розпочалася розробка стандарту. Які у цього стандарту базові поняття:

1. SOAP. Перш ніж викликати віддалену процедуру, потрібно описати цей виклик у XML файлі формату SOAP. SOAP - це просто одна з численних XML розміток, яка використовується у веб-сервісах. Все, що ми хочемо кудись відправити через HTTP, спочатку перетворюється на XML опис SOAP, потім засовується в HTTP пакет і посилається на інший комп'ютер у мережі TCP/IP.
2. WSDL. Існує веб-сервіс, тобто. програма, методи якої можна віддалено викликати. Але стандарт вимагає, щоб до цієї програми додався опис, в якому сказано, що «так, ви не помилилися – це дійсно веб-сервіс і можна у нього викликати такі-то методи». Такий опис є ще одним файлом XML, який має інший формат, а саме WSDL. Тобто. WSDL – це просто XML-файл опису веб-сервісу і більше нічого.

Чому так стисло запитаєте ви? А детальніше не можна? Напевно, можна, але для цього доведеться звернутися до таких книг як Машнін Т. «Web-сервіси Java». Там протягом перших 200 сторінок йде детальний опис кожного стандартного тега SOAP і WSDL. Чи варто це робити? На погляд немає, т.к. все це на Java створюється автоматично, а вам потрібно лише написати вміст методів, які передбачається видалено викликати. Так ось у Java з'явився такий API, як JAX-RPC. Якщо хтось не знає, коли кажуть, що в Java є такий-то API, це означає, що є пакет з набором класів, які інкапсулюють технологію, що розглядається. JAX-RPC довго розвивався від версії до версії і зрештою перетворився на JAX-WS. WS, очевидно, означає WebService і можна подумати, що це просте перейменування RPC на популярне нині слівце. Це негаразд, т.к. Тепер веб-сервіси відійшли від початкового задуму і дозволяють не просто викликати віддалені методи, а й просто надсилати повідомлення-документи у форматі SOAP. Навіщо це потрібно я поки не знаю, навряд чи відповідь тут буде «про всяк випадок, раптом знадобиться». Сам би хотів дізнатися від досвідченіших товаришів. Ну і останнє, далі з'явився ще JAX-RS для про RESTful веб-сервісів, але це тема окремої статті. У цьому вступ можна закінчувати, т.к. далі ми будемо вчитися працювати з JAX-WS.

Загальний підхід

У веб-сервісах завжди є клієнт та сервер. Сервер – це і є наш веб-сервіс і іноді його називають endpoint (типу як кінцева точка, куди доходять SOAP повідомлення від клієнта). Нам потрібно зробити таке:

1. Описати інтерфейс нашого веб-сервісу
2. Реалізувати цей інтерфейс
3. Запустити наш веб-сервіс
4. Написати клієнта та віддалено викликати потрібний методвеб-сервісу

Запуск веб-сервісу можна здійснювати різними способами: або описати клас з методом main та запустити веб-сервіс безпосередньо, як сервер, або задеплоїти його на сервер типу Tomcat або будь-який інший. У другому випадку ми самі не запускаємо новий сервері не відкриваємо ще один порт на комп'ютері, а просто говоримо контейнеру сервлетів Tomcat, що «ми написали тут класи веб-сервісу, опублікуй їх, будь ласка, щоб усі, хто до тебе звернутися могли нашим веб-сервісом скористатися». Незалежно від способу запуску веб-сервісу, клієнт у нас буде той самий.

Сервер

Запустимо IDEA та створимо новий проект Create New Project. Вкажемо ім'я HelloWebServiceта натиснемо кнопку Next, далі кнопку Finish. В папці srcстворимо пакет ru.javarush.ws. У цьому пакеті створимо інтерфейс HelloWebService: package ru. javarush. ws; // Це інструкції, тобто. спосіб відзначити наші класи та методи, // як пов'язані з веб-сервісною технологією import javax. jws. WebMethod; import javax. jws. WebService; import javax. jws. soap. SOAPBinding; // кажемо, що наш інтерфейс працюватиме як веб-сервіс@WebService // говоримо, що веб-сервіс використовуватиметься для виклику методів@SOAPBinding (style = SOAPBinding. Style. RPC) public interface HelloWebService ( // Кажемо, що цей метод можна викликати віддаленовикористовується параметр style зі значенням, що говорить, що веб-сервіс працюватиме через повідомлення-документи, бо як класичний RPC, тобто. для виклику методу. Давайте реалізуємо логіку нашого інтерфейсу та створимо у нашому пакеті клас HelloWebServiceImpl. До речі, зауважу, що закінчення класу на Impl – це угода Java, за якою так позначають реалізацію інтерфейсів (Impl – від слова implementation, тобто реалізація). Це не вимога і ви вільні назвати клас як хочете, але правила хорошого тону цього вимагають: package uk. javarush. ws; // Таже анотація, що і при описі інтерфейсу, import javax. jws. WebService; // Але тут використовується з параметром endpointInterface, // вказівним повне ім'якласу інтерфейсу нашого веб-сервісу@WebService (endpointInterface = "ru.javarush.ws.HelloWebService") public class HelloWebServiceImpl implements HelloWebService ( @Override public String getHelloString (String name) ( // просто повертаємо вітання return "Hello, "+name+"!" ; src) ) Запустимо наш веб-сервіс як самостійний сервер, тобто. без участі будь-яких Tomcat та серверів додатків (це тема окремої розмови). Для цього у структурі проекту у папці створимо пакет ru.javarush.endpoint, а в ньому створимо клас HelloWebServicePublisher з методом main: package ru. javarush. endpoint;// клас для запуску веб-сервера з веб-сервісами import javax. xml. ws. Endpoint;// клас нашого веб-сервісу import uk. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher ( public static void main (String. . . args) ( // запускаємо веб-сервер на порту 1986// і за адресою, вказаною в першому аргументі, // запускаємо веб-сервіс, що передається у другому аргументі Endpoint. publish ( "http://localhost:1986/wss/hello", New HelloWebServiceImpl());

) ) Тепер запустимо цей клас, натиснувши

Shift+F10 srcстворимо пакет ru.javarush.client, а в ньому клас HelloWebServiceClient з методом main: package ru. javarush. client; // Потрібно, щоб отримати wsdl опис і через нього // Дотягнутися до самого веб-сервісу import java. net. URL; // такий ексепшн виникне під час роботи з об'єктом URL import java. net. MalformedURLEвідповідь; // класи, щоб пропарсувати xml-ку c wsdl описом // і дотягнутися до тега service в ньому import javax. xml. namespace. QName; import javax. xml. ws. Service;// інтерфейс нашого веб-сервісу (нам більше і потрібно) import uk. javarush. ws. HelloWebService; public class HelloWebServiceClient ( public static void main (String args) throws MalformedURLException (// створюємо посилання на wsdl опис URL url) ; = new URL ( "http://localhost:1986/wss/hello?wsdl" // Параметри наступного конструктора дивимося в першому тезі WSDL опису - definitions// Перший аргумент дивимося в атрибуті targetNamespace // Другий аргумент дивимося в атрибуті name QName qname = new QName ("http://ws.сайт/", "HelloWebServiceImplService"); // Тепер ми можемо дотягнутися до тега service у wsdl описі, Service service = Service. create (url, qname);// а далі і до вкладеного в нього тега port, щоб // отримати посилання на віддалений від нас об'єкт веб-сервісу HelloWebService hello=service. getPort (HelloWebService. class);

// Ура! Тепер можна викликати віддалений метод

System. out. println (hello. getHelloString ("JavaRush")); ) ) Максимум коментарів за кодом я дав у лістингу. Додати мені нічого, тому запускаємо (Shift+F10). Ми повинні побачити в консолі текст: Hello, JavaRush! Якщо не побачили, то мабуть забули запустити веб-сервіс.Висновок У цьому топіці був представленийкороткий екскурс у веб-сервіси. Ще раз скажу, що багато з того, що я написав – це мої здогади з приводу того, як це працює, і тому мені не варто довіряти. Буду вдячний, якщо

WSDL (знаючі людимене виправлять, адже тоді я чогось навчуся. WSDL UPD. WSDLрозширюємо, що дозволяє описувати послуги (сервіси) та їх повідомлення незалежно від того, які формати повідомлень чи мережеві протоколи використовуються для транспорту, проте найчастіше використовується WSDL 1.1 разом із SOAP 1.1, HTTP GET/POST та MIME. Оскільки WSDLбув розроблений спільно з SOAP, в його розробці брали участь ті самі фірми Microsoft, Ariba і IBM. Якщо розглядати документ WSDLінтуїтивно, то можна сказати, що він дозволяє відповісти на 4 запитання:

1) що ви робите? Відповідь це питання дається у формі придатної як сприйняття людиною і формі сприймається машиною. Відповідь для людини в тегах:<name/>, <documentation/>, для машини -<message/>, <pointType>

2) якою мовою ви розмовляєте? (які типи ви використовуєте?) Відповідь у тезі:<types/>

3) як я буду з вами спілкуватися? (Як клієнт буде звертатися до веб-служби?):HTTP або SMTP. Відповідь знаходиться в<binding/>

4) де мені знайти вас? (де я можу знайти цю веб-службу або яка у неї URL?). Відповідь знаходиться:<service/>

Структура:

Кожен документ WSDL можна розбити на три логічні частини:

1. визначення типів даних - визначення виду повідомлень, що надсилаються та одержуються сервісом XML.

2. абстрактні операції - Список операцій, які можуть бути виконані з повідомленнями

3. зв'язування сервісів - спосіб, яким повідомлення буде доставлене

Документи WSDLможна створювати вручну, проте строга формалізація мови WSDLдозволяє автоматизувати процес написання WSDL-документів. Багато інструментальних засобів створення Web-служб містять утиліти, які автоматично створюють WSDL-Файли, що описують готові Web-служби. Наприклад засіб створення Web-служб Apache Axisмістить у своєму складі клас Java2WSDL, що створює WSDL-Файл за класом або інтерфейсом Java, що описує Web-службу. Пакет IBM WSTK, до складу якого входить Axisмістить утиліту java2wsdl, що створює та запускає об'єкт з цього класу. Вона працює із командного рядка.

Елементи документа WSDL

Опишемо найчастіше вживані теги WSDL:

Тег – це кореневий тег усіх документів WSDL. Він визначає кілька просторів імен:

1) target Name space – це простір імен нашої веб-служби

2) xmlns – стандартний простір імен документа WSDL

3)xmlns: SOAP_ENC – простір імен, що використовується для опису кодування SOAP

4)xmlns: impl і intf – простір імен реалізації та визначення нашої веб-служби

· Документ для визначення веб-служби

· Документ для реалізації веб-служби

Для простоти зазвичай використовують 1 файл, який містить всю інформацію

Елемент - надає інформацію про дані, що передаються від однієї кінцевої точки до іншої.

Для опису виклику RPC необхідно створити вхідне повідомлення та вихідне повідомлення.

В рамках цього елемента можна вказати параметри методу за допомогою елемента

Елемент описує та визначає операції або методи, що підтримуються веб-службою

Операції можуть мати вхідні повідомлення та повідомлення про помилки.

Елемент - описує, як операції, визначені у типі порту, будуть передаватися по мережі. Т.к. елемент використовує тип порту, він повинен вказувати тип певний десь раніше у документі.

Елемент - Вказує де знайти веб службу

Елемент import . Дуже часто елемент service виділяється у свій wsdl документ з міркувань практичності.

Для того, щоб дозволити зібрати з декількох документів wsdl один використовується елемент import. Він дозволяє включати один wsdl документ до іншого.

Елемент types дозволяє вказати типи даних, що передаються якщо вони не є стандартними.

WSDL підтримує 4 режими операцій:

· Операції типу one-way або односторонні операції. Повідомлення надсилається кінцевій точці служби. У цьому випадку операція описується лише одним вхідним повідомленням.

· Request-Response - режим запит-відповідь. Цей режим операції є найзагальнішим. У цьому режимі опис операції містить вхідне та вихідне повідомлення та необов'язкове повідомлення про помилку.

· Операція типу вимога-відповідь. У цьому режимі кінцевою точкою є клієнт іншої кінцевої точки. Формат операції схожий на режим запит-відповідь, але вихідні дані перераховуються перед вхідними даними.

· Операція повідомлення. Цей режим – ще одна версія примітиву односторонньої передачі, в якій кінцева точка посилає повідомлення, а не отримує його. Операція містить лише вихідне повідомлення.

Елементи розширення зв'язування використовуються для вказівки конкретної граматики для вхідних (3) та вихідних (4) повідомлень, повідомлень про помилки (5). Також може вказуватися інформація рівня операції (2) та рівня зв'язування (1).

Елемент зв'язування operation містить дані для однойменної операції пов'язаного типупорту. Однак ім'я операції в загальному випадку не є унікальним (приклад: навантаження методів / функцій - використання однакових імен з різними сигнатурами), тому його може бути недостатньо для визначення цільової операції типу порту. У разі цільова операція адресується з допомогою додаткового завдання відповідних імен елементів wsdl:input і wsdl:output з допомогою атрибута name .

Зв'язування повинновстановлювати лише один протокол.

Зв'язування не повинномістити інформацію про адресу.

Порт

Порт визначає окрему кінцеву точку за допомогою установки адреси зв'язування.

1. <wsdl:definitions .... >
2. <wsdl:service .... > *
3. <wsdl:port name = "nmtoken" binding = "qname" > *
4. <-- extensibility element (1) -->
5. wsdl:port>
6. wsdl:service>
7. wsdl:definitions>

Атрибут name визначає унікальне ім'я серед усіх портів у рамках WSDL-документа. Атрибут binding типу QName містить посилання зв'язування (див.).

Елементи розширення (1) використовуються для визначення адреси.

Порт не повиненставити більше однієї адреси.

Порт не повиненмістити будь-яку інформацію зв'язування, відмінну від адреси.

Служба

Служба об'єднує разом набір пов'язаних портів.

1. <wsdl:definitions .... >
2. <wsdl:service name = "nmtoken" > *
3. <wsdl:port .... /> *
4. wsdl:service>
5. wsdl:definitions>

Атрибут name визначає унікальне ім'я серед усіх служб, визначених у рамках WSDL-документа.

Порти всередині служби пов'язані таким чином:

• Порти не взаємодіють один з одним (тобто вихід одного порту не є входом іншого).
• Якщо служба має кілька портів, які розділяють загальний тип порту, але використовують різні зв'язування або мають різні адреси, такі порти є альтернативними. Кожен такий порт реалізує логічно еквівалентну поведінку (у межах обмежень транспорту та формату повідомлень, що накладаються відповідним зв'язуванням). Це дозволяє клієнту вибирати конкретний порт для обміну на основі різних критеріїв(Підтримка транспортного протоколу і т.д.).
• Розглянувши порти, можна визначити типи портів, що підтримуються службою. На основі цих даних клієнт може визначити можливість взаємодії із конкретною службою. Це корисно, якщо мається на увазі зв'язок між операціями з різних типівпортів, і для виконання певного завдання потрібна підтримка службою всіх необхідних типівпортів.

1. Це вільний, частковий, доповнений переклад документа Web Services Description Language (WSDL) 1.1 від 15 Березень 2001
2. Несхиляються написаними латиницею термінами оперувати вкрай незручно, до того ж вони однозначно перекладаються. Тому вихідне ім'я дається лише за введенні нового терміна, а далі текстом використовується російський переклад.

У розділі 2 ми говорили про те, що після створення Web-служби на сервері у вигляді сервлета, сторінки JSP, JWS-файлу, компонента EJB або іншого об'єкта, слід описати склад і можливості Web-служби мовою, яка не залежить від платформи, операційної системисистеми програмування, використаної при створенні Web-служби. Цей опис реєструється у загальнодоступному місці Інтернету, наприклад, реєстрі UDDI чи ebXML, або зберігається на сервері Web-служби. Опис повинен містити повну та точну інформацію про всі послуги, що надаються Web-службою, способи отримання послуг, вміст запиту на отримання послуги, формат інформації, що надається.

Один із засобів точного та одноманітного опису Web-послуг – мова WSDL, створена консорціумом W3C. Ця мова – ще одна реалізація XML. Його остання рекомендована специфікація завжди публікується на сторінці http://www.w3.org/TR/wsdI. Під час написання книги на чорновій стадії була версія WSDL 1.2, яку ми опишемо в цьому розділі.

Склад документа WSDL

Кореневим елементом документа XML - опис WSDL - служить елемент . У цьому елементі необов'язковим атрибутом name можна назвати опис. Крім того, це зручне місце для введення імен, що використовуються в описі просторів.

Описи WSDL активно використовують різноманітні простори імен. Крім власних імен, мова WSDL часто використовує імена типів та елементів мови опису схем XSD (див. розділ 1) та імена мови протоколу SOAP. Простір імен мови WSDL часто описується як простір за промовчанням. Ідентифікатор простору імен останньої на час написання цих рядків версії WSDL 1.2 дорівнював http://www.w3.org/2002/07/wsdl. Цільовий простір імен, ідентифікатор якого визначається атрибутом зазвичай отримує префікс tns (target namespace).

У кореневий елемент вкладаються елементи шести основних та двох додаткових типів. Всі елементи необов'язкові, їх може бути будь-яка кількість, крім елемента , який може зустрітися у документі лише один раз. Кожен елемент має ім'я, яке визначається обов'язковим атрибутом name. Елементи посилаються один на одного за допомогою цих імен. Ось елементи, що вкладаються в кореневий елемент

? - Визначає складні типи, що використовуються Web-службою, за допомогою мови XSD або іншої мови опису типів. Цей елемент не потрібен, якщо Web-служба застосовує лише прості типи, описані у мові XSD

? - Описує кожне SOAP-послання: запит, відповідь, пересилання документів. У цей елемент вкладаються елементи Що описують неподільні з погляду WSDL частини послання. Для послань процедурного типу кожен елемент Може описувати ім'я та тип одного аргументу запиту або тип значення, що повертається. Для послань документного типу елементи Можуть описувати кожну частину послання multipart/related. Цей абстрактний опис потім конкретизується елементами .

? Описує інтерфейс Web-служби, який називається мовою WSDL пунктом призначення (endpoint) або портом (port) прибуття послання. Він описується як набір Web-послуг, які називаються мовою WSDL операціями. Перекладаючи цей опис на мову програмування можна побачити, що порт добре співвідноситься з інтерфейсом Java, кожна операція - з цього інтерфейсу. Операції описуються вкладеними елементами , що описують кожну окрему послугу Послуга описується діями, які розбиті на чотири види. Це два простих дії: "отримання послання", "надсилання відповіді", і дві комбінованих дії: "надсилання послання - отримання відповіді" або, навпаки, "отримання послання - надсилання відповіді". Отримання та відправлення, у свою чергу, описуються вкладеними елементами і

, а повідомлення про помилку - елемент . Послання, що одержуються і надсилаються, вже повинні бути описані елементами , елементи ,

І посилаються на НИХ СВОЇМ атрибутом message.

? - перераховує вкладеними елементами Набір портів, пов'язаних із однією Web-службою. Один і той же порт може бути пов'язаний із кількома службами.

? - описує конкретний формат пересилання послання: протоколи, такі як SOAP або HTTP, способи пакування послання, тип вмісту: HTML, XML або інший MIME-тип послання. Кожен елемент може бути пов'язаний з декількома такими елементами по одному для кожного способу пересилання. У цей елемент вкладаються елементи, визначені у схемі вибраного протоколу.

? < service >- Вказує розташування Web-служби як один або кілька портів. Кожен порт описується вкладеним елементом Інтерфейс Web-служби, що містить адресу, заданий за правилами обраного в елементі способу пересилання.

Крім цих шести основних елементів є ще два допоміжні елементи.

? - включає файл із XSD-схемою опису WSDL або інший WSDL-файл.

Коментар. Його можна включити до будь-якого елементу

Опис WSDL.

Можна сказати, що елементи , і Показують, ЩО є в описаній Web-службі, які послуги вона надає, як організовані послуги, які типи даних у цих послуг.

Елементи пояснюють, ЯК реалізовано Web-службу, який протокол передачі послань: HTTP, SMTP або якийсь інший, а також задає технічні характеристикипередачі даних.

Нарешті елементи показують, ДЕ знаходиться Web-служба, пов'язуючи опис із конкретними адресами Web-служби.

Структура документа WSDL показана у лістингу 4.1. Символи у квадратних дужках не містяться у документі. Вони показують повторюваність елемента або атрибута в описі веб-служби:

Символ [?] означає, що елемент або атрибут може з'явитись у документі нуль або один раз;

Символ [*] означає, що елемент може з'явитися нуль або кілька разів;

Символ [+] означає, що елемент може з'явитись один або кілька разів;

Відсутність символу у квадратних дужках означає, що атрибут повинен з'явитися рівно один раз.

j Лістинг 4.1. Схема документа WSDL

targetNamespace="nfleH l ra«iij

location="URI-aflpec" /> [*]

Довільний коментар

Опис складних та нестандартних типів.

[*]

[*]

[? ]

Абстрактний опис SOAP-послання як набору складових його частин.

[*]

Анотація опису Web-служби як набору операцій (послуг).

[*]

Опис послуги як отримання (input) та відправлення (output, fault) послань.

[?]

Отримуване послання.

[?] [?]

Відправляється

message="nMH відповідного елемента "> [*] [?]

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

[*]

[+]

type="MMH відповідного елемента "> [*]

[?]

Деталі конкретного протоколу. Вони визначаються у схемі

цього протоколу. ->

[*]

[?]

Сюди записуються елементи, що описують деталі

конкретної операції. ->

[?]

Сюди записуються елементи, що описують

деталі конкретного одержуваного послання. ->

[?]

[?]

Сюди записуються елементи, що описують

деталі конкретного послання. ->

[*]

[?]

Сюди записуються елементи, що описують

деталі конкретного повідомлення про помилку. ->

serviceType="MMH відповідного елемента "> [*]

Опис інтерфейсу Web-служби як набору портів.

binding="nMH соотв. елемента "> [*]

[?]

Сюди записується обов'язкова та єдина адреса інтерфейсу Web-служби, записана за правилами

протоколу, вказаного в елементі . ->

Кожен конкретний протокол пересилання послань - SOAP, HTTP, FTP, SMTP - додає до шести основних та двох допоміжних елементів мови WSDL свої додаткові елементи, що описують особливості цього протоколу.

Наведемо найпростіший приклад. У лістингу 3.14 ми записали у вигляді класу Java найпростішу Web-службу, яка повертає без будь-якої обробки надісланий запит:

public class EchoService(

public String getEcho (String req) (return req;

У лістингу 4.2 наведено опис цієї Web-служби мовою WSDL, що використовує протокол SOAP.

Лістинг 4.2. Опис Web-служби EchoService

version="1.0" encoding="UTF-8" ?>

targetNamespace="http://echoservice.com/echoservice.wsdl" xmlns="http://www.w3.org/2002/07/wsdl" xmlns:tns="http://echoservice.com/echoservice.wsdl " xmlns:soap="http://www.w3.org/2002/07/wsdl/soapl2" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

transport="http://schemas.xmlsoap.org/soap/http" />

"http://schemas.xmlsoap.org/soap/encoding/"

namespace= "http://echoservice. ccm/echcservice .wsdl" use="encoded" />

^oapKbocy enccdingStyle=

"http://schemas .xmlsoap. org/soap/encoding/" namespace= "http://echoservice. c^/ech^service .wsdl" use="encoded" />

name="EchoServService">

Binding="tns:EchoServiceSoapBinding" name="EchoService"> location=

"http://localhost:8080/axis/EchoService.jws" />

У лістингу 4.2 ми в елементі визначили префікси всіх необхідних нам просторів імен. Далі ми описали запит та відповідь у двох елементах . Ми дали їм імена "getEchoRequest" і "getEchoRe- sponse". У запиті один аргумент типу xsd:string. Цей тип визначено у мові XSD. Ми дали аргументу ім'я req, що збігається з ім'ям аргументу методу getEcho(). Значення, яке повертається методом, ми дали ім'я return, його тип теж xsd: string.

Імена "getEchoRequest" та "getEchoResponse" ВИКОРИСТАНІ В наступному елементі Для вказівки вхідних та вихідних параметрів Web-послуги. У нього вкладено один елемент . Це означає, що служба Web надає одну послугу, ім'я якої "getEcho" збігається з ім'ям методу, що виконує цю послугу. В елементі вказано вхідний та вихідний

настройки послуги. Потім, елементом ми вказали один спосіб пересилання послань - SOAP-послання у процедурному стилі, що пересилаються за протоколом HTTP, на що вказує елемент

txarspcrt^=^"ht:tp^://?cheпas^.>пlscap^.c^rc^/?cap^/ht:tp^" />

Якщо застосовується документний стиль SOAP, то атрибуті style записується значення " document " .

Зрештою, в елементі вкладеним елементом Зв'язуємо елемент з елементом

, що вказує адресу, за якою розташована Web-служба.

У лістингу 4.2 імена з префіксом soap конкретизували опис послання та способи його пересилання. Розглянемо, які конкретні протоколи пропонує специфікація WSDL 1.2.

Література:

Хабібуллін І. Ш. Розробка Web-служб засобами Java. – СПб.: БХВ-Петербург, 2003. – 400 с: іл.