注意：開發前有路障

這次我們談服務導向架構 (SOA) 的執行面。一如近幾年來導入 J2EE 架構和應用伺服器，每當 IT 轉型進入新的架構（從兩層式 client-server 到 3-tier/n-tier 分散式架構），跌跌撞撞的情形在許多企業都會見到，特別是剛開始的時候。深究陣痛的病因，不外乎事前規劃過於輕率、architect 腦中仍殘留先前 IT 世代的餘毒、開發人員在實作上對新科技缺乏掌握度、與使用單位溝通不足等問題。而 SOA 的到來，architect 和開發人員在觀念上和思維上所需調適的幅度，事實上並不亞於前幾個時代的IT 架構間的差異。如同先前所討論的，SOA 試圖讓 IT 能更快和業務同步，在規劃上以朝向提供彈性的業務服務為目標。從資訊長到負責規劃的 architect，需要和業務單位和策略夥伴間有充分的溝通。資訊長必須體認， SOA 的建立，將會是一個為期數年的承諾，基礎建設需要按部就班打起來，資助的模式也必須在 IT 和各個業務單位間建立，來陸續支援基礎建設及各項業務服務的開發。在規劃建置業務服務方面，和在過去的 IT 架構之下相比，IT 和業務單位的互動幅度會需要更多。此一溝通工作的執行，甚至會需要一種新的角色，在技術與業務間扮演橋樑和接著劑的任務。有些 architect 或許可以勝任這項工作。但姑且不論是兼職或專職，此項工作的負責人，除了 domain 的知識和 SOA 的認知之外，最重要的是要能不厭其煩地將業務單位的需求，與技術人員充分溝通，進而規劃出較為完善而有價值的業務服務（或者說 “business API”）。在另一方面，技術單位必須培養具備設計 “business API” 的新技能。對開發人員來說，轉型到 SOA 所需要作的調適，幅度或許不如從 structural programming 到 OOP，歷經「頓悟」般的轉變；但對於習於使用 function call和元件等較為緊密結合(tightly-coupled) 的方式進行應用整合的 architect 和開發人員來說，改成從業務的角度來思考、設計 AP，且能充分掌握鬆散藕合 (loosely-coupled) 的設計法則，仍是一項新的挑戰。國外一些開始導入 SOA 的企業資訊長也紛紛意識到，設計“business API” 的技能，需要開始導入和培訓。如我們先前所討論的，鬆散藕合的原則，是 Web services 和 SOA 承襲自第一代 Web（即 Web 1.0）的主要精髓，也是 Web 之所以能有今天，其背後最重要的關鍵因素。要設計出業務導向的服務，開發人員在規劃 Web services 介面和 XML 的顆粒大小（應囊括哪些欄位和內容）等問題時，可以把要規劃的介面單元想像成一個個的頁面（不管是網頁的形式，或者client-server 的 GUI 畫面，或主機的終端畫面皆可），其提供了一項項申辦、查詢、訂購…的功能。如何透過和業務單位 and/or 策略夥伴充分溝通（視該項 Web service 要服務的對象），從業務和續發展的彈性等角度出發，然後逐漸討論、描繪出 XML 文件的各項欄位，將會是規劃業務服務的過程中，需要好好構思的一項重要工作。