两个进程之间如果要做点什么交互的话，总得通过一些机制来实现；这就像我们两个人之间要沟通，总得通过语言、文字等各种机制来实现一样。如果两个进程都在一台机器上，交互的机制就显得稍微多一点，例如可以用 shared memory、message queue、file、pipe、socket 等各种技术。如果两个进程不在同一台机器上，可以的选择显得稍微少一点，但是还可以用 socket 等。如果开发应用时总是要考虑这么底层细节的事情，那效率就太低了。在应用开发的需求牵引下，大家发明了从 RPC、CORBA、RMI，到 SOAP、WebService 之类的不同层次的技术。

最近碰巧遇到了一个 legacy 的应用，需要跨机器的 C 程序与 Java、C、C++ 程序之间的交换。它没有采用流行的 Web 技术，用的还是 C/S 技术。为了在这些不同的进程之间交换数据，要么自己在 socket 等的基础上写自己的应用层协议，要么依靠古老的 RPC 技术，要么借助于失去光彩的 CORBA 技术——这些东西怎么看怎么不爽，一个比一个老。

为了温习一下早就忘光了的 CORBA，找了个简单易懂的例子来参考：A Simple C++ Client/Server in CORBA。可惜它是个 C/C++ 的版本，没体现出 CORBA 跨语言的本事来。