Programování

Webové služby v prostředí Java SE, část 1: Přehled nástrojů

Java Standard Edition (SE) 6 zahrnovala podporu webových služeb. Tento příspěvek začíná čtyřdílnou sérií webových služeb v prostředí Java SE vysvětlením, jaké jsou webové služby, a přehledem jejich podpory v prostředí Java SE. Budoucí příspěvky budou tuto podporu využívat k vytváření webových služeb založených na SOAP a RESTful a budou také pokrývat pokročilá témata webových služeb.

Java XML a JSON

V této sérii předpokládám, že rozumíte XML a JSON. Pokud ne, možná se budete chtít podívat na můj Java XML a JSON kniha, která je inzerována na konci tohoto příspěvku.

Co jsou webové služby?

Wikipedia definuje webová služba jako „softwarový systém navržený pro podporu interoperabilní interakce mezi stroji v síti.“ Podrobnější definici lze získat nejprve definováním částí tohoto výrazu:

  • Web: Obrovská propojená síť zdrojů, kde a zdroj je zdroj dat s názvem Uniform Resource Identifier (URI), jako je dokument založený na PDF, stream videa, webová stránka nebo dokonce aplikace. K těmto zdrojům lze přistupovat pomocí standardních internetových protokolů, jako je HyperText Transfer Protocol (HTTP) nebo Simple Mail Transfer Protocol (SMTP).
  • Servis: Serverová aplikace nebo softwarová součást, která vystavuje prostředek klientům prostřednictvím výměny zpráv podle vzoru výměny zpráv (MEP). Typický je MEP požadavek-odpověď.

Vzhledem k těmto definicím, a webová služba je serverová aplikační / softwarová součást, která prostřednictvím výměny zpráv vystavuje klientům webový prostředek. Tyto zprávy mohou být formátovány podle XML (Extensible Markup Language) nebo JavaScriptu Object Notation (JSON). Tyto zprávy lze také považovat za vyvolání funkcí webových služeb a přijímání výsledků vyvolání. Obrázek 1 ilustruje tuto výměnu zpráv.

Obrázek 1. Klient přistupuje ke zdroji výměnou zpráv s webovou službou

Podniky a webové služby

Firmy využívají webové služby, protože překonávají tradiční problémy s middlewarem (např. Nákladné na získání a údržbu, neschopnost komunikovat s back-endovým softwarem a klientskými aplikacemi přes internet a nepružné) tím, že jsou založeny na svobodných a otevřených standardech, jejich udržovatelnosti, zapojením na webu a tím, že je flexibilní. Kromě toho pomáhají větším podnikům zachovat jejich často významné investice do staršího softwaru.

Webové služby lze klasifikovat jako jednoduché nebo složité. Jednoduché webové služby neinteragují s jinými webovými službami (např. Samostatná serverová aplikace s jedinou funkcí, která vrací aktuální čas pro zadané časové pásmo). Naproti tomu složité webové služby často interagují s jinými webovými službami. Například obecná webová služba sociální sítě může interagovat s webovými službami Twitter a Facebook, aby získala a vrátila svému klientovi všechny informace o Twitteru a Facebooku pro konkrétní osobu. Komplexní webové služby jsou také známé jako mashupy protože oni kaše (kombinovat) data z více webových služeb.

Architektura orientovaná na služby

Webové služby jsou implementací Servisně orientovaná architektura (SOA), což je styl softwarového designu, kdy jsou služby poskytovány různým softwarovým komponentám prostřednictvím komunikačního protokolu po síti. Představte si SOA jako sadu principů návrhu nebo rámec pro implementaci obchodní logiky jako opakovaně použitelné služby, které lze kombinovat různými způsoby, aby vyhovovaly vyvíjejícím se obchodním požadavkům.

Webové služby založené na protokolu SOAP

A Webová služba založená na protokolu SOAP je široce používaná kategorie webových služeb, na které je založen MÝDLO, jazyk XML pro definování zprávy (abstraktní vyvolání funkcí nebo jejich odpovědi), kterým lze porozumět na obou koncích síťového připojení. Výměna zpráv SOAP se nazývá úkon, což odpovídá volání funkce a její odezvě a které je znázorněno na obrázku 2.

Obrázek 2. Provoz webové služby zahrnuje vstupní a výstupní zprávy

Související operace jsou často seskupeny do rozhraní, který je koncepčně podobný rozhraní Java. A vazba poskytuje konkrétní podrobnosti o tom, jak je rozhraní vázáno na protokol zasílání zpráv (zejména SOAP) za účelem komunikace příkazů, chybových kódů a dalších položek po drátě. Vazba a síťová adresa (IP adresa a port) URI je známý jako koncový boda kolekce koncových bodů je a webová služba. Obrázek 3 představuje tuto architekturu.

Obrázek 3. Rozhraní operací jsou přístupná prostřednictvím jejich koncových bodů

