我一直在研究 Node.js 的身份验证，看起来http://passportjs.org/非常符合要求。您认为这会是与 ESB 范围内所有主要第三方云服务进行交互的良好候选者吗？您认为 Passport 是一个可靠的框架吗？
答案1
关于 ESB 身份验证，我可以告诉您有关 SwarmESB（我是作者）的信息，更改身份验证机制很容易：您有一个外部服务提供 API（REST 或其他。我在一个项目中使用了 LDAP，而在其他项目中使用了本地数据库）和一个适配器（node.js 进程提供您自己的适配 API 以面向 Swarm 或转发到外部服务），然后您定义 Swarm 描述（就像一个脚本，用 JS 编写并使用“swarm”函数和一些约定），可以随时更改，而无需更改客户端代码或适配器代码。使用一些 IF，您可以轻松获得用于调试/开发、不同租户、用户、身份验证提供商等的不同算法。
我喜欢将 SwarmESB 与其他（通常是 Java）ESB 之间的相似之处视为 REST 与 SOAP 之间的相似之处。它们服务于相同的范围，但采用激进的方法消除（通常无用的）仪式。我试图创建一个具有 ESB 架构灵活性的解决方案，而无需付出培训程序员掌握相当复杂概念的复杂性代价。如果一个人理解了 Swam 消息传递模型和一些细节，就可以轻松地开始编写集成各种 API（Web 服务或其他）的 node.js 代码
我确实指导过一些 node.js 初学者，让他们理解相关概念，几天后他们就能开展有意义的工作了。到目前为止，我已经在 2 个项目中使用了 SwarmESB（其中一个项目是为罗马尼亚的一家大型机构开发的，使用一年多来，它一直很稳定，没有出现任何问题）。SwarmESB 确实发挥了作用，但文档仍然不够完善（我没有资源、时间等），也无法无限扩展（理论上可以，但有点受限于单个 Redis PUB/SUB 实例），而我可以快速改进这些方面。此外，我还会稍微改进一下错误处理和故障恢复机制。在新的项目中使用 Swarm 理念可能需要一点信任和热爱，而且需要我作为顾问和培训师来启动项目，但一切都是开源的，代码也不多，所以是可行的。
一方面，到目前为止，我们只在使用套接字（flash 和 websockets）的客户端上使用 SwarmESB，而 Swarm 模型从设计上提供了推送通知。使用纯 AJAX 客户端是可能的，但可能不是最佳用例。套接字的感知速度是用户体验的一大优势。关于 Passportjs，您可以推迟决策，因为使用 ESB，您可以获得灵活性，可以专注于设计服务（适配器）并进行身份验证，直到您从业务角度知道您真正应该使用哪些身份验证提供程序。使用 Passportjs 的 Web 服务器可以用作外部服务，也可以由 Swarm 客户端用于连接到 ESB 的适配器提供。如果有兴趣，我可以通过 Skype 联系，我会解释什么是可能的。