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.
xpidl is a tool for generating XPCOM interface information, based on XPIDL interface description files. It is based on the GNOME library for ORBit, libIDL.
The Ensemble Distributed Communication System
A distributed communications system implemented in ML. Based on The Horus Project, the point of the exercise is to provide a generalization of TCP communication to groups of processes.
DCOP: Desktop COmmunications Protocol
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 has learned from the usage of CORBA by GNOME and DCOP by KDE . One of the major "use cases" is for policies that require an "interact with user" component.
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.
This is a "distributed objects" system for C++ ; by eschewing portability across languages, they can produce something smaller than CORBA .
Two Cardinal Sins of REST API Design: Lessons you can Learn from the NewsGator REST API
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."
Synchronous Interprocess Messaging Project for LINUX (SIMPL)
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
efficient fashion.
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
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.
IBM MQSeries: Introduction for SAP Consultants
Oracle Advanced Queuing AQ FAQ
It can communicate with IBM MQSeries and the Java JMS, and stores messages in the (hopefully robust!) Oracle database.
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
Progress SonicMQ - a fast, fully JMS compliant Internet messaging server.
Useful Asynchronous Events and Messaging Middleware Research Links
XmlBlaster- Java and CORBA -based Open Source MOM system; also supports C and C++
"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 - Multi User Server Client Linkage
Environment
The 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
support. 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
Spread
:
Ada Binding for Spread - for the Ada link.
Anasazi - Let's reimplement the wheel... or at least another GCS
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...
zeromq: Fastest. Messaging. Ever.
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 basic "Distributed Object" system for use with Python . Fairly similar to Java RMI
RMI - Remote Method Invocation
A way of invoking Java objects remotely.
The Castor Project provides integration tools to represent Java objects in a persistent manner, storing them assortedly as XML , JDO , and LDAP.
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.
Embedding RPC structures as XML, transmitted as an HTTP-POST request
Several additional implementations have sprung up:
XMLRPC-C - XML-RPC library for use with C /C++
A lightweight RPC library based on XML and HTTP. Also includes an XML-RPC HOWTO that demonstrates examples of the use of XML-RPC in a variety of languages including Perl, Python , C, PHP .
CapnRPC - XML-RPC for PLT Scheme
Framework for XML-RPC in Objective-C . Uses EDCommon
/ EDInternet
, framework extensions for Foundation
and AppKit
.
developerWorks: XML zone : XML Matters: XML-RPC as object model
IBM Application Development:XML Metadata Interchange Format (XMI)
OMG MOF (Meta Object Facility)
XMI ( XML Metadata Interchange) allows metadata conforming to strict metamodels to be encoded as XML documents. The specification has two main parts:
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.
O'Reilly Network: Meerkat: An Open Service API [May. 09, 2000]
O'Reilly Network: Meerkat: The XML-RPC Interface [Nov. 14, 2000]
Python modules to transmit XML-RPC messages via Spread and Jabber.
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:
G-Wrap is a portable tool for easily importing types, functions, and constants from C into Scheme interpreters. As of version 0.8.0, G-Wrap supports both Guile and RScheme.
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.