|
In my last post I took a look at data-centric and message-centric communication and their effects on software systems. This post will take that discussion a little bit further by connecting the idea of data-centric messaging to Event Driven Architecture (EDA). Along the way, we will build up a vocabulary that we can use to disucss systems of actors and the types of coupling we encounter while building them.  In the post on Data-Centric vs Message-Centric Communication, we considered how message-centric communication couples the information being sent between two actors with how the receiving actor handles the information. Specifically, we took a look at the Actor Framework and how its use of the command pattern implied that each message class would call one of the recieving Actor's methods. We then compared the Actor Framework to a data-centric implementaiton of inter-actor communication. We finished by describing how message-centric communication typically sends verbs, while data-centric communication typically updates nouns. That data-centric communication example was an example of EDA where the updating of nouns is analogous to the publishing of events.  In an effort to build up a common vocabulary, I will refer to actor systems that rely on command and query messages rather than events as Imperative Actors. Actor Framework Actors are Imperative Actors by definition because their message execution is based on the command pattern.  We can call actors that use data-centric communication mechanisms Reactive Actors because they react to events being raised by other actors in the system. The basic system model for for this type of interaction between actors relies on an event notification service providing storage and management for subscriptions and efficient delivery of events. In previous discussions, we have seen how an implementation of the mediator design pattern solves this problem. We can build a system of Reactive Actors using an EDA where the publishers of events do not hold references to the subscribers, nor do they know how many subscribers are participating in the interaction. Similarly, the subscribers do not hold references to the publishers, nor do they know how many of publishers are participating in the interaction. This inversion of communication dependencies leads to very loosely Reactive Actors.  The event-based interaction paradigm is based on decoupling producers and consumers of events. The main advantage of decoupling the production and consumption of events is an increased scalability in our application as a whole. The three common dimensions of coupling between event producers and consumers are space, time and synchronization.  We can say that two actors are spatially decoupled if they do not need to know about each other in order to communicate. If one actor needs to have a reference to another actor for communication then it can be said that they are spatially coupled. We can accomplish this in an EDA through the use of a mediator that allows publishers to publish events to relevant topics and subscribers to receive notification of events from the topics that they subscribe to.  We can say that two actors are temporally decoupled if they do not need to be actively involved in interactions at the same time. In particular, the publisher might publish some events while the subscriber is disconnected, and conversely, the subscriber might get notified about the occurrence of some event while the original publisher of the event is disconnected.  We can say that two actors are synchronously decoupled if publishing actors are not blocked while producing events, and subscribing actors can get asynchronously notified of the occurrence of an event while performing some concurrent activity. The production and consumption of events do not happen in the main flow of control of the publishers and subscribers, and do not therefore happen in a synchronous manner.  That the leaves the last type of decoupling, semantic decoupling. Event semantic decoupling refers to the requirement that event producing and consuming actors can exchange events without a priori full understanding of, or agreement on the vocabulary used to describe event types, properties, or values. If an event system assumes mutual agreement on event types, properties, and values, this agreement is an explicit dependency between parties.  My current event semantics use a message interface class as an event abstraction. Any subclass of the message interface class can be sent by publishing actors and received by subscribing actors. The problem is that this implementation does not decouple the event semantics; it requires that the publisher and the subscriber agree on the type of the message object. This means that the subscriber actor must always attempt to typecast the message object to the type it expects to receive. There are a few interesting ideas that can be used to help alleviate this semantic coupling, but we would need to talk through implementation detail of the mediator and topic actors first for context. For this reason, I will leave the expansion of this idea for my next post. Jon McBee is the Founder and Managing Partner at Composed Systems and is a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer, Certified TestStand Developer, an NI Certified Professional Instructor, a LabVIEW Champion, and a Certified ScrumMaster
1 Comment
|
Tags
All
Archives
October 2019
LabVIEW Blogs |
RSS Feed
Powered by the Panda Ant
|