宏觀設計Web services

我們在上 期中談到，服務導向架構 (SOA) 是透過業務服務的概念來提供 IT 的各項基本應用功能，藉以拉近業務和 IT 之間的距離。因為傳統上，IT 的思維多偏應用導向（沒什麼不對）。ERP、CRM、SCM、 ...，專有名詞縮寫多到目不暇給。在試圖為一個個應用空間提供解決方案的同時，也累積造就了一個個的資訊壁壘，也就是所謂的silos。

服務導向架構的產生，正是著眼於將這些縱向資訊堡壘加以橫向貫穿，讓它們各自提供若干對企業整體有價值的應用服務，讓這些服務可以自由的被排列組合、融會貫通，以便在未來能隨時彈性配合新的需求而調整。

我們同時談到，Web services協助跨越系統間的鴻溝，扮演了SOA的催化劑角色；反過來看，要成功導入 Web services，進而獲致成效，那麼整個IT架構必須有通盤、全面性的規劃，以SOA為大方向和指導原則，將它定位在接下來三至五年規劃藍圖的核心。

其實算一算，Web services的風潮也已喊了有兩、三年了。但感覺上，尤其在國內，至今仍難免給人雷聲大、雨點小的印象。事實上，許多讀者可能已經觀察到一個 pattern：熱門新科技的問世，隨著市場上的炒作，往往才剛開始便一炮沖天，high 到最高點；如果把它的熱度發展用曲線來描繪，像極了一座陡峭的山峰，一過頂點便大幅下滑，墜入谷底--因為已被談膩，大家也沒興趣聽了。

這個大起大落、如洗三溫暖般的發展過程被稱作是「炒作曲線」(Hype Curve)。 Web services是如此；幾年前的 Java、兩年前鼎沸的3G、還有去年被大書特書的奈米科技，何嘗不都是如此？隨著炒作曲線發展的同時，真正具有潛力的科技，會逐漸受到愈來愈多青睞，導 入的比例隨著時間逐漸攀升，就像一條比較平緩卻務實的曲線，由地平線逐漸升起，有如高原狀般。這條被稱作叫「導入曲線」(Adoption Curve)，與炒作曲線形成強烈對比。

回顧J2EE的發展，歷經過去幾年的洗禮，可說早已渡過炒作曲線跌至谷底深淵的危機，開始進入導入曲線的後段高點，成為新一代最主流的中介軟體(middleware)运算平台(我們將在稍後一期的專欄中將探討應用平台，包括 J2EE 和 .NET 與 SOA 的關係)從西方大企業近兩年導入Web services的盛況（如BEA、微軟、IBM等主要的Web services廠商皆不乏成功案例），加上國內近年來的發展（如電子化政府共通平台），以及各科技廠商在研發上持續的支持和投資來觀察，Web services後續看起來也有很強的支撐力道。

其實Web services所招致的誤解和片面了解的程度也不小。這一部分要歸咎於它的名稱取得也實在是有點不太明確，也不響亮。很多人的直覺反應可能會是：「提供 網站服務的，像 Web server提供網頁這類HTTP服務，就是 Web services啊」。另外，有的工程師朋友們可能看得比較底層，會認為Web services/SOAP只不過是種「透過 XML 封裝、較為冗長，執行效能較差的溝通模式」。

這樣的敘述，雖然從純技術的角度而言基本上正確，但卻也容易導致見樹不見林的遺憾。我們說 Web services要能擔綱企業級、關鍵性應用，在實作和設計上必先把握幾個關鍵原則，包括鬆散藕合 (loose coupling) 和正確的顆粒大小 (granularity)。

先前提到，Web services提供的是異質系統間的溝通介面，這個介面越中立越好，而且必須由雙方共同配合遵守，以避免因為單方面系統、程式內部的調整而衝擊到雙方的 溝通。中立的介面同時有助於提升再利用率--因為設計時將完全不預設未來可能呼叫此一介面的系統或使用者。

此外，由於Web services是用來提供相當於業務服務的功能，因此在設計上便應將所傳遞的XML資料內容，朝向設計成為一種在業務上有意義的單元。換句話說，顆粒必 須要夠粗，層級必須要夠高（高到business層級），這和過去在設計函式呼叫、小顆粒的作法，在概念和目標上便有所分別。

至於什麼時候適用 Web services，以及溝通介面的長相及顆粒大小等設計課題，也將逐漸成為一個專門的學問。我們可以歸納一個簡單的原則：如果是跨機關企業、跨應用系統， 或跨程式語言間的交流，那麼便該優先考慮Web services；但如果是某一個系統、或某一種語言內部的溝通，它就不見得是最好的候選人了。只有使用得當，Web services才能真正發揮它潛在的價值。如果只是「為Web services而Web services」，那可有苦頭吃的。