SOAP se často používá s Jazyk popisu webových služeb (WSDL, vyslovováno whiz-matný), jazyk XML pro definování operací webové služby. A Dokument WSDL je formální smlouva mezi webovou službou založenou na protokolu SOAP a jejími klienty, která poskytuje veškeré podrobnosti pro interakci s webovou službou. Tento dokument umožňuje seskupovat zprávy do operací a operace do rozhraní. Umožňuje také definovat vazbu pro každé rozhraní i adresu koncového bodu.

Kromě podpory dokumentů WSDL mají webové služby založené na protokolu SOAP následující vlastnosti:

  • Schopnost řešit složité nefunkční požadavky, jako jsou zabezpečení a transakce: Tyto požadavky jsou k dispozici prostřednictvím různých specifikací. Aby se podpořila interoperabilita mezi těmito specifikacemi, Organizace interoperability webových služeb (WS-I) (průmyslové konsorcium). WS-I zavedla sadu profilů, kde a profil je sada pojmenovaných specifikací webových služeb na konkrétních úrovních revizí spolu se sadou pokynů pro implementaci a interoperabilitu doporučujících, jak lze tyto specifikace použít k vývoji interoperabilních webových služeb. Například úplně první profil, Základní profil WS-I 1.0, se skládá z následující sady nechráněných specifikací webových služeb:
  • SOAP 1.1
  • WSDL 1.1
  • Universal Description Discovery and Integration (UDDI) 2.0
  • XML 1.0 (druhé vydání)
  • Schéma XML, část 1: Struktury
  • Schéma XML, část 2: Datové typy
  • RFC2246: Transport Layer Security Protocol verze 1.0
  • RFC2459: Certifikát infrastruktury veřejného klíče Internet X.509 a profil CRL
  • RFC2616: HyperText Transfer Protocol 1.1
  • RFC2818: HTTP přes TLS
  • RFC2965: Mechanismus správy stavu HTTP
  • Secure Sockets Layer Protocol verze 3.0

Mezi další příklady profilů patří WS-I Basic Security Profile a Simple SOAP Binding Profile. Další informace o těchto a dalších profilech najdete na webu WS-I. Java SE podporuje základní profil WS-I.

  • Schopnost asynchronně komunikovat s webovou službou: Klienti webových služeb by měli být schopni komunikovat s webovou službou neblokujícím asynchronním způsobem. Podpora asynchronního vyvolání operací webových služeb na straně klienta je poskytována v prostředí Java SE.

Webové služby založené na protokolu SOAP se spouštějí v prostředí, které zahrnuje žadatele o službu (klienta), poskytovatele služeb a zprostředkovatele služeb. Toto prostředí je znázorněno na obrázku 4.

Obrázek 4. Webová služba založená na protokolu SOAP zahrnuje žadatele o služby, poskytovatele služeb a zprostředkovatele služeb (např. UDDI)

Žadatel o službu, obvykle klientská aplikace (např. Webový prohlížeč), nebo možná jiná webová služba, nejprve nějakým způsobem vyhledá poskytovatele služby. Například žadatel o službu může odeslat dokument WSDL zprostředkovateli služeb, který odpoví jiným dokumentem WSDL identifikujícím umístění poskytovatele služby. Žadatel o službu poté komunikuje s poskytovatelem služeb prostřednictvím zpráv SOAP.

Poskytovatelé služeb musí být zveřejněni, aby je mohli ostatní najít a používat. V srpnu 2000 byla otevřena průmyslová iniciativa známá jako Univerzální popis, zjišťování a integrace (UDDI) byla zahájena, aby podniky mohly zveřejňovat výpisy služeb, vzájemně se objevovat a definovat, jak služby nebo softwarové aplikace interagují přes internet. Tento platformově nezávislý registr založený na XML však nebyl široce přijat a aktuálně se nepoužívá. Mnoho vývojářů zjistilo, že UDDI je příliš komplikované a postrádající funkčnost, a rozhodli se pro alternativy, jako je publikování informací na webu. Například Google jednou zpřístupnil své veřejné webové služby (např. Mapy Google) na adrese //code.google.com/more/.

Zprávy SOAP, které proudí mezi žadateli o službu a poskytovateli služeb, jsou často neviditelné a jsou předávány jako požadavky a odpovědi mezi knihovnami SOAP jejich zásobníků protokolu webových služeb. Je však možné k těmto zprávám přistupovat přímo, jak zjistíte dále v této sérii.

Velké webové služby

Webové služby založené na protokolu SOAP jsou také známé jako velké webové služby protože jsou založeny na mnoha specifikacích, jako jsou dříve zmíněné profily WS-I.

RESTful webové služby

Webové služby založené na protokolu SOAP lze doručovat prostřednictvím protokolů, jako jsou HTTP, SMTP, FTP a Blocks Extensible Exchange Protocol (BEEP). Doručování zpráv SOAP přes HTTP lze zobrazit jako speciální druh webové služby RESTful.

A RESTful webová služba je široce používaná kategorie webových služeb, na které je založen Převod reprezentačního státu (REST), styl softwarové architektury pro distribuci hypermediální systémy (systémy, ve kterých jsou obrázky, text a další zdroje umístěny kolem sítí a jsou přístupné pomocí hypertextových odkazů). Hypermediální systém zájmu v kontextu webových služeb je World Wide Web.

Historie REST

Roy Fielding (hlavní autor specifikací HTTP verze 1.0 a 1.1 a spoluzakladatel Apache Software Foundation) představil a definoval REST ve své disertační práci již v roce 2000. Fielding si představil REST jako architektonický styl webu, i když napsal vzrostlo to dlouho poté, co byl Web nepřetržitým provozem. REST je široce považován za řešení toho, co je považováno za rostoucí složitost webových služeb založených na protokolu SOAP.

Centrální část REST je prostředek identifikovatelný podle URI. REST identifikuje zdroje podle jejich typů MIME (Multipurpose Internet Mail Extensions) (například text / xml). Zdroje mají také stavy, které jsou zachyceny jejich reprezentacemi. Když klient požaduje prostředek z webové služby RESTful, služba klientovi odešle reprezentaci prostředku typu MIME.

Klienti používají k načtení reprezentací prostředků ak manipulaci se prostředky slovesa POST, GET, PUT a DELETE protokolu HTTP. REST mapuje tato slovesa na operace vytvoření, čtení, aktualizace a mazání databáze (CRUD), a to následovně:

  • POST: Vytvořte nový zdroj na základě dat požadavku.
  • ZÍSKAT: Přečtěte si existující zdroj bez vytváření vedlejších účinků (zdroj neupravujte).
  • PUT: Aktualizujte existující prostředek o data požadavku.
  • ODSTRANIT: Odstranit existující prostředek.

Za každým slovesem následuje URI, který identifikuje prostředek. (Tento nesmírně jednoduchý přístup je v zásadě nekompatibilní s přístupem SOAP k odesílání kódovaných zpráv do jednoho zdroje.) URI může odkazovat na kolekci, jako například //javajeff.ca/library, nebo k prvku kolekce, jako je //javajeff.ca/library/9781484219157 - tyto URI jsou pouze ilustrační.

U požadavků POST a PUT se data těla založená na XML předávají jako tělo požadavku. Můžete například tlumočit POST //javajeff.ca/library HTTP / 1.1 (kde HTTP / 1.1 popisuje verzi HTTP žadatele) jako požadavek na vložení POŠTAXML data do //javajeff.ca/library zdroj sběru.

U požadavků GET a DELETE se data obvykle předávají jako řetězce dotazů, kde a Řetězec dotazu je ta část URI začínající a ? charakter. Například kde ZÍSKAT //javajeff.ca/library může vrátit seznam identifikátorů pro všechny knihy v a knihovna zdroj, ZÍSKAT //javajeff.ca/library?isbn=9781484219157 pravděpodobně vrátí reprezentaci zdroje knihy, jehož řetězec dotazu identifikuje mezinárodní standardní číslo knihy (ISBN) 9781484219157.

Další informace o mapování HTTP-CRUD

Úplný popis mapování mezi slovesy HTTP a jejich protějšky CRUD najdete v tabulce „Metody HTTP RESTful Web Service HTTP“ v záznamu Reprezentativní stav Wikipedie.

REST také spoléhá na standardní kódy odpovědí HTTP, například 404 (požadovaný prostředek nebyl nalezen) a 200 (operace zdroje úspěšná), spolu s typy MIME (při načítání reprezentací prostředků).

RESTful vs velké webové služby

Pokud vás zajímá, zda vyvinout webovou službu pomocí SOAP nebo REST, podívejte se na webové služby RESTful vs. „velké“ webové služby: Správné architektonické rozhodnutí.

Podpora webových služeb v prostředí Java SE

Před verzí Java SE 6 byly webové služby založené na prostředí Java vyvíjeny výhradně pomocí sady Java Enterprise Edition (EE) SDK. Ačkoli je Java EE upřednostňována pro vývoj webových služeb z produkčního hlediska, protože servery založené na Java EE poskytují velmi vysoký stupeň škálovatelnosti, bezpečnostní infrastrukturu, monitorovací zařízení atd., Opakované nasazení webové služby do Java EE kontejner byl často časově náročný a zpomalil vývoj. Java SE 6 zjednodušil a zrychlil vývoj webových služeb přidáním API, anotací, nástrojů a odlehčeného serveru HTTP (pro nasazení webových služeb na jednoduchý webový server a jejich testování v tomto prostředí) do svého jádra.

API

Java SE poskytuje několik rozhraní API, která podporují webové služby. Spolu s různými API JAXP (SAX, DOM, StAX atd.), O kterých diskutuji Java XML a JSON, Java SE poskytuje API JAX-WS, JAXB a SAAJ:

$config[zx-auto] not found$config[zx-overlay] not found