Введення в веб-сервіси

Передмова


Сьогодні багато уваги приділяється веб-сервісів. При цьому майже в кожній компанії створюється своє, власне визначення для цього поняття, хоча всі вони схожі між собою. Ця стаття починається з історичного огляду розподіленого програмування. Мета даного огляду – показати, що веб-сервіси є не повторним "винаходом колеса", а новим кроком у розвитку цієї технології.


Потім представлений огляд веб-сервісів, а також їх формальне визначення. При цьому замість створення ще одного нового визначення веб-сервісів обговорюється визначення, опубліковане на сайті WebServices.org. У заключній частині статті пояснюються три основні технології, що використовуються при роботі з веб-сервісами: SOAP, WSDL і UDDI.


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


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


Історичний ракурс


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


Перші проміжні програмні продукти, наприклад DCE, грунтувалися на моделі процедурного програмування. Їм на зміну прийшла об'єктно-орієнтована модель, реалізована в проміжних програмних продуктах CORBA, DCOM або RMI, які є найбільш популярним програмним забезпеченням цього класу в даний час.


Поточна ситуація


Як вже обговорювалося раніше, існує три основні технології проміжного програмного забезпечення: DCOM, CORBA і RMI. Кожна з них має свої переваги і недоліки. У цій главі засуджуються тільки основні можливості, без заглиблення в подробиці цих технологій. Це забезпечить уявлення про те, як веб-сервіси вписуються в загальну картину.


CORBA


