第一章 緒論
1.5 論文大綱
用的 SQL 執行語句(包含 Data Definition Language 及 Data Manipulation Language 的部分)，歸納出通用的語句轉換規則。 會介紹 Aspect-Oriented Programming 概念並包含 AspectJ 的相關技術及 SQL Parser Tree 工具-Jsqlparser 相關技術與 SaaS 多租戶應用系統及其資料綱要設計方 法技術；第三章，完整的介紹本論文的核心概念及技術；第四章，實際的展示研 究成果；最後，我們在第五章提出結論及未來可能的發展。
‧
語言(Aspect-Oriented Programming, AOP)可以快速的達到此目的。本章節一開始 將會介紹剖面導向語言的概念；接著會介紹我們在設計、開發工具時用到的相關 技術，內容包含 2.2 節介紹 AspectJ、2.3 節介紹 Jsqlparser、2.4 節介紹 SaaS Multi-tenant System、2.5 節則介紹 SaaS 多租戶系統的資料綱要。2.1 Aspect-Oriented Programming
為 了 滿 足 整 體 系 統 目 標 的 特 定 需 求 ， 軟 體 系 統 的 設 計 會 包 含 許 多 的 考 量
（concern）。有人認為必頇將這些特定需求功能分離（separation of concerns, SOC），也就是所謂模組化。而設計一套軟體系統，最重要的就是它的主要功能，
不管是早期的程序性程式設計（Procedural programming）或物件導向程式設計
（object-oriented programming）都是為此目標而發展的。而横跨系統多個模組中 的共通功能（crosscutting concern）就是希望能交由剖面導向語言(Aspect-Oriented Programming, AOP)處理。
剖面導向語言的概念是於 1997 年所提出，一提出此概念立即引起程式語言 與軟體工程方面的學者專家重視及迴響，之後，便陸續發佈許多的相關研究。目
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
前有不少支援 AOP 的語言及工具，其中又以 Xerox Palo Alto 實驗室開發出以 Java 為基礎的 AOP 程式語言“AspectJ”最盛行。剖面導向語言是一種新的程式機 制。舉例來說，在一般應用程式當中除了業務面的功能性需求外，經常需要做許 多授權檢查與 Log 紀錄等等的非功能性需求，而這些需求在實作上往往都會分 散在應用程式的各個功能模組當中，造成不易集中維護等等的缺點。現有的程式 機制(programming mechanism) 在實作這方面需求時並無法提供有效的封裝與模 組化的支援，所以必頇將相同的程式碼重複於功能模組當中。雖然目前的程式機 制可以將程式碼集中開發及維運，但還是必頇在引用該段程式碼的地方加入引用 的程式碼。例如，下列程式碼(圖 2.1)，每個功能皆需單獨加入 Log 紀錄的程式 碼。
圖 2.1 重覆出現的程式碼片段
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
剖面導向程式設計就因為此種需求而產生，此種設計方法可先將重覆的程式 碼移出，並且集中在另一個模式，之後再透過程式的整合機制去將兩個模組做結 合，並完成實作。即便將來需要變更 Log 紀錄模組部份，也只需要去修改 Log 紀錄模組本身程式碼，不需要變更所有與 Log 紀錄相關的所有程式碼。
圖 2.2 利用 AOP 織入重覆程式碼片段
想要了解 AOP 的精神，則必需要先了解三項議題：
一、考量的分離（separation of concerns）：考量如果有做良好的模組化會使 程式開發的效率提升，並且可以更容易的去修改模組程式。
二、横跨（crosscutting）：程式設計與撰寫時常常會造成系統中反覆出現類 似的程式碼及不同需求的程式碼夾雜不清，可將程式碼嵌入到應用系 統的各個模組中，具有橫跨的特性。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
三、相依性反向（dependencies inversion）：要依賴於抽象，而不要依賴於具 體類別。當名稱愈抽象，則受到變動而影響的機會就會愈小。
進一步使用 AspectJ 來說明 AOP 的基本想法。AspectJ 程式分為 class 模組與 aspect 模組，Aspect 模組主要是定義 pointcuts 與 advice。而 Pointcuts 是規範 aspect 與應用系統介接的 join points，即 pointcut 是 join points 的集合；advice 則是定義 由 join points 定義的 point 所要執行的程式碼。每個 advice 都需要一個 pointcut，
二者共同界定應用程式在何時以及如何實現橫跨性的需求。AOP 最後會再透過 織入(weaving)的機制將 aspect 的程式碼整合到功能模組中，而不會更動到原有的 軟體架構。AOP 的架構如下：
圖 2.3 以 AOP 方式組合成應用系統的各類模組
而 AOP 在編譯時，利用 AOP 本身的編譯工具做為執行工具。且編譯時 並非一定需要原始程式碼檔案，編譯好的.class 一樣可以進行 weaving Rules 的動作。如圖 2.4 所示，將 AOP Complier 的流程皆表示出來。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 2.4 AOP 編譯程式流程
AOP 的優點有下列幾項：
一、單一模組的責任更簡單 二、可以做更好的模組化 三、使系統更容易發展 四、使程式設計上更具彈性 五、使程式的重用率更高
六、加快開發速度並滅少實作成本
2.2 AspectJ
AspectJ 是由 Java 語言延伸的 AOP 語言。每一個有效的 Java 程式就是一個有效 的 AspectJ 程式。AspectJ 的編譯器產生出符合 Java byte-code 規範，可執行在 Java 的 virtual machine (VM)。它具備所有的 Java 優點，也方便 Java 程式設計師去學 習 AspectJ。
在 AspectJ，經由編譯織入(weaving)規則的實作稱為橫跨(crosscutting)。AspectJ 定義兩種問題的 crosscutting：靜態橫跨(Static crosscutting)和動態橫跨(Dynamic
‧
靜態橫跨是修改系統靜態結構(如：類別 Class、介面 Interface 和剖面 Aspect) 的織入。本身並不改變系統的執行行為。靜態橫跨最重要的功能是支援動態橫跨 的實作。例如：想要新增變數或方法至類別或介面中，為了確定特定類別的狀態 和行為。這可被使用在動態橫跨的行為上。另外，靜態橫跨可以被使用在宣告編 譯時的警告和錯誤的橫跨多個模組。
AspectJ 延伸使用下面的構造指定織入規則程序：
一、Join Point
Join Point 是 應 用 程 式 在 執 行 時 加 入 流 程 的 確 認 點 (identifiable point)。具體來說，就是 Advice 在應用程式中被呼叫執行的點，這個點 可能是某個方法被呼叫之前或之後（或兩者都有），或是某個例外發生 的時候。
二、Pointcut
Pointcut 是一種定義，可以藉由這個定義指定某個 Aspect 在哪些 Joinpoint 時被應用至應用程式之上。可以在定義檔中撰寫 Pointcut，當 中說明了哪些 Aspect 要應用至應用程式中的哪些 Joinpoint。
三、Advice
Aspect 的具體實作稱之為 Advice，以儲存存取紀錄為例，Advice 中會包括真正的儲存存取紀錄程式碼是如何實作的，Advice 中包括了 Cross-cutting concerns 的行為或所要提供的服務。
四、Introduction
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Introduction 可以對現存的類別增加行為，而不用修改該類別的程 式，也就是說，可以為某個已撰寫、編譯完成的類別，在執行時期動態 加入一些方法或行為，而不用修改或新增任何一行程式碼。
五、Compile-time declaration
Complie-time declearation 是靜態的 crosscut 通知，可以增加在執行 時期偵測到錯誤或警告時，就通知使用何種 pattern。
六、Aspect
將散落於各個物件之中的 Cross-cutting concerns 收集起來，設計各 個獨立可重用的物件，這些物件稱之為 Aspect。在 AOP 中著重於將 Aspect 從程式流程中獨立出來，在需要該服務的時候，縫合（Weave）
至應用程式之上，不需要服務的時候，也可以馬上從應用程式中脫離，
應用程式中的可重用元件不用作任何的修改。
另一方面，對應用程式中可重用的元件來說， AOP 不用知道處理 提供服務的物件之存在，具體的說，與服務相關的 API 不會出現在可重 用的應用程式元件之中，因而可提高這些元件的重用性，您可以將這些 元件應用至其它的應用程式之中，而不會因為加入了某些服務而與目前 的應用程式框架發生耦合。
圖 2.5 AspectJ 的編譯流程
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
2.3 Jsqlparser
JsqlParser 用來剖析 SQL 語句並將句子結構轉換成階層式的 java 類別，可以使用 Visitor pattern 來操作及瀏覽這些階層式的類別。JsqlParser 是用 JavaCC (Java Compiler Compiler) Java 剖析產生器所建立出來，為產生階層式的 Java 類別，作 者修改了從 Guido Draheim's site 得到的 SQL 文法搭配 JavaCC 的方式建構出 Jsqlparser。
本研究就是利用 Jsqlparser 來完成 SQL 語法結構剖析與轉換的工作。首先 將 jsqlparser.jar 引入到 java 的 classpath 下，我們就可以在編譯時使用到 Jsqlparser 提供的 SQL 語句剖析功能，協助我們將 SQL 語句關鍵字或變數值識別出來，搭 配 SQL 語句轉換機制以重組方式將關鍵資料表改寫達到自動轉換 SQL 語法的目 的(圖 2.6)。
圖 2.6 SQL 語句剖析與自動轉換概念圖
2.4 SaaS Multi-tenant System
在 SaaS 的雲端平台架構中，多租戶技術指的是大量的用戶共同使用、分享一組 軟硬體資源。在多租戶技術中，常見的資料隔離的架構設計共有 3 種(圖 2.7)，(1)
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Separate Database 、 (2) Shared Database, Separate Schemas 、 (3) Shared Database, Shared Schema，以下分別說明這 3 種資料隔離架構的特性：
圖 2.7 資料隔離與資源共享關係圖
(Berthold Reinwald, 2010)
1. Separate Database
對於每一個租戶(tenant)，其所存取的資料庫是分離(Separate)的。即使運算 資源或程式碼可能是多個租戶共用，但在資料的儲存或取得上，是完全隔離 (isolate)的狀態。這種架構可以根據用戶需求容易的來擴展資料結構，而備份和 回復資料也相對容易。但每一租戶需提供一個完整的資料庫，因此維護成本高，
另外硬體成本較其他兩種架構高。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
2. Shared Database, Separate Schemas
這種架構是多個租戶(Multi-Tenant)共用一個資料庫，但每個租戶的資料會 存在一個屬於自己的資要綱要(Schema)中，這個資料綱要裡面包含了數個資料 表。這種架構在硬體成本上相較於 separate database 來的低，每一台伺服器可以 承受的租戶也比較多。但資料庫出問題時回復較難，當使用 Separate Schemas 的 架構且需要復原整個資料庫時，同時也會將其他租戶的 schemas 都覆蓋掉。
圖 2.9 Shared Database, Separate Schemas 圖 (Frederick Chong, Gianpaolo Carraro, and Roger Wolter, 2006)
3. Shared Database, Shared Schema
所有的租戶使用相同的資料庫，且同時用同一組資料表來維護其資料，在
圖 2.8 Separate Database 圖
(Frederick Chong, Gianpaolo Carraro, and Roger Wolter, 2006)
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
這種架構中，會用 tenant ID 來當作每個租戶的識別。使用這種架構讓每一台伺 服器可以負擔的租戶數量最多、單位成本最低且資源利用率最高。由於所有的租 戶都共用同一個資料庫，在安全維護和資料隔離程度上最差，當單一租戶的資料 需要復原時，必需在資料表中尋找所有相同的 tenant ID，數量多時就會造成其他 租戶的效能降低。
圖 2.10 Shared Database, Share Schemas 圖
(Frederick Chong, Gianpaolo Carraro, and Roger Wolter, 2006)
共用資料庫與資料表的設計方式比起獨立資料庫或資料表的設計方式需要 更多的人力成本來開發，因為共用資料表方式的設計方式其資料庫關聯性更複
共用資料庫與資料表的設計方式比起獨立資料庫或資料表的設計方式需要 更多的人力成本來開發，因為共用資料表方式的設計方式其資料庫關聯性更複