XML Web Services. Огляд технології. Що таке Web-сервіси і чому вони важливі

Веб-служба, Веб-сервіс (англ. Web service) - ідентифікується веб-адресою програмна система зі стандартизованими інтерфейсами.

Веб-служби можуть взаємодіяти один з одним і з сторонніми додатками за допомогою повідомлень, заснованих на певних протоколах \u003d

• XML-RPC
• і т.д.

Веб-служба є одиницею модульності при використанні сервіс-орієнтованої архітектури додатку.

У побуті веб-сервісами називають послуги, що надаються в Інтернеті.
У цьому вживанні термін вимагає уточнення, Чи йде мова про пошук, веб-поштою, зберіганні документів, файлів, закладок і т. П.
Такими веб-сервісами можна користуватися незалежно від місця доступу в Інтернет, комп'ютера або браузера.

архітектура

Як показано на малюнку, можна виділити три інстанції, взаємодіючі в рамках веб-служби. Переведемо їх назви як замовник, виконавець і каталог (Service Requestor, Service Provider і Service Broker).

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

• Розширювана мова розмітки, призначений для зберігання і передачі структурованих даних;
• Протокол обміну повідомленнями на базі XML;
• : Мова опису зовнішніх інтерфейсів веб-служби на базі XML;
• Універсальний інтерфейс розпізнавання, опису та інтеграції (Universal Discovery, Description and Integration).

Каталог веб-служб і відомостей про компанії, що надають веб-служби в загальне користування або конкретним компаніям. Поки UDDI існують, однак, тільки в невеликих фірмових мережах і ще не знайшли широкого поширення у відкритому інтернеті.

методи розробки

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

При розробці знизу-вгору спочатку пишуться імплементує класи, а з їх вихідного тексту генеруються WSDL-файли, що документують службу. Недоліком цього методу є схильність Java-класів до частих змін. При підході зверху-вниз спочатку готується WSDL, а з нього генерується скелет Java-класу, імплементує службу. Цей шлях вважається більш важким, зате призводить до більш чистим і краще захищеним від змін рішенням. Поки формат повідомлень, якими обмінюються замовник і виконавець, не змінюється, зміни в кожному з них не порушують взаємодії. Ця техніка називається іноді "contract first", так як вихідною точкою є WSDL ( "договір" між замовником і виконавцем).

переваги

1. Веб-служби забезпечують взаємодія програмних систем незалежно від платформи. Наприклад, Windows-C #-клієнт може комунікувати з Java-сервером, що працює під Linux.
2. Веб-служби засновані на базі відкритих стандартів і протоколів. завдяки використання XML досягається простота розробки і налагодження веб-служб.
3. Використання інтернет-протоколу забезпечує HTTP-взаємодія програмних систем через міжмережевий екран. Це значна перевага, порівняно з такими технологіями, як CORBA, DCOM або Java RMI. З іншого боку, веб-служби не прив'язані намертво до HTTP - можуть використовуватися і інші протоколи.

недоліки

1. Менша продуктивність і більший розмір мережевого трафікув порівнянні з технологіями RMI, CORBA, DCOM за рахунок використання текстових XML-повідомлень. Однак на деяких веб-серверах можлива настройка стиснення мережевого трафіку.
2. аспекти безпеки. Відповідальні веб-служби повинні використовувати кодування, можливо - вимагати аутентифікації користувача. Чи достатньо тут застосування HTTPS, або кращі такі рішення, як XML Signature, XML Encryption або SAML - має бути вирішено розробником.

приклади

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

Google з 2002 до 2009 року надавав веб-службу, яка дозволяла замовникам шукати необхідну інформацію в інтернеті так само, як це роблять звичайні користувачі. По зручності це не порівняти, наприклад, з автоматичним розбором HTML-тексту Googleвскіх сторінок.

Amazon.com має веб-службу, яка надає різні веб-базовані послуги (щось "як послуга" - хмарні технології)

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

Вступ

Почати треба з того, для чого створювалася концепція веб-сервісів. До моменту появи цього поняття в світі вже існували технології, що дозволяють додаткам взаємодіяти на відстані, де одна програма могла викликати який-небудь метод в іншій програмі, яка при цьому могла бути запущена на комп'ютері, розташованому в іншому місті або навіть країні. Все цього скорочено називається 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 \u003d SOAPBinding. Style. RPC) public interface HelloWebService ( // говоримо, що цей метод можна викликати віддалено @WebMethod public String getHelloString (String name); ) У цьому коді класи WebService і WebMethod є так званими анотацій і нічого не роблять, крім як позначають наш інтерфейс і його метод, як веб-сервіс. Це саме можна сказати і до класу SOAPBinding. Різниця лише в тому, що SOAPBinding - це анотація з параметрами. В даному випадку використовується параметр style зі значенням, що говорять, що веб-сервіс буде працювати не через повідомлення-документи, а як класичний RPC, тобто для виклику методу. Давайте реалізуємо логіку нашого інтерфейсу і створимо в нашому пакеті клас HelloWebServiceImpl. До речі, зауважу, що закінчення класу на Impl - це угода в Java, за яким так позначають реалізацію інтерфейсів (Impl - від слова implementation, тобто реалізація). Це не вимога і ви вільні назвати клас як хочете, але правила хорошого тону того вимагають: package ru. javarush. ws; // таже анотація, що і при описі інтерфейсу, import javax. jws. WebService; // але тут використовується з параметром endpointInterface, // вказує повне ім'я класу інтерфейсу нашого веб-сервісу @WebService (endpointInterface \u003d "Ru.javarush.ws.HelloWebService") Public class HelloWebServiceImpl implements HelloWebService (@Override public String getHelloString (String name) ( // просто повертаємо вітання return "Hello," + name + "!" ; )) Запустимо наш веб-сервіс як самостійний сервер, тобто без участі будь-яких Tomcat і серверів додатків (це тема окремої розмови). Для цього в структурі проекту в папці src створимо пакет ru.javarush.endpoint, а в ньому створимо клас HelloWebServicePublisher з методом main: package ru. javarush. endpoint; // клас, для запуску веб-сервера з веб-сервісами import javax. xml. ws. Endpoint; // клас нашого веб-сервісу import ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher (public static void main (String... args) ( // запускаємо веб-сервер на порту 1986 // і за адресою, вказаною в першому аргументі, // запускаємо веб-сервіс, який передається в другому аргументі Endpoint. publish ( "Http: // localhost: +1986 / wss / hello", New HelloWebServiceImpl ()); )) Тепер запустимо цей клас, натиснувши Shift + F10. В консолі нічого не з'явиться, але сервер запущений. У цьому можна переконатися набравши в браузері рядок http: // localhost: 1 986 / wss / hello? Wsdl. Правда, яка сторінка, з одного боку, доводить, що у нас на комп'ютері (localhost) запустився веб-сервер (http: //) на порту 1986, а, з іншого боку, показує WSDL опис нашого веб-сервісу. Якщо ви зупините додаток, то опис змінюватиметься, як і сам веб-сервіс, тому робити цього не будемо, а перейдемо до написання клієнта.

клієнт

В папці проекту src створимо пакет ru.javarush.client, а в ньому клас HelloWebServiceClient з методом main: package ru. javarush. client; // потрібно, щоб отримати wsdl опис і через нього // дотягнутися до самого веб-сервісу import java. net. URL; // такої ексепшн виникне при роботі з об'єктом URL import java. net. MalformedURLException; // класи, щоб пропарсіть xml-ку c wsdl описом // і дотягнутися до тега service в ньому import javax. xml. namespace. QName; import javax. xml. ws. Service; // інтерфейс нашого веб-сервісу (нам більше і потрібно) import ru. javarush. ws. HelloWebService; public class HelloWebServiceClient (public static void main (String args) throws MalformedURLException ( // створюємо посилання на wsdl опис URL url \u003d New URL ( "Http: // localhost: тисячі дев'ятсот вісімдесят шість / wss / hello? Wsdl") ; // Параметри наступного конструктора дивимося в найпершому тезі WSDL опису - definitions // 1-ий аргумент дивимося в атрибуті targetNamespace // 2-ий аргумент дивимося в атрибуті name QName qname \u003d new QName ( "http://ws.javarush.ru/", "HelloWebServiceImplService"); // Тепер ми можемо дотягнутися до тега service в wsdl описі, Service service \u003d Service. create (url, qname); // а далі і до вкладеного в нього тега port, щоб // отримати посилання на віддалений від нас об'єкт веб-сервісу HelloWebService hello \u003d service. getPort (HelloWebService. class); // Ура! Тепер можна викликати віддалений метод System. out. println (hello. getHelloString ( "JavaRush")); )) Максимум коментарів по коду я дав в лістингу. Додати мені нічого, тому запускаємо (Shift + F10). Ми повинні в консолі побачити текст: Hello, JavaRush! Якщо не побачили, то мабуть забули запустити веб-сервіс.

висновок

В даному топіку був представлений короткий екскурс в веб-сервіси. Ще раз скажу, що багато з того, що я написав - це мої припущення з приводу того, як це працює, і тому мені не варто сильно довіряти. Буду вдячний, якщо знаючі люди мене поправлять, адже тоді я чогось навчуся. UPD.

анотація: Області застосування. Переваги. Особливості розробки web-сервісів для платформи.NET. Опис і виявлення web-сервісу

Що таке XML Web Service?

У міру розвитку інформаційних технологій виникали різні підходи до написання програм: модульне програмування, Подієво-орієнтоване програмування, Компонентно-орієнтоване програмування і проектування. Логічним продовженням цих підходів стала сервісно-орієнтована розробка програмного забезпечення.

Застосування сервісно-орієнтованих підходів дозволяє говорити про повторне використання (reuse) на макрорівні (рівні сервісів), на відміну від мікро-рівня (рівня об'єктів). Сервісно-орієнтований підхід передбачає використання простих і загальноприйнятих стандартів, що дозволяє самим різним програмам використовувати функціональність один одного. Сервіси можуть бути написані з використанням самих різних мов програмування, на різних платформах. Крім того, сервіси можуть бути розгорнуті окремо або в рамках програмного комплексу в будь-якій точці земної кулі і будуть таким чином надавати доступ до своєї функціональності по мережі.

назвемо сервісом (service) ресурс, який реалізує бізнес-функцію і володіє наступними властивостями:

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

Окремим випадком сервісу є XML web-сервіс.

XML Web-сервіс - це особливий тип web-додатків, який:

• розгортається на web-сервері;
• публікує web-методи, які можуть бути викликані зовнішніми клієнтами;
• очікує надходження HTTP-запитів, які є командами викликів web-методів;
• виконує web-методи і повертає результати.

На відміну від традиційного web-додатків, у web-сервіси немає призначеного для користувача інтерфейсу. Замість цього у нього є програмний інтерфейс, тобто web-сервіс надає функції (web -Методи), які можуть бути викликані віддалено (наприклад, через мережу Internet). Web-сервіс не призначений для обслуговування кінцевих користувачів. Його завдання - надання послуг іншим додаткам, будь то web-додатків, додатки з графічним призначеним для користувача інтерфейсом або консольні додатки.

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

Web-сервіси - не власне конкретної компанії. Це промисловий стандарт на основі відкритих протоколів (SOAP, HTTP і т. Д.). Web-сервіси розгортаються на різних платформах (в тому числі на серверах під управлінням Windows або UNIX). Web-сервіси можна розробляти з застосуванням багатьох засобів розробки (від текстового редактора до сімейства Microsoft Visual Studio).

Методи більшості web-сервіси викликаються HTTP-запит, що містять повідомлення SOAP SOAP - це XML -Мова (XML vocabulary) для виклику віддалених процедур по HTTP і іншим протоколам ( повний опис SOAP http://www.w3.org/TR/SOAP).

Місце web-сервісів серед інших технологій віддаленого виклику

Існує чимало протоколів і технологій віддаленого виклику: Microsoft Distributed Component Object Model (DCOM), the Object Management Group "s Common Object Request Broker Architecture (CORBA), Sun" s Remote Method Invocation (RMI),. NET Remoting, XML Web Services.

Всі ці компонентно-орієнтовані технології (DCOM, CORBA і RMI) довгі роки успішно застосовувалися в Intranet-додатках. Вони забезпечують надійну, масштабовану архітектуру. Однак при використанні цих технологій в Internet виникають дві серйозні проблеми. По-перше, вони погано взаємодіють між собою. Всі технології оперують об'єктами, але істотно відрізняються деталями: управлінням життєвим циклом, підтримкою конструкторів і ступенем підтримки успадкування. Другий, більш важливий аспект полягає в тому, що орієнтація на RPC-взаємодії призводить до побудови сільносвязний систем на основі явних викликів методів об'єктів.

На відміну від даних технологій, XML Web Services і. NET Remoting в повній мірі реалізують об'єктно-орієнтований підхід для web -програмування.

XML Web Service - компонент, що надає Internet-клієнтів набір функцій API або web -методів. XML входить в назву, оскільки web-сервіси і їх клієнти використовують його для обміну даними. В основі web-сервіси лежать відкриті стандарти, такі як HTTP, XML (Extensible Markup Language), SOAP (Simple Object Access Protocol - стандарт Intenet, що описує, як додатки можуть взаємодіяти, тобто викликати методи один одного, за допомогою HTTP і інших протоколів ). Основне завдання web-сервіси - забезпечення межпрограммного взаємодії. Багато хто працює на UNIX-сервер, при цьому до них звертаються Windows-клієнти. Дані, що передаються web-сервіси, серіалізуются в XML і передаються в SOAP-пакет. Метадані про вміст таких повідомлень зберігаються в WSDL-контракті web-сервіси і схемах XSD. Головна перевага такого підходу - читабельність метаданих. Розробник може легко переглянути всі опис web-сервіси і навіть створити власний модуль, який розбирає SOAP -пакети.

.NET Remoting надає інфраструктуру для розподілених об'єктів. Вона набагато складніше простий архітектури web-сервіси, заснованої на передачі повідомлень. . NET Remoting включає передачу параметрів по посиланню і значенням, зворотні виклики, множинну активацію об'єктів і політики управління життєвим циклом. Щоб використовувати зазначені можливості, клієнтське додаток повинен володіти всіма технологіями. Дані в. NET Remoting передаються в бінарному або SOAP-формату. Однак в будь-якому випадку метадані про структуру переданої інформації містяться в загальномовного виконуючого середовищі. Без загальномовна виконуючого середовища (CLR) клієнтську програму не зможе розібрати специфічні для. NET Remoting заголовки SOAP. Тобто. NET Remoting пред'являє істотно вищі вимоги в порівнянні з web-сервіси.

Розробка web-сервісів на платформе.NET

Є багато способів написання web-сервіси. Їх можна розробляти вручну або за допомогою SOAP -Інструменти, що надаються Microsoft, IBM і ін. Написання web-сервіси з допомогою Microsoft. NET має дві переваги:

• .NET Framework істотно спрощує процес розробки за рахунок надання бібліотеки класів і автоматизації окремих етапів розробки;
• Web-сервіси, написані з помощью.NET Framework, - це керовані програми. Тобто в таких додатках не виникає проблем витоків пам'яті, неправильно ініціалізованих покажчиків та інших типових проблем програмування.

створення

Розробимо простий web-сервіс AdditionService, який здійснює складання двох чисел. У нього буде всього один метод Add, що приймає як параметр два цілих числа і повертає також ціле число. AdditionService демонструє кілька важливих принципів програмування web-сервісів за допомогою Microsoft .NET Framework.

• Web-сервіси реалізуються як ASMX-файли. ASMX - це особливе розширення імені файлу, зареєстроване за ASP .NET (точніше, за HTTP-обробником ASP.NET) в головному файлі конфігурації ASP .NET Machine.config.
• ASMX-файли починаються директивою @WebService. Ця директива повинна містити хоча б атрибут Class, що задає клас, з якого складається web-сервіс.
• Класи web-сервісів можуть мати необов'язкові атрибути WebService. В даному прикладі такий атрибут призначає ім'я web-сервісу і опис, яке відображається на HTML-сторінці, коли користувач викликає в браузері AdditionService.asmx.
• Web-методи оголошуються шляхом призначення відкритим методам класу Web-сервісу атрибута WebMethod. Для допоміжних методів, що застосовуються всередині нього, але недоступних зовнішнім клієнтам, цей атрибут просто не вказується.
• HTTP, XML і SOAP "невидимі". Роботу з XML-даними і повідомленнями SOAP виполняет.NET Framework.

AdditionService.asmx<%@ WebService language="C#" Class="AddService" %> using System using System.Web.Services class AddService (public int Add (int a, int b) (return a + b))

Незважаючи на малі розміри, AdditionService.asmx - повноцінний web-сервіс, якщо його встановити на web-сервер з ASP.NET. Його методи викликаються за допомогою SOAP, HTTP GET і HTTP POST, і він може повертати результати як SOAP-відгуки або як прості XML-оболонки.

Використовуючи фоновий код, класи web-сервісу можна винести з asmx-файлів в окремі файли.

Web-сервіси підтримують використання складних типів даних в якості вхідних або вихідних параметрів. Складні типи даних підтримуються, так як XML дозволяє легко серіалізовать більшість типів даних. Однак при автоматичному тестуванні web-сервісу ASP .NET не генерує тестові сторінки для методів, які приймають складні типи даних. Це відбувається тому, що не можна передати складні типи даних web-методу за допомогою HTTP GET і POST.

Web-сервіси дозволяють викликати свої методи асинхронно. Асинхронний виклик повертає управління негайно, незалежно від того, скільки часу потрібно web-сервісу на обробку виклику. Асинхронні виклики корисні в разі, якщо обробка виклику вимагає значного часу. Додаток виконує виклик, далі продовжує працювати, не чекаючи результату виклику, і пізніше отримує результати асинхронного виклику. Отримання результату відбувається при повторному виклику web-методу в зручне додатком час або за допомогою підписки на повідомлення про закінчення обробки виклику web-сервісом (механізм делегатів).

Web-сервіси можна створювати за допомогою інструментальних засобів, наприклад, Microsoft Visual Studio 2005. Для створення web-сервісів там передбачений окремий тип проекту ASP .NET Web Service. Visual Studio генерує asmx-файл, файл з фоновим кодом для опису класів web-сервісу, файл конфігурації web-сервісу і т. Д. При запуску проекту на виконання відбувається компіляція класів сервісу та відкриття asmx-файлу у вікні браузера.

Опис web-сервісів за допомогою контрактів

Для того щоб інші розробники могли використовувати AdditionService, їм потрібно знати, які методи він надає, які протоколи підтримує, сигнатури методів і адреса web-сервісу (URL). Вся ця та інша інформація може бути описана на мові WSDL (Web Service Description language).

Виявлення web-сервісів

Яким чином інші розробники дізнаються про існування AdditionService?

По-перше, за допомогою DISCO (скорочення від слова discovery) - файлового механізму пошуку локальних web-сервісів, тобто механізму отримання списку доступних web-сервісів з DISCO-файлів, розміщених на web-серверах. Крім того, DISCO-файли містять записи про розташування WSDL-контрактів наявних сервісів. DISCO-файл являє собою XML-файл з записами.

Також можливо використовувати VSDISCO-файли, які аналогічні DISCO-файлів, але їх вміст є результат динамічного пошуку web-сервісів в зазначених каталогах і всіх вкладених підкаталогах. ASP .NET відображає розширення імені файла.vsdisco на HTTP-обра-робником, який шукає в даному каталозі і його підкаталогах asmx і disco і повертає динамічно генерується DISCO-документ. З міркувань безпеки динамічний пошук в ряді версій.NET Framework відключений, але його можна включити, змінивши записи файлу Machine.config.

А як же здійснюється пошук web-сервісів в глобальної мережі? Для пошуку web-сервісів в глобальній мережі Microsoft, IBM і Ariba спільно розробили UDDI (Universal Description Discovery and Integration) - специфікацію побудови розподілених баз даних, яка дозволяє відшукувати web-сервіси. UDDI підтримується сотнями компаній. UDDI-сайти самі є web-сервісами. Кожен може опублікувати свій реєстр на основі UDDI. Більшість розробників ніколи не використовують UDDI API безпосередньо. Замість цього до реєстрів UDDI звертаються інструментальні засоби розробки. Вони також генерують класи-оболонки виявлених і вибраних web-сервісів.

підсумки

XML Web-сервіс є програмним компонентом, що надає функціональність, яку можуть використовувати самі різні системи, Що підтримують такі стандарти, як XML і HTTP Клієнтами web-сервіси можуть бути як локальні, так і віддалені програми. Web-сервіси дозволяють створювати структури, що дозволяють легше інтегрувати різні системи на основі простих загальноприйнятих стандартів.

Веб-служба - це програма, до якої можуть звертатися інші програми через Інтернет (http). Наприклад, припустимо, що у вас є функція, яка надає текст в форматі HTML. Мета програми - це веб-браузер, який відображає результати, і людина зможе легко прочитати цей текст на сторінці.

З іншого боку, цільовою аудиторією веб-сервісу є інші програми або інші веб-служби, які споживають дані, які обслуговуються веб-службою. Зазвичай висновок здійснюється на стандартній мові, який може бути зрозумілий іншим програмам. Візьміть Наведений вище приклад, якщо веб-служба виводить текст в форматі XML, тоді інші веб-служби, які можуть читати або розуміти XML, можуть використовувати цей висновок.

Основною перевагою веб-служби є те, що додатки можуть бути написані на будь-якій мові, але вони можуть обмінюватися даними і обмінюватися даними один з одним через веб-службу. програмні додатки, Написані на різних мовах програмування і працюють на різних платформах, можуть використовувати веб-служби для обміну даними через Інтернет (HTTP). Ця взаємодія (наприклад, між Java і Python, або додатками Windows і Linux) пов'язане з використанням відкритих стандартів (XML, SOAP, HTTP).

• SOAP (простий протокол доступу до об'єктів)
• UDDI (універсальне опис, виявлення і інтеграція)
• WSDL (мова опису веб-сервісів)

Скільки існує різних видів веб-служб?

В першу чергу, існують два типи веб-служб, простий протокол доступу до об'єктів (SOAP) і репрезентативний перенесення станів (REST).

• Веб-служба SOAP приймає запит в форматі XML і генерує висновок в форматі XML.
• Веб-служба REST більш універсальна і може приймати XML, а також JSON в якості запиту і генерує висновок в XML, а також в JSON або навіть HTML

Детальніше це питання може бути вивчений на наших.

19 відповідей

Просте визначення: веб-служба - це функція, до якої можуть звертатися інші програми через Інтернет (Http). Щоб трохи уточнити, коли ви створюєте веб-сайт на PHP, який виводить HTML, його метою є браузер і, на додаток, людина, що читає сторінку в браузері. Веб-послуга непридатна для людей, а скоріше для інших програм.

Таким чином, ваш сайт PHP, який генерує випадкове ціле число, може бути веб-службою, якщо він виводить ціле число в форматі, який може бути використаний іншою програмою. Це може бути в форматі XML або іншому форматі, якщо інші програми можуть зрозуміти висновок.

Повне визначення, очевидно, більш складне, але ви попросили простий англійський.

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

Приклад: Я можу перейти на maps.google.com і ввести свою домашню адресу, а також подивитися, де я живу в своєму браузері.

Але що, якщо ви пишете комп'ютерну програму, Де ви хочете взяти адресу і показати симпатичну карту, точно так же, як карти Google?

Ну, ви могли б написати зовсім нову програму зіставлення з нуля, або ви могли б назвати веб-службу, яку карти Google надають, відправити їй адресу, і вона поверне графічну карту розташування, яку ви можете відобразити в своєму програма.

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

Так, це простий веб-сервіс.

Веб-сервіси - це не що інше, як механізм запиту / відповіді, який дозволяє клієнту віддалено отримувати доступ / змінювати дані. Існують офіційні стандарти для веб-сервісів (SOAP, SOA і т.д.), Але ваша проста сторінка також є сервісом.

Основний недолік друку на сторінці - це те, що ваша служба поверне HTML. Кращими форматами даних є JSON і XML, оскільки більшість клієнтських фреймворків (і серверних фреймворків) розроблені з використанням JSON і XML.

Отже, якщо ви змінили свій сервіс для повернення:

some random number

... some random number

то це було б більш корисно для більшості клієнтів

У більш спрощених термінах веб-служба - це те, що надає дані як послугу по протоколу http. Звичайно, це не так ... але він близький.

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

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

Прикладами веб-сервісів є такі речі, як Weather.com, що надають інформацію про погоду, яку ви можете використовувати на своєму сайті, або ІБП, що надає метод запиту лапок або відстеження пакетів.

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

Веб-служба відрізняється від веб-сайту тим, що веб-служба надає інформацію, яка споживається програмним забезпеченням, а не людьми. В результаті ми зазвичай говоримо про експонованих JSON, XML або SOAP-сервісах.

Веб-сервіси є ключовим компонентом у "mashups". Mashups - це коли інформація з багатьох сайтів автоматично агрегируется в новий і корисний сервіс. Наприклад, є сайти, які об'єднують карти Google з інформацією про поліцейських звітах, щоб дати вам графічне представлення про злочинності в вашому районі. Іншим типом mashup було б отримання реальних даних про запаси, що надаються іншим сайтом, і об'єднання їх з підробленим торговим додатком для створення "ринкової гри" на фондовому ринку.

Веб-служби також використовуються для надання новин (див. RSS), останніх елементів, доданих на сайт, інформації про нові продукти, подкастах і інших чудових функціях, які роблять сучасний веб-поворот.

Надіюсь це допоможе!

Для більшості сайтів у вас є сторінки HTML, Які ви відвідуєте, коли використовуєте свій браузер. Це сторінки, читаються людиною (після візуалізації в вашому браузері), де безліч даних може бути переповнене, тому що це має сенс для людей.

Тепер уявіть, що хтось хоче використовувати деякі з цих даних. Вони можуть завантажити вашу сторінку і почати фільтрувати весь "шум", щоб отримати потрібні їм дані, але більшість веб-сайтів не побудовані таким чином, що дані на 100% напевно будуть поміщені в один і той же місце для всіх елементів, тому додатково до тому, щоб бути громіздким, він також стає ненадійним.

Введіть веб-служби.

Веб-сервіс - це те, що веб-сайт пропонує запропонувати тим, хто хоче читати, оновлювати та / або видаляти дані з вашого сайту. Ви можете назвати це "бекдор" для своїх даних. Замість того, щоб представляти дані як частина веб-сторінки, вона надається заздалегідь певним чином, де деякі з найбільш популярних - це XML і JSON. Існує кілька способів спілкування з веб-сервісом, деякі використовують SOAP, інші - веб-служби REST "а і т.д.

Що характерно для всіх веб-сервісів, так це те, що вони є машиночитаному еквівалентними веб-сторінок, які сайт пропонує іншим. Це означає, що інші, які бажають використовувати дані, можуть відправити запит на отримання певних даних, які легко розібрати і використовувати. На деяких сайтах може знадобитися ввести ім'я користувача / пароль в запиті для конфіденційних даних, в той час як інші сайти дозволяють будь-кому витягувати будь-які дані, які можуть їм знадобитися.

Найкраще пояснення на англійською пояснюється аналогією:

• Веб-сторінки дозволяють людям спілкуватися і співпрацювати один з одним.
• Веб-служби дозволяють програмам спілкуватися і співпрацювати один з одним.

Ваш приклад PHP - це веб-сервіс за цим визначенням, тому що висновок може бути використаний іншою програмою. Але насправді HTML-скребок екрану не є надійним або підтримуваним способом створення веб-сервісів.

Веб-сервіс являє собою набір відкритих протоколів та стандартів, які використовуються для обміну даними між додатками або системами. Програмні додатки, написані на різних мовах програмування і працюють на різних платформах, можуть використовувати веб-служби для обміну даними по комп'ютерних мереж, Таким як Інтернет, способом, аналогічним межпроцессорной комунікації на одному комп'ютері. Ця сумісність (наприклад, між Java і Python, або додатками Windows і Linux) пов'язана з використанням відкритих стандартів (XML, SOAP, HTTP).

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

• SOAP (протокол простого доступу до об'єктів)
• UDDI (універсальне опис, виявлення і інтеграція)
• WSDL (мова опису веб-служб)

Він працює приблизно так:

Webservice - це технологія, за допомогою якої два або більш віддалених веб-додатки взаємодіють один з одним по мережі / Інтернету. Він може бути реалізований з використанням Java, .net, PHP і т.д.

Особливості веб-служби: -

Операційна система надає інтерфейс GUI (і CLI), з яким ви можете взаємодіяти. Він також надає API, з яким ви можете взаємодіяти з програмним забезпеченням.

Аналогічним чином, веб-сайт надає HTML-сторінки, з якими ви можете взаємодіяти, а також може надавати API, який пропонує таку ж інформацію і операції програмно. Або ці служби можуть бути доступні тільки через API без відповідного призначеного для користувача інтерфейсу.

Веб-служба, що використовується розробниками програмного забезпечення, зазвичай відноситься до операції, виконуваної на віддаленому сервері і викликається з використанням специфікації XML / SOAP. Як і у всіх визначеннях, існують нюанси, але це найбільш поширене використання терміну.

Simple way to explain web service is ::

• Веб-сервіс - це спосіб зв'язку між двома електронними пристроями по Всесвітній павутині.
• Його можна назвати процесом, який програміст використовує для зв'язку з сервером.
• Для виклику цього процесу програміст може використовувати SOAP і т.д.
• Веб-служби створюються поверх відкритих стандартів, таких як TCP / IP, HTTP

Перевага веб-служби полягає в тому, що, скажімо, ви розробляєте один шматок коду в.net, і ви хочете використовувати JAVA для використання цього коду. Ти можеш взаємодіють безпосередньо з абстраговані шаром і не знають, що технологія була розроблена для розробки коду.

Оскільки @Vincent Ramdhanie сказав, що веб-сервіс не призначений для перегляду / споживання кінцевим користувачем, а інший програми. Таким чином, технічна логіка в вашій програмі буде:

У разі виконання нормальної програми

User on website -\u003e HTML / JS / JQuery etc -\u003e give me a random number -\u003e ur program

ur program -\u003e generate random number -\u003e generate HTML and encapsulate o / p -\u003e go back to user