與資策會合作規劃的「軟體架構師」培訓課程

這是明年 (2015)元月份與資策會「數位教育研究所」所合作規劃,課程主題就定為「軟體架構師培訓班」。

綜觀軟體架構的三大構面-需求分析、結構設計、程式設計,軟體架構師要能有足夠的高度與相關技能來調和這三大面向。幾年前寫的幾篇文章,可以參考-「從軟體架構師(Architect)的觀點來看軟體開發流程」。

原來課程時數為24小時,不過整個內容規劃後時間實在有些勉強,所以協調後再調整為28個小時。兩個星期假日 (星期六、日)上完,共四天時間。

當然,短短幾十個小時也不可能窮盡涵蓋到軟體各層面的細節,所以內容的規劃係以整體性軟體架構的框架 (skeleton)為主。從介紹三大構面所各應具備的相關核心技能與技術外,再佐以實際的案例並透過實作產出得以當為範本。至於如何培養出快速聚焦的能力、有效調和各個構面的開發與相關產出,這就需要有志於往軟體架構師一職者,所應長期修鍊與學習的方向所在。

課程內容的比重,我把主軸擺在「實作性的架構設計」。這仍是比較現實的問題,在中小型系統,實作面的技術,還是決定系統開發成敗的主要關鍵。所以課程會以實際的案例演練,第一期的課程係以 Java Spring Framework 當為實作的技術與架構設計的標的 (當然再下一季的課程會考量改以 C#.NET Framework)。一致性的架構設計與規劃的理論基礎,而可以套用在不同的實作技術。

這裡我列出所規劃的課程大綱。若想瞭解更多細節或欲報名本課程的學員,可以至本文開頭所列的資策會網址瀏覽報名;另外,若讀者有一些想法與建議或問題,也歡迎在此留言討論。

課程單元 課程內容大綱
軟體架構導論 。What and Why Architecture?
。瞭解架構的三大面向-需求分析、結構設計、程式實作
。比較 Architecture/Structure/Framework 的區別與定義
。以架構為中心的開發模式
。架構的 POC (Proof of Concept)與主要產出(UML Template)
需求分析 。定義系統開發範圍 (System Boundary)
。系統需求架構設計-利用使用案例模型
。 從使用案例橋接到實作的關鍵-界定使用者期望與需求陳述
。UML 產出-使用案例、功能類別 (Class)與物件合作循序 (Sequence)圖 (Diagram)
結構設計 。定義Enterprise MVC (Model-View-Control)的分層架構規劃與設計
。展示層 (Presentation Layer)-UI 與 SOA
。領域層 (Domain Layer)-企業Domain的商務邏輯
。永續層 (Persistence Layer)-Data Access 與 Adapter
。UML 產出-類別與元件 (Component)圖
Java Spring 實作 。 Spring Framework 的核心觀念-IoC (Inversion of Control)
。Spring MVC-Web UI 的架構設計與實作
。JPA (Java Persistence API) with Hibernate-透過 JEE 標準介面實現資料存取與交易處理
案例研討 。以 推特 (Twitter)系統架構設計與開發為例
 --利用使用案例建立需求架構模型
 --Pure Web-tier UI 設計-隔離商業邏輯與資料存取
 --領域物件與資料庫的結構設計
 --Java Spring 的實作程式碼

DoDAF 案例規劃與演練《2》— OV5 (Operational Activity Model)

OV-5 — Operational Activity Model,可說是等同於傳統的企業的業務流程 (Business Process)描述, 在經由一連串的操作 (Operation)所組成的工作流程 (Workflow)後,以履行某一個業務標的或任務 (Mission)。

OV-5 的表達可說是幾乎與 UML 活動圖表達一般,它會描述在諸多活動之間包括 性能 (capibility), 活動 (activity, 或稱為工作, task), 輸入/輸出流 (I/O Flow)等資訊。

為了呈現某一連串活動所組成的活動圖,其目的為何,則可以利用企業層級的使用案例 (Business Use Case)來表達。

OV-5 精要 (Essential)筆記:

  • 利用企業層級的使用案例圖 (Business-level Use Case Diagram) 表達系統的規劃範圍。(本範例為 JFC 系統,亦即將聯合作戰指揮部當作系統)
  • 從使用案例可以看出:
    • 系統觸發事件的主要參與者 (primary actor),與系統的支援性參與者 (supporting actor)。
    • 系統所提供的服務 (service),每一個系統服務即為一個使用案例 (use case)。
  • 區分系統 “內” 與 “外” 時的好處在於:
    • 外部觀點即為功能性的需求分析,是站在外面看待如何 “用” 系統。
    • 內部觀點則著重在系統內部的組成結構元素,一般即以所謂物件導向的分析設計思維。
  • dodaf_ov5_business_usecase
    圖 1、OV5 – Business Use Case (點擊圖可察看原圖)

  • 作業活動圖 (Operational Activity Diagram)的重點在於表達什麼人(角色, role),在什麼時候,做什麼樣的事情(活動, activity),以及這些活動之間的流程關連。
  • 本張視圖的關鍵為呈現 “整體性的業務流程 (business process)”。
  • dodaf_ov5_operational_activity_model
    圖 2、OV5 – Operational Activity Model (點擊圖可察看原圖)

※延伸參考
 o DoDAF 案例規劃與演練《1》 — OV1(高階概念視圖)
 o 聊聊 DoDAF/MoDAF 規格與實作議題

DoDAF 案例規劃與演練《1》 — OV1(高階概念視圖)

對於大型系統利用 DoDAF 規格的架構規劃,其實均有個共同的特點,也就是有多個節點(Node)、多個資訊系統(Information System)。 包括軍事領域的聯合作戰指揮系統、以及政府單位防救災系統的架構規劃等,均是有這樣的特點:如何表達表達多個節點之間的關連性、如何表達多個資訊系統之間的互動。

兩個主要的觀點: Operation View and System View。 又依照每個觀點所涵蓋的層次(layer) 與 功能性質的不同,又分為 OV1~OV7, SV1~SV11。 有趣的是,即使是 Operation View,也會利用如 UML 的循序圖(sequence diagram),如 OV6,來表達節點之間的動態互動情形。 而 UML 循序圖一般是被用來表達軟體系統內部,參與物件之間的互動合作關係。 其實這隱含什麼意思呢? 很簡單的道理! 在 Operation View,也可以運用物件導向分析的手法,與 System View 所不同的只有:一個是把 Node 當物件;另一個是把 System 當物件;但是相同的是:兩者均用物件導向分析設計的思維來作塑模(Modeling)

依據「DoDAF Deskbook v1」的建議,Architecture View 的開發步驟可以參考如下圖的各種視圖的先後開發順序。 當然,這不會是絕對的,對我而言,在抓這類大型系統的架構時,首要就是要先能界定出系統的整體框架。當把某一個設計的目標框架,界定為一個系統時,就會分出 “外” 與 “內”,而兩者的分析手法與看待系統的角度就會不一樣了。 “外” 重視的是 “用”,所以會觀察系統所提供的服務,而服務就會衍生出,系統應該提供什麼 “介面(interface” 讓外部的參與者來用;再來 “內” 重視的就是系統的組成元素,這就是屬於結構分析的角度。結構分析觀察的兩個重點是,一個為靜態的結構關係、另一個就是,在動態為了完成某一個 “用” 的功能服務時,會有哪些元素的參與、它們彼此之間又是如何傳遞訊息的。 最終,你就會發現到,到底是如何 “界定” 某一個框架為一個系統,會是架構師最大的課題與其必備的素養了。

DoDAF_Architecture_View 建議開發步驟
圖 1、 摘錄自「DoDAF Deskbook v1 p.2-5」

從上圖中可以看出, 「DoDAF Deskbook」所建議的開發步驟,是以 AV1 開始觸發、以 AV2 涵蓋所有的視圖。 事實上,AV-1 是什麼呢? “Overview and Summary”。 其實它就是一份 SAD(System Architecture Document)。 文件內容大概就是包含了專案的目的、專案的描述與說明、架構規劃的標的、情境、任務、願景與目標 …等。 也就是說,在未來展開這個系統的規劃時,範圍與目標均是在該文件所描述的範圍之內。 AV-2 呢? “Integrated Dictionary”,它就是未來在涵蓋所有的視圖內,經常會使用的術語(terminology),要能給予一個明確的定義及其該字彙的意涵。

所以, “All-View” 只是文件的報告而已,真正的第一張視圖是 OV1— “High Level Operational Concept”。 這一張也可以說是要能涵蓋所要規劃系統全貌最大格局的視圖了。 它是給指揮官以上的層級所看的概念性視圖,所以盡量不要以技術面的角度來表達這張視圖。 參考下圖:

DoDAF_OV1_Conceptual_Diagram
圖 2、OV-1— 高階概念視圖

閱讀全文 »

聊聊 DoDAF/MoDAF 規格與實作議題

上上個星期,應國防某單位要求,希望由我們利用 EA(Enterprise Archiect) UML 工具,藉由一個案例,來展示在順應 DoDAF 規格下,如何從架構規劃、到依循每一個包括 Operation 與 System View 的設計圖,以及又該如何導出到實作,尤以後者,對他們很困擾,一直不知道該如何將 DoDAF 設計與實作順利地橋接在一起。

其實原來是上個月初過去介紹的是 EA 的 UML 工具,因為 EA 其中一個 Plugin 產品,稱為 MDG for DoDAF-MODAF,兩者的搭配,應用的是 UML Profile 機制,可以充分完整支援 DoDAF 1.5 的設計規格。 說真的,工具沒啥好介紹的,況且席間諸多長官與教授們問最多的問題就是有沒有 “自動化” 的機制,可以從某一個 View 的設計圖,自動轉化到另外一個 View 的設計圖。這個… 我總覺得他們研究的方向會不會有問題? 我只能反問:1. 如果規則明確,例如 OV-2(作業節點連結) 轉 OV-5(作業活動流程)有很明確轉換規格的話,那麼工具當然可以支援。 (可想而知的答案是,當然沒有那種必然明確的規則) 2.能不能轉到程式碼? 這些我都覺得都不是問題耶,前提是有沒有那種確定的規則? 有趣的是,他們用來比較 EA UML 工具的是另一套 T牌、要價 100 萬的工具,也沒有支援他們 “心目中” 的自動化啊。 所以我開玩笑的說,好吧,把那個 T牌與 EA (EA+DoDAF Plugin 才 1萬初頭)的差價,用來委託我們開發那個自動化的 Transform 機制,保證可以幫你們生的出來,不過前提是要能給我們明確的轉換規則。 🙂

我可不會想賺工具的錢啦,要能懂得設計符合 DoDAF 架構規格的系統,要具備的是軟體設計基礎功夫的底子;要能有整體性的架構觀,要知道什麼時候該封裝、什麼時候該打開,分析系統的內部;要懂得如何把一個看起來好像很大的系統(關於系統的定義,可不一定指軟體系統,在這種大格局下,包括企業單位,都可能是一個系統),該如何大題小作;又懂得那個時候該具焦在某一個焦點上,然後小題大作。 這一種整體性的設計思維,正是架構規劃與設計箇中的竅門之所在。

我想要傳達的是,我們可以協助國防某單位,如何具備能具有規劃 DoDAF 架構設計的技能(Skill),與相關軟體設計的基礎功夫,以及所該具有的技術實作能力。當然就是以顧問輔導與教育訓練為主,如果可以的話,規劃成一個外包的專案更是好,然後從實作的過程中帶著學習,作中學的效果會更好的。 不過前提是,我們總是要能先證明我們懂得如何規劃這類超大格局符合 DoDAF 規格的系統,一般當然就是出個題目了,這一向是我個人最為意願的了,比較容易在短時間內取得雙方之間彼此的信賴與共識;也比較現實,會就會,不會的話早一點出局,最不囉唆了。 喔,還有,這是繼我十餘年前從志願役中尉預官退伍後,再一次能回到軍中,為國效勞的好機會呢,哈。 😀

由於國防某單位最近忙了些,等了幾星期,還是沒拿出案例讓我們來演練,所以只好我們團隊內部自行構思一個與軍事相關的案例。 所以呢,這個案例是沒有與軍事任何單位有關連(正因如此,才能拿出來公開分享),完全是充滿想像;也沒有軍事專家的協助,所以需求必然是謬誤百出。不過這也不是什麼困擾,因為我們要做的是如何能捕捉出 DoDAF 的架構規劃與橋接到實做階段的那個精髓之所在。只要未來能有軍事領域專家的協助,那麼就很容易可以調整修正,來符合正確的需求了。

整整花了四天的時間,投入了約 2.3 個人力,以一個我們所想像創造出來的案例,也算是規劃了一個類似 C4ISR(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) 的聯合作戰指揮系統,透過偵測與防衛系統,發現到敵人即將進軍來襲時,是如何即時協同陸、海、空三軍暨後勤補給中心,來達成防衛作戰的目標。 包括了 Operation、System View 共約 17 張設計圖、再加上利用 .NET 程式碼來模擬諸多系統間的即時互動(透過 Web-Service)。 喔,甚至連那個表達 OV-1 的概念視圖,都還是請美工畫出來的呢,效果十足! 老實說,個人對我們團隊能在如此短的時間內,就能規劃出如此大的架構格局,甚至還產出程式碼來驗證架構的完整性。藉此而能解開 DoDAF 這個算是軍中資訊人員們的 “潘朵拉密盒”,可說是成就感十足,也算頗引以為傲。

ea_dodaf_demo
圖 1、 利用 EA-DoDAF 開發的 SV-1 設計圖

所完成的案例在上上星期至國防某單位的 Seminar 展示效果相當不錯! 在座許多高級長官以及教授們在會後的許多問題透過我們的解說,也算能得到合理的解釋。也讓許多中、上尉的資訊官們,見識到我們是如何從某一些 View 再轉到微觀(Micro)的實做階段。 由於沒有軍事機密等的問題存在(案例全都是想像的),所以到是可以藉由公開發表這一個案例,除了展示是如何實現 DoDAF 規格,並大概解釋一下每一個 View 的 精要(essential)設計意涵為何,同時也算是藉由此,來看看這種偏多個節點(Node)、多個資訊系統是如何做架構規劃的。

閱讀全文 »

{iThome 書評—15} Patterns Of Enterprise Application Architecture

副標題:企業層級的應用系統,是要能兼顧彈性、穩定與效能,而這需要具整體的架構設計觀與前人所提供解決方案的設計模式。

Patterns Of Enterprise Application Architecture Patterns Of Enterprise Application Architecture
———————————–
作者/Martin Fowler /著
出版社/Addison-Wesley Professional
ISBN/0321127420
Amazon 評鑑:四顆半星

內容簡介
The practice of enterprise application development has benefited from the emergence of many new enabling technologies. Multi-tiered object-oriented platforms, such as Java and .NET, have become commonplace. These new tools and technologies are capable of building powerful applications, but they are not easily implemented. Common failures in enterprise applications often occur because their developers do not understand the architectural lessons that experienced object developers have learned.

Patterns of Enterprise Application Architecture is written in direct response to the stiff challenges that face enterprise application developers. The author, noted object-oriented designer Martin Fowler, noticed that despite changes in technology–from Smalltalk to CORBA to Java to .NET–the same basic design ideas can be adapted and applied to solve common problems. With the help of an expert group of contributors, Martin distills over forty recurring solutions into patterns. The result is an indispensable handbook of solutions that are applicable to any enterprise application platform.

This book is actually two books in one. The first section is a short tutorial on developing enterprise applications, which you can read from start to finish to understand the scope of the book’s lessons. The next section, the bulk of the book, is a detailed reference to the patterns themselves. Each pattern provides usage and implementation information, as well as detailed code examples in Java or C#. The entire book is also richly illustrated with UML diagrams to further explain the concepts.

Armed with this book, you will have the knowledge necessary to make important architectural decisions about building an enterprise application and the proven patterns for use when building them.

The topics covered include:

  • Dividing an enterprise application into layers
  • The major approaches to organizing business logic
  • An in-depth treatment of mapping between objects and relational databases
  • Using Model-View-Controller to organize a Web presentation
  • Handling concurrency for data that spans multiple transactions
  • Designing distributed object interfaces

前言

每次研讀 Martin Fowler 的著作,直覺馬上就浮現出一個成語:天縱英才! 從極高度抽象的「分析模式(analysis pattern)」,對程式碼實作階段時的結構重整的 「重構(refactoring)」,以及本次書評所介紹的,關於企業層級系統平台設計議題的 「企業應用架構模式 (patterns of enterprise application architecture, 簡稱 PEAA)。 我是從來沒有看過有人可以如此像他這般,務虛與務實的不同層次都能是軟體業界的第一把交椅,著作的每一本書都是鉅作,然後又能在抽象分析、平台設計、程式碼實作等各層次整理出所謂的 “模式(pattern)”,供我輩軟體人員學習並再利用於現實的軟體開發工作。 前述的這三本書每一本都蠻厚的,但是 Fowler 也能寫出薄薄的那麼一本 「UML 精華(uml distilled)」,真正道盡 UML 的本質精髓,而熱銷全球數十萬本以上。 在我的心目中,Martin Fowler 有如神人一般,可以說是引領我在軟體業界持續奮進與學習的精神導師。

不僅如此,他寫的書,總是能以很淺顯易懂的白話來解釋看起來很深奧的道理。寫到這突然讓我想起,也算是有感而發,想當初我在啟蒙軟體領域的學習時,當然也會先從國內一些所謂的名家作者的著作來研讀。 可明明就是中文字,但閱讀起來就是很吃力,本想說是不是我真的有比較笨,領悟力差。 而後先從接觸 Fowler 的中文翻譯著作(感謝高水平的翻譯),耶! 我看得懂啊,甚至一看再看也不覺得煩,還能讀得津津有味,每一次的重讀又有不同的體會。後來再轉而看他的原文著作,雖然多少有些英文字彙的障礙,但是真的,絕對是比國內那些寫軟工書籍的作者,輕鬆易讀太多了,可以說閱讀 Fowler 的論著,就是一種享受。後來我才逐漸體悟到,太多所謂的軟工技術人,就是常賣弄太多 IT 的專業術語,而把單純的觀念表達的很複雜;還有一點,就是不容易從文字感受到這些 IT技術人 的想法,好像內容就是東拼西湊般,沒有真正自己主觀的想法。 的確,言之有物的好書能帶軟體人員上天堂;太多艱深術語、沒有自己體悟的書籍真的會讓你下地獄。

本次書評的主角,PEAA,所涉及相關軟體設計的議題可是相當廣泛,焦點是全擺在平台面系統設計的諸多議題,包括 分層結構、O-R(Object-Relation) Mapping、WebUI 的狀態控管、多人同時上線時的交易機制處理、分散式的設計策略等。 500 多頁,書本是蠻厚的,不過內容其實不會難懂 (前面說過,作者的風格就是總能以很淺顯的白話表達某一個所討論的主題)。 因為本書真的比較厚一些,我也不可能如同書摘般來記錄每一章的重點,在這裡我是想分享一下我是如何來閱讀本書的。

從書名思考本書的核心關鍵內容,找出自己的體悟

閱讀一本書籍,我總是會先從書名開始思考,本書的核心關鍵字有三個:企業應用程式(簡稱 企業AP)、架構(architecture)、模式(pattern)。 企業AP 會有什麼樣的特性,又與一般的 Web-based AP 有何差異? 我的心中大概就是浮現出大規模的企業AP特性有三:穩定、效能與彈性,三者缺一不可! 而因為有這些各個構面的考量,所以在設計議題上要相當慎重嚴謹,對於開發團隊甚或客戶而言,那種整體性的架構觀是要能有共識的。再來,由於構面與涉及的各類設計議題太多,從無到有是很辛苦的,是否可以借重 “前人” 的設計經驗來應用在現實的開發上,所以,所謂的 “模式”,包括分析、設計、乃至於實作類,期能可以協助我們來解決一再重覆發生的問題。

從關鍵字去推論目前心中的一些想法,其實也沒有什麼對或錯,心中先有個底,再去研讀內容,就會比較有感覺,也可以比較一下作者與自己想法上可能是相同也有可能是不同見解的落差。 本書從大綱的編排上,是分為兩大部分,第一部份是作者稱之為 “Narratives” 的敘述,就是我所說的,Fowler 總是以閒話家常的方式,來表達出他對某些主題的主觀想法。真的是很充分表達出他的觀感,但讀者又不會覺得有壓迫感或那種不是對就是錯的二分邏輯,實在高明之至;再來就是第二部分的 “模式”,這裡如同「重構」那本書一樣,是把每一個模式先歸納在某一個大類內,然後再給予一個名字,成為所謂的模式名錄。 本書我強烈建議的是,要先看 前言與介紹 的部分,價值非凡。 從前言你可以知道作者寫這本書的動機與所要討論的主要議題為何;而介紹也算是作者的一個導讀,也是各個主題的精要解說,甚而是會讓讀者知道可以先從哪裡看起,哪些地方又可以先略過不看,事半功倍。

前言與介紹的部分真的是太精彩了,讓我是逐字細讀來品味作者的想法。Fowler 說他是一位物件導向的狂熱份子,他也不說教,而是從敘述的過程中,讓讀者去瞭解到物件的主要優點在於對複雜的邏輯易於處理。 然後他又提到了一個很有趣的想法,他認為所謂的企業邏輯(business logic)是最沒有邏輯可言的,因為企業邏輯的複雜性,是無法被套用在任何的邏輯性模式,它就是被用在企業人(business people)來贏得商業利益的;任何一點的小改變都有可能贏得商業上的交易,而這也意味著,每一次的小改變都會導致系統的複雜度。為了應付這種 “瞬變” 的無邏輯性,企業AP 就是要被設計成很能禁得起變動,所以本書會討論的設計議題有六大項:企業AP的分層(layering)結構, 企業(領域)邏輯的結構, WebUI 的結構, O-R Mapping 的設計議題, 在 Stateless(無狀態)環境中處理 session(會談) state, 分散的原則。 在介紹這一部份,Fowler 提到了他對一些字彙(術語)的看法,我印象最深刻的就是他說他不懂架構該如何解釋,也不敢去冒犯這個詞彙 (我在想,如果連他都不敢去解釋架構的話,那還有誰能?)。 不過,他還是盡其所能說明架構對他的認知而言,第一個想到的就是 “分層(Layering)” (例如常談及的展示層、企業邏輯層、資料來源層)。 嗯,這裡我倒是也可以分享一下我對架構的看法,我以為架構是一種整體觀,整體需要時常凝聚各種不同角度的觀點,那是一種動態的調和。 另外,作者還有談及包括 效能(performance) 的設計議題,以及對於模式的應用想法。 Fowler 提到了,模式的關鍵點在於具體的實踐,是觀察人們於日常生活與工作中,觀察發現到某一個特定的解決方案;使用模式的關鍵是不能盲目去使用它,所以好像會看到同一個解決方案,但沒有一次是相同的。

設計是務實,是要能調和理想與現實的

500 多頁看來好像好多的內容,其實作者有說只要研讀第一部份即可。這一部份是屬於觀念上的引導,才一百頁而已,而每一個主題又都能分開去看它,其實讀起來並不費力。建立了在平台面設計議題的相關基礎知識與觀念後,就可以參考第二部分作者所整理提供的各類模式,例如 O-R Mapping 的相關設計模式,讓你知道如何建立 Data Mapper 的機制,來橋接領域模型的物件與關連式資料庫的表格。有需要再去看、去查這些模式,否則會很悶,這是作者對讀者的中肯建議。

先前我曾提過,許多所謂的物件導向基本教義派就是掛在無法把他們所認知那種理想美好的那一面(例如,建立純粹是領域的物件模型),給應用在現實的平台環境中。因為,現實上,沒有如此大的記憶體可以容納都是活生生的物件,所以需要給 “冬眠(hibernate)” 到如關連式的資料庫內;因為系統的資源有限,所以需要作資源的控管,包括資料庫連線與物件數量等管理;因為 WebUI 要服務更多廣眾的 Internet 用戶,所以被設計為 “無狀態(stateless)”,但是企業用戶需要的是 “stateful” 服務,如何把 stateless 作成像 stateful,就是考驗了設計者對資源與狀態控管上能否權衡的好。

這是一本專注在系統平台面設計議題的書籍,是討論關於如何把理想美好、能表達出軟體主結構的物件領域模型,橋接至利用現實系統業者所提供對企業層級的開發平台框架與應用伺服器等。對於想要瞭解企業層級的應用系統是如何調和彈性、延展度、穩定與效能等,本書絕對是必備參考的經典鉅作。

SOA (Service Oriented Architecture) 探討

問題思考

Bill Gates 曾於 1999 年在「數位神經系統」一書中提出 DNA (Distributed Network Architecture) 架構,那麼,又與現今當紅 SOA (Service-Oriented Architecture)架構有何異同?

理念相同

 o 業務驅動 IT 技術,科技支援商業。
 o 企業間的協同合作,提供即時精確的服務。
簡言之,即為以服務為導向 (service-oriented) 的架構規劃與整合,讓 IT 與 企業合為一體。

作法不同

 o DNA 走自家的 COM/COM+ 分散式技術,是屬於 “緊密式耦合 (tight-coupling)” 的連結方式;SOA 則走 Web-Service 的寬鬆連結方式 (loose-coupling)。
 o DNA 偏以自家產品 (MS Solution)為中心的整合方式;SOA 則為異質平台的整合方式,依循標準的 HTTP/SOAP, XML 的整合方式。

SOA 的四大特質

 o 簡單
 o 異質
 o 彈性
 o 寬鬆連結

  • 不同的平台之間 (.NET, J2EE, PHP/Ruby … 等),均可以透過 HTTP/SOAP 協定傳遞 XML 資料 (純文字的格式)。
  • 利用 WSDL (Web-service description language) 描述 Web服務 的公佈介面 (interfaces)。這是一個基於 XML格式的標準,以描述如何與 Web服務 通訊和使用的服務。
  • 因為是寬鬆連結,最好不要期待 Web-service 可以處理交易機制的協調處理,取用一次,完成所需的服務即可。
  • Web-service 的本質就是屬於 “state-less (無狀態)” 的機制,若是應用在 UI 與 Middleware 的系統連結上 (如 .NET Form 透過 web-service 連結 J2EE),需注意用戶端與伺服端的狀態保存與維護。

SOA 的挑戰

 o 如何作整體性的架構規劃?
 o 如何快速部署 (deploy) Web-service based 的應用程式?
 o 如何讓設計比較有彈性,以快速應付外界的需求?

整體性的架構規劃

 o 可以利用 UML 使用案例圖 (use case diagram)呈現整體架構設計。
 o Use Case 本來就是以需求服務為導向的設計,與 SOA 的標的一致,故用其作為架構設計的呈現,最為適合。
 o 每一個由 web-service 所揭露的服務 (service),會對應至一到多個使用案例 (use case)。

快速部署 WebService

 o 這是屬於系統廠商的責任,包括 MS, IBM (WebSphere), BEA (Weblogic), TiBCO 等,均能提供快速部署 Web Service 的應用程式。
 o 先進的工具還能支援:
  o 資料物件與 XML 的格式轉換
   o Java Bean to XML (反之亦然)。
   o DataSet to XML (反之亦然)。
  o Support XML Schema 的設計與定義。

彈性的設計

 o 這是屬於 Developer 的責任。
 o 這是軟體設計最為嚴謹且為最大挑戰的領域。
 o “應變” 是軟體設計者應有的態度。
 o 可先以 “分層結構 (後述)” 作為系統開發的 “cook book”,先瞭解與熟悉 “委派(delegate)” 的設計手法。

軟體思維顧問

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

Personal