MICA can be compared with many other systems; since the problem MICA addresses -- storage and communication, are two of the universal problems in computer science. To help show how MICA fits in with these alternatives, it is compared here with existing systems.
MICA can be thought of as a database, in fact, to be accurate, an object-oriented active database. It is object-oriented, because objects can be stored directly in the database, and active, because active databases support the execution of code under certain conditions when the database changes. When clients write objects to the blackboard, this can be thought of as writing a record to a table in a database. Similarly for reading, deleting and querying.
The important difference is the way that MICA conveys information about changes to the database to interested third parties; who wish to be informed about whatever changes occur to a database.
There are to our knowledge, no active object-oriented databases particularly ones that communicate information of changes to the database.
Another way to think of MICA is as a publish/subscribe model of interaction (like the InfoBus architecture), or an Observer pattern in languages like Java or as a content-based routing system (such as elvin).
The main difference between MICA and such systems is that MICA integrates storage into such an architecture. Though this change seems small, it does actually have some significant implications.
The popularity of XML-based web services has increased dramatically over the last few years; but really they are examples of general remote procedure calls systems.
The main differences compared to MICA are that these systems are "one-way" -- queries are launched by clients to the server, and the client gets a response; and secondly, that there is no inherent storage capability built in -- though it would be possible to build one.
Having said that, it would be possible to implement MICA as a two-way web service. It would be messy, but possible.
CORBA could be used to implement a MICA service; however, CORBA is incredibly complex and this would be like implementing a simple counter with a Pentium processor. Further, though the protocol supports more advanced forms of interaction than the client-server protocol mentioned above, such features are rarely implemented in CORBA systems.
MICA can be considered a type of agent architecture. Compared to most other agent architectures, however, it is much simpler. MICA is like an agent architecture where the only elements allowed in the agent communication language are objects.
Having said that, it is easy to interface non-MICA agents to MICA. For comparison, we compare it to a popular agent architecture: SRI's Open Agent Architecture.
In many ways, MICA is a simplified form of OAA. MICA could be implemented using OAA, but it would be like trying to build a lower level abstraction on a higher one -- possible, but for serious work, you want a clean implementation. There are also a few other differences in security and data model.
OAA has a "facilitator" agent that manages interaction between different agents. In MICA, this is the blackboard manager. OAA uses the idea of "solvables"-- things or queries that can be resolved. So an agent in OAA says that it provides a certain solvable to the facilitator. In MICA, solvables correspond pretty closely to objects. In MICA, an agent tells the blackboard to inform it of particular objects it is interested in.
The main differences are:
MICA has no backtracking across agents to solve problems; whereas in OAA, you can post compound goals to the facilitator, which will then employ depth-first and/or breadth-first search to fulfill those goals. For example, in OAA, if you tried to make an enquiry like "Get me Bill Smith's manager's phone number" you could say:
(R is the return value here, and M is an
"intermediate" variable) The "manager" solvable might be handled
by one agent, and the "fax" solvable might be handled by two
different agents, each with access to different fax numbers.
Backtracking would allow this to be done seamlessly.
OAA's security model is agent-based; ie. "only the agents I specify can use my solvables". MICA's is object-based, i.e. "this particular object should not be visible to this agent". The blackboard manager in informing agents or responding to their queries, has a policy expressed as a function of the agent to which the object is to be delivered and the object itself.
MICA uses object inheritance to model objects on the blackboard; OAA can use any data structure supported by ICL (which is basically Prolog).
OAA uses "procedural solvables" and "data solvables" -- the MICA equivalent for both of these is an Object.
OAA specifies four different types of triggers: data triggers (tell me fact X), communication triggers (tell me when agent X talks to agent Y about Z), timed triggers (tell me every 5 seconds) and task triggers (tell me when someone wants to do X). MICA has one trigger only: tell me when an class X or one of its subclasses appears on the blackboard.