Anrop for ekstern prosedyre

I distribuert databehandling er ekstern prosedyrekall (på engelsk , Remote Procedure Call , RPC ) et program som en datamaskin bruker for å kjøre kode på en annen ekstern maskin uten å måtte bekymre seg for kommunikasjon mellom de to, slik at det ser ut til å bli utført i lokalene . Protokollen som brukes for denne samtalen er et stort fremskritt i forhold til Internett - kontaktene som er brukt til nå. På denne måten trengte ikke programmereren å være klar over kommunikasjonen, siden de var innkapslet i RPC-ene.

Et prosedyrekall er veldig likt en ekstern metodeanrop der et klientprogram kaller en prosedyre i et annet program som kjører i en serverprosess. Servere kan være klienter til andre servere for å tillate RPC-kjeder. En serverprosess definerer i tjenestegrensesnittet prosedyrene som er tilgjengelige for å bli kalt eksternt. RPC er vanligvis implementert over forespørsel-svar-protokollen, som forenkles ved å utelate referanser til eksterne objekter i forespørselsmeldingsdelen.

RPC-er er mye brukt i klient-server- kommunikasjon . Å være klienten den som starter prosessen som ber serveren om å utføre en bestemt prosedyre eller funksjon og sender resultatet av operasjonen tilbake til klienten.

Klienten som får tilgang til en tjeneste inkluderer en stumpprosedyre for hver prosedyre i tjenestegrensesnittet. Rollen til en reserveprosedyre er lik den til en proxy. Den oppfører seg som en lokal klientprosedyre, men i stedet for å utføre anropet, pakker den prosedyreidentifikatoren og argumentene inn i en forespørselsmelding som sendes via kommunikasjonsmodulen til serveren; når svarmeldingen kommer, pakker den ut resultatene.

Konseptet RPC ble først introdusert av Birrell og Nelson i 1984, og la grunnlaget for distribuert systemutvikling som brukes i dag. ]

Designproblemer

Det er problemer knyttet til implementering av RPC-systemer som programmerer med grensesnitt og transparens, begge oppsummert i boken "Distribuerte systemer: konsepter og design". ]

Grensesnitt

De fleste moderne programmer har en modulær struktur, der en funksjon kan brukes gjennom et grensesnitt, som maskerer nevnte prosedyre og dens funksjonalitet kan endres uten å påvirke måten den kalles på. Disse modulene kan kommunisere med hverandre via RPC på en slik måte at interaksjonene styres gjennom modulenes grensesnitt, selv om deres interne implementering varierer.

I et distribuert program, for eksempel med en klient-server-arkitektur, gir serveren klientene en liste over modulene som er tilgjengelige for bruk, samt argumentene som er nødvendige for å foreta et korrekt kall til dem. På denne måten trenger klienten bare å bekymre seg for grensesnittet, han trenger ikke å vite detaljer om implementeringen av modulen, for eksempel programmeringsspråket, eller plattformen der tjenesten ble implementert, på denne måten problemet med heterogeniteten til dagens distribuerte systemer.

På den annen side, hvis en modul som kjører i en prosess trenger tilgang til variabler fra en annen modul som kjører i en annen prosess, kan den ikke få tilgang til dem, siden det ikke er tillatt å sende argumenter ved referanse. Som en konsekvens av sistnevnte går utgangsparametrene i en svarmelding. Ett unntak er CORBA som kan få tilgang til variabler fra en modul plassert i en annen prosess ved å bruke getter- og settermetodene .

Åpenhet

Skaperne av RPC, Birrell og Nelson, prøvde å foreta eksterne prosedyreanrop så like lokale som mulig, slik at det ikke skulle være noe skille mellom en lokal samtale og en ekstern samtale. Transformasjonene av datarepresentasjonen til et passende format, såkalt marshalling , samt andre prosedyrer for meldingsoverføring er skjult for programmereren. RPC fokuserer på å gi plassering og tilgangsgjennomsiktighet ved å skjule den fysiske plasseringen av metoder.

