Jeg kunngjorde nettopp det nye Lær våren kurs, med fokus på det grunnleggende i vår 5 og vårstøvel 2:
>> KONTROLLER KURSET
1. Oversikt
Ofte trenger våre webtjenester å bruke andre webtjenester for å gjøre jobben sin. Det kan være vanskelig å betjene brukerforespørsler samtidig som det holder en lav responstid. En langsom ekstern tjeneste kan øke responstiden vår og føre til at systemet vårt hoper opp forespørsler ved å bruke flere ressurser. Det er her en ikke-blokkerende tilnærming kan være veldig nyttig
I denne opplæringen vil vi skyte ut flere asynkrone forespørsler til en tjeneste fra et Play Framework-program. Ved å utnytte Javas ikke-blokkerende HTTP-evne, vil vi kunne stille spørsmål om eksterne ressurser uten å påvirke vår egen hovedlogikk.
I vårt eksempel vil vi utforske Play WebService Library.
2. Play WebService (WS) -biblioteket
WS er et kraftig bibliotek som gir asynkrone HTTP-anrop ved bruk av Java Handling.
Ved hjelp av dette biblioteket sender koden vår disse forespørslene og fortsetter uten å blokkere. For å behandle resultatet av forespørselen, tilbyr vi en forbruksfunksjon, det vil si en implementering av Forbruker grensesnitt.
Dette mønsteret deler noen likheter med JavaScript-implementeringen av tilbakeringinger, Løfter, og asynkronisere / vente mønster.
La oss bygge en enkel Forbruker som logger noen av svardataene:
Våre Forbruker logger bare på dette eksemplet. Forbrukeren kan gjøre alt vi trenger å gjøre med resultatet, som å lagre resultatet i en database.
Hvis vi ser dypere på bibliotekets implementering, kan vi observere at WS bryter inn og konfigurerer Java AsyncHttpClient, som er en del av standard JDK og ikke er avhengig av Play.
3. Forbered et eksempel på prosjekt
For å eksperimentere med rammeverket, la oss lage noen enhetstester for å starte forespørsler. Vi oppretter et skjelettapplikasjon for å svare på dem og bruke WS-rammeverket til å komme med HTTP-forespørsler.
3.1. Skjelettnettapplikasjonen
Først og fremst lager vi det opprinnelige prosjektet ved å bruke sbt ny kommando:
sbt ny playframework / play-java-seed.g8
I den nye mappen, vi da redigere build.sbt fil og legg til WS-bibliotekets avhengighet:
bibliotekavhengigheter + = javaWs
Nå kan vi starte serveren med sbt kjøre kommando:
$ sbt run ... --- (Kjører applikasjonen, automatisk omlasting er aktivert) --- [info] pcsAkkaHttpServer - Lytter etter HTTP på / 0: 0: 0: 0: 0: 0: 0: 0: 9000
Når applikasjonen har startet, kan vi sjekke at alt er ok ved å bla // lokal vert: 9000, som åpner Play velkomstside.
3.2. Testmiljøet
For å teste søknaden vår, bruker vi enhetstestklassen HomeControllerTest.
Først må vi utvide WithServer som vil gi serverens livssyklus:
Takk til foreldrene, denne klassen starter nå skjelettwebserveren vår i testmodus og i en tilfeldig port, før du kjører testene. De WithServer klasse stopper også søknaden når testen er ferdig.
Deretter må vi gi et program for å kjøre.
Vi kan lage det med Guice‘S GuiceApplicationBuilder:
Som vi kan se, er det ganske enkelt å legge til overskrifter og spørringsparametere.
Etter at vi har konfigurert forespørselen vår fullt ut, kan vi ringe metoden for å starte den.
4.2. Generisk GET-forespørsel
For å utløse en GET-forespørsel må vi bare ringe få metode på vår WSRequest gjenstand:
ws.url (url) ... .get ();
Siden dette er en ikke-blokkerende kode, starter den forespørselen og fortsetter deretter kjøringen på neste linje i vår funksjon.
Objektet returnerte av få er en CompletionStage forekomst, som er en del av Fullførbar fremtid API.
Når HTTP-samtalen er fullført, utfører dette trinnet bare noen få instruksjoner. Den bryter responsen inn i en WSResponse gjenstand.
Normalt vil dette resultatet videreføres til neste trinn i kjøringskjeden. I dette eksemplet har vi ikke gitt noen forbrukende funksjon, så resultatet går tapt.
Av denne grunn er denne forespørselen av typen "fyr og glem".
4.3. Send inn et skjema
Å sende inn et skjema er ikke veldig forskjellig fra få eksempel.
For å utløse forespørselen ringer vi bare post metode:
I dette scenariet må vi sende en kropp som en parameter. Dette kan være en enkel streng som en fil, et json- eller xml-dokument, en BodyWritable eller a Kilde.
4.4. Send inn en flerdelt / skjemadata
Et flerdelt skjema krever at vi sender både inndatafelt og data fra en vedlagt fil eller strøm.
For å implementere dette i rammeverket bruker vi post metode med en Kilde.
Inne i kilden kan vi pakke inn alle de forskjellige datatypene som skjemaet vårt trenger:
Dette kan for eksempel være nyttig for å gi en sterk datakonsistens som vi ikke kan oppnå på andre måter.
5.2. Behandle svar asynkront
For å behandle et asynkront svar uten å blokkere, vi gir en Forbruker eller Funksjon som drives av det asynkrone rammeverket når svaret er tilgjengelig.
La oss for eksempel legge til en Forbruker til vårt forrige eksempel for å logge svaret:
Det er verdt å merke seg at vi brukte deretterAksepter, som krever en Forbruker funksjon siden vi ikke trenger å returnere noe etter loggingen.
Når vi vil at den nåværende fasen skal returnere noe, slik at vi kan bruke det i neste trinn, trenger vi deretterSøk i stedet, som tar en Funksjon.
Disse bruker konvensjonene til standard Java Functional Interfaces.
5.3. Stor respons kropp
Koden vi har implementert så langt, er en god løsning for små svar og de fleste brukssaker. Men hvis vi trenger å behandle noen hundre megabyte med data, trenger vi en bedre strategi.
Vi bør merke oss: Be om metoder som få og post last hele responsen i minnet.
For å unngå en mulig OutOfMemoryError, kan vi bruke Akka Streams til å behandle svaret uten å la det fylle minnet vårt.
De strøm metoden returnerer a CompletionStage hvor i WSResponse har en getBodyAsStream metode som gir en Kilde.
Vi kan fortelle koden hvordan vi behandler denne typen kropp ved å bruke Akkas Synke, som i vårt eksempel ganske enkelt vil skrive data som går gjennom i OutputStream.
5.4. Tidsavbrudd
Når vi bygger en forespørsel, kan vi også angi en bestemt tidsavbrudd, slik at forespørselen blir avbrutt hvis vi ikke mottar det komplette svaret i tide.
Dette er en spesielt nyttig funksjon når vi ser at en tjeneste vi spør etter, er spesielt treg og kan føre til en samling av åpne forbindelser som sitter og venter på svaret.
Vi kan angi en global tidsavbrudd for alle forespørslene våre ved hjelp av innstillingsparametere. For en forespørselsspesifikk tidsavbrudd kan vi legge til en forespørsel ved hjelp av setRequestTimeout:
Det er fremdeles ett tilfelle å håndtere, skjønt: Vi har kanskje mottatt alle dataene, men vår Forbruker kan være veldig treg å behandle den. Dette kan skje hvis det er mye dataknusing, databasesamtaler, etc.
I systemer med lav gjennomstrømning kan vi bare la koden kjøre til den er fullført. Vi kan imidlertid ønske å avbryte langvarige aktiviteter.
For å oppnå det, må vi pakke koden med noen futures håndtering.
La oss simulere en veldig lang prosess i koden vår:
Nå vil fremtiden vår returnere et resultat på begge måter: beregningsresultatet hvis Forbruker ferdig i tide, eller unntaket på grunn av futures pause.
5.5. Håndtering av unntak
I forrige eksempel opprettet vi en funksjon som enten returnerer et resultat eller mislykkes med unntak. Så nå må vi håndtere begge scenariene.
Vi kan håndtere både suksess- og fiaskoscenarier med handleAsync metode.
La oss si at vi vil returnere resultatet, hvis vi har fått det, eller logge feilen og returnere unntaket for videre håndtering:
Vi kan stille inn ønsket loggnivå ved å endre vårt logback.xml konfigurasjon.
7. Caching-svar
WSClient støtter også caching av svar.
Denne funksjonen er spesielt nyttig når den samme forespørselen utløses flere ganger, og vi ikke trenger de ferskeste dataene hver gang.
Det hjelper også når tjenesten vi ringer midlertidig er nede.
7.1. Legg til Caching-avhengigheter
For å konfigurere caching må vi først legge til avhengigheten i vår build.sbt:
biblioteksavhengighet + = ehcache
Dette konfigurerer Ehcache som vårt cachelag.
Hvis vi ikke vil ha Ehcache spesifikt, kan vi bruke hvilken som helst annen JSR-107 cache-implementering.
7.2. Force Caching Heuristic
Som standard vil ikke Play WS cache HTTP-svar hvis serveren ikke returnerer noen bufringskonfigurasjon.
For å omgå dette, kan vi tvinge heuristisk caching ved å legge til en innstilling til vår application.conf:
play.ws.cache.heuristics.enabled = true
Dette vil konfigurere systemet til å bestemme når det er nyttig å cache et HTTP-svar, uavhengig av fjerntjenestens annonserte hurtigbufring.
8. Ekstra innstilling
Forespørsel til en ekstern tjeneste kan kreve noen klientkonfigurasjon. Vi kan trenge å håndtere viderekoblinger, en treg server eller noe filtrering avhengig av brukeragentens overskrift.
For å løse det kan vi stille inn WS-klienten vår ved å bruke egenskaper i vår application.conf:
play.ws.followRedirects = falsk play.ws.useragent = MyPlayApplication play.ws.compressionEnabled = true # tid å vente på at tilkoblingen blir opprettet play.ws.timeout.connection = 30 # tid å vente på data etter at tilkoblingen er åpen play.ws.timeout.idle = 30 # maks tid tilgjengelig for å fullføre forespørselen play.ws.timeout.request = 300
Det er også mulig å konfigurere det underliggende AsyncHttpClient direkte.
Den komplette listen over tilgjengelige eiendommer kan sjekkes i kildekoden til AhcConfig.
9. Konklusjon
I denne artikkelen utforsket vi Play WS-biblioteket og dets hovedtrekk. Vi konfigurerte prosjektet vårt, lærte hvordan vi kan utløse vanlige forespørsler og behandle svaret deres, både synkront og asynkront.
Vi jobbet med store data nedlastinger og så hvordan vi kunne kutte korte langvarige aktiviteter.
Til slutt så vi på caching for å forbedre ytelsen, og hvordan du kan stille inn klienten.
Som alltid er kildekoden for denne opplæringen tilgjengelig på GitHub.
Java bunn
Jeg kunngjorde nettopp det nye Lær våren kurs, med fokus på det grunnleggende i vår 5 og vårstøvel 2:
