If it's not blatantly obvious, I value the Actor Framework (AF) as an important part of my toolkit. It's not the right tool for every job, but it is a useful tool for many. One part of the AF I don't love is the necessary tedium of building Actor Core event-handling UIs and then dragging reference controls (for my by-reference updates) into the Class Private Data Cluster. This got me thinking... In general, adding controls to a class feels like a relatively clumsy process, even when not using the AF. I let this mild frustration stew inside my melon for years, and then I finally did something about it.
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.
Delving into the world of asynchronous and concurrent programming can be quite daunting these days. There is a deluge of jargon and hip new libraries to learn as a newbie. At times, it feels like the difficulty in navigating these rough waters might rightly be interpreted as a dire warning: BEWARE THEE WHO DOES NOT KEEP HIS PROMISES. But what is a promise anyway? And for that matter, what is a future? Or a continuation? And here I thought I was in over my head when I started threading...
While I won't even try to completely illuminate these topics in a single blog post, I hope to provide a straightforward explanation that can help a beginner navigating the waters of asynchronous programming. Really, once you get past the nomenclature, these programming constructs are REALLY interesting and useful.
I recently gave a presentation at a local user group on message transport abstraction and how it can be used to abstract communication between actors running in LabVIEW and thin clients running in web browsers. During the presentation an interesting question came up regarding why I chose to make communication between my actors data centric instead of message centric. This question triggered a lot of thinking on my part and after a few days of rumination I decided that a blog post on the topic was warranted.