多租戶雲端應用程式之中介軟體框架 - 政大學術集成

全文

(1)國立政治大學資訊科學系 Department of Computer Science National Chengchi University 碩士論文 Master’s Thesis. 立. 政治大. ‧ 國. 學. 多租戶雲端應用程式之中介軟體框架. ‧. A Middleware Framework for Multi-tenant SaaS Applications. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 研究生：陳俊傑指導教授：陳. 恭. 中華民國一零二年七月 July 2013 I.

(2) 多租戶雲端應用程式之中介軟體框架 A Middleware Framework for Multi-tenant SaaS Applications. 研究生：陳俊傑. Student：Jiu-Jye Chen. 指導教授：陳恭. Advisor：Kung Chen. 國立政治大學. 學. ‧ 國. 立. 政治大資訊科學系. Nat. y. ‧. 碩士論文. sit. A Thesis. er. io. submitted to Department of Computer Science. n. a l Chengchi University National iv n. C. U h e n gofcthe in partial fulfillment h i Requirements for the degree of Master in Computer Science 中華民國一零二年七月 July 2013. II.

(3) 多租戶雲端應用程式之中介軟體框架. 摘要. 近年來，雲端運算中的軟體即服務(Software as Service，SaaS)穩健與快速地成長。SaaS 服務提供者在建置服務的過程中，無不希. 政治大. 望盡可能地讓租戶共享資源，避免租戶擁有特殊資源，需要獨立. 立. 維護，以降低維護營運成本。另一方面，也要能讓租戶們擁有一. ‧ 國. 學. 定程度的客製化能力，以製作出屬於租戶私有之服務邏輯。因此. ‧. 如何讓租戶在共有一切資源的前提下，又能提供客製化能力，將. Nat. io. sit. y. 是 SaaS 服務提供者的一大課題。本研究所提出的中介軟體框架將. er. 在共用硬體及資料庫與單一應用程式的共用架構下，採用. al. n. v i n C h資料架構，並提供三大特色功能，Tenant Force.com Universal Table engchi U Aware、Data Access 以及 Tenant Customizability，來解決隔離性、存取 Force.com Universal Table 資料架構以及提供租戶客製化能力三大議題。透過此中介軟體框架應可幫助 SaaS 提供者，建置出一個資源共享、租戶具有客製能力與維護性高的多租戶雲端軟體服務。關鍵字：軟體即服務、多租戶、物件關聯對映、Bytecode 轉換. 1.

(4) A Middleware Framework for Multi-tenant SaaS Applications. Abstract. In recent years, Software as a service (SaaS), the service model of cloud computing, has been growing healthy and rapidly. When SaaS providers build service, they want tenants to share same resources, and not to have its own special resource which will cause providers to maintain it. 政治大 But the current trend. separately. SaaS providers want tenants sharing the same resources to. 立. reduce maintenance cost.. is to provide the. ‧ 國. 學. customizability to tenants for customizing its own service. How to share resources under the premise of providing customizability to tenants will. ‧. be the main challenge to SaaS providers. In this thesis, we propose a middleware framework based on shared hardware、database with a single. y. Nat. io. sit. application instance. Our framework will use the Force.com Universal. a. er. Table schema as the foundation. The key features of our framework are. n. iv Tenant Aware、Data Access These features l and Tenant Customizability.. n U e n g ctenants, h i accessing isolating. Ch. will address the issues of. the Force.com. Universal Table schema and providing customizability to tenants. This middleware. framework. resource-sharing,. will. customizable. help. SaaS. providers. multi-tenant. SaaS. to. build. with. maintenance cost.. Keywords : SaaS、Multi-tenant、ORM、Bytecode Transformation. 2. a. lower.

(5) 誌謝感謝老師陳恭教授的細心教誨，無論是課堂上的教學或論文的指導，均給予細心的教導與啟發，以培養學生獨立思考與創新研究的能力。同時也要感謝家人、朋友以及同事的支持、鼓勵與包容，讓我得以在這兩年的過程中能專心完成研究工作。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 3. i n U. v.

(6) 目. 錄. 第一章緒論 ................................................................................................................. 8 1.1 研究背景.......................................................................................................... 8 1.2 研究動機........................................................................................................ 11 1.2.1 資料綱要............................................................................................. 11 1.2.2 領域邏輯............................................................................................. 14 1.2.3 外觀..................................................................................................... 14 1.2.4 小結..................................................................................................... 15 1.3 研究目標........................................................................................................ 15 1.4 論文貢獻........................................................................................................ 16 1.5 論文之限制 ................................................................................................... 16 1.6 論文章節架構 ............................................................................................... 17. 立. 政治大. ‧. ‧ 國. 學. 第二章相關研究與技術背景 ................................................................................... 18 2.1 多租戶 SaaS 資料層設計 ............................................................................. 18 2.2 Force.com Universal 資料架構 ................................................................... 21 2.2.1 Objects、Fields、Data 資料表 .......................................................... 22 2.2.2 Indexes、UniqueFields 資料表.......................................................... 24 2.2.3 Relationships 資料表 .......................................................................... 25. y. Nat. sit. n. al. er. io. 2.3 多租戶 SaaS 資料存取 ................................................................................. 27 2.4 多租戶 SaaS 隔離性 ..................................................................................... 28 2.5 Bytecode 轉換工程 ....................................................................................... 29 第三章中介軟體框架 ............................................................................................... 31 3.1 中介軟體框架設計目標 ............................................................................... 31 3.2 框架特色........................................................................................................ 32. Ch. engchi. i n U. v. 3.2.1 Tenant Aware ....................................................................................... 32 3.2.2 Data Access ......................................................................................... 33 3.2.3 Tenant Customizability ....................................................................... 33 3.3 框架架構設計 ............................................................................................... 34 3.4 框架實作設計 ............................................................................................... 36 3.4.1 Tenant Context .................................................................................... 36 3.4.2 Object Relational Mapping ................................................................. 37 3.4.3 UtbDBService ..................................................................................... 40 3.4.4 Customization API .............................................................................. 49 3.4.5 Bytecode Transformation .................................................................... 51 第四章多租戶 SaaS 實作 ......................................................................................... 54 4.

(7) 4.1 多租戶 SaaS 架構設計 ................................................................................. 54 4.2 多租戶 SaaS 實作設計 ................................................................................. 56 4.2.1 Tenant Aware 使用方式 ...................................................................... 56 4.2.2 Data Access 使用方式 ........................................................................ 57 4.2.3 Tenant Customizability 使用方式 ...................................................... 59 4.3 多租戶 SaaS 效能測試 ................................................................................. 61 第五章結論與未來研究方向 ................................................................................... 66 5.1 結論................................................................................................................ 66 5.2 未來研究方向 ............................................................................................... 67 參考文獻...................................................................................................................... 69. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 5. i n U. v.

(8) 表目錄. 1.1 DataNucleus RDBMS Plugin 修改清單 ............................................... 38 4.1 效能測試結果........................................................................................ 64. 圖目錄. 政治大. 1.1 多租戶 SaaS 共用架構設計模型......................................................... 10 1.2 租戶私有資料表設計........................................................................... 11 1.3 Extension 資料表設計......................................................................... 12 1.4 Universal 資料表設計 ......................................................................... 12 1.5 Pivot 資料表設計 ................................................................................ 12 1.6 Chunk 資料表設計 .............................................................................. 13 1.7 Chunk Folding 資料表設計 ................................................................ 13 2.1 多租戶資料層級技術典型.................................................................. 19 2.2 Force.com Universal Table 資料架構 ................................................. 21 2.3 Data、Objects、Fields 資料表關係 ................................................... 23 2.4 Universal Table 查詢 SQL 指令 .......................................................... 23 2.5 Data、Indexes、UniqueFields 資料表關係 ....................................... 24 2.6 Universal Table Join 查詢 SQL 指令 .................................................. 26 2.7 Data、Relationships 資料表關係 ....................................................... 26 3.1 基於 MTA Framework 的多租戶 SaaS 架構圖 ................................... 32 3.2 MTA Framework 架構圖 ..................................................................... 34 3.3 Tenant Context 結構設計 .................................................................... 36 3.4 DataNucleus 架構圖 ............................................................................ 37 3.5 UTbServiceHelper 內部設計 .............................................................. 39 3.6 MTA Framework 資料模型 ................................................................. 41 3.7 Associations 資料表 ............................................................................ 42 3.8 Relationships 資料表修改結果 ........................................................... 44 3.9 產生 Select SQL 指令規則 ................................................................. 45 3.10 中介軟體框架產生查詢 SQL 指令 .................................................... 45 3.11 產生 Insert SQL 指令規則 ................................................................ 46. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 6. i n U. v.

