系統整合的淺談

早期的系統整合方式，一開始是透過檔案，反正就大家都來排隊對同一份檔案或一群檔案作操作，就可以達成資訊傳遞共享的目的，雖然代價是檔案壞掉就壞掉了...

再來一陣子，稍微好一點的是用DB，但是彼此之間的資料交換變成是DB Schema owner 之間的dependency, owner 若改動了schema，若其他參考的應用程式沒跟著去更新，那這樣也會出問題...

好吧，後續的再高一點的選擇就是透過Model API 來封裝了存取的語意，用來統一存取溝通，這樣就沒有因為Schema改動而有的問題產生，可是這樣還是有個大問題，就是一旦Model成長的快速，提供的多面向的語意查詢開始紛雜混亂，變得甚至可能會讓原先的Method Signature都給打破了，這時候又該如何 ?

這時候可以考慮採用Message Queue了，Message 傳遞的資訊不是一個Conversational的語句片段，他強調傳遞的是一個完整的scenario，所以他可以指定發給誰，而Message Broker可以陸續去指派其他的接收者，甚至作反還重新執行的行為，此外，一旦遇到越來越多不同的呼叫訊息版本以後，可以透過Broker來傳遞穿透改以不同新版本的Message來處理，進而達成企業需求整合的目的，會用到這個地步的時候，往往是因為不同的需求來的太多太快，甚至已經是無法透過版本控制來解決業務需求了，透過這樣的Message Mechanism能解決相關的問題!!!