有一天，身為一個優秀開發者的你被同事抓到旁邊，他想到了一個空前絕後、聰明至極的好點子：一個線上停車繳費系統！非常興奮的他開始滔滔不絕地說著如何連接 GPS，放到自己繪製的精美地圖、如何跟銀行溝通，實現信用卡繳費功能、如何設計登入介面、還有忘記密碼、錯誤訊息......，你眼球一翻，說「阿就直接讓這個系統接上 Google Maps, Paypal Payment 還有 Facebook Login 就好啦！幹嘛要自己重造輪子？你時間那麼多？而且你確定你會做得比人家好？」「好...好像是這樣...」他愣愣看著自己厚厚一疊的草稿。突然之間覺得應該要安慰他的你，只好說「哎呀，其實我也不是第一個有這個點子的人啦，我們今天能夠那麼方便地使用別人做好的功能，是因為十幾年前有人先提出了這個想法，慢慢演進，才有現在這個樣子的。」登登，這就是我們今天要談的主題：服務導向架構（Service-Oriented Architecture）。

一點點講古

從前從前，當一個人想到什麼新的工程點子，通常就是深呼吸一口氣，跟你的同事一樣，開始把計畫中的需要用到的所有功能一點一點建構出來，頂多參考一下別人的怎麼做的，沒有捷徑可循。這樣打造出來的結構，也是當時主流的工程系統有幾個特徵：同質的（homogeneous）、有邊界的（bounded）、與靜態的（static）。

但是當各種技術發展得越來越快，結構越來越複雜，加上分散式運算 (distributed computing) 的潮流，我們開始思考，如何才能更好地因應現在異質（heterogeneous）, 無邊界的（unbounded）, **動態的（dynamic）與未定義的（undefined）**的網路世界。

於是 服務導向架構（Service-Oriented Architecture, SOA） 出現了。早在 1996 年，Roy Schulte 就爲 Service-Oriented Architecture 下了定義：

A service-oriented architecture is a style of multitier computing that helps organizations share logic and data among multiple applications and usage modes.

而到了 2002 年，當 web 服務（web services）的概念崛起時，SOA 開始流行。˙

所以 SOA 到底是什麼？有什麼好？

在服務導向架構的世界中，一個服務（service）就是一個功能，通常是一個有清楚定義的商業功能，比如說提供天氣資料、檢查使用者身份等等。服務與服務之間是低耦合的（loosely coupled）並且使用標準化的介面（interface）與規範（protocol）來確保其他程式/客戶端可以無痛的使用它們。

SOA Manifesto

2009 年的 服務導向架構宣言 定義了六個核心價值：

1. 商業價值 (business value） 比技術策略 (technical strategy) 更加重要。
2. 策略目標 (strategic goal） 比專案本身帶來的好處 (project-specific benefits) 更加重要。
3. 內部系統的合作（intrinsic inter-operability） 比客製化的整合 (custom integration) 更加重要。
4. 共享的服務 (shared services） 比客製化的實現 (specific-purpose implementation) 更加重要。
5. 彈性 (flexibility） 比優化 (optimization) 更加重要。
6. 逐步演進 (evolutionary refinement） 比一開始就做到完美 (pursuit of initial perfection) 更加重要。

下面是幾個導入 SOA 的優點：

• 敏捷 agile: 因為服務與服務之間是獨立並且低耦合的，所以更動的成本低，企業更容易快速因應市場需求調整服務。
• 人員溝通成本低 ease of human communication: 一個撰寫良好的服務就是一個清楚的功能，而這個功能應該是不具工程背景的人也可以輕易理解的。如此一來，非工程部門的人也可以據此來暸解企業的軟體架構，日後提新的需求、改動需求的時候，也能夠更準確預估所需要的時間與心力。
• 可重複使用 reusable: 因為服務之間都有個統一的介面可以互相呼叫彼此，所以一個服務可以被不只一個應用程式使用，除了省去重造輪子的繁瑣，也因為該服務自己本身應該已經要有測試了，所以可以節省為新的應用程式寫測試的時間。

SOA 中服務的互動方式與角色

通常 SOA 會以 web 服務（web service）的方式被實現，並且常搭配 SOAP（Simple Object Access Protocol）來作為訊息傳遞的規範（但這只是最被廣泛採納的作法，並非唯一）。以下介紹 SOA 三個主要組成角色：Service Registry, Service Provider 與 Service User。

• Service Registry: 每個服務在被應用程式使用之前都會需要先註冊。UDDI (Universal Description, Definition, and Integration) 是定義註冊方式的規範。而註冊時，每個服務都會有一份用 Web Services Description Language (WSDL) 寫成的， XML 格式自我介紹文件，讓應用程式、別的服務知道自己提供的功能是什麼。
• Service Provider: 一個個獨立的功能。像是上面例子中的地圖檢索、登入、信用卡繳費等等。
• Service User: 服務的使用者，有可能會是一個應用程式，或是其他服務。

理想與現實的差距：SOA 的轉變

一開始，服務導向架構的理念是好的：加快開發速度與減少成本。當 SOA 的概念出現，Enterprise Service Bus (ESB) 接著被提出，用來實現 SOA 低耦合（loose coupling）的原則。ESB 想要改進的是 Enterprise Application Integration (EAI) 所帶來的低開發效率與高度依存性。原本 ESB 的目標是做一個輕量的、普遍的平台來整合不同服務節點，但是當廠商真的要導入 SOA 時，大多數的供應商都只是將原本的 EAI 改名變成 ESB 而已。

換湯不換藥的結果，就是 ESB 幾乎變成要實作 SOA 時不可或缺的要素。於是 SOA 變得非常中心化，加上隨之而來的各種實作公版（technological templates）與規則（prescriptive standards），原本 ESB「輕量、普遍」的訴求已經不在了。

由於龐大的 ESB 與註冊機制（registry），使得 2009 年開始崛起的 RESTful Web API 逐漸取代了 SOA 的位置。與 SOA 「先有定義，再有實作」的發展過程相反，RESTful Web API 是有機演化的，並且有著輕量與分散式的優點，於是變成了直到今日都仍然是主流的架構。

仍然是一個光榮的失敗

雖然時至今日已經很少人使用 SOA 了，它仍然是在軟體工程架構發展史上不可或缺的一員。下一篇要介紹的微服務（Microserivces） 架構就是根據 SOA 的教訓而演化而來的。有些人說微服務是「沒有走歪的 SOA」，因為微服務架構的精神其實跟 SOA 非常相似。敬請期待！

參考資料

• https://www.gartner.com/en/documents/302868
• https://www.infoworld.com/article/3080611/learning-from-soa-5-lessons-for-the-microservices-era.html
• https://docs.microsoft.com/en-us/previous-versions/dotnet/articles/ms996507(v=msdn.10)
• https://www.javaworld.com/article/2071889/what-is-service-oriented-architecture.html
• https://www.researchgate.net/publication/224711735_Bilateral_Service_Mapping_Approaches_between_the_Different_Service_Oriented_Architectures_Web_Services_and_UPnP
• https://www.ibm.com/support/knowledgecenter/SSMQ79_9.5.1/com.ibm.egl.pg.doc/topics/pegl_serv_overview.html
• https://youtu.be/_dFJOSR-aFs
• https://youtu.be/Xjm6y8rs8u4

作者：Jenny