Java SOA 基本觀、架構與實做 <2>

SCA的規格

SCA (Service Component Architecture) 是由 OSOA (Open Service Oriented Architecture) 的組織所訂定的 SOA 元件的標準規格。

SCA 的主要目的在於訂定一個統一的程式標準,讓想要採用 SOA 的組織,可以透過該標準獲得一致性的程式寫作的方式。原則上 OSOA 的組織是由幾個支援 SOA 軟體的大廠(IBM、TIBCO、Oracle(with Bea)、Red Hat、Sun…等)所組成 (OSOA 的網址),也因此,在理論上,學會SCA的標準規格,應該可以對不同的SOA產品有一致性地程式寫作策略。

在SCA規格中,其中最重要的一個部分就是一個標準的組合模型 (Assembly Model),下圖即為該組合模型的基本示意圖:

圖2.SCA 的元件圖 (Component Diagram)
(點擊圖片鏈接看原圖)圖 2. SCA 的元件圖 (Component Diagram)
ref: SCA Service Component Architecture Assembly Model Specification, 2007, p. 3

上圖表達了一個SCA所定義的Component的幾個重要特性以及相關的Domain名詞,包括:

  • Component:代表Service的群組集合體,一般來說,Component通常指的是一個Function Group;通常來說,Component的實際實現的方式,有可能是各式各樣不同的方法(可以是一般的Java Code,或是BPEL,甚至是其他Component組合而成)。
  • services:代表Component所提供的服務,一個Service意指一段不可分割的操作,通常來說,一個Service就代表了單一個Function。
  • properties:代表Component中所必要的一些屬性,定義出來的Property在Component中會被共用,一般來說,我們很有可能在Property中設定一些會共用的複雜資料型態。
  • references:若是Component會用到外部的服務時,你可以利用reference直接設定參考的service。

閱讀全文 »

Java SOA 基本觀、架構與實做 <1>

*** 本系列文章與程式碼範例 均為 賴信仁 (Ringle Lai) 所撰寫 ***

在之前的課程中,我們曾經說明過SOA的設計來源其實是從架構面的 使用案例 (Use Case) 模型分析而來。本次課程我們將進一步地說明,如何利用標準化的設計準則來設計一個公司的SOA架構。

以下是屬於 SOA (Service Oriented Architeture) 的定義:

A service-oriented architecture is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components—services—that can be reused and combined to address changing business priorities.
Ref: Service-Oriented Architecture (SOA) Compass, by Bieberstein et al. (2006)

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Ref: http://en.wikipedia.org/wiki/Service-oriented_architecture#cite_note-9

從上述的定義來看,所謂 SOA 的目的,其實只是在分散處理的環境,提供了一個「分散但可預期的」整體環境。

從這個定義來看,其實在數年前由產業界的力量所推出的「RosettaNet」,就是這一波 SOA 的濫觴;只是目前的SOA的觀念,從產業間的合作關係,逐漸地往企業內部的整體流程整合邁進。但從其基本觀念觀之,其實正是「Design to Interface」觀念的衍生。

那麼,SOA 究竟是怎樣的觀念呢,其基本的結構又會是如何?我們以下圖來呈現一般 SOA 所建議的架構(由於 SOA 畢竟並非一個標準化的架構,因此,各個不同的廠商或是學者,各自有其對 SOA 架構的看法,以下筆者所採取的,是筆者比較認同的SOA架構圖):

圖1. SOA的參考架構
(點擊圖片鏈接看原圖)圖 1 、SOA的參考架構
(Ref: SOA Practitioners’Guide Part 2: SOA Reference Architecture, 2006, p.19)

從這個架構圖,可以看出 SOA 架構的立體性。

在 SOA 架構中,對於企業 (Business)有意義的部分,在於整體企業服務層次的提供,這是上圖中最上方的三角形的部分,也因此,一般在實現 SOA 時,我們必須先從 Business 著手;至於下方的三個 Tier,則是從 IT 的架構層面出發,其主要的目的,在於提供 Business Service 一個穩定性的地基。 以上圖來看,其實 Service Tier 所代表的意義,在於將企業的 應用程式 (Application) 做適當的包裝,好讓其可以簡單地 Mapping 到 Business 的 Service。

也因此,所謂的 SOA 並非是一個固定的產品或是規則,相反地,先讓我們確認 SOA 的主要目的(Business Service <-> Information Service),再從這個主要目的去找尋適合的開發方式 (Development Process)與適用的技術,如此一來,對於 SOA 的整體規劃才不至於見樹而忘林,甚至在不知不覺間,被特定的廠商牽著鼻子走,反而忘掉了 SOA 的最根本的目的!

