18. Architecture Checklist
? Identify systems and processes
? Create an integration profile
? Map data flows
? Set performance requirements
? Define security requirements
? Identify redundancy requirements
? Quantify QoS requirements
18
19. To ESB
? Numerous integration points
? Need to grow the architecture
? More that one protocol
? Mediation requirements
? Scalability, Management, Monitoring,
Transformation and Security requirements
? Strategic Projects
19
20. 總結
? ESB 是一套軟體
– 提供了各種各樣的容器綁定元件（ Binding
Component, BC ）
? 接收各種各樣的傳輸協定的消息與發送請求消息給外部容器
– 提供處理各種業務的元件的消息（ Service Engines,
SE ）
? 接收到 HTTP 的消息後需要轉發給外部元件 EJB 。
– 訊息通過傳輸通道（ Deliver Channel ）傳送到
NMR （ Normalized Message Router ），再由 NMR
通過 DC 將資訊轉到 SE 或 BC
? 是否要使用 ESB 是可以評估的。
20
Editor's Notes
#5: JBI 目的主要是在於創建一個可以集成各種元件服務的運行環境，當然這也是一種服務匯流排思想的體現。 目前流行的服務容器有 Servlet 容器、 EJB 容器、 JMS 容器。 a. Servlet 容器只能處理以 HTTP/SOAP 協定傳輸的消息（接收與回應）； b. EJB 容器只能處理 RMI 協定傳輸的消息； c. JMS 容器則處理的是 JMS 協定傳輸的消息； 它們之間無法進行通訊，如果想集成上面不同類型的容器服務，則必須有一種能融合以上不同容器的 新容器出現。 JBI 就是基於解決這種問題的思路出現的， JBI 提供了各種各樣的容器綁定元件（ Binding Component, 稱 BC ） ,BC 專門負責接收各種各樣的傳輸協定的消息與發送請求消息給外部容器。當然 JBI 還提供其他的功能，要不這純屬一種代理 了，就沒什麼意義。 JBI 提供處理各種業務的元件的消息（即 Service Engines 元件，稱 SE ），比如接收到 HTTP 的消息後需要轉發給外部元件 EJB ，則需要 SE 元件來進行轉換（更準確的說是 Transform SE 元件）。其實 BC 與 SE 之間是無法直接通信的，所有的消息都是通過傳輸通道（ Deliver Channel ）傳送到 NMR （ Normalized Message Router ），再由 NMR 通過 DC 將資訊轉到 SE 或 BC 的
#7: Event handling - guarantee event processing protocol conversion - transparently translate between communication protocols (e.g. HTTP, FTP, REST, SOAP, JSON, DCOM, CORBA, SAP RFC etc.) Mapping - Transfer between tabular data formats Translation and transformation - Change data content based on rules Queuing and buffering - Handle differing data processing speeds between sender and receiver
#18: An ESB does not define your architecture for you. It provides a model in which your architecture can be defined.
#20: Start small with a view to grow over time: Anecdote
