事件處理詞表

David C. Luckham 在 Complex Event Processing 社群網站發佈一份按照邏輯順序編排的事件處理詞表。許多有關 event processing 的研究，例如， Hu等人於 2008 年 Complex Event Processing in RFID Middleware: A Three Layer Perspective 文章，用語大都參考這一份詞表。

摘錄

事件：任何已發生或打算要發生的事。

事件物件：用來表達事件的結構：例如訂單是事件物件，用來表達訂購事件。

虛擬事件：未實際發生，但需要用來象徵實際事件的事件；多半來自想像或模擬。

事件類型：事件物件的種類。

事件時間：屬於事件的時間值。

時間間隔：由二個事件時間所限定的一段時間；二個事件時間是指時間間隔的開始時間和結束時間。

即時事件：事件的時間間隔小於單位時間；也就是說，事件的開始時間和結束時間是同一個。

抽象事件：用來為一組事件做摘要、做註解的事件。

複雜事件：是一個抽象事件，所摘要、解釋的事件對象是它的成員。

衍生事件：被產生而做為一項結果，要再對其他事件做處理，的事件。

複合事件：是複雜事件，也是衍生事件，是用到如事件的分離、結合、順序等等運算方法將基本事件結合而成的事件。複合事件自然包含了從所衍生的基本事件。

RFID中介軟體如何處理複雜的事件？

Hu等人於 2008 年 Complex Event Processing in RFID Middleware: A Three Layer Perspective 文章裏提到：現在已經有一些中介軟體處理 RFID 事件的過濾和匯總等功能，例如有 BEA 、 Sun 、 Singularity 和 Logicalloy 等公司的產品；不過，作者們注意到 EPCglobal Network 的架構，在 Application Level Events 和 EPC Information Service 之間有一個叫做 EPC Capture Application 的層次。他們說，在 EPC Capture Application 層次， RFID 中介軟體應該運作一些複雜的功能，為了處理特定的商務流程而處理較複雜的 RFID 事件。

架構分為三個層次，由下層到上層依序為：

1. 邏輯結構： RFID 事件源自讀寫機探測到的基本事件，而複雜的事件是由一些基本事件組成，或者，複雜事件也可以由另外一些複雜事件組成。
2. 時間限制：在複雜事件結構中，可以加上時間限制的屬性。
3. 事件偵測：應用前二層的產物，藉由複雜事件分析，向上回報究竟發生了哪些事件類型。

這篇文章對事件結構做了初步的正規描述，並使用 Petri Net 為處理工具。對第一層，邏輯結構方面，使用 Petri Net 延伸的模型 Composite Event Structure-layer Net 。對時間限制層面，使用 structured token and transition mark 處理。對事件偵測層面，使用 Petri Net 著色方法處理；但是本文尚未討論到 Petri Net 著色方法的細節。

邏輯結構

每一個基本事件，按照 EPCglobal 的說法，是讀寫機探測並回報在什麼時候「看見」了哪個 tag 。用大寫字母 A, B, ... 表示每一個基本事件的類型。於是，用到以下六項運算，可以處理許多基本事件之間的各種基本邏輯關係：

1. 彙總： (A, n) 表示進來 n 個 A 事件。
2. 分離： (A | B) 表示進來的事件是 A 或 B 。
3. 結合： (A & B) 表示 A 和 B 二事件都進來。
4. 否定： (~ A) 表示 A 事件沒有進來。
5. 順序： (A; B, t) 表示依序有 A 和 B 二事件，而且二事件的間距在 t 時間區段之內。
6. 內在： Within(A, t) 表示 A 事件在 t 時間區間之內進來。

事件的間距定義是，對事件 e 有一對參數 [Start e, End e] ，表示事件發生的時間和結束的時間。事件 e 自己發生的時間長度是 (Start e - End e) 。二事件 A, B 有 (A; B, t) 順序，代表：

(A & B) [0 < Start A - End B < t]

即為 A, B 二事件除了同時發生之外，加上 A, B 的時間有些差距。

而事件 A 在 t 時間之內發生， Within(A, t) ，可以改寫成：

(A, 1)[Start A - End A > t]

(註：以上二式都是文章中的原文照列，不過看起來有一些矛盾的疑問。)
即為發生了一件 A 事件，並且此事件持續了有 t 時間區段那麼久。

所以，事件的順序關係是結合關係的特例，而內在關係是彙總關係的特例。

以上所指六項運算符號，扣除二項特例，可以有四種 Petri Net 圖型表達彙總、分離、結合、以及否定等關係。

時間限制

對一個事件 e ，將它對應事件類型的集合表示為 S e 。則加上時間限制的結構是一個三元詞組 (Start e, End e, S e) ：例如，進來一個事件 (epc, r, t) ，則做出一個 token 為 (t, t, {(epc, r, t)}) 。
(註：此例中 (epc, r, t) 也有些疑問，在此也暫以原文照列。)
做成這樣的 token 是為了使 Petri Net 中 Guard 位置計算比較方便。

其他人的相關作品

Siemens RFID 中介軟體使用宣告式的語言，可撰寫規則，用到邏輯和時間限制的運算語法。事件偵測以圖論為基礎。

SAMOS 以 Colored Petri Net 做事件偵測的機制。

Esper 是一件開源軟體，處理複雜事件和事件串流的架構。用到類似 SQL 的語言表達複雜事件，並使用自動狀態機做事件偵測。

關於雲端運算

這篇是談一個稱為雲端運算的東西如何不是雲端運算。因為反面的評價高，相關人事背景加以文字混淆，避開Google搜尋。

Wikipedia對於cloud computing有一番解釋。Cloud就是internet，cloud computing是將計算擺到internet。其中對於商務需求，有一些詞彙如 Platform as a Service (PaaS)、Software as a Service (SaaS)。張亞勤對雲端運算有更細的解釋。

26日參與「s編a碼l編e碼s f編o碼r編c碼e.com」公司所辦的「雲編端碼運編算碼技編術碼論編壇碼」，原本希望看到類似於「某個翻議比賽Google傳說」(1)(2)(3)之類的有趣討論，但後來是覺得失望的。

基本上他們公司是做Application Service Providing (ASP)的。這場event是商務軟體發表會，並且與技術思考的交涉不深，其中看到的概念也不新。不過，換一個角度看，我們想要的軟體元件重覆使用的功能他們已經做了，不過耗時九年。

以下是會議摘記：

---

開場：(業務經理)

網路服務趨勢

1. 以消費者為導向的enterprise IT，
2. Enterprise IT服務趨勢: 多用戶和租用，
   且提供服務租用的廠商必須投入成本維持satisfactary。
3. 網路服務提供叢集的資料中心儲存大量用戶資料。

接下來的說明演示，在本公司商務平台上短短幾分鐘開發應用程式.，達成 (企業內)「無軟體」的商務系統。

說明與演示：(亞洲區業務經理)

本公司花費九年做出可訂製的商務平台，其中包擴了 PaaS和 SaaS 的特性。本平台將商務中許多重用的功能整合，使用戶能自己建置自己合用的系統。

在 CIO checklist 上，企業系統須符合許多準則，如安全、可擴展、可靠、可訂製、資料庫整合、前瞻性、和可用等等。傳統平台:大多只有基本服務，而需要的功能經常要重建。而本商務平台將基礎平台、安全、應用處理架構納入。

一般建製案例

1. Disney米‧老鼠管理系統：在 .net 平台與本平台建製時間比為 3000 : 96 小時。
2. EA公司 HR 系統：使用本平台建製，並獲得美國 innovative use of technology award。
3. JP network 郵便局業務轉型。

演示：(亞洲區系統工程師)

以下為本平台，創新的「非」基礎架構 PaaS 的演示。

需求 1： system reliability

演示 1：本平台一天有超過一億的 transaction.(100M+)..225ms平均處理速度.. 1,100,000+用戶數。並符合 ISO, NCS2 認證。

需求 2：在系統上建置新的模塊數據來管理線上系統的一些資料。

演示 2：在 browser 可建立數據庫、切換介面語系，以及可應使用者熟習語系開發數據庫.。

(創造 project 管理) 建立物件→建立欄位→建立 page view →調整哪一些用戶可以看見物件或欄位→加入資源需求數量。

(根據亞洲區業務經理所提出的說明，資料庫實體檔案應該是以「物件導向資料庫」模型實作。)

好簡單，普通人也可以做？

此時聽眾回應：對這平台的期待更深，因為專案所需要的資料庫都是關聯性很複雜的。一但案子因為在此平台建置出了問題，而資料也都鎖在平台內，是否有風險？

(會後討論針對此問題有解答提出)

需求 3：現有數據庫的移轉。

演示 3：提供 script 將現有數據庫導入本平台

(PaaS 特色) 本平台提供 WebServices API、 Native ERP connectors、 Middleware connectors、 .net- or Java-based tools、 Mashups 和 Desktop Connectors。

需求 4： Logic (work flow) 的需求。

演示 4：本系統可訂製批準流程、自動化、 trigger rules 和欄位與欄位的互動變化等細節特色。

(Logic as a Service 特色) 本系統使用 Java-liked 的 apex 語言，讓使用者能夠撰寫企業需要的邏輯。邏輯建置的方式有：

1. 宣示性邏輯(只要點擊)
2. 公式基礎邏輯
3. apex code

需求 5：UI 的需求。

演示: 5：本平台有標準UI。此外在手機上也提供比較簡單的使用者介面。

此外提出 Vi編su碼al編Fo碼rce 的功能，使平台的整個頁面都能更改.。成功案例有 Cisco、Ashiland 和 Coda 的案例。

除了上述演示之外，

應用程式交換服務: Ap編pe碼xch編an碼ge 平台讓用戶在本平台做的東西可以賣給別人。在此交流平台上可以 "test drive" 也可以 "get it now"。案例：Chevron 用 Ap編pe碼xch編an碼ge 管理內部費用。

本平台也提供 dashboard 功能顯示各種圖形報表。

(Desktop as a Service) 本平台提供 IDE 供桌面開發使用。

結論：(亞洲區業務經理)

Cloud Computing 概念是指系統可在線上使用並與其他系統相連接。企業應知道如何使用公用系統共享合作夥伴與共享用戶。

答問與討論：

1. 資料庫變更欄位所造成的改變是否都正確?

答：線上測試帳號去做某種程度的邏輯測試，滿意了再採購本平台。

(某公司工程師 Danis 的答案) (1) 除了普通邏輯之外，還可以寫一些檢核規則。

(2) 使用 sandbox 測試開發案，完成之後再 deploy 。

2. 設計上與技術圖面上的管理？

答：本平台提供 document 與 version 管理。

此外，主要是跟隨 80-20 原則，本平台希望幫助解決大部份該解決的問題，使企業用互能夠有較多心力專注處理 20% 非平台能夠解決的問題。

---

以上是會議內容摘要。接下來是我的看法：

1. 技術人員們，當公司說要建個 cloud computing 這東西，你覺得是什麼？實際該做哪些東西？


2. 這家公司的這個平台概念不新。 Meta-system (即產生系統的系統) 的概念非常容易由技術圈萌生。做 compiler 的會漸漸做出 meta-compiler ，做 SOHO 的人會漸漸將程式整理成可以組裝的軟體零件。普通寫程式的用手刻程式，厲害的程式師則用少許程式產生大量程式。


3. 談到正題， cloud computing 與雲端計算。在這次討論中，我看不到那片雲在哪裏。所以第 1 項我感覺不到做為一個 cloud computing 的東西，該有哪些實作。而我說感覺不到那片雲的意思，是因為這個平台只將用戶的軟體與資料搬入網路，卻還談不到任何 cloud computing 。 Cloud computing 的涵義，我覺得是 computing 的效能與產出能夠由這片 cloud 受惠。但這個平台還只是將自己的軟體平台搬上網路，享有一些資料存取的透明度 (storage transparency) 而已。但是產能是否較強呢？在 marketing 層面還有討論空間。但在純計算部份，看不到什麼好東西。


4. 當場有個關於資料庫組織的討論，對研發者而言是有趣的事情。我們知道 relational database 有很多講究的地方，包括 functional dependency, enterty integrity 、 reference integrity 和表格的劃分。若由網頁介面提供用戶可以自行定義表格，或許表示在用戶的 view 中不必考慮這些事情。但資料庫組織改動之後，要怎麼保持資料庫與改動前的內容一致，其中的 reference 轉換可能很複雜。不過，從發言人的解釋，可以聽出他們使用的資料模型是物件導向資料庫模型，或許在物件的關係與 reference 比較簡單。這方面是可以思考的要點。當你要做個 middleware 時，在 storage transparency 方面要提供某程度的保證。裏頭要談的是一些數學與邏輯上可證明的穩固基礎。