報名系統分析課程(06/27)免費送 Linux 軟體開發平台 DVD 光碟

HSDc. 團隊近日費心製作了「Linux 軟體開發平台」DVD 光碟。 目的是為了讓學員可以擁有與講師相同的軟體開發環境,只要帶回家啟動光碟後,不需作任何設定,就可以方便對講師所提供的實做案例自行練習 (當然,也可以開發所屬於自己的應用程式)。

即日起,只要報名【系統分析課程】系統分析設計與實作—活用 UML 塑模 與 Java (06/27, 54 Hrs),即免費贈送學員 DVD 光碟乙片 (不要忘了,線上報名還有免費贈送 Ringle 的親筆簽名新書喔)。 光碟內容相當豐富,包括課程所使用的教材電子檔、完整的實做案例 (包括 UML Model 檔與可執行的應用程式碼); 當然,還包括了如下完整的 J2EE 開發環境 (爾後 HSDc. 會對其系統與應用平台版本的更新而持續 Update):

  • OS: Fedora 10.0 Traditional Chinese
  • XWindows: GNome
  • VMWareTool
  • Java SDK 1.6.0_0b12
  • JBoss Application Server 5.0.1
    (Install in /usr/jboss-5.0.1.GA)
  • MySQL Server 5.0.77 (Fedora Default)
    MySQL GUI Tools 5.0r12
    MySQL JDBC Connector 5.0.8
    (Install in /usr/mysql-connector-java-5.1.7
  • Eclipse 3.3 with J2EE
  • Spring Framework 2.5.5
  • Hibernate 3.3.1 Code and Library

安裝的Server以及Java Library

底下同時列出幾幅開發環境的 Screenshot 圖片:
UML Development Tool (EA, Enterprise Architect) under Fedora Linux:
利用Wine執行EA

閱讀全文 »

關於股票 Tick 跳動時單量顏色的判斷原則 (含程式碼片段)

我最近正在寫一個成交量判讀的應用程式。 要能即時判斷構成大盤主要的權值成份股 (約 60~80 家即可),在任一權值股跳動時 (Tick),就立即加總成交量,並在每一分鐘報出 (report) 買進價量 (BidPrice Volume) 或為 賣出價量 (AskPrice Volume) 的相對數據。

以 eLeader 來說,視窗 [5203] 就是期貨的成份股即時報價,用戶若要判斷個別的權值股單量是買進價量或賣出價量很簡單,報價視窗在 "單量" 這一欄,當出現紅色數字時代表 "買進價量";相對來說,出現綠色數字則為 "賣出價量"。 (還有一種罕見的黑色,算是無法判斷為買 or 賣價量)

但是若要寫成應用程式時,程式可不知道紅色或綠色之分。 理論上,在該看盤視窗上,應該會有個 "Flag" 旗標欄位,透過所提供的數據 (如 1為紅、2為綠),來協助判讀 單量 為 買或賣 價量。 但是 eLeader 不知怎麼搞的,可能是 Bug,並沒有這個 Flag 欄位。 所以要即時判斷單量的顏色,該邏輯就變得相對複雜很多。

生魚片給了我一份「單量顏色判斷原則」參考。 最重要的判讀原則是,程式一定要保存著個股前一個 Tick 的買進價、賣出價與成交價,再與現在 Tick 的買進、賣出、成交價等來比較。 其判斷的邏輯參考如下:

時間 買進 賣出 成交 單量
t B2 A2 P2 V2
t-1 B1 A1 P1 V1

-成交明細只揭露有成交的資訊.
-交易所所送資訊,是以 B2/A2/P2為一組資訊.B1/A1為成交前的買賣價,B2/A2為成交後的買賣價.

-單量判斷原則:
(1)僅有買價或賣價:

時間 買進 賣出 成交 單量
t B2 --- P2 V2

當只有買進價,若P2=B2,則V2是紅色(因為市場上都沒有人要賣);

時間 買進 賣出 成交 單量
t --- A2 P2 V2

當只有賣出價時,若P2=A2,則V2是綠色(因為市場上都沒有人要買);

(2)把成交後的買賣價資訊與成交前的買賣價比較:
若B2=A1,則V2是紅色(以較高的價格成交表示買方向賣方妥協,願意以較高的價格買);
若A2=B1,則V2是綠色(以較低的價格成交表示賣方向買方妥協,原意降低價格求售);

(3)若不符合上列條件,以同一時段的買賣價做比較:
若P2>=A1,則V2是紅色;
若P2<=B1,則V2是綠色; (4)若同時不符合(1)(2)(3)時: 也就是B2不等於A1,A2不等於B1,P2不等於B1,P2不等於A1,則V2的顏色視P2的價位較P1大小決定, 若P2>P1,V2標紅色;
若P2=P1,V2標黑色;
若P2

然後我把其邏輯寫進 C# 的程式碼,其片段原始碼參考如下:
(目前測試結果,大概 100 次的 Tick 跳動,好像還是有 1~2 次的顏色判讀錯誤情形,不知道問題在哪裡。 不過大致上運作都算正常,算是在可容許範圍之內。)

閱讀全文 »

VDB 理論與實作 by .NET (1) — 虛擬DB、Value 與 Business 物件的關係

VDB 理論與設計 — Ringle Lai;本次範例實現 — Steve Chou:編排與修正 — Kenming Wang。


虛擬DB(Virtual DB) 並非特定平台的實做技術,其主要特性如下:

針對某一個特定的任務,將該任務所需的相關資料由各種不同的資料來源取得至 記憶體(Memory)中,讓相關的處理程式可以「就近處理」這些資料;其與資料來源的實體儲存格式無關,且在取得資料後,應該保持與資料來源「離線(offline)」的方式來進行存取,而 虛擬DB 只提供資料的存取,不負責進行運算。

也因此,Java 世界中的 Value Object 其實也是「虛擬DB」的一種體現;至於在.NET Solution中,最適宜表現虛擬DB的技術就是 ADO .NET 中的「DataSet」技術。而 Business Object 與 Value Object 最大的差別在於 Business Object必須要有「企業運算邏輯(Business Logic)」。舉例而言,下圖就是一個典型的Business Object的類別圖:

典型的 Business Object 類別圖
(點擊圖片鏈接看原圖)圖、典型的 Business Object 類別圖

根據前述的 Business Object 的定義,我們可以發覺在上圖中,Business Objcet只有兩個,分別是:

  • Order Class – 因為其有一個【CalculateTotalAmount】的 Business Method;
  • OrderItems Class – 因為其有一個【CalculateSubtotal】的 Business Method。

而在該圖中,Product Class 因為只有一個 Getter 的 Method,因此可以將之視為 Value Object,至於 OrderItems 也有一個【Quantity】的屬性,因此也具備了 Value Object 的性質。

一般來說,Business Object其實通常具備了三個主要特質,分別是:

  • 資料面 – 這通常會以【屬性(attributes)】來呈現。
  • 企業邏輯 – 這通常是除了 Getter 與 Setter 之外的 Method。
  • 結構面 – 也就是類別間的靜態關係(包括 Association、Aggregation、Generalization 以及Dependency 等)。

然而,當我們有了 虛擬DB 的概念後,資料面的部分可以交由 虛擬DB 代勞,因此,Business Object就只存在了企業邏輯以及結構面。

我們可以利用UML的 Composite Structure Diagram(複合結構圖) 來表達 虛擬DB 與 Business Object 兩類元件的關係:

虛擬DB 與 Business Object 間的關係
(點擊圖片鏈接看原圖)圖、虛擬DB 與 Business Object 間的關係

淺論 Visual Studio .NET 專案開發的目錄規劃議題

在這一期剛結束的「系統分析設計與實作」的課程中,有位女學員問了一個問題:

「由於老師上課時都是以 “類別 (Class)” 為單位,來說明類別之間的連結關係;但是,在微軟實際的發佈(Deploy),卻是以 “DLL” 為單位,而一個 DLL 檔案,可能會包含了一到多個類別,若是被呼叫的某一個類別有經過編輯修改後,則整個 DLL 檔就必須重新編譯,相當地麻煩。 所以,到底該如何規劃這些類別的配置呢?」

先說明一下這個問題,是屬於 “相依性(Dependency)” 的設計議題。 小至以類別、套件(Package) 為單位,大至以模組 (Module)、子系統(Sub-System)、系統,都有這類相依性的設計考量。

DLL,全名為 “Dynamic-link library (動態連結函式庫)”,中文版的 Wiki 解釋是這樣的:

「所謂動態連結,就是把一些經常會共用的程式碼(靜態連結的OBJ程式庫)製作成DLL檔,當執行檔呼叫到DLL檔內的函數時,windows作業系統才會把DLL檔載入記憶體內,DLL檔本身的結構就是可執行檔,當程式需求函數才進行連結。透過動態連結方式,記憶體浪費的情形將可大幅降低。」

上述這一段的解釋應該是從系統實作(Implementation)的角度來說明的。 在邏輯性的設計觀念呢? 應該是稱之為 元件(Component) 最為恰當了; 在 UML 的塑模(Modeling)階段,則是以 套件(Package) 為單位較適合; 至於在微軟的 Visual Studio .NET 中,則確然是以 “專案(Project)” 為單位無庸置疑了。

而 VS.NET,則有兩種專案開發的容器(Container)類型,一就是上述所提的 “專案”:另一個就是所謂的 “方案(Solution)” 了。 一般說來,方案即為 “大” 的容器,一個方案可以包含一到多個專案,而且,最頂層的容器,必然是以方案為單位,也就是說,即使只有一個專案,也仍需要有一個方案存在。 這是相當合理的,較早免費版的 VS.NET Express 版本,只能以獨立的一個專案為開發單位,這反而不妥。 畢竟,專案開發時,必然會有多個相關連性的專案存在,以方案將多個專案 “聚合(composite)” 在一起,是比較恰當。 從 UML 圖來表達方案與專案的複合結構關係,可以參考如下圖:

.NET Solution 與 Project 的複合結構圖

那麼到底一個系統的開發,分為幾個專案比較恰當呢? 這當然還是要看專案的性質與規模而定。 但我強烈建議,無論如何,最起碼一定是至少兩個專案: 含企業邏輯(Business Logic)的 Model 專案,以及 UI(User Interface) 專案

UI 專案相依於 Model 專案,反之則否。 所以當 UI 未來會變動時,例如從 ASP.NET 改為 Windows Form,Model 專案是不需要作任何變動的。 當然,這樣的規劃起碼有個前提: 不會把 企業邏輯 實作在 UI 專案,而這點,應該也是軟體開發最基本的彈性度考量了。

再講究一點,對於大規模如 ERP 系統的開發,更需要考量到未來系統的變動性與延展性等議題,所以對於彈性度與可容易抽換的再利用性,自然要求就更為嚴謹了。 可以參考一下先前我曾寫過的一篇:「淺論資訊系統的分層結構」,那個圖內的每一個框框所表示的套件(Package),都會被規劃為一個個的專案。 所以,在 UI 層,會有個 UI 專案;在中間層(Middleware),則會有如 “Control”、”Business Model”、”Boundary” 三個專案的規劃。 參考如下,在 VS.NET 建立一個 Solution 方案,例如名稱為 “ERP System”,然後再建立起四個專案目錄。

ERP System (Solution)
— Web_UI
— Control
— Business_Model
— Boundary

“Control” 顧名思義,屬於在 Enterprise 系統中 MVC 基本框架中的 Control,它橋接了 UI 與 Model,也讓其兩者沒有耦合(Coupling)在一起; Model,也就是物件導向中,代表問題領域概念呈現所稱之為的 企業物件,也是軟體的主結構。 只是,國內短線專案很少重視這一塊,往往會與 Control 層糾纏在一起,以及退化成為資料庫內的 Data Model(資料模型); Boundary,連結資料庫或者外部系統。 連結資料庫這一層稱之為 “DAO 物件(Data Access Object)”、連結外部系統這一層稱之為 “Adapter 物件”,此兩者都會因連結的資料源(Data-Source)變動而必須調整,但不致也不應該影響到 Control or Model 層。

上述例子中的 ERP System 方案,在開發階段中,規劃了四個專案目錄,所以未來經過編譯後,會有四個 DLL 檔案(當然,若以 WebUI,可能有它特別的格式,但是,對於微軟的角度來說,執行期間(run-time)的一組群組(Group)起來的物件或函式庫,都可稱之為 DLL)。 再經過分層結構的相依性分析,就會瞭解到 DLL 之間的相依性關係,以及抽換某個 DLL,是否會影響到另外的 DLL。

除此之外,分為如上四個專案,還有個好處: 在開發階段可以平行分工

例如,開發 UI 專案的團隊,不用也不需瞭解後端包括 Model 層或連結資料的 Boundary 層,它只需要負責與 Control 層溝通即可; 而 Control 層,會定義系統功能的規格,包括呼叫的名稱(也就是 method 名稱)、參數與回傳值等,只要先規範好這些規格,供 UI 團隊連結呼叫即可,開發初期不需要得等到實際連結到資料庫這段工作;而 Model 這一層,甚至可以延後到系統實際上線(供 End User 操作使用)後,對於所謂企業邏輯共用性的設計需求考量,再施以結構的重整,也就是現在很熱門、從程式碼的角度來稱謂的 “重構(Refactoring)” 了。

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal