CosEventChannelAdmin(3)

๐Ÿ“ฆ
version 5.2.2 ยท 2 versions
, in fedora 43, fedora 44

๐Ÿ’– CosEventChannelAdmin ๐Ÿ’–

okay bestie, welcome to CosEventChannelAdmin โ€” it's an Erlang module, section 3 of the manual, and it's literally the blueprint for the whole OMG COSS event service vibe. โœจ


๐ŸŒธ NAME ๐ŸŒธ

CosEventChannelAdmin โ€” the way this defines a set of event service interfaces that enables decoupled asynchronous communication between objects, and implements the generic (untyped) version of the OMG COSS standard event service. no cap. ๐Ÿ’…


๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

so the event service gives objects exactly two roles, and honestly it's giving main character energy for both:

  • the supplier role โ€” suppliers supply event data to the event channel
  • the consumer role โ€” consumers receive event data from the channel

and here's the iconic part: suppliers do not need to know the identity of the consumers, and vice versa. mutual mystery, mutual respect, zero codependency. ๐Ÿซถ

consumers and suppliers get connected to the event channel via proxies, and those proxies are managed by ConsumerAdmin and SupplierAdmin objects. the admins are the ones running the group chat, fr fr.


๐ŸŒˆ the four general models of communication ๐ŸŒˆ

there are four, and yes you need to know all of them, don't skip:

  • The canonical push model. It allows the suppliers of events to initiate the transfer of event data to consumers. Event channels play the role of Notifier. Active suppliers use the event channel to push data to passive consumers registered with the event channel. ๐Ÿ‘‘
  • The canonical pull model. It allows consumers to request events from suppliers. Event channels play the role of Procure, since they procure events on behalf of consumers. Active consumers can explicitly pull data from passive suppliers via the event channels. โœจ
  • The hybrid push/pull model. It allows consumers to request events queued at a channel by suppliers. Event channels play the role of Queue. Active consumers explicitly pull data deposited by active suppliers via the event channels. ๐ŸŽ€
  • The hybrid pull/push model. It allows the channel to pull events from suppliers and push them to consumers. Event channels play the role of Intelligent agent. Active event channels can pull data from passive suppliers to push it to passive consumers. ๐Ÿงš

๐Ÿ’œ how to get access to all the definitions ๐Ÿ’œ

to get access to all definitions, e.g., exceptions, include the necessary hrl files by using:

-include_lib("cosEvent/include/*.hrl").

literally just drop that in and you're set. ๐Ÿ“


โญ the seven different interfaces supported in the service โญ

there are seven, and here's the full lineup, no gatekeeping:

  • ProxyPushConsumer
  • ProxyPullSupplier
  • ProxyPullConsumer
  • ProxyPushSupplier
  • ConsumerAdmin
  • SupplierAdmin
  • EventChannel

and that's the whole page, bestie โ€” every role, every model, every interface, all seven of them, accounted for. ๐Ÿ’–

this little love letter to decoupled async communication comes to you from Ericsson AB, and it's cosEvent 5.2.2 โ€” so go forth, wire up your proxies, and slay. ๐Ÿ’…โœจ

๐Ÿ“ฆ where this page comes from