Publish–subscribe
En l'arquitectura del programari, publish–subscribe és un patró de missatgeria on els remitents de missatges, anomenats editors, no programen els missatges perquè s'enviïn directament a receptors específics, anomenats subscriptors, sinó que classifiquen els missatges publicats en classes sense saber quins subscriptors podria haver-hi, si n'hi ha. De la mateixa manera, els subscriptors manifesten interès en una o més classes i només reben missatges que els interessen, sense saber quins editors hi ha, si n'hi ha.[1]
Publish-subscribe és un germà del paradigma de la cua de missatges i normalment és una part d'un sistema de programari intermedi orientat a missatges més gran. La majoria dels sistemes de missatgeria admeten tant els models pub/sub com la cua de missatges a la seva API; per exemple, Java Message Service (JMS).[2]
Aquest patró proporciona una major escalabilitat de xarxa i una topologia de xarxa més dinàmica, amb una flexibilitat reduïda per modificar l'editor i l'estructura de les dades publicades.[3]
Filtrat de missatges modifica
En el model de publicació-subscripció, els subscriptors normalment reben només un subconjunt del total de missatges publicats. El procés de selecció de missatges per rebre i processar s'anomena filtratge . Hi ha dues formes habituals de filtratge: basat en temes i basat en contingut.
En molts sistemes de publicació i subscripció, els editors publiquen missatges a un intermediari de missatges o a un bus d'esdeveniments, i els subscriptors registren les subscripcions amb aquest corredor, deixant que l'agent faci el filtratge. El corredor normalment realitza una funció d'emmagatzematge i reenviament per encaminar missatges dels editors als subscriptors. A més, el corredor pot prioritzar els missatges en una cua abans d'enrutar.[4]
Avantatges modifica
Els editors estan vagament vinculats als subscriptors i ni tan sols necessiten saber de la seva existència. Amb el tema enfocat, els editors i els subscriptors poden ignorar la topologia del sistema. Cadascun pot continuar funcionant de manera normal independentment de l'altre. En el paradigma tradicional de client-servidor estretament acoblat, el client no pot publicar missatges al servidor mentre el procés del servidor no s'està executant, ni el servidor pot rebre missatges tret que el client estigui en execució. Molts sistemes pub/sub desacobla no només les ubicacions dels editors i dels subscriptors, sinó que també els desacoblen temporalment. Una estratègia comuna que fan servir els analistes de middleware amb aquests sistemes pub/sub és eliminar un editor per permetre que el subscriptor treballi amb l'endarreriment (una forma d'acceleració de l'ample de banda).
Desavantatges modifica
Els problemes més greus amb els sistemes pub/sub són un efecte secundari del seu principal avantatge: el desacoblament de l'editor amb el subscriptor.
Referències modifica
- ↑ «Publish-Subscribe Design Pattern: Introduction to Scalable Messaging | HackerNoon» (en anglès). https://hackernoon.com.+[Consulta: 18 febrer 2023].
- ↑ Wickramasinghe, Shanika. «What Is Pub/Sub? Publish/Subscribe Messaging Explained» (en anglès). https://www.bmc.com.+[Consulta: 18 febrer 2023].
- ↑ «Pub/Sub Examples: 5 Use Cases to Understand the Pattern and its Benefits | Ably Blog: Data in Motion» (en anglès). https://ably.com.+[Consulta: 18 febrer 2023].
- ↑ «What is Pub/Sub Messaging?» (en anglès). https://aws.amazon.com.+[Consulta: 18 febrer 2023].