【本篇發表於 iTHome 雜誌】
身為IT人,鎮日埋首於科技/專案中,久而久之難免對硬梆梆的科技產生麻痺。如果非IT界的家人或朋友問我們:「什麼是XXXX?」(請將XXXX代換成Java、XML、ERP,或您所從事的科技領域),我們直覺的反應往往會是:「很枯燥,你不會感興趣的」,或是「講了你大概也聽不懂」…這類的。其實轉一個角度,IT也可以很生活化,在日常生活中的例子俯拾即是。
Java和星巴克
我了解,多年下來,大家可能早已聽爛了各種耍cute的Java名稱和術語,其中又多圍繞著咖啡的主題打轉;例如,Java的元件叫JavaBeans – 咖啡豆;負責運行這些元件的環境叫container – 咖啡豆罐;著名的open-source組織Apache基金會之下的Java計畫叫「雅加達」(jakarta.apache.org) 等等。
把這些咖啡辭語擱在一旁,大家或許不曾注意到的,是Java平台和星巴克之間的有趣類比關係。龍應台在網路上廣為流傳的『在紫藤廬和Starbucks之間』一文中說到:「我喜歡在Starbucks買咖啡。不見得因為它的咖啡特別好,而是因為,你還沒進去就熟悉它的一切了。你也許在耶路撒冷,也許在倫敦,在北京,或者香港……你就知道在那裡可以點一大杯拿鐵咖啡加一個bagel麵包,雖然這是一個陌生的城市。」想想Java的平台環境,不就是這樣嗎?一支支Java程式,雖然身處各個陌生的OS國度中,但只要其中有它們熟悉的活動場所 (JVM),因為清楚裡面的遊戲規則,所以很確定,和Barista講什麼語言一定通,點什麼飲料一定有,店裡有紙巾和低脂牛奶可自取…。各大廠商願意砸大錢幫我們把這樣的環境建立起來,因為它們知道,比起雞同鴨講、菜單內容迥異、服務態度抓不準的餐飲店 (proprietary platforms),這會是一個大賣點。
XML、Web services和FedEx
如果世上各個國家的人都能配合多學一種簡單的新文字,那麼跨國間的書信往來,便可透過此一「世界文」來達到,這就是XML。Web services中的基本協定SOAP,則是在這個世界文的基礎上,所設計出來的信封、信紙格式及相關的規範。
IT人作久了,不自覺容易罹患一種叫「為科技而科技」的症候群,也就是當某種科技開始流行,往往會有為了要嘗試這個科技而刻意去使用的情形。其實更公道地說,追求fashion本是人性的一環,IT人當然也在所難免。就像看到現在正在流行的衣服、皮包款式,忍不住也想買一件來試試看,儘管配在不同的身材上不見得都合適,對某些買的人更不見得真有此需求。
科技人中,對採用XML的態度,存在著兩種極端,一種是上述的「為XML而XML」,以及「為Web services而Web services」,這個現象近兩年來有愈來愈普遍的趨勢。這就像是把所有的信件和物品,一律都用硬紙箱、防震泡泡給他層層包裹,然後請FedEx/快遞來替我們運送,結果忘了收件人就住在隔壁,其實根本不用包裝,敲個門請他拿過去就可以解決的事,這麼一搞下來,在效率和成本上自然付出很大的代價。當收件人住在另一個國家,講不同的語言時,那麼用國際快遞當然就是合情合理的選擇。
另一種極端則認為,XML格式至為冗長,速度據測試比走binary/native方式至少慢了5至10倍,所以如果用了XML,系統效能上會付出慘痛的代價,所以應該竭盡所能地避免。猶記在十年前,當World Wide Web剛剛興起,大家都還痛苦地使用28.8k甚至14.4k modem上網時,當時我們製作網頁,不但是hand-code HTML(好用的WYSIWYG網頁設計工具尚未發明),而且為了讓訪客能有更好的瀏覽經驗,能更快下載我們的網頁,對於HTML的size往往孜銖必究、絞盡腦汁。幾年下來,隨著寬頻普及、電腦運算速度、容量不斷攀升,還有網路設備對傳輸資料的壓縮功能等因子交互作用的結果,現在可能已經沒有多少人還會關心網頁製作工具,以及各種動態網頁科技所自動產生的HTML中,是否塞了大量的空白、多餘字元?是否不夠精簡、不夠最佳化?在HTML剛出來的時候,不是也有人批評純文字格式的HTML不如一些專為文書處理所設計的binary文件格式來得精簡嗎?結果是,HTML成就了人類有資訊史以來,最跨平台、最普及,最成功的文件格式。為什麼?
同步、非同步、超商,還有(抱歉又是)星巴克
在enterprise computing中,有我們常說的同步 (sync) 和非同步 (async) 的作業模式。打電話、打手機是標準的同步模式。在建立連線時,一個巴掌拍不響,通話雙方人都得在電話附近,手機不能關機、訊號不能斷。如果當時正好找不到對方,溝通便告失敗。用瀏覽器瀏覽網路也是典型的同步模式,當網路斷線、塞車,server當機時,資訊傳遞的目的便無法達成。Email/簡訊採用的則是非同步的策略,發訊者並不期待對方一定能立刻收到,只預計在一個合理的時間範圍內,對方應該會收到。在enterprise computing中,線上交易處理 (On-Line Transaction Processing; OLTP) 是典型的同步作業,而訊息佇列 (message queuing) 則是典型的非同步。
過去手機WAP的失敗、3G寬頻上網的延遲推出,和SMS簡訊跌破眼鏡地大行其道,說明了在無線收訊時有時無的先天環境下,選擇同步、用拉的 (pull) 模式,所必須面對的嚴峻課題(另一種稱作「用推的;push」模式)。
同步作業的模式,會因為某些業務的本質而有其必要性,例如銀行存、放款和轉帳的交易,便可能因為時間先後不同而產生重大差異,故往往皆採用OLTP作業方式。如果我們稍微觀察,會發現便利超商、賣場,還有麵包店在結帳時,通常也都採用同步的模式,當生意好而結帳人員又只有一兩位時,往往大排長龍,而這正是同步模式所必須面對的另一大課題 - scalability。有趣的是,星巴克這類的咖啡連鎖店,採用了非同步的作業,來達到更高的scalability(另外也是因為商品特性的緣故)。他們會先跟客人結帳,然後利用咖啡杯上所作的記號,將製作飲料的工作交由另一組同事進行。一位曾在Starbucks工作的資深Barista告訴我,其實他們使用的濃縮咖啡機,每次一定是左右兩股同時壓出來,但由於會點雙份的客人其實不多,所以他們會儘量在流程中進行「配對」,把倒掉一份的情形減到最低。
因為這種scalability的特性,這正是為什麼我們說,在設計跨系企業Web services交流時,“async is king”。