用於連接到基於雲的服務的 Node.js ESB 身份驗證
我一直在研究 Node.js 的身份驗證，看起來http://passportjs.org/非常符合要求。您認為這將是與所有在 ESB 範圍內有用的主要第三方基於雲的服務互動的好選擇嗎？你認為護照是一個可靠的框架嗎？
關於 ESB 身份驗證，我可以告訴 SwarmESB（我是作者），更改身份驗證機制很容易：您擁有提供 API（REST 或其他）的外部服務。我將 LDAP 用於項目和其他地方的本地數據庫) 和一個適配器（node.js 程序為集群提供您自己適應的 API 或用於轉發到外部服務），並且您定義一個集群描述（如腳本，用 JS 編寫並使用 ‘swarm’ 函式和一些約定），可以隨時更改，無需更改客戶端程式碼或適配器程式碼。使用一些 IF，您可以輕鬆獲得用於調試/開發的不同算法、不同的租戶、使用者、身份驗證提供者等。
我喜歡將 SwarmESB 與其他（通常是 Java）ESB 之間的相似之處視為 REST 和 SOAP 之間的相似之處。他們的服務範圍相同，但在取消（通常無用的）儀式方面採取了激進的方法。我試圖創建一個具有 ESB 架構靈活性的解決方案，而無需支付培訓具有相當複雜概念的程序員的複雜性代價。如果一個人了解 swam 消息傳遞模型和一些細節它可以很容易地開始編寫集成各種 API（Web 服務或其他）的 node.js 程式碼
我確實指導了一些 node.js 初學者來理解這些概念，並且他們能夠在幾天內完成有意義的工作。到目前為止，我在 2 個項目中使用了 SwarmESB（一個用於羅馬尼亞的大型機構，它很穩定，並且工作一年多沒有問題）。SwarmESB 正在完成它的工作，但仍然沒有很好的文件記錄（我沒有資源、時間等）並且無法無限擴展（理論上它可以，因為受單個 Redis PUB/SUB 實例的限制）和我可以快速改善這些方面。另外我會改進一點錯誤處理和故障恢復機制。在新項目中使用 swarm 想法可能需要一點信任和熱愛，你需要我作為顧問和培訓師來啟動項目，但一切都是開源的，沒有那麼多程式碼，這是可行的。
一方面，到目前為止，我們僅將 SwarmESB 與使用套接字（flash 和 websockets）的客戶端一起使用，並且 swarm 模型提供來自設計的推送通知。擁有純 AJAX 客戶端是可能的，但可能不是最佳案例。套接字的感知速度是一個巨大的使用者體驗優勢。關於passportjs，您可能會延遲做出決定，因為使用ESB 您可以獲得靈活性並且可以專注於設計您的服務（適配器）並讓身份驗證直到您知道從業務角度真正應該使用哪些身份驗證提供程序。使用 passportjs 的網路伺服器可以用作外部服務，也可以由 swarm 客戶端用來連接到 ESB 的適配器提供。如果有興趣，我可以通過 Skype 與我聯繫，我將解釋可能的情況。