使用 UML 圖表達微服務 (Microservices)的架構設計

使用 UML 圖表達微服務 (Microservices)的架構設計

這裏藉由一個「放入購物車」的極小型功能案例,並利用 UML 各面向的設計圖,來表達微服務 (Microservices) 的架構規劃與設計的呈現樣貌。下列是幾個主要設計面向的設計圖 (並非是全部) 可以參考。

系統功能與實現程序

利用 UML 使用案例模型 (use case model) 與系統循序 (sequence) 圖表達「放入購物車」的系統功能與主要實現程序。

Microservices Use Case Model

Microservices System Sequence Diagram

  • 從需求模型可以看出共有兩個微服務:「Product Microservice」與「購物車 Microservice」。
  • 每一個微服務均各有資料庫,圖中可看出共有兩個。資料庫是私有倉儲,不能跨微服務直接存取 (即使位於同一區域都不行),只能透過 API 呼叫。

閱讀全文 »

關於 DDD (Domain Driven Development) 微服務的結構設計議題

** 本文同步發表於 FB社群-軟體設計鮮思維 **

最近在線上輔導了一位 技術職PM 結構設計的實現 (Realization)議題,他傳給我 DDD 的架構圖,覺得在「Domain Service」與「Domain Model」的責任界定上,觀念不是很清楚。

嗯,其實這所謂的 DDD (Domain Driven Development) 架構圖根本就是典型 3-tier (Presentation-Application Logic-Data Source) 分層結構呈現爲圓形的剝洋蔥層次而已,越是內層 (Domain Model) 越代表爲系統的核心。
關於 DDD (Domain Driven Development) 微服務的結構設計議題

工程師從這張圖往往會認爲「Domain Model」是最重要的核心觀念。是這樣沒錯,但對以「需求爲導向」的專案開發性質,它卻反而沒那麼重要!況且結構設計的基礎功夫要很紮實,封裝-介面-多型 諸多「虛」的設計觀念確實能充分了解並能整合活用,沒有花上 5-10 年以上功夫,是不容易應用在現實的系統開發上的。相對於此,「Domain Service」對現實的專案開發可是更切實際,且結構設計上的觀念也會比較容易入手。

閱讀全文 »

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