Imidlertid er eksterne prosedyreanrop mer sårbare for feil enn lokale, siden de involverer en nettverkstilkobling og en annen datamaskin med en annen prosess. Dette gjør det vanskeligere å fastslå hva som kan ha forårsaket en feil.

Husk også at RPC-anrop har høyere ventetid . Dette må tas i betraktning ved å redusere denne typen anrop minst mulig eller ved å gjøre prosedyren som gjør at RPC-anropet er i stand til å avbryte det hvis det tar for lang tid. Hvis det siste gjøres, er det viktig at serveren gjenoppretter informasjonen til slik den var før samtalen.

Det er en diskusjon blant programmerere om hvor transparent en RPC-samtale må være. For eksempel hevdet skaperne av programmeringsspråket Argus ( Liskov og Scheifler ) at RPC-anrop burde være forskjellige fra lokale, og som en konsekvens gjorde Argus eksterne anrop eksplisitte til programmereren. Den generelle konklusjonen er at syntaksen mellom en lokal samtale og en ekstern samtale bør være den samme, og at forskjellen mellom den ene og den andre bør forklares i deres grensesnitt.

Typer semantikk

Det er forskjellige moduser som garanterer levering av meldinger i RPC:

• Forespørselsmelding på nytt: kontrollerer reoverføring av forespørselen til serveren mottar den eller antar at den har mislyktes

• Duplikatfilter: kontrollerer bruken av reoverføringer og om serveren forkaster duplikatforespørsler

• Reoverføring av resultater: Kontrollerer om en historikk over meldingsresultater skal beholdes, slik at tapte resultater kan overføres på nytt uten å utføre operasjoner på nytt på serveren.

Kombinasjonen av disse alternativene fører til tre mulige typer semantikk: «kanskje», «minst én gang» og «på-mest-en gang» ]

Feiltoleransetiltak ]			Ring semantikk
Prøv forespørselsmelding på nytt	Duplikatfilter	Resending av resultatene
Nei	Ikke anvendelig	Ikke anvendelig	kanskje
Ja	Nei	Kjør prosedyren på nytt	i hvert fall en gang
Ja	Ja	Videresend svaret	høyst en gang

"Kanskje" semantikk

• Ekstern prosedyre kan utføres én gang eller ikke i det hele tatt.
• Kunden kan få svar eller ikke.

Fungerer

1. Klienten sender en forespørsel og venter på en viss tid.
2. Hvis svaret ikke kommer innen tidsavbruddet, fortsetter det å utføre.
3. Klienten har ingen tilbakemelding ved svikt (vet ikke hva som har skjedd).

Kun tillatt i søknader der tap av forespørsler og mottak av forsinkede svar (ute av funksjon) tolereres.

"Minst-en gang" semantikk

• Ekstern prosedyre utføres en eller flere ganger.
• Kunden kan motta ett eller flere svar.

Fungerer

1. Klienten sender en forespørsel og venter en stund.
2. Hvis ingen svar eller ACK kommer innen tidsavbruddet, gjenta forespørselen.
3. Serveren filtrerer ikke dupliserte forespørsler (den eksterne prosedyren kan utføres gjentatte ganger).
4. Kunden kan motta flere svar.

Det er bare aktuelt når utelukkende idempotente (repetable) operasjoner brukes. Merk: En operasjon er idempotent hvis den kan utføres flere ganger med samme effekt som om den bare hadde blitt utført én gang. Noen ganger kan en ikke-idempotent operasjon implementeres som en sekvens av idempotente operasjoner. Tillatt i søknader der det er tolerert at påkallinger kan gjentas uten at det påvirker driften.

"på-most-once" semantikk

• Fjernprosedyren utføres nøyaktig én gang eller ikke i det hele tatt.
• Klienten mottar et svar eller en indikasjon på at fjernprosedyren ikke er utført.

Fungerer

1. Klienten sender forespørselen og venter en stund.
2. Hvis ingen svar eller ACK kommer innen tidsavbruddet, gjenta forespørselen.
3. Serveren filtrerer dupliserte forespørsler og holder en historikk over svarene som er sendt (server med minne). Fjernprosedyren utføres bare én gang.
4. Klienten får kun svar hvis forespørselen kom og prosedyren ble utført, ellers mottar den en feilrapport.

Sammendrag av RPC-semantikk

Semantikk	Fungerer
kanskje	Klienten sender ikke forespørslene sine på nytt (bruker ikke ACK )
	Serveren filtrerer ikke dupliserte forespørsler
i hvert fall en gang	Klienten sender sine forespørsler på nytt (bruker ACK + timer)
	Serveren filtrerer ikke dupliserte forespørsler
	Konfrontert med gjentatte forespørsler, gjentar server kjøringen
høyst én	Klienten sender sine forespørsler på nytt (bruker ACK + timer)
	Server filtrerer dupliserte forespørsler
	I møte med gjentatte forespørsler, sender serveren tidligere svar på nytt

Implementeringer

Implementeringen av et eksternt prosedyrekall krever en rekke programvarekomponenter, som kan sees i følgende figur oversatt fra den som finnes i boken "Distribuerte systemer: konsepter og design". ]

RPC implementeringsplan

Inne i klientprosessen ligger hovedprogrammet (klientprogrammet). Dette kommuniserer med en stumpprosedyre som er ansvarlig for å utføre rangeringsfunksjonen , for å transformere dataene til riktig format og sende dem som en forespørselsmelding gjennom kommunikasjonsmodulen. Når svaret kommer, angrer stubben transformasjonen for å få resultatene.

Kommunikasjonsmodulen til klientprosessen kommuniserer med den til serverprosessen, hvorfra den overfører dataene til en distributør (dispatcher) som sender dataene til den tilsvarende stubbprosedyren, som vil utføre rangeringsfunksjonen med serviceprosedyren. Siden det er flere stubber, en for hver serviceprosedyre, er distributøren ansvarlig for å velge den som tilsvarer hver forespørsel.

Kommunikasjonsmodulene er ikke bare ansvarlige for å adressere meldingene, men også for andre aspekter knyttet til kommunikasjon som dupliserte meldinger, tidsavbrudd eller resendinger. ]

Generelt implementerer RPC en forespørsel-svar-protokoll.

Eksterne prosedyrekall implementeres gjennom ulike typer protokoller, mange av dem standardiserte, slik som Suns RPC kalt ONC RPC ( RFC 1057 ), Open Software Foundation (OSF) RPC kalt DCE/RPC og "Model of Microsoft Distributed Component Object Model ( DCOM ), selv om ingen av disse er kompatible med hverandre. De fleste av dem bruker et grensesnittbeskrivelsesspråk ( Interface Description Language eller IDL) som definerer metodene som eksporteres av serveren.

I dag brukes XML som språk for å definere IDL og HTTP som applikasjonsprotokollen, noe som gir opphav til det som kalles webtjenester. Eksempler på disse kan være SOAP eller XML-RPC .

Se også

• ONC RPC ekstern prosedyrekall fra Sun.
• DCE/RPC ekstern prosedyrekall fra Open Software Foundation.
• Distributed Component Object Model (DCOM), Microsofts distribuerte komponentobjektmodell.
• Java Remote Method Invocation (RMI), Invocation of Remote Methods for Java.
• CORBA .
• XML-RPC .
• SÅPE .
• Distribuert databehandling .

Eksterne lenker

• www.sun.com Sun Microsystems (på engelsk).
• www.w3.org/TR/soap/Soap .
• www.faqs.org/rfcs/rfc1057.html RFC 1057 (på engelsk).
• www.jmasters.info:8443/jres/ JRES - Java Remote Execution Service er en RPC - protokoll som bruker en kodemekanisme i SSL - stil for å kode sine samtaler og ren HTTP som en transportmekanisme .