(9) 3.12 中介軟體框架產生新增 SQL 指令 .................................................... 47 3.13 產生 Delete SQL 指令規則 ................................................................ 47 3.14 中介軟體框架產生刪除 SQL 指令 .................................................... 48 3.15 產生 Update SQL 指令規則............................................................... 48 3.16 中介軟體框架產生修改 SQL 指令 .................................................... 49 3.17 CustomObject、CustomField 結構設計 ............................................. 49 3.18 CustomObject、CustomRelationship 結構設計 ................................. 50 3.19 CustomizationHandler 結構設計 ........................................................ 51 3.20 @MultiTenantable 示意圖 .................................................................. 52 3.21 MTAJavaAgent、MTAClassFileTransformer 結構關係 .................... 52 3.22 MTA Framework runtime bytecode transformation 機制 ................... 53 4.1 購物商城 SaaS 使用案例...................................................................... 54 4.2 購物商城 SaaS 架構設計...................................................................... 55 4.3 購物商城驗證機制與 TenantContext 結構關係 .................................. 57 4.4 Order 類別套用 JDO Annotations 程式碼片段.................................... 58 4.5 JDOQL 程式碼片段 .............................................................................. 58 4.6 宣告@MultiTenantable 程式碼片段 .................................................... 59 4.7 MTAJavaAgent 初始化程式碼片段 ..................................................... 60 4.8 Product 類別實現 CustomObject 結構關係 ......................................... 60 4.9 開發人員如何取得租戶自定義欄位範例............................................ 61 4.10 購物商城 SaaS 資料綱要 Index 圖 .................................................... 62 4.11 測試環境佈署圖 .................................................................................. 63 4.12 效能測試結果...................................................................................... 64 5.1 CustomObject、CustomMethod 結構設計........................................... 68. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 7. i n U. v.

(10) 第一章緒論近年來雲端運算快速地發展，相關技術與環境也日益成熟，美國國家標準技術局 (the National Institute of Standards and Technology，NIST)也對雲端運算做出最終的定義： ” 雲端運算具備五個基礎特徵分別是隨需自助服務 (On-demand. 政治大源池(Resource Pooling)、快速重新部署靈活度(Rapid Elasticity)以及被監控與量測立 Self-service)、隨時隨地用任何網路裝置存取(Broad Network Access)、多人共享資. ‧ 國. 學. 的服務(Measured Service)” [1]。此外定義中還提到雲端運算有三種服務模式，分別為 Software as a Service(SaaS)、Platform as Service(PaaS)以及 Infrastructure as. ‧. Service(IaaS)。. sit. y. Nat. 針對服務模型中的 Software as a Service (SaaS)，Gartner, Inc 在 2012 年預估. al. er. io. 全球 Software as a Service (SaaS)當年的收入將可達到 145 億美元，比起 2011 年. v. n. 的收入 123 億美元成長了 17.9 個百分比。Gartner, Inc 也進一步指出全球 Software. Ch. engchi. i n U. as a Service (SaaS)將會穩健地成長至 2015 年，並預測收入可達 221 億美元[2]。由此可見 Software as a Service (SaaS)的市場是相當的龐大，使得獨立軟體供應商 (Independent Software Vendor，ISV)紛紛試圖在雲端上打造屬於自己的服務。. 1.1 研究背景目前指標性的 SaaS 有 Google 的 Apps 或是 Microsoft 的 Office 365，兩者在其 SaaS 中主要提供了電子郵件、行事曆、文件編輯…等服務。但除了這種具有普遍性需求的 SaaS 外，還有一種 SaaS 是把企業專用的應用程式(例如：ERP、CRM、HCM… 等)搬上雲端，當中最具代表性則為 Salesforce.com 的 CRM，這一類型的 SaaS 與 8.

(11) 一般性的 SaaS 最大的差別在於不同租戶之間其商業邏輯多少有所差異，因此這類型的 SaaS 除了滿足一般性的商業邏輯外，必須還要讓租戶能夠進行客製化。假設一般的 ISV 希望把自家原本的所開發的企業應用程式跟 Salesforce.com 一樣轉移至雲端成為 SaaS，通常都不會那麼的順利。主要是因為傳統上我們在設計應用程式時，設計思維大都專注於滿足該領域的普遍性的功能需求。但實際上一旦提供給客戶使用時，不同的客戶便會有其特殊的需求。此時我們為了滿足該客戶的特殊需求，勢必需要修改原本的應用程式進行客製化。如果這只是一般的企業所獨自使用的應用程式，這樣的情境並不會造成太大的問題，因為每個企. 政治大應用程式對於 ISV 而言，並不會造成太大的成本。立. 業客戶有其專屬的實體(硬體設備、資料庫、應用程式、資料綱要)，不同版本的. 可是一旦客製化的情境來到雲端上就將會是一大設計挑戰，因為一個多租戶. ‧ 國. 學. SaaS 最大的優勢在於經濟上的效益，客戶們能以便宜價格使用該服務。為何多. ‧. 租戶 SaaS 的價格是較便宜的？因為不同的客戶是共用一組硬體設備、同一套的. y. Nat. 應用程式實體以及同一個資料庫與同樣的資料綱要，如此一來 SaaS 提供者在開. er. io. sit. 發、維護、擴充上只需專注在同一個實體上，不須付出額外的成本來提供不同的實體給客戶使用。由此我們可以了解到 SaaS 在提供客製化能力時勢必與其實體. al. n. v i n 共用架構設計息息相關。ISV C 如仍以傳統的方式設計 SaaS，未把多租戶 SaaS 的 hengchi U. 實體共用議題包含進去設計時，一旦遇到客戶有特殊需求時，勢必以傳統方式增加實體的解決方案來滿足客戶的特殊需求，造成此多租戶 SaaS 營運成本。. 因此一個 SaaS 提供者必須優先決定其實體共用的程度，此共用程度將會影響實際 SaaS 的設計方式，以下為三種基本多租戶 SaaS 共用資源的架構設計模型 [3] 。. 9.

(12) 圖 1.1：多租戶 SaaS 共用架構設計模型。. 1.. 政治大共用硬體(Shared Hardware)：透過虛擬化的技術，共用同一套硬體設施，立然而不同的租戶仍然使用不同的應用程式及資料庫與資料綱要。. ‧ 國. 學. 2.. 共用硬體(Shared Hardware)、單一應用程式(Single Application) ：共用同. 共用硬體及資料庫(Shared Hardware、Database)單一應用程式(Single. y. Nat. 3.. ‧. 一套硬體設施及應用程式，但資料庫仍是各自獨立的。. 區分租戶是否共用同一套資料綱要設計[4]. n. al. Ch. engchi. er. io. sit. Application) ：在共用資料庫下，當中的資料綱要(Data Schema)設計又可. i n U. v. 共用架構設計模型中的第三種方式(共用硬體及資料庫與單一應用程式)，是最符合經濟效率的方式，因為租戶們全都共用相同的實體。此外假設我們在建置多租戶 SaaS 使用了第三種方式並搭配共用資料綱要，便能以最有效率的方式節省成本，因為每一個資料庫都將能服務其最大限度的租戶數。這也是多租戶 SaaS 一再強調的優點，因此建置一個多租戶 SaaS 理應採共用硬體及資料庫與單一應用程式、資料綱的方式來建置，本研究也將採用此方式作為研究中 SaaS 的共用架構。. 10.

(13) 1.2 研究動機一個具有經濟效益的多租戶 SaaS 勢必會採用共用硬體及資料庫與單一應用程式及資料綱要的共用架構，但在這樣的架構底下，SaaS 服務提供者該如何提供租戶客製化能力? 一般說來，針對租戶需求可以進行三種主要的客製化：資料綱要、應用程式外觀以及領域邏輯的部分。以下將就這三個部分如何客製化進行探討。. 1.2.1 資料綱要. 政治大才能讓租戶們擁有自己的資料綱要呢? Aulbach et al. [5] 的研究中歸納了六種資立首先來看資料綱要的部分，在租戶們共用資料綱要的情境下，應該如何設計. ‧ 國. 學. 料綱要的設計方式，可以讓租戶們在共用資料綱要時，同時又可以客製化自己的資料綱要。這六種方式分別為：. ‧. 1.. Private Table：傳統的方式為如果租戶們希望客製資料表(Tables)，則讓他. n. al. y. er. io. sit. Nat. 們擁有自己的資料表，私有的資料表不共用。. Ch. engchi. i n U. v. 圖 1.2：租戶私有資料表設計，本圖取自[5]。. 2.. Extension Table：如同物件導向物件的繼承父類別與子類別一樣，共用的欄位資料至於同一個資料表，每個租戶客製化的欄位各自建立擴充資料表。. 11.

(14) 圖 1.3：Extension 資料表設計，本圖取自[5]。. 3.. Universal Table：將所有租戶的資料共同放置於一個包含大量欄位的資料表，利用租戶編號與資料表名稱欄位來區分不同租戶的資料。. ‧. 圖 1.4：Universal 資料表設計，本圖取自[5]。. sit. y. Nat. Pivot Table：採用了一種泛型的結構，不同的型別的資料有其獨立的資料. io. er. 4.. 學. ‧ 國. 立. 政治大. 表，租戶們的資料會根據其資料型別分別存放在這些的資料表中。. n. al. Ch. engchi. i n U. v. 圖 1.5：Pivot 資料表設計，本圖取自[5]。. 5.. Chunk Table：如同 Universal Table 與 Pivot Table 是一種泛型的結構，改良自 Pivot Table，但它不特別建立獨立的資料型別資料表，反而是將租戶資料依型別存放於不同的欄位內，改以一組固定數量的型別欄位稱之 12.

(15) 為 Chunk。. 圖 1.6：Chunk 資料表設計，本圖取自[5]。. 6.. Chunk Folding：混和了 Extension Table 與 Chunk Table 概念，在租戶欄位. 政治大客製的欄位資料則儲存在採用 Chunk Table 設計的擴充資料表中。立. 資料共用的部分採用了 Extension Table 父資料表的概念，每個租戶特殊. ‧. ‧ 國. 學 er. io. sit. y. Nat. al. v. n. 圖 1.7：Chunk Folding 資料表設計，本圖取自[5]。. Ch. engchi. i n U. 這六種方式分別有各自的優缺點，SaaS 服務提供者可從這六種資料綱要設計方式中找出一個最適合自己的資料架構(Data Architecture)設計，但不同的資料架構在存取資料時，必須採用適用其架構的 SQL 指令，這些 SQL 指令又與傳統的寫法有所不同。假設服務提供者選擇使用 Universal Table 資料綱要，但此資料綱要由於隱藏了 Data 資料表中欄位的意義，服務提供者的開發人員必須藉由其他文件的幫助，才能有效的了解這些資料欄位的意義，一不小心即可能造成程式 bug 的產生。. 13.

(16) 1.2.2 領域邏輯一般 ISV 在開發應用程式時，會依據該應用程式所處理的領域，設計出負責處理該領域相關業務邏輯的領域物件(Domain Object)。因此在談到如何讓租戶客製應用程式邏輯時，其實也就是租戶們如何新增或修改這些領域物件進而客製出屬於自己的商業邏輯。客製化領域物件主要分為兩個部分，分別是客製物件的狀態(State)及行為 (Behaviors) ；狀態對應到物件的欄位 (Fields) ，行為則對應到物件的方法 (Methods)。客製化功能又分為新增跟修改，這兩者在設計上有其困難度上的區. 政治大資料架構，新增物件的欄位必須配合不同的資料綱要而有不同的設計方式。立. 別。首先針對客製物件狀態來討論，狀態的客製化必須搭配服務提供者所選擇的. 但反觀修改既有領域物件的欄位，有其一定的難度，因為原本 ISV 所設計. ‧ 國. 學. 的領域物件是提供給所有租戶使用的，一旦租戶們修改了既有領域物件的欄位. ‧. 後，這個領域物件便不再是共用的領域物件而是某個租戶其私有的領域物件。. y. Nat. ISV 的 SaaS 該如何針對不同的租戶，把共用領域物件轉化成其私有的領域物件?. er. io. sit. 加上在設計階段時 ISV 並無法預測未來租戶們會如何修改既有的領域物件，因此如何設計出一個能具有彈性的軟體架構是一大難題。. al. n. v i n 針對客製化領域物件行為的部分，勢必也是需要新增或修改領域物件的方 Ch engchi U. 法，這代表 ISV 必須讓租戶可以透過設定的方式或是撰寫其提供的領域專屬語. 言(Domain Specific Language)，如同 Salesforce.com 所提供的 Apex 語言，藉由此方式來實現租戶特殊的領域邏輯。新增或修改領域物件方法如何納入至領域物件中是一個難度極高的功能，對於軟體架構設計同樣也是極高的挑戰。. 1.2.3 外觀由於 SaaS 的外觀上主要仰賴於 HTML(HyperText Markup Language) 與 CSS(Cascading Style Sheets)，因此在設計上 ISV 必須讓租戶們可以自行撰寫屬於自己的 HTML 與 CSS。目前主流的內容管理系統(Content Management System， 14.

(17) CMS )，例如：Drupal、Joomla、SharePoint、...等，皆可以讓 CMS 管理者，透過樣板機制(Template Mechanism)，建立屬於自己的外觀。不同的 CMS 可能對樣板有不同的名稱定義，例如：Theme、Skin、…等，但其本質是相同，皆是讓 CMS 管理者撰寫樣板，這個樣板必須符合其所規範的 HTML 與 CSS，接著套用至系統當中，CMS 便會針對不同的樣板產生出不同的外觀。. 1.2.4 小結綜合以上所述，建置一個具有客製能力的多租戶 SaaS 除了要專注在設計服務的功能外，還必須花費額外的精力處理以上所列出的多租戶 SaaS 的設計議題。首. 政治大. 先必須決定一個多租戶 SaaS 共用架構，因為租戶共用實體的程度將會影響到多. 立. 租戶 SaaS 的隔離程度(Isolation)、安全性(Security)、客製化能力(Customizability)、. ‧ 國. 學. 可維護性(Maintenance)、復原能力(Recovery)；可見決定一個共用架構是相當的重要，然而為了獲取最高的經濟效益，ISV 勢必要選擇共用程度最高的架構，但. ‧. 建置上也相對的困難。. y. Nat. sit. 此外，為了讓多租戶 SaaS 具備客製化能力，必須針對資料綱要、應用程式. n. al. er. io. 邏輯及外觀進行額外的設計，才能使得租戶們自行設計屬於他們私有的虛擬應用. i n U. v. 程式。但在資料綱要的部分，雖然有六種 Schema 提供給服務提供者參考，可是. Ch. engchi. 其開發人員必須非常熟悉此模型的運作原理，才能撰寫出正確的 SQL 指令，並且必須花費相當多的精力來撰寫額外的程式碼來整合資料與領域物件。至於應用程式領域邏輯與外觀的客製化設計則仰賴於開發團隊的軟體設計能力，假設客製化功能的設計不良容易造成日後維護與改版的困難度。. 1.3 研究目標本論文基於前述的研究背景與動機，探討如何實現一中介軟體框架(Middleware Software Framework，以下文中所提及中介軟體框架皆指本研究之中介軟體框架)，透過此中介軟體框架幫助 SaaS 提供者建置出一個資源共享、租戶具有客製 15.

(18) 能力與維護性高的多租戶雲端軟體服務。本研究主要目標為： 1.. 實現 Force.com 所提出的 Universal Table 資料架構。. 2.. 擴充合適的物件關聯對映(Objet Relational Mapping，ORM)框架，以支援 Force.com Universal Table 資料架構。. 3.. 透過剖面導向(aspect-oriented)原理，整合以上兩項機制，提供多租戶 SaaS 客製化能力。. 4.. 以本論文之中介軟體框架實作出具有客製化能力的多租戶 SaaS 雛形。. 立. 1.4 論文貢獻. 政治大. ‧ 國. 學. 本論文在實現中介軟體框架的過程中，分析了使用 Universal Table 資料架構的優缺點，並利用此資料架構實現租戶資料的虛擬隔離性，進而能提供虛擬資料庫的. ‧. 功能給予多租戶 SaaS 的租戶使用。在資料存取的部分，本論文修改一套目前主. sit. y. Nat. 流的 ORM 框架的擴充套件，藉由此擴充套件提供 SaaS 開發人員在建置開發多. al. er. io. 租戶 SaaS 時，仍可使用其慣用的 ORM 風格存取資料。至於在多租戶 SaaS 租戶. v. n. 客製化能力的提供上，本論文基於剖面導向原理，在中介軟體框架中實現如何讓. Ch. engchi. i n U. 租戶們可以新增其領域物件以及修改既有的領域物件。. 1.5 論文之限制本論文之中介軟體框架採用 Java 來實現，J2SE 版本為 1.5；因此使用中介軟體框架的多租戶 SaaS 其 Java 版本必須為 5 或是更高。本論文所使用的資料庫為 MySQL 5.5.31，所擴充的 ORM 套件目前也只支援產生能執行於 MySQL 的 SQL 指令，ORM 規格只支援 Java Data Object(JDO)。. 16.

(19) 1.6 論文章節架構本論文分為五個章節：第一章為研究源起與論文目標、貢獻及限制；第二章介紹與本論文中介軟體框架有關的研究以及所使用技術的背景知識；第三章將探討多租戶 SaaS 中介軟體框架設計目標與特色，並針對框架架構與實作設計進行說明；第四章介紹如何使用本論文中介軟體框架實作出具有客製化能力的多租戶 SaaS，以及此 SaaS 的效能測試結果；第五章提出結論及未來可能的發展。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 17. i n U. v.

(20) 第二章相關研究與技術背景本章節將針對多租戶 SaaS 在共用硬體及資料庫與單一應用程式及資料綱要的系統架構下，探討多租戶資料層的設計與存取方式，租戶應用程式與資料的隔離性的實現方式、以及客製領域邏輯之相關研究與技術背景。. 立. 政治大. 2.1 多租戶 SaaS 資料層設計. ‧ 國. 學. 1.2 小節中提到最符合經濟效率的共用架構設計為共用硬體及資料庫與單一應用程式，並搭配共用資料綱要的設計，便能以最有效率的方式節省成本，因為每一. ‧. 個資料庫都將能服務其最大限度的租戶數，每年將可省下數百萬美元之成本。然. y. Nat. sit. 而 Aulbach et al. [5]發現，大部份難以解決的多租戶技術議題都出現於「資料. n. al. er. io. 層」，資料層的多租戶技術主要面臨的挑戰包含多租戶同時競爭分享的資源所造. i n U. v. 成的效能問題及安全問題，以及共享資料庫及資料表時所造成的擴充性問題。因. Ch. engchi. 此，當前大多數多租戶研究皆聚焦於此類資料層之共享問題。在多租戶 SaaS 中，如何提高租戶間資料存放的共享程度是很重要的議題。由於租戶資料的安全性以及資料量大小都會造成開發者在設計多租戶資料層級架構有不同的考量，於是，租戶間在資料存放的共享程度也會因採取的技術不同而改變。Liao et al. [6]將資料層級的多租戶技術依資料分隔程度及各租戶自訂綱要的彈性將現行技術分為四個典型(如下圖)。. 18.

