個人經驗談現實中的 SOA, part 1 - 實況, 概念與基於動態語言的實踐途徑
我目前任職於一間百貨流通業的資訊部門，在這裡資訊系統往往不能滿足業務單位，即採購、倉儲、物流、批發與門市零售等單位之需求。我注意到，儘管業務單位總是嚷著軟體不符需求，但企業資訊系統的真正問題並不是不夠，事實上是太多了。不敷業務工作需求的原因，在於資訊無法在這些資訊系統之間平順地移轉流動。每當我們試圖引入一套資訊系統以為這樣能滿足業務單位需求時，往往事與願違。現實狀況是每多一套資訊系統，業務人員就多一份電腦文書工作，這才是業務單位抱怨的事。
在《一個供貨廠商，看興奇與 PCHome 的網購龍頭之爭》一文中，提到了我碰到的網路線上購物管理資訊系統之現實狀況。每間公司內部自有一套進銷存系統，而網購平台上的訂單幾乎不可能直入供貨廠商進銷存系統的客戶訂購單。供貨廠商若不想由業務助理將網購訂單人工輸入到進銷存系統，就得要設計一套資料中介輸出入系統。在公司中，這工作自然由我這個電子商務系統專員來做。然而，這些網購平台業者的供應商後台介面，沒一個符合 SOA 精神，全部都是「人工作業導向」，說得好聽些稱為「使用者友善介面」。其中「東？」最極端，擺明要業務助理用滑鼠從頭點到尾。如果有一百個商品要處理客戶訂單，就要點擊開啟一百個頁面。這倒是讓業務助理得「強迫症」的好方法。一開始業務單位只要「應付」自家進銷存系統，每多一個網路購物平台，就得多應付一套管理資訊系統。每一個資訊系統幾乎都仰賴人工作業，因此資訊系統愈多，業務單位的文書工作就愈多。資訊系統不但不能使業務單位專注於價值創造之本務，反而增加了成本性的文書工作。
資訊系統之患不在寡，在不互通。現在的狀況就是這些資訊系統把公司的業務人員當成了訊息匯流排 (message bus) ，我們依賴「人」作為訊息匯流排，由人把訊息從 A 系統複製出來，再貼到 B 系統去。 SOA (Service Oriented Architecture) 之目的就是要將業務人員從訊息匯流排的角色中解放。對程序員而言，也降少了老是在製造新車的困窘。是的，我們現在不用從輪子開始打造，卻天天在造「更多功能整合的」新車。
SOA (Service Oriented Architecture 服務導向架構) 是一種用於建構分散式系統的方法，它可以將應用程式以「服務」的方式提供給終端使用者，也能建構成其他的服務。透過 SOA ，我們可以將單一的軟體開發成為可提供其他應用系統使用的基本元件。
IBM developerWorks Live! 2006
SOA 的基本概念，是將一個已上線的系統 (system) 視為一個類別與個體 (class/object) ，使程序員可以訊息驅動 (個體之間的互動，乃是由一個個體發送一個訊息給另一個個體……訊息：啟動個體的工具。
(施保旭，1994)) 的方式編寫新的軟體功能。從 CORBA, DCOM 的觀點， SOA 是它們的實踐。雖然現實上的 SOA 未必是用這兩種技術實作，但 SOA 概念仍然是個體導向 (OO) 的延伸，是一種在軟體與系統 (software/system) 層次上的個體導向編程技術 (一般人接觸的是源碼與類別庫 (source/library) 層次上的OOP) 。
個體導向技術在這方面希望能提供一個簡單的方法來解決它。我們將各個舊有的應用系統和它相關的資料庫或是檔案包裝成一個個體。……當系統需要增加新功能時，我們便將它製作成另一個新個體。……這樣做的最大好處便是原有的應用系統、人機界面、資料庫等等均可繼續延用。…… OMG 所訂定的 CORBA 標準便是要滿足這一項需求。
《個體導向技術指引》，施保旭，1994
一個號稱支援 SOA 的系統，應該要有公開的個體行為 (public method) ，不需要調用者了解其實作細節。在我和東？ 、PC????、 Yah?? 這些網路購物平台的線上管理資訊打交道時，我不需要知道它們是用 java 還是 .net ，也不需要知道它們的訊息傳遞機制是用 ESB, BizTalk 還是什麼樣的 message queue 。我一律只看公開介面的部份去評斷它們對 SOA 的支援程度，而我看到的是：
就訊息格式來看:
- 不提供 XML 格式的查詢結果。
- 不提供 JSON 格式的查詢結果。
- 有限的 CSV 格式匯出文件。有些則是匯出微軟 Excel 專屬格式。
- 僅提供 HTML 格式的查詢結果，而且是給人看的，所以會分頁，並夾雜許多格式化內容。
就方法調用來看:
- 不提供 SOAP/WSDL 。
- 不提供良好的 REST 。僅提供 HTTP GET method ，但狀態訊息往往夾雜在 cookie 中，不完全符合 REST 的要求。另一方面，它們並無提供相關資訊，參數作用要自己判斷與試驗。
就訊息發佈來看:
- 不提供 Atom Publishing (參閱《Create and edit Web resources with the Atom Publishing Protocol》了解這一方面的應用)。
- 僅提供 HTTP POST method ，但無相關資訊，要自己看 Html 探知。
不用問到實作細節，先看看服務的公開行為，我所知道的標準方式皆不提供。試問協作廠商如何將它們視為一個服務元件 (service component) 呢？喔，當然可以，只是要用許多麻煩手段。例如自行剖析 HTML 內容，擷取所需資訊。這種作法是不得已的，不能視為 SOA 的作法。
程序員將整個系統視為一個個體封裝起來，透過公開行為調用之概念，其程式碼應該像這樣:
class PcxxxxSupplyManagerService {
protected SOAService pcxxxx;
public Product getProduct(ProductId id);
public ProductId createProduct(Product product);
public boolean updateProduct(Product product);
}如果我要先知道他的系統是如何實作的，亦即我要先繼承以接觸到該系統的實作細節，才能實作我要的功能。而我在實作過程中必須調用父類別的保護方法與成員，才能完成工作。那程式碼就變成這樣:
class PcxxxxService { //某系統實作內容
}
class PcxxxxSupplyManagerService : PcxxxxService{
protected SOAService pcxxxx;
public Product getProduct(ProductId id);
public ProductId createProduct(Product product);
public boolean updateProduct(Product product);
}兩者的差異在於，前者維持兩系統／服務元件之關係為「使用關係」，後者卻是「繼承關係」。從前文對 SOA 的概念說明來看，在 SOA 中的各服務元件之關係應該是鬆散耦合的「使用關係」。我實踐 SOA 概念組合新的資訊作業流程時，我不必知道原有的那些資訊系統內部如何實作，甚至我也不必取得特定的 API 。我僅僅是透過公開行為「使用」那些原有資訊系統。
SOA 是一種基礎結構，用於支援鬆散耦合、可重複使用的 Web Services 之間的溝通，促使商業系統連接後可運作。
「微軟應用平台架構優化 (APIO)」發表會，2006
我認為實踐 SOA 的重點應在使用輕巧的工具快速組合既有服務元件，因此 PHP, Ruby 等動態語言當然可以實踐 SOA ，甚至本來就應該這麼用。我們反而要先感謝其他人用 Java 實作 ESB 這些訊息佇列 (message queue) 機制。用 PHP, Ruby 實作訊息佇列這些底層內容不是個好主意；PHP, Ruby 的強項在調用服務元件，快速組合出新的軟體功能。當然不透過特殊的訊息佇列機制，而僅將 HTTP Server 視為訊息佇列系統也可以，例如 RoR + light httpd 這樣的組合已經在實務上被廣泛應用 (例如 Hemidemi)。不需要用到 XML, SOAP, WSDL, ESB 那些正規軍， RoR, PHP 也可以用輕量級的方式實踐 SOA 。
Reference
- 《個體導向技術導引》第二版，施保旭，1994。資訊與電腦出版社。
- IBM developerWorks Live! 2006 IBM 開發者大會，議程講義文件。
- 微軟應用平台架構優化 (APIO) 發表會 2006，議程講義文件。