Besked passerer - Message passing

Denne artikel handler om datalogisk koncept. For anden anvendelse, se Beskedoverførsel (disambiguation) .

Inden for datalogi er meddelelsesoverførsel en teknik til at påkalde adfærd (dvs. køre et program ) på en computer . Påkaldelsesprogrammet sender en besked til en proces (som kan være en aktør eller et objekt ) og er afhængig af denne proces og dens understøttende infrastruktur for derefter at vælge og køre en passende kode. Beskedoverførsel adskiller sig fra konventionel programmering, hvor en proces, underrutine eller funktion direkte påberåbes ved navn. Beskedformidling er nøglen til nogle modeller af samtidighed og objektorienteret programmering .

Besked passerer er allestedsnærværende i moderne computer -software . Det bruges som en måde for de objekter, der udgør et program, til at arbejde med hinanden og som et middel til objekter og systemer, der kører på forskellige computere (f.eks. Internettet ) til at interagere. Beskedoverførsel kan implementeres ved forskellige mekanismer, herunder kanaler .

Oversigt

Beskedoverførsel er en teknik til påkaldelse af adfærd (dvs. at køre et program) på en computer. I modsætning til den traditionelle teknik til at kalde et program ved navn, bruger meddelelsesoverførsel en objektmodel til at skelne den generelle funktion fra de specifikke implementeringer. Påkaldelsesprogrammet sender en besked og er afhængig af objektet for at vælge og eksekvere den relevante kode. Begrundelserne for at bruge et mellemlag falder i det væsentlige i to kategorier: indkapsling og distribution.

Indkapsling er tanken om, at softwareobjekter skal kunne påberåbe sig tjenester på andre objekter uden at vide eller bekymre sig om, hvordan disse tjenester implementeres. Indkapsling kan reducere mængden af ​​kodningslogik og gøre systemer mere vedligeholdelige. F.eks. I stedet for at have IF-THEN-sætninger, der bestemmer, hvilken underprogram eller funktion der skal kaldes til en udvikler, kan det bare sende en besked til objektet, og objektet vælger den relevante kode baseret på dens type.

Et af de første eksempler på, hvordan dette kan bruges, var inden for computergrafik. Der er forskellige kompleksiteter involveret i manipulation af grafiske objekter. For eksempel vil blot at bruge den rigtige formel til at beregne arealet af en lukket form variere afhængigt af om formen er en trekant, rektangel, ellipse eller cirkel. I traditionel computerprogrammering ville dette resultere i lange IF-THEN-sætninger, der testede, hvad slags objekt formen var og kalder den relevante kode. Den objektorienterede måde at håndtere dette på er at definere en klasse kaldet Shapemed underklasser som Rectangleog Ellipse(som igen har underklasser Squareog Circle) og derefter blot sende en besked til enhver, der Shapebeder den om at beregne sit område. Hvert Shapeobjekt påkalder derefter underklassens metode med den formel, der er passende for den slags objekter.

Distribueret beskedoverførsel giver udviklere et lag af arkitekturen, der leverer fælles tjenester til at bygge systemer, der består af undersystemer, der kører på forskellige computere forskellige steder og på forskellige tidspunkter. Når et distribueret objekt sender en besked, kan meddelelseslaget tage sig af problemer som:

  • At finde processen ved hjælp af forskellige operativsystemer og programmeringssprog på forskellige steder, hvor meddelelsen stammer fra.
  • Gemmer meddelelsen i en kø, hvis det relevante objekt til håndtering af meddelelsen ikke kører i øjeblikket og derefter påberåber meddelelsen, når objektet er tilgængeligt. Også lagring af resultatet, hvis det er nødvendigt, indtil afsenderobjektet er klar til at modtage det.
  • Styring af forskellige transaktionskrav til distribuerede transaktioner, f.eks. ACID -test af dataene.

Synkron kontra asynkron beskedoverførsel

Synkron besked sender

Synkron meddelelsesoverførsel sker mellem objekter, der kører på samme tid. Det bruges af objektorienterede programmeringssprog som Java og Smalltalk.

Synkron messaging er analog med et synkron funktionsopkald; ligesom funktionopkalderen venter, indtil funktionen er fuldført, venter afsendelsesprocessen, indtil den modtagende proces er fuldført. Dette kan gøre synkron kommunikation upraktisk for nogle applikationer. For eksempel fungerer store, distribuerede systemer muligvis ikke godt nok til at være brugbare. Sådanne store, distribuerede systemer skal muligvis fungere, mens nogle af deres undersystemer er nede for vedligeholdelse osv.

Forestil dig et travlt forretningskontor, der har 100 stationære computere, der sender e -mails til hinanden ved hjælp af synkron besked, der udelukkende passerer. En medarbejder, der slukker computeren, kan få de andre 99 computere til at fryse, indtil medarbejderen tænder computeren igen for at behandle en enkelt e -mail.

Asynkron besked passerer

Når en asynkron besked passerer, kan det modtagende objekt være nede eller optaget, når det anmodende objekt sender beskeden. Ved at fortsætte funktionsopkaldsanalogien ligner det et funktionsopkald, der vender tilbage med det samme uden at vente på, at den kaldte funktion skal fuldføres. Beskeder sendes til en kø, hvor de gemmes, indtil modtagelsesprocessen anmoder om det. Den modtagende proces behandler sine meddelelser og sender resultaterne til en kø til afhentning ved den originale proces (eller en anden udpeget næste proces).

Asynkron besked kræver yderligere muligheder for lagring og videresendelse af data til systemer, der muligvis ikke kører samtidigt, og som generelt håndteres af et mellemled af software (ofte kaldet middleware ); en almindelig type er Message-orienteret middleware (MOM).

Bufferen, der kræves i asynkron kommunikation, kan forårsage problemer, når den er fuld. Der skal tages stilling til, om afsenderen skal blokeres, eller om fremtidige meddelelser skal kasseres. En blokeret afsender kan føre til dødvande . Hvis meddelelser slippes, er kommunikation ikke længere pålidelig.

Hybrider

Synkron kommunikation kan bygges oven på asynkron kommunikation ved hjælp af en Synchronizer . For eksempel fungerer α-Synchronizer ved at sikre, at afsenderen altid venter på en bekræftelsesmeddelelse fra modtageren. Afsenderen sender først den næste besked, når kvitteringen er modtaget. På den anden side kan asynkron kommunikation også bygges oven på synkron kommunikation. For eksempel leverer moderne mikrokerner generelt kun en synkron besked primitiv og asynkron besked kan implementeres oven på ved hjælp af hjælper -tråde .

Distribuerede objekter

Hovedartikel: Distribueret objekt

Meddelelsesoverførende systemer bruger enten distribuerede eller lokale objekter. Med distribuerede objekter kan afsender og modtager være på forskellige computere, køre forskellige operativsystemer, bruge forskellige programmeringssprog osv. I dette tilfælde tager buslaget sig af detaljer om konvertering af data fra et system til et andet, afsendelse og modtagelse af data på tværs af netværk osv. RPC -protokollen ( Remote Procedure Call ) i Unix var et tidligt eksempel på dette. Bemærk, at med denne form for besked, der passerer, er det ikke et krav, at afsender eller modtager bruger objektorienteret programmering. Proceduresprogsystemer kan pakkes ind og behandles som store kornete objekter, der er i stand til at sende og modtage beskeder.

Eksempler på systemer, der understøtter distribuerede objekter, er: Emerald , ONC RPC , CORBA , Java RMI , DCOM , SOAP , .NET Remoting , CTOS , QNX Neutrino RTOS , OpenBinder og D-Bus . Distribuerede objektsystemer er blevet kaldt "delte ingenting" -systemer, fordi meddelelsen, der passerer abstraktion, skjuler underliggende tilstandsændringer, der kan bruges til implementering af afsendelse af meddelelser.


Distribueret eller asynkron beskedoverførsel har ekstra omkostninger i forhold til at kalde en procedure. Ved meddelelsesoverførsel skal argumenter kopieres til den nye meddelelse. Nogle argumenter kan indeholde megabyte data, som alle skal kopieres og overføres til det modtagende objekt.

Traditionelle procedureopkald adskiller sig fra meddelelsesoverførsel med hensyn til hukommelsesbrug, overførselstid og lokalitet. Argumenter videregives typisk til modtageren af registre til generelle formål, der ikke kræver yderligere lagring eller overførselstid, eller i en parameterliste, der indeholder argumenternes adresser (et par bits). Adressepassage er ikke mulig for distribuerede systemer, da systemerne bruger separate adresserum.

Web- browsere og webservere er eksempler på processer, der kommunikerer med besked-forbifarten. En URL er et eksempel på henvisning til en ressource uden at afsløre procesinternt.

Et opkald til en subrutine eller metode vil ikke blive afsluttet, før den påberåbte beregning er afsluttet. Asynkron meddelelsesoverførsel kan derimod resultere i, at et svar ankommer et betydeligt tidspunkt efter, at anmodningsmeddelelsen blev sendt.

En meddelelsesbehandler vil generelt behandle meddelelser fra mere end én afsender. Det betyder, at dets tilstand kan ændre sig af årsager, der ikke er relateret til adfærden hos en enkelt afsender eller klientproces. Dette er i modsætning til den typiske adfærd for et objekt, hvorpå metoder påberåbes: sidstnævnte forventes at forblive i samme tilstand mellem metodeopkaldelser. Med andre ord opfører meddelelsesbehandleren sig analogt med et flygtigt objekt .

Matematiske modeller

De fremtrædende matematiske modeller for meddelelsesoverførsel er Actor -modellen og Pi -beregningen . I matematiske termer er et budskab det eneste middel til at overføre kontrol til et objekt. Hvis objektet reagerer på meddelelsen, har det en metode til denne meddelelse.

Alan Kay har argumenteret for, at meddelelsesoverførsel er vigtigere end objekter i OOP, og at objekter selv ofte er overbetonede. Den levende distribuerede objekter programmeringsmodel bygger på denne observation; den bruger begrebet en distribueret datastrøm til at karakterisere adfærd for et komplekst distribueret system med hensyn til meddelelsesmønstre ved hjælp af specifikationer på højt niveau i funktionel stil.

Eksempler

Se også

Referencer

Yderligere læsning

eksterne links