(21) 圖 2.1：多租戶資料層級技術典型，本圖取自[6]。. 第一類 Shared Table，Shared Schema 又稱為 Basic Layout (Aulbach et al.. 政治大料庫中的一組資料表，Shared 立 Schema 代表租戶們的資料綱要都是相同的。此技. [5] )，Shared Table 代表租戶們的資料都保存於同一儲存空間，例如：關聯式資. ‧ 國. 學. 術典型在實現上最為容易，只要在 Shared Table 中加上租戶識別碼欄(Tenant Id) 即可區分所有租戶，而且很容易就可以透過資料切片(Sharding)技術大幅擴充資. ‧. 料的延展性，在有限的硬體環境中仍可提供給較多租戶使用。然而，其主要問題. sit. y. Nat. 即為彈性，因為所有租戶的 Schema 必須相同，也缺乏安全性，因為所有租戶的. al. er. io. 資料均位於同一個資料表。此外，Aulbach et al. [5]也發現，個別租戶回復資料，. n. 在這種資料架構下會變得相當困難。. Ch. engchi. i n U. v. 反之，第二類的 Private Table, Shared Schema 由於每個租戶資料存在各自的資料表，因此具備較高的安全性。但 Schema 方面仍然有缺乏彈性的缺點。此外，由於每個租戶都具有獨立不共享的資料表，因此實作的成本高，很難達到規模經濟的效益。第三類 Private Table, Private Schema 又被稱為 Private Table Layout (Aulbach et al. [5])，是讓個別租戶具有客製自訂欄位能力最簡單的設計方式，和其它架構相比，這種做法具有最高的安全性及彈性，但從另一面來看，這種做法同時也具有成本高與實作困難 (因為每個租戶具有個別的 Schema，在設計共通的 SQL Rewriting 較為複雜) 的缺點。. 19.

(22) 目前大部份的資料層級多租戶架構研究與應用都屬於最後一類：Shared Table, Private Schema。這種資料架構相較於 Private Table，Private Schema 雖然安全性較低，需要其它機制來補強，但由於具有成本低(Shared Table)且彈性高的優勢，因此也是現在業界最廣為採用的資料架構。由於採用 Private Schema，因此其實作難度顯然較高，也因此在實作策略上也存在多種不同型式設計方式，大部份都是基於早期學術界所提出之創新資料儲存結構改良而來，例如 Extension Table (Copeland & Khoshafian [7])、XML Table(Foping et al. [8]；Du et al. [9]) 與 Universal Table (Maier et al. [10])。. 政治大需要一個，配合資料切片技術(Database Sharding)，可以較容易加以延展。此外，立 Universal Table 在規模經濟效益上表現最佳，由於無論多少租戶，Table 都只. 由於不受型別資訊的限制，相較於其它資料配置方式，較容易延展擴充(Aulbach. ‧ 國. 學. et al. [5])。知名的 SaaS 服務提供廠商 Force.com 內部所採之多租戶架構即為基於. ‧. Universal Table 改良而來(Weissman & Bobrowski [11])。. y. Nat. 然而，Universal Table 必須事先配置定量的欄位，在租戶佔用欄位數相差很. er. io. sit. 多時，將造成許多空間浪費(太多 Null 值)。此外，由於欄位並未規範型別，應用程式讀出一個 row 之後，每一個 field 的型別必須靠應用程式自行解讀，應用程. al. n. v i n 式可能會有較多的負擔或容易出錯。針對以上問題，也有許多研究基於 Universal Ch engchi U. Table 加以延伸改良，例如 Pivot Table(Grust et al. [12]，Beckmann et al. [13])、Chunk Table (Aulbach et al. [5]) 及 Chunk Folding(Aulbach et al. [5])等。雖然 Pivot Table、Chunk Table 及 Chunk Folding 針對 Universal Table 進行改良，但這三者在 Metadata 的設計上主要還是針對擴充資料表的欄位，因此將欄位 Metadata 的資訊與資料保存在同一個資料表中。Force.com 所改良的 Universal Table 資料架構不同於這三者，其將 Metadata 資訊獨立出來保存，這樣的好處在於除了可實現擴充資料表欄位外，還可建立虛擬資料表的關聯。此外 Force.com Universal Table 資料架構也加入特殊目的 Pivot Table 來增加查詢效能。中介軟體框架以 Force.com Universal Table 資料架構為資料層的基礎，接著將針對 20.

(23) Force.com Universal Table 資料架構做詳細的說明。. 2.2 Force.com Universal Table 資料架構 Force.com 改良的 Universal Table 資料架構將資料表歸納成三種類型，分別為 Metadata Tables、Data Tables 以及 Specialized Pivot Tables，利用這三類型的資料表建置一個虛擬資料庫[11]，以下為 Force.com 的 Universal Table 設計模型：. 立. 政治大. ‧. ‧ 國. 學 sit. y. Nat. n. al. er. io. 圖 2.2：Force.com Universal Table 資料架構，本圖取自[11]。. 1.. Ch. engchi. i n U. v. Metadata 類型的資料表示用來描述租戶資料的樣貌，這當中 Objects 資料表讓租戶們可以建立自己的物件，如同一個虛擬資料表。Fields 資料表則是讓租戶們建立客製物件中的客製欄位，並指定欄位的資料型別。. 2.. Data 類型的資料表中有 Data 資料表，當中保存了所有租戶的資料，此外資料的保存統一使用字串資料型別，之後再利用 Fields 當中所記載的實際型別進行對應。Clobs 資料表則保存了租戶非結構化文字資料。. 3.. Specialized Pivot 資料表主要在維護 Data 資料表中的非正規化資料，並利用當中資料加速取得租戶在 Data 資料表中的資料。雖然 Force.com 並未把全部的 Pivot 資料表公布，但主要有 Indexes 、 UniqueFields 、 21.

(24) Relationships、NameDenorm 以及 FallBackIndex 資料表。由於 Data 資料表中所保存的租戶資料都是字串，因此不可能使用關聯式資料庫的 Index 功能來建置索引加速查詢速度，所以把 Data 資料表中 Value 欄位的值複製到 Indexes 後再建立關聯式資料庫的索引。UniqueFields 的功能如同 Indexes 資料表，但 Indexes 中的索引值是可以重複的，不過 UniqueFields 是不可重複。Relationships 則是記錄了 Objects 之間關聯的索引，當需要使用到 join 進行查詢時，便會利用到此資料表。NameDenorm 則是提供快速查詢 Object 名稱與 Id 的索引。此外當 Force.com 搜索引擎出問題或. 政治大. 是負載過高時，Force.com 的查詢機制便會使用 FallBackIndex 中資料來完成查詢請求。. 立. ‧ 國. 學. 雖然 Force.com 並未公開其資料模型全部的細節，但根據文獻可以推論出其. Nat. y. ‧. 資料模型的內部細節，以下將針對其內部細節說明。. er. io. sit. 2.2.1 Objects、Fields、Data 資料表. Data 資料表中保存了租戶的資料，Objects 與 Fields 則保存了資料的詮釋資料. al. n. v i n (Metadata)，Objects 當中的每筆資料就如同關聯式資料庫的資料表(Table)，Fields Ch engchi U. 中的資料就如同資料表中的欄位(Column)。以下為這個三個資料表的內部的細節欄位：. 22.

(25) 政治大. 圖 2.3：Data、Objects、Fields 資料表關係。. 立. ‧ 國. 學. Data 資料表的欄位中主要有 DataGuid 為主鍵(Primary key)，當中使用全域唯一識別碼(Global Unique Identifier)產生器所產生的文字做為唯一值。TenantId 為. ‧. 租戶 Id，ObjectId 則是此租戶所擁有的 Object 的 Id，ObjectName 則是該 Object. y. Nat. sit. 的名稱，因此使用 TenantId 與 ObjectId，我們便可知道某筆資料的租戶是誰，該. n. al. er. io. 筆的資料所對應的 Object 為哪一個。實際的資料則是保存在 Data 資料表中以. i n U. v. Value 為開頭的欄位中，由 0 至 500，這些 Value 欄位便是未來提供給租戶擴充所. Ch. engchi. 預留的。假設這筆資料有四個欄位的值要保存，便是存在 Value0、Value1、Value2、 Value3 這四個欄位中。假設我們要查詢 TenantId 為 1，ObjectId 為 1，Value0 欄位值為 1 的資料，所需要執行的 SQL 指令如下： Select Value0 , Value1 , Value2 , Value3 from Data where TenantId=1 and ObjectId=1 and Value0=1 圖 2.4：Universal Table 查詢 SQL 指令。. 查詢出結果後，由於欄位的意義已被一般化成 Value 來表達，因此我們需要透過 Objects 與 Fields 這兩個 Metadata 資料表來獲得資料實際所代表的意義。在 23.

(26) Objects 資料表中有 ObjectId 與 ObjectName 欄位，分別代表 Object 的唯一 Id 與名稱。一個 Object 所擁有的 Field 則是保存在 Fields Metadata 資料表中，Fields 資料表中有 FieldId、ObjectId、FieldName、FieldNum、FieldType 以及 IndexType。 FieldNum 是當中邏輯最為重要的欄位，因為透過 FieldNum 可以對應回 Data 資料表中 Value 的編號，假設 FieldNum 的值為 0 對應的 Value 欄位為 Value0，如此我們才能真正了解 Data 資料表中 Value 欄位實際的意義。FieldId 是 Field 的唯一 Id，FieldName 為其名稱，FieldType 是此 Field 實際的資料型別，IndexType 則為此 Field 是否被建立索引或者其索引類型為何。當然這兩個資料表都有. 政治大. TenantId 的欄位，才能區別是和租戶所擁有的。. 立. 2.2.2 Indexes、UniqueFields 資料表. ‧ 國. 學. 由於 Data 資料表中所保存的租戶資料的 Value 欄位中都是使用字串，不區分資. ‧. 料實際型別的，因此無法使用關聯式資料庫索引的功能來加速查詢。Force.com. y. Nat. 特別建立了 Indexes 與 UniqueFields 這兩個資料表來間接使用關聯式資料庫的索. n. al. er. io. 料表欄位如下：. sit. 引功能，Data、Indexes 與 UniqueFields 三者關係以及 Indexes 與 UniqueFields 資. Ch. engchi. i n U. v. 圖 2.5：Data、Indexes、UniqueFields 資料表關係。. 24.

