soa | Kenmingの鮮思維

「軟體需求分析與塑模」－什麼是系統功能

2018-10-02 16:16 | 閱覽人次：4,281 | 尚無迴響

本文收錄於我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

系統 (system) 是由一組互動 (interacting) 或獨立的元件 (component) 所組成的整合體 (integrated whole)。

系統功能 (system functions)，即為某一整合體所提供給外界 (參與者或外部系統)的一連串服務 (services)。

把企業 (business) 當成一個整合體，並藉以分析該整合體所提供的功能需求，以及組成該整合體的組成元素。這樣以企業為標的的分析塑模方式，稱為「企業塑模 (business modeling)」。

把資訊系統 (information system) 當成一個整合體，並藉以分析該整合體所提供的系統功能，以及組合該整合體的結構元素。這樣以資訊系統為標的的分析塑模方式，稱為「資訊系統塑模 (information system modeling)」。

把企業或資訊系統當為一個整合體，便可以採用相同的手法，如利用 UML (Unified Modeling Language) 語法，來分析系統需求。

「企業」與「資訊系統」兩者的關係即為，「資訊系統」為組成「企業」內部結構的其中之一的元素 (element)。而當把焦點轉移至資訊系統，探究其中所提供的系統需求 (系統功能)時，則再將「資訊系統」這個結構元素放大，並從「外」的需求分析，與「內」的結構設計來看待資訊系統的分析、設計，乃至於實作了。

參考上節範例，「診療服務」為企業的系統需求，如果企業架構師規劃了三個資訊系統 (組成元素) 的支援，參考如下圖，架構師可以利用 UML 使用案例圖表 (use case diagram) 規劃每一個資訊系統各有其需實現的系統功能，以及資訊系統之間的關係是透過介面 (interface)的連接達成所謂的「SOA (service-oriented architecture)」架構。

至於資訊系統是如何實現系統功能，又如何連接其它外部系統，那就是所謂的系統（這裡就是指資訊系統了) 結構設計與實作的議題了。

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

2009-05-27 11:53 | 閱覽人次：7,907 | 尚無迴響

設定 SCA 以及 SDO 的開發環境

安裝步驟 Overview

安裝 STP/SCA Tools

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

安裝 SDO Runtime 以及 Eclipse Link

設定 JAVA_HOME 環境變數以及 PATH。
下載 EclipseLink，並解壓縮。

設定 ECLIPSELINK_HOME 環境變數：

ECLIPSELINK_HOME = <INSTALL_DIR>/eclipselink。

下載 EclipseLink for OSGi，並解壓縮至 ECLIPSELINK_HOME 目錄下。

閱讀全文 »

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

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

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,660 | 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,865 | 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 的最根本的目的！