When building a software system composed of multiple decoupled components, the need typically arises for interprocess coordination and communication.
As an example, say that we have a customer requirement that allows emails to be sent based on certain events or conditions that occur while the user is interacting with a web application.
We build an email component that takes care of the details of actually sending of the email. The web application could use the email component directly, but that would introduce a dependency that we’d rather avoid. How can the two processes communicate without creating a dependency between the two?
If you’re using Ruby, there’s an option that is built right into the standard library. The Rinda module implements the Linda distributed computing paradigm in Ruby. That’s great, but what is Linda? Linda is a coordination language developed by a couple of Yale researchers in the early 1990s.
Linda itself is built on the concept of a
tuple is an ordered
list of objects, and a
tuplespace contains a set of
tuple which can
be accessed concurrently. A basic set of operations were defined by the language to allow
reads, writes and takes.
Getting back to the example, how can Rinda be utilized to enable communication between
the web application and the email component? First, a
tuplespace will need to be setup
that both components can access. When a condition arises within the web application that
requires an email to be sent on its behalf, a specific
tuple will be written to the
The email component is looking for
tuple that match a specific pattern. When it finds
tuple written by the web application that matches this pattern, it processes the
request and reports back to the
tuplespace when finished. In this way, we end up
with only data coupling between the two processes, which is a much looser coupling
than a direct dependency. This type of approach bears some resemblance to a
Now that we know a little bit about what Rinda can buy us, let’s dive in and try it out. Let’s put together a simple server and client to demonstrate how each works.
Here’s a simple server (server.rb):
We start by setting the default port to 4000. We then create a new
object. The call to
start_service starts a local dRuby server listening
on port 4000.
tuplespace as the second parameter sets the server’s front object
tuplespace. The URI of the server is output, and the program
waits for a kill signal, and we have a Rinda server ready to be accessed by a client. To start the
Here’s a simple interactive client (client.rb). It allows input to be gathered on standard input, with the form:
We’re using the send method in order to invoke the method specified on standard input. There’s also a conversion between nil as a string into nil proper. This is necessary because of wildcards, which we’ll get to in a minute. With the server running, run the client to start a new session:
Below is a sample session (output is indented for clarity):
The inputs above translate to these method calls:
Note that reads do not remove the
tuple from the
tuple is left untouched such that other clients can access the same
data. This is an important concept when dealing with synchronization that we’ll
return to in a future post.
The structure of the patterns used in the read and take methods deserve some additional
attention. When the
tuplespace is queried through a read or a take, there
are two criteria used to determine if a
First, the length of the
tuple must match the pattern’s length. In the example above,
all patterns are pairs (2-
tuple), so only
tuple that are pairs will qualify.
tuple must match the pattern specified. When specifying a pattern,
nil is used as a wildcard, which will match anything.
Assume that our
tuplespace has the following
If the pattern
[nil] is specified, e.g.
ts.read([nil]), only #1 will match.
If the pattern
[:message, nil] is specified, only #2 will match. Of course,
[:message, “hello”] would also result in #2 matching as well, while
[:message, “world”] would not.
[:message, nil, nil],
[:message, “hello”, nil], or
[:message, nil, “world”] would all result in #3 matching. Remember that
patterns are matched on both length and content of the
We haven’t even scratched the surface of what can be done with Rinda. This introduction only gets the simplest client and server talking to each other. Stay tuned for more.