Servizi Web in Java SE, Parte 1: panoramica degli strumenti

Java Standard Edition (SE) 6 includeva il supporto per i servizi Web. Questo post inizia una serie di quattro parti sui servizi Web in Java SE spiegando cosa sono i servizi Web e fornendo una panoramica del supporto di Java SE per essi. I post futuri utilizzeranno questo supporto per creare servizi Web basati su SOAP e RESTful e tratteranno anche argomenti avanzati sui servizi Web.

Java XML e JSON

In questa serie, presumo che tu comprenda XML e JSON. In caso contrario, potresti dare un'occhiata al mio libro Java XML e JSON , che è pubblicizzato alla fine di questo post.

Cosa sono i servizi web?

Wikipedia definisce il servizio Web come "un sistema software progettato per supportare l'interazione interoperabile da macchina a macchina su una rete". Una definizione più dettagliata può essere ottenuta definendo prima le parti di questo termine:

  • Web: un'enorme rete interconnessa di risorse, in cui una risorsa è un'origine dati denominata URI (Uniform Resource Identifier) ​​come un documento basato su PDF, un flusso video, una pagina Web o persino un'applicazione. È possibile accedere a queste risorse utilizzando protocolli Internet standard come HyperText Transfer Protocol (HTTP) o Simple Mail Transfer Protocol (SMTP).
  • Servizio: un'applicazione basata su server o un componente software che espone una risorsa ai client tramite uno scambio di messaggi secondo un modello di scambio di messaggi (MEP). Il MEP richiesta-risposta è tipico.

Date queste definizioni, un servizio Web è un'applicazione / componente software basato su server che espone una risorsa basata sul Web ai client tramite uno scambio di messaggi. Questi messaggi possono essere formattati secondo Extensible Markup Language (XML) o JavaScript Object Notation (JSON). Inoltre, questi messaggi possono essere considerati come invocare funzioni del servizio Web e ricevere risultati di chiamata. La figura 1 illustra questo scambio di messaggi.

Figura 1. Un client accede a una risorsa scambiando messaggi con un servizio Web

Imprese e servizi Web

Le aziende utilizzano i servizi Web perché superano i tradizionali problemi del middleware (ad esempio, costosi da ottenere e mantenere, incapaci di comunicare con il software di backend e le applicazioni client su Internet e inflessibili) essendo basati su standard liberi e aperti, sulla loro manutenibilità, coinvolgendo il Web e essendo flessibili. Inoltre, aiutano le aziende più grandi a preservare i loro investimenti spesso significativi nel software legacy.

I servizi Web possono essere classificati come semplici o complessi. I servizi Web semplici non interagiscono con altri servizi Web (ad esempio, un'applicazione standalone basata su server con una singola funzione che restituisce l'ora corrente per un fuso orario specificato). Al contrario, i servizi Web complessi spesso interagiscono con altri servizi Web. Ad esempio, un servizio Web di social network generalizzato potrebbe interagire con i servizi Web di Twitter e Facebook per ottenere e restituire al proprio client tutte le informazioni di Twitter e Facebook per un individuo specifico. I servizi Web complessi sono anche noti come mashup perché schiacciare (Combine) i dati da più servizi Web.

Architettura orientata ai servizi

I servizi Web sono un'implementazione di SOA (Service-Oriented Architecture) , uno stile di progettazione del software in cui i servizi vengono forniti a vari componenti software tramite un protocollo di comunicazione su una rete. Pensa alla SOA come a un insieme di principi di progettazione o un framework per l'implementazione della logica di business come servizi riutilizzabili che possono essere combinati in modi diversi per soddisfare i requisiti aziendali in evoluzione.

Servizi Web basati su SOAP

Un servizio Web basato su SOAP è una categoria di servizi Web ampiamente utilizzata basata su SOAP , un linguaggio XML per la definizione dei messaggi (invocazioni di funzioni astratte o relative risposte) che possono essere comprese da entrambe le estremità di una connessione di rete. Uno scambio di messaggi SOAP è chiamato operazione , che corrisponde a una chiamata di funzione e alla sua risposta, ed è illustrato nella Figura 2.

Figura 2. Un'operazione di servizio Web implica messaggi di input e output

Le operazioni correlate sono spesso raggruppate in un'interfaccia , che è concettualmente simile a un'interfaccia Java. Un legame fornisce dettagli concreti su come un'interfaccia si associa a un protocollo di messaggistica (particolarmente SOAP) per comunicare comandi, codici di errore e altri oggetti sopra il filo. L' URI di associazione e di un indirizzo di rete (un indirizzo IP e una porta) è noto come endpoint e una raccolta di endpoint è un servizio Web . La figura 3 presenta questa architettura.

Figura 3. Le interfacce delle operazioni sono accessibili tramite i loro endpoint

