首先声明,我不知道如何实现一个通用的解决方案,希望感兴趣的朋友讨论一下，下面是我的一些思路，或许会有用途。
了解医疗设备的朋友都知道DICOM协议,通过遵循DICOM协议开发的程序,就可以实现即插即用,我们开发的PACS程序，其他厂商的PACS程序，所有厂家的CT设备，等等，只要遵循DICOM，则都可以通过直接进行通信，可以相互检索数据，相互发送和接收数据，非常容易。
这里讨论的即插即用不是组件级的，而是应用程序级的，确切的说，是系统级的。系统集成是一个非常令人头痛的问题。如果可以实现两个系统直接非常方便的交换数据，则系统继承也就easy了。
我们现在开发了很多的数据库管理系统，如何实现这些程序之间非常简单的通信？DICOM协议采用应答的方式进行通信的，同时规定了的数据实体的基本属性，以及通信数据包的基本结构，DICOM是针对医疗设备的，我们是否可以定义一种协议，是针对某种对象的，我们可以定义对象的基本属性，例如，我们规定病人的基本信息包括那些字段，每个字段的类型是什么，每个字段的长度是多少，含义是什么，我们规定职工管理程序中，职工包括哪些字段，每个字段的基本属性是什么，有了这些规定之后，我们每个人开发数据库管理软件时就可以参考了。如果能够将各种各样的对象的描述信息编制成XML文档，并且提供在网站上下载，然后通过响应的工具在某个数据库中生成数据表。这样，这些标准的定义过程（在数据库中创建表）将非常简单。DICOM定义对象（例如病人和图像等）的类型很好，但是我们必须辛苦的阅读DICOM协议才可以了解这些对象，然后手工编写代码创建图像。
有了上面的定义，至少我们可以很方便的在创建数据库时，保证每个人创建的数据表结构是一致的，从而，数据的存储格式是一直的。如果我们再规定一种应答的通信机制，那么实现每个数据库应用程序之间的通信应该不是问题。这些定义保存在一个叫www.uniobject.net的网站上（当然这个网站还不存在，我不知道是否有这个样的一个网站），我们假设UniObject就是我们的标准化协议。
例如，当应用程序A访问应用程序B，他们会进行如下的交流：
A：你是谁？我的名字是A。
B：我的名字是B，很高兴遇到你，我们通讯录中有你的名字。（A可能是朋友列表中，也可能是黑名单上，假设在朋友列表中）我能够为您做点什么？
A：非常感谢您的热心，请问您哪里有关于“机车”的资料吗？（“机车”是uniobject网站上定义的对象名称，是一个标准的关键词）
B：有的，您希望哪个“机车”的资料呢？
A：我只知道该”机车“的”名字“。（机车的“名字”也是uniobject上关于“机车”对象的一个属性）
B：哪就将这个“机车”的“名字”发送过来吧。
A：好的。（将“名字”按照UniOpject上规定的格式封装成XML格式的字符串，发送给了B，可能是通过Socket，也可能是通过.Net Remoting），机车的名字是“青藏车”，我想了解一下青藏车的情况。（“青藏车”是UniObject上定义的“机车”对象的“名字”属性的值）
B：您的运气不错，关于“青藏车”的资料找到了12条，我现在发送给您。（将数据按照UniObject网站上的规定打包，按照一种默认的通信方式发送给A）
A：太谢谢您了，我现在要处理这些数据了，为了方便以后的联系，您可以保留我得几种联系方式，将来如果需要我的帮助，可以发送电子邮件（UniObject规定了系统通信的电子邮件格式），发送IM信息（UniObject规定了数据的格式，所有遵循UniObject的系统都可以识别），或者直接跟我建立连接（UniObject规定两个系统直接可以直接Connect，如果一方不存在，则返回规定的提示信息）都可以。（A给B递交了一个系统名片，系统名片上有A的各种联系方式）
B：很高兴为您效劳，再见。欢迎下次光临。
A：再见。
这样一次系统交互就结束了。两个系统之间的通信，跟两个人之间的通信类似，两个人在大街上相遇会打招呼，两个系统也可以，两个人可以选择英语交流，也可以选择汉语交流，两个系统之间可以选择TCP协议，也可以选择HTTP协议，人可以有名片，系统也可以有名片。两个系统交换名片之后，可以确定是否进一步联系，人也是这样的。人以类聚，物以群分，系统可以分组、分类。
当然，现实肯定不会如此简单，肯定有很多的问题需要考虑。如果能够实现的话，生活岂不是很美好？
