朋友们，
我正在寻求您的意见，以帮助我考虑下一个开源项目。我有两个想法，其中一个我想做，可能使用 Java 作为主要语言，只是作为一个偏好问题。我特别想知道其中任何一个是否已经完成，这样我就不会重复工作，以及您是否认为它可能对您所做的工作有用。
第一个是 UDDI 的 SOA 目录服务替代方案。当我在 90 年代中期帮助实现中间件/SOA 框架时，我们构建的其中一个部分是目录服务。虽然它没有提供今天 UDDI 提供的元数据存储功能，但它比 UDDI 具有一些优势。很简单：很容易注册服务、进行查找等。速度非常快。使用租用机制注册的服务，因此您可以获得匹配服务实例的列表，知道这些实例可能仍在运行。接下来，它被复制了。当然，许多 UDDI 实现都支持复制。我不想做的是创建另一个 UDDI 实现，而是构建一个替代目录服务，它更像我们在 90 年代所做的，符合当今的框架需求，但更轻量级。在我看来，UDDI 是一个比大多数企业需要的更重量级的解决方案，一个更简单的解决方案可能会提供一些吸引力，前提是它与他们已经使用的任何框架很好地集成。也就是说，很容易选择它作为 UDDI 的替代方案。
第二种可能性是对数据联合系统进行开源实现。我们为一个从未使用过的客户建造了一个，但里面有一些好主意。作为一个开源项目，我想再做一次，因为它提供了一些有用的功能。它本质上允许用户将文档发布到主节点，然后将文档复制到区域服务器，也就是说，将数据推送到靠近组织内使用它的位置。例如，如果一个文档被标记为与某个组织的欧洲地区相关，那么它将被推送到该地区的服务器，以及邻近地区的备份服务器。然后，该地区的用户可以根据需要对文档进行注释，并将其推送回原作者以供考虑。相对于拥有单一文档服务器，像这样的联合系统提供了一些可用性和性能优势。当用户想要一个没有存储在他或她的区域中的文档时，系统会返回到主服务器或另一个区域服务器来获取它。作为一项附加功能，原始系统支持可以从外部来源获取数据的插件，并且包含这些插件可能很有用。