Web Services best practices

承續上篇關於WebServices的錯誤應用說明後 ,
來介紹一下Web Services best practices
以下內容出自 IBM Redbook : sg247257.pdf
Web Services Handbook for WebSphere Application Server Version 6.1
內容的Page.228(AdobeReader頁碼)
            Page.198(PDF頁碼)
提到關於~Generic best practices~
(1)Be WS-I compliant
(2)Use simple data types
(3)Avoid nillable primitives
(4)Avoid fine-grained Web services
(5)Avoid Web services for intra-application communication
(6)Use short attribute, property, and tag names
(7)Avoid deep nesting of XML structures
(8)Apply common sense (also known as being defensive)
第1點是要符合WS-I的標準
第2點是要使用簡單資料型別(就是一般的基本資料型別)
裡面的第4點提到 fine-grained 一般是直譯為"細粒" , 就是說到要避免過細的WebServices的使用
另外如(6)(7)就是關於XML傳輸的資料量的問題 , 太長的attributes , property , 太深的XML結構都會造成XML 資料量變大 , 而可能導致佔用大量的網路頻寬
此外還有(5)提到避免用於intra的應用程式的通訊 ,這點也說明了 , 不要濫用WebServices於系統的建議


世上沒有萬靈藥 , 沒有一種藥可以治療所有的各種病痛
技術與樣式也是一樣 , 需要看場合 , 看需要的應用 , 濫用技術與樣式不是好事
提出此篇來與前一篇 WebServices的錯誤應用來對照呼應

有興趣看完原文的人 , 可上 IBM 的紅皮書網站 , 下載上面提到的 PDF , 來看詳細內容

WebServices技術的錯誤運用

WebServices技術的錯誤運用

每當有些新的技術出來 , 就會有人把它掛在嘴邊 , 似乎是萬能丹
可是要小心不要落入錯用新的技術的陷阱中
WebService s? 現在已經不新了吧
隨便舉個應用的例子好了 ,
有些 FlowEngine的產品或是要與FlowEngine整合的系統 , 馬上想到要使用的方式就是 WebServices ,
這種想法有沒有問題呢?

首先要記得 WebServices
1.叫用遠端的服務 ,
2.參數的傳入與結果的傳回都是使用 XML 格式
叫用遠端的服務 , 看起來沒有什麼大問題啊?
事實上 , 如果你有點年紀有使用過 COM+ 跟 EJB 的話 ,
COM+ , EJB 也都是提供遠端呼叫的元件規範
在那個時候 , 就有人濫用這種方式而導致網路與系統效能的降低
舉例來說:
假設Server端有一個 COM+ 物件 X , 提供 methodA , methodB , methodC 三個 Function Call
而你有一個Client端程式的交易是需要呼叫 methodA , 然後呼叫 methodB , 然後呼叫 methodC,
那你會發現透過 TCP方式,你的網路呼叫的往返次數至少是6次,
如果你在Server端有一個 COM+ 物件 Y 提供 methodTran , method內部就是包含了 methodA , methodB , methodC的呼叫
而你的Client端程式去叫用 Y.methodTran 時 , 網路呼叫的往返次數只有 2 次
這中間對於效能就有影響了,網路往返的次數少,花費在網路上的時間就減少,積少成多,效能就變快了
此外在網路呼叫的次數上 , 也會影響網路的頻寬使用
所以在 COM+ 時代 , 就有人提出相關的使用樣式

類似的狀況, 在EJB也反映出來相關的問題 , 所以Core J2EE Patterns 樣式中 , 就出現了DTO(Data Transfer Object)
就是為了避免呼叫EJB的method 時 , 傳入傳回的都是單一的屬性值 , 但是卻要進行多次的網路呼叫,
將可以進行一次網路呼叫並且取回的結果封裝成一個物件傳回 , 為的也是相同的原因 ,
避免多次網路呼叫 , 系統效能會變差 , 並且影響網路頻寬 ,

不是要談 WebServices 嗎? , 怎麼開始講古了呢? , 講到 EJB / COM+ 去了?
再重複上面提到的 WebServices的基本要項首先要記得 WebServices 1.叫用遠端的服務 , 2.參數的傳入與結果的傳回都是使用 XML 格式當然這裡面有個潛規則就是叫用遠端服務如何叫用 是透過網路 , 看起來好像是廢話 , 沒有網路如何呼叫遠端服務?
剛剛談到了 COM+ , EJB 在提供遠端服務的 method 時 , 其中一個影響要素就是 網路
當然使用的網路協定還是基於TCP協定(HTTP/FTP/SMTP)
所以COM+ / EJB 碰到的問題 , WebService 還是一樣會碰到 , 就是不要提供過細的method服務

你可以想像有人可能會濫用過細的WebServices 然後用在可能是上千萬筆的檔案轉換上面(Ex:轉檔) ,
可能是上千萬 次的WebService Call, 這個除了帶來程式的效能很差的結果之外 ,
也可能會影響到網路的頻寬使用
記得上面提到 WebServices的要項2嗎? 2.參數的傳入與結果的傳回都是使用 XML 格式
也就是說如果你呼叫過細的method 服務 , 你需要傳入XML ,也需要傳回XML , 這樣的資料量 , 可能遠遠大於你真正要傳回的資料
這些會吃掉你的網路頻寬 , 而當網路頻寬被吃掉 , 就是其他別的系統可能也需要網路頻寬 , 卻因為網路頻寬不足而導致別的系統服務的效能
也變差
所以不要濫用WebServices ,
如果你不是把它使用在交易服務 , 而是許多細小的資料查詢上面的話 , 那你就是濫用了
回過頭來看 , 最原始的問題
"有些 FlowEngine的產品或是要與FlowEngine整合的系統 , 馬上想到要使用的方式就是 WebServices ,這種想法有沒有問題呢?"

那要看看你的 Flow Engine 的呼叫對象 , 到底是會呼叫非常多次細項的資料處理的WebServices 還是呼叫一次交易處理的WebServices
如果是前者 , 那我只能提醒你 , 你的系統可能會有效能不佳並且導致整個網路頻寬被佔用的情況
如果你的人員或是外包商中會提出這樣的系統設計的 , 也請注意 , 他們可能只是知道有個WebServices的技術可以用 , 但是卻不會進一步深思 , 用法有沒有問題

WebServices 不是不好 , 而是要小心的用 , 正確的用 ,
用的不好 , 只能說你再換一個 128顆CPU的主機(現在應該還沒有這種商用主機吧 , 誇張的說法)系統還是跑不快... 當然如果你的Server間的網路都改用光纖或許可以改善...
關於系統效能不佳 , 平台人員要求換機器那又是另外的主題了...
這篇主題中還有一個要點沒有提到的就是關於交易處理的部分 , 它也是影響系統效能表現的要點

不要說我舉的例子太蠢 , 不會有人犯這種蠢錯誤 ,
就是有看過 , 而且還不少...

分析與設計03-企業需求2

接續 分析與設計02-企業需求

上面提到了 , 有些項目是在進行系統分析與設計時 , 必須要一併考慮進去的

例如 如何降低系統維護人力的這個要求
有些系統常常只考慮正常狀況 , 但是如果發生了異常狀況 ,  則可能會需要大量的人力來進行後續的處理與作業 ,


又或者是說到了 Server 的Cluster 配置 , 這裡面就會牽扯到兩台或是多台Server 之間 , 關於 Web Session 的共用(或者是同步)等等．在進行系統設計時必須要稍微注意一下


舉例來說 , 有某廠商在設計排程程式時 , 根本沒有考慮Cluster的狀態 , 結果我們一問他們 ,
在Cluster 環境下 , 是不是會各跑各的(2台 Server上的相同工作各自執行) ,
結果廠商就說兩邊都會起來執行(有些工作是只應該被執行一次的 , 而不是兩次的)
或者是檔案的產生 , 因為有2 台Server就必須要考慮 ,

如果user由Server1 切到 Server2時 , Server2可能取不到剛剛 Server1上面的檔案 , 而導致失敗．
當然聰明的人馬上就會想到要將Server1 與 Server2 的檔案存取點是 mount 一個共用的Server3上的Share 路徑．這樣做也沒有問題．

只是這些其實是要再設計的時候就考慮進去的，因為這些細節會影響到日後各項細項的工作．

分析與設計02-企業需求

在面對企業內部需求 , 有些系統就必須要考慮到十分周詳與長遠
例如 , 企業上會有些要求 , 例如 , 系統維護人力必須要低 , Down Time 要短 , 還是 Fail over 等等

因應這些需求 , 就會有一些配套的解決方式 ,
例如: Fail over 跟 Down time 的需求就會有 Cluster 或者是 Load Balance 等等解決方案
而系統維護人力要低 , 則必須要從分析跟設計開始著手 , 搭配一些自動化的監控軟體．


這裡面必須要提出來談的是，千萬不要一開始就看所謂的監控log file 這樣的問題點入手 ,
那根本不是有企業等級眼光的人員提出來的 ,


我看過某家公司的某些人員一開始提監控就是提監控 log file , 而不是先提系統該如何被監控 , 哪些事件是要由哪些角色來進行處理 , 這個只能說他們是小孩子在開大車

為何這樣說呢 ? 大型企業一般來說  , 可能會把 IT 的人員角色切的很細 , 管理 Database 的人員 , 管理 AP Server 的人員 , 管理網路的人員 , 管理應用系統的人員．

而大型企業的系統的 log , 有可能一天就是幾千條 , 甚至上萬條紀錄 , 如果你一開始就只是去談 log 的監控而不是由 log 的上游看起 , 那我只能告訴你 , 那是垃圾 , 垃圾進 , 垃圾出．


不相信嗎？　去看一下企業內部的相關管理系統的人員，他們一天可能會收到上百封由監控系統發出alert email ,

你猜猜看那些人員會怎麼看這些mail ,
答案是直接略過 , 為什麼 ?
理由1: alert 太多了 , 所以分不出來 , 那些是真正重要的 , 哪些是不重要的
理由2: alert 沒有足夠明確的訊息 , 管理Database 的人員(或者是管Server的人)不知道要如何進行下一步的處理 , 那些可能只有系統的維護人員才會了解


所以當你要開始規劃公司的監控機制之前 , 請先從系統最上游開始分析 , 要求系統在分析設計時 , 就要把那些錯誤 , 是必需要由哪些角色去處理 , 跟做什麼的全部釐清 , 甚至要把log 也拆離出來 , 商業作業的log跟系統錯誤的log 要切出來．


我看過某公司的某個Enterprise Architect 在規劃監控機制時 , 連腦子動都不動的 , 就談 log file 的監控 ,　似乎以為有監控 log file 就能滿足企業的需要 , 結果明明上游（會產生log file 的系統）就是攪和在一起 ,


要記住 不要為了 XX 而 XX．
在這裡來說就是：不要為了監控而監控．要記住監控真正的原意是什麼．
如果你的上游完全沒有訂出事件的類型，錯誤的情況，處理的方式，甚至是切出log 那麼就會發生 , AP Server 管理人員一天會收到 幾百封的mail , 裡面可能是 JDBC Exception , File not found 各式各樣的問題 , 但是管理人員根本沒有辦法去處理．
結果這樣監控的結果等於就是有跟沒有是一樣的．



要記住 不要為了 XX 而 XX．
不要為了 UML 而 UML 了
不要為了 CMM 而 CMM
不要為了 PM 而 PM

分析與設計01-錯誤案例解析

在進行系統分析與設計時 , 沒有經驗或是沒有動腦的SA/SD 常常會給出錯誤的分析與設計結果
為何說是分析與設計 , 而不單提分析或是單提設計呢 ?
因為常常有很多人以為分析人員可以不需要了解技術 , 不需要了解實作 , 所以常常搞了一堆不會寫程式的人來當 SA ,
可是要記住 , SD 的上游 是SA 的產出 , 當 SA 的產出就是錯誤的時候 , 你就不要期望 SD 的產出會是對的
所以以下的解說，會把 SA/SD 等等混在一起解說
案例1: Web 應用系統的設計 - 長時間的批次作業
使用情境：
在企業環境下 , 可能有某些作業是需要'長時間的且是大量資料處理的作業項目 , 這些作業有一種是由排程自動定時啟動執行(不需要人工介入 , 去啟動) , 另一類則是需要由人工介入 , 來啟動．

原始需求分析：
在web 系統 , 某某頁面，由操作人員輸入＂起始年月＂，＂結束年月＂，然後按下＂開始轉檔作業＂按鈕．
轉檔作業執行結束後，頁面顯示轉檔作業執行成功．

解說：
這上面的需求有幾個盲點，
盲點1: 這是web系統
盲點2: 轉檔作業的需要時間
盲點3:轉檔作業的結束狀態與結果
盲點4: 轉檔作業的過程狀態與監控

首先是web 系統的問題 , web 系統一般來說會有 session timeout 的設定 , 避免有人員連入系統之後 , 一直沒有登出而佔用系統的資源．
而需求上是使用者直接由Ｗｅｂ頁面輸入資料，按下按鈕之後，然後系統直接轉檔，轉檔完成後，就直接顯示結果在頁面上．(這是同步作業的樣式 , 但是錯 , 這個需求應該要轉成非同步作業的樣式)
這樣的做法在 desktop 的應用程式可行 , 但是在Web 應用程式上卻是大錯特錯 , 理由是很有可能會因為 session timeout 而結束轉檔作業, 有人會說 那把 session timeout 調長一點 , 例如 24 小時(那肯定是大外行的人會這樣說)  , 有哪一個人會真的需要掛在系統上 24 小時的 , 如果設成這樣 , 不如將 session 設成永不 timeout , (那為何要設計 session timeout 呢 ? , 就是要避免系統資源的浪費 , 希望系統在相同的硬體架構下可以服務更多的使用者)

第二是轉檔作業的時間，可能需要一次整批處理幾百萬筆的資料，不太可能在30分鐘內處理完成,可能需要幾個鐘頭才能處理完成．
第三是轉檔作業執行結束，轉檔不見得一定會成功，如果失敗了要如何處理？
這個也是大外行的分析跟設計人員常犯的錯誤 ,
他們都會只考慮作業一定會成功 , 而不考慮如果發生錯誤要如何進行錯誤處理與錯誤回覆
所以如果你問他們如果發生錯誤 , 頁面會如何顯示時 , 他們就答不出來,
如果發生錯誤時 , 轉檔的資料是否會 Rollback 還是會部分寫入 , 他們可能也會答不出來 ,

我的建議解: 請將上述的需求由同步處理 轉成 非同步處理的樣式
需求：
在web 系統 , 某某頁面，由操作人員輸入＂起始年月＂，＂結束年月＂，然後按下＂開始轉檔作業＂按鈕．(頁面會將需求轉成排入批次作業 , 並取得處理批號 , 這裡就是要轉成非同步處理 , 而不是直接進行作業然後等到作業處理完成後 , 才回應結果)
頁面回應 轉檔作業處理批號．
另有批次處理監控頁面，顯示批次處理作業的處理批號，起始時間 , 結束時間 , 目前處理狀態(啟動/處理中/結束) , 結束狀態(成功/失敗) , 結束狀態備註(失敗原因) , 處理筆數 , 啟動人員代碼 , 系統代碼 , 作業代碼．

系統背端會有一服務程式每隔 10 min(閒距可以調整) 去監控批次處理作業的狀態,
如果有發現到批次處理作業沒有結束時間 , 但是起始時間已經超過 4 小時者 , 則需要發警訊(Email) 給系統維護人員進行檢視 , 看看是否該批次作業已經當掉 , 需要重新執行或是進行其他補救動作等等

補充說明:
還有很多更細節的需求 , 例如系統需要根據起始年月 , 結束年月到資料庫的某某 table 去取什麼資料 , 做處理 , 或是要對起始年月 , 結束年月進行輸入資料的檢核等等 , 這些就不用特別標示出來談 , 因為這些是更基本的．


有的沒經驗或是沒有動腦想的分析設計人員真的會做出如上例的原始需求分析，
而且他們還沒有意識到哪裡有錯誤，反正這樣也能執行，然後就Coding , 結果就會是慘不忍睹 ,
這些是我在公司的外包廠商碰到的經驗 , 他們還會理直氣壯的告訴你 , Session Timeout 設長一點(反正就是要你改公司的Server 設定來配合他們的程式)

除錯心法5

心法10: 不要忘記檢查環境的基本設定-1: 日期時間


有時候軟體系統執行不正常 , 不是因為程式的問題 , 而是因為環境設定的不正確
舉例來說 ,
有些人可能會去調整 Server 的時間設定 , 例如把時間往前調或是往後調 ,
這些設定可能會導致 Server 上的軟體運作不正常 ,
特別是在Cluster 架構下 , 你又只異動其中一台Server


或者是在J2EE Server 環境下 ,
舉例來說 , Tomcat Server 會根據 jsp 檔的修改日期時間 , 來決定要不要重新將jsp 編譯
很久之前 , 有同事去異動了Server上的時間 . 然後當他不斷的去修改 jsp , 卻發現jsp執行的結果 , 一直是舊的jsp頁面執行結果 , 查了很久,才發現是有人異動了Server上的時間 , 導致 Server 檢查jsp 的日期時間時 , 認為 jsp 是不須重新編譯的情況 , 結果不論同事怎麼修改 jsp 就是不會有更新的結果出來

心法11: 不要忘記檢查環境的基本設定-2: Client 的 IE 的編碼設定
之前有發生過 User 來反應 , 他看到系統的頁面 , 是一片空白 ,我們的頁面輸出是big5,
原先以為是系統有問題 , 但是跟其他人的機器一比對,其他人的執行結果都正常 ,
發現只有他的會這樣

去檢查了他的 IE 設定 , 發現他把編碼設定成 UTF-8 , 結果導致頁面出現一片空白