一、 TDMA技術
英文全寫是Time-Division Multiple Access，中文翻譯成分時多工存取。以聲音溝通為例，顧名思義，TDMA技術是將每個發言者發言的時間錯開。也就是同一時間只能有一個人發言，如此發言者的聲音便不會受到干擾，並可清楚的傳達。以行動電話系統比喻為一般的開會場合。行動電話基地台可以比喻為主席，而行動電話使用者比喻為參與開會者。當很多人同時要發言時，主席可分派每個人發言之順序及時間，而每個發言人依分配之時間進行發言，如此便可避免開會常有的吵雜情況。當然在使用行動電話時，使用者並不會有分時發言的感覺，原因是這種分時切換的頻率很快，而且聲音經由數位壓縮後，只要很短的時間就可將代表某一時段的聲音訊號傳送出去，而其他的時間則分配給其他的使用者。此項技術被應用於目前之GSM(http://www.gsmdata.com/)行動電話系統及部分之衛星通訊系統。
二、 FDMA技術
英文全寫是Frequency-Division Multiple Access，中文翻譯為分頻多工存取。以收音機為例，很多電台要同時將訊號以無線電廣播，因此在空間上所有訊號是混在一起的。但利用分頻技術，每個電台使用之廣播頻率是分開來的，例如ICRT使用100.1Mhz而警廣使用105.1Mhz，因此在收音機上便可利用濾波器(filter)調整而將某個你想聽的電台代表的一段頻率取出並濾掉其他之頻率，此訊號再加以解調產生聲音訊號。真正的FDMA技術是將每個發送端的數位訊號調變到不同的頻率，而接收端則將欲接收訊號以濾波器濾出，再還原為數位訊號。類似技術被採用於舊式的行動電話系統(AMPS系統)，但是由於其系統真正的通訊量不佳，因此漸被淘汰。
分頻多工是最舊但仍廣泛使用的頻道分配計劃，雖然簡單，但FDM仍有一些缺點。首先在頻道中間必須有看守頻帶(guard band)，以便將工作站區隔，這種需求的存在是因為傳輸器在主頻帶輸出能量時，也會影響到副頻帶，而浪費在看守頻帶的頻寬佔總頻寬很大一部份。
另外，工作站的效率必須仔細的控制，如果工作站在主頻道放出太多的功率，同樣也會放出許多功率在副頻帶上，並且擴散到相鄰的頻道上，進而發生干擾現象。
最後 FDM是一個完整的類比技術它不是很容易使用軟體製造出來。
10月 22, 2010
10月 18, 2010
PCM (pulse code modulition)
早期的通信，大部份是採用連續型類比信號來傳輸。但由於數位電腦及網路多重通訊的興盛，使得許多資訊以脈波方式來傳送較為簡單與方便。脈波調變可用來傳輸如類比語音或資料之用。其方法是以一定的速率對連續波信號作取樣，而此速率亦是其傳輸速率。在接收端，將接收到的脈波作解調以還原回原來的連續波類比信號。脈波調變一般常見的有脈波振幅調變（Pulse-amplitude modulation,PAM），脈波寬度調變（Pulse-width modulation, PWN）脈波位置調變（Pulse Position modulation,PPM）以及脈波符碼調變（Pulse code modulation, PCM）。其中前三者是屬於類比式調變，而PCM則是屬於數位式調變，將分逑於下面各節。值得注意的是PCM是真正的數位信號，故可透過電腦進行資料處理與貯存。PAM，PWM以及PPM則分別有點類似於AM，FM以及PM。
任何脈波調變在調變前皆須經過取樣信號對原始連續型信號作取樣，而取樣信號之取樣速率不可過低，否則還原後的信號會產生失真。取樣速率大小須依循取樣定理（Sampling theorem）。其定理如下：在任何脈波調變系統中，若取樣速率超過信號的最大頻率的二倍以上，則接收端重建還原的信號之失真程度會最小。例如語音信號頻率範圍為40～4K HZ間，作脈波調變之取樣信號頻率至少須8K HZ以上，取樣誤差方可降至最小。
PCM是對類比信號的振幅作取樣後，再利用類比對數位的轉換後，編碼成〝0〝與〝1〝數位信號再作傳輸。如圖所示：
其中在取樣化時間內將類比位準化為脈衝數的過程稱量子化（quantization）再加以符碼化（coding）即可完成PCM符碼脈衝輸出。事實上，量子化和符碼化的過程，都是由A/D轉換器一次完成。須注意的是3碼的PCM碼，23 =8，即其量子位階（quantizationlevels）為8階。PCM碼再增加一碼，其量子位階變成24=16，其傳真性會增加 ，但頻亦隨之增加。
總的來說，PCM的產生，須先透過取樣取得與原信號振幅成正比的脈波（此即PAM信號），再將比PAM信號量化及編碼甚至再加上控制碼即可直接透過纜線作傳輸或再經調變後由發射機發射出去。在接收端，PCM先轉成PAM信號，再解調回原始類比信號。由於PCM信號是屬於數位信號，其對雜訊的免疫力甚高且可作TDM的多重通訊，更可在一段長距離傳輸後透過重覆器（repeater）作數位信號重整，因此，目前長距離電話語音通訊大都採用PCM方式傳輸。
任何脈波調變在調變前皆須經過取樣信號對原始連續型信號作取樣，而取樣信號之取樣速率不可過低，否則還原後的信號會產生失真。取樣速率大小須依循取樣定理（Sampling theorem）。其定理如下：在任何脈波調變系統中，若取樣速率超過信號的最大頻率的二倍以上，則接收端重建還原的信號之失真程度會最小。例如語音信號頻率範圍為40～4K HZ間，作脈波調變之取樣信號頻率至少須8K HZ以上，取樣誤差方可降至最小。
PCM是對類比信號的振幅作取樣後，再利用類比對數位的轉換後，編碼成〝0〝與〝1〝數位信號再作傳輸。如圖所示：
其中在取樣化時間內將類比位準化為脈衝數的過程稱量子化（quantization）再加以符碼化（coding）即可完成PCM符碼脈衝輸出。事實上，量子化和符碼化的過程，都是由A/D轉換器一次完成。須注意的是3碼的PCM碼，23 =8，即其量子位階（quantizationlevels）為8階。PCM碼再增加一碼，其量子位階變成24=16，其傳真性會增加 ，但頻亦隨之增加。
總的來說，PCM的產生，須先透過取樣取得與原信號振幅成正比的脈波（此即PAM信號），再將比PAM信號量化及編碼甚至再加上控制碼即可直接透過纜線作傳輸或再經調變後由發射機發射出去。在接收端，PCM先轉成PAM信號，再解調回原始類比信號。由於PCM信號是屬於數位信號，其對雜訊的免疫力甚高且可作TDM的多重通訊，更可在一段長距離傳輸後透過重覆器（repeater）作數位信號重整，因此，目前長距離電話語音通訊大都採用PCM方式傳輸。
10月 15, 2010
各類開發模式
SDLC
使用者可以清楚表達需求，開發階段均要清楚系統範圍，要有設計規畫文件、每個階段要進行驗證後，才可進入下階。
漸增
在瀑布模式中，一次要考量所有需求，而且在一個週期內就完成系統開發，執行上會有些難度，所以漸增模式就把需求切割成子系統，各別使用 SDLC 週期進行開發。由於每個週期都有使用者參與，所以可以盡早發現問題。
適用：需求明確，預算分期編列，組織需要時間熟悉新科技。
雛型
瀑布與漸增模式的運作基礎，是在需求能明確表達的前提下。但此與實際狀況不合，通常「使用者無法清楚表達需求」、「系統分析師經不夠，無法即時想出恰當方案」。針對這樣的狀況，只能針對需求較明確的部份，先行開發出一個系統雛型，再以此為基礎，作為溝通工具，釐清與反覆確認使用者需求。
特點：
- 使用者高度參與，而且任何時間都可變更需求。
- 適用在高風險、高變動性的專案上。
- 快速見到系統雛型，失敗成本低。
- 不適用在大型、複雜專案上。
1. 演進式：從需求清楚的部份進行開發，完成初版後，下次再以此為演進依據，加上使用者的回饋，反覆修改。每次演進都會一併考量新、舊需求。適用在系統開發初期，需求不明確時。
2. 設計式：用後即丟，用來確認需求規格，使用快速而粗糙的方式建立雛型，促使用戶決定需求項目。適用在高風險、高困難度之專案上。因為用後即丟，表示未來必需拋棄該架構，所以成本相對高。
螺旋
強調各開發週期的風險評估，
(1)找出目標限制 (2)評估方案風險 (3)由風險決定下一步
同步
把一個版本的系統分成多個「功能組」平行分派給多個團隊，進行開發。當一個版本的系統開發完成，交由獨立團隊進行測試，此時開發團隊可以進行下一版本的開發。目的在於縮短開發時程。主要精神有三：1. 多團隊開發，多個工作平行進行，這種多組人同時工作的方式稱為活動同步
2. 資訊同步，各組間可以相互交流共享(向前/後傳遞)
3. 整合性的管理系統，因為使用同步模式，人力規模較傳統來得複雜。
RUP
使用反覆(Iterative)與漸增(Incremental)的方式進行軟體開發。反覆指的是，使用相同的步驟進行系統開發；漸增指的是，每次都在軟體上加入新功能、模組。每一次的反覆都會生成一個可運作版本，並可在每個週期中評估相關風險。
動態階段：
1. 初始：瞭解專案風險，建立系統需求與範圍，取得人員認同 (完成專案生命週期目標)
2. 詳述：進行系統的設計、編碼、測試。並以實際的程式架構，來探討技術風險。建立系統基本結構 (完成生命週期結構)
3. 建構：建立一個初步可運行版本(可演化)系統α版 (最後完成一個有完整功能的系統β版)
4. 轉移：建立最終軟體交給顧客 (完成產品出版)，包括備份、培訓、支援。
靜態階段：
1. 企業塑模：導出系統需求以支援組織目標，產出企業模型。
2. 需求：定義軟體細部需求
3. 分析設計：將需求轉成系統實作的規格
4. 實作
5. 測試
6. 配置
7. 組態管理、專案管理、環境 - 此屬管理支援
模式驅動結構 MDA (Model Driven Architecture)
(1) 每個過程都會產出「模式」
(2) 模式的表達是用「正規模式」讓電腦可以理解
(3) 分析階段產出 PIM(高階抽象模式，與開發技術獨立，不涉及運作平台)
(4) 設計階段產出 PSM(與特定平台相關)
(5) 三個核心是：PIM + PSM + Code
敏捷開發 (Agile)
適用在：非關鍵專案、公司文化適合、地域近、有經驗團隊
(1) 個體的互動勝於流程：重視團隊工作，SA、程式師、客戶一起工作
(2) 可運作軟體勝於文件：用軟體來衡量開發進度
(3) 懂得變化，而非遵守計畫。
極限編程 (Extreme Programming, XP)
(1) 編碼，程式師碰到開發問題時，可用所寫的程式與人討論想法
(2) 測試，系統開發時間，使用測試來確認功能可否運作。
(3) 傾聽，開發人員要傾聽使用者需求
(4) 設計，系統開發需要經由設計來釐清系統範圍
10月 13, 2010
ISDN 簡介
PSDN (分封交換資料網路)
PSDN (Packet Switching Data Network) 同 PSN(Packet Switching Network)。是將傳輸資料分割成為較小的封包(packet) 之後，並將每一個封包加上 header(以免封包在傳輸的過程當中遺失)，之後在網路上傳遞，當所有封包都到達目的地之後，接收者會將封包依照順序組合起來，成為要傳送的原始資料，非同步傳輸模式 (ATM) 使用的便是分封交換技術。
ISDN (整體服務數位網路)
ISDN (Integrated Services Digital Network) 是利用現有的電話線路來高速傳遞訊息的一種技術，它在現有的線路上可以傳遞數位訊號，達到比數據機較高的傳輸速率，但是卻比專線 (leased line) 較低的使用花費。
基本上，ISDN 是以撥接式的方式連接，這表示當使用者有需要使用網路時，才將電腦透過 ISDN 連接到電信公司。但是 ISDN 卻可以同時適用於電路交換(circuit switched) 或是分封交換 (packed switched) 的網路中，前者是以 B (Bearer)通道來達成，這表示 B 通道必須使用獨佔式線路，後者則以 D (Delta) 通道來達成，所以 D 通道可能不會使用整個 64 Kbps 的頻寬。
B 通道可以傳送數位化的語音與資料，而 D 通道則可以傳遞控制訊號與資料，兩者的傳輸速率都可以達 64 Kbps。實際應用上，ISDN 分為基礎速率(Basic-Rate ISDN，簡稱 BRI) 與主要速率 (Primary-Rate ISDN、PRI) 兩種，前者提供兩個 B Channels 與一個 D Channel；後者在美國系統提供 23 個 B Channels 與一個 DChannel，歐洲系統則提供 30 個 B Channels 與一個 D Channel。
通常我們將超過一個 T1 (1.544 Mbps) 或是 E1 (2.048 Mbps) 速率的 ISDN 另外歸類為『寬頻 ISDN』(Broadband ISDN、B-ISDN)，通常它是架構在 ATM 或是光纖網路上；而前述的 BRI (2B+D) 或是 PRI (23B+D、30B+D) 則為『窄頻ISDN』(Narrowband ISDN、N-ISDN)，或是簡稱為 ISDN。
未來的 ISDN 可能架構在光纖網路 (fiber optical network)，以改進目前電信線路的品質和傳輸效率。ISDN 目前最可能的利用是在於視訊會議系統(video conference)，透過 ISDN 網路將各地的使用者集合於電腦螢幕上，此外凡是多媒體系統在廣域網路 (WAN) 上的應用，都可利用 ISDN提供電傳視訊、音響、數據傳輸等功能。
PSDN (Packet Switching Data Network) 同 PSN(Packet Switching Network)。是將傳輸資料分割成為較小的封包(packet) 之後，並將每一個封包加上 header(以免封包在傳輸的過程當中遺失)，之後在網路上傳遞，當所有封包都到達目的地之後，接收者會將封包依照順序組合起來，成為要傳送的原始資料，非同步傳輸模式 (ATM) 使用的便是分封交換技術。
ISDN (整體服務數位網路)
ISDN (Integrated Services Digital Network) 是利用現有的電話線路來高速傳遞訊息的一種技術，它在現有的線路上可以傳遞數位訊號，達到比數據機較高的傳輸速率，但是卻比專線 (leased line) 較低的使用花費。
基本上，ISDN 是以撥接式的方式連接，這表示當使用者有需要使用網路時，才將電腦透過 ISDN 連接到電信公司。但是 ISDN 卻可以同時適用於電路交換(circuit switched) 或是分封交換 (packed switched) 的網路中，前者是以 B (Bearer)通道來達成，這表示 B 通道必須使用獨佔式線路，後者則以 D (Delta) 通道來達成，所以 D 通道可能不會使用整個 64 Kbps 的頻寬。
B 通道可以傳送數位化的語音與資料，而 D 通道則可以傳遞控制訊號與資料，兩者的傳輸速率都可以達 64 Kbps。實際應用上，ISDN 分為基礎速率(Basic-Rate ISDN，簡稱 BRI) 與主要速率 (Primary-Rate ISDN、PRI) 兩種，前者提供兩個 B Channels 與一個 D Channel；後者在美國系統提供 23 個 B Channels 與一個 DChannel，歐洲系統則提供 30 個 B Channels 與一個 D Channel。
通常我們將超過一個 T1 (1.544 Mbps) 或是 E1 (2.048 Mbps) 速率的 ISDN 另外歸類為『寬頻 ISDN』(Broadband ISDN、B-ISDN)，通常它是架構在 ATM 或是光纖網路上；而前述的 BRI (2B+D) 或是 PRI (23B+D、30B+D) 則為『窄頻ISDN』(Narrowband ISDN、N-ISDN)，或是簡稱為 ISDN。
未來的 ISDN 可能架構在光纖網路 (fiber optical network)，以改進目前電信線路的品質和傳輸效率。ISDN 目前最可能的利用是在於視訊會議系統(video conference)，透過 ISDN 網路將各地的使用者集合於電腦螢幕上，此外凡是多媒體系統在廣域網路 (WAN) 上的應用，都可利用 ISDN提供電傳視訊、音響、數據傳輸等功能。
10月 08, 2010
Protocol Data Unit
PDU = PCI + SDU
- PDU (Protocol Data Unit, 通信協定資料單元) ... HDR+BODY
- PCI (Protocol Control Information, 通信協定控制資訊) ... HDR
- SDU (Service Data Unit, 服務資料單元) ... BODY
10月 07, 2010
10月 06, 2010
SOA 是啥
最近一年多以來，SOA（Service-Oriented Architecture，服務導向架構）成為IT界的當紅炸子雞。
隨著媒體與IT大廠的炒作，好像一談到「整合」就非SOA不可。很多技術詞彙（例如：BPEL、ESB、BAM…）也在這個過程中不斷地被創造出來，但這些一技術詞彙好像並不會幫助我們對於SOA在應用上的了解，甚至只會令人更懷疑這些名詞只是IT產業又拿出來行銷的噱頭而已。
事實上，技術出身的我不得不承認，SOA有一種架構性美很容易讓技術人員醉心。但在同事朋友們討論SOA的時候，總覺得少了什麼？這樣的美可以幫助我們解決什麼樣的問題呢？如果只是架構上的美，終究也只限於技術架構的美而已，有什麼資訊問題是無法用傳統EAI（Enterprise Application Integration）技術手法來解決而一定要採用SOA嗎？還是它的美只存在於IT學院的象牙塔之中呢？
面對業界許多（非IT領域）朋友的疑惑，我決定寫這一篇文章來重新為SOA「正名」，從IT在商業運作上應用的角度來闡述SOA主要所要解決的問題，讓大家再從另一個角度來看SOA。
定義：不只是技術，是IT架構
或許已經有讀者注意到了，我們通常談到IT，大部份都會說是XX「技術」，但為什麼沒有聽過有人說SOA「技術」呢？如果我們看SOA（Service- Oriented Architecture）這三個英文字母，會發現SOA中的「A」竟然是Architecture（架構）這個字。單就語句結構上來看，如果在「架構」這個字詞後面再扯上「技術」兩個字，還真有點奇怪。
嚴格說來，SOA這一個詞並不是指一種「技術」，而是指一種IT架構，當然，這樣架構下會有各種不同的技術，來解決企業在面對商業自動化的所面臨的各種不同的問題。
本文將先介紹SOA對企業的意義，主要在藉由商業自動化，以協助企業解決一個千古不變的難題：變。
自動化服務元件是商業自動化的第一步
SOA（Service-Oriented Architecture，服務導向架構）顧名思義，以「服務」做為導向來出發，以設計並建構我們的系統構架。簡單來說，我們可以說：「服務導向架構」目的是要達到一個自動化的商業行為。
首先，讓我們舉個例子說明。澳圖美德（Automated）科技是一個系統整合廠商，在他的商業行為中，他需要經常對他的供應商（例如SUN Microsystems）來進行詢料（特別是在庫存中並沒有足夠的備料時）。
早期這樣的一個行為，是由純人工的方式來處理，需要再透過SUN業務同仁處理（包括報價及答覆商品的Delivery Time），但在整個商業流程中，商品的報價與Delivery Time並不會有經常性的異動，因此這樣的做法是一種人力資源的浪費。
為了避免這樣的問題，我們可以將上下流兩個公司的系統做適當的調整，讓SUN公司在系統中建架一個服務元件來提供價格與Delivery Time 的資料查詢，直接利用在澳圖美德內部的系統來呼叫SUN公司所提供的服務元件，澳圖美德的同仁即可完成報價與Delivery Time（交期）的詢問。所以可以認知到的是，在商業自動化的前提下，SOA需提供一個「跨系統的資料交換與傳遞的規範與方法」，以便商業上的資訊交換。而在整個架構中，被實做出來以負責資訊的交換與傳遞的程式一個個的模組，我們可稱為服務元件。
或許有些讀者會發現，這樣的做法，不就是幾年前 Web Service的技術觀念下就已經提出來的做法嗎？這跟SOA 有什麼關係呢？
當然，如果只是上述的例子中所提到的需求，其實只要用 Web Service就可以做到了。那SOA可以再解決什麼樣的問題呢？藉由上面的例子，我們再來拉大企業的需求，以再進一步認識 SOA。
「服務元件」結合「流程」提供更多樣的自動化服務
由上述的例子，如果單純從資料流的角度來看，我們可以說：「澳圖美德公司與SUN公司在做資料交換的動作，讓澳圖美德員工可以很輕易得到他需要的資料。」但其實自動化的商業行為並不只是資料交換那麼單純；例如，以身份認証而言：是不是所有的廠商都不需經過認証就可以呼叫SUN公司所提供的元件來取得SUN的報價與 Delivery Time 呢？或者不同的協力廠商所取得報價會相同嗎（不同的協力廠商有可能會因不同的規範而有不同的報價）？再從流程的角度來看，整個商業行為並不是在取得報價後就結束了–是不是要有詢價記錄（以便未來的追蹤）？
或者，如果價格合理，那就會進入採購的程序。如果價格不被接受，那則有可能進行到議價的程序，如果該項商品還有多個供應商的話，那也有可能進入到詢價、比較的不同的程序。甚至不同供應商也有可能有不同的作業流程或程序，有些一定要先下單再出貨，有些關係好的則可以先出貨再下單。有的商品則有可能要先下樣品單，甚至樣品交貨的同時也要先付貨款等等。
因此很單純地由一個服務元件來進行資料交換，並無法滿足商業行為自動化的所有需求。在一個完整的商業自動化行為中，往往需要由一組（多個）可能由多個不同系統提供的服務元件來進行服務。
例如，系統應該先進行身份確認（這裏是一個身份確認的服務元件），再來才進行詢報價程序（這裏應該又是另外一個服務元件），最後，當買方確認要進行下單的時候，才會進入採購程序（進入採購流程應該又是另外一組服務元件，甚至有可能對應到另外一個獨立的系統中）。而組織、整合並決定所有的服務元件的使用順序地即是「流程」。因此商業自動化的目的下，如何進行跨程式語言、跨系統、跨組織、甚至跨企業的流程架構、規劃、設計與實作，也是SOA 要思考與規範的重點項目。
我一開始說SOA有種架構性的美，是指它作為一種IT架構，竟與哲學中的現象學具有同樣的世界觀 。現象學提到「存有」與「關係」。「存有」在OO（物件導向，Object-Oriented）中（註），可以視為是物件，而在SOA中，我們可以說它是服務元件。而關係，在OO中就是那個方法，而在SOA中，就是跟時間一起被定義在流程之中。SOA即是結合服務元件及流程的很嚴謹、很工整的架構（待續）。
註
Service-Oriented 與 Object-Oriented：
看到Service-Oriented，IT產業較熟悉的人應該就會直接覺得想到OO（Object-Oriented，物件導向）。確實，從觀念上來說，這兩個概念是雷同的，只不過它們所關切並要解決的問題是屬於不同層面的：SOA是從商業邏輯成層面來看，以減少系統中服務元件設計與開發的時間；而 OO則是關注程式設計與開發的層面，以減少程式元件重新開發的時間。
昨天談到SOA之所以不同，是因為它結合服務元件及流程，而形成嚴謹而具有美感架構的IT概念。但它是不是僅只是於「比較美」而已呢？它對企業運作，是不是真的發揮效益呢？讓我們再隨著昨天的例子繼續走下去。
「變」才是自動化IT最大挑戰
伴隨著澳圖美德跟Sun 原廠生意往來的增加，他們的合作關係越來越密切，也越來越有信任感，因此在兩邊老闆與業務同仁熱切期望與鼓吹下，在短短一個禮拜會議討論後，老闆們握手作出以下決議：「面對市場的快速反應，某些單期的商品，只要是澳圖美德業務人員確認後的訂單，Sun原廠這邊就可以直接出貨，澳圖美德的同仁只要事後在一個月內補上訂單及貨款即可，以縮短整體的交期。」
這樣的消息對兩個公司的業務同仁而言都是一個普天同慶的大好消息，特別在信任感足夠的前提下，交期縮短的做法會讓客戶滿意度增加，並相對地提升業績，特別對澳圖美德而言，這樣的做法會縮短貨品在途與減少庫存，可大大提升兩個公司在整體銷售上的執行力。
但獲得執行力是要付出代價的。
老闆又繼續說了下去：「為符合這樣的需求，請IT人員於半個月內修改系統…」一語未閉，資訊部門的同仁全都當場傻眼（並考慮要不要遞出辭呈）：天啊，當初為了達到整體的商業自動化，花了澳圖美德公司與Sun原廠的資訊同仁們三個月時間的系統分析以及六個月的程式撰寫，最後逐一的測試，直到上個月才剛算完全測試完成的系統，半個月要怎麼改啊？瘋了嗎？
IT主管們（特別是資訊長與技術長）所面臨的最大挑戰並不是一個固定的商業行為，其實大部份跨企業/組織的商業流程自動化需求都可以利用傳統EAI所使用的IT技術手法來完成；講白了，IT人員只要把商業的作業流程定義清楚，不管採用什麼技術（VB、JAVA、N-tier、 mainframe、有資料庫就用資料庫，沒有資料庫就用最笨的方式，像是TEXT file等），大部份商業上的需求都還是可以硬生生--不論用苦力技術或高級的方式（例如物件導向加XML）來實作出來，但最大的挑戰往往發生在商業流程改變的時候。
「規劃永遠趕不上商業變化。」這是所有IT人的痛，因此當我們談到商業自動化，「流程」只是故事的一半而已。也是SOA的切入點所在。
在瞬息萬變的經營環境中，SOA目的在更深一層去關切並預想商業流程的變異性，並思考、定義與切割一個個服務與流程，以強化企業商業自動化的靈活度。
是行銷名詞還是真的有用？
談到這邊，我想「為什麼要SOA？」或「SOA是不是一個行銷術語？」應該會得到較清楚的答案。在商業自動化為前提下，「服務元件」與「流程」可視為商業自動化的基本元素。面對商業行為的變異性，在「服務元件」與「流程」的設計與實作上，應該要達到彈性並且可以重複被使用的水準，以減少系統重複開發的時間，這樣子以商業服務為基本元素來做為的出發點，而設計出來的IT架構，我們就稱之為「服務導向架構」(SOA)。
面對企業資訊「整合」的需求，SOA並不是唯一的答案，但無疑地，隨著SOA技術逐漸發展成熟，新的概念與技術可以讓企業面對商業整合時可擁有更大的彈性與效率。而接下來的專欄文章中，我們將陸續探討SOA對企業內人事、流程、甚至CEO角色職權的衝擊。
隨著媒體與IT大廠的炒作，好像一談到「整合」就非SOA不可。很多技術詞彙（例如：BPEL、ESB、BAM…）也在這個過程中不斷地被創造出來，但這些一技術詞彙好像並不會幫助我們對於SOA在應用上的了解，甚至只會令人更懷疑這些名詞只是IT產業又拿出來行銷的噱頭而已。
事實上，技術出身的我不得不承認，SOA有一種架構性美很容易讓技術人員醉心。但在同事朋友們討論SOA的時候，總覺得少了什麼？這樣的美可以幫助我們解決什麼樣的問題呢？如果只是架構上的美，終究也只限於技術架構的美而已，有什麼資訊問題是無法用傳統EAI（Enterprise Application Integration）技術手法來解決而一定要採用SOA嗎？還是它的美只存在於IT學院的象牙塔之中呢？
面對業界許多（非IT領域）朋友的疑惑，我決定寫這一篇文章來重新為SOA「正名」，從IT在商業運作上應用的角度來闡述SOA主要所要解決的問題，讓大家再從另一個角度來看SOA。
定義：不只是技術，是IT架構
或許已經有讀者注意到了，我們通常談到IT，大部份都會說是XX「技術」，但為什麼沒有聽過有人說SOA「技術」呢？如果我們看SOA（Service- Oriented Architecture）這三個英文字母，會發現SOA中的「A」竟然是Architecture（架構）這個字。單就語句結構上來看，如果在「架構」這個字詞後面再扯上「技術」兩個字，還真有點奇怪。
嚴格說來，SOA這一個詞並不是指一種「技術」，而是指一種IT架構，當然，這樣架構下會有各種不同的技術，來解決企業在面對商業自動化的所面臨的各種不同的問題。
本文將先介紹SOA對企業的意義，主要在藉由商業自動化，以協助企業解決一個千古不變的難題：變。
自動化服務元件是商業自動化的第一步
SOA（Service-Oriented Architecture，服務導向架構）顧名思義，以「服務」做為導向來出發，以設計並建構我們的系統構架。簡單來說，我們可以說：「服務導向架構」目的是要達到一個自動化的商業行為。
首先，讓我們舉個例子說明。澳圖美德（Automated）科技是一個系統整合廠商，在他的商業行為中，他需要經常對他的供應商（例如SUN Microsystems）來進行詢料（特別是在庫存中並沒有足夠的備料時）。
早期這樣的一個行為，是由純人工的方式來處理，需要再透過SUN業務同仁處理（包括報價及答覆商品的Delivery Time），但在整個商業流程中，商品的報價與Delivery Time並不會有經常性的異動，因此這樣的做法是一種人力資源的浪費。
為了避免這樣的問題，我們可以將上下流兩個公司的系統做適當的調整，讓SUN公司在系統中建架一個服務元件來提供價格與Delivery Time 的資料查詢，直接利用在澳圖美德內部的系統來呼叫SUN公司所提供的服務元件，澳圖美德的同仁即可完成報價與Delivery Time（交期）的詢問。所以可以認知到的是，在商業自動化的前提下，SOA需提供一個「跨系統的資料交換與傳遞的規範與方法」，以便商業上的資訊交換。而在整個架構中，被實做出來以負責資訊的交換與傳遞的程式一個個的模組，我們可稱為服務元件。
或許有些讀者會發現，這樣的做法，不就是幾年前 Web Service的技術觀念下就已經提出來的做法嗎？這跟SOA 有什麼關係呢？
當然，如果只是上述的例子中所提到的需求，其實只要用 Web Service就可以做到了。那SOA可以再解決什麼樣的問題呢？藉由上面的例子，我們再來拉大企業的需求，以再進一步認識 SOA。
「服務元件」結合「流程」提供更多樣的自動化服務
由上述的例子，如果單純從資料流的角度來看，我們可以說：「澳圖美德公司與SUN公司在做資料交換的動作，讓澳圖美德員工可以很輕易得到他需要的資料。」但其實自動化的商業行為並不只是資料交換那麼單純；例如，以身份認証而言：是不是所有的廠商都不需經過認証就可以呼叫SUN公司所提供的元件來取得SUN的報價與 Delivery Time 呢？或者不同的協力廠商所取得報價會相同嗎（不同的協力廠商有可能會因不同的規範而有不同的報價）？再從流程的角度來看，整個商業行為並不是在取得報價後就結束了–是不是要有詢價記錄（以便未來的追蹤）？
或者，如果價格合理，那就會進入採購的程序。如果價格不被接受，那則有可能進行到議價的程序，如果該項商品還有多個供應商的話，那也有可能進入到詢價、比較的不同的程序。甚至不同供應商也有可能有不同的作業流程或程序，有些一定要先下單再出貨，有些關係好的則可以先出貨再下單。有的商品則有可能要先下樣品單，甚至樣品交貨的同時也要先付貨款等等。
因此很單純地由一個服務元件來進行資料交換，並無法滿足商業行為自動化的所有需求。在一個完整的商業自動化行為中，往往需要由一組（多個）可能由多個不同系統提供的服務元件來進行服務。
例如，系統應該先進行身份確認（這裏是一個身份確認的服務元件），再來才進行詢報價程序（這裏應該又是另外一個服務元件），最後，當買方確認要進行下單的時候，才會進入採購程序（進入採購流程應該又是另外一組服務元件，甚至有可能對應到另外一個獨立的系統中）。而組織、整合並決定所有的服務元件的使用順序地即是「流程」。因此商業自動化的目的下，如何進行跨程式語言、跨系統、跨組織、甚至跨企業的流程架構、規劃、設計與實作，也是SOA 要思考與規範的重點項目。
我一開始說SOA有種架構性的美，是指它作為一種IT架構，竟與哲學中的現象學具有同樣的世界觀 。現象學提到「存有」與「關係」。「存有」在OO（物件導向，Object-Oriented）中（註），可以視為是物件，而在SOA中，我們可以說它是服務元件。而關係，在OO中就是那個方法，而在SOA中，就是跟時間一起被定義在流程之中。SOA即是結合服務元件及流程的很嚴謹、很工整的架構（待續）。
註
Service-Oriented 與 Object-Oriented：
看到Service-Oriented，IT產業較熟悉的人應該就會直接覺得想到OO（Object-Oriented，物件導向）。確實，從觀念上來說，這兩個概念是雷同的，只不過它們所關切並要解決的問題是屬於不同層面的：SOA是從商業邏輯成層面來看，以減少系統中服務元件設計與開發的時間；而 OO則是關注程式設計與開發的層面，以減少程式元件重新開發的時間。
昨天談到SOA之所以不同，是因為它結合服務元件及流程，而形成嚴謹而具有美感架構的IT概念。但它是不是僅只是於「比較美」而已呢？它對企業運作，是不是真的發揮效益呢？讓我們再隨著昨天的例子繼續走下去。
「變」才是自動化IT最大挑戰
伴隨著澳圖美德跟Sun 原廠生意往來的增加，他們的合作關係越來越密切，也越來越有信任感，因此在兩邊老闆與業務同仁熱切期望與鼓吹下，在短短一個禮拜會議討論後，老闆們握手作出以下決議：「面對市場的快速反應，某些單期的商品，只要是澳圖美德業務人員確認後的訂單，Sun原廠這邊就可以直接出貨，澳圖美德的同仁只要事後在一個月內補上訂單及貨款即可，以縮短整體的交期。」
這樣的消息對兩個公司的業務同仁而言都是一個普天同慶的大好消息，特別在信任感足夠的前提下，交期縮短的做法會讓客戶滿意度增加，並相對地提升業績，特別對澳圖美德而言，這樣的做法會縮短貨品在途與減少庫存，可大大提升兩個公司在整體銷售上的執行力。
但獲得執行力是要付出代價的。
老闆又繼續說了下去：「為符合這樣的需求，請IT人員於半個月內修改系統…」一語未閉，資訊部門的同仁全都當場傻眼（並考慮要不要遞出辭呈）：天啊，當初為了達到整體的商業自動化，花了澳圖美德公司與Sun原廠的資訊同仁們三個月時間的系統分析以及六個月的程式撰寫，最後逐一的測試，直到上個月才剛算完全測試完成的系統，半個月要怎麼改啊？瘋了嗎？
IT主管們（特別是資訊長與技術長）所面臨的最大挑戰並不是一個固定的商業行為，其實大部份跨企業/組織的商業流程自動化需求都可以利用傳統EAI所使用的IT技術手法來完成；講白了，IT人員只要把商業的作業流程定義清楚，不管採用什麼技術（VB、JAVA、N-tier、 mainframe、有資料庫就用資料庫，沒有資料庫就用最笨的方式，像是TEXT file等），大部份商業上的需求都還是可以硬生生--不論用苦力技術或高級的方式（例如物件導向加XML）來實作出來，但最大的挑戰往往發生在商業流程改變的時候。
「規劃永遠趕不上商業變化。」這是所有IT人的痛，因此當我們談到商業自動化，「流程」只是故事的一半而已。也是SOA的切入點所在。
在瞬息萬變的經營環境中，SOA目的在更深一層去關切並預想商業流程的變異性，並思考、定義與切割一個個服務與流程，以強化企業商業自動化的靈活度。
是行銷名詞還是真的有用？
談到這邊，我想「為什麼要SOA？」或「SOA是不是一個行銷術語？」應該會得到較清楚的答案。在商業自動化為前提下，「服務元件」與「流程」可視為商業自動化的基本元素。面對商業行為的變異性，在「服務元件」與「流程」的設計與實作上，應該要達到彈性並且可以重複被使用的水準，以減少系統重複開發的時間，這樣子以商業服務為基本元素來做為的出發點，而設計出來的IT架構，我們就稱之為「服務導向架構」(SOA)。
而在這樣一個約定而成、公開規範的SOA架構下，企業便可藉由「服務元件」與「流程」靈活組合（就像玩樂高積木一般），因應瞬息萬變的商業行為需求。理解SOA的本質後，我們再來看SOA中各個資訊原廠或SI廠商所提出的各種五花八門資訊名詞時，應該就會比較清楚個中差異。例如：BPEL（Business Process Execution Language，商業流程執行語言），簡單說就是特定資訊語言可以用定義及規範各個服務元件的執行的先後順序與因果關係（也就是流程）。再如 ESB（Enterprise Service Bus，企業服務匯流排）則是服務被實踐的地方，ESB在系統與系統間、企業與企業間，負責整合的作業，讓「服務」的串連形成一個匯流排（Bus），如同巴士（Bus）一般地，傳遞跨系統、組織與企業的資訊服務。
面對企業資訊「整合」的需求，SOA並不是唯一的答案，但無疑地，隨著SOA技術逐漸發展成熟，新的概念與技術可以讓企業面對商業整合時可擁有更大的彈性與效率。而接下來的專欄文章中，我們將陸續探討SOA對企業內人事、流程、甚至CEO角色職權的衝擊。
10月 05, 2010
懸置指標(dangling pointer) 與 懸置物件(dangling object)
[Dangling Pointer]
[Dangling object]
空間 free 掉，我還在用[Dangling Reference]
函式呼叫結束，空間還回去了
解法 tombstone , locks-and-keys
[Dangling object]
heap dynamic variable 才會發生
可用 garbage collection 去解(投影片)
(1)參考計數法(reference-counting)
配置記憶體時，為所配置的記憶體額外提供一個計數器，用來紀錄
參考到此記憶體的指標變數，每增加一個指標參考此位址時，則計
數器加一，當指標變數不再指向此位址時，則計數器減一。
當計數器為零時，系統會收回此記憶體。
實做簡單，需要參考計數欄位
(2)標記追蹤法(mark tracing)
目前最廣被採用的演算法
在記憶體不足時執行，會掃描整個記憶體兩次，
第一次掃描時會判斷記憶體中的每一個物件是否仍在使用
如果仍在使用則做一個標記，否則就不做標記
第二次掃描清除沒有做標記的物件
C 語言指標：Reference & Dereference 運算
& reference operator
* dereference operator
* dereference operator
foo()
{
int x, *ptr;
/* store the address of x into the ptr */
ptr = &x;
/* dereference here */
*ptr=18;
}
訂閱：
意見 (Atom)