Software Cinema

Wayne Fenton, Director of Architecture at eBay Inc., 在 JAOO 2007 上給了一個 Talk : Operational Scalability in the Next Generation Web World (連結內有側錄影片 + Slides), 雖然影片長達 48 分鐘, 不過內容其實很簡短, 雖然提到很多次 eBay, 但是其實內容是獨立的, 有認真上 Fault Tolerance 的人應該都很容易聽懂內容, 因為都是基本的概念.

事實上我沒有真的找到對於 Operational Scalability 較為嚴格的定義, 看看幾個從不同網頁 Copy 下來的 :

From SOA Magazine [1] :

Operational scalability is the ability of a service-oriented solution architecture to establish and maintain highly efficient and adaptive, cost effective day-to-day operations as the solution grows and scales with time. It is also represents the ability of the architecture itself to be efficiently re-factored to accommodate change and dynamic business requirements.

From Rajith’s Column [2] :

Operational scalability is a software problem and you need to think about operational concerns right from the beginning. Pay attention to,

• Logging metrics, Monitoring.
  
• Controlling/updating/tuning live apps without disrupting traffic.

與 Rajith 類似的說法在 CoverPages 的一篇 Sybase 新聞中也可以看到, 不過搞不太清楚算是甚麼, 比較像是文宣, 就不納入參考.

Leticia Duboc 的 PhD Work [3][4] 認為 Scalability 基本上不容易也不適合有一個通用的定義, 需要視乎不同的系統以及面對不同的 Stakeholder 而異. 因此他們也建立了一個 Scalability Framework, 在不同的情況下去 Initiate 此 Framework, 定義不同的 Scaling Dimensions, Independent Variable, Dependent Variable, 以及 Evaluation Standard ( Scalability Claim ).

We define scalability as a quality of software systems characterized by the causal impact that scaling aspects of the system environment and design have on certain measured system qualities as these aspects are varied over expected operational ranges.

(以下圖片引用自 [4])

這樣我差不多可以稍稍做出結論. 基本上可以說有 Operational Scalability 這東西, 也可以說沒有. 在 [1][2] 中基本上是在特定的觀點下, 面對特定的 Stakeholder 去定義 Operational Scalability, 而其中 [1] 又更偏向一般性的 Scalability 敘述. 而在 Wayne Fenton 的 Talk 中事實上提到了許多不同的 Stakeholders, 不僅僅是一般的 Customers 而已. 因此他的 Operational Scalability 與其說是以 Stakeholders 作區分, 不如說是以 Operational Reliable Service 為中心思想, 並且放在Community 多變的 Web Service Context 下作說明.

Operational 指的是 Service 本身是必須持續運作的, 你幾乎不能考慮停止這項 Service, 必須隨時 Ready for Use, 概念同於古老的 Non-Stop System 概念. 而 Reliable 指的是 Service 可能會更新 Features, 但是不能夠因為新的 Features 而造成不可逆的改變. 這兩項在新時代的 Web Service 上更顯關鍵. 我們很容易有了想法, 很快的成立網站提供服務, 但是隨之而來的使用者人潮跟對於新功能的需求非常難以預料, 這跟過去 Software 面對的情況有顯著不同, Community 的形成之快是超乎預料的, 但是 Community 的衰落之快也同樣難以預期.

而 Operational Scalability 在此情況下, 我認為其實就是針對 Community Change 的 System Scalability.


References

[1] Ted Barbusinski, "SOA Engineering Focal Points," The SOA Magazine, Issue XIX, June 2008
[2] Rajith Attapattu, "Scaling your system - What I learnt from Dan Pritchett’s (eBay) talk"
[3] Leticia Duboc, David S. Rosenblum, and Tony Wicks, "A Framework for Modelling and Analysis of Software Systems Scalability," Proceedings of the 28th international conference on Software engineering, pp. 949 - 952, 2006 ( Syposium Presentation )
[4] Leticia Duboc, David S. Rosenblum, and Tony Wicks, "A Framework for Characterization and Analysis of Software Systems Scalability," in Proceeding of the The 6th joint meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering, ESEC/FSE '07

在 Martin Fowler 的 Refactoring 書 [1] 中提到 :

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure.

然而, 究竟 external behavior 如何認定, 甚麼算是 external behavior, 而甚麼又不是呢 ?

