Уеб услуги в Java SE, част 1: Преглед на инструментите

Java Standard Edition (SE) 6 включва поддръжка за уеб услуги. Тази публикация започва поредица от четири части за уеб услуги в Java SE, като обяснява какво представляват уеб услугите и преглежда поддръжката на Java SE за тях. Бъдещите публикации ще използват тази поддръжка за изграждане на базирани на SOAP и RESTful базирани уеб услуги и също така ще обхващат разширени теми за уеб услуги.

Java XML и JSON

В тази поредица предполагам, че разбирате XML и JSON. Ако не, може да разгледате моята книга за Java XML и JSON , която се рекламира в края на тази публикация.

Какво представляват уеб услугите?

Уикипедия определя уеб услугата като „софтуерна система, предназначена да поддържа оперативно съвместимо взаимодействие машина към машина през мрежа“. По-подробна дефиниция може да бъде получена чрез първо определяне на частите на този термин:

  • Web: Огромна взаимосвързана мрежа от ресурси, където ресурс е източник на данни с единен идентификатор на ресурс (URI), като PDF-базиран документ, видео поток, уеб страница или дори приложение. Тези ресурси могат да бъдат достъпни чрез използване на стандартни интернет протоколи като HyperText Transfer Protocol (HTTP) или Simple Mail Transfer Protocol (SMTP).
  • Услуга: Приложение или софтуерен компонент, базиран на сървър, който излага ресурс на клиентите чрез обмен на съобщения според модела за обмен на съобщения (MEP). Членовете на Европейския парламент за искане-отговор са типични.

Като се имат предвид тези дефиниции, уеб услугата е сървърно базирано приложение / софтуерен компонент, който излага уеб базиран ресурс на клиенти чрез обмен на съобщения. Тези съобщения могат да бъдат форматирани съгласно Extensible Markup Language (XML) или JavaScript Object Notation (JSON). Също така тези съобщения могат да се възприемат като извикващи функции на уеб услуги и като получаващи резултати от извикване. Фигура 1 илюстрира този обмен на съобщения.

Фигура 1. Клиентът получава достъп до ресурс, като обменя съобщения с уеб услуга

Бизнес и уеб услуги

Бизнесът използва уеб услуги, тъй като преодолява традиционните проблеми на средния софтуер (напр. Скъпи за получаване и поддръжка, неспособни да комуникират с бекенд софтуер и клиентски приложения в Интернет и негъвкави), като се основават на безплатни и отворени стандарти, чрез тяхната поддръжка, като включват в мрежата и чрез гъвкавост. Освен това те помагат на по-големия бизнес да запази своите често значими инвестиции в стария софтуер.

Уеб услугите могат да бъдат класифицирани като прости или сложни. Простите уеб услуги не взаимодействат с други уеб услуги (например самостоятелно сървърно базирано приложение с една функция, която връща текущото време за определена часова зона). За разлика от тях сложните уеб услуги често взаимодействат с други уеб услуги. Например, обобщена социална мрежа Уеб услуга може да взаимодейства с Twitter и Facebook уеб услуги, за да получи и върне на своя клиент цялата Twitter и цялата информация на Facebook за конкретно лице. Комплекс уеб услуги са известни също като каша , защото те каша (съчетават) данни от множество уеб услуги.

Архитектура, ориентирана към услуги

Уеб услугите са изпълнение на ориентирана към услуги архитектура (SOA) , което е стил на софтуерно проектиране, при който услугите се предоставят на различни софтуерни компоненти чрез комуникационен протокол през мрежа. Помислете за SOA като набор от принципи на проектиране или рамка за внедряване на бизнес логика като услуги за многократна употреба, които могат да се комбинират по различни начини, за да отговорят на променящите се бизнес изисквания.

Уеб услуги, базирани на SOAP

А уеб услуга SOAP базиран е широко използван категория уеб услуга, която се основава на SOAP , език на XML за определяне на съобщенията (абстрактна функция извиквания или техните отговори), които могат да бъдат разбрани от двата края на мрежова връзка. Обменът на SOAP съобщения се нарича операция , която съответства на извикване на функция и нейния отговор и която е изобразена на фигура 2.

Фигура 2. Операция на уеб услуга включва входни и изходни съобщения

Свързаните операции често се групират в интерфейс , който е концептуално подобен на Java интерфейс. А задължителен предвижда конкретни подробности за това как интерфейс е свързан с протокол за съобщения (особено SOAP), за да общуват команди, кодове за грешки, както и други предмети върху кабела. Обвързващият и мрежовият адрес (IP адрес и порт) URI е известен като крайна точка , а колекция от крайни точки е уеб услуга . Фигура 3 представя тази архитектура.

Фигура 3. Интерфейсите на операциите са достъпни чрез техните крайни точки

SOAP често се използва с езика за описание на уеб услуги (WSDL, произнася се whiz-dull) , XML език за определяне на операциите на уеб услуга. А документ WSDL е формален договор между уеб услуга SOAP базиран и на своите клиенти, като предоставя всички данни за взаимодействие с уеб услугата. Този документ ви позволява да групирате съобщения в операции и операции в интерфейси. Също така ви позволява да дефинирате обвързване за всеки интерфейс, както и адреса на крайната точка.

Освен че поддържат WSDL документи, базираните на SOAP уеб услуги имат следните свойства:

  • Възможността да се отговори на сложни нефункционални изисквания като сигурност и транзакции: Тези изисквания се предоставят чрез различни спецификации. За да се насърчи оперативната съвместимост сред тези спецификации, беше сформирана Организацията за оперативна съвместимост на уеб услугите (WS-I) (индустриален консорциум). WS-I е създал набор от профили, където профилът е набор от наименовани спецификации на уеб услуги на конкретни нива на ревизия, заедно с набор от насоки за изпълнение и оперативна съвместимост, препоръчващи как спецификациите могат да се използват за разработване на оперативно съвместими уеб услуги. Например, първият профил, WS-I Basic Profile 1.0 , се състои от следния набор от специални спецификации на уеб услуги:
  • САПУН 1.1
  • WSDL 1.1
  • Универсално описание Откриване и интеграция (UDDI) 2.0
  • XML 1.0 (второ издание)
  • XML схема част 1: Структури
  • XML схема част 2: Типове данни
  • RFC2246: Протокол за защита на транспортния слой, версия 1.0
  • RFC2459: Сертификат за инфраструктура с публичен ключ Internet X.509 и CRL профил
  • RFC2616: Протокол за прехвърляне на HyperText 1.1
  • RFC2818: HTTP през TLS
  • RFC2965: Механизъм за управление на състоянието на HTTP
  • Протоколът за слой със защитени гнезда версия 3.0

Допълнителни примери за профили включват WS-I Basic Security Profile и Simple SOAP Binding Profile. За повече информация относно тези и други профили посетете уебсайта на WS-I. Java SE поддържа основния профил на WS-I.

  • Възможност за асинхронно взаимодействие с уеб услуга: Клиентите на уеб услуги трябва да могат да взаимодействат с уеб услуга по неблокиращ, асинхронен начин. Поддръжката на асинхронно извикване от страна на клиента за операции на уеб услуги се предоставя в Java SE.

Уеб услугите, базирани на SOAP, се изпълняват в среда, която включва заявител на услуги (клиент), доставчик на услуги и брокер на услуги. Тази среда е показана на Фигура 4.

Фигура 4. Уеб услугата, базирана на SOAP, включва заявител на услуги, доставчик на услуги и брокер на услуги (например UDDI)

Заявителят на услуги, обикновено клиентско приложение (например уеб браузър), или може би друга уеб услуга, първо локализира доставчика на услуги по някакъв начин. Например заявителят на услугата може да изпрати WSDL документ до брокер на услуги, който отговаря с друг WSDL документ, идентифициращ местоположението на доставчика на услуги. След това заявителят на услуги комуникира с доставчика на услуги чрез SOAP съобщения.

Доставчиците на услуги трябва да бъдат публикувани, за да могат другите да ги намират и използват. През август 2000 г. стартира отворена индустриална инициатива, известна като Универсално описание, откриване и интеграция (UDDI), за да позволи на предприятията да публикуват списъци с услуги, да се откриват взаимно и да определят как взаимодействат услугите или софтуерните приложения през Интернет. Този независим от платформата, базиран на XML регистър обаче не беше широко приет и понастоящем не се използва. Много разработчици установиха, че UDDI е прекалено сложен и липсва функционалност, и са избрали алтернативи като публикуване на информацията на уебсайт. Например Google веднъж направи публичните си уеб услуги (например Google Maps) достъпни на //code.google.com/more/.

SOAP съобщенията, които протичат между заявителите на услуги и доставчиците на услуги, често са невидими и се предават като заявки и отговори между SOAP библиотеките на техните стекове на протоколи за уеб услуги. Възможно е обаче да получите директен достъп до тези съобщения, както ще откриете по-късно в тази поредица.

Големи уеб услуги

Уеб услугите, базирани на SOAP, са известни също като големи уеб услуги, тъй като се основават на много спецификации, като споменатите по-рано WS-I профили.

RESTful уеб услуги

Базираните на SOAP уеб услуги могат да се доставят чрез протоколи като HTTP, SMTP, FTP и Blocks Extensible Exchange Protocol (BEEP). Предоставянето на SOAP съобщения през HTTP може да се разглежда като специален вид RESTful уеб услуга.