SOAP viene spesso utilizzato con il linguaggio di descrizione dei servizi Web (WSDL, pronunciato whiz-dull) , un linguaggio XML per definire le operazioni di un servizio Web. Un documento WSDL è un contratto formale tra un servizio Web basato su SOAP ei suoi client, che fornisce tutti i dettagli per interagire con il servizio Web. Questo documento consente di raggruppare i messaggi in operazioni e le operazioni in interfacce. Consente inoltre di definire un'associazione per ciascuna interfaccia e l'indirizzo dell'endpoint.

Oltre a supportare i documenti WSDL, i servizi Web basati su SOAP hanno le seguenti proprietà:

  • La capacità di affrontare requisiti non funzionali complessi come sicurezza e transazioni: questi requisiti sono resi disponibili tramite varie specifiche. Per promuovere l'interoperabilità tra queste specifiche, è stata costituita la Web Services Interoperability Organization (WS-I) (un consorzio di settore). WS-I ha stabilito una serie di profili, in cui un profilo è un insieme di specifiche di servizi Web denominate a livelli di revisione specifici, insieme a una serie di linee guida di implementazione e interoperabilità che raccomandano come le specifiche possono essere utilizzate per sviluppare servizi Web interoperabili. Ad esempio, il primo profilo, WS-I Basic Profile 1.0 , è costituito dal seguente insieme di specifiche del servizio Web non proprietario:
  • SOAP 1.1
  • WSDL 1.1
  • Universal Description Discovery and Integration (UDDI) 2.0
  • XML 1.0 (seconda edizione)
  • Schema XML Parte 1: Strutture
  • Schema XML Parte 2: tipi di dati
  • RFC2246: il protocollo di sicurezza del livello di trasporto versione 1.0
  • RFC2459: certificato infrastruttura a chiave pubblica Internet X.509 e profilo CRL
  • RFC2616: HyperText Transfer Protocol 1.1
  • RFC2818: HTTP su TLS
  • RFC2965: meccanismo di gestione dello stato HTTP
  • Il protocollo Secure Sockets Layer versione 3.0

Esempi di profili aggiuntivi includono WS-I Basic Security Profile e Simple SOAP Binding Profile. Per ulteriori informazioni su questi e altri profili, visitare il sito Web WS-I. Java SE supporta il profilo di base WS-I.

  • La capacità di interagire con un servizio Web in modo asincrono: i client del servizio Web dovrebbero essere in grado di interagire con un servizio Web in modo asincrono e non bloccante. Il supporto del richiamo asincrono lato client delle operazioni del servizio Web viene fornito in Java SE.

I servizi Web basati su SOAP vengono eseguiti in un ambiente che include un richiedente del servizio (il client), un fornitore di servizi e un broker di servizi. Questo ambiente è mostrato nella Figura 4.

Figura 4. Un servizio Web basato su SOAP coinvolge un richiedente del servizio, un fornitore di servizi e un broker di servizi (ad esempio, UDDI)

Il richiedente del servizio, in genere un'applicazione client (ad esempio un browser Web), o forse un altro servizio Web, prima individua il fornitore del servizio in qualche modo. Ad esempio, il richiedente del servizio potrebbe inviare un documento WSDL a un broker del servizio, che risponde con un altro documento WSDL che identifica l'ubicazione del fornitore del servizio. Il richiedente del servizio comunica quindi con il fornitore del servizio tramite messaggi SOAP.

I fornitori di servizi devono essere pubblicati in modo che altri possano individuarli e utilizzarli. Nell'agosto 2000, è stata lanciata un'iniziativa di settore aperto nota come UDDI (Universal Description, Discovery, and Integration) per consentire alle aziende di pubblicare elenchi di servizi, scoprirsi a vicenda e definire il modo in cui i servizi o le applicazioni software interagiscono su Internet. Tuttavia, questo registro indipendente dalla piattaforma e basato su XML non è stato ampiamente adottato e attualmente non viene utilizzato. Molti sviluppatori hanno trovato UDDI eccessivamente complicato e privo di funzionalità e hanno optato per alternative come la pubblicazione delle informazioni su un sito Web. Ad esempio, una volta Google ha reso disponibili i suoi servizi Web pubblici (ad esempio Google Maps) su //code.google.com/more/.

I messaggi SOAP che scorrono tra i richiedenti di servizi e i fornitori di servizi sono spesso invisibili, essendo passati come richieste e risposte tra le librerie SOAP dei loro stack di protocollo del servizio Web. Tuttavia, è possibile accedere direttamente a questi messaggi, come scoprirai più avanti in questa serie.

Grandi servizi Web

I servizi Web basati su SOAP sono anche noti come grandi servizi Web perché si basano su molte specifiche, come i profili WS-I menzionati in precedenza.

Servizi web RESTful

I servizi Web basati su SOAP possono essere forniti su protocolli come HTTP, SMTP, FTP e Blocks Extensible Exchange Protocol (BEEP). Il recapito di messaggi SOAP su HTTP può essere visto come un tipo speciale di servizio Web RESTful.

