architecture | Kenmingの鮮思維

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

2009-05-22 11:49 | 閱覽人次：9,822 | 尚無迴響

SDO的規格

SDO (Service Data Objects) 是 Java 世界中對於 SOA 資料存取的一個架構。

在這個架構中，其主要的元素包括三個，分別是：Data Object、data graph 以及 Data Access Services (DAS)。

Data Object 主要是屬於資料面的呈現，在 Data Object 中，保存了一組的屬性 (Property)，其實非常類似傳統的Java Bean。
data graph 包裝了 Data Object，並且保存了 Data Object 操作的相關屬性(如是否有被更改…等)，一般來說，data graph 的來源可以是 Data Source(XML file, EJB或是RDB)或是Service(Web Service、JCA或是JMS)。
DAS 則是實際操作 data graph 的操作，如將 data graph 的修改註記直接 Commit 到 Data Source 中。

這三者的關係，其實非常類似 .NET Framework 的 ADO.NET 的 Dataset 結構。

Data Object可以類比為 Data Row；data graph 則類似 Dataset；而 DAS 則是 Dataset 的 Data Adapter。
我們可以利用下圖來說明者三者的關係：

（點擊圖片鏈接看原圖）圖 5. SDO的存取結構

在圖 5中表達了這個存取的結構關係。
首先 Client 要求 DAS 進行存取，DAS 到 Data Source 存取 Data Object，並將其包裝為 data graph 後回傳給 Client，此時，data graph 已經和 Data Source 分離，呈現一個 off line 的 data；當 Client 對 data graph 進行操作後，再請 DAS 將該 data graph 更改的情形 Commit 回 Data Source。

根據上圖 5的原理，SDO的API則如下圖所示：

（點擊圖片鏈接看原圖）圖 6. SDO API

在這個 API 中，其實可以更進一步看出整體 SDO 的相關重要的結構關係。

　o Java SOA 基本觀、架構與實做 ─ {01}。
　o Java SOA 基本觀、架構與實做 ─ {02}。

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

2009-05-20 16:27 | 閱覽人次：11,382 | 6 則迴響

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)
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>

2009-05-19 16:42 | 閱覽人次：17,305 | 3 則迴響

＊＊＊本系列文章與程式碼範例均為賴信仁 (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的參考架構
(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 的最根本的目的！