Un editor -abonat sau un pub / sub este un model comportamental de proiectare a mesajelor în care expeditorii de mesaje, numiți editori , nu sunt legați direct de abonați prin .codul de mesagerie În schimb, mesajele sunt împărțite în clase și nu conțin informații despre abonații lor, dacă există. În mod similar, abonații se ocupă cu una sau mai multe clase de mesaje, făcând abstracție de la anumiți editori.
Modelul editor-abonat este o extensie a modelului observator care adaugă o descriere a unui canal de eveniment special conceput pentru notificarea evenimentului [1] .
Modelul editor-abonat, împreună cu conceptul asociat de coadă de mesaje, face parte din setul de instrumente middleware bazat pe evenimente a unui sistem mare. Majoritatea sistemelor de mesagerie acceptă atât un model de publicare-abonare, cât și o coadă de mesaje în API -ul lor. Un exemplu de astfel de sistem ar fi Java Message Service (JMS) [1] .
Acest model oferă o scalabilitate mai mare și o topologie de rețea mai dinamică .
Într-un model editor-abonat, abonații primesc de obicei doar un subset din toate mesajele publicate. Procesul de selectare a mesajelor pentru a le primi și de procesare se numește filtrare . Există două forme principale de filtrare: bazată pe subiect și bazată pe conținut .
Într -un sistem bazat pe subiecte , mesajele sunt publicate în „subiecte” sau conducte logice denumite. Abonații din astfel de sisteme vor primi toate mesajele publicate în subiectele la care s-au abonat, iar toți abonații care se abonează la același subiect vor primi aceleași mesaje. Editorul este responsabil pentru determinarea claselor de mesaje la care sunt abonați abonații.
Într -un sistem bazat pe conținut , mesajele sunt livrate abonaților numai dacă atributele sau conținutul acestor mesaje sunt acceptate de către abonat. În acest sistem, abonatul este responsabil pentru clasificarea mesajelor.
Unele sisteme sunt un hibrid între cele două: un editor trimite mesaje la un subiect, în timp ce abonații înregistrează un abonament bazat pe conținut pentru unul sau mai multe subiecte.
În multe implementări ale modelului editor-abonat, editorul trimite mesaje unui intermediar, care poate fi un broker de mesaje sau un autobuz. Într-un astfel de caz, abonații înregistrează un abonament la acest broker de filtrare. Brokerul realizează de obicei stocarea și redirecționarea mesajelor pentru a direcționa mesajul de la editor la abonat. În plus, un broker poate prioritiza mesajele într-o coadă de mesaje înainte de a le direcționa.
Abonații se pot abona la anumite mesaje în timpul codării, în timpul inițializării aplicației sau în timpul rulării. Pe sistemele cu o interfață grafică de utilizator, abonații se pot abona manual folosind comenzi (cum ar fi apăsarea unui buton). Unele cadre și software folosesc fișiere de configurare în format XML sau JSON pentru abonament , astfel de fișiere sunt citite în timpul inițializării. Alte sisteme software pot adăuga sau elimina un abonament în timpul rulării, cum ar fi declanșatoarele de baze de date sau RSS .
Majoritatea sistemelor în timp real distribuite DDS nu folosesc brokeri. În schimb, fiecare editor și abonat împărtășesc metadate unul despre celălalt. Editorul și abonatul memorează aceste informații în cache local și direcționează mesajele pe baza acestor informații.
Modelul editor-abonat a fost prezentat pentru prima dată public în 1987 de către Association for Computing Machinery (ACM) la Operating Systems Principles Symposium de la SOSP '87, în articolul „Aplicarea sincroniei virtuale la sistemele distribuite. 123-138” [2] ca parte a subsistemului de știri Isis Toolkit.