David Wallace Croft
Senior Software Architect
Architecture and Research Group
VerticalNet, Inc.
2000-02-18
Clients selectively choose which objects they read and take by using template matching.
A "tuple" can be thought of as a set of attributes to be used as a template for matching.
Example: (category=sci_fi_books, author=heinlein, year=any)
Tightly coupled communication, as opposed to space-based communication, is said to require a "rendezvous" in that a sender must know the receiver's location and both sender and receiver must be available at the same time.
Contrast this with the "anyone, anywhere, and anytime" communications between tuple space agents.
A "bag" is an unordered collection of objects which may contain duplicates.
The "master" process deposits task entries into one or more "task bags".
One or more "worker" processes take these tasks out of the task bags, perform the tasks, and then write results entries to the "result bags".
A familiar example of this is when multiple customers stand in a single line to be served by the next available bank teller or ticketing agent. Given that the bags are unordered and selection is by template matching, however, a better analogy may be a milling mob crowded up against the counter in which the worker agents choose their next customer based upon individual preferences.
Regardless, we know from multiprocessor queueing theory that this architecture has inherent advantages in load-balancing and in minimizing average response time. To understand this, contrast this with a round-robin approach in which each worker has its own queue. If any one worker takes an unusually long time to process an entry, such as when a price check is needed or the checker is extremely slow, the delay is added to all of the entries currently in that queue. With a single queue and multiple workers, however, any individual delay does not have the multiplicative effect.
Notice that this master-worker pattern also easily supports problem decomposition. For example:
The "Computation/Communication Ratio" indicates whether this replicated-worker pattern is appropriate. If a low ratio cannot be increased by adjusting the amount of computation between successive communications, a uniprocessor approach may be more efficient.
public interface Command
{
public void execute ( );
}
Because objects containing both code and data can be transmitted, workers do not need specialized knowledge of the content, in effect becoming simple mobile agent hosts.
Equivalent to a reverse auction:
In the Blackboard pattern, a group of specialists observes the space of entries and then performs add, erase, or update operations until a solution to a problem is found.
In the field of Artificial Intelligence (AI), "Production Systems" are used to perform logical operations.
"Production Rules" can be thought of as symbolic "if...then..." rules.
Example: if A is true and B is false then C is true.
Like an AI Production System, Blackboard Architectures are used to search for solutions to problems [Luger 1993].
Unlike Production Systems, such knowledge is distributed amongst "knowledge sources".
Just as a Production System might trigger a logical rule under a certain state to create a new state, Blackboard Agents may react to messages written to a blackboard and write new messages.
Tuple Spaces evolved from early Blackboard Architecture research within the field of AI [IBM].
With Tuple Spaces, the rules and state can be extremely dynamic as the set of "knowledge sources", or agents, that participate can be extremely dynamic.
Spaces use persistent memory to enable restart.
Distributed transactions permit commit and rollback operations.
Agents can communicate with other agents that may be temporarily offline due to network failure by depositing messages within the space. This is true even when access to the space itself is sporadic.
Spaces and agents may be mirrored.
Agents use space-side filtering mechanisms to throttle the number of messages that they receive.
Acting as a queue, a space facilitates an inherent load-balancing mechanism that is superior to yet simpler than weighted round-robin approaches.
More agents can be added simply by activating them. They could immediately locate the nearest Tuple Space automatically and begin participating.
Agents may be created and die over time without requiring a system-wide restart.
Mobile agents may use a space to communicate with each other during their intermittent connections.
Agents interact through the space medium without requiring knowledge of the addresses of other agents. This is especially useful when such addresses are dynamic due to agent mobility or fluctuating availability.
Messages are said to be persistent through both space and time in that they can cross the boundaries of virtual machines and are stored for communicating with future agents which may not currently exist.
Messages within a space can be programmed to fade away after a given duration.
Unrestrained agent activity may deplete the resources of a space.
As all communications must be encapsulated as finite-length messages before transmission, a stream-based approach may be better suited for some applications.
If mobile code is used with remote clients when passing objects through a space, it is a security risk.
The serialized objects in the space are passive, like read-only messages. Their methods may not be invoked and their values may not be changed. Instead, clients manipulate downloaded copies of these objects.
JavaSpaces implements object selection by matching both class and public instance variables against a template object.
An entry object in a JavaSpace matches a template object by class if the entry is an instance of the template class. This provides a form of template polymorphism.
The second test is whether the public instance variable values match. A null value in the template object is considered to be a "wildcard" slot, i.e., anything is permissible.
In a way, it seems like we have come full circle. AI created the concepts of "frames" and "slots" which used pattern matching through symbol substitution over tuples to fire rules. Frames and slots were adopted in the form of "objects" which led to "object-oriented programming". JavaSpaces is the object-oriented approach to tuple spaces.
JMS permits object selection using an SQL subset over the message header attribute values whereas JavaSpaces does not. This permits ranged selection.
Examples [Bea Systems 1999]:
salary > 64000 and dept in ('eng','qa')
(product like 'WebLogic%' or product like '%T3') and version > 3.0
hireyear between 1990 and 1992 or fireyear is not null
fireyear - hireyear > 4
JMS permits messages to be stored within persistent memory until all registered subscribers have connected and received them or until a given timeout is reached and they are discarded. The subtle difference between this and the lifecycle of objects within a JavaSpace is that the number of interested recipients is unknown to a JavaSpace. While not attempted at the time of this writing, it may be possible for a JMS agent to duplicate the capability of a JavaSpace agent to communicate indirectly with currently non-existent future agents by registering a dummy recipient that will never actually receive the messages. The messages would then persist until the timeout, possibly allowing agents that were created long after the initial transmission of such messages to receive them.
JavaSpaces supports the operation "write" and the pattern-matched operations "read", its asynchronous counterpart "notify", and "take". Unlike JavaSpaces, JMS does not provide the destructive read operation "take". This may not be disadvantageous, however, as the "take" operation introduces difficulties in an untrusted agent environment. Rather than simply removing a message from a tuple space, it may be more appropriate for an agent that wishes to act exclusively on the message to negotiate this with the sending agent. For example, instead of simply removing a task message so that no other worker agents could read and act upon it, a worker agent that wanted to perform the task would submit a bid message to be approved by the master agent. The master agent would then allow its original task message to expire only after it had negotiated with and made a selection from some number of worker agents.
Both JavaSpaces and JMS support distributed transactions. JavaSpaces uses the Jini transactions API while JMS uses the J2EE transactions API. There is a rumor that the plan for integrating overlapping J2EE and Jini/JavaSpaces technology will be described at JavaOne 2000.
Some MOM systems implement the JMS API in addition to other APIs for legacy programming languages. This allows Java agents to interact with non-Java agents via the MOM. As the JMS API supports text-based in addition to serialized object message bodies, a JMS MOM implementation can be used to ensure reliable message transport across heterogeneous programming language systems with the message content in portable XML. In the future, we can also expect to see heterogeneous vendor communications via standardized XML for the message wrappers with associated protocols [Cover 2000].
| Feature/Implementation | JavaSpaces | JMS |
|---|---|---|
| Message Selection by Range | N | Y |
| Mobile Code | Y | Y? |
| Leases | Y | Y* |
| Distributed Transactions | Y | Y |
| Asynchronous Transmission | Y | Y |