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

設定 SCA 以及 SDO 的開發環境

安裝步驟 Overview

    o 安裝 STP/SCA Tools
    ※ Prerequisition – 請確定已安裝 Eclipse Modeling Tool。
    安裝步驟:

  1. 打開 Eclipse Software Update,並選擇「Available Software」。
  2. 選擇 Ganymede Update Site > SOA Development > SCA Composite Tools Feature 1.0.0
  3. 鍵入 Install 按鍵
  4. 安裝 SCA 執行環境(使用Apache Tuscany):請至 http://tuscany.apache.org/sca-java-releases.html 下載最新版本的 Tuscany 以及其Source。
  5. 將Apache Tuscany解壓縮至適當路徑。
    o 安裝 SDO Runtime 以及 Eclipse Link
    安裝步驟:

  1. 設定 JAVA_HOME 環境變數以及 PATH。
  2. 下載 EclipseLink,並解壓縮。
  3. 設定 ECLIPSELINK_HOME 環境變數:
    ECLIPSELINK_HOME = <INSTALL_DIR>/eclipselink。
  4. 下載 EclipseLink for OSGi,並解壓縮至 ECLIPSELINK_HOME 目錄下。

閱讀全文 »

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

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. 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
    (點擊圖片鏈接看原圖)圖 6. SDO API

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

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

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 的最根本的目的!

軟體思維顧問

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

Personal