А RESTful Web Service е широко използван категория уеб услуга, която е на базата на представителна държавна Transfer (REST) , софтуерна архитектура стил за разпределени хипермедийни системи (системи, в които се намират изображения, текст и други ресурси, около мрежи и са достъпни чрез хипервръзки) . Интересната хипермедийна система в контекста на уеб услугите е World Wide Web.

ПОЧИВКА история

Рой Филдинг (главен автор на HTTP спецификациите версии 1.0 и 1.1 и съосновател на Apache Software Foundation) въведе и определи REST в своята докторска дисертация още през 2000 г. Филдинг предвижда REST като архитектурен стил на мрежата, въпреки че той пише това се случи дълго след като мрежата беше действащо предприятие. REST е широко разглеждан като решение на нарастващата сложност на базирани на SOAP уеб услуги.

Централната част на REST е ресурсът, идентифициран с URI. REST идентифицира ресурси по техните многофункционални разширения за интернет поща (MIME) (като text / xml). Също така ресурсите имат състояния, които са уловени от техните представителства. Когато клиент поиска ресурс от RESTful уеб услуга, услугата изпраща MIME-типизирано представяне на ресурса до клиента.

Клиентите използват глаголите POST, GET, PUT и DELETE на HTTP за извличане на представления на ресурси и за манипулиране на ресурси. REST картографира тези глаголи върху операциите за създаване, четене, актуализиране и изтриване (CRUD) на базата данни, както следва:

  • POST: Създайте нов ресурс въз основа на данни за заявка.
  • ПОЛУЧАЙТЕ: Прочетете съществуващия ресурс, без да създавате странични ефекти (не променяйте ресурса)
  • PUT: Актуализирайте съществуващия ресурс с данни за заявка.
  • ИЗТРИВАНЕ: Изтриване на съществуващ ресурс.

Всеки глагол е последван от URI, който идентифицира ресурса. (Този изключително прост подход е по същество несъвместим с подхода на SOAP за изпращане на кодирани съобщения до един ресурс.) URI може да се отнася до колекция, като например //javajeff.ca/library, или до елемент от колекцията, като например //javajeff.ca/library/9781484219157- тези URI са само илюстрации.

За POST и PUT заявки, XML-базирани данни за ресурси се предават като тяло на заявката. Например можете да интерпретирате POST //javajeff.ca/library HTTP/ 1.1(където HTTP/ 1.1описва HTTP версията на заявителя) като заявка за вмъкване POSTна XML данни в //javajeff.ca/libraryресурса за събиране.

За GET и DELETE заявки данните обикновено се предават като низове на заявка, където низът на заявка е тази част от URI, започваща със ?символ. Например, където GET //javajeff.ca/libraryможе да върне списък с идентификатори за всички книги в даден libraryресурс, GET //javajeff.ca/library?isbn=9781484219157вероятно ще върне представяне на книжния ресурс, чийто низ за заявка идентифицира Международния стандартен номер на книгата (ISBN) 9781484219157.

Научете повече за HTTP-CRUD картографиране

За пълно описание на съпоставянията между HTTP глаголи и техните аналози на CRUD, разгледайте таблицата „Методи за RESTful уеб услуга HTTP“ в записа на Представителния държавен трансфер на Wikipedia.

REST също разчита на стандартните кодове за отговор на HTTP, като 404 (заявеният ресурс не е намерен) и 200 (операцията на ресурса е успешна), заедно с типовете MIME (когато се извличат представителства на ресурси).

RESTful срещу големи уеб услуги

Ако се чудите дали да разработите уеб услуга, използвайки SOAP или REST, разгледайте RESTful Web Services срещу "Big" Web Services: Вземане на правилното архитектурно решение.

Поддръжка на уеб услуги в Java SE

Преди Java SE 6, базираните на Java уеб услуги са разработени изключително с Java Enterprise Edition (EE) SDK. Въпреки че Java EE е предпочитан за разработване на уеб услуги от производствена гледна точка, тъй като базираните на Java EE сървъри осигуряват много висока степен на мащабируемост, инфраструктура за сигурност, съоръжения за наблюдение и т.н., многократното внедряване на уеб услуга в Java EE контейнерът често отнема много време, забавяйки развитието. Java SE 6 опрости и ускори разработването на уеб услуги чрез добавяне на API, анотации, инструменти и лек HTTP сървър (за разполагане на уеб услуги на прост уеб сървър и тестването им в тази среда) в своето ядро.

API

Java SE предоставя няколко API, които поддържат уеб услуги. Заедно с различни JAXP API (SAX, DOM, StAX и т.н.), които обсъждам в Java XML и JSON , Java SE предоставя JAX-WS, JAXB и SAAJ API: