在《生命的形態|討論 23|理性與感性(三)》我簡單地介紹網路路由演算法。事實上，在那兒我故意用IN跟OUT來代表「需求」與「執行」。可是一般是用client跟server來表達的喔！也就是說，client送交「需求」給server來「執行」，然後server再將「結果」傳回給client。client 跟server 之間的傳遞路徑，就是由網路路由演算法來決定的。我之所以會選擇用IN跟OUT來代表需求與執行，而不是用client跟server來表達的原因就在於考量「網路服務」(web service)與「系統整合」(systems integration)的差異。就讓我利用這篇文章來解釋一下。

現今絕大部分的網路路由演算法只是用來算出最佳路徑。類似高速公路開車一樣，通常網路資料傳遞最佳路徑的考量不外乎(1)經過的路由器最少(也就是說，經過最少收費站)，(2)等待的時間最少(也就是說，避開繁忙的收費站與路段)，(3) 收費最低(也就是說，避開收費較高的路段)，以及(4)最少的資料丟失(也就是說，避開肇事率較高或較常施工的路段)等等。

簡單地來說，網路路由演算法目前只是非常機械地以"成本"來考量最佳路徑，因為它的責任就是找出最佳路徑將IN(client)的需求快速有效地送達OUT(server)來執行，然後將OUT(server)的執行結果快速有效地送回給IN(client)。可是，最近開始很夯的雲端運算(cloud computing)，卻提供了一個全新的未來網路路由路徑的考量：功能。也就是說，未來的路由演算法也有可能是非常智慧地以"功能"來決定路由路徑。聽不大懂？就讓我用系統整合的例子來解釋一下。

多年前，在接觸網路應用時，我常常會聽到「系統整合」這四個字。舉例來說，假如我們的客戶需要A跟B兩種不同的系統來執行各自的功能時，客戶便會要求某個廠商來做系統整合(systems integration)，好讓IN(client)只要將需求送達給單一的OUT(server)來同時執行A+B(如下圖所示)。

可是，這樣的「系統整合」很有問題喔！首先是，誰該被誰整合？以我們的例子而言，是A整合B，還是B整合A？有不少客戶是用「先後新舊」來決定、有些客戶是以「輕重緩急」來考量，但是，就技術面而言，考量的重點應該是以資料庫(database)的設計好壞為取捨，因為資料庫對軟體應用程式設計而言，就像是建築物的地基。萬一用「先後新舊」或「輕重緩急」的考量結果，是把摩天大樓加蓋在透天厝的地基上的話，那麼系統當機(crash)的機率就大大的提高！另外，「系統整合」本身就是個非常冒險的行為，除非A跟B在當初被設計的時候，就有考慮與其他應用程式來整合，否則整合過程中，出狀況的機率也很高，往往到最後廠商只好採取「頭痛醫頭、腳痛醫腳」的方式來應付了事。

我之所以會對「系統整合」抱持不好的看法，主要也是看到有些不肖廠商假藉「系統整合」之名，行「排除異己」之實。譬如說，早期台灣有不少的大學，為了進行非同步網路教學，或者俗稱的數位學習，也因著當時教育部的專案執行之「明修棧道、暗渡陳倉」，就紛紛採用了國人自行研發的內容管理系統(content management system)，其中最常見的就是旭聯科技(sunnet)的系統。近年來，當越來越多的客戶必須將原有的"非同步"網路教學系統來擴充增加"同步"網路教學系統時，旭聯科技就以「無法整合」或「整合費用過高」的原因來迫使"它們的"客戶接受旭聯所代理的同步教學產品。旭聯科技不願意開放整合介面給客戶的原因，除了有"綁架"客戶之嫌疑之外，我個人覺得它們很有可能是藏拙--深怕客戶會發現旭聯的資料庫設計是「透天厝的地基」！我一向認為，任何系統開發廠商應該要公開整合介面，並且誠實地告訴客戶種種的整合限制，尤其是有關資料庫設計方面的限制。我實實在在地指著那些不願意對客戶公開整合介面的系統開發廠商說重話：你們眼中只有自身的利益；你們眼中完全沒有客戶的權益！

為了解放被「系統整合」所綁架的客戶，網路服務(web service)的架構就應運而生，然後演變成最近很夯的技術發展，也就是雲端運算(cloud computing)。根據維基百科的解釋：

網路服務（Web service）應當是一個軟件系统，用以支持網路間不同機器的互動操作。

這個解釋是文言文了點。讓我用白話文來翻譯一下：

網路服務是一個應用軟體之間的溝通標準，好讓安裝在不同電腦機器上的應用軟體能透過網路通訊來互動操作。

另外，維基百科對「雲端運算」的解釋是：

雲端運算（cloud computing，中國大陸譯作雲計算)是一種基於網際網路的運算新方式...終端使用者不需要了解「雲端」中基礎設施的細節，不必具有相應的專業知識，也無需直接進行控制，只關注自己真正需要什麼樣的資源以及如何透過網路來得到相應的服務。(下圖攫取自維基百科)

簡單用一句話來做個總結：未來的應用程式要能自行合作來共同滿足終端使用者的需求。其中最簡單也最普遍的合作機制就是Single Sign-On (SSO)。SSO是一個標準的網路服務，我稱之為「單一登入」。根據維基百科的解釋：

Single sign-on (SSO) is a property of access control of multiple, related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them.

讓我來翻譯一下：

「單一登入」是多個相關但卻獨立的軟體系統之間的使用權控制機能。藉由這個機能，使用者只要一次登入就有權使用這多個獨立的軟體系統，而不用一次又一次地登入各個獨立的軟體系統。

基於以上的解釋，我個人認為，一開始所提到的A+B系統整合的方式會被以下的網路服務的方式所取代：

畢竟，路由器(router)跟電腦(computer)的界線越來越模糊了，這也是為什麼Cisco跟Microsoft的大戰一觸即發的原因。有朝一日，當雲端運算越來越成熟的時候，我們也許用「網路元」來稱呼它們(路由器+電腦)也許更恰當，因為它們的功能將會越來越像人類大腦網路裡的神經元（neuron）。也因此，我認為人類的大腦不可能採取「系統整合」的方式，一而再、再而三地來加強某一個神經元的功能，反而應該是採用類似「網路服務」或「雲端運算」的方式，讓更多相關但卻各自獨立的神經元來合作執行更強的功能。

如果現在還在談系統整合，那真的是有點落伍了喲！

後記：

之所以會寫這篇文章的另外一個私人原因，是聽到台灣的代理商報告說：『兩個案子因為旭聯科技不願意幫客戶整合JoinNet，所以掉了！』

事實上，這兩個案子的老師跟學生都非常想用JoinNet 來做線上教學，並且老師跟學生也都完成了JoinNet 線上體驗。可是在最後階段，學校的網管人員卻以「無法與旭聯的系統做整合」而活生生地將案子砍掉，然後再向旭聯來購買他們所代理的產品。

旭聯科技曾經想代理JoinNet，但是因為它的目的是為了謀取更高的整合利潤，與JoinNet採用開放式的系統整合介面有衝突，所以被我拒絕了。於是旭聯就向我們的台灣代理商取得經銷權，並且也推廣了JoinNet 多年，但是畢竟產品開發的理念南轅北轍，於是旭聯就開始代理其他許多非JoinNet 的產品，然後假藉「系統整合」之名，行「排除異己」之實。可是，再怎麼地處心積慮，也只有極少數還堅持系統整合的網管人員，還會甘心情願地待在旭聯的"牢獄"裡，而不願意採用Single Sign-On 的機制來獲得自由。這種「眼中只有自身的利益，卻沒有客戶的權益」的銷售手法是無法經營得下去的。

另外值得一提的是，旭聯科技多年來所開發的「智慧大師」數位學習平台，已經被更好的免費開放程式系統Moodle 給勝過了！所以啊，光靠一個來日無多的學習平台，能夠把客戶綁多久呢？真的很替那些還甘心情願地待在旭聯的"牢獄"裡的網管人員擔心，當他們被open-source 的主流市場邊緣化的時候，該如何自圓其說他們今日的決定？總不能一直地錯上加錯吧！

所以啊，即將成為JoinNet 的客戶們，當旭聯科技跟你說：『JoinNet 無法整合』或『JoinNet 整合費用過高』的時候，你只要跟他們說：『不要緊，JoinNet 支援免費的 Single Sign-On。』

Then you will be free, and fine.

P.S. 如果基於無法抗拒之因素，客戶真的只能選擇系統整合這一條路的話，JoinNet 還是有完整的web application development tools 的喲！都是採用跨平台的XML語法哦！