(27) Indexes 與 UniqueFields 資料表內部欄位都是一樣的，兩者的差別在 UniqueFields 資料表當中索引值是不可重複的。Indexes 與 UniqueFields 資料表使用 TenantId、ObjectId、FieldNum 以及 DataGuid 這四個欄位做為複合主鍵來保持唯一性。 TenantId 代表為哪個租戶，ObjectId 代表此租戶的哪個 Object，FieldNum 欄位則與 Fields 資料表中的 FieldNum 用意一樣，記錄這個 Field 是 Data 資料表中哪個 Value 欄位。 Force.在儲存資料時，會同步把需要建立關聯式資料庫索引的資料複製一份到 Indexes 或 UniqueFields 中，此時需要建立索引的 Value 欄位值便會根據其實. 政治大 StringValue、NumValue、DateValue…等具有型別意義的欄位，屬於 String 的資料立. 際的資料型別來保存，因此我們在可以看到 Indexes 及 UniqueFields 中有. 便會儲存在 StringValue 中，屬於數字的資料便會儲存在 NumValue 中，依此類推。. ‧ 國. 學. 藉由上述的設計方式，Force.com 的 Query Optimizer 在接受到查詢請求時，. ‧. 會去判斷查詢條件中是否有建立索引的欄位，如果有的話便會先到 Indexes 或是. y. Nat. UniqueFields 中先查出 DataGuid；這時由於 Indexes 與 UniqueFields 儲存資料的. er. io. sit. 欄位都能依照其實際資料型別儲存，便可以利用關聯式資料庫的索引功能加速查詢。取得 DataGuid 後再至 Data 資料表取得完整的資料，因為 DataGuid 為 Data. al. n. v i n 資料表的主鍵，所以使用此欄位進行查詢，在查詢上的速度同樣也會受惠於關聯 Ch engchi U 式資料庫索引功能。. 2.2.3 Relationships 資料表租戶們的資料統一儲存在 Data 資料表中，因此假如需要使用到 Join 查詢時，便需要利子查詢(sub query)的 SQL 指令，以下將以訂購與訂購明細的 Join 查詢 SQL 指令做為例子： Select * from (Select Value0 as OrderId , Value1 as OrderDate from Data where TenantId = 1 and ObjectId= 1 and Value0=1) o. 25.

(28) inner join (Select Value0 as OrderLineitemId , Value1 as OrderId , Value2 as ProductId , Value3 as Qty from Data where TenantId = 1 and ObjectId= 2 ) oi on oi.OrderId= o.OrderId 圖 2.6：Universal Table Join 查詢 SQL 指令。. 我們分別利用兩個子查詢查出訂購與訂購明細的資料後再利用 OrderId 將這. 政治大因此 Force.com 特別設計了一個 Relationships 資料表來改善 Join 查詢速度。但立. 兩個子查詢 Join 起來。但子查詢的方式在資料量大時，查詢效能並不如人意，. Force.com 並未在其論文中公開 Relationships 資料表的欄位資訊，反而是在其開. ‧ 國. 學. 發白皮書[14]中公開了 Relationships 資料表的欄位資訊，Data 與 Relationships 資. ‧. 料表關係如下：. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 2.7：Data、Relationships 資料表關係。. Force.com 針對某 Object 建立與其他 Object 的關聯性後，會在此 Object 的資料中保存有關聯的 ObjectId 於 Data 資料表的 Value 欄位中，並且在儲存資料時，會同步把需要具有關聯性的資料複製到一份到 Relationships 中。Relationships 資料表中欄位設計使用了兩組複合索引鍵，分別為 TenantId 與 DataGuid 為一組， 26.

(29) 以及 TenantId、ObjectId、AssociationId、TargetObjectId 為一組。 TenantId 與 DataGuid 的複合索引鍵目的在於讓系統可透過租戶 Id 與 Data 資料表中的 DataGuid 找出此筆資料的 Object 與其他 Object 的關聯性，因為可在查詢結果可以找到有關聯的 ObjectId 與 TargetObjectId，如查詢結果為多筆資料的話，則代表此 Object 與多個 Object 有關聯性。使用 TenantId、ObjectId、AssociationId、TargetObjectId 複合索引鍵進行查詢，代表系統已經知道 ObjectId 與 TargetObjectId，系統將使用 Object 的關聯性查出資料 DataGuid，接著再利用此 Guid 結果再去查詢 Data 資料表，藉此達到. 政治大在論文與白皮書中都未有詳細說明，因此本研究在實作中介軟體框架的過程中，立 Join 的效果，反而不去使用子查詢。Force.com 對於 Relationships 資料表的應用. 發現其有所不足的地方並進行修改，請見 3.4.3 小節。. ‧ 國. 學 ‧. 2.3 多租戶 SaaS 資料存取. sit. y. Nat. 在實作資料存取時，無論採用那一種方法，Shared Table, Private Schema 類型資. al. er. io. 料架構都必須面臨 Physical Schema 與 Logical Schema 的轉換的議題，因為租戶. v. n. 可以自定義其私有的資料綱要，但實作資料存取的 SQL 又必須符合所採用資料. Ch. engchi. i n U. 架構的 Physical Schema。Pereira & Chiueh [15]提出了用來追蹤處理 Phantom Dependency 的 SQL Rewriting Engine。他們也注意到，SQL Rewriting Engine 的概念在未來多租戶資料架構下，將成為核心的服務。此外，Li[16]也提出了一個 heuristic-based 的 Rewriting Engine 來將關聯式資料庫導向的 Logical Schema 對應到 BigTable(Change et al. [17])類型的 Physical Schema。除了 Physical Schema 與 Logical Schema 的轉換的議題，本研究所採用 Force.com Universal Table 資料架構將資料都保存於 Data 資料表中，由於欄位並未規範型別，應用程式讀出一個 row 之後，每一個 field 的型別必須靠應用程式使用 Fields 資料表來辦別，應用程式可能會有較多的負擔或容易出錯。. 27.

(30) 目前物件導向語言在存取關聯式資料庫時所使用的物件關聯對映(Object Relational Mapping)概念能有效解決上述兩項議題。Object Relational Mapping 源自於早年當物件導向程式語言開始利用關聯式資料庫來保存物件狀態時，開發人員必須花費額外的心力來橋接物件模型與關聯式資料庫中的資料綱要，因此 Keller et al. [18]於 1993 年提出一套自動化工具來橋接物件與關聯式資料庫。隨著 Java 日益盛行，不少的 Object Relational Mapping 框架也於此時推出，像是 90 年代末期的商用版本 TopLink 或是 2000 年初期的開源框架 Hibernate。 Object Relational Mapping[19]旨在提供一套方式讓物件直接對映到資料表，. 政治大 Relational Mapping 已成為物件導向語言存取關聯式資料庫一種主流方式，在 Java 立讓物件模型成為虛擬資料庫，開發人員不須再撰寫額外的 SQL 指令。目前 Object. 社群中主要的 Object Relational Mapping 框架有 Hibernate、iBATIS、Enterprise Java. ‧ 國. 學. Bean、DataNucleus…等[20]。. ‧ sit. y. Nat. 2.4 多租戶 SaaS 隔離性. al. er. io. 租戶識別碼(Tenant Id)是多租戶技術的一個重要基礎，SaaS 內部必須依賴租戶識. v. n. 別碼來達成租戶應用程式邏輯與資料的虛擬隔離性，並可藉由虛擬隔離性來提供. Ch. engchi. i n U. 客製化的服務。然而租戶識別碼如何傳遞是一個很重要的議題。對於剖面導向程式設計(aspect-oriented programming，AOP，Kiczales et al. [21])而言，這是一種 AOP 要解決的橫跨性關注，所以 Hisashi et al. [22]提出了一個以 AOP 實現的租戶識別碼傳遞機制。此外 Cai et al. [23]提出在既有的 Web 應用程式中加入 Tenant Context，使其具有租戶感知的能力。此 Tenant Context 做法是利用 Web 應用程式在接收到 http 請求時將租戶相關資訊保存至 thread 中，藉由 thread 將 Tenant Context 遍及在 Web 應用程式處理管道中。如此一來 Web 應用程式便具備租戶感知的能力，SaaS 開發人員可以根據不同的租戶來提供不同的服務，進而轉化成一個多租戶 Web 應用程式。. 28.

(31) 本研究將實現 Tenant Context 概念進而讓多租戶 SaaS 具備租戶感知的能力，由於本研究採用 Java 5 來實現中介軟體框架，Java 5 當中提供了 ThreadLocal 泛型類別[24]，其主要功能是讓每個 thread 都能擁有屬於自己的獨立變數，彼此不受干擾。因此我們可以將 Tenant Context 放置 ThreadLocal 中實現 Cai et al. [23] 所提出的將 Tenant Context 保存至 Thread 中的想法。. 2.5 Bytecode 轉換工程剖面導向程式設計(aspect-oriented programming，AOP，Kiczales et al. [21])旨在充. 政治大性。剖面導向程式設計在發展的過程中實現了不少重要的概念像是攔截器立. 分支援軟體工程的關注分離原則(Separation of concerns)，提高應用系統的模組. ‧ 國. 學. (Interceptors)、 Bytecode 織入(Bytecode weaving)…等。Bytecode weaving 概念的實現非常重要，因為在靜態或動態時期透過織入(weaving)的機制得以將剖面. ‧. (aspect)的程式碼整合入功能模組中。. sit. y. Nat. 修改 Bytecode 讓應用程式得以演變這一概念，Keller & Hölzle 於 1998 年也. al. er. io. 提出 Binary Component Adaptation 的概念[25]，讓元件在被載入之前已經進行調. v. n. 整與演變，Bytecode 轉換(transform)工程也是基於此概念旨在建立一個具自我調. Ch. engchi. i n U. 整能力(Adaptable)的系統。本研究希望透過 Bytecode 轉換工程讓 SaaS 開發人員所設計的領域物件能夠也具備自我調整的能力，動態的演變成租戶所自定義的客製物件。Bytecode 轉換工程實現方式為在 Java 虛擬機器(Java Virtual Machine， JVM)載入編譯好的中介格式位元碼(bytecode)之前，進行 bytecode 的新增或是修改，便能改變原本程式的樣貌。目前在開源框架中有 ASM、BCEL、Javaasisat 以及 SERP[26]專門在幫助開發人員修改 bytecode。ASM 強調操作 bytecode 的效能比起其他三個開源框架都較佳，它是使用 Java 所撰寫的 bytecode 操作框架，幫助開發人員直接處理 bytecode 的常數區(constant pool)與 offsets，使得開發人員在處理 bytecode. 29.

(32) 更為輕鬆。目前 ASM 已被廣泛的採用，被使用領域也非常多元，像是程式語言 Clojure、Groovy、JRuby…等，AOP 框架的 AspectJ、AspectWerkz…等，ORM 框架的 Oracle TopLink、OpenEJB、DataNucleus…等。[27]. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 30. i n U. v.

(33) 第三章中介軟體框架本章節將說明中介軟體框架的設計目標，並依據設計目標勾勒出三大特色，分別為租戶感知(Tenant Aware)、資料存取(Data Access)以及租戶客製化能力(Tenant Customizability)。在架構設計上將設計出五個模組，分別為 Tenant Context、. 政治大模組將會實現中介軟體框架的三大特色。立. ORM、UtbDBService、Customization API 以及 Bytecode Transformation，這五個. ‧ 國. 學. 3.1 中介軟體框架設計目標. ‧. 建置一個具有客製能力的多租戶 SaaS 除了要專注在設計服務的功能外，還必須. y. Nat. sit. 處理上述之多租戶 SaaS 的設計議題。這些設計議題主要包含共用架構、隔離程. n. al. er. io. 度、安全性、客製化能力、可維護性、復原能力；其中共用架構處於核心地位，它的設計將會影響到其他的五項議題。. Ch. engchi. i n U. v. 中介軟體框架是採用 1.1 小節中的第三種共用模型的第二個方式(共用硬體及資料庫與單一應用程式及資料綱要)，所使用的資料架構為 Force.com Universal Table。在這兩項前提下針對隔離程度、客製化能力與可維護性這三個議題來進行設計。目標是期望採用中介軟體框架所建置出的多租戶 SaaS 是一個具有高經濟效益，同時又具備客製化能力以及好維護的特性。具體而言，中介軟體框架有以下之設計目標為： 1.. 隔離性：透過 Tenant Context 概念的落實，達成租戶應用程式邏輯與資料的虛擬隔離性。. 2.. 資料層抽象化：多租戶 SaaS 的資料架構與客製化功能所須處理的實作議 31.

(34) 題，皆由中介軟體框架負責處理，讓 SaaS 開發人員專注於其服務的商業邏輯與前端使用者介面的設計開發上。 3.. 實用性：支援企業應用程式常使用的資料層開發模式：物件關聯對映工具(Object-Relational Mapping，ORM)。. 3.2 框架特色根據前述的框架設計目標，中介軟體框架主要將提供三個特色功能來滿足 3.1 小節中的目標。三個特色功能分別為：租戶感知(Tenant Aware)、資料存取(Data. 政治大 SaaS 應用程式(MTA)之架構圖如下：立. Access)以及租戶客製化能力(Tenant Customizability)。基於此所建構之的多租戶. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 3.1：基於 MTA Framework 的多租戶 SaaS 架構圖。. 3.2.1 Tenant Aware 一般軟體希望能根據不同的使用者來提供不同的服務時，通常最簡單及快速的方式便是在程式中的每個方法(Method)中加入使用者資訊這個參數，藉由此參數來判斷究竟是哪個使用者，進而提供差異化的服務。同樣的，在雲端多租戶 SaaS. 32.

(35) 中，如果要根據不同的租戶來提供不同的服務時，通常最簡單的方式也是把租戶資訊當作參數來傳遞。但傳遞參數的方式會增加程式相依性與耦合度(Coupling)，因為跟服務邏輯相關的程式方法中都要加上租戶資訊這個參數，如果缺少此參數便無法判斷目前的租戶為何。此外不相關的程式也可能必須加上此租戶參數，因為它可能會呼叫需要此參數的方法，造成整個系統中租戶資訊都在傳來傳去，大家都依賴於租戶資訊。因此中介軟體框架將提供 Tenant Context 之機制，讓採用本軟體框架的多租戶雲端 SaaS 具備 Tenant Aware 的能力。. 3.2.2 Data Access. 立. 政治大. 採用 Force.com Universal Table 資料架構模型的優點在於能夠共用一套資料綱. ‧ 國. 學. 要，以增加資源的共享程度以及可維護性，並藉由此模型設計上的特點讓租戶的. ‧. 資料具有虛擬隔離性，進而讓每個租戶都能擁有屬於自己的虛擬資料庫，並且可. y. Nat. 以客製其虛擬資料綱要。但缺點在於多租戶 SaaS 開發人員必須非常熟悉. 取層撰寫額外的程式碼來對映資料與領域物件。. al. er. io. sit. Universal Table 是如何運作的，才能撰寫出正確的 SQL 指令，以及必須在資料存. n. v i n 本研究希望多租戶雲端 SaaS Universal Table C h開發人員不需要擔心如何使用 engchi U. 資料架構以及其運作的機制，並且能夠使用目前主流的 ORM 的方式存取關聯式資料庫即可。因此中介軟體框架將會提供 ORM 機制讓多租戶 SaaS 開發人員使用，背後資料存取的部分中介軟體框架皆會負責處理。. 3.2.3 Tenant Customizability 多租戶 SaaS 在提供租戶客製化的部分主要為外觀與服務邏輯的部分，服務邏輯又可分為資料與行為兩個部分。本研究所提出的軟體框架主要是針對多租戶 SaaS 的中介層所設計的，因此將不會處理系統外觀客製化的議題。目前使用物. 33.

(36) 件導向程式語言所設計出的軟體，通常都會根據其應用的領域設計出相關的領域物件，這些領域物件將負責處理此領域的重要邏輯。因此多租戶 SaaS 中主要的服務邏輯是由這些領域物件負責的，想要提供租戶具有客製服務邏輯的能力，也就是能讓租戶新增領域物件或是修改既有的領域物件。由於領域物件透過 ORM 會對映回關聯式資料庫的資料表，新增或修改領域物件也代表著租戶們能客製屬於自己的資料綱要。中介軟體框架將能讓租戶們修改多租戶 SaaS 既有領域物件以及新增新的領域物件，不過目前能客製化的部分為服務邏輯的資料面(領域物件的欄位)，希望未來能再增加行為面的客製化。. 立. 3.3 框架架構設計. 政治大. ‧ 國. 學. 本研究期望採用中介軟體框架所建置出的多租戶 SaaS 是具有高經濟效益，同時又具備客製化能力以及優異的可維護性。為此，我們的中介軟體框架特色為多租. ‧. 戶 SaaS 能透過 Tenant Context 察覺所需處理租戶為何，SaaS 開發人員能夠使用. sit. y. Nat. ORM 的方式存取資料以及租戶能夠新增或修改領域物件。根據以上的目標與特. n. al. er. io. 色，中介軟體框架架構設計如下：. Ch. engchi. i n U. v. 圖 3.2：MTA Framework 架構圖。 34.

(37) 中介軟體框架內有五個模組分別為 Tenant Context、ORM、UtbDBService、 Customization API 以及 Bytecode Transformation，這五個模組將會實現本研究所提出的三個框架特色。 1.. Tenant Context：可與多租戶 SaaS 的驗證使用者機制搭配，當租戶使用者登入多租戶 SaaS 時，便可使用 Tenant Context 保存租戶使用者資訊。多租戶 SaaS 與中介軟體框架便可區分租戶產生屬於此租戶的虛擬應用程式及資料庫。. 2.. ORM：中介軟體框架提供 ORM 技術讓多租戶 SaaS 開發人員將其領域物. 政治大法，不須自行撰寫符合 Universal Table 資料架構的 SQL 指令。立. 件與 Universal Table 資料架構對映。存取資料方式也為 ORM 的查詢語. UtbDBService：此模組將負責把 ORM 的查詢指令轉換成符合 Universal. 學. ‧ 國. 3.. Table 資料架構的 SQL 指令，並在轉換的過程中使用 Universal Table 資. ‧. 料架構相關的 Pivot Table 以加速查詢速度。此外新增、刪除、修改的操. y. sit. io. Customization API：中介軟體框架將提供一組 API 給多租戶 SaaS 開發人. al. v i n 用使用，藉由這組 API 開發人員可以實現租戶新增、修改、 C多租戶 h e nSaaS gchi U n. 4.. er. Tables。. Nat. 作過程中，將會維護 Universal Table 資料架構的 Metadata Tables 與 Pivot. 刪除領域物件及查詢其客製的領域物件之相關功能。 5.. Bytecode Transformation：多租戶 SaaS 開發人員在開發服務時是根據其服務領域制定出相關的領域物件，若要客製化這些物件，必須提供動態修改物件之機制。本研究提供 Customization API，應用 Bytecode 改寫工具來達成此一要求。框架中的 Bytecode Transformation 模組便是讓開發人員可以透過 Customization API，讓租戶具有修改 SaaS 既有領域物件的能力。. 35.

(38) 3.4 框架實作設計本小節將針對框架架構設計中的五個模組實作方法進行說明，在說明當中將包含各模組如何實現架構設計中所賦予的任務、實作的細節以及相關使用技術。. 3.4.1 Tenant Context 根據前述 2.1 小節的介紹，實現 TenantContext 概念可以採用 Java 所提供的 ThreadLocal 功能，將 TenantContext 保存於 Thread 當中，中介軟體框架透過 Thread 取得 Tenant 的資訊進而產生應用程式邏輯與資料的虛擬隔離性。框架實作中主. 政治大 TenantContext 模組主要結構圖：立. 要將設計 TenantContextKeeper 類別用來負責保存與管理租戶資訊，以下為. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. i n U. v. 圖 3.3：Tenant Context 結構設計。. Ch. engchi. TenantContextKeeper 內有一靜態變數為 contextRepository ，其型別為 ThreadLocal<TenantContext>，中介軟體框架便是使用此變數將 TenantContext 保存於 Thread 當中。此 TenantContext 負責保存為租戶使用者介面： MultiTenantUser，它必須與多租戶 SaaS 的使用者驗證機制搭配，將租戶使用者資訊保存於 TenantContext 中。因此當中介軟體框架或多租戶 SaaS 開發人員需要辨. 識. 租. 戶. 使. 用. 者. 時. ，. 只. 需. 透. 過. 呼. 叫. TenantContextKeeper.getContext().getTenantUser()則可獲得租戶的資訊，進而產生租戶應用程式邏輯與資料的隔離性。 36.

(39) 3.4.2 Object Relational Mapping 在多租戶 SaaS 的資料綱要設計選擇上，本研究是採用 Universal Table 資料架構，但使用這套資料綱要有其難度。為了 SaaS 開發人員能更輕易快速的使用 Universal Table 資料架構，中介軟體框架將提供 ORM 的方式來存取 Universal Table 資料架構的資料，SaaS 開發人員不須自行撰寫符合 Universal Table 資料架構的 SQL 指令以及維護相關的資料表。但由於 ORM 的概念發展已久，市面上已有相當多的 ORM Framework，重新設計開發一套 ORM Framework 似乎事倍功半，因此本研究將會評估一套市面上主流的 ORM Framework 撰寫其擴充套件. 政治大目前市面上主流的 ORM Framework 主要有 Hibernate、iBATIS、DataNucleus 立. (PlugIn)來支援 Universal Table 資料架構。. 等等，經過仔細評估過這幾個主流 ORM Framework 的架構與 SourceCode 後，. ‧ 國. 學. 我們發現修改 DataNucleus 是最佳的選項。主要原因是 DataNucleus 為依據 OSGi. ‧. 規格所開發而成，其核心(engine)部分與其他所希望實現的功能，皆能有效地的. y. Nat. 分割，其各元件的相依性與耦合度低。也因為這樣的特性，DataNucleus 可以同. er. io. sit. 時支援 JPA(Java Persistence API)及 JDO(Java Data Object)這兩個 Java ORM 規格。另外在資料來源方面，它也不像主流的 ORM Framework 只能支援關聯式資. al. n. v i n 料庫，其他各種不同的資料來源只要有人實現其 Plugin 便能使用，例如：excel、 Ch engchi U xml、MongoDB 等等。DataNucleus 架構圖如下：. 圖 3.4：DataNucleus 架構圖[28]。 37.

(40) 從上圖可看出 DataNucleus AccessPlatoform 中分為三個區塊，分別是 API、 PersistenceEngine 及 Store Management。每個區塊中都是一個 Plugin，端看開發人員想要使用那種規格，就直接利用該 Plugin，Plug 進 Engine 中。由此可看出 DataNucleus 的彈性所在，這也是選擇 DataNucleus 的進行修改的主要原因，避免直接修改到其 Engine 的部分，只需針對其 DataStore RDBMS 的 Plugin 修改即可。在中介軟體框架架構設計中 ORM 模組的任務為負責把查詢結果與領域物件對映以及提供 ORM 的查詢語言，目前 DataNucleus 提供兩個 ORM 規格 JDO 及 JPA。因為 JDO 規格可支援不同的資料來源，從 DataNucleus 的參考文件[27]中也發現. 政治大 Plugin 也先從 JDO 相關的部分開始修改。立. 其是較為偏好 JDO 規格，本研究將先支援 JDO 的部分，修改 DataStore RDBMS. 在本研究架構設計中 ORM 模組依賴於另一模組 UtbDBService，因為此模組. ‧ 國. 學. 負責產生符合 Universal Table 資料架構的 SQL 指令及維護此資料綱要的相關資. ‧. 料表。我們不希望直接在 DataNucleus RDBMS Plugin 中產生符合這些 SQL 指. y. Nat. 令，DataNucleus RDBMS Plugin 只需負責執行符合 Universal Table 資料架構的. er. io. sit. SQL 指令則可。原因在於 DataNucleus RDBMS Plugin 為開源專案(Open Source Project)，會定時的改版升級，如果修改此 Plugin 幅度過大，會增加日後升級到. al. n. v i n 新版的難度。此外，產生符合CUniversal Table 資料架構的 SQL 指令及維護相關 hengchi U. 的資料表應由另外的模組負責以達到責任區分的效果，日後中介軟體框架想要增加支援更多的多租戶 SaaS 資料綱要，只需要另外再新增一模組即可，DataNucleus RDBMS Plugin 也不須大幅的修改。根據上述的設計決策，修改了九個 DataNucleus RDMBS Plugin 的原始檔案以及新增一個 Java 檔，修改清單如下：表 1.1：DataNucleus RDBMS Plugin 修改清單。新增 1. /org/datanucleus/store/rdbms/art/utb/UTbServiceHelper.java. 38.

(41) 修改 1. /org/datanucleus/store/rdbms/query/JDOQLQuery.java 2. /org/datanucleus/store/rdbms/query/PersistentClassROF.java 3. /org/datanucleus/store/rdbms/request/InsertRequest.java 4. /org/datanucleus/store/rdbms/request/UpdateRequest.java 5. /org/datanucleus/store/rdbms/request/DeleteRequest.java 6. /org/datanucleus/store/rdbms/request/FetechRequest.java 7. /org/datanucleus/store/rdbms/scostore/RDBMSFKListStore.java. 政治大 9. /org/datanucleus/store/rdbms/sql/SQLText.java 立 8. /org/datanucleus/store/rdbms/sql/SQLStatement.java. ‧ 國. 學. 修改 DataNucleus RDBMS Plugin 原始碼的原則為修改幅度越小越好，因此. ‧. 特別新增了 UTbServiceHelper 這個新的類別，把呼叫 UtbDBService 模組的邏輯. n. al. er. io. sit. y. Nat. 都封裝在此。UTbServiceHelper 類別如下：. Ch. engchi. i n U. v. 圖 3.5：UTbServiceHelper 內部設計。. 1.. generateUTbSql：呼叫 UtbDBService 模組產生符合 UTB Schema 的 SQL 指令相關的 API，回傳轉換後的 SQL 指令交由 DataNucleus RDBMS Plugin 執行。由於 DataNucleus RDBMS 中 JDOQLQuery 負責執行查詢， RDBMSFKListStore 與 FetchRequest 則負責執行領域物件中有設定外鍵關聯的對映查詢，因此修改這兩個類別把原本 DataNucleus 所產生的 SQL 39.

(42) 指令，換成由 UTbServiceHelper. generateUTbSql 所產生的 SQL 指令。此外 UtbDBService 模組需要知道 DataNucleus RDBMS 所產生的 SQL 指令才能將其轉換成符合 Universal Table 資料架構的 SQL 指令，因此修改原本 SQLStatement 與 SQLText 類別讓 UTbServiceHelper 得以取得 DataNucleus RDBMS 所產生的 SQL 抽象語法樹(Abstract Syntax Tree， AST)，然後在呼叫 UtbDBService 模組前將 DataNucleus RDBMS SQL AST 轉換成 UtbDBService 的 SQL AST，接著再傳遞給 UtbDBService 如此一來 UtbDBService 才能正常運作。 2.. 政治大 DataNucleus RDBMS 中的 InsertRequest、UpdateRequest、DeleteRequest 立. insert、delete、update：呼叫 UtbDBService 模組進行資料的增刪修。. 分別也是負責處理增刪修的操作，因此修改這三個類別並在增刪修時呼. ‧ 國. 學. 叫 UTbServiceHelper 的 insert、delete、update 方法。. doCustomField、isMTAAnnoated：負責處理租戶修改既有的領域物件欄. ‧. 3.. y. Nat. 位。DataNucleus RDBMS 中與租戶修改既有領域物件相關的類別分別有. er. io. sit. PersistentClassROF 、 JDOQLQuery 、 InsertRequest 、 UpdateRequest 、 DeleteRequest 以及 FetchRequest。關於客製 SaaS 既有領域物件將在 3.4.5. n. al. Ch. 中有更加詳細的說明。. engchi. i n U. v. 藉由修改 DataNucleus RDBMS Plugin，使其與中介軟體框架 UtbDBService 模組合作，中介軟體框架便能實現提供給多租戶 SaaS 開發人員使用 ORM 存取資料的目標。透過此 ORM 模組多租戶 SaaS 開發人員可使用 JDO 規格對映其領域物件至 Universal Table 資料架構，並且在查詢資料時可使用 JDO 查詢語法 (JDOQL)，不必擔心該如何撰寫出符合 Universal Table 資料架構的 SQL 指令。. 3.4.3 UtbDBService 中介軟體框架所使用 Universal Table 資料架構是由 UtbDBService 負責實現，上一小節的 ORM 模組將依賴於 UtbDBService 模組。如此設計的原因在於不希望 40.

(43) 實現 Universal Table 資料架構的責任交由 ORM 模組負責，因為中介軟體框架的 ORM 模組是修改 DataNucleus 開源框架，因 DataNucleus 會不斷釋出新版，假如修改的 ORM 模組當中擔負過多的責任，日後極有可能無法跟上 DataNucleus 新版的腳步，因此獨立出 UtbDBService 模組來實現 Universal Table 資料架構，ORM 模組只需存取此模組所提供服務即可。根據 3.2 小節框架架構設計，UtbDBService 模組主要任務有三分別為： 1.. 產生符合 Universal Table 資料架構 SQL 指令。. 2.. 當租戶執行新增、修改、刪除資料時維護相關的 Pivot Tables。. 政治大不過 UtbDBService 模組在實現 Force.com Universal Table 資料架構上並未完立. 3.. 當租戶執行新增、修改、刪除領域物件時維護相關的 Metadata Tables。. 全採用 2.2 小節中所說明的資料表。本研究將先實現 Force.com Universal 資料綱. ‧ 國. 學. 要的核心，Metadata Tables 實現的為 Objects、Fields 以及 Associations 資料表，. ‧. Data Tables 實現的為 Data 資料表，Pivot Tables 實現的為 Indexes、UniqueFields. n. al. er. io. sit. y. Nat. 以及 Relationships 資料表。. Ch. engchi. i n U. v. 圖 3.6：MTA Framework 資料模型。. 41.

(44) Metadata Tables 的 Associations 資料表在 Force.com 的論文中並未提到；按照其論文中的說明，某 Object 建立與其他 Object 的關聯性後，會在此 Object 的資料中保存有關聯的 ObjectId 於 Data 資料表的 Value 欄位中，Object 之間的關聯性 Metadata 並未獨立出來保存。但在實作的過程中發現假設沒有 Associations 這個資料表來保存 Object 關聯性的 Metadata，會連帶影響無法維護 Pivot Tables 的 Relationships 資料表。. 立. 政治大. Nat. y. ‧. ‧ 國. 學圖 3.7：Associations 資料表。. er. io. sit. 因為 Relationships 中的 ObjectId 與 TargetObjectId 這兩個欄位的資料無從所得，必須要有一個資料表來保存 Object 關聯性的 Metadata，Associations 資料表. al. n. v i n 詳細欄位資訊見上圖。此外，Force.com 的論文中也未提及資料與資料的關聯性 Ch engchi U. 是如何產生的，因此在新增的 Associations 資料表中分別有 FieldId、FieldNum、 TargetFieldId 與 TargetFieldNum 這四個欄位來記錄資料與資料是如何產生關聯性，就如同在建立一般資料表的外鍵。假設我們有兩個 Object 分別為 Order 與 Order Lineitem，並為這兩個 Object 建立 Association。從資料模型設計的角度來看，此 Association 的 Source Object 為 Order Lineitem，Target Object 則為 Order，所以此 Association 的 ObjectId 為 Order Lineitem 的 ObjectId，TargetObjectId 為 Order 的 ObjectId。不過 Order Lineitem 中必須有一個 Field 來保存其所對應的 Order 的主鍵值，如同建立外鍵的概念，. 42.

(45) 所以此 Association 的 FieldId 與 FieldNum 為 Order Lineitem 保存 Order 主鍵值的 Field 資訊，TargetFieldId 與 TargetFieldNum 則為 Order 的主鍵 Field 資訊。新增 Metatdata Tables 的 Associations 資料表後，在實作過程中也發現 Pivot Tables 的 Relationships 資料表有所不足的地方。按照 Force.com 開發白皮書中指出使用 TenantId、ObjectId、AssociationId、TargetObjectId 複合索引鍵進行查詢，代表系統已經知道 ObjectId 與 TargetObjectId，系統將使用 Object 的關聯性查出資料 DataGuid，接著再利用此 Guid 結果再去查詢 Data 資料表，藉此達到 Join 的效果。. 政治大的 DataGuid，而且只保存 Object 的 DataGuid 或 TargetObject 的 DataGuid 是不足立但其論文並未說明此 DataGuid 是保存 Object 的 DataGuid 還是 TargetObject. 的，因為無法馬上利用 Object 的 DataGuid 或是 TargetObject 的 DataGuid 就可查. ‧ 國. 學. 出其所關聯的資料之 DataGuid。因此在 Pivot Tables 的 Relationships 資料表中，. ‧. 新增一欄位為 TargetDataGuid 用以保存 TargetObject 資料的 DataGuid。原本. y. Nat. Relationships 資料表的 DataGuid 欄位則是保存 Object 的 DataGuid，藉由這兩個. er. io. sit. 欄位將資料關聯性保存起來。. 如此一來，假設我們需要知道某筆 Order Lineitem 其所關聯的 Order 資料，. al. n. v i n 利用該筆的 Order Lineitem 的C DataGuid 至 Relationships 資料表中查詢，馬上便可 hengchi U. 知道其對應的 Order 資料的 DataGuid。同樣地，如需知道某筆 Order 所對應的 Order Lineitem 資料，將查詢條件設為 TargetDataGuid 為該筆 Order 的 DataGuid，便可馬上獲得其所應的 Order Lineitem 的 DataGuid。修改過後的 Relationships 資料表如下圖所示。. 43.

(46) 圖 3.8：Relationships 資料表修改結果。. 政治大模組需要將 ORM 模組傳遞來的 SQL AST 轉換成符合 Universal Table 資料架構立在實現產生符合 Universal Table 資料架構 SQL 指令的任務中，UtbDBService. SQL 指令。本研究針對產生 Select、Insert、Delete、Update 的 SQL 指令歸納出. ‧ 國. Select SQL 指令. ‧. 1.. 學. 以下規則。. y. Nat. 由於 Universal Table 資料架構的特性，所有資料都是保存於 Data 資料表，. er. io. sit. 資料的 Metadata 是保存於 Objects 與 Fields 資料表，因此必須先找出我們查詢的 Object 為何，Object 內擁有其 Fields 的資訊。獲取了 Object 與其 Field 的 Metadata. al. n. v i n 後，UtbDBService 模組才能產生符合 Where 條件的 SQL C h Data 資料表欄位的資訊與 engchi U. 指令。以下為產生 Select 指令規則：. Rule GenerateSelectStatement : Input : T, the name of object; QL, a list of query fields; WL, a list of where clauses. Output : S, the SQL SELECT statement. Steps :. 44.

(47) obj = FindObject(T) S= “SELCT” append GenerateQueryFields(QL, obj) append “FROM Data” append GenerateWhereClause (WL) return S. function FindObject(T) : Object return Use T to find Object from Object table. 政治大 return QL map ( x (obj .Fields) => mapping Query Field to Data Table column ) 立. 學. ‧ 國. function GenerateQueryFields(QL,obj) : String. function GenerateWhereClause(WL) :String. ‧. return WL map (case IndexField => handle Indexed Field to get DataGuids. sit. y. Nat. case UniqueField => handle UniqueField to get DataGuid. io. er. case _ => handle Field). 圖 3.9：產生 Select SQL 指令規則。. n. al. Ch. engchi. i n U. v. 透過上述的 GenerateSelectStatement 規則可以產生出以下的範例 SQL 查詢指令。 SELECT Value0 as ProductId,Value2 as UnitPrice, Value1 as ProductName,Value3 as image1 ,Value4 as image2 , Value5 as note ,Value6 as image3 FROM Data WHRE ObjectId=3 AND TenantId=1 AND (DataGuid ='F0AC2C4D-1A1F-4E3C-B4D9-68AEA0EC1CE4' OR Value2>10) 圖 3.10：中介軟體框架產生查詢 SQL 指令。 45.

(48) Insert SQL 指令. 2.. 產生 Insert SQL 指令的規則主要是將欲新增物件的欄位資訊與欄位資料轉換成符合 Insert 到 Data 資料的 SQL 指令。 Rule GenerateInsertStatement : Input : O, an object to be added. Output : S, the SQL INSERT statement.. 政治大 S= “INSERT INTO Data” append 立 Steps :. GenerateColumnName (O) append “VALUES” append. ‧ 國. 學. GenerateColumnValue (O). ‧. return S. sit. y. Nat. io. er. function GenerateColumnName (O) : String. return use O.Fields map(x(Field) => mapping Field.FieldNum to Data Table. n. al. column ). Ch. engchi. i n U. v. function GenerateColumnValue (O) : String return O. Fields map ( x(Field) => append Field.Value by Data Table column) 圖 3.11：產生 Insert SQL 指令規則。. 透過上述的 GenerateInsertStatement 規則可以產生出以下的範例 SQL 新增指令。. 46.