Etter at klienten har koblet seg til tjenesten på en bestemt port, får han tilgang til tjenesten ved hjelp av den etablerte protokollen. En protokoll er en forhåndsutviklet prosedyre for utveksling av informasjon mellom parten som ønsker å bruke tjenesten og parten som yter tjenesten. «Parten» som trenger tjenesten kan være en person, men som oftest er det det dataprogram, For eksempel, Nettleser. Protokoller er ofte tekstlige beskrivelser av prosedyren for å utveksle informasjon mellom en klient og en server.

UNIX

Den enkleste protokollen er kanskje for dagtjenesten. Hvis du kobler til port 13 på en maskin som støtter en dagtidsserver, vil den serveren svare med informasjon om dagens dato og tid og kobler deretter fra tilkoblingen. Protokollen er som følger: "Hvis en klient etablerer en forbindelse med en dagtidsserver, sendes dato- og klokkeslettdata til den, hvoretter forbindelsen kobles fra." De fleste UNIX-maskiner støtter denne serveren. Du kan kontakte ham ved å bruke Telnet-applikasjonen. På UNIX vil økten se slik ut:

• %telnet web67.ntx.net 13
• Tilkobling til web67.ntx.net.
• Avbryttegnet "^]".
• Søndag 25. oktober 08:34:06 1998

Windows

På en Windows-maskin kan du få tilgang til denne serveren ved å skrive inn "telnet web67.ntx.net 13" i MSDOS-vinduet.

I dette eksemplet er web67.ntx.net UNIX-servermaskinen, og 13 er portnummeret for dagtidstjenesten. Telnet-applikasjonen kobles til port 13 (telnet kobles vanligvis til port 23, men du kan spesifisere hvilken som helst annen port som skal kobles til), så sender serveren dato- og klokkeslettdata, og lukker deretter tilkoblingen. De fleste versjoner av Telnet har muligheten til å spesifisere et portnummer, og denne funksjonen kan brukes uavhengig av hvilken versjon av Telnet som er installert på maskinen.

De fleste protokoller er mer komplekse enn dagtidsprotokollen og er definert i offentlig tilgjengelige forespørsler om kommentarer (RFC-er) (for et godt arkiv over alle RFC-er, se sunsite.auc.dk/RFC/). Hver Internett server på Internett er i samsvar med HTTP-protokollkravene kompilert i The Original HTTP-dokument i 1991. Den viktigste formen for protokoll som forstås av en HTTP-server involverer bare én kommando: GET. Hvis du oppretter en forbindelse med en server som kjører HTTP og sender en "GET filnavn"-forespørsel, vil serveren svare ved å sende innholdet til forespørselskilden spesifisert fil, og kobler deretter fra tilkoblingen. En typisk økt ser slik ut:

• %telnet nettsted 80
• Forsøker å koble til 78.110.59.235...
• Tilkobling med pcwork.ru.
• Avbryttegnet "^]".
• Tilkoblingen er deaktivert av den eksterne vertsdatamaskinen.

I den første versjonen av HTTP-protokollen var det bare det faktiske filnavnet som måtte sendes, for eksempel [/] eller Protokollen ble senere endret for å kunne håndtere fullstendige URL-er. Dette tillot selskaper som driver med virtuelle domener, under forhold der mange domener er plassert på én maskin, å bruke én IP-adresse for alle slike domener.

Oppsummer

Etter å ha lest denne artikkelen har du lært mye om. Nærmere bestemt vet du nå at når du skriver inn en URL i en nettleser, skjer følgende:

1. delte nettadressen inn i tre deler:

• Protokoll ("http")
• Servernavn ("nettsted") - in I det siste positiv tendens til å forkorte de tre første bokstavene www
• Filnavn ("webserver.htm")

Nettleseren kontakter navneserveren for å oversette servernavnet til en IP-adresse, som brukes av den nettleseren for å koble til den tilsvarende servermaskinen.

Etter å ha mottatt IP-adressen, oppretter den angitte nettleseren en forbindelse til WEB-serveren som har denne IP-adressen på port 80.

I samsvar med HTTP-protokollen sender nettleseren en GET-forespørsel til denne serveren for å motta filen (Merk at sammen med GET-forespørselen kan informasjonskapsler sendes fra nettleseren til serveren - detaljer finner du i artikkelen om hvordan informasjonskapsler arbeid).

Serveren sender HTML-tekst den forespurte WEB-siden til nettleseren. (Cookies kan også sendes fra serveren til nettleseren i sideoverskriften.)

Nettleseren leser HTML-taggene og viser den tilsvarende siden på skjermen.

Tillegg: Sikkerhet

Fra denne beskrivelsen kan vi konkludere med at en WEB-server kan være et ganske enkelt program. Den tar filnavnet sendt med GET-kommandoen, finner filen den leter etter og sender den til nettleseren. Selv med all portadministrasjon og portkommunikasjonskode, kan du enkelt lage et C-program som fungerer som en enkel WEB-server på mindre enn 500 linjer programkode. Selvfølgelig er en fullverdig bedrifts WEB-server mer kompleks, men de grunnleggende prinsippene for driften er fortsatt veldig enkle.

De fleste servere legger til et visst sikkerhetsnivå i arbeidsflyten. Til dette formålet brukes for eksempel passordbeskyttede sider. Når du prøver å åpne en slik side med nettleseren din, vises en dialogboks som ber deg skrive inn brukernavn og passord. Serveren gir eieren av WEB-siden muligheten til å bruke en liste over navn og passord til personer som har tilgang til denne siden; i dette tilfellet tillater serveren visning av siden kun for de som har riktig passord. Avanserte servere har tilleggsfunksjoner sikkerhet som krypterer informasjon som utveksles mellom serveren og nettleseren, og gjør det mulig å overføre sensitiv informasjon som kredittkortnumre over Internett.

Dette er praktisk talt alle funksjonene som en server designet for å sende standard statiske WEB-sider kan utføre. Statiske sider er de WEB-sidene som ikke endres før de er redigert av utvikleren.

Tillegg: Dynamiske sider

Hva med dynamisk WEB sider? For eksempel:

• I enhver bok med anmeldelser er det tillatt å legge igjen meldinger i HTML-form, og neste gang du ser den, lagres den nye informasjonen som er lagt inn på denne siden.
• I skjermbildet Network Solutions whois, som svar på å skrive inn et domenenavn, mottas en WEB-side, hvis utseende avhenger av det angitte navnet.
• I hvilken som helst søkemotor i HTML-skjema er introdusert søkeord, hvoretter maskinen oppretter en side som viser søkeresultatet for disse ordene.

I alle de ovennevnte tilfellene søker ikke WEB-serveren bare nødvendig fil. Den behandler den mottatte informasjonen og lager en WEB-side som på en bestemt måte tilsvarer den mottatte forespørselen. I nesten alle tilfeller bruker WEB-serveren den såkalte CGI-prosedyren for å løse dette problemet.

Hver servermaskin eksponerer tjenester fra Internett ved hjelp av nummererte porter, en for hver tjeneste tilgjengelig på serveren. For eksempel, hvis servermaskinen har en WEB-server og en FTP-server, gjøres vanligvis tilgang til WEB-serveren via port 80, og til FTP-server- via port 21. Klienter kobler til tjenesten ved å velge riktig adresse og koble til riktig port.

Hver populær tjeneste er tildelt et spesifikt portnummer. Følgende er de mest brukte portnumrene:

• ekko 7
• dagtid 13
• qotd 17 (dagens sitat)
• ftp 21
• telnet 23
• smtp 25 (e-post)
• tid 37
• navneserver 53 (navneserver)
• kallenavn 43 (Hvem er hvem)
• gopher 70
• finger 79
• WWW 80

Begrensninger

Hvis servermaskinen tillater tilkobling til en port fra Internett og denne porten ikke er beskyttet, kan du koble til den fra hvor som helst på Internett og bruke den tilsvarende tjenesten. Det skal bemerkes at det ikke er noen begrensninger som krever at for eksempel WEB-serveren kobles til port 80. Ved å sette i drift din egen maskin og installere WEB-serverprogramvaren på den, kan du om ønskelig spesifisere at WEB-serveren skal fungere , for eksempel på port 918 , eller på en annen ledig port. Deretter, hvis maskinen heter xxx.yyy.com, kan du koble til denne serveren over Internett ved å bruke URL-en xxx.yyy.com:918. ":918"-delen angir eksplisitt portnummeret og må legges til av alle som ønsker å kontakte denne serveren. Hvis ingen port er spesifisert, prøver nettleseren som standard å koble til den vanlige porten 80.

HTTP. Det er basert på interaksjon" klient server", det vil si at det antas at:

1. Forbruker- klient etter å ha startet en forbindelse med leverandør-serveren, sender den en forespørsel;
2. Forsørger- server, etter å ha mottatt forespørselen, utfører de nødvendige handlingene og returnerer et svar med resultatet tilbake til klienten.

   I dette tilfellet er det to mulige måter å organisere arbeidet til klientdatamaskinen på:

   • Tynn klient er en klientdatamaskin som overfører alle informasjonsbehandlingsoppgaver til serveren. Eksempel tynn klient kan fungere som en datamaskin med en nettleser som brukes til å jobbe med nettapplikasjoner.
   • Fet klient tvert imot, behandler informasjon uavhengig av serveren, og bruker sistnevnte hovedsakelig kun for datalagring.

Før vi går videre til spesifikke klient-server-webteknologier, la oss se på de grunnleggende prinsippene og strukturen til den grunnleggende HTTP-protokollen.

HTTP-protokoll

HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) er en applikasjonslagsprotokoll for overføring av hypertekst.

Den sentrale enheten i HTTP er ressurs URL-en som ble pekt på i klientforespørselen. Vanligvis er disse ressursene filer som er lagret på serveren. En funksjon ved HTTP-protokollen er muligheten til å spesifisere i forespørselen og svaret metoden for å representere den samme ressursen i henhold til ulike parametere: format, koding, språk, etc. Det er takket være muligheten til å spesifisere metoden for å kode en melding at klienten og serveren kan utveksle binære data, men i utgangspunktet er denne protokollen designet for å overføre symbolsk informasjon. Ved første øyekast kan dette virke som sløsing med ressurser. Faktisk tar data i symbolsk form mer minne, meldinger skaper ekstra belastning på kommunikasjonskanaler, men dette formatet har mange fordeler. Meldinger som sendes over nettverket er lesbare, og etter å ha analysert de mottatte dataene, Systemadministrator kan enkelt finne feilen og fikse den. Om nødvendig kan en person spille rollen som en av de interagerende applikasjonene ved manuelt å legge inn meldinger i det nødvendige formatet.

I motsetning til mange andre protokoller, er HTTP en minneløs protokoll. Dette betyr at protokollen ikke lagrer informasjon om tidligere klientforespørsler og serversvar. Komponenter som bruker HTTP kan uavhengig opprettholde tilstandsinformasjon knyttet til nylige forespørsler og svar. For eksempel klient Webapplikasjon, sender forespørsler, kan overvåke svarforsinkelser, og Internett server kan lagre IP-adresser og be om overskrifter for nylige klienter.

Alle programvare for arbeid med HTTP-protokollen er delt inn i tre hovedkategorier:

• Servere- tilbydere av informasjonslagring og -behandlingstjenester (forespørselsbehandling).
• Kunder- sluttforbrukere av servertjenester (sende forespørsler).
• Proxy-servereå støtte arbeidet med transporttjenestene.

Hovedkundene er nettlesere eks: Internett Utforsker, Opera, Mozilla Firefox, Netscape Navigator og andre. De mest populære webserverimplementeringene er: Internett Informasjon Tjenester (IIS), Apache, lighttpd, nginx. De mest kjente proxy-serverimplementeringene: Squid, UserGate, Multiproxy, Naviscope.

Det "klassiske" HTTP-øktskjemaet ser slik ut.

1. Etablere en TCP-tilkobling.
2. Kundeforespørsel.
3. Serverrespons.
4. Avslutter TCP-tilkoblingen.

Dermed sender klienten en forespørsel til serveren, mottar et svar fra den, hvoretter interaksjonen stopper. Vanligvis er klientforespørselen en forespørsel om å overføre et HTML-dokument eller en annen ressurs, og serversvaret inneholder koden for denne ressursen.

HTTP-forespørselen sendt av klienten til serveren inkluderer følgende komponenter.

• Statuslinje (noen ganger brukes begrepene statuslinje eller spørringslinje også for å referere til den).
• Overskriftsfelt.
• Tom linje.
• Forespørselsinstans.

Statuslinjen sammen med overskriftsfelt noen ganger også kalt forespørselsoverskrift.

Ris. 2.1.

Statuslinjen har følgende format:

request_method URL_pecypca protocol_version HTTP

La oss se på komponentene i statuslinjen, med spesiell oppmerksomhet til forespørselsmetodene.

Metode spesifisert i statuslinjen bestemmer hvordan ressursen hvis URL er angitt på samme linje påvirkes. Metoden kan ta verdiene GET, POST, HEAD, PUT, DELETE, etc. Til tross for overfloden av metoder, er bare to av dem virkelig viktige for en webprogrammerer: GET og POST.

• FÅ. I følge den formelle definisjonen er GET-metoden ment å skaffe en ressurs med en spesifisert URL. Ved mottak av en GET-forespørsel må serveren lese den spesifiserte ressursen og inkludere ressurskoden som en del av svaret til klienten. Ressursen hvis URL sendes som en del av forespørselen, trenger ikke å være en HTML-side, bildefil eller andre data. Ressurs-URLen kan peke til kjørbar programkode som, hvis visse betingelser er oppfylt, må kjøres på serveren. I dette tilfellet returneres ikke klienten programkoden, men dataene generert under utførelse. Selv om GET-metoden per definisjon er ment for å hente informasjon, kan den brukes til andre formål. GET-metoden er ganske egnet for å overføre små databiter til serveren.
• POST. I henhold til samme formelle definisjon er hovedformålet med POST-metoden å overføre data til serveren. I likhet med GET-metoden kan imidlertid POST-metoden brukes på mange forskjellige måter og brukes ofte til å hente informasjon fra en server. Som med GET-metoden, peker URL-en som er angitt i statuslinjen til en bestemt ressurs. POST metode kan også brukes til å starte en prosess.
• HEAD- og PUT-metodene er modifikasjoner av GET- og POST-metodene.

Protokollversjon HTTP er vanligvis spesifisert i følgende format:

HTTP/versjon.modifikasjon

Overskriftsfelt, etter statuslinjen, lar deg avgrense forespørselen, dvs. overføre til server Ytterligere informasjon. Overskriftsfeltet har følgende format:

Feltnavn: Verdi

Formålet med et felt bestemmes av navnet, som er atskilt fra verdien med et kolon.

Navnene på noen av de vanligste overskriftsfeltene i en klientforespørsel og deres formål er vist i tabell 2.1.

Tabell 2.1. HTTP-forespørselshodefelt.

Overskriftsfelt HTTP -be om	Betydning
Vert	Domenenavn eller IP-adresse til verten som klienten har tilgang til
Henviser	URL til dokumentet som refererer til ressursen som er oppført i statuslinjen
Fra	Adresse E-post bruker som jobber med en klient
Aksepterer	MIME-typer av data behandlet av klienten. Dette feltet kan ha flere verdier, atskilt med komma. Ofte brukes feltet Accept header for å fortelle serveren hvilke typer grafiske filer klient støtter
Accept-Language	Et sett med identifikatorer med to tegn, atskilt med komma, som indikerer språkene som støttes av klienten
Accept-Charset	Liste over støttede tegnsett
Innholdstype	MIME-type data som finnes i forespørselsteksten (hvis forespørselen ikke består av en enkelt overskrift)
Innhold-lengde	Antall tegn i forespørselsteksten (hvis forespørselen ikke består av en enkelt overskrift)
Område	Tilstede dersom klienten ikke ber om hele dokumentet, men kun deler av det
Forbindelse	Brukes til å administrere TCP-tilkobling. Hvis feltet inneholder Close, betyr dette at serveren skal lukke forbindelsen etter å ha behandlet forespørselen. Keep-Alive-verdien foreslår å holde TCP-tilkoblingen åpen slik at den kan brukes til påfølgende forespørsler
Bruker agent	Kundeinformasjon

I mange tilfeller, når du jobber på nettet, er det ingen forespørselsinstans. Når CGI-skript kjøres, kan dataene som sendes til dem i forespørselen, plasseres i forespørselens brødtekst.

Vi har gitt ut en ny bok «Content Marketing in i sosiale nettverk: Hvordan komme inn i abonnentenes hoder og få dem til å bli forelsket i merkevaren din.»

Webtjeneste (tjeneste) er et program som organiserer interaksjon mellom nettsteder. Informasjon fra en portal overføres til en annen.

For eksempel er det et flyselskap. Hun har mange flyreiser, noe som betyr at hun har mange billetter. Den overfører informasjon gjennom en netttjeneste til et reisesamlernettsted. En bruker som får tilgang til aggregatoren vil kunne kjøpe billetter til dette flyselskapet direkte der.

Et annet eksempel på nettjenester er et værsporingsnettsted som inneholder informasjon om værforhold i en bestemt by eller land som helhet. Denne informasjonen også ofte brukt av tredjeparter.

Informasjonen på Internett er variert. Nettsteder administreres av forskjellige systemer. Ulike overførings- og krypteringsprotokoller brukes. Webtjenester forenkler utveksling av informasjon mellom ulike nettsteder.

Webtjenesters arkitektur og protokoller

Du kan definere 3 myndigheter som samhandler med hverandre: katalog, entreprenør og kunde. Etter å ha opprettet tjenesten, registrerer entreprenøren den i katalogen, og kunden finner tjenesten der.

Datautvekslingsmekanismen er dannet i webtjenestebeskrivelsen. Dette er en spesifikasjon som dekker videresendingsformater, innholdstyper, transportprotokoller som brukes i prosessen med å utveksle informasjon mellom kunden og tjenestetransportøren.

I dag brukes flere teknologier oftest for å implementere ulike webtjenester:

1. TCP/IP er en protokoll som er forstått av nesten alle nettverksutstyr, fra stormaskiner til bærbare enheter og PDAer.
2. HTML er et universelt merkespråk som brukes til å vise innhold på forbrukerenheter.
3. XML er et universelt verktøy for behandling av alle typer data. Andre inkan fungere på dens basis: SOAP og WSDL.
4. UDDI er en universell kilde til anerkjennelse, integrering og beskrivelse. Det fungerer som regel i private nettverk og har ennå ikke funnet tilstrekkelig distribusjon.

Allsidigheten til de presenterte teknologiene er grunnlaget for å forstå webtjenester. De jobber for standard teknologier, uavhengig av applikasjonsleverandører og andre nettverksressurser. Kan brukes i alle operativsystemer, applikasjonsservere, programmeringsspråk osv.

Fordeler

• Skape nødvendige forutsetninger for samhandling programvarekomponenter uavhengig av plattform.
• Webtjenester er basert på åpne standardprotokoller. Takket være introduksjonen av XML er opprettelsen og konfigureringen av webtjenester forenklet.
• Bruken av HTTP garanterer interaksjonen mellom systemene gjennom internettarbeid.

Feil

• Lav ytelse og stort trafikkvolum, sammenlignet med RMI, CORBA, DCOM-systemer, på grunn av bruk av XML-meldinger i tekstsammenheng.
• Sikkerhetsnivå. Alle moderne webtjenester må implementere koding og krever brukerautorisasjon. Hvorvidt HTTPS er nok her eller om det trengs mer pålitelige protokoller, som XML-kryptering, SAML osv., avgjøres under utviklingen.

Oppgaver for nettjenester

Webtjenester kan brukes på mange områder.

B2B-transaksjoner

Integrering av prosesser skjer umiddelbart, uten deltakelse fra mennesker. For eksempel oppdatering av nettbutikkkatalogen med nye produkter. De bringes til lageret, og lagerholderen noterer ankomsten i databasen. Informasjonen overføres automatisk til nettbutikken. Og kjøperen, i stedet for å merke "Ikke på lager" på produktkortet, ser antallet.

Integrasjon av bedriftstjenester

Hvis bedriften bruker bedriftsprogrammer, vil webtjenesten hjelpe med å sette opp deres felles arbeid.

Opprette et klient-serversystem

Tjenester brukes til å konfigurere driften av klienten og serveren. Dette gir fordeler:

• Du kan ikke selge selve programvaren, men gi betalt tilgang til nettjenesten;
• Det er lettere å løse problemer ved å bruke tredjepartsprogramvare;
• det er lettere å organisere tilgangen til innholdet og materialet på serveren.

En webtjeneste er en applikasjon som forenkler det tekniske oppsettet av ressursinteraksjon.

World Wide Web er en ferdig plattform for å lage og bruke distribuerte maskinorienterte systemer basert på webtjenester. Nettserveren fungerer som en applikasjonsserver som ikke er tilgjengelig for sluttbrukere, men av tredjepartsapplikasjoner. Dette lar deg gjenbruke funksjonelle elementer, eliminere kodeduplisering og forenkle løsningen avr.

Nettjeneste, nettjeneste(engelsk web-tjeneste) er nettverksteknologi, gir inter-program interaksjon basert på nettstandarder. W3C definerer en webtjeneste som "et programvaresystem designet for å støtte interoperabel maskin-til-maskin-kommunikasjon over et nettverk."

Webtjenester: Konsepter og protokoller

En nettjeneste identifiseres av en URI-streng. Nettjenesten har et programvaregrensesnitt presentert i et maskinbearbeidbart format. Andre systemer samhandler med denne webtjenesten ved å utveksle protokollmeldinger. HTTP-protokollen brukes som en transport for meldinger. Beskrivelser av webtjenester og deres APIer kan bli funnet ved å bruke . Det konseptuelle diagrammet av teknologien er vist i, og forholdet mellom protokollene er vist i fig. 2.

Ris. 1. Webtjenestekonsept

• SÅPE(Simple Object Access Protocol) - meldingsutvekslingsprotokoll mellom forbrukeren og nettjenesteleverandøren;
• WSDL(Web Services Description Language) - språk for å beskrive eksterne grensesnitt til en webtjeneste;
• UDDI(Universal Discovery, Description and Integration) er et universelt gjenkjennelses-, beskrivelses- og integrasjonsgrensesnitt som brukes til å lage en katalog med webtjenester og få tilgang til den.

Ris. 2. Webtjenesters protokoller

Alle spesifikasjoner som brukes i teknologien er basert på XML og arver følgelig fordelene (strukturert, fleksibilitet, etc.) og ulemper (tunghet, treghet).

SÅPE

SÅPE (opprinnelig Simple Object Access Protocol, og i versjon 1.2 er det ingen offisiell dekoding av forkortelsen) er en enkel protokoll for tilgang til objekter (komponenter av et distribuert datasystem), basert på utveksling av strukturerte meldinger. Som enhver tekstprotokoll kan SOAP brukes med alle applikasjonslagsprotokoller: SMTP, FTP, HTTPS, etc., men oftest brukes SOAP over HTTP.

Alle SOAP-meldinger er formatert i en struktur kalt konvolutt(konvolutt), som inkluderer følgende elementer:

• Meldings-ID (lokalt navn).
• Valgfritt overskriftselement:
  • Null eller flere egenskaper tilgjengelig i dette navneområdet.
• Obligatorisk Body-element (meldingstekst)
  • Null eller flere referanser til brukte navneområder;
  • Barneelementer meldingstekst

En detaljert liste over SOAP-meldingselementer er gitt i dataskjemaet (for SOAP versjon 1.2).

Eksempel SOAP-melding:

Konvolutt xmlns:env=" http://www.w3.org/2003/05/soap-envelope"> Overskrift> 1 2001-06-22T14:00:00-05:00 Overskrift> Kropp> Stå opp klokken 06:30 Kropp> Konvolutt>

XML-RPC: Ikke en konkurrent, men et alternativ til SOAP

XML-RPC er en veldig enkel og effektiv protokoll for å kommunisere webtjenester. Det er ikke designet for å løse globale problemer som SOAP, men er mye brukt i mange nettutviklinger.

XML-RPC konsept

Tabell 1. Grunnleggende elementer i WSDL-protokollen.

WSDL 1.1-element	WSDL 2.0-element	Kort beskrivelse
PortType	Grensesnitt	Representerer en beskrivelse av webtjenestegrensesnittet (en liste over operasjoner og deres parametere).
Service	Service	Liste over systemfunksjoner
Binding	Binding	Spesifiserer grensesnitt og setter bindingsparametere med SOAP-protokollen: bindingsstil (RPC/Document) og transport (SOAP). Denne delen er også tilgjengelig for hver av operasjonene
Operasjon	Operasjon	Definerer operasjonen presentert av webserveren. En WSDL-operasjon er analog med tradisjonelle funksjoner og prosedyrer.
Beskjed	ikke brukt	En melding knyttet til en bestemt operasjon. Inneholder informasjon som er nødvendig for å utføre en gitt operasjon. Hver melding kan bestå av flere logiske deler som beskriver datatyper og attributtnavn. I versjon 2.0 ble det ekskludert pga XML Schema-støtte ble introdusert for alle elementer.
Typer	Typer	Beskrivelse av data i henhold til XML Schema.

Ris. 3. WSDL-protokollstruktur

WSDL 1.1-spesifikasjonen definerte 4 meldingsutvekslingsmønstre (operasjonstyper):

• Enveisoperasjoner: En operasjon kan motta en melding, men vil ikke returnere et svar.
• Request-response: Operasjonen kan godta en forespørsel og må returnere et svar.
• Spørsmål-svar (Solicit-response): operasjonen kan sende en forespørsel og vil vente på svar på den.
• Varsling: Operasjonen kan sende en melding, men vil ikke vente på svar.

I WSDL 2.0 er disse malene modifisert og utvidet for å støtte feilmeldinger (for eksempel Robust-in-only-malen), men for bakoverkompatibilitet WSDL 1.1-typer støttes

UDDI er avhengig av industristandardene HTTP, XML, XML Schema (XSD), SOAP og WSDL. Det konseptuelle forholdet mellom UDDI og andre protokoller i webtjenestestabelen er vist i.

Ris. 4. UDDIs plass i Web Services Protocol Stack

Funksjonaliteten til UDDI-registeret er å representere data og metadata om webtjenester. Det kan brukes både online vanlig bruk, og innenfor den interne infrastrukturen til organisasjonen. UDDI-registeret gir en standardbasert mekanisme for klassifisering, katalogisering og administrasjon av webtjenester slik at webtjenester kan brukes av andre applikasjoner. Denne mekanismen inkluderer fasiliteter for å finne en tjeneste, påkalle den tjenesten og administrere metadata om den tjenesten.

Nøkkelfunksjonene til UDDI er å publisere informasjon om en tjeneste til et register og hente den informasjonen tredjepartsapplikasjoner. Sammen med disse implementeres også typiske funksjoner for en katalogtjeneste: representasjon av den lagrede datamodellen og strukturen informasjonsgrunnlag, forhold mellom registerobjekter, replikering, sikkerhet, etc. —Alle hovedfunksjonene til registret presenteres som webtjenester og er tilgjengelige via UDDI API.

Webtjenester: Pro et Contra

Fordeler

• Gi interaksjon programvaresystemer uavhengig av plattform.
• Basert på åpne standarder og protokoller.
• Ved å bruke HTTP kan applikasjoner kommunisere gjennom en brannmur.

Feil

• Lavere ytelse og høyere volum av nettverkstrafikk sammenlignet med teknologier som CORBA eller DCOM.

Permanent adresse til denne siden:

Lar deg motta ulike ressurser, for eksempel HTML-dokumenter. HTTP-protokollen ligger til grunn for datautveksling på Internett. HTTP er en klient-server kommunikasjonsprotokoll, som betyr at forespørsler til serveren initieres av mottakeren selv, vanligvis en nettleser. Det resulterende sluttdokumentet vil (kan) bestå av ulike underdokumenter som er en del av sluttdokumentet: for eksempel separat mottatt tekst, en beskrivelse av dokumentstrukturen, bilder, videofiler, skript og mye mer.

Klienter og servere kommuniserer ved å utveksle enkeltmeldinger (i stedet for en strøm av data). Meldinger sendt av en klient, vanligvis en nettleser, kalles forespørsler, og meldinger sendt av serveren kalles opp svar.

Selv om HTTP ble utviklet på begynnelsen av 1990-tallet, har den blitt kontinuerlig forbedret på grunn av dens utvidbarhet. HTTP er en applikasjonslagsprotokoll som oftest bruker egenskapene til en annen protokoll - TCP (eller TLS - sikker TCP) - for å videresende meldingene sine, men enhver annen pålitelig transportprotokoll kan teoretisk brukes til å levere slike meldinger. På grunn av utvidbarheten brukes den ikke bare for klienten for å motta hypertekstdokumenter, bilder og videoer, men også for å overføre innhold til servere, for eksempel ved hjelp av HTML-skjemaer. HTTP kan også brukes til å hente kun deler av et dokument med det formål å oppdatere en nettside på forespørsel (for eksempel via en AJAX-forespørsel).

Komponenter av HTTP-baserte systemer

HTTP er en klient-server-protokoll, det vil si at forespørsler sendes av én part - en deltaker i utvekslingen (brukeragent) (eller en proxy i stedet). Som oftest er deltakeren en nettleser, men det kan være hvem som helst, for eksempel en robot som reiser på nettet for å fylle på og oppdatere nettsideindekseringsdata for søkemotorer.

Hver forespørsel be om) sendes til serveren, som behandler den og returnerer et svar (eng. respons). Mellom disse forespørslene og svarene er det vanligvis mange mellomledd kalt proxyer, som utfører ulike operasjoner og fungerer som gatewayer eller cacher, for eksempel.

Vanligvis er det mellom nettleseren og serveren mange flere forskjellige mellomliggende enheter som spiller en rolle i behandlingen av forespørselen: rutere, modemer og så videre. På grunn av det faktum at nettverket er bygget på grunnlag av et system av interaksjonsnivåer (lag), er disse mellomleddene "gjemt" på nettverks- og transportnivå. I dette lagdelingssystemet okkuperer HTTP det øverste laget, som kalles "applikasjonslaget" (eller "applikasjonslaget"). Kunnskap om nettverkslag som presentasjon, økt, transport, nettverk, kobling og fysisk er avgjørende for å forstå nettverksdrift og diagnostikk. mulige problemer, men er ikke pålagt å beskrive og forstå HTTP.

Oppdragsgiver: utvekslingsdeltaker

En brukeragent er ethvert verktøy eller enhet som handler på vegne av en bruker. Denne oppgaven utføres primært av nettleseren; i noen tilfeller er deltakerne programmer som brukes av ingeniører og webutviklere for å feilsøke applikasjonene deres.

Nettleser Alltid er enheten som oppretter forespørselen. Serveren gjør vanligvis ikke dette, selv om nettverket i løpet av årene har blitt oppfunnet måter som kan tillate at forespørsler fra serveren oppfylles.

For å vise en nettside sender nettleseren en første forespørsel om å få tak i HTML-dokumentet til den siden. Etter dette undersøker nettleseren dette dokumentet og ber om ytterligere filer som er nødvendige for å vise innholdet på nettsiden (kjørbare skript, informasjon om sidelayout - CSS-tabeller stiler, tilleggsressurser i form av bilder og videofiler) som er direkte en del av kildedokumentet, men som ligger andre steder på nettverket. Deretter kobler nettleseren alle disse ressursene for å vise dem til brukeren i form av et enkelt dokument - en nettside. Skript utført av nettleseren selv kan motta ytterligere ressurser over nettverket på senere stadier av behandlingen av nettsiden, og nettleseren oppdaterer visningen av den siden til brukeren tilsvarende.

En nettside er et hypertekstdokument. Dette betyr at noen deler av den viste teksten er lenker som kan aktiveres (vanligvis ved å klikke på en museknapp) for å hente og derfor vise en ny nettside (ved å følge en lenke). Dette lar brukeren "navigere" nettsider (Internett). Nettleseren konverterer disse hyperkoblingene til HTTP-forespørsler og viser deretter de mottatte HTTP-svarene i en brukervennlig form.

Internett server

På den andre siden av kommunikasjonskanalen er det en server som betjener (eng. tjene) bruker, og gir ham dokumenter på forespørsel. Fra sluttbrukerens synspunkt er serveren alltid en virtuell maskin, som genererer et dokument helt eller delvis, selv om det faktisk kan være en gruppe servere som belastningen er balansert mellom, det vil si at forespørsler fra forskjellige brukere blir omfordelt, eller kompleks programvare som poller andre datamaskiner (som caching-servere , databaseservere, e-handelsapplikasjonsservere og annet).

En server er ikke nødvendigvis plassert på én maskin, og omvendt – flere servere kan være lokalisert (hosted) på samme maskin. I henhold til HTTP/1.1-versjonen og med en Host-header, kan de til og med dele den samme IP-adressen.

Fullmakt

Mellom nettleseren og serveren er det et stort antall nettverksnoder som overfører HTTP-meldinger. På grunn av sin lagdelte struktur opererer de fleste av dem også på transportnettet eller fysiske nivåer, bli gjennomsiktig for HTTP-laget og potensielt redusere ytelsen. Disse operasjonene på applikasjonsnivå kalles proxy . De kan være gjennomsiktige eller ikke (endringsforespørsler vil ikke gå gjennom dem), og kan utføre mange funksjoner:

• caching (cache kan være offentlig eller privat, som nettleserbuffer)
• filtrering (som antivirusskanning, foreldrekontroll, …)
• lastbalansering (tillat flere servere å betjene forskjellige forespørsler)
• autentisering (kontroller tilgang til forskjellige ressurser)
• logging (tillatelse til å lagre transaksjonshistorikk)

Grunnleggende aspekter ved HTTP

HTTP er enkelt

Selv med den større kompleksiteten introdusert i HTTP/2 ved å kapsle inn HTTP-meldinger i rammer, er HTTP generelt enkelt og lesbart for mennesker. HTTP-meldinger kan leses og forstås av mennesker, noe som gir enklere testing for utviklere og redusert kompleksitet for nye brukere.

HTTP - utvidbar

HTTP-hodene introdusert i HTTP/1.0 gjorde protokollen enkel å utvide og eksperimentere med. Ny funksjonalitet kan til og med introduseres ved en enkel avtale mellom klient og server om semantikken til den nye overskriften.

HTTP er statsløs, men har en økt

HTTP er statsløs: det er ingen sammenheng mellom to forespørsler som utføres sekvensielt over samme tilkobling. Dette innebærer umiddelbart potensialet for problemer for en bruker som prøver å samhandle med en bestemt side sekvensielt, for eksempel ved bruk av en handlekurv i en nettbutikk. Men mens HTTP-kjernen er statsløs, muliggjør informasjonskapsler tilstandsfulle økter. Ved å bruke overskriftsutvidbarhet blir informasjonskapsler lagt til i arbeidertråden, slik at økten kan dele en eller annen kontekst, eller tilstand, på hver HTTP-forespørsel.

HTTP og tilkoblinger

Forbindelsen administreres på transportlaget, og går derfor fundamentalt utenfor HTTPs grenser. Selv om HTTP ikke krever at den underliggende transportprotokollen er tilkoblingsbasert, krever kun pålitelighet, eller ingen tapte meldinger (dvs. i det minste en feilrepresentasjon). Blant de to vanligste transportprotokollene på Internett er TCP pålitelig, mens UDP ikke er det. HTTP er deretter avhengig av at TCP-standarden er tilkoblingsbasert, selv om en tilkobling ikke alltid er nødvendig.

HTTP/1.0 åpnet en TCP-tilkobling for hver forespørsel/svar-utveksling, med to viktige ulemper: Å åpne en tilkobling krever flere meldingsutvekslinger og er derfor treg, selv om det blir mer effektivt når du sender flere meldinger, eller når du sender meldinger regelmessig: varm tilkoblinger er mer effektive enn kald.

For å redusere disse manglene, introduserte HTTP/1.1 pipelining (som viste seg vanskelig å implementere) og vedvarende tilkoblinger: den underliggende TCP-tilkoblingen kan delvis kontrolleres gjennom Connection-headeren. HTTP/2 tok neste steg ved å legge til multipleksing av meldinger over en enkel tilkobling, noe som bidro til å holde tilkoblingen varm og mer effektiv.

Det gjennomføres eksperimenter for å utvikle en bedre transportprotokoll som er mer egnet for HTTP. For eksempel eksperimenterer Google med QUIC, som er basert på UDP, for å gi en mer pålitelig og effektiv transportprotokoll.

Hva kan styres via HTTP

Den naturlige utvidbarheten til HTTP har muliggjort større kontroll og funksjonalitet på nettet over tid. Buffer og autentiseringsmetoder var tidlige funksjoner i HTTP-historien. Muligheten til å lempe på de opprinnelige restriksjonene ble derimot lagt til på 2010-tallet.

Følgende er vanlige funksjoner som administreres med HTTP.

• 
  Serveren kan instruere proxyer og klienter hva som skal bufres og hvor lenge. Klienten kan instruere mellomliggende hurtigbufferproxyer til å ignorere lagrede dokumenter.
• Avslappende kildebegrensninger
  For å forhindre spionprogrammer og andre personvernkrenkende inntrengninger, opprettholder nettleseren strengt skille mellom nettsteder. Kun sider fra samme kilde kan få tilgang til informasjon på nettsiden. Selv om slike restriksjoner belaster serveren, kan HTTP-hoder lempe på den strenge separasjonen på serversiden, slik at dokumentet kan bli en del av informasjon fra forskjellige domener (av sikkerhetsgrunner).
• Autentisering
  Noen sider er kun tilgjengelige for spesielle brukere. Grunnleggende autentisering kan gis via HTTP, enten ved bruk av WWW-Authenticate og lignende overskrifter, eller ved å sette opp en spesiell økt med informasjonskapsler.
• Proxy og tunnelering
  Servere og/eller klienter er ofte plassert på et intranett, og skjuler deres sanne IP-adresser for andre. HTTP-forespørsler gå gjennom en proxy for å krysse denne nettverksbarrieren. Ikke alle proxyer er HTTP-proxyer. SOCKS-protokollen, for eksempel, opererer på et lavere nivå. Andre, for eksempel ftp, kan håndteres av disse proxyene.
• Økter
  Ved å bruke en HTTP-informasjonskapsel kan du knytte en forespørsel til en tilstand på serveren. Dette skaper en økt, selv om HTTP er en statsløs protokoll i kjernen. Dette er nyttig ikke bare for handlekurver i nettbutikker, men også for alle nettsteder som lar brukeren tilpasse utgangen.

HTTP-strøm

Når en klient ønsker å kommunisere med en server, enten det er en endelig server eller en mellomproxy, følger den disse trinnene:

1. Åpne en TCP-tilkobling: En TCP-tilkobling vil bli brukt til å sende en forespørsel eller forespørsler og motta et svar. Klienten kan åpne en ny tilkobling, gjenbruke en eksisterende eller åpne flere TCP-tilkoblinger til serveren.
2. Sende en HTTP-melding: HTTP-meldinger (før HTTP/2) er lesbare for mennesker. Siden HTTP/2, enkle meldinger er innkapslet i rammer, noe som gjør dem umulige å lese direkte, men forblir fundamentalt de samme. GET / HTTP/1.1 Vert: nettsted Accept-Language: fr
3. Leser svar fra server: HTTP/1.1 200 OK Dato: Lør, 09. okt. 2010 14:28:02 GMT Server: Apache Sist endret: Tue, 01. Des. 2009 20:18:22 GMT ETag: "51142bc1-794907bc1-794497b" Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html
4. Lukker eller gjenbruker forbindelsen for ytterligere forespørsler.

Hvis HTTP-rørledningen er aktivert, kan flere forespørsler sendes uten å vente på at det første svaret mottas i sin helhet. HTTP-pipelinen er vanskelig å integrere i eksisterende nettverk, der gamle deler av programvare eksisterer side om side med moderne versjoner. HTTP-rørledningen ble erstattet i HTTP/2 med mer pålitelige multipleksede forespørsler i en ramme.

HTTP-meldinger

HTTP/1.1 og tidligere HTTP-meldinger er lesbare for mennesker. I HTTP/2 er disse meldingene innebygd i en ny binær struktur, en ramme, som tillater optimaliseringer som header-komprimering og multipleksing. Selv om en del av den opprinnelige HTTP-meldingen sendes i denne versjonen av HTTP, endres ikke semantikken til hver melding, og klienten gjenskaper (praktisk talt) den opprinnelige HTTP-forespørselen. Det er også nyttig for å forstå HTTP/2-meldinger i HTTP/1.1-format.

Det finnes to typer HTTP-meldinger, forespørsler og svar, hver i et annet format.

Forespørsler

Eksempler på HTTP-forespørsler:

• HTTP-metoden, vanligvis et verb som GET,
• Overskrifter (valgfritt) som gir tilleggsinformasjon til serveren.
• Eller en kropp, for noen metoder som POST, som inneholder ressursen som ble sendt.

Svar

Eksempelsvar:

• HTTP-protokollversjon.
• HTTP-statuskode som indikerer suksessen til forespørselen eller årsaken til feilen.
• Statusmelding -- en kort beskrivelse av statuskoden.
• HTTP-hoder ligner på overskrifter i forespørsler.
• Valgfritt: en kropp som inneholder ressursen som sendes.

Konklusjon

HTTP er en enkel å bruke, utvidbar protokoll. Klient-server-strukturen, kombinert med muligheten til å enkelt legge til overskrifter, gjør at HTTP kan gå videre med de utvidede mulighetene til nettet.

Selv om HTTP/2 legger til noe kompleksitet ved å bygge inn HTTP-meldinger i rammer for å forbedre ytelsen, forblir den grunnleggende meldingsstrukturen med HTTP/1.0. Øktråden forblir enkel, noe som tillater utforskning og feilsøking med letthet.