Un servizio Web REST è una categoria di servizi Web ampiamente utilizzata basata su REST (Representational State Transfer) , uno stile di architettura software per sistemi ipermediali distribuiti (sistemi in cui immagini, testo e altre risorse si trovano nelle reti e sono accessibili tramite collegamenti ipertestuali) . Il sistema ipermediale di interesse in un contesto di servizi Web è il World Wide Web.

RIPOSO storia

Roy Fielding (uno dei principali autori delle specifiche HTTP versioni 1.0 e 1.1, e cofondatore dell'Apache Software Foundation) ha introdotto e definito REST nella sua tesi di dottorato nel 2000. Fielding ha immaginato REST come lo stile architettonico del Web, sebbene abbia scritto è cresciuto molto tempo dopo che il Web era diventato un problema. REST è ampiamente considerato come la soluzione a quella che è considerata la crescente complessità dei servizi Web basati su SOAP.

La parte centrale di REST è la risorsa identificabile tramite URI. REST identifica le risorse in base ai loro tipi MIME (Multipurpose Internet Mail Extensions) (come text / xml). Inoltre, le risorse hanno stati che vengono catturati dalle loro rappresentazioni. Quando un client richiede una risorsa da un servizio Web RESTful, il servizio invia una rappresentazione di tipo MIME della risorsa al client.

I client utilizzano i verbi POST, GET, PUT e DELETE di HTTP per recuperare le rappresentazioni delle risorse e manipolare le risorse. REST associa questi verbi alle operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) del database, come segue:

  • POST: crea una nuova risorsa in base ai dati della richiesta.
  • OTTIENI: leggi la risorsa esistente senza produrre effetti collaterali (non modificare la risorsa).
  • PUT: aggiorna la risorsa esistente con i dati della richiesta.
  • DELETE: Elimina la risorsa esistente.

Ogni verbo è seguito da un URI che identifica la risorsa. (Questo approccio estremamente semplice è fondamentalmente incompatibile con l'approccio SOAP di inviare messaggi codificati a una singola risorsa.) L'URI potrebbe fare riferimento a una raccolta, ad esempio //javajeff.ca/library, oa un elemento della raccolta, ad esempio //javajeff.ca/library/9781484219157: questi URI sono solo illustrazioni.

Per le richieste POST e PUT, i dati delle risorse basati su XML vengono passati come corpo della richiesta. Ad esempio, è possibile interpretare POST //javajeff.ca/library HTTP/ 1.1(dove HTTP/ 1.1descrive la versione HTTP del richiedente) come una richiesta di inserire POSTi dati XML di nella //javajeff.ca/libraryrisorsa di raccolta.

Per le richieste GET e DELETE, i dati vengono in genere passati come stringhe di query, dove una stringa di query è quella parte di un URI che inizia con un ?carattere. Ad esempio, dove GET //javajeff.ca/librarypotrebbe restituire un elenco di identificatori per tutti i libri in una libraryrisorsa, GET //javajeff.ca/library?isbn=9781484219157probabilmente restituirebbe una rappresentazione della risorsa libro la cui stringa di query identifica il codice ISBN (International Standard Book Number) 9781484219157.

Ulteriori informazioni sulle mappature HTTP-CRUD

Per una descrizione completa delle mappature tra i verbi HTTP e le loro controparti CRUD, controlla la tabella "Metodi HTTP del servizio Web RESTful" nella voce Representational State Transfer di Wikipedia.

REST si basa anche sui codici di risposta standard di HTTP, come 404 (risorsa richiesta non trovata) e 200 (operazione risorsa riuscita), insieme ai tipi MIME (quando vengono recuperate le rappresentazioni delle risorse).

RESTful vs grandi servizi Web

Se ti stai chiedendo se sviluppare un servizio Web utilizzando SOAP o REST, dai un'occhiata ai servizi Web RESTful e ai servizi Web "grandi": prendere la giusta decisione architettonica.

Supporto del servizio Web in Java SE

Prima di Java SE 6, i servizi Web basati su Java venivano sviluppati esclusivamente con Java Enterprise Edition (EE) SDK. Sebbene Java EE sia preferito per lo sviluppo di servizi Web da una prospettiva di produzione, poiché i server basati su Java EE forniscono un grado molto elevato di scalabilità, un'infrastruttura di sicurezza, funzionalità di monitoraggio e così via, la distribuzione ripetuta di un servizio Web in Java EE container ha spesso richiesto tempo, rallentando lo sviluppo. Java SE 6 ha semplificato e accelerato lo sviluppo di servizi Web aggiungendo API, annotazioni, strumenti e un server HTTP leggero (per distribuire servizi Web su un semplice server Web e testarli in questo ambiente) nel suo nucleo.

API

Java SE fornisce diverse API che supportano i servizi Web. Insieme a varie API JAXP (SAX, DOM, StAX e così via) che discuto in Java XML e JSON , Java SE fornisce le API JAX-WS, JAXB e SAAJ: