在談服務之前，我想先安插一小段企業流程與資訊流程的資訊流說明，接下來再說明，企業流程軟體與ESB服務繞徑的差別，以免有人跟當初的我一樣，將此兩部份的資料流搞混了，最後，我會再進入本次的主體 — “ 服務 “ 的說明。
一. 企業流程與資訊流程的資訊流說明
就拿一般企業內部的電子表單來說好了，申請人申請表單後，就會一路至各級長官進行批示，這樣的流程在這裡我稱為”企業流程“，但資訊流卻不是如此，很可能只在電子表單軟體與流程軟體中進行資料交換而已，其實真實的數據資料那裡也沒去，這樣的流程我稱為” 資訊流程 ”。這樣的分流觀念很容易理解，但也很重要，特別在進行系統設計時將它掌握住，視為不同的系統模組觀念，可以比較輕易的將複雜的系統設計拆解開，在跟客戶對談時也可以簡化客戶的需求，加速整個觀念的溝通。
二. 流程軟體與ESB服務繞徑的差別
這部分，現在的人可能比較少遇到了，但如上段所述的，這在過去曾經困惑我很久，因為最早進行SOA專案時，還沒有所謂的ESB產品，相關的訊息繞徑實作其實是拿流程軟體來當作核心，然後外圍再包一層類似訊息控制與服務註冊的功能，說穿了就是類似現在ESB的實作，但通通是在流程軟體上，一度讓我陷入困惑很久，企業流程與資訊流程到底該怎麼進行處理，問題變得很複雜，也陷入分析的癱瘓。
好在後來有遠見的專家學者或廠商，提出了ESB的觀念，讓整個觀念與實作可以切割來視為不同的子系統，如果，現在要我來區分兩者間的應用，在規劃上，我會將企業業務活動放在流程軟體中，而屬於系統間的資料流程控制放在ESB中來完成，例如:
(1) 使用者申請請款單，完成後系統經過ESB通知流程軟體確知下一位審核者
(2) 審核者同意請款後，系統透過ESB通知流程軟體已完成，並且經由ESB呼叫帳務系統開出傳票…等等一連串系統資料交換服務。
簡單的說，只要是業務流程的設定就採用流程軟體來完成，但涉及到服務內的資料流，則會依賴ESB來進行，將問題切割來看，就好解多了。
三. 何謂服務? 簡述服務顆粒度的重要性
接下來終於要談所謂的【服務】了，所謂的服務其實是很抽像的觀念，一個API的呼叫也可以稱為一個服務，多個API串連起來的複雜流程也可以稱為服務，這樣的問題很類似當我們在設計物件導向的程式時所會發生的問題一樣，到底一個物件要多大才是合理的? 同樣的情況也發生在服務大小的定義。太大的服務容易成為特定的業務流程，其重用性差，而太小的服務雖然重用性高，反而成了資料流而非業務觀點，不易被業務單位所釐解，並且容易出現系統實作上效能上的問題。
於是有些學者就又提出服務分層的觀念，如下圖所示
將服務分層，粗顆粒主要是依業務特性單位，而細顆粒則以系統組件為單位，對於外部的使用者而言只要了解業務面的粗顆粒即可，易於業務單位了解及調整業務需求，並且如果系統面有必要，也可以在細顆粒層透過系統面修改來達成業務的需求。
不過，在此我也必須誠實的說，在實作上如果有連接許多的Legacy System，光開發現有系統的連接介面(習慣上稱為LI,Legacy Interface)就花掉一堆時間了，還要做這樣服務整合與規劃，不是做不到，但有許多的客觀因素要建立。例如雙方觀念的建立，成本、時程的考量、舊系統維護人員的配合、內外許多單位的政治折衝…都要一併考量在內，必要的話，專業有時候還要讓位給其它因素，總之，那不會是一件簡單的事，在之後，我會簡單的跟各位分享這方面的所見所聞，此處就不累述了。
四. 一些可以參考的服務設計原則
在實務上，服務的設計或修改很容易因為不同的因素而必需妥協，但撇開這些，仍有一些設計的原則可以參考的，例如在業務流程的規劃上，盡可能讓過去循序的流程改為平行設計為主，這樣的好處是，可以加速業務流程的處理，對系統而言也可以因為各自獨立的作業方式而降低系統的偶合性。而在系統介接的設計上，則是盡可能朝向非同步處理的方式來處理為佳，相較於同步處理，非同步處理可以增加資訊系統介接的容錯度，讓整個服務的運用更加的穩固。
<<未完，待最終篇，SOA與企業流程再造>>
留言列表
