The notable predecessor to CORBA was DCE; Microsoft's COM system, their nearest equivalent to CORBA, was originally based on DCE.
DCE is now available as open source under the LGPL
XPCOM is a (built-for-Mozilla ) mimic of COM. Instead of mimicking Microsoft's nonstandard MIDL compiler, this uses a CORBA-compliant IDL compiler, XPIDL. It doesn't provide an RPC scheme; it really is intended for communicating between components within a process.
This is used by the KDE project for local IPC.
D-BUS is a message bus system, a simple way for applications to talk to one another. D-BUS has no required dependencies, but includes Glib, supporting gtk , Qt , Python and .NET APIs to the D-BUS system, if you want to build those. The list of projects using D-BUS is growing and they provide a wealth of examples of using the various APIs to learn from.
It is intended to allow low latency, avoiding round trips and allowing asynchronous operation. It is low overhead, using a binary protocol (unlike XML-based systems like XML-RPC and SOAP). By using "messages" rather than byte streams, this eliminates a lot of the tough IPC issues, and is designed to make it easy to use some common existing object/type systems.
Some of the makers of CORBA implementations have released a CORBA-like middleware system that offers a simpler threading model, asynchronous method invocation and dispatch, batched invocations, multiple transports, complete with cleaner C++ memory management.
It appears to be an attempt to create a CORBA successor that learns from CORBA whilst not shackling itself by trying to be compatible with it.
There are a variety of libraries available for managing message queues on Linux. The following list orders implementations roughly in the order of how "heavyweight" the implementations appear to be, from the SystemV "message queue" implementation found in the Linux kernel to some Java-based implementations that might represent "monstrosities."
Providing an IPC mechanism similar to QNX Syncronous/Asyncronous messaging.
Introduced in FreeBSD 5.0,
kqueue() provides a generic method of notifying
the user when an event happens or a condition holds, based on the
results of small pieces of kernel code termed filters. An kevent is
identified by the (ident, filter) pair; there may only be one unique
kevent per kqueue.
Applications need to be notified when an event occurs, or a
specific condition holds.
Kqueue provides a
standard API for applications to register their interest in various
events/conditions and have the notifications for these delivered in an
Isectd Message-Oriented Middleware Uses the GPL
Ivy is a simple protocol and a set of libraries that allows applications to broadcast information through text messages, with a subscription mechanism based on regular expressions. Ivy libraries are available in C, C++, Java and Perl, on Windows and Unix boxes and on Macs. Several Ivy utilities and hardware drivers are available too.
OpenQueue is consciously reminiscent of IBM MQSeries, providing a messaging system that provides a socket-based interface. At this point, the server software is implemented in Java , using MySQL™ for persistent data storage.
Implementation of MQSeries, more recently reimplemented by Microsoft as their MSMQ system. Falcon MQ allows various Unixes to connect to Microsoft's MSMQ.
Level 8 have versions for Linux, SCO, HP/UX, AIX, VMS, Digital Unix, Solaris, AS/400, Tandem.
Note: This product requires that a host running Windows NT 4.0 and Microsoft MSMQ is present.
Ten Commandments of MQSeries
Thou shalt not use a queue as a database.
Thou shalt backup your pagesets, filesystems, and logs.
Thou shalt routinely apply maintenance to your MQSeries systems.
Thou shalt use MQCLOSE and MQDISC when terminating an application.
Thou shalt not use MQGET with WAIT UNLIMITED without specifying MQGMO_FAIL_IF_QUIESCING.
Thou shalt not create objects with long, drawn out names.
Thou shalt create standard naming conventions.
Thou shalt provide systems management tools for administrators and users.
Thou shalt not create an MQSeries network without mapping out all connections and object relations on paper first.
Thou shalt not attempt to apply asynchronous methods to all problems simply because MQSeries is a wonderful product.
MessageQ.Com - Communications Middleware Lots of Whitepapers
Publish-and-Subscribe describes a software architecture where individual applications, both information providers and information consumers, define the information they can deliver or wish to receive.
BeOS does "pervasive messaging," as described below. Since it is so available, provided as a basic OS service, it is used everywhere, and reportedly represents one of the ways that BeOS is able to provide extremely fast user interaction. In an application, the programmer hardly ever writes code that waits for the user to do something; it merely queues requests...
So messaging, the way applications, the way we communicate with each other, the main way we use to communicate in the BeOS is the BMessage, because our messaging architecture is so pervasive, it's all throughout our interface kit, et cetera, it's really easy to do scripting using that, the same messaging architecture.
A messaging scheme intended to support thread-to-thread messaging atop IP, but independent of TCP and UDP.
Java Message Queue software implements the industry standard Java Message Service (JMS) 1.0.1 specification, which provides a standardized API and common messaging strategies for developers. Java Message Queue software supports traditional, address-based queues for message delivery, but also includes the speed and flexibility of the asynchronous Publish and Subscribe message delivery model. In this model, messages are routed and delivered based on the properties of the message, not on an address or location. Client processes simply register an interest in a particular topic, allowing Java Message Queue software to intelligently and efficiently handle all the communication needs between application components.
A free implementation of the Java Messaging Service
"Plumbing" is a message queueing system for Plan9 The design of the plumbing system is peculiar: a centralized language-based file server does most of the work, while compared to other systems the applications themselves contribute relatively little. This architecture is deliberate, of course.
Plumbing's rule language uses only regular expressions and a few special rules such as isfile for matching text. There is much more that could be done. For example, in the current system a JPEG file can be recognized by a .jpg suffix but not by its contents, since the plumbing language has no facility for examining the contents of files named in its messages. To address this issue without adding more special rules requires rethinking the language itself. Although the current system seems a good balance of complexity and functionality, perhaps a richer, more general-purpose language would permit more exotic applications of the plumbing model.
J. Paul Morrison worked on various "flow-based" systems at IBM over the last 30-odd years, and has written a book describing this paradigm. This excerpt, entitled Cognates, describes various existing systems programming schemes that parallel this, notably the notions of Unix streams, where data can flow in parallel from process to process, as well as message queueing systems like IBM MQSeries, where flows are parallelized by submitting work into asynchronous "work queues."
MUSCLE system is a robust, somewhat
scalable, cross-platform client-server solution for dynamic
distributed applications under any POSIX-compliant operating system.
Originally built for BeOS.
Spread is a toolkit that
provides a high performance messaging service that is resilient to
faults across external or internal networks.
Spread functions as a unified message
bus for distributed applications, and provides highly tuned
application-level multicast and group communication
Spread services range from reliable message
passing to fully ordered messages with delivery guarantees, even in
case of computer failures and network partitions.
There are bindings to several languages:
Several interesting projects are already using and extending
Unfortunately, Spread doesn't scale, at least not when you try to use it for particularly high load tasks. It was designed as an academic system, not as a high grade "production" system; there is merit to creating something intended for heavy duty usage...
A project to build an AMQP "kernel" designed to maximize performance (in several ways, depending on strategy).
A persistent message queueing implementation created by LinkedIn, implemented in "Java".
A reliable, persistent message queueing system implemented in 1
MQTT was developed by IBM as a publish/subscribe protocol for remote sensors and control devices through low bandwidth, unreliable or intermittent communications.
Patterned after NeXt Distributed Objects; uses Objective C
A way of invoking Java objects remotely.
A distributed object system for Python. It includes a Name Server, Event Service, mobile objects, remote exceptions, dynamic proxies, automatic reconnection, and such...
Several proposals have come out whereby XML messages are layered atop some messaging scheme.
Several additional implementations have sprung up:
A set of production rules for producing an XML DTD from any metamodel specification.
A parallel set of production rules for producing an XML document conforming to the DTDs from a model (i.e. a collection of metadata) that conforms to the above metamodel.
Appendices to the specification include example XMI generated DTDs for the interchange of UML models and MOF metamodels.
By basing XMI on XML , we provide implementors with an easy path into the world of metadata-based systems. An application does not need to "speak" CORBA to use XMI.
By basing XMI on the metamodelling technology of the OMG's Meta Object Facility, we make it feasible to avoid the effort of hand-crafting DTDs and the corresponding document producer/consumer software. The MOF/XMI framework can support and integrate all kinds of metadata and can be extended at will.
For those looking to bind themselves to whatever Microsoft will allow them to do today, DCOM is a "reasonable" alternative to CORBA.
An important issue when working with multiple languages can be to try to invoke code written in one language when writing code in another language.
C is commonly used as a "lowest common denominator" in this regard; there are a number of other options as well:
SWIG Simplified Wrapper and Interface Generator
SWIG provides a way of easily connecting C and C++ code to the Python, TCL, Perl, and Guile interpreters. This allows one to link in highly optimized compiled code to add operators/functions that are much faster than they would be in interpreted form, as well as the possibility of linking to existing code written in or linkable to C/C++ code.
ASN.1 is for sending messages across a network. Each time a message is sent over the network, it will be ASN.1-encoded at the sender, and ASN.1-decoded at the receiver. So you need to add code to do the encoding and decoding. You can do this by hand, or have an ASN.1 compiler do it for you.
Informally, ASN.1 notation is something like a BNF grammar language. You have terminals and non-terminals, and a start symbol. ASN.1 is somewhat less abstract, however; this is important, because the need for interoperability is stronger for message passing than it is for programming languages. In addition, ASN.1 also comes with rules on how to encode messages that conform to a given ASN.1 notation.