也許我們應該從 refactoring 的目的來看. refactoring 的目的是為了整理目前的 code ( 目前探討 refactoring 停留在 code level 居多, 因此沿用 ), 以便以較少的 time & efforts 進行後續的 software changes [2][3] . 因此 refactoring 可以視為是一種 data pre-processing 的技術, 目的在於把 data, 也就是 code, 調整到一個方便進行後續處理的狀況. 而對於後續要進行的處理來說, 其實 refactoring 的步驟並非是必須的, 只是為了降低整體程序的花費而進行 refactoring, 因此自然不希望在進行 refactoring 的過程中, 會改變 code 本身對於原本要進行的 software changes 之意義. 而這些不允許被改變的部份, 就是 external behavior.

換句話說, 在 refactoring 中, external behavior 的認定跟所要進行的 software changes 有關, 而所要進行的 software changes 又跟 software engineers 有關. 最常見的可能是由 test cases 所保證的 external behavior, 這類型的大多跟 software functionality change 比較有關, 也比較容易理解.

但是從另外一個角度來說, refactoring 畢竟還是改變了 code structure, 對於整個 source code 的意義還是造成了些許的改變, 只是這樣的改變對於要進行的 software changes 來說是否需要關心罷了. 比如說 pull-up-method, 改變前後的意義考量到原始的設計還是有差別的. 只是當我們的目的是方便後續的 maintenance 工作時, 這個差別就會被忽略不計.

然而這樣對於 software maintenance 長期來說是好事嗎 ? 或者只是炒短線的作法呢 ? 畢竟在 [2][3] 中似乎都沒有針對往後其他無關原本預計進行的 software changes 作探討. 然而所作的 refactoring 的的確確影響到了之後相關的 maintenance 工作之進行. 我們應該不能僅僅針對所預計進行的 changes 作有效評估才是.


References

[1] M. Fowler, Refactoring: Improving the Design of Existing Programs, Addison-Wesley, 1999.
[2] E. Stroulia and R. Leitch, "Understanding the Economics of Refactoring," In Proceedings of the 5th International Workshop on Economics-Driven Software Engineering Research (EDSER-5): The Search for Value in Engineering Decisions, May 3-4, 2003, Portland, OR, USA, pp. 44-49.
[3] R. Bahsoon and W. Emmerich, "Applying ArchOptions to Value the Payoff of Refactoring," In Proc. of the 6th Int. Workshop on Economics-Driven Software Engineering Research, Edinburgh, Scotland. pp. 66-70. IEE.

Built-in Test (BIT) 簡單來說就是把 object 內( 在 OO 中來說 )加上 self-testing 的部分, 因而此 object 就會有兩種 modes, 一種是正常的 functional mode, 另一種是 testing mode. 藉由執行 testing mode, 可以確認 object 的運作是否正常, 因而達成 testing 的部分目的. 因為此 tests 是建立在 object 內, 因此叫做 Built-in Test.

下圖取自於 [Wang2000] 可以簡單看出 BIT 的概念, 至於 BIT 的地位以及原始概念可以參考 [Binder1994] :

這些 built-in tests 可能會以 testcases 的方式呈現, 但是基本上跟 JUnit 之類的 testcase 還是有所不同. 例如 BIT 可以測試的對象以及能保證的事情, 跟一般在 object 外部的 testcase 就不完全相同, 同時兩者所持的觀點也不相同.

當然我們也可能把一般的 testcase 整合進 object 內作成 BIT 的樣子, 但是這樣一來就失去了不少 flexibility, 同時也造成 maintainability 的問題. 另外一個問題是, BIT 幾乎只有對原始程式碼了解的人, 可能只有原本的 developers, 可以產生, component consumers 要加入 BIT 有許多困難存在.

References

1. [Binder1994] Robert V. Binder, "Design for Testability in Object-Oriented Systems," Communications of the ACM, vol.37, no.9, pp.87-101, Sept. 1994


2. [Wang2000] Yingwu Wang, Graham King, Mohamed Fayad, Dilip Patel, Ian Court, Geoff Staples, and Maraget Ross, "On Built-in Test Reuse in Object-Oriented Framework Design," ACM Computing Surveys (CSUR), vol.32, no.1es, March 2000