CORBA представляє собою засноване на відкритих стандартах рішення для виконання розподілених обчислень. Промисловий консорціум OMG (група з розвитку стандартів управління програмними об'єктами) розробив специфікацію для CORBA і визначив протокол Internet InterORB Protocol (IIOP), Що є стандартним протоколом комунікації між диспетчерами об'єктних запитів ORB (Object Request Brokers).


Основна перевага CORBA полягає в тому, що і клієнти, і сервери можуть бути написані на будь-якій мові програмування. Це стає можливим, оскільки об'єкти визначаються з високим рівнем абстракції, забезпечуваним мовою визначення інтерфейсу IDL (Interface Definition Language). Після того, як визначення буде виконано в IDL-файле, компілятор забезпечує його перетворення в певну мову програмування. Взаємодії між об'єктами, клієнтами і серверами обробляються з допомогою диспетчерів об'єктних запитів ORB. Якщо від розподіленого додатка потрібна висока продуктивність, тоді CORBA є кращим вибором проміжного програмного забезпечення. Проте написання розподілених додатків за допомогою CORBA – це дуже складне завдання. Для того щоб забезпечити перетворення IDL на різні мови програмування, доводиться обмежуватися тими базовими концепціями, які реалізовані в підтримуваних мовами. Таким чином, IDL є для них чимось на зразок спільного знаменника.


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


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


RMI


Технологія виклику віддалених методів RMI (Remote Method Invocation) дозволяє створювати розподілені додатки Java-to-Java. У них методи віддалених Java-об'єктів можуть викликатися з інших віртуальних машина Java (JVM), найбільш ймовірно знаходяться на різних вузлах мережі. Java-програма може виконати виклик віддаленого об'єкта після отримання на нього посилання, або виконавши пошук віддаленого об'єкта в самозагрузчик просторі імен, запропонованому RMI, або отримавши посилання в якості аргументу або значення, що повертається. Клієнт може викликати віддалений об'єкт на сервері. Цей сервер у свою чергу теж може бути клієнтом для інших віддалених об'єктів. RMI використовує серіалізацию об'єктів, щоб упорядкувати і разупорядочіть їх параметри і запобігти усікання типів, підтримуючи справжній об'єктно-орієнтована поліморфізм. Для комунікацій використовується протокол JRMP (Java Remote Method Protocol).


Програмування з використанням RMI не викликає проблем, якщо розробник набув певного досвіду створення розподілених додатків і програмування мовою Java. При цьому не потрібне використання абстрактних мов (таких як IDL) для опису вилученого серверного об'єкта. Крім того, RMI підтримує розподілений механізм регенерації звільняється пам'яті.


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


DCOM


Технологія DCOM (Microsoft Distributed Component Object Model) дозволяє здійснювати виклики віддалених об'єктів з допомогою ланки, що надбудовується поверх механізму DCE RPC і взаємодіє з оперативними COM-сервісами. Сервер DCOM публікує свої методи для клієнтів, підтримуючи різні інтерфейси. Вони пишуться на мові IDL, схожому з C + +. Цей компілятор IDL створює модулі доступу (заступники), заглушки та скелетні елементи програми так само, як це робить IDL-компілятор CORBA, але реєструє їх також в системному реєстрі. Крім цього створюються бібліотеки типів. Вони являють собою файли, в яких описуються віддалені об'єкти і вказується, які з них можуть запитуватися інтерфейсами, що забезпечуються механізмом COM.


Для цього використовується протокол викликів віддалених об'єктних процедур ORPC (Object Remote Procedure Call).


Специфікація DCOM на двійковому рівні дозволяє використовувати різні мови для програмування серверних об'єктів.


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


Більшість користувачів пов'язують технологію DCOM з операційними системами Microsoft. Проте вже існують портірованний версії DCOM для Unix, VMS і Apple Macintosh.


Попереднє ув'язнення


Як було показано в попередньому розділі, всі ці три технології використання проміжного ПЗ працюють по одному схожим сценарієм. Їх відмінності виявляються, перш за все, в різних підтримуваних можливостях, а також у рівні складності. Усі вони приводять до встановлення надійного з'єднання клієнта із сервером, тому будь-яке з перерахованих вище проміжних ПО придатне для використання. Через відмінності в протоколах не можна здійснити виклик DCOM-сервера з RMI-клієнта. (Одним з кроків щодо вирішення цієї проблеми є звернення до механізму, що викликає RMI поверх IIOP, який використовується при розробці з застосуванням Enterprise JavaBeans). При цьому встановлюється з'єднання за принципом "від точки до точки".


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


Майбутні перспективи: веб-сервіси


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


Короткий огляд


Умовно кажучи, веб-сервісами називають програми, які можуть бути опубліковані, виявлені і запущені за допомогою Інтернет. Класичними прикладами веб-сервісів є:



Для виконання своїх завдань одні веб-сервіси можуть використовувати інші веб-сервіси.


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


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


Визначення


В якості формальної передумови наведемо визначення, опубліковане на сайті WebServices.org:


"Веб-сервіси – це виділені в самостійний елемент, слабкозв'язаного стислі функції, пропоновані за стандартними протоколами",


де:



Архітектура


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


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



Наступний малюнок ілюструє відносини між компонентами веб-сервісів.




























Підписи до малюнка
Service Broker Сервісний агент
Inquire Запит
Publish Публікація
Internet Інтернет
Service Requester Ініціатор сервісного запиту
Service Provider Постачальник сервісів
Bind З'єднання

Проміжне програмне забезпечення, яке обговорювалося до цих пір, використовувалося як двійкового протоколу зв'язку. Однак веб-сервіси використовують XML поверх протоколу HTTP. Тому не виникає жодних проблем при роботі через брандмауери, оскільки вони зазвичай не блокують порт HTTP. Якщо повернутися до визначення, можна помітити, що веб-сервіси не обов'язково повинні використовувати тільки HTTP. В якості альтернативи можуть бути розглянуті протоколи FTP і SMTP.


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


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


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


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


SOAP


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


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


У повідомленні SOAP в якості кореневого елемента міститься тег ENVELOPE (на російську мову його можна перекласти як "конверт"). Цей конверт містить два елементи:



Такий заголовок може містити набір так званих рядків заголовка, які можна використовувати для надання інформації, наприклад, при аутентифікації або кодуванні даних.


Крім того, два атрибути заголовка призначені для надання інформації про те, як повинен обробляти повідомлення SOAP його одержувач:



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



Додаючи цей атрибут зі значенням "1" до рядка заголовка, можна змусити одержувача виконати обробку цього рядка. Таким чином, можна забезпечити належну увагу цій терміні.


Якщо атрибут не вказується, то семантика має той же вигляд, як якщо б для нього було задано значення "0".


Усі рядки заголовка повинні отримувати назви згідно простору імен.


Крім того, простору імен для конверта і стиль кодування (encodingStyle) визначаються в рамках специфікації SOAP.


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


Специфікація визначає один рядок основної частини, яка використовується для перенесення інформації про помилку або статус, пов'язаної з цим повідомленням. У повідомленні SOA може бути тільки одна така рядок. Всі інші опису елемента <fault> будуть дані в кінці цього розділу.


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



public String getSymbol ( String company );


Ця функція отримує на вході один параметр, що позначає назву компанії. На виході повертається рядок, що показує символ, який використовується для отримання курсу акцій.


На наступному малюнку показано, які елементи обов'язково повинні міститися в повідомленні SOAP, щоб воно описувало розглянуту функцію.



<Envelope>
   <Body>
     <GetSymbol>
       <Company>
         Borland
       </Company>
     </GetSymbol>
   </Body>
</Envelope>


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


Інкапсуляція RPC-викликів є найважливішим аспектом використання SOAP. З цією метою в специфікації визначаються глобальні атрибути, звані "стилем кодування" (encodingStyle), які використовуються для серіалізациі даних і, таким чином, можуть застосовуватися для їх впорядкування при RPC-виклики. Вони можуть з'являтися в будь-якому елементі. Дочірні елементи, які мають свого власного атрибуту encodingStyle, потрапляють під дію стилю кодування найближчого до них в ієрархії батьківського елементу. Хоча правил кодування даних, що задаються специфікацією схеми XML, було б достатньо, SOAP використовує підмножина цих правил.


Подібно мов програмування в SOAP визначаються прості типи даних (такі як short, int, float), а також строкові, перераховуваними, складові типи даних і масиви. Кожен елемент складових типів також містить свій тип даних. Ці типи адаптуються із специфікації схеми XML (див. посилання в розділі довідкової інформації).


RPC-виклики кодуються в основній частині повідомлення. Щоб викликати метод, необхідні наступні дані:



URI викликається об'єкта не вказується в рамках конверта повідомлення. Це виконується при встановленні зв'язку за протоколом. Якщо в якості основного використовується протокол HTTP, то запитуваний їм URI визначає цільовий об'єкт.


Кожен з методів SOAP містить тільки один виклик методу. Виклик, описуваний складовим типом даних, має таку ж назву, що і даний метод. Для кожного параметра, що має таке ж ім'я і тип, що і зазначений параметр, існує "засіб доступу". Порядок параметрів повинен бути таким же, як і у зазначеній функції.


Таким чином, щоб розглянутий найпростіший приклад був RPC, він повинен виглядати наступним чином. До нього внесено поліпшення за допомогою просторів імен.



<SOAP-ENV:Envelope


             xmlns:SOAP-ENV=
“http://schemas.xmlsoap.org/soap/envelope/”


SOAP-ENV:encodingStyle=
“http://schemas.xmlsoap.org/soap/encoding/”>


<SOAP-ENV:Body>
           <mtd:GetSymbol xmlns:mtd=”an URI”
           <company xsi:type=”xsd:string”>
       Borland
            </company>
        </mtd:GetSymbol>
     </SOAP-ENV:Body>


</SOAP-ENV:Envelope>


Як можна бачити, SOAP, по суті, задає протокол для передачі в одну сторону.


Для того щоб встановити зв'язок типу "запит / відповідь" буде відправлятися друге повідомлення SOAP від постачальника до ініціатора сервісного запиту.


Обидва ці повідомлення не мають очевидного зв'язку між собою. Тобто SOAP не визначає, як повинні виглядати назви для засобів доступу. Однак повинно існувати засіб доступу для значення, що повертається, а також засоби доступу для кожного вихідного і кожного вхідного / вихідного параметрів. Необхідно дотримуватися те порядок, що й у повідомленні запиту: засіб доступу для значення, що повертається має бути першим.


Додатково в угоді з програмування запропоновано іменувати у відповідь повідомлення також як і повідомлення запиту, додаючи в кінці рядок "Response" ("відповідь").


На наступній ілюстрації показаний відповідь на раніше відправлений запит.



<SOAP-ENV:Envelope


xmlns:SOAP-ENV=
“http://schemas.xmlsoap.org/soap/envelope/”


SOAP-ENV:encodingStyle=
“http://schemas.xmlsoap.org/soap/encoding/”>


<SOAP-ENV:Body>
   <mtd:GetSymbolResponse
     xmlns:mtd=”an URI”>
     <return xsi:type=”xsd:string”>
        BORL
      </return>
   </mtd:GetSymbolResponse>
</SOAP-ENV:Body>


</SOAP-ENV:Envelope>


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


Це поле може оброблятися серверами або брандмауерами з метою фільтрації відповідних повідомлень.


У кінцевому рахунку, повний приклад відправки RPC-виклику SOAP по HTTP буде виглядати наступним чином.



POST /Symbol HTTP/1.1
Host: www.borland.com
Content-Type: text/xml; charset=”utf-8″
Content -Length: nnnn
SOAPAction: “www.borland.com/Symbol”


<SOAP-ENV:Envelope


xmlns:SOAP-ENV=
“http://schemas.xmlsoap.org/soap/envelope/”


SOAP-ENV:encodingStyle=
“http://schemas.xmlsoap.org/soap/encoding/”>


<SOAP-ENV:Body>
  <mtd:GetSymbol
    xmlns:mtd=”an URI”>
     <return xsi:type=”xsd:string”>
       BORL
     </return>
   </mtd:GetSymbol>
</SOAP-ENV:Body>


Якщо з яких-небудь причин відбувається збій запиту, елемент <fault> в основній частині буде використаний для пояснення помилки. Зазвичай елемент <fault> у SOAP містить наступні чотири підлеглих елементи:



У специфікації визначається чотири коду для опису типу помилки:


1. VersionMismatch (Невідповідність версій):


Дана версія не містить простору імен http://schemas.xmlsoap.org/soap/envelope/


2. MustUnderstand:


Елемент з атрибутом mustUnderstand, для якого задано значення "1" не був правильно оброблений.


3. Client (Клієнт):


Повідомлення було невірно оформлене.


4. Server (Сервер):


Повідомлення не може бути правильно оброблене, але помилка не пов'язана з його вмістом.



Пропонується зручний для читання пояснення.



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



Містить специфічну для конкретного додатка інформацію про помилку.


Для розглянутого прикладу буде показано повне повідомлення SOAP з можливою рядком <fault> для випадку, коли не вдається знайти певний символ.



POST /Symbol HTTP/1.1
Host: www.borland.com
Content-Type: text/xml; charset=”utf-8″
Content -Length: nnnn
SOAPAction: “www.borland.com/Symbol”


<SOAP-ENV:Envelope


xmlns:SOAP-ENV=
“http://schemas.xmlsoap.org/soap/envelope/”


SOAP-ENV:encodingStyle=
“http://schemas.xmlsoap.org/soap/encoding/”>


<SOAP-ENV:Body>
    <mtd:GetSymbol
       xmlns:mtd=”an URI”>
        <return xsi:type=”xsd:string”>
         BORL
          </return>
           </mtd:GetSymbol>
</SOAP-ENV:Body>


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




























Підписи до малюнка
Service Broker Сервісний агент
Service Requester Ініціатор сервісного запиту
Service Provider Постачальник сервісів
Internet Інтернет
inquire Service using SOAP Запит сервісу за допомогою SOAP
bind to Service using SOAP Запит сервісу за допомогою SOAP
publish Service using SOAP Публікація сервісу за допомогою SOAP

Тепер, коли у Вас з'явилося деяке уявлення про те, що таке SOAP, ми постараємося пояснити, як описуються функціональні можливості веб-сервісів.


WSDL


WSDL описує мережеві сервіси за допомогою граматики XML. У рамках цієї технології забезпечується документація для розподілених систем. Її мета – дати додаткам можливість взаємодіяти один з одним в автоматичному режимі.


У той час як SOAP визначає взаємодію між ініціатором запиту і постачальником, WSDL описує сервіси, пропоновані постачальником (в "кінцевій точці"), які можуть використовуватися як засіб створення правильних повідомлень SOAP для доступу до сервісів. WSDL-документ відіграє роль, подібну до ролі IDL-файлу в CORBA або дистанційного інтерфейсу при впровадженні Java RMI. Структура документа і його елементи описуються в наступних розділах.


Структура документа


Кореневим елементом будь-якого WSDL-документа є <визначення> елементів. У кожному документі міститься шість елементів, які можна поділити на дві групи: абстрактні визначення та конкретні визначення.




  1. типи <types>,

  2. повідомлення <messages>,

  3. тип порту <portType>.



  1. зв'язку <binding>,

  2. сервіси <service>.

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




























Підписи до малюнка
UDDI Registry Реєстр UDDI
Service Requester Ініціатор сервісного запиту
Service Provider Постачальник сервісів
Internet Інтернет
inquire WSDL using SOAP запит WSDL за допомогою SOAP
bind using SOAP підключення за допомогою SOAP
publish WSDL using SOAP публікація WSDL за допомогою SOAP


  1. Постачальник веб-сервісу описує його у документі WSDL і публікує його в UDDI, використовуючи реєстрацію за допомогою API для публікацій (створеного на основі SOAP).

  2. Ініціатор сервісного запиту використовує API інтерфейс запиту UDDI для пошуку відповідної реєстраційної інформації про відповідний постачальника сервісів. Якщо постачальник знайдений, можна виконати пошук елемента tModel, що вказує на даний документ WSDL.

  3. Запит SOAP буде створений відповідно до цього документа WSDL.

  4. Це запит SOAP буде відправлений постачальнику сервісів, а отриману відповідь буде оброблений.

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


У деяких розділах даної статті веб-сервіси розглядалися як "ще один тип проміжного ПЗ", схожий на інші аналогічні продукти, такі як CORBA і RMI, але безумовно, більш придатний для використання через Internet.


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


Довідкові матеріали


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*