2007-09-07

服務導向新概念-Web Oriented Architecture



http://www.ithome.com.tw/itadm/article.php?c=41508

服務導向新概念-Web Oriented Architecture
文/ 黃天賜 (記者) 2007-01-16

各家大廠鼓吹服務導向架構(SOA)已久,但仍似遙不可及,然而WOA概念的出現,卻讓服務導向有了立即可行的作法。


隨著Web 2.0襲捲而起的新浪潮,將軟體變成網站服務的風潮方興未艾。利用Web作為軟體運作平臺與服務,是Web 2.0時代一個鮮明的特色,因此也產生了WOA(Web Oriented Architecture,Web導向架構)這個新詞,用來描述這種現象。

WOA是SOA的子集合
2005年年底,IT研究機構Gartner發布了一個縮寫字WOA,定義它屬於SOA(Service Oriented Architecture,服務導向架構)的一個子集,並可以簡單的用「WOA = SOA + WWW + REST」這樣的算式來說明。

提出這個詞的Nick Gall認為,之所以必須新鑄詞彙,從SOA中切割出一塊新領域,在於SOA導入方法很多,而WOA代表一種完全倚賴Web的形式。

在Gartner的部落格上,副總裁Whit Andrew解釋使用WOA一詞,事實上也意味著企業在系統上的需求,不總是事事要做到十足的穩固、可靠與嚴密,有時快速、輕簡如WOA,即足以符合企業特定的需求。
WOA專指透過WWW(Word Wide Web)這個媒介和REST(Representational State Transfer,表徵狀態移轉)架構作為SOA的執行方式,REST簡單而言,是一種寬鬆、簡單協定,藉由HTTP管道傳送資料,而無須額外的訊息層, 像是SOA使用的SOAP協定。

WOA是SOA的一個子集合,經常採用REST、JSON(JavaScript Object Notation)和POX(Plain Old XML)等較簡易方式,混搭應用程式與資料,在開發或使用上,都有快速便捷的特性。

WOA更容易實現服務導架構
SOA高舉服務導向旗幟,將應用程式及資源以可重複使用的服務方式呈現,藉此提供更高彈性和效率的資訊整合環境。不過SOA原本就是為大型企業量身訂作的龐大架構,將複雜的系統整合視為首要任務,因此必須構思宏大,實作嚴謹。

導入SOA因此變得茲事體大,企業不是望之卻步,便是心存觀望,希望有較多的成功典範出現之後,再考慮跟進。然而同樣以服務導向為概念,WOA卻能更快速的實現服務導向為核心、分散式、分享式的架構。

看看幾個WOA的典型案例,Salesforce在網站上提供的客戶關係管理,並有開放式API可以整合其他應用程式,或像Google Map提供API讓使用者可以自行在上面開發應用。此外如Amazon也提供許多API可以使用網站中的資料。甚至像是部落格中使用的RSS通知或引用功 能,都是一種以網站為開發規模、透過HTTP的特性交換資料或提供服務的WOA實踐。

REST源於設計模式概念
SOA和WOA在概念上一個鮮明的差異在於WOA擁抱REST。從Gartner扼要的定義「WOA = SOA + WWW + REST」中不難發現,WWW和REST均是WOA的核心元素。

WWW從1991年公開以來已經成為我們熟知的一部分,而REST則是相較陌生的詞彙。REST是2000年Roy Fielding(制定HTTP協定規格的主要成員之一)在他的博士論文中提出的一種設計模式,用來描述良好的Web應用程式應該如何運作。簡單而言,使 用者可以利用包含有超連結的網頁來操作應用程式,而應用程式狀態(state)的改變結果,會以另一個頁面呈現。

就Roy Fielding的定義來說,用戶端使用URL指定一個Web資源,而一個資源的表徵(Representation)被送回給用戶端(例如一個網頁), 這個表徵讓用戶端保持在新的狀態,當用戶端選擇包含在網頁中的一個超連結時,它就等於存取了另一個新的資源,而這個新資源傳送給使用者後,則讓使用者又處 在新的狀態中。因此用戶端應用程式得以透過每個資源的表徵,以傳送新的狀態。

REST的運作方式看起來就像目前WWW的運作方式,然而仔細檢視,目前許多Web應用程式是用一連串參數的方式來表達網頁的資源,而且為了提供豐富的個人化功能,也讓伺服器端保留使用狀態,這些作法都違反REST的設計方式。

隨著Web 2.0的盛行,REST的設計方法再度被重視,像是最近推出1.2版的Ruby on Rails的重點之一便是更全面地支援REST。此外,Ajax技術崛起,也解決一部分個人化的問題,透過非同步的傳輸技術,提供更豐富的使用者介面,而 且許多工作可以在用戶端處理,無須伺服器以保留狀態的方式介入。

在訂位系統中,上圖非REST架構的會員不分等級,都必須進入同一個介面,讀取會員身分,判斷等級之後,才分派不同的資源。而以REST做法而言,應像下圖提供每種會員一個管道去存取對應的資源,因為每一種資源都應該要有唯一的URL做為識別之用。

REST介面簡單,易於混搭
REST除了是一種設計模式,更多的時候,Web 2.0的開發人員是將REST視為一種進行混搭服務時的輕巧介面,並經常被用來和SOAP作為比較。

REST雖然不一定採用HTTP作為溝通的語彙,即使用SOAP、RPC等方式,也能實作出符合Roy Fielding定義的模式,然而被視為SOA原生協定的SOAP由於過於複雜,對於WOA力走輕裝便捷的概念並不相符,因此HTTP的方式就成了今日 REST在建立Web服務的不二選擇。

HTTP提供簡單的運作方式,也可以說,HTTP提供一組API,透過GET、PUT、POST、DELETE等語彙,來建立檢視、新增、修改、刪除等動作,善用這些語法,Web的服務就能相互溝通。

因此透過REST風格的設計,使用者只需知道HTTP這個具有普及性、延展性的通訊協定,以及利用XML、JSON等儲存資料和狀態即可使用。而 SOAP在使用上便相對複雜,如果沒有依照相同的Web服務的標準與堆疊,就無法進行溝通,讓雙向互動難以進行。這也是簡單、直觀的REST之所以能勝出 的原因。

WOA並非萬靈丹,卻是快速實現SOA的方法
WOA讓網站成為服務平臺、透過平臺間混搭程式與資料,可以成為一個相當規模的供應鏈體系,這是過去以網站為獨立單位所無法想像的事,而WOA讓SOA大夢得以落實與普及。

然而企業在思考SOA與WOA時,必須要正視的一個事實,那便是WOA並非萬靈丹。一旦系統架構要求穩固,或者系統複雜時,WOA就顯得無以為繼,這時就只有SOA提供的技術與架構,可以提供妥善的解決方案。

不過如果SOAP的複雜協定,無益於企業的應用系統,那麼企業大可拋掉,透過簡易的REST架構,擁抱開發快速、互動容易的WOA。文☉黃天賜


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

「數位典藏」該往何處去?



http://www.ithome.com.tw/itadm/article.php?c=42718

「數位典藏」該往何處去?
文/ iThome (記者) 2007-04-03

支持本地內容社群發展、翻譯、改編和數位化檔案,增強在地與原住民社群的力量,都是當代資訊社會裡的數位決策者應該特別留心的文化傳承議題。


劉靜怡╱台灣大學國家發展研究所法律組專任副教授
美國芝加哥大學法學博士、哈佛大學法學碩士

兩年多前在突尼西亞首府突尼斯召開的「第二階段聯合國世界資訊高峰會(World Summit on Information Society, Phase II)」,清楚揭示了全球運用資訊通訊技術推動資訊社會發展理念,以及如何落實的行動綱領。其中針對「文化多樣性、認同與語言多樣性和本地內容」,與會的 各國政府、企業、公民社會代表所提出的共同宣言,特別強調文化與語言的多樣性,和對於文化認同、傳統與宗教的尊重。

對於一個相當著重在文化與文化間、區域與國際競合情勢中發展對話關係的資訊社會而言,上述宣言是永續發展的重要基礎,而為了落實上述共同目標,世界資訊高峰會也通過了一連串的行動準則。這些行動準則的內容有不少值得我們據以反思之處。

例如,以國內的數位化風潮為例:「數位化」一直是政府長期規畫與執行的重要政策之一,而「數位典藏」及其相關的「數位學習」,過去五年來也都列為 國家型科技計畫。觀察這些國家重大數位化建設的內容,再對照上述世界資訊社會高峰會的共識,或許,我們應該以下面的一系列問題為主軸,共同思考未來的發展 方向:

決策者應該制訂怎樣的政策,達成尊重、保存、推廣與增進文化與語言的多樣性與文化傳承的目標?國家的政策與法律應該如何做完整詳細的擘畫,才能確保圖書館、典藏機構、博物館與其他應該參與數位化的文化機構,可以充分扮演資訊社會中的內容提供者的角色?

支持一般人民發展與使用資訊傳播工具來保存自然與文化資產,才能夠使人人都成為文化生活裡的一部分。所以,如何發展出確保人人都能夠持續地取用數 位倉儲(Digital Repositories)裡的數位化典藏資訊與多媒體內容的系統,進而使每個人所蒐集或創造的文化蒐藏,成為人類集體記憶的一環,或許正是各國政府不容 怠忽的責任。與此相關者,還包括如何激發、創造出各式各樣的資訊內容,以及如何使用各種方法,包括如何透過數位化教育、科學與文化等層面的資產,來發展出 保存與推廣文化表現多樣性和本地知識傳統的問題,都應該一併思考。換言之,支持本地內容社群發展、翻譯、改編和數位化檔案,增強在地與原住民社群的力量, 都是當代資訊社會裡的數位決策者應該特別留心的文化傳承議題。

在手段的選擇方面,是不是應該找出最有效的手法,讓資訊社會裡的個人,人人都能夠朝向成為內容的創造與永續發展者的方向去發展。在資源動員和配置方面,或許應該嘗試藉由建立公部門和民間部門之間更有效的夥伴關係,來加速內容的創造、傳播與再創造。
在培養在地能力方面,則更應該注意如何培養在地社群創造與散布軟體和內容的能力,並支持在地社區媒體將傳統媒體和新科技進行結合,讓在地社群在文化推廣與語言多樣性政策的經驗和知識上,能充分擴散。

以上這些思考,只是展現全球各國目前對於應用資訊通訊科技來改善資訊社會面貌和保存地方文化方面的幾點共識而已,其他可供挖掘和討論者不勝枚舉。 回顧過去並盱衡當前全球的數位趨勢內容,國家數位化政策應該往何處去,方能展現數位典藏的歷史意義,並讓推廣數位學習等相關措施成為資訊社會裡造福每個人 的政策,恐怕都和以上這些思考脫離不了關係了。


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

組態管理資料庫實現ITIL最佳實務



http://www.ithome.com.tw/itadm/article.php?c=37662
組態管理資料庫實現ITIL最佳實務

組態管理資料庫實現ITIL最佳實務
文/ 張瑞隆 (記者) 2006-06-14

ITIL讓資訊系統能提供各種商業流程所需的服務,凸顯資訊部門的價值,CMDB在ITIL扮演著組成實體網路基礎架構上各元件的可靠資料來源,是實現ITIL的核心。


資訊業界提出資訊基礎架構資料庫(IT Infrastructure Library,簡稱為ITIL),主要希望藉著整合人員(People)、技術(Technology)與流程(Process),提高資訊服務效率而 為企業節省成本與增加商業利潤。然而,直到去年為止,國內企業對ITIL的認知仍停留在理論的階段,直到今年BMC、CA、HP與IBM等ITIL解決方 案供應商,將組態管理資料庫(Configuration Management Database,簡稱為CMDB)由各自的Service Desk產品中獨立成為中央儲存庫(Repository),並結合自家的管理工具後,讓企業了解如何藉由技術與工具,結合人員與流程,實現ITIL的最 佳實務。

ITIL建議企業為顧客提供高品質的資訊服務、提出服務流程的宏觀管理
以往資訊服務與顧客獲利看似無直接關聯性,但目前企業與顧客之間,越來越仰賴電子商務服務而為企業帶來利潤,使得資訊服務與顧客獲利緊密地關聯。 ITIL提供指導準則,指引企業如何將資訊系統由被動的例行維護事務,轉變成主動提供高品質的服務。然而,就服務層面來看,資訊部門勢必對資訊系統整體運 作狀態掌握地一清二楚,才能在使用者抱怨前就調整系統最佳的運作狀態。組態管理資料庫能記錄資訊系統整體運作狀態資料,因而成為ITIL的核心,以及實現 ITIL的重要技術。

CMDB是實現ITIL的核心、落實ITIL整合人員、流程與技術的目的
CMDB起源於ITIL,這是由英國商務辦公室所寫的一套資訊架構管理標準。ITIL的目的是讓資訊系統能因應商業需求的各種流程提供所需的服務,除了降低營運成本與確保企業在資訊系統上的投資能產生更大的生產力,更要凸顯出資訊部門的價值。

ITIL解決方案供應商各自提出CMDB
目前ITIL解決方案供應商包括BMC、CA、HP與IBM,它們成為領導廠商的原因是各自具備完整的資訊管理工具,例如Remedy (BMC)、Unicenter(CA)、OpenView(HP)、Tivoli(IBM)。這些產品對應ITIL的理論時,先期透過各自獨立的組態資 料庫,記錄各系統的運作狀態,直到今年才將組態管理資料庫獨立成為中央儲存庫,並成為ITIL的核心。

ITIL建議企業為顧客提供高品質的資訊服務

在資訊架構中,企業發現資訊系統建置的目的是為了提供商業流程所需要的各種服務,而不是業務受資訊系統所支配。換個方向來說,資訊系統應該是為各式各樣的 使用者提供服務,無論這些使用者是企業外部的顧客或內部的作業人員,可是許多時候是本末倒置,使用者受限於資訊系統缺乏彈性,修改業務流程或作業習慣以配 合著系統的要求。

企業建置資訊系統,主要目的是為使用者提供服務,而讓顧客在享用高品質的服務後,為企業帶來利潤,而不是在使用者來電告知系統服務異常,才調整資 訊系統的被動處理,這是例行事務,而不是提供服務。舉例來說,對Amazon而言,時間就是金錢,如果顧客必須等待網頁查詢的冗長時間,則下訂單採購書籍 的數量便會隨著系統服務時間越來越長而下降。

以往資訊服務與顧客獲利看似無直接關聯性,但目前企業與顧客之間,越來越仰賴電子商務服務而為企業帶來利潤,使得資訊服務與顧客獲利緊密地關聯。 ITIL提供指導準則,指引企業如何將資訊系統由被動的例行維護事務,轉變成主動提供高品質的服務。然而,就服務層面來看,資訊部門勢必對資訊系統整體運 作狀態掌握地一清二楚,才能在使用者抱怨前就調整系統最佳的運作狀態。組態管理資料庫能記錄資訊系統整體運作狀態資料,因而成為ITIL的核心,以及實現 ITIL的重要技術。

ITIL提出服務流程的宏觀管理
企業在日常營運時,不免會遇到使用者抱怨資訊系統服務的問題。舉例來說,企業資訊入口網站的網頁反應過慢,到底是網頁伺服器還是應用伺服器等單一 系統的效能不足,還是使用者本身操作不當所引起的,或者以上都是?此外,企業面對這類問題時,應該由客戶服務人員還是資訊系統管理人員負責向使用者解說, 並答覆最終的處理結果?

這是資訊系統提供服務時,面對使用者提問的兩難問題。由於資訊系統的複雜,客戶服務人員通常因為不了解資訊部門處理的進度與技術細節,難以向使用 者清楚解說處理的過程與結果,只能回覆官方式的答案。接下來,客戶服務人員會將問題記錄在申訴單上,轉由資訊部門處理,以至於資訊人員僅能依靠有限的文字 敘述,然後記錄資訊系統調整結果,交由客戶服務人員向使用者答覆。這種一來一往且冗長的問題處理程序,總是趕不上使用者回報問題的速率。

此外,使用者更進一步抱怨為何總是官方式的回答,或是答非所問。使用者總是不斷地以電話或電子郵件抱怨,造成客戶服務部門應接不暇,而資訊人員也 一直調整系統。好比環繞著操場的接力賽,每個人都很努力地交棒,但交接的只是單純的工作,而缺少細節的資訊,造成周而復始地重覆同樣的工作,直到筋疲力 盡,卻毫無效率。

在這個例子中,呈現典型的資訊服務流程問題,部門處理人員與資訊技術各自獨立,所以每個部門都解決了客戶申訴中資訊系統服務上單點的問題,卻沒有 從整體服務層面的角度,也就是與企業入口網站相關的所有伺服器互動,分析企業網頁反應過慢的瓶頸。ITIL建議企業由資訊系統應用生命週期管理的宏觀角度 看待資訊服務的問題,從問題發生的起源、過程,直到解決等所有歷程,都納入追蹤與控管的範疇。

由資訊基礎架構上來看使用者所面對的服務問題,由資訊系統所造成的意外事件觸發、轉變為服務中斷的問題、調校系統所需的設定變更、組成服務所有元 件的組態,到最後上線時所提供的服務,資訊系統應用的整個生命周期都牽涉到各系統相關聯的組態設定,因此ITIL管理準則中明訂「組態管理 (Configuration Management)」流程,並以單一組態管理資料庫詳盡記錄資訊架構中所有元件與流程的更動紀錄,使ITIL成為貫穿資訊系統應用生命週期管理的實作 標準。

ITIL為資訊系統提供服務時,建立問題處理流程的指導方針,並落實為企業日常營運的標準程序,讓企業能依據ITIL指導準則逐步調整資訊系統, 最終能提供高品質的服務。基本上,ITIL僅提供規範流程的大綱,簡單地說,這是一種抽象的理論,並未要求處理的細節。ITIL解決方案供應商實作「組態 管理資料庫」後,才實現ITIL所要求「人員」、「技術」、「流程」整合成資訊服務的緊密核心。

CMDB是實現ITIL的核心
CMDB起源於ITIL,這是由英國商務辦公室所寫的一套資訊架構管理標準。ITIL的目的是讓資訊系統能因應商業需求的各種流程提供所需的服務,除了降低營運成本與確保企業在資訊系統上的投資能產生更大的生產力,更要凸顯出資訊部門的價值。

此外,藉由ITIL管理標準,資訊部門也可以在為企業營運上負起責任,不再只是支援角色,並在業務中提供可預測問題的管道。ITIL中定義CMDB應具備 擷取跨越網路基礎架構系統元件中事件處理與變更記錄,所以管理員可在出現突發事件後,讓系統即時主動依設定政策通知相關人員,達到自動化管理作業。

CMDB在ITIL扮演著組成實體網路基礎架構上各元件的可靠資料來源,這些資料包括問題記錄、變動記錄、版本資訊、狀態資訊、關係資訊等,稱為 組態項目。CMDB除了保持組態項目為最新的資料外,也負責呈現各項目間的關聯性與輸出報表。資訊管理員從CMDB所提供的資訊確保系統正常運作與準確地 處理所有日常任務。它也有助於資訊人員了解有效的管理如何影響架構與商業服務。雖然一般資訊系統管理員有各式各樣的控管工具,例如網路監視工具、資產管理 工具、變動管理工具等,可用來收集各種資料,但無法為管理人員提供網路上各系統互動與關聯性的全盤概況。

CMDB由維運的角度審視資訊管理
ITIL所制定的管理標準分為10個流程與1個服務功能,或者可以區分為資訊服務支援(Service Support)與資訊服務交付(Service Delivery)等兩大核心。兩者的區別在於服務支援可應用在企業日常的營運流程,並強調量化指標、追蹤和記錄、持續調整、報告產出等,CMDB則是這 些資料的集中儲存處。

如果資訊管理只著重在基礎資訊元件,則資訊人員只在乎主機、網路、資料庫、網頁伺服器等各獨立元件的穩定與效能,而不關心使用者層面,造成資訊人 員為了處理層出不窮的應用問題疲於奔命;相對地,如果改以資訊維運(IT Operations)的角度來看,就不會只是應付軟體與硬體等獨立元件,而是企業入口網站(EIP)、企業資源規畫(ERP)、客戶關係管理(CRM) 等整體服務系統面,管理員可以規劃、預期問題、主動解決問題,無論在提昇管理效率、降低管理成本都可展現資訊人員的價值。

雖然在實作的技術面,資訊系統管理員可以收集各別系統的記錄檔(Log),再以人工分析,同樣可以滿足ITIL的要求,但CMDB可以提供自動化 的機制,也降低人工作業的疏忽與錯誤,而且CMDB扮演資訊的中央儲存庫。換句話說,客戶服務部門也可以從CMDB中取得資訊系統運作現況的報告,向客戶 回答系統反應過慢的問題,而不是每次都給予官方式的答案。

CMDB轉化資訊為服務
組態管理資料庫並不是全新的技術,本身是一種中央儲存庫(Repository),但與傳統資料庫的用途不同,用來記錄溝通用的中介資料 (metadata)。在ITIL所制定的組態管理中,CMDB記錄資產管理、網路與系統管理,以及變動管理工具所收集的資料,匯整後為企業基礎架構上的 伺服器、交換器、桌上型電腦等元件或系統,提供可靠的組態資料來源,包括網路位址、磁碟空間、作業系統版本、更新套件現況、軟體序號與授權時效等配置資 訊,這一來就讓儲存庫成為資訊服務中心,不單只是資訊系統而已。

在企業架構中建立CMDB後,資訊系統管理員可以從中知道基礎架構中各元件或系統間的交互作用關係,以及當更動某一個元件時,事先預測對其他流程 與服務的影響。簡單地說,CMDB可以為管理員提供資訊系統運作現況的全貌,使資訊人員能對各種突發狀況有更快速的回應能力,以及對新加入的商業流程做好 更動的準備,而不是每次都重新設計系統。

Stephan Hackel與Richard Nolan在哈佛商業評論中所提的「連線管理(Managing by Wire)」,將企業資訊系統比喻為航空界中的「線傳飛控(Flying by Wire)」系統,也就是噴射引擎飛機利用電腦系統輔助飛行員收集與匯整周遭環境快速變化的各種資訊,取代以往飛行員使用感官的方式。當駕駛員突然遇到大 風暴等突發狀況時,即使操控著747這種龐然大物,也必須在很短的時間內了解周遭的全盤概況,並快速地反應,而不是逐一檢視儀表板。CMDB正可比喻成資 訊人員的連線管理系統,隨時提供系統運作的全貌。

CMDB落實ITIL整合人員、流程與技術的目的
ITIL是一套獨立的資訊管理標準,指導企業建立資訊服務願景,並藉由資訊人員使用主動式的工具,分析與評估資訊系統運作的即時狀態,反覆調整流程,達成為顧客提供高品質服務的目的。

資訊科技威力雖然強大,但企業應用資訊科技並非一帆風順,許多企業投下鉅資建立系統,卻造成資訊氾濫而且成效不彰。一般資訊人員會以工具或技術角 度處理許多管理的瓶頸,卻常無法解決使用者所提出的各種使用上的問題,這不代表企業資訊入口(EIP)或企業應用系統整合(EAI)等技術無法發揮預期的 效益。通常管理問題起因於紊亂的流程,而不是技術或工具本身造成的,例如任意更改系統設定,導致系統發生錯誤而中斷服務,引起使用者抱怨;或因為資訊支援 權責畫分不清,當使用者反應問題時,前端的客戶服務人員和後端的資訊人員,在溝通不良與資訊不通透的情況下,造成反應時間過長而降低服務品質。總結而言, 這些都是人員、流程、技術等各自獨立的結果。此外,客戶服務知識無法累積,造成問題一再重覆發生,讓資訊部門成為名副其實的花錢單位,也失去眾多商機。

企業建置大型資訊系統,不外乎是用來提供日常商業營運所需的服務。建立CMDB後,企業不僅可以服務外部的一般使用者,也包括企業內部資訊部門以 外的員工,也就是將員工也當成是顧客一般。這樣的轉變,有助於資訊人員展現資訊科技的商業價值,定義長久以來模糊不清的績效問題。只是,資訊人員必須隨時 了解目前有多少系統資源可以為使用者服務,當用戶提出使用上的問題時,能在多少時間內答覆與找出問題的癥結。

ITIL解決方案供應商各自提出CMDB 目前ITIL解決方案供應商包括BMC、CA、HP與IBM,它們成為領導廠商的原因是各自具備完整的資訊管理工具,例如Remedy(BMC)、 Unicenter(CA)、OpenView(HP)、Tivoli(IBM)。這些產品對應ITIL的理論時,先期透過各自獨立的組態資料庫,記錄各 系統的運作狀態,直到今年才將組態管理資料庫獨立成為中央儲存庫,並成為ITIL的核心。以CA Unicenter與HP OpenView為例,都是由原本內建在Service Desk的組態管理資料庫獨立後,才符合ITIL的要求。

至於由Service Desk原本的內建的CMDB獨立出來,ITIL白皮書中提到,Service Desk由於可作為資訊部門與服務流程的「支援前臺」,使得企業在解決資訊服務問題時,不需要聯繫特定的資訊人員的情況下,處理大量的使用者需求。此外, Service Desk又稱為Help Desk,只是意義與功能更廣泛,除了記錄、解決與監控服務運作過程所產生的問題,並提供集中和專職的服務中心,整合資訊服務管理基礎架構與組織業務流 程。

不過,在Gartner的一份標題為「CMDB or Configuration Database:Know the Difference」報告中指出,ITIL所要求的CMDB其實應具備4種特性,才能稱為CMDB。這4種特性分別是:「一致 (Reconciliation)」、「聯邦(Federation)」、「對應與可見(Mapping and Visualization)」、「同步(Synchronization)」。Gartner提醒有意導入ITIL的企業,在選擇CMDB產品時,避免 工具供應商以ITIL的外表包裝產品,而忽略了CMDB的重要特性,所以才提出4種主要功能特性,作為企業選購的判斷依據。文☉張瑞隆

--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

客戶關係管理-Microsoft Dynamics CRM 3.0



http://www.ithome.com.tw/itadm/article.php?c=37665
客戶關係管理-Microsoft Dynamics CRM 3.0

客戶關係管理-Microsoft Dynamics CRM 3.0
文/ 張瑞隆 (記者) 2006-06-15

Dynamics CRM 3.0除了結合Office和SQL Server,微軟也在.NET的基礎上,整合Dynamics系列的各個產品,橫跨企業財務管理、客戶關係管理、供應鍊管理等解決方案。


Microsoft Dynamics CRM 3.0為Dynamics產品的成員,包括適用於中大型企業的專業版與小型企業伺服器版(Small Business Server,SBS),並以角色基礎(Role-Based)的設計理念,其產品的操作介面與Outlook或Office產品相似,而且使用者可選擇 Outlook、瀏覽器或行動裝置作為CRM的用戶端工具。系統核心則採用事件導向(Event-Driven)工作流程,搭配Excel或SQL Server Reporting Service的報表與分析功能,將Dynamics CRM由操作型提升為分析型客戶關係管理系統。

銷售、行銷、客戶服務緊密關聯
在銷售模組功能中商機管理可以將潛在客戶與機率等銷售情報換算為商機,並且追蹤整個銷售周期;報價是透過產品分類型錄所產生,可支援複合價位與折 扣等;主管則可以在業務人員管理中依配額評量各別的銷售績效;直接電子郵件可使用範本傳送自訂的電子郵件給具有共同特性的客戶。當然,銷售時也必須考量競 爭對手,所以系統也內建對應的次模組,而且還能記錄競爭產品資料。

行銷模組可根據預算與開支、促銷代碼、目標產品、行銷附屬資料等規畫行銷活動,並與客戶資訊取得關聯,或查詢與尋找符合特定準則的客戶;後續能追 蹤行銷活動的成本與績效,並比較成本與效益,評鑑活動是否成功。客戶服務模組主要在客戶個案管理,用於集中建立、分派及管理客戶服務要求、合約與產品等; 一般常用的電子郵件自動回應可對客戶的要求,自動產生回應。此模組也提供知識庫,作為企業記錄客戶服務所有歷史資訊的儲存庫,文章能區分為草稿、未核準與 已公布等3種等級。

CRM結合財務管理、供應鍊成為解決方案
2005年9月,微軟將原本各自獨立的Great Plains、Navision、Axapta、Solomon等4種商業應用軟體以及CRM產品,統一成為單一應用軟體平臺,並命名為 「Dynamics」。原先的套裝軟體也因此更名為Dynamics GP(Great Plains)、Dynamics SL(Solomon)和Dynamics CRM等。Dynamics CRM 3.0除了結合Office和SQL Server,微軟也在.NET的基礎上,整合Dynamics系列的各個產品,橫跨企業財務管理、客戶關係管理、供應鍊管理等解決方案,試圖在同級產品 上另闢優勢。微軟預計在今年底提供產品的中文版,至於企業在導入時所需的顧問服務,可以透過通用數碼等合作夥伴。文☉張瑞隆

Microsoft Dynamics CRM 3.0

建議售價:22790元 /年(小型企業伺服器版)、75690元 /年(專業版)

臺灣微軟

(02)2999-8833

www.microsoft.com/taiwan

處理器需求 Pentium 700MHz以上
記憶體需求 512MB以上
硬碟空間需求 SCSI與RAID 5
作業系統需求 Windows 2000 Server或Advanced Server/2003 Standard、Enterprise或Web版
支援的資料庫 SQL Server 2000/2005
其他需求 .NET Framework 1.1


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

客戶關係管理-SugarCRM 4.2



http://www.ithome.com.tw/itadm/article.php?c=37666
客戶關係管理-SugarCRM 4.2

客戶關係管理-SugarCRM 4.2
文/ 張瑞隆 (記者) 2006-06-15

內建數位儀表版(Dashboard)為企業提供各種即時的商業資訊,而且可依企業需求客製化所需的產品或服務情報。


SugarCRM是由PHP語言所開發的客戶關係管理系統,為企業提供所需的市場、行銷與服務等功能與資訊,不但適用在Linux或Windows等平臺,也支援MySQL或Oracle等資料庫。

SugarCRM提供離線作業功能
SugarCRM特色除了具備客戶關係管理所需要的主要功能,例如記錄顧客連絡資訊與銷售喜好等;在市場資訊中,為行銷人員提供銷售機會預測,將產品總數 與機率相乘後,得到銷售權重,行銷人員也能提供銷售建議,作為附加資訊。系統也內建報表功能,將客戶所需的產品報價詳盡資訊,直接轉為PDF或Word檔 案並傳送給客戶,甚至可透過產品所提供的行動模組,在個人數位助理(PDA)上即時更新合約、銷售會議通知或新增客戶帳號等。

此外,系統也提供離線作業功能,使用者如果在網路頻寬低或甚至飛機上時,依然能在頻寬不足時瀏覽客戶資料。用戶端除了提供Word外掛工具外,還包括Outlook外掛工具,使用者可以將Outlook的電子郵件與約會等匯入SugarCRM中。

行銷部門可透過此產品統一管理所有銷售管道活動,無論是電話、電子郵件、一般郵件等,還包括負責的部門與銷售員,以及時間與目前狀態。不僅於此, 系統也會針對所有銷售活動作狀態統計,並比對現在接觸與目標值,以及兩者的差距,以長條圖方式顯示。只要與銷售相關活動,都搭配特定的報告,這些報告可以 供特定的組織參考,或開放讓整個企業瀏覽。

企業可採取隨選或一年合約的付費方式
SugarCRM共區分為3種版本:開放源碼版(Open Source)、專業版(Professional)與企業版(Enterprise),不同版本的差別在功能模組與授權費用。開放源碼版不需要授權費, 專業版比開放源碼版多了7個功能模組,計費方式分為每位使用者每個月39.95美金(隨選,On-Demand)或每位使用者每年239美金(一年合 約)。企業版比開放源碼版增加12個功能模組,以及額外的技術支援、主動升級、存取開發者論壇的知識庫等, 隨選與合約的費用分別是74.95美金與449 美金。文☉張瑞隆

SugarCRM 4.2

建議售價:449美金/年(企業版)、239美金/年(專業版)、開放源碼(免費)

SugarCRM

0800-4546940

www.sugarcrm.com

處理器需求 Pentium 4 1.4GHz(單一使用者)∼雙Xeon 3.0GHz(100 至250位使用者)
記憶體 256MB(單一使用者)/3GB(100至250位使用者)
作業系統需求 Linux、Windows 2000/XP、Unix、BSD、Mac OS X
支援的網頁伺服器 Apache、IIS或支援PHP語言的伺服器
支援的資料庫 MySQL 4.0.×、4.1.×(4.0.23為最佳搭配)
支援的PHP語言版本 PHP 4.2.×、4.3.×(4.3.10為最佳搭配)、5.×


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

軟體架構設計鮮思維-從合成結構到使用案例模型



http://www.ithome.com.tw/itadm/article.php?c=37307
軟體架構設計鮮思維-從合成結構到使用案例模型

軟體架構設計鮮思維-從合成結構到使用案例模型
文/ iThome (記者) 2006-05-23

以「寬頻路由分享器」這類的嵌入式系統為例,說明牽涉到軟體、硬體整合設計時,如何從合成結構圖到使用案例模型,以釐清功能需求。


作者:王克明
信仁軟體設計顧問中心軟體架構師、機械化師文書官、系統工程師、Oracle DBA、IT部門副理、講師、顧問


軟體架構設計中,設計師可使用UML的「合成結構圖(Composite Structure Diagram)」所呈現的架構視圖,表達產品整體觀;後續開發加值應用軟體時,可以將產品的硬體部分當成一個黑盒子(Black Box),藉以表達黑盒子的功能需求,這時候可以應用「使用案例圖(Use Case Diagram)」。兩者能達成非常好的互補,合成結構圖表達黑盒子(設計中的系統)位於硬體產品的哪一個部位,以及與硬體內的其他的組件的關係;再由此 可以很平順地利用使用案例圖來表達,找出使用該黑盒子的主要參與者(Primary Actor),以及外部的支援性參與者(Supporting Actor)。

由於系統範圍明確、與外部溝通的參與者也很清楚,所以要漸增與漸進的找出該黑盒子的系統功能,也就是使用案例(Use Case),那就不是難事了;找出使用案例,在先不考量系統內部結構設計的前提下寫出程式碼,外加確保程式碼正確性的功能測試碼,那根本是輕而易舉的事。

我們以「寬頻路由分享器」這類的嵌入式系統為例,說明牽涉到軟體、硬體整合設計時,如何從合成結構圖到使用案例模型,以釐清功能需求。至於案例圖 說中硬體元件只是用於示意的框架,不是強調組件關係的正確性,以免讓應用軟體的程式設計師誤解系統需求的範疇,或陷入分析癱瘓(paralysis)。

嵌入性系統與「純軟體應用系統」的設計差異?
那麼,嵌入性系統的軟體設計,是否有別於「純」軟體應用系統的設計?從多家硬體製造業內的軟體開發部門與 PDA、手機等應用程式開發廠商就近的觀察中,發現到一個比較顯明的問題,這類廠商中軟體開發人員的規模,甚至比一般中型「純」軟體開發廠商的人員還多, 但開發人員的角色卻連最基本的系統分析/系統設計都沒有區分。資深的開發人員或經理擔任需求分析,幾乎沒有所謂的結構分析或設計,就是依照需求後直接撰寫 程式碼,反而是需求的不明確。

嗯,好吧,如何釐清有效的需求?嵌入式系統的需求分析與設計,比起「純」軟體如ERP系統等簡單得很多,理由為何?因為系統範圍就是被「硬體」確 實「框住」,形成最有效的封裝效果,工程師可以將待開發的系統當成是一個黑盒子;而「純」軟體應用系統,系統分析人員要能有較高度抽象的能力,分析與界定 系統的範圍。要能在嵌入式系統做好有效的需求分析與設計,只有一個關鍵:「找出黑盒子(界定系統範圍),以及了解該黑盒子在硬體產品內的角色與定位」。

好像很簡單,不是嗎?但團隊成員往往就是對那一個黑盒子很模糊,沒有共識。只要問每一個成員,那個黑盒子的系統名稱為何,就可以了解他們為何難以定義系統 的需求範疇。問題在哪裡呢?因為沒有確實把整體圖像有效表達出來。在嵌入式系統中,我們可以把硬體產品視為是這個整體圖像,例如IP分享器、MP3播放 器、手機等,然後找出該硬體產品與外界溝通的「介面(Interface)」,例如,MP3播放器的介面包括了「Line-in」、「Line- out」、「Control UI」、「USB」等。再來,就是就是檢視這個硬體產品內塞了哪些重要的組件,而其中有一個組件就是嵌入式系統的黑盒子所在,我們要先能釐清這些組件之間 的關連、哪些組件負責與外部介面的溝通等。

有了這一張架構視圖才能讓我們釐清,所要加值軟體應用程式所在的那一個黑盒子,在整個硬體產品內所承擔的角色與責任為何,然後才有可能「聚焦」, 團隊才能有共識。有共識後才能對該黑盒子進行更進一步的需求分析,包括找出誰來使用系統、使用系統的目的、系統是否需要外部系統的服務等系統外部功能面的 觀點。

確立軟體廠商設計的核心
從寬頻路由分享器的例子,工程師須了解應用軟體的核心是位於哪一個「黑盒子」組件,以及該黑盒子是否有與其他的組件連結。若是站在設計代工製造 (ODM)軟體廠商的角度來看時,未來得以讓他們加以發揮的加值軟體應用程式是位於RCS(Router Control System)組件內,所以RCS成為整個寬頻分享器應用軟體的核心。

RCS確定應用程式的核心所在,當確立共識後,再來就是將焦點轉移至RCS,並且「放大」,分析檢視出RCS會提供哪些「系統功能」供外部的參與者來使用,這些「系統功能」,稱之為「使用案例」。

誰來使用系統,就會成為該系統的「主要參與者」。從圖中得知,網路管理員其實是外部寬頻分享器的主要參與者,但網管人員透過寬頻分享器的介面所連進來的系統就是由RCS負責,所以網管人員同時就會成為RCS的主要參與者。

RCS是否需要其他系統的服務支援?若是,其他系統就成為RCS的「支援性參與者」。從案例圖中可以看出,主要與RCS連結的組件有微處理器、快 閃記憶體(Falsh Memory)等,所以兩者都可以成為RCS的支援性參與者。其中,快閃記憶體的角色蠻有趣,它如同企業資訊系統的資料庫,或看成是RCS系統的私有倉儲 (private storage),而不會將之視為是外部的系統。圖中特別把它畫出來是反應合成結構圖中,快閃記憶體是明確獨立的硬體組件。

發掘潛在獲利的需求,實現在嵌入系統內
確認了整體(寬頻分享器)與核心焦點(RCS),團隊有了全貌、一致性的共識後,再來才是實作核心系統所提供的功能。甚至,團隊可以據此集思廣 益,來發掘出潛在的需求。例如,A 牌的寬頻分享器就發掘出分享器同時可以提供Web與FTP 的服務,更賦予了分享器多功能的面貌與價值。

建立合成結構圖,由此推導出使用案例圖。從整體看局部的焦點,從低精確度逐漸地至高精密的細節,在階段過程中用最少的精力,找出最重要的精華與本質,一開始把焦點集中在對的目標上,勝過於忙忙碌碌,結果花在太多沒有必要的工作上。



--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

為什麼Google能翻動整個世界?



http://www.ithome.com.tw/itadm/article.php?c=37023
為什麼Google能翻動整個世界?

為什麼Google能翻動整個世界?
文/ iThome (記者) 2006-05-07

《翻動世界的Google》基本上是本評價Google還算中肯的書籍,除了告訴讀者Google的成功以及獨特處之外,也點出了Google所面臨的潛在風險及法律困擾。


   翻動世界的Google
 David A. Vise、Mark Malseed/著,
 蕭美惠、林秀津/譯
 時報出版
 售價:380元

Google的崛起,始於.com時代的結束。當人們因為網路泡沫的幻滅而開始懷疑、低估網際網路的影響力時,Google正暗自的建立它的帝國。當全球的人們陸續開始使用這個遠較其他搜尋引擎更為準確的搜尋引擎時,已在不知不覺間將它納入成為生活不可或缺的一部份。

我在臺灣的朋友把Google稱為Google大神,因為想要找答案,毋需焚香禱祝,只須輸入關鍵字,多半就能在很短的時間內,找到自己想要的答案。

所以我們在不知不覺間養成了習慣:找餐廳、找論文、找作業解答、找範例程式來抄,第一個想到的都是請教Google大神,有人甚至在與陌生的人見面前,都 會到Google上輸入對方的名字,以了解他的背景。這就是Google的影響力,真難想像沒有Google的世界是如何的不方便。

Google的影響力是在不知不覺間建立的,但它的價值,卻是在它IPO(股票公開發行)後,才普遍的為世人所震驚。

做為一家傳奇性的公司,自然和IBM、微軟、蘋果等公司一樣,少不了各式各樣介紹性的書籍。

這類型的書籍,最怕的就是歌功頌德,錦上添花。畢竟,當一家公司正當成功之際,任何缺點也都能夠解釋成優點,而待公司營運情況不佳時,在許多人的口中或筆下,這些缺點又成了十足的致命傷。

讀這類型的書籍,須得小心此點。畢竟,讀者的目的是希望從成功的經驗中獲取成功的方法,不能從中找出成功的關鍵,那麼和讀完一篇杜撰的小說,也就沒有什麼兩樣。

完整介紹Google的發展歷史
這本《翻動世界的Google》基本上是本評價Google還算中肯的書籍。本書從兩位創辦人Sergey Brin及Larry Page的出生背景及教育談起,他們的家庭背景以及性格,對日後Google的發展,有著深遠的影響力。

Brin與Page相遇於史丹佛大學,在就學期間研究出搜尋引擎的關鍵技術,為了讓更多的人使用這個更準確的搜尋引擎,這個搜尋引擎的規模得不斷的擴增。

事實上,整個Google運作於名為Googleware的分散式架構之上。為了維持營運,他們明白必須引入資金。但最初打算賣斷授權予 AltaVista(當時影響力最大的搜尋引擎業者)以及Yahoo的計畫碰壁,迫使他們走向成立公司以及募集資金的道路。這使得他們毅然而然的決定休 學,決心打造全世界最好的搜尋引擎,並從矽谷天使(個人投資者)及親友們募得創業的第一筆資金。

技術與商業的成功接軌
隨著規模的擴增,早期募得的資金即將耗盡,史丹佛出身的他們擁有較常人更佳的人脈關係,爭取與創投業者的會面機會。

在當時網路創業的熱潮中,Google的獨特風格與技術,爭取到兩家極有聲望的創投業者投資-這是極為罕見的,因為像他們這麼大規模的創投公司,是很難接受與其他公司共同投資一家公司的。

但是在Brin與Page的堅持與運作下,這項共同投資案竟然成局。這也讓Brin與Page在商業領域的操作中初試啼聲,證明他們不僅有技術,更具備商業頭腦與膽識。

Google和許多一心只想著在NASDAQ上市的公司不同,他們持續的強化公司的技術體質,重視產品的創新,更引進專業經理人協助建立公司的營運架構。

他們追求公司的真正獲利,事實上Google長期都是私人自募資金的公司,因為他們不願因為股票上市,而對外揭露他們獲利的商業秘密。大眾普遍不能意識到,在.com公司哀嚎遍野之際,Google正一步一步的建立可觀獲利的基礎。

不過,為了向創投公司及投資人交代,他們最終仍舊得走向上市之路,即使Brin與Page是如此的不願意。

在Google公開發行時,他們獨特地採取荷蘭式(Dutch auction)拍賣的方式來發行他們的股票,而非華爾街傳統的IPO方式,這也正是Brin與Page即便是商業操作中仍舊獨樹一格的另一例證。 Google的股價以85美元掛牌,但卻一路漲上超過300美元,這是Google的成功,同時也說明了網路的價值反而是在泡沫消失後真正的發光發熱。

以技術創業的人,最容易遇上的瓶頸,就是不知道如何將好的技術對應到好的商業模式並藉以獲利。一個再好的技術,倘若不能獲利,對於創業者來說,是一點價值都沒有的,因為主掌一家公司的營運,和待在實驗室或研究室裡研究新的技術,是有很大的差異。
許多由研究單位出身的創業者,時常在這一點上跌跤。能夠被聲譽卓著的期刊所接受的論文,不見得能夠成為商業市場上賺錢的技術。

而Google的兩位創始者,自離開史丹佛校園後,儘管擁有極佳的技術,並且持續的加以改進,但始終未能找出正確的商業模式-原先所設定的商業模式乃是透過技術的授權來獲利,但事實證明那行不通。

重新調整後的商業模式-搜尋廣告行銷,卻能在本質上善用Google的搜尋技術優勢,同時對應到商業的價值-對廣告主來說,點擊廣告的網路使用 者,有更高的機會對他們所廣告的商品感興趣;對網路使用者而言,能在搜尋的過程中,同時看到自己可能會想購買的商品,也是一件十分便利的事情,何況 Google獨特的廣告擺放方式,並不會對正常的搜尋動作造成困擾。

所以在這個模式的轉變之後,Google的技術不單只是一個好的技術,而成了一個能夠對廣告主,使用者都產生正面助益的技術。也惟有如此,技術才能產生真正的商業價值。

Google的故事也告訴我們,身為創業者,如果只是想透過IPO大撈一筆,而不專注在產品的本質上,那麼往往也只是虛夢一場。

從.com時代許多在NASDAQ風光上市,之後卻又慘淡一片的公司身上,相信不會有人懷疑這點。Google的創始者始終不急著上市,他們在意 的是公司真正的獲利,只有關注真正的獲利,才會真正的致力於產品的本質。倘若公司專注的是財務面的操作,那麼頂多也只是另一個泡沫罷了。

想利用自己所擁有的獨特技術來創業的人,可以閱讀這本書。從這本書所介紹的故事中,可以意識到好的技術應如何的與成功的商業運作接軌,避開許多技術創業者常犯的毛病。

文化獨特的Google
Google做為一家成功的商業公司,卻有著許多獨特的文化,在本書中一一揭曉。大家知道為什麼在某些特定的日子,例如耶誕節、中國新年、甚至是大畫家莫內的生日,Google首頁上都會有特殊的裝飾圖案?

Google允許每個員工每週花20%的時間在公事之外,自己感興趣的事情上面,而很多此類的專案最後衍生成Google正式的產品。

Google為員工提供免費的餐廳,甚至聘任專門的主廚為員工每天變化不同的健康美食,成了Google特有的企業文化。

看成功也看風險及危機
本書除了告訴讀者Google的成功以及獨特處之外,也點出了Google所面臨的潛在風險及法律困擾。

Google必須面臨色情資訊被搜尋的問題,Google必須面臨侵犯他家公司專利權的問題,甚至Google大賺其錢的關鍵字廣告模式,在允許某公司的競爭對手購買該公司或產品名稱做為廣告關鍵字的情況下,勢必讓Google在全球各地都必須小心翼翼的處理法律爭議。
此外,在關鍵字廣告的經營模式中,點閱詐騙的手法,可能讓廣告主蒙受損失,Google也必須加以妥善的偵測與防堵。而員工在公司股票上市後,個個身價大漲,工作意願與態度也都有待考驗。而這種種的問題,更是身為讀者的我們,在Google的成功之外,最值得留意的。


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

熱愛古典音樂與飆車的「組合語言痴漢」



http://www.ithome.com.tw/itadm/article.php?c=36748
熱愛古典音樂與飆車的「組合語言痴漢」

熱愛古典音樂與飆車的「組合語言痴漢」
文/ 劉人豪 (記者) 2006-04-21

威盛電子軟體工程師陳依德對於各電玩主機技術細節、計算機組織結構與各指令集組合語言的熱情,加上對古典音樂和飆車的熱愛,顛覆一般人對工程師的刻板印象。


清明節的下午,在復興北路的某咖啡館,現任職於威盛電子擔任軟體工程師的「組合語言痴漢」陳依德,邊喝著抹茶冰沙,邊回憶起他的組合語言人生。

都是電動玩具惹的禍
當在正值人生「含苞待放」的高中時代,陳依德不像一般高中生踴躍參與「服務性質」社團,以提升在人類族群中的地位,提高與異性交往的機率,毅然決然的參加 一個正面臨倒社危機的師大附中工業技術研究社(簡稱「工研社」),開始過著每天看漫畫、打電腦、放炸藥(因為社團在製造「純娛樂性質」的炸藥)的另類學生 生活。

為何陳依德會加入這種連招牌都會把貓嚇跑的社團?那時的大型電玩幾乎清一色的使用Motorola 68K處理器,但當時的師大附中電算社卻只有286,陳依德因酷愛電玩,想要深入瞭解相關的技術細節,所以才去「理論上有機會應用68K的社團」。在考完 大學聯考的那個暑假,陳依德還想用一顆Intel 8748去實作一個電子鐘,自己撰寫七百多行組合組合程式碼可惜找不出bug,外加缺乏布雙層電路板線路的工具,導致功敗垂成,卻加深了他對組合語言的執 著,靠著這股熱情,雖然陳依德大學念幾乎和電腦技術無關的交大管科系,卻仍考上臺大資工所。

十多年下來,陳依德對於各電玩主機技術細節、計算機組織結構與各指令集組合語言的熱情,依舊沒有減少,反而因工作與興趣相結合而越燒越旺。數年 前,陳依德準備研究所考試之際,在巴哈姆特電玩資訊站發表諸多連筆者都深為折服的技術大作,甚至連他在臺大資工所關於影像處理的畢業論文,差一點就要用 PS2去執行計算模擬的工作,因為他覺得PS2處理器的向量指令集,還遠比Pentium 4的SSE2好用。由於PS3發表在即,其採用的Cell處理器非常具有技術開創性,又有豐富的免費開發工具,最近他也想把腦袋動到PS3頭上。

工程師生活不見得苦悶
有別於一般人認為工程師等於苦悶生活的同義詞,陳依德自認他目前的人生非常歡樂,一點都不苦悶。為什麼他可以這麼「諸法皆空,自由自在」?他表 示,所謂的苦悶,皆出自於「無法達成慾望的極度飢渴」,尤其是感情,只要學會從旁觀者的角度思考,就會發現苦悶與煩惱都是出自於自己的執念。若能適時地轉 移注意力、調整情緒,就能從此等執念中釋放出來,退一步即是海闊天空。

可是,那為何你還是「痴漢」呢?畢竟這讓人聯想到日本的電車痴漢。他義正言詞的表示,所謂的「痴漢」對他來說,只是專注在某些技術層面事物的研究 執著,並非如普羅大眾所認為心理異常的變態,譬如對於性的話題,一旦以學術角度角度來探討,就不會有令人覺得低級不堪入耳的成份。更重要的是,這就是他自 認的「長處」,雖然筆者和他相識多年,一直覺得他這個人,以正常人的標準來說,在某種程度上還是蠻變態的。

「船到橋頭自然直」的人生哲學
生活不苦悶並不代表工作就沒有挫折,在競爭激烈的資訊產業,工程師一直都是非常辛苦的一群人,壓力不足外人道也。

對於這點,陳依德認為各行各業都有自己的苦,很難為外人所理解。對大部分工程師而言,所謂的甘苦都是與工作、感情有關,譬如說事情做得多領得少, 或是找不到女朋友。對他來說,卻是另一個層次的感受問題:每個人寫出來的程式,都反映出對某個問題或需求的詮釋方式,完善地處理問題其實是種學習成長的機 會,但是當解決完一個問題後,卻沒有機會可以對其他人表現自己的理念,則是比較容易讓他有受挫的感覺。不過這種情緒上的問題,對他而言是很短暫的,因為他 很容易找到別的事情做,此種負面的感受中跳脫出來,譬如拉小提琴、或是打電動、開車閒晃等。

曾經遇到難過到想跳樓的挫折嗎?他自豪的講,天底下沒有解決不了的問題,除非這問題是外星人、神或女人所造成的,否則如果連他都會跳樓,大概整個 資訊產業的工程師都要蒙主寵召了,反正「每部警匪動作片電影,都是在一個多小時內,主角一堆親朋好友慘遭殺害,但結局都是皆大歡喜」。

透過音樂來洗滌心靈
對陳依德而言,他認為古典音樂才是能完全抒發、表現人類本能的音樂,而時下流行的嘻哈風或是饒舌歌,他完全不以為意,並認為要叫他聽這種東西,倒不如去聽陳雷或日本演歌。

他學過幾種樂器,小時後學過鋼琴,只是不耐久坐在鋼琴前面,而只短暫地學了一兩年。而小提琴對他而言,卻完全是個意外,他獨立在日本札幌大通公園 散步,因緣際會聽到兩位路人的街頭演奏,讓他瞭解小提琴有著能高度引起共鳴的魔力。雖然技巧還未能登大雅之堂,他還是固定每天至少會練習個數十分鐘。他開 玩笑地說著,如果年紀大了沒工作做,在外流浪說不定還可以靠這混口飯吃,因為他現在就算上班,也會躲在會議室裡拉小提琴。

偶爾從「公車男」升級成「飆車男」
在學會開車之前,幾乎雙腿或公車是陳依德的代步工具,因為所有兩輪的交通工具都不是那麼地安全,又容易讓全身沾滿煙塵,連騎腳踏車也曾經騎到摔 車。他也透露,如果沒有公車,他是那種寧願花個一小時走路回家也不願讓小黃海噱,因為坐在公車上,至少有機會可以欣賞到美女,但坐在計程車上,卻只能聽開 車的歐吉桑聊些「當年勇」或是苦澀人生的話題。

雖然考上駕照是距今十年前的往事,但卻是在工作之後,才實際把開車當作日常生活必須的技能,因為這樣才能實現「車開到哪,人睡到哪」的全臺流浪境 界,也比較能四處雲遊。偶爾飆車,對他而言是燃燒熱情、生命及抒發情緒的方法,最高記錄是一天開了將近八百公里,時速高達160公里。他開玩笑地說,短暫 爽一下是無妨,生命還是要顧。

一日痴漢,終身痴漢
對他來說,組合語言已經不再只是單純的興趣,而早已成為生活的一部分,就有如呼吸一樣,沒有人會去在乎「呼吸究竟是不是有趣的事情」他依舊會繼續鑽研技術底層,盡其所能的學習不同指令集的組合語言。

如果借給他小叮噹的時光機,讓過去可以重來,他還會不會繼續走上組合語言痴漢這條路?這絕對著毋庸議,他只擔心,「如果世界上哪天真的沒有組語,我就只能從運算碼(opcode)下手了」。文☉劉人豪

IT人物-陳依德
現任職威盛電子的軟體工程師
●學經歷:畢業於交大管科系與臺大資工所,PC Shopper組合語言痴漢專欄作家。

公司檔案-威盛電子
●成立時間:1992年9月
●營業項目:IC設計,個人電腦平臺解決方案

陳依德對處理器技術發展的看法

 首先,必須降低電晶體,甚至是新型的電子或光子開關所需要的能量。目前電晶體比腦細胞的的耗能程度多了百倍以上,開著一個產生一堆廢熱卻不像燈管一樣會發光的處理器,很浪費能源。

 其次,增加運算單元的電晶體比例。目前的處理器耗費過多電晶體在做非循序動態最佳化排程的動作,偏偏這些方法都是極度浪費電路成本,與其用電路硬幹,不 如讓編譯器產生出最佳化執行檔,還比較節省能源。再者,處理器快取記憶體的電晶體個數越來越多,甚至還比處理器核心大,可是光增加容量能對哪種類型的程式 增加多少幫助?這個實在是有待斟酌。

 最後,多核心已經是趨勢了,因為越來越少廠商有本事能降低時脈增加所造成的額外耗能量。現在很難斷定哪種多核心的型態才是比較好,是因為不同型態的資料 處理有著不同的適用架構。對所有的程式設計者而言,就得要開始適應這種架構發展的趨勢,不能再侷限於舊有單線性控制流程的思考模式, 必須思考把計算量分散在不同處理器中的資料流向模型。文☉劉人豪



--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

主題書-從駭客的觀點看世界



http://www.ithome.com.tw/itadm/article.php?c=36647
主題書-從駭客的觀點看世界

主題書-從駭客的觀點看世界
文/ iThome (記者) 2006-04-16

《駭客與畫家》說明駭客與畫家都試著創作美好的事物:畫家從前人的作品中學習模仿,找出偉大畫作的共通靈魂;駭客能從開放源碼的專案中,透過閱讀他人的程式碼,琢磨設計程式的要點與精神,繪畫與設計軟體都需要對美感的狂熱奉獻。


駭客與畫家Paul Grahm/著,莊友欣、莊惠淳/編譯
O'Reilly出版
售價:300元

《駭客與畫家》(書摘) 基本上是一本散文集,它收錄了作者的十五篇文章,而這十五篇文章,基本上是以作者做為一名「駭客」,來檢視各種不同的主題。

事實上,駭客只是個通稱,在駭客的光譜上,還是散佈著各種不同風格的駭客,有像Richard Stallman這種仙風道骨,有著崇高理想的駭客,也有像本書作者一樣,對於創業別有獨特想法的駭客。

駭客是極具藝術性的
本書的標題《駭客與畫家》,也正好是眾多散文中的一篇主題。本書作者不僅擁有哈佛大學的電腦科學博士,同時還曾經在藝術學校中學習繪畫。在這篇文章中,作者試圖說明駭客與畫家之間的相似性。這樣的結果看似違反常識,但仔細一想,卻又極為合理。

他們都是創作者,都試著創作美好的事物。畫家從前人的作品中學習模仿,找出偉大畫作的共通靈魂。

而駭客能從開放源碼的專案中,透過閱讀他人的程式碼,琢磨設計程式的要點與精神。繪畫與設計軟體都需要對美感的狂熱奉獻。

駭客的社交關係
本書中有篇文章叫做《為什麼書呆子不受歡迎》。在文中,作者認為所謂的聰明人在成長過程中常常因為自己的聰明,而使得自己在同儕團體間不受歡迎,而被視為 所謂的書呆子。並從自己受教育的經驗為例,檢討為什麼在美國的校園中,會欺壓所謂的聰明人,導致大家寧可做個受歡迎的人,而不願意做個聰明人。

駭客的財富觀
從另一個觀點切入,作者的新創事業-Viaweb,成功的出售給Yahoo,使得他與幾位一同創業的駭客,都獲取了大量的財富。在《另一條路》、 《製造財富》以及《留心鴻溝》諸篇文章中,作者不僅描述了他如何透過獨特的觀察,找出應用程式的另一條路,並且據以做為新創的事業開始投入發展,同時他也 對於做為一名駭客,應該如何的快速賺取大量財富,提供了他自身的經驗之談。

站在作者的觀點來看,駭客是具有超凡驚人技藝的人,理當獲取超越凡人的報酬,畢竟十個凡人或一百個凡人,無論如何也比不上一個駭客。這不是量的差 異,這是質的分際。而辛勤熱情工作的駭客,更應該獲得更高的報酬。從作者的角度看來,就明顯不是主張駭客當分文不取,而只應為理想努力,不應墮落在資本主 義社會的金錢遊戲之下-所以我說駭客的屬性,是散佈在一整個光譜上的,沒有絕對同類的駭客。

好的設計該有品味
本書中有幾篇文章談論到「設計」這個主題。我認為所謂的設計,是解決問題的手段,低層次的設計,關心問題是否被有效解決;而高層次的設計,則關心 設計是否達到足夠的美感。其中有一篇叫做《設計與品味》的文章,像這樣子的文章,把軟體的設計和品味放在一塊,基本上就有深度可以談論了。

作者列出多個評估設計是否夠好的準則,例如「良好的設計是簡單的」是普遍被接受的想法,而像「好設計歷久彌新」,則掌握了「不夠美好的東西總是會被取代,留下來的東西,才是最好的」這樣子想法的精髓。

在這個準則下有個有趣的論點,也就是說如果我們的設計,想要吸引未來的人,肯定要能夠吸引過去的人。誠哉斯言呀,美的價值恆久不變,對於未來的人要是美的,那麼對過去的人來說,也勢必是美的。這彷彿又對流行與時尚,做了更高層次的詮釋。

該不滯於物
做為一名駭客,作者對程式語言有他自己特別的觀點。事實上,我發現駭客都有不喜歡受限的特質。所以不難理解作者對於程式語言的偏好方向。

但就我來看,終歸是楊過在獨孤求敗的劍塚前所見的一句話-「四十歲後,不滯於物,草木竹石均可為劍。自此精修,漸進於無劍勝有劍之境。」究竟是利劍強、玄鐵重劍強,還是木劍強,這程式語言優劣的論戰,我想始終是難以平息。

《作者簡介》王建興
清華大學資訊工程系的博士研究生,研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人,專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同,從ERP、PC GAME到P2P網路電話都在他的涉獵範圍之內。


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

Delphi擁抱PHP,下一步是Ruby?+Delphi歸來,重燃開發人員的信心+新聞分析-Delphi的下一步



http://www.ithome.com.tw/itadm/article.php?c=42763

Delphi擁抱PHP,下一步是Ruby?
文/ 王宏仁 (記者) 2007-04-04

CodeGear進軍動態語言市場,在臺推出Delphi for PHP整合開發工具。


透過元件拖拉和簡單幾行程式,CodeGear大中華區技術總監李維在幾分鐘內示範了過去PHP開發人員需兩小時人工才能完成的資料集控制與內容篩選。3 月22日CodeGear進軍動態語言市場,在臺推出Delphi for PHP,提供PHP語言的視覺化整合開發工具,包括整合式除錯工具、程式碼編輯工具與跨平臺部署工具。 >>>Delphi歸來,重燃開發人員的信心

Delphi for PHP完全支援雙位元的中文,開發人員無須像過去開源元件需自行調整中文相容設定,內建50多個VCL for PHP元件,開發人員可完全用PHP直接開發Ajax介面。CodeGear網站上已提供Delphi for PHP的一天試用版下載。

內建開源元件可自行擴充修改
內建VCL for PHP元件已包含常見表單控制元件、Ajax元件與資料庫控制元件,使用者點選元件的名稱,可直接打開原始碼自行修改。李維表示:「與其他開發工具的 Ajax不同,Delphi提供的是元件,而不是框架,因此可以更方便的透過拖拉設定去控制,使用者也可以很容易增加新的元件,例如只需80多行程式就能 把Google Map封裝成可重複使用的元件。」

Delphi for PHP並非使用Delphi語言,而是純粹的PHP開發環境,內建VCL元件均由PHP語言寫成。目前僅支援Windows平臺,但開發出來的PHP網 頁,可 部署到其他如LAMP的環境中。惟透過C開發的擴充元件則無法透過Delphi for PHP直接部署。

雖然動態語言容易修改與維護,程式除錯仍是PHP開發環境的困擾,開源部落格平臺LifeType的社群主持人Mark Wu認為:「程式除錯是目前PHP開發中很困難的部分,目前的除錯方式除了自行在程式碼中寫Echo指令外,就是需要自行在伺服器安裝追蹤程式,PHP很 少有整合式開發環境。」,針對除錯功能, Delphi for PHP可直接開啟既有PHP專案,設定中斷點進行程式追蹤,開發人員無須自行撰寫除錯控制的程式碼。

針對網頁設計與PHP程式的整合問題,Mark Wu認為:「目前網頁應用程式的方式傾向於,網頁美術設計把Photoshop圖檔弄出來就完成,其他都是程式設計負責。……臺灣網頁程式開發人員最大的 困擾就是要作美工。……如果Delphi for PHP能整合既有框架或提供適當的工作流程,或許有助於吸引更多人使用。」

李維說明Delphi for PHP對美工的整合方式:「目前Delphi for PHP會提供一套標準,以Dreamweaver8設計網頁時,可於適當位置加入特定標籤,Delphi for PHP會將PHP程式碼套用到特定標籤所在的網頁位置中。開發人員與美工設計只要遵循這套標準,隨時可以整合。」

對於開發社群的建議,李維表示:「Delphi for PHP的研發團隊已經開始規劃下一版, Delphi for PHP下一版會整合Zend 框架,並提供美工設計的預視功能,讓開發人員可以在Delphi for PHP中直接看到美工人員的工作結果。」

Delphi 2007 for Win32也支援Ajax
CodeGear開發日也同時發表Delphi 2007 for Win32,提供Win32原生的整合開發工具。新增Ajax元件,讓Delphi使用者可完全使用Delphi設計Ajax效果的網頁。改採DBX4的 資料庫架構, 未來若需要在.NET或64位元環境執行,只要重新編譯程式碼而無須重新撰寫資料庫程式。此外,採用MSBuild部署工具,開發人員可自訂 不同版本的部署方式,提供部署過程的事件驅動功能,可讓程式將部署過程所需相關設定,全部自動化,可大幅減少瑣碎的部署設定程序。

CodeGear為改變先前Borland對開發工具市場的態度,重拾使用者的信心,積極於2007年推出開發工具與支援服務。李維表示在 2007年的重心除維持既有產品線的穩定,也將開拓Web和動態語言的市場。每季預定至少推出兩項產品。除第一季所推出的Delphi for PHP與Delphi 2007 for Win32之外,六月將全球同步推出新版C++ Builder,第三季推出Borland Developer Studio 2007,包括Delphi for Win32、Delphi for .NET、C# Builder與C++ Builder,特別是Delphi部分,會支援泛型編程(Generic Programming)。詢問是否會推出Ruby的開發工具,李維回應不能對這類產品發表評論,只表示:「下半年將會有新的IDE開發工具,將會給動態 語言開發人員一個驚喜。」 >>>新聞分析-Delphi的下一步

CodeGear也強化了參考文件與技術支援服務。一方面招募更多文件撰寫人員,直接於產品中提供詳盡的英文技術文件,另一方面也透過官方網站上的開發者 網絡(Developer Network)提供各類電子資源,包括功能操作的示範影片,可直接下載觀賞。臺灣區目前有一位CodeGear大中華區技術總監李維,他表示:「新加坡 設有亞太區技術服務中心,可提供24小時的華語諮詢,對購買支援服務者,還可透過遠端遙控,讓技術人員看到使用者的操作過程,直接提供建議。目前正在經營 一些大陸與臺灣的中文技術社群,也將錄製中文示範影片,待美國總公司審查後,會放到開發網絡上。」

拋開過去Borland強化行銷的迷思,改採鎖定開發人員的策略,李維指出:「CodeGear採取鄉村包圍城市的行銷策略,先說服專案人員與開 發人員,贏得開發人員的認同後,未來就能影響公司決策階層採用產品。」,他認為:「臺灣的軟體開發多為個人、SOHO族或小公司,正適合這種推廣策略,預 計五月時將至中南部舉辦更多技術研討會。」文☉王宏仁

Delphi歸來,重燃開發人員的信心 CodeGear大中華區技術總監李維介紹完新產品,聽眾迫不及待的走向講臺,紛紛問起新產品的相容問題,知網生物識別科技技術長江元麟也是其中一位,他特地來問一個問題,因為這將影響到公司未來產品的開發效率。

Windows Vista出現帶來64位元新挑戰。知網生物識別科技去年面臨客戶要求在Vista的Content Menu技術上支援64位元檔案指紋加密。江元麟表示:「目前只有Microsoft Visual C++支援64位元,但我們累積了很多Delphi的Library和元件,基於穩定度及開發時效的考量,並不希望換開發環境,目前做法是花很多力氣和C ++整合。……我今天就是來問Delphi什麼時候支援64Bit?」

從1995年發表1.0版後,12年來,Delphi歷經11個版本更迭,從16位元的1.0到.NET平臺的BDS 2006。開發部門獨立成立CodeGear 後,又回到原生Win32環境下的Delphi 2007 for Win32。江元麟24年程式開發經驗,一路見證了Delphi的變化。

從1987年開始接觸Borland,江元麟用過Turbo Pascal和Turbo C。1995年,因為工作需要開始使用Delphi。2000年,他投入生物識別產業,繼續使用Delphi 5開發,他指出:「Delphi有一個很好的優點是可以開發自己的元件,它的元件讓我們的產品開發加速很快。新進工程師能馬上就作一些簡單的開發,這是 Delphi最棒的地方。」

相較於當時其他開發工具,他認為:「VB當時沒辦法完全用物件導向的方式去開發元件,比較不是給Engineer用,而是給Power User使用。而C++要客製化元件難度頗高,它的平臺沒有那麼靈活。」
為何一直用Delphi?江元麟解釋說:「是因為它的平臺,很多Source Code都有釋出,所以你可以開發一些真的是自己會用到的基層元件。我們公司的元件已經累積5年到10年都有,一個元件能夠撐那麼久,代表它很穩定了,相 對的我們公司的產品出來品質是非常好的,這也是Delphi的貢獻……這也是為什麼,我們寧可在Delphi上花力氣結合C++來處理新挑戰。」3年前, 知網的識別軟體能讓Pentium 4 處理器在1秒內辨識十萬枚指紋,是當時國外最高速度的3倍,他說:「這其中有一部份是由Delphi編譯出來的程式碼效率相當好的貢獻。」

雖然當天江元麟的問題沒有立即的解決方案,但對於脫離Borland後的GodeGear,他表示:「蠻喜歡切割出來的CodeGear,以前步 調很慢,現在步調很快,我比較喜歡,聽到李維傳遞的訊息,感覺比較有活力,但希望能維持以前的速度和品質。兩年前看到Borland公司很亂,覺得很遺 憾,周圍的人兩年前已經慢慢轉到C#去了。」,他接著說:「我們本來去年要考慮轉成C#,現在要重新考慮了。」文☉王宏仁

新聞分析-Delphi的下一步 Delphi for PHP自CodeGear宣布後即引爆PHP社群熱烈討論,CodeGear跨出既有開發語言,首度邁入動態語言市場。CodeGear大中華區技術總監 李維表示:「Delphi for PHP是我們的第一步,但是我們不會停止在這一步。」,那麼這個下一步會是什麼?

去年底開始,CodeGear開始大量招募動態語言的研發人員,特別是PHP與Ruby。現在已看到PHP研發人員的成果。CodeGear宣示 今年每季都將推出新產品,不難看出CodeGear的活力和企圖心,不僅要重新穩固既有使用者的信心,更進一步,還想成為軟體開發市場的領導者。

軟體開發市場上,在.NET平臺,微軟具有先天優勢,短期內CodeGear勢難與之抗橫。Java平臺Borland過去經營已久, JBuilder 2007已建立相當口碑。至於Adobe新的Apollo平臺,李維表示還有待觀察但短期內不會考慮支援。那麼,CodeGear想在最短時間內展現企圖 心的爆發力,勢必要直接開闢新戰場,塑造優先者的形象。切入Web開發語言中佔有率最高的PHP,可看出CodeGear已經選定動態語言市場作為新戰 場。Delphi for PHP的確是一套優秀的動態語言視覺化整合開發工具,但既有PHP開發環境中,並不乏整合開發工具的解決方案,例如已與Orcale、微軟合作的Zend Studio,或者像是臺灣人自行開發的免費IDE工具PPForm。CodeGear不易在PHP語言市場,大幅拉開品牌差距。可預期,尚無整合開發工 具又當紅的Ruby自然成為CodeGear下一個鎖定的目標。

還可從幾個地方觀察到CodeGear對Ruby熱切的關注。在CodeGear副總裁David Intersimone的部落格上,蒐集許多Ruby開發手冊或Ruby語言的參考連結,TIOBE宣布Ruby成為2006年度開發語言的新聞,也被特 別摘錄出來,甚至David I.將Ruby列入2007年CodeGear觀察關鍵字清單中(watchwords),僅次於PHP。CodeGear在3月12∼16日舉辦的 CodeRage 2007開發人員研討會中,和PHP一樣,也安排了兩場介紹Ruby的演講。

在CodeGear官方網站上已經開始招募Ruby的產品佈道者(Evangelist),如同李維的工作角色一樣。這更確定了李維所說的下半年這一步,將會是Ruby的開發工具。文☉王宏仁

--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

解析微軟「Flash Killer」-WPF/E(上)(下)



http://www.ithome.com.tw/itadm/article.php?c=42704
http://www.ithome.com.tw/itadm/article.php?c=42764

解析微軟「Flash Killer」-WPF/E(上)
文/李延華 (記者) 2007-03-29

WPF/E是WPF的子集,桌面應用由WPF支撐,微軟希望WPF/E與現有的網頁技術互相整合,幫助提供更好的使用體驗。


奚江華
NET書籍作家、微軟專屬講師及顧問, 熱愛微軟.NET 技術,創立「DotNet開發聖殿」部落格,以發布.NET相關資訊為宗旨,聖殿祭司則是他在網路上的代號。

微軟才推出.NET 3.0不久, 相關工具尚未到位,WPF(Windows Presentation Foundation)還是個新鮮而陌生的技術名詞,沒想到這一會兒又冒出了一個WPF/E(Windows Presentation Foundation/Everywhere)。到底WPF和WPF/E有什麼差別?和Flash又是什麼關係呢?微軟最有價值專家兼.NET暢銷書作者 奚江華,給了我們第一手的資訊。

問:WPF/E和WPF是什麼關係?
答:WPF/E是WPF的子集,嵌入在瀏覽器中提供2D繪圖、向量動畫與影音的效果。

問:WPF/E是否可不依附在HTML或瀏覽器中,獨立在桌面環境執行?
答:桌面應用由WPF這個巨人撐著,並不需要WPF/E從瀏覽器跳出,要是拿WPF/E來應付桌面應用,那麼WPF/E站在WPF這個巨人面前,只會顯得像侏儒般瘦小,不但突兀,而且也不符合邏輯。

WPF/E的Runtime Component下載檔也只有1.1MB,相對於.NET Framework 3.0安裝檔約50MB以上,顯得精簡許多,但這並不表示WPF/E的功能很陽春,反倒有許多功能是超越HTML能力,所以雖然WPF/E本身具有獨當一 面的潛力,但微軟目前沒有讓WPF/E獨立的計畫,反倒希望WPF/E能夠與現有的網頁技術互相整合,在Web上扮演好應有的角色。

問:既然WPF/E是嵌入在網頁之中,不就是和Flash的定位相同?開發者該如何選擇?
答:雖然WPF/E與Flash在功能與行為模式上非常神似,WPF/E也確實常被業界號稱為「Flash Killer」,但撇開功能與行銷上的勝負爭執,其實兩者本質上有很大的差異。

簡單來講,未來廣大的.NET程式設計師會想擁抱的是WPF/E,因為WPF/E不是孤島,WPF/E可 以和ASP.NET AJAX、C#、VB、XAML、WF、WCF與WPF等.NET平臺的技術結合,成為好開發又好維護的統合技術,而非東拼西湊的解決方案,在開發、維護 與擴展方面具有很大的優勢。

問:通常以向量技術所設計的網站,不能直接被搜尋引擎解析,WPF/E有這樣的問題嗎?如果希望提高網站的能見度, 是不是就應該選擇ASP.NET AJAX?
答:Flash這方面的問題,據專家表示可以在MetaData中嵌入文字,以便讓搜尋引擎解析,不過若是動態的產生資料,則無法自動更新MetaData中的資料。

而WPF/E本身是以DOM型式公開它的元素樹(Element Tree),所以透過最原始、最單純的JavaScript,就能夠讀取WPF/E內容。搜尋引擎可以輕易對WPF/E所設計的網站進行爬文檢索,完全不需要使用任何的特殊橋接器或演算法。

問:WPF/E是與IE捆綁,還是可以跨瀏覽器?
答:目前所發行的WPF/E CTP版本安裝套件,只支援Windows及Mac兩種作業系統上的瀏覽器,實際支援規格如下:

● Windows XP SP2:IE 6、IE7/Firefox 1.5、Firefox2.0。
● Windows Vista:IE7/Firefox 1.5、Firefox2.0。
● Mac OSX 10.4.8:Firefox 1.5.0.8/Safari 2.0。

問:那麼,未來WPF/E會發行Linux平臺的 Runtime Component嗎?
答:就我的觀察,微軟對Linux平臺的一貫政策與作法,似乎是不會主動支援。所以這也是為什麼有Mac版的WPF/E安裝檔,卻沒有Linux版本的緣故。就種種利害關係的考量,未來不會有Linux版本的WPF/E安裝檔的機率似乎較大。

問: ASP.NET AJAX與WPF/E,是二擇一的方案?還是未來其中一個會被對方取代?
答:基本上ASP.NET AJAX與WPF/E兩者並不是相互替代,而是彼此互補的技術,兩者各有其強項,所以微軟的策略是整合兩者的能力。 ASP.NET AJAX與WPF/E結合,會比目前Web只融入單純的Ajax技術更具吸引力。整理☉李延華

解析微軟「Flash Killer」-WPF/E(下)
文/李延華 (記者) 2007-04-04

WPF/E超越.NET的限制,可與JSP、PHP或CGI程式溝通,不過支援的瀏覽器目前仍限於Windows和Mac平臺,未來是否支援Linux尚是未知數。


奚江華
NET書籍作家、微軟專屬講師及顧問, 熱愛微軟.NET 技術,創立「DotNet開發聖殿」部落格,以發布.NET相關資訊為宗旨,聖殿祭司則是他在網路上的代號。

既然ASP.NET AJAX 1.0和WPF /E不是二擇一的方案,而是互補的技術,兩者有什麼差別呢?開發者該如何並用這兩種技術,達到相輔相成的效果?請看奚江華的說明。

問:Ajax技術即可強化網頁的互動性,為什麼還需要WPF/E?
答:傳統的網頁技術,由HTML到DHTML,再進化到Ajax,雖然讓用戶端與伺服器端互動能力增加,運作速度也變快,但對於2D繪圖、向量動畫與影音 效果的改善,仍十分貧乏。而這些不足之處正是WPF/E天生的超級強項,所以如果Ajax能與WPF/E互相搭配,將會大幅提升Web應用程式在使用者經 驗上的滿意度。

問:ASP.NET AJAX與WPF/E兩者之間如何互動?
答: ASP.NET AJAX與WPF/E之間的互動,完全不需要依賴特殊的橋接器,只要透過三個要素:W3C的DOM、JavaScript與WPF/E Object Model即可做到。也就是說,開發者利用JavaScript,就能夠操控DOM與WPF/E控制項,讓彼此之間可互相溝通與呼叫。 而ASP.NET AJAX的用戶端解決方案,正是以JavaScript為基礎,而透過JavaScript即可與WPF/E互動。

問:如果我們已架設好ASP.NET AJAX開發環境,該如何與WPF/E整合?
答:開發WPF/E程式最基本只需要安裝WPF/E Runtime Component,如果希望在Visual Studio 2005中有WPF/E的樣板使用,需先安裝Visual Studio 2005 SP1後,再下載安裝WPF/E SDK,透過內建的工具產生WPF/E專案樣板。

問:如您所言, ASP.NET AJAX專案樣板要如何與WPF/E整合開發應用程式?
答:在ASP.NET AJAX專案中只需引用WPF/E的agHost.js及eventhandlers.js兩個JavaScript檔, 即可整合開發。

問:WPF/E使用的是標準的HTML和JavaScript,所以其他類型的網頁程式是否可以使用?
答:的確如此。由於WPF/E只要安裝Runtime Component就能夠執行,而它本身又可以透過JavaScript存取WPF/E DOM,並且執行WPF/E控制頂的方法與屬性,就理論上是可以讓JSP、PHP、ASP等網頁語言使用,所有以HTML為基礎的網頁程式,都可以直接整 合WPF/E程式,發揮WPF/E在動畫、繪圖與影音的強大能力。

不過,讓JSP叫用WPF/E的想法,是我在研究WPF/E技術時,無意間想到的,所以就實際建置Apache和Tomcat,並部署WPF/E應用程式測試看看,結果發現確實可以正常瀏覽與執行WPF/E的應用程式。這確實令我十分吃驚。

因為實驗的結果背後的意義是:WPF/E擺脫了Windows、IIS與ASP.NET,那麼Linux伺服器的JSP或PHP程式,按理來說,也可以自由叫用WPF/E的功能(編按:WPF/E目前尚未支援Linux的瀏覽器)。
微軟從來不會大方開放.NET技術給其他軟體使用,也不曾推出一個可以不需要買Windows、IIS就能執行的網頁技術。未來微軟會不會鎖定WPF/E只應用在Windows平臺,就不得而知了!

問:最後一個問題, WPF/E的影音多媒體、2D動畫與向量繪圖等功能都非常令人驚艷,但是,為什麼沒有支援3D?
答:WPF/E為何捨棄3D視覺效果?理由有幾個重要因素:

1. WPF的3D是透過DirectX引擎著色,並且充分利用顯示卡GPU的強大運算效能,但其他平臺並沒有DirectX引擎,為了保持WPF/E跨平臺的特性,所以無法進行3D運算。

2. WPF/E是在瀏覽器中執行,而瀏覽器本身是屬於沙箱(Sandbox)的環境,基於安全性的理由,並不允許直接與DirectX引擎等底層服務溝通,所以3D功能的運算,有這一層限制。

3. WPF/E Runtime Component的大小限制在1.1MB, 這部分與Flash相當,所以無法塞入大量的3D函式庫。而且Flash本身也因為跨平臺因素沒有提供3D功能,微軟參照競爭者的作法,思維上也就不急著加入3D功能了。

雖然無論是WPF/E或Flash,3D的功能兩大陣營都有種種不實作的考量,但不表示這兩個技術無法實現3D功能。因為有一個著名的 Papervision 3D(開放源碼的Flash),已經實作在Flash中加入3D功能了,所以由此看來,3D在WPF/E上運作是可行的,剩下的就是微軟決定何時在 WPF/E中加入3D功能罷了。整理☉李延華


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

軟體設計必讀經典(1)(2)(3)



http://www.ithome.com.tw/itadm/article.php?c=44561
軟體設計必讀經典(1)

軟體設計必讀經典(1)以簡約之道介紹UML最實用的部分
文/ iThome (記者) 2007-07-29

《UML精華(UML Distilled)》的作者以口語化、精簡的文字,活化描述UML13張設計圖的精髓,幫助讀者完成80%的工作。


 UML精華第三版:
 增訂嵌入式系統與工作流程概念

 Martin Fowler /著
 趙光正/譯
 �峰出版
 480元

教授軟體設計課程多年來,我經常建議學員要常看書,但不是看使用手冊這類操作性How-to書籍,若是因為工作需要,工具書擺著幾本當作參考無妨;或者,學會在Google下對搜尋關鍵字那更好,可以更快找到How-to 性質的答案。

拜搜尋技術發達之賜,我們越來越容易從網路上找到How-to答案,相對來說,軟體開發人員就可以把更多的時間與心思用在軟體設計的思維上。不過,著重軟 體設計的書籍,只有國外幾位頂尖軟體大師的著作可以學習。只是軟體人員一般會對原文書有恐懼感,加上經常會有一種閱讀的壞習慣──想要從第一頁看到最後一 頁,結果大多數人只看到前三章就看不下去了。

讀軟體設計書籍要「不求甚解」,沒必要追求所謂「唯一的答案」,要如同看漫畫、金庸小說般去享受,對某一主題作思考與體悟。不過,前提是你必須要 能分辨出作者是否有自己的「想法」,沒有自己想法的作者相當多,導致許多讀者看不懂坊間所謂的「物件導向系統開發」書籍。當你能「感受到」作者想要透過書 中的文字,表達他的想法,甚而,還逐漸能猜得出作者內心中的「假設點」,那麼,這就是一本可以值得學習的好書!

用UML 20%的精髓完成80%工作
《UML精華(UML Distilled)》,是軟體設計叢書中,最能表達作者自我又帶著創意性想法的好書。作者以口語化、精簡的文字,活化描述UML(Unified Modeling Language,統一塑模語言)13張設計圖的精髓。

我覺得Kobryn(UML 規格制訂主席)為本書所寫的推薦序形容得最好:「自古以來,天縱英才的架構師與最具智慧的設計師都瞭解何謂「簡約之道 (the law of parsimony)」。」 他甚而還引用佛家禪宗的心法來解釋簡約之道:「禪宗的心是初學者的心」。而軟體與佛家的智慧是一樣的,是不受時空限制的,其要旨都在於如何從繁雜的表象萃 取其本質(Essence),讓形體(Form)可以很協調地與功能融合在一起。

Martin Fowler,正是軟體界具有真正智慧的軟體大家,能將「簡約之道」,真正在本書中發揮得淋漓盡致。他就是能用迷人、口語化的寫作風格,來寫出「UML 中最有用的一小部分」,而這一部分,正是可以幫你完成80%工作的20%的精髓。

以軟體結構分析為重點
本書前二章談軟體開發方法論(methodology);後續的章節,則分別介紹UML的13張圖;關於類別圖,Fowler 則用2個章節說明,其中,與一般軟體設計書最大的不同,是在第三章就談類別圖,先從需求分析著手。至於需求面的設計圖,包括使用案例圖與活動圖,則擺在中 間的章節。

從編排來看,可以知道 Fowler 最重視軟體的結構分析,而這也是本書最精彩之處,包括類別圖與循序圖的介紹與其想法的論述。

軟體開發方法論:UML與開發流程
方法論包含二大要素:溝通的機制與開發流程。UML正是利用圖形標準化的模式語言,作為團隊開發之間溝通的最佳機制。Fowler 在UML簡介裡,說明了UML的發展歷程,這部分只要稍微了解就可以。
Fowler也提到對UML的用法,分為草稿式與藍圖式。前者是將UML圖形作為溝通的機制,不講究精確的語法;後者則是要求精確性高的設計,讓 程式設計師能依樣畫葫蘆地寫程式。我的作法與Fowler的想法一致,比較偏向草稿式。道理很簡單:一、你不能假設你的設計會是正確無誤的;二、絕大部分 的軟體人員,連「畫出來」都不太有勇氣了,更何況要求僵化的工程模式?那可會嚇跑一堆軟體人員,也違背了圖形模式開發的本質──溝通。

雖然是介紹UML語法,不過Fowler 還是特別開出一個章節介紹開發流程,比較往覆式(Iterative)與瀑布式(Waterfall)的開發風格。

現今主流的開發流程都一致認同往覆的開發方式,但很難做到,因為往覆式開發會衍生出不確定性的恐懼感與專案管理的議題。Fowler 用了一個很有趣的字眼,「偽往覆式開發方式(原文是用 pseudo,我覺得真的很客氣,不是用fake)」:雖然大家都宣稱採用往覆式開發方式,不過實際上卻仍是瀑布式開發方式。如同我在課堂上常提的,導入 如RUP軟體製程的開發公司,大部分都是「藍皮綠骨」──重視制度與管理,卻忽略了人本──而人本正是往覆式導入成功與否的關鍵,所以根本作不到往覆式開 發。

另外,關於「敏捷式(Agile)」、「極致軟體製程(XP,Extreme Programming)」、「RUP (Rational Unified Process)」的比較。我覺得Fowler在這部分道出開發流程的本質:流程僅是框架,只是建議、範本,不要以為導入某一開發流程就可以解決軟體的根 本複雜問題。我最喜歡書中的一個字彙:裁適(tailor)──要懂得裁減開發流程以符合專案的需要。

軟體系統的根本:結構分析與設計
UML最重要的一張設計圖就是類別圖(Class Diagram),Fowler最重視軟體的結構分析與設計,而這也是軟體根本所在──不從表象的需求看待系統的開發,而是直指核心,找出軟體的本質。

本書用兩個章節介紹類別圖,基本概念是介紹類別圖的基本語法,高等概念則是說明類別之間的關係,與關連類別、範本類別等比較少見的說明。要看這2 個章節,最好有物件導向觀念的基礎,如:什麼是物件、類別 (老實說,老手可能也不一定清楚物件與類別的區分)。高等概念不容易看懂,雖然只介紹語法,並沒有教你如何抓本質性的類別,那部分需要抽象高層次的悟性, 與IT技術沒有多大關連。

真要談到程式設計人員會關心的,反而不是類別圖,而是表達物件互動的序 (Sequence)圖。Fowler 提到集中式與分散式的控制設計方式,這裡他寫的很精彩。你會發現,Fowler不直接談集中式控制方式的缺點(事實上,這是最容易的開發方式,但嚴格說 來,它根本不是物件導向),他的說法是:「就是強烈要求寫集中控管的軟體人員採用分散式的設計風格,也不說明為什麼,但總有一天,他們會恍然大悟,這時 候,他們的腦袋將彷彿重生。」這真是最高段的損人不帶髒字。

系統的外觀:需求分析
針對需求分析,Fowler使用案例模型(Use Case Model)與活動(Activity)圖。使用案例模型包括案例圖與敘述,Fowler只簡單針對基本的語法作說明。在案例敘述這部分,他其實參考了 Cockburn的《Writing effective use cases》(使用案例寫作實務)。

他還特別提到:對於使用案例,請把自己的精力放在說明文字,而不是在圖上,使用案例敘述才是全部價值之所在。對於這段敘述,我不太同意,應該要先 釐清假設點:需求敘述對需求分析人員是最重要的;但是,案例圖則是軟體架構師的利器,用來界定系統開發範圍,區分內與外,決定那些要作、那些不作。

狀態圖與複合結構圖
Fowler很有意思,他覺得不重要的設計圖,大概就以一頁說明,再加上一張範例圖就結束。我把這些設計圖稱為「雞肋」── 食之無味、棄之可惜。

其中,狀態(State)圖與複合結構(Composite Structure)圖算是比較重要的設計圖。本書第三版改版最多的部分就是狀態圖的說明,狀態圖會與嵌入式系統設計或複雜的畫面狀態設計有相當的貢獻; 而複合結構圖則是UML 2.0規格最有價值的一張新視圖,它同時結合類別與元件(Component)圖的優點,來表達整體系統對外的介面,以及系統內部的結構組成元素。

這本書目前出到第三版,Fowler針對每一版本的制訂,並不只是新增補充,而是把他當下對UML的心得與體悟,重新編寫到新版本內,但還是只有「薄薄的一本」。

我三不五時仍會翻閱本書,新手看了本書,可以收穫甚多,而老手重新再看本書,仍會有不同的體會,這就是本書的精彩之處!

《作者簡介》王克明
台北工專五專部電子科畢業。現於HSDc軟體設計顧問團隊擔任架構師╱顧問╱講師。興趣為整體架構性的思考與學習、期貨投機操作與閱讀。

相關閱讀:
軟體設計必讀經典(2)物件導向分析與設計入門
軟體設計必讀經典(3)洞悉易學難精的Use Case

http://www.ithome.com.tw/itadm/article.php?c=44867
軟體設計必讀經典(2)

軟體設計必讀經典(2)物件導向分析與設計入門
文/iThome (記者) 2007-08-19

物件責任的分派很容易被忽略,卻很重要。若不重視這個部分,將導致行為分散,造成系統的混亂與複雜。


 UML與樣式徹底研究
 (Applying UML and Patterns)

 Craig Larman /著
 趙光正/譯
 培生出版
 售價:720元

翻譯自《Applying UML and Patterns 2nd edition》(目前已出至第三版)的《UML與樣式徹底研究》,是物件導向分析與設計最為暢銷的入門教科書之一,也是筆者踏入軟體設計領域的第一本書。

《UML與樣式徹底研究》的大綱架構,可說是最為標準的典型軟體工程式教科書。作者Craig Larman把他多年來豐富的教學經驗全都濃縮在本書內。第二版並導入UP(Unified Process)流程框架到大綱目錄內,讓讀者能大致掌握UP的 Milestone階段目標,與每次往覆(Iteration)的產出(Artifacts)。

系統開發的基本:了解需求
對軟體設計入門者而言,關於「需求」的討論是本書最有價值的部分。這本書是以需求作為系統開發的初端,再進而導出系統內部的結構分析、設計至實作 等。使用案例模型(Use Case Model)的建立,是功能性需求當中最重要、用來發掘並記錄需求的一種機制,它會影響到系統開發之後的諸多環節。

UP所倡導的「4+1 View」,即是以使用案例作為驅動,並且涵蓋整個專案的重心所在。

本書在使用案例敘述部分寫得相當好,同時也揭露多種不同的寫作格式與風格,讓讀者得以選擇適合的需求寫作方式。除了使用案例外,作者也介紹輔助規 格(記錄非功能性需求)、企業規則、字彙表、專案願景等其它功能需求,其實,這也是UP建議在需求製程的產出。參考範例的寫作方式不錯,但不要全盤照收, 以免造成不必要的儀式與負擔。

物件導向分析設計精髓:物件責任的分派
物件責任的分派(Responsibility Assign)是本書最精彩之處,也是其它書籍所看不到的。

對SA╱SD而言,責任的分派容易被忽略,相對來說卻最重要。要把軟體作「軟」,物件責任的分派是關鍵。舉例來說,誰負責訂購總額的計算?一般 SA並不重視這個,可能就寫在表單(Form)、Stored-Procedure,或者功能性的物件上,導致行為的分散,因此造成系統的混亂與複雜。

如何熟練指派責任是SA在物件設計中最重要的事,作者提出GRASP(General Responsibility Assignment Software Patterns)的設計原則,裡面提出5種重要的責任設計樣式。

其中,高內聚力(High Cohesion)與低耦合性(Low Coupling),決定了軟體核心的穩定性。但兩者也經常相互衝突,它們之間的關係,可比擬為軟體工程的陰與陽,互相牽制且彼此影響。

系統內部的靜態結構分析:找出物件
至於如何找出建構領域模型,進而產出軟體規格設計圖的部分,作者仍是以傳統的方式──找名詞,以歸納概念性類別。雖然他又列出概念性類別分類清 單,來協助SA找物件,但這仍不是個好方法,因為這是從需求的片段記錄來找尋物件,但需求並不穩定,相對來說,也不容易找出最具本質性 (Essential)的核心物件。

當初我在看這一部分時,著實疑惑甚久,後來閱讀了Peter Coad《Object Modeling》一書,揭露出以交易為核心,來找出本質性的領域物件的作法,才總算得到滿意的解決方案。

以POST系統開發案例,串連各章節觀念
後面幾個章節,一般的讀者其實可以忽略不看。例如:利用設計樣式設計出永續性框架(Persistent Framework)。由於.NET的ADO.NET, 以及J2EE的Hibernate等,都作得很好,我們只需學會如何使用即可。

總體而論,全書以一個POST系統開發為案例研討對象,包含需求分析記錄、領域模型建立、物件責任分派、系統規格模型設計等。讓讀者能透過案例跟著內容操作,將所有章節的觀念串連起來。

本書與《UML 精華》都是我鼓勵軟體從業人員必買的兩本好書,由於中譯本的翻譯品質甚佳,建議軟體公司都擺上一本,甚至舉辦讀書會鑽研一番。

《作者簡介》王克明
台北工專五專部電子科畢業。現於HSDc軟體設計顧問團隊擔任架構師╱顧問╱講師。興趣為整體架構性的思考與學習、期貨投機操作與閱讀。

相關閱讀:
軟體設計必讀經典(1)以簡約之道介紹UML最實用的部分
軟體設計必讀經典(3)洞悉易學難精的Use Case

http://www.ithome.com.tw/itadm/article.php?c=44992
軟體設計必讀經典(3)

軟體設計必讀經典(3)洞悉易學難精的Use Case
文/iThome (記者) 2007-08-26

使用案例(Use Case)運用簡單的圖形,加上文字敘述,建構出以使用者觀點檢視系統功能的模型。


 使用案例寫作實務
 (Writing Effective Use Cases)

 Alistair Cockburn/著
 趙光正/譯
 �峰出版
 售價:650元

使用案例(Use Case)是由Jacobson在易利信開發電信系統時,所發明的一種描述系統行為的工具,隨著UML規格的制訂,已成為捕捉需求最關鍵的技術。

使用案例可說是軟體界這十年來最了不起的創見,因為簡單。使用案例圖中,利用棒型人偶(參與者),表達系統的使用者與系統需要外部系統的支援服務,而橢圓 形的使用案例,即是表達系統所提供的功能服務;再以純文字寫作,描述每一個使用案例的需求陳述,可說是參與者與系統之間的互動對話,卻又不致於牽涉到系統 的實作面。簡單的圖形,加上文字敘述,建構出從使用者觀點看系統功能的模型。

不過,使用案例易學難精,如果沒有把握基本精要與原則,很難把圖給畫好(不容易界定出系統範圍),更何況是用純文字寫出需求陳述。

我對使用案例的技術相當著迷,但學習的前兩年完全無法體會它的本質精髓,直到閱讀了《Use Case Requirements in Context》,以及本文要介紹的《Writing Effective Use Cases》,才慢慢打開心眼。

腦力激盪的最佳工具──記錄需求、發掘需求
本書內容分為3大部分:使用案例的主體、相關議題的討論、寫作提示等。一開始閱讀會有些吃力,我建議要隨時翻閱目錄,了解自己在閱讀時的主題與焦點所在,若當下無法體會該章內容,其實跳過去也無妨。

本書第一部分讓你了解使用案例的本質,以及使用案例的寫作格式。作者Cockburn提供多種格式,如單欄/兩欄/RUP,甚至利用Occam程 式語言、圖形呈現的另類寫作風格。另外,作者自創的三個目標等級──白雲、海平面、海平面下,說明使用案例的精確程度,以及適合的目標層級對象,是該書第 一部分最有價值的內容。

第2部分屬於FAQ性質的主題性討論。例如常見的CRUD(Create、Read、Update、 Delete)與可參數化的使用案例該如何描述比較恰當;開發流程中,使用案例所扮演的角色與其它製程產出的關連性;撰寫使用案例常見錯誤……等,對於實 務上已經在運用使用案例的開發人員來說,相當具有參考價值。

第3部分是全書最實用的內容,第20章列出的使用案例相關寫作提示,就足以讓分析人員受用無窮。我看過多位系統分析師所寫的使用案例中常犯的錯誤,在本章都有提到。只要依循本章所列出的11個提示,寫出中規中矩的案例敘述,也就不難。

即使你寫的是中等程度的使用案例,本書仍然有相當的參考價值,事實上,只要使用案例具備可讀性,對整個專案就會有相當程度的貢獻;再者,使用案例不僅僅只是記錄需求的工具而已,它更可以成為專案成員的腦力激盪工具,發掘新的或潛在性的需求,這部分更是價值斐然。

順應國內短線專案型態──Use Case First
事實上,臺灣95%以上的專案都是功能導向的開發方式,至於系統內部的結構分析設計,由於時程壓縮,以及抽象基礎的素養不足,往往無法做好。

功能直接影響到專案能否被「做出來」;結構則是影響系統的彈性與穩定度。所以我主張應該「務實一點」,先順應國內短線的專案生態,利用使用案例,快速地對應到實作面。

在實際經驗中,這樣的效果與接受度相當高,雖然「Quick」,但可不「Dirty」。另外,有兩個配套措施是一定要做的:「測試案例到測試程 式」,以隨時驗證功能的正確性;「分析類別的規畫」,以符合3-tier 的MVC(Model-View-Control)框架。

在此之後,系統做得出來、開發能力顯著提升,老闆也就比較願意投入更多資源,再施以結構重整,慢慢萃取出系統最穩定、共用的部分。有了使用案例後,我似乎再也沒擔心過能否「做」得出來,因為那根本不是問題。

此書在Amazon是評價四顆半星的好書,猜猜中譯本賣多少錢?你可以在某書局以99元的價格購買!建議身為需求分析人員的你,用一到兩次便當錢的代價,買本可以讓你工作上獲益良多的好書。

《作者簡介》王克明
台北工專五專部電子科畢業。現於HSDc軟體設計顧問團隊擔任架構師╱顧問╱講師。興趣為整體架構性的思考與學習、期貨投機操作與閱讀。

相關閱讀:
軟體設計必讀經典(1)以簡約之道介紹UML最實用的部分
軟體設計必讀經典(2)物件導向分析與設計入門


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

備份占空間 刪除重複就有解+節省10∼20倍儲存空間的重複資料刪除技術+重複資料刪除技術竄起,廠商積極引進臺灣



http://www.ithome.com.tw/itadm/article.php?c=42964
備份占空間 刪除重複就有解

備份占空間 刪除重複就有解
文/ 許雅婷 (記者) 2007-04-17

訴求可將資料壓縮10倍以上的重複資料刪除技術,可節省硬體成本和提升管理效益,儲存廠商也紛紛看好此市場而競相跨入,現階段已有國內企業開始採用。


備受矚目的重複資料刪除技術於近年內迅速竄起,並受各家儲存廠商青睞,許多廠商在去年紛紛透過併購等方式獲得重複資料刪除技術,並將此技術視為今年的力推重點。

重複資料刪除(Data De-duplication)技術是將資料以演算法切割分段處理,經過比對分析後,將重複的資料剔除,因此可壓縮資料量,且由於重複資料刪除技術是和所 有已經儲存的資料進行比對,所以理論上,隨著時間越長,重複的資料比例也越高,得到的壓縮效果也越好。

在應用方面,重複資料刪除技術除了用於磁碟備份外,遠端複製和歸檔也是主要的應用,但現階段廠商所推出的產品,都是以縮減磁碟備份空間為主要訴求。

國內已有企業採用,壓縮比達9.4倍
一家金融業者在去年第四季便採用重複資料刪除技術產品,以應用在磁碟備份上。此金融業者備份政策為每周進行全備份、每天進行差異備份,從去年12月至今,備份累積的資料量約為1.6TB,但經過壓縮後容量約170GB,壓縮比約 9.4倍。

該企業原本僅用磁帶備份,因此採用磁碟備份後,備份架構也從D2T轉為D2D2T(Disk to Disk to Tape)架構,其線上、近線和離線儲存設備分別為NetApp FAS250、Data Domain DD410和Tandberg Autoloader LTO2,採用備份軟體CA ArcServ 11.5R。

麟瑞科技產品經理楊偉智表示,理論上,隨著資料越多,壓縮比會更高,長期來說,壓縮比可達20倍以上。

然而,一般廠商雖都宣稱壓縮比例平均為10∼50:1,但必須注意的是,壓縮比會受備份政策、資料類型影響,因此究竟可達到多少壓縮率,仍要視不 同情況而定。以備份政策為例,若企業全備份的頻率越高,資料重疊性越多,因此壓縮比也會越高,在資料類型方面,文件、電子郵件比起圖檔、影音檔,則可得到 比較高的壓縮比。

儲存廠商競相跨入,產品今年陸續到位
目前許多廠商已透過自行開發或併購方式進入此市場,包括Data Domain、NetApp都已推出基於重複資料刪除技術的產品,飛康國際(FalconStor)也預計在第二季推出採用該技術的設備,而賽門鐵克 (Symantec)收購DTC、Quantum收購ADIC,以及EMC去年年底買下重複資料刪除技術廠商Avamar後,產品都將於今年陸續到位。

EMC資深產品行銷經理李百飛表示,資訊量的成長速度只會越來越快,而同一份資料會有多份副本,或者被儲存在不同設備上,因此造成儲存空間浪費, 但重複資料刪除技術能有效解決儲存浪費的情況,根據研究機構Taneja Group日前所做的報告也指出,重複資料刪除技術將會是未來3年引領儲存市場變革的重要技術。

楊偉智表示,除了硬體成本的節省之外,採用重複資料刪除技術更大的效益是在於管理的成本,原本可能需要十幾臺甚至數十臺的設備才能承載的容量,經過壓縮後則僅要一臺設備就可解決,不僅管理方便、占用空間少,且硬碟數量少,相對來說損壞的機率也較低。

另一方面,若將重複資料刪除技術用於遠端複製,除了能減少儲存容量外,還能降低網路頻寬的使用,以Symantec的重複資料刪除產品 NetBackup PureDisk來說,便是鎖定遠端複製應用。Symantec技術顧問陳力維表示,有進行異地備份的企業便可能有這樣的需求。

重複資料刪除技術結合VTL,需求有待觀察
值得一提的是,許多廠商也計畫將重複資料刪除技術應用在虛擬磁帶櫃(Virtual Tape Library,VTL)上,目前Data Domain就可提供企業將該儲存系統虛擬成磁帶櫃的方案;飛康國際的SIR,是將軟體整合在一臺專屬硬體設備上,做為自家VTL的延伸方案;EMC除了 將推出單獨做為磁碟備份的方案外,還會推出結合VTL的方案;NetApp也預計在下半年將重複資料刪除技術也應用至該公司的VTL上。

必須注意的是,若要採用重複資料刪除技術,可能會影響到現有作業的效能。NetApp去年年底將重複資料刪除技術內建於FAS3000系列,並於 日前再將此技術應用至FAS6000、NearStor R200產品上。NetApp臺灣系統工程師姜群表示,採用重複資料刪除技術,由於必須進行比對和刪除的作業,因此線上儲存效能會稍有影響,所以這樣的方 案適合以空間為第一優先考量的客戶選用,但他認為目前國內企業的資訊量還不夠大,因此需求尚少。

FalconStor行銷經理張智鴻則表示,由於該公司的SIR是以先備份後刪除的方式進行,因此不會影響作業效能,而先備份後刪除,雖然備份時間差異不大,但還原的速度會加快許多。文☉許雅婷

主要儲存廠商紛紛跨足重複資料刪除技術

廠商 廠商動態
DataDomain於2005年年底將基於COS(Capacity Optimized Storage) 技術的DD400系列儲存伺服器進入臺灣市場,並委由麟瑞科 技代理,現階段已有國內企業採用。
EMC 去年年底收購Avamar獲得該技術,今年將開始在臺銷售, 除了將以磁碟備份方案銷售外,還將搭配自家的VTL銷售。
FalconStor預計在第二季前發表一款基於重複資料刪除技術的Single Instance Repository(SIR)設備,是與自家VTL搭配銷售。
NetApp去年年底先將重複資料刪除技術用於FAS3000系列儲存系統 上,並於日前將此技術再應用至FAS6000、NearStor產品 上,為免費內建工具,計畫於今年下半年會將該技術與自家 VTL產品結合。
Quantum去年收購ADIC獲得該技術,日前新增DXi產品線,推出 DXi300、DXi500兩款設備,國內由零壹科技代理,預計第 二季前引進臺灣。
Symantec前年年底收購DTC獲得該技術,去年年終發表NetBackup PureDisk 6.0 軟體,並於日前正式在臺發表,預計今年開始 在臺推廣。


相關閱讀:
節省10∼20倍儲存空間的重複資料刪除技術
重複資料刪除技術竄起,廠商積極引進臺灣

http://www.ithome.com.tw/itadm/article.php?c=38018
節省10∼20倍儲存空間的重複資料刪除技術

節省10∼20倍儲存空間的重複資料刪除技術
文/張明德 (記者) 2006-06-29

面對日趨膨脹的資料量,無限制的添購硬碟肯定會讓企業難以承受,透過重複資料刪除技術能去除冗餘資料,節省儲存空間,進而降低儲存成本。


隨著分層儲存(Tiered storage)應用的日漸普及,透過區分資料類型並分別存儲在不同的媒體上,已成為當前企業提高備份效率、降低儲存成本的主要做法。典型的應用就是磁碟 到磁碟再到磁帶(D2D2T)的三層架構,透過中介的低價SATA磁碟,作為前端高速但價昂的FC、SCSI硬碟,以及後端價廉但速度慢的磁帶間的緩衝, 以兼收速度與降低成本的效益。

但業界在實際的D2D2T應用中發現,由於經常性的檢索與快速還原資料的需求,中介緩衝的硬碟容量需求直線升高。在早期的應用中,從線上搬移到中 介緩衝硬碟的資料,一般只會停留一周的時間,很快就會被轉存到後端的磁帶上。但現在的用戶卻經常讓資料存放在中介緩衝硬碟上達數周甚至數月之久,使得中介 緩衝硬碟的容量需求大增。

雖然SATA硬碟的價格不斷降低,但是單位成本仍比磁帶高出許多。面對日趨膨脹的資料量,如果用戶堅持將大量資料存放在硬碟上達數周之久,無限制 的添購硬碟顯然不是現合理的做法,高昂的儲存成本肯定會讓企業難以承受。因此以縮減資料容量、減少磁碟儲存容量需求為的重複資料刪除(Data De-duplication)技術也就應運而生。

解析資料刪除技術

 

重複資料刪除技術的關鍵在於如何透過對掃描磁碟資料,判斷資料是否為「重複」或「冗餘」,各家廠商在實作細節上雖有不同,但原理大致上都是對寫入 硬碟的資料以演算法(例如Hash)切割分段處理,分段的單位可以是區塊(Block)或是區段(Segment),並為每一個分割單位求出一個特徵 值... 繼續閱讀

技術領導者:小型新創企業

 

重複資料刪除技術是一項新興技術,目前這個領域的開路先鋒多半是小型的新創企業,如Asigra、Avamar、Data Domain、與Rocksoft等,大廠方面則有ADIC、Symantec與微軟等。依產品針對的應用範圍不同,可分為純軟體與應用程式伺服器兩 類...... 繼續閱讀

透過特殊演算法去除資料中的冗餘
重複資料刪除技術依廠商的不同而有不同的名稱,包括單實例存儲(Single-Instance Storage)、共同性分解(Commonality Factoring)、全域壓縮(Global Compression)、容量最佳化(Capacity Optimization)或資料合併(Data Coalescence)等稱呼,不過目的與原理都是相同的。

重複資料刪除技術的關鍵在於如何透過對掃描磁碟資料,判斷資料是否為「重複」或「冗餘」,各家廠商在實作細節上雖有不同,但原理大致上都是對寫入 硬碟的資料以演算法(例如Hash)切割分段處理,分段的單位可以是區塊(Block)或是區段(Segment),並為每一個分割單位求出一個特徵值, 特徵值是利用演算法得出的一個很小、但是又可以代表此區塊的資料,如同每個人的指紋可以用來代表一個人一樣,也叫做訊息摘要(message digest)或數位指紋等(digital fingerprint)。

所有後續資料在寫入硬碟時也都會先經由演算法的處理,並得出特徵值,接下來系統就可比對硬碟中已有資料的特徵值與新寫入資料的特徵值,若發現特徵 值相同,則系統就會知道硬碟上已有一個相同的副本,這筆新資料即為「重複」,那新資料將只會存入一個指向已有副本位址的指標,而不會重複儲存,只會為這筆 資料留下一個索引,標註指向硬碟上已有的那份副本,而不會實際寫入硬碟。只有特徵值不同的資料才會被實際寫入硬碟。

而這些演算與寫入程序是不對外透通的,就外部的作業系統與應用程式看來,資料的存取仍與平時完全相同,當使用者要讀取那些被判定為重複的資料時,系統就會透過之前建立的索引把資料取出。
也就是說,原來的完整資料經重複資料刪除技術後,被化為許多個完全是唯一(unique)、不重複的資料區塊,以及紀錄原始資料結構與指向的索 引,這個「多個唯一、不重複的資料區塊」加上「紀錄原始資料結構與指向的索引」,對作業系統與應用程式看來是等同於原始的完整資料,只要反向運作就能得回 原來型態的資料。

重複資料刪除技術的三大類型
依處理流程、運作架構以及對原始資料進行分段方式的不同,重複資料刪除技術有以下幾種不同的區分:

1.in-band與out-of-band
依處理流程可分為即時的in-band與非即時的out-of-band兩類。in-band的系統是在資料寫入磁碟之前作重複資料刪除演算與處 理;而out-of-band則是在資料已經寫入磁碟後,再作重複資料刪除演算處理。兩種處理方式的優缺點正好相反,in-band的方式對磁碟存取的效 能影響較大,系統的性能會有所降低。而out-of-band雖不會影響到即時的存取效能,但由於資料一開始寫入磁碟時仍完全未經處理,需佔用與原始資料 相同大小的空間,要等到寫入完畢、經重複資料刪除演算處理後才會縮減容量,因此對磁碟容量的需求較高。所以in-band與out of band也就是一個效能與儲存容量間的選擇。不過為追求容量縮減的效果,絕大多數的產品都是採用in-band的方式作業。

2.前端代理程式與後端專屬硬體
而就架構上而言,重複資料刪除技術有在前端透過代理程式執行,與在後端透過專屬設備執行兩類。前者即是在前端的個人電腦或伺服器上安裝代理程式, 透過代理程式來對個人電腦或伺服器上指定的資料區域進行分割演算與去除冗餘資料的處理,然後再送到遠端伺服器上備份。需要取回資料時再反向運作,重新組回 原始資料的型態,如Avamar、ADIC、Asigra、Symantec等公司都是採用這種做法。採這種方式的多半是純軟體類產品,對系統的需求較 高、部署上比較麻煩,而且代理程式會影響到前端各系統的效能。不過由於資料在前端系統上就已經過重複資料刪除處理,只有新產生的不同資料才會傳往後端,所 以需要的網路頻寬很小。

另一類就是完全不對前端系統作動作,把所有的重複資料刪除演算都放到後端的一臺專屬設備上處理,也就是把這臺專屬設備當作一個儲存裝置,前端的資 料儲存再指向這臺設備,當資料送到這臺設備上準備寫入硬碟時,才由這臺設備進行重複資料刪除處理。顯然的,這種架構把演算處理的負擔丟給後端的專屬設備, 因此對前端系統不會造成任何負荷,不過也由於重複資料刪除處理是在後端,所以前端的資料在從網路送往後端時,仍是以原始的型態與大小傳送,網路負荷相對會 比前一種方式大許多。屬於這類架構的產品有Data Domain的COS系列儲存伺服器產品,以及Diligent的虛擬磁帶櫃等。

另外這種後端處理也有其他的優點,因為所有的資料搬移動作都是透過第三方備份或複製軟體來進行,因此這類產品可以迴避與資料庫間的溝通問題,只要備份軟體能支援資料庫,那這類產品也能用於資料庫備份,不像代理程式類產品必需考慮與資料庫間的驗證問題。

3.資料分段切割方式與大小
目前重複資料刪除技術的演算法在切割資料、進行分段求解特徵時的做法有兩類,一類是以區塊(Block)為單位來切割,如Avamar的 Axion是將資料切為平均12KB大小的區塊,再分別為每個區塊計算並分派1個20byte的特徵值(或是稱為固定位址)。另一類則是以區段 (Segment)為基礎,如Data Domain的COS是將資料以Byte為單位為分解成4∼16KB的區段(平均8KB),再進行處理。

系統是採用區塊還是區段等級的處理沒有一定的好壞,不過資料分割的片段大小會有比較大的影響。同樣大小的資料若切成較小的片段,意味著系統需要產 生並存放更多的特徵值以及索引,將會延緩備份的時間;但若切成較小的片段,則系統也能對資料內容進行更精細的比對,通常可以得到更高的壓縮比率。目前多數 產品的分段大小都是可調的,系統會嘗試以多種分段大小來切割資料,以求得到更好的資料冗餘判斷結果。

節省儲存空間,進而節省成本
依廠商的宣稱,原始資料經過重複資料刪除技術的處理後,可得到高達10:1到50:1的資料壓縮率,某些情況下還會有更高的比率。由於重複資料刪 除技術的分析比對是對所有已儲存資料與新產生資料持續進行的,除非該環境的資料差異性非常大,否則隨著時間的延長,執行資料分段比對與冗餘處理的次數越 多,則得到的壓縮效果也就會越高,當然實際的壓縮效果需視資料型態而定。

雖然重複資料刪除技術宣稱能透過降低硬碟空間進而節省儲存費用,但這項技術本身也需要一定的成本才能取得(而且還不便宜),因此只有儲存容量需求 超過一定限度,這項技術節省的容量花費抵消其本身的費用後,整體的成本降低效果才能顯現。依表1的估計,假設提供的「可用」儲存空間均相同時,只要重複資 料刪除技術的壓縮比達到10:1,就能降低25∼50%的單位儲存成本;若壓縮比為15:1,則單位儲存成本就能比不使用時降低1倍以上;如果達到20: 1以上的壓縮比,則重複資料刪除技術所需的單位成本就能降低到甚至比磁帶還低的程度,此時改用硬碟來取代磁帶來作為資料的最終儲存媒體,就會有相當的競爭 力。

然而不管是哪一類型的技術,由於系統在每次寫入資料時,都要對所有的資料進行分段演算與特徵值校驗,無論這個演算是在前端機器、還是再後端專屬設 備上執行,就整個系統的存取效能來說還是會造成負面的影響,一定還是會比直接寫入磁碟的方式慢上許多。因此只適用於較不要求效能的近線儲存,如VTL、固 定內容儲存等應用,而不適用於即時儲存環境。文☉張明德

備份緩衝與歸檔是主流應用

如內文所述,由於重複資料刪除技術會影響系統的存取效能,因此不適於對性能要求較高的線上即時儲存環境,但對作為中介緩衝的近線儲存、郵件、檔案歸檔等應用來說,就能充分發揮其節省容量的好處,而又不會暴露出減損存取效能的缺點。目前主要的應用範圍有以下三方面:

備份緩衝磁碟、近線儲存與虛擬磁帶櫃(VTL)
也 就是應用在分層儲存中的第2層儲存裝置上,透過重複資料刪除技術,將能使得儲存容量大幅提高,對備份緩衝磁碟與虛擬磁帶櫃來說,由於可容納的資料量提高, 因此使用者原來每隔幾天或每週就需要執行一次的轉存(磁帶)作業,可改為間隔1個月甚至是半年之久,除減輕管理壓力、降低緩慢的磁帶轉存作業對系統帶來的 衝擊外,由於留存在硬碟上的資料量增多,也提高了資料還原或檢索的速度,降低從眾多備份磁帶中找尋資料的機率。目前絕大多數的重複資料刪除技術產品都是針 對這個應用領域,如ADIC、Diligent、Data Domain與Sepaton等都是將產品結合二級儲存或VTL銷售。

遠端備份儲存
某些廠商如Asigra、Symantec等的重複資料刪除產品是鎖定在遠端備份的應用,透過在前端的重複資料刪除技術來大幅降低備份的資料量,從而減輕網路頻寬需求。這類產品其實可以看做是一種附加了重複資料刪除技術的備份軟體。

郵件歸檔與固定內容儲存
對 於郵件、數位X光片、票據等依法律規定不可刪改、非經常使用,但又必須被儲存的固定內容(Fixed Content)資訊來說,重複資料刪除技術也有很大的應用潛力。由於這類資訊依法規定不能刪改,資料量會隨著時間而不斷增長,消耗的儲存資源也越來越 大。因此重複資料刪除技術在這個領域將可大展所長,除縮減空間需求外,由於重複資料刪除技術是透過每個資料分段的特徵值與索引來辨識與檢索資料,免除傳統 檔案系統須在邏輯位址與實際區塊的物理儲存位址間轉換的麻煩,因此也能提高資料定位與檢索的效率。其實在2年前EMC發表針對歸檔市場的Centera 時,所宣稱的固定內容尋址(CAS)技術就具備與重複資料刪除十分類似的單實例儲存特性。而HP在其歸檔產品RISS剛發表的 1.5版中,也增加了區塊級的單實例儲存功能,宣稱可提供3∼5倍的資料壓縮,將每TB儲存成本將低到原來的1/4。


小型新創企業領導重複資料刪除技術

重複資料刪除技術是一項新興技術,目前這個領域的領導廠商多半是些小型的新創企業,如Asigra、Avamar、Data Domain、與Rocksoft等,大廠方面則有ADIC、Symantec與微軟等。依產品針對的應用範圍不同,可分為純軟體與應用程式伺服器兩類:

使用彈性大的純軟體產品
純軟體類產品的運用方式主要是在備份方面,如Asigra與Avamar都是將重復刪除技術整合在其Televaulting與Axion備份軟體中,而 Symantec去年併購DTC取得重復資料刪除技術後推出的NetBackup 6.0 PureDisk也是鎖定在遠端備份。

比較特別的是微軟在剛推出的Windows Storage Server 2003 R2上也新增了單實例儲存功能,不過WSS R2不直接提供給終端用戶,而是搭配儲存廠商的硬體一起銷售。

應用伺服器產品便於部署
應用伺服器類的產品以Data Domain最為典型,Data Domain是將其產品包裝為儲存伺服器或閘道器,使用時只要在備份軟體下將儲存目標指向Data Domain的伺服器即可。另外Diligent去年推出的ProtectTier系列、以及ADIC的PathLight VX VTL也採用類似的架構,這些產品都是包裝成VTL伺服器,只要接上儲存網路即可提供重覆資料刪除服務。比較特別的是Sepaton同時有 DeltaStor獨立軟體以及與VTL伺服器結合的S2100-ES2應用伺服器,針對的是高階的企業用戶。

不過,業界並非一致看好重複資料刪除技術,隨著垂直寫錄技術的採用,新一代的硬碟在單位儲存密度與成本方面將有持續的突破,連帶也會影響到企業採 用重複資料刪除技術的意願。另外對EMC、IBM、HP這類同時擁有軟、硬體產品線的儲存大廠來說,由於重複資料刪除技術將促使客戶減少在儲存容量方面的 投資,顯然會影響到其硬體產品方面的銷售,因此對投入這個領域將會存在相當疑慮,實際上目前這個領域的廠商也多為不需背負硬體銷售包袱的廠商為主。文☉張 明德

http://www.ithome.com.tw/itadm/article.php?c=39314
重複資料刪除技術竄起,廠商積極引進臺灣
文/許雅婷 (記者) 2006-09-08

重複資料刪除技術主要是將資料以演算法切割分段處理,經過比對分析後,將重複的資料剔除,因此可壓縮資料量,廠商宣稱,資料壓縮率可高達10:1。


隨著資料量不斷激增,資料所占據的空間也越來越大,而企業也必須添購更多的儲存容量,因此,重複資料刪除技術(Data De-duplication)便因蘊而生,標榜藉由剔除重複性資料,以達到節省空間的效益。

目前許多廠商已經紛紛在產品中導入重複資料刪除技術(不同廠商所制定的名稱則不盡相同),並在國外推出採用該技術的產品,而近一年內,廠商也積極將產品推到臺灣市場。

Data Domain在去年年底開始將COS(Capacity Optimized Storage)系列儲存伺服器引進臺灣,並在今年新增代理商麟瑞科技,年底則預計會推出新版作業系統和設備。賽門鐵克(Symantec)去年併購 DTC取得重複資料刪除技術,隨後推出NetBackup 6.0 PureDisk軟體,並計畫在今年第4季引進臺灣;飛康國際(FalconStor)在稍早前發表一款基於該技術的Single Instance Repository(SIR)軟體,也預計第4季時會在臺正式發表。

重複資料刪除技術主要是將資料以演算法切割分段處理,經過比對分析後,將重複的資料剔除,因此可壓縮資料量,而且由於重複資料刪除技術是和所有已 經儲存的資料進行比對,所以理論上,隨著時間越長,重複的資料比例也越高,得到的壓縮效果也越好。廠商宣稱,資料壓縮率可高達10:1,長期而言,更可能 達50:1,不過實際上仍要看資料本身的類型而定。

在應用方面,主要有磁碟備份、虛擬磁帶櫃(Virtual Tape Library ;VTL)、遠端備份和歸檔等,而隨著應用不同,各家廠商鎖定的族群和作法也不同,有些是以純軟體銷售,有些則將軟體整合在硬體設備上。

以Data Domain的COS儲存伺服器而言,便是鎖定在D2D2T(Disk-to-Disk-to-Tape)架構下的磁碟備份應用。Data Domain高級系統工程師盧廷偉表示,企業若要增加一層磁碟備份設備,往往會將資料存放一段時間後再做刪除,時間可能達數周或數月,因此所需的空間量就 會大幅提升。若是藉由重複資料刪除技術,企業就可添購較少容量的設備,不僅可節硬碟成本,也可帶動企業增加磁碟備份的意願。此外,COS儲存伺服器也在今 年開始增加對虛擬磁帶櫃的支援。

FalconStor的SIR與Data Domain的做法則類似,是將軟體整合在一臺專屬硬體設備上,並能與自家的虛擬磁帶櫃整合。FalconStor表示,由於SIR和VTL為獨立的設 備,因此不會有降低效能的疑慮,此外,SIR內含重複資料刪除(RDE)引擎,讓使用者可從設備上快速復原檔案,另外,也適用在遠端備援的應用上。

有別於Data Domain和FalconStor,Symantec的重複資料刪除產品則是鎖定遠端備份應用。臺灣賽門鐵克技術顧問經理李松濱表示,企業資料量越大,使用重複資料刪除技術可呈現的效益越高,因此Symantec主要會鎖定大型企業用戶。

李松濱進一步表示,將重複資料刪除技術用於遠端備份,除了減少儲存容量外,由於是將資料壓縮後再傳送,因此也能降低網路頻寬的使用。

此外,惠普的歸檔產品RISS中,也有導入重複資料刪除技術,除了提供郵件歸檔外,也在最新1.5版本中納入對資料庫和檔案的支援。其他廠商包括ADIC、Diligent、Sepaton等也有推出該技術的產品。

臺灣惠普企業系統事業群網路儲存解決方案事業處儲存方案產品經理蕭舜華表示,以電子郵件為例,相同的郵件可能會存放在不同的檔案夾中,因此同樣的郵件就會有好幾份,所以會耗損許多空間,若能透過重複資料刪除技術,就能讓容量更有效使用。文☉許雅婷


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!

Exchange Server 2007變身通訊總樞紐



http://epaper.pchome.com.tw/archive/last.htm?s_date=old&s_dir=20070424&s_code=0004&s_cat=

http://www.ithome.com.tw/itadm/article.php?c=42985

Exchange Server 2007重裝上陣
文/吳其勳 (iThome電腦報副總編輯) 2007-04-23

Windows Vista及Exchange Server 2007都稱得上是微軟產品大躍進的重要里程碑,其中Exchange Server新版本更做到了以往所缺乏的通訊整合,因而大受青睞。


今年初,在我們採訪企業如何看待微軟最新的Windows Vista作業系統時,研華公司的資訊主管說,他們目前毫不考慮Windows Vista,但對於微軟在同一時刻發表的Exchange Server 2007,卻有極高的興趣,他們已經在測試新版本了。

在Windows Vista與Exchange Server 2007的發表會上,參與者的反應亦是如此,對於較為華麗的Windows Vista介面,頂多只是讚歎,但在看了Exchange Server 2007整合通訊的示範──透過電話就能控制郵件與個人行程,聆聽郵件與行程內容,多數人應該就開始推想了,這些整合通訊的功能加到企業�,應該會構成什 麼樣的應用。

研華公司打算建構行動化辦公室,提升運作效率,而Exchange Server 2007所強化的行動郵件與整合通訊,就正好符合他們的需要。

雖然Windows Vista及Exchange Server 2007都稱得上是微軟產品大躍進的重要里程碑,但企業已經滿足於Windows XP的功能,毫無升級的動力;Exchange Server新版本則做到了以往所缺乏的通訊整合,因而大受青睞。

雖然,國外媒體分析Exchange Server 2007新增的功能固然不錯,但有需要的企業早已尋求其他的解決方案了。不過,在臺灣企業的狀況卻不盡如此,本期封面故事,我們分析Exchange Server 2007新增的諸多功能,以及如何藉由Exchange Server 2007來整合企業的通訊架構。由於Exchange Server 2007改變不小,升級需要注意,請見本期封面故事──「 Exchange Server 2007重裝上陣」的分析報導。

安全與便利一直是相互抗衡的因素。企業為了要保護資料,製作了諸多備份資料,卻也面臨儲存空間不足的問題。若要做到完善地備份資料,以及快速地復原資料,那麼全備份是最好的方法。但是,每天都製作全備份,備份資料的成長量勢必相當驚人,儲存空間耗用極快。

於是,大多數的企業都會採取差異備份的策略,在每一次備份周期的起始先製作全備份,期間再備份資料遞增的差異部分,當然在復原資料時,就必須逐一回復全備份及所有的差異備份,所需時間自然是比起全備份要來得多。

多數企業不得不採取差異備份,畢竟全備份太占儲存空間了,將使得資料保護的成本大為提升;不過,有些企業在某些關鍵應用上,卻不得不採取全備份,所幸,現在有一項新技術可以抒解既兼顧資料安全防護,又要減緩儲存空間倍增的困擾。

這項技術稱之為──「重複資料刪除技術」,藉由刪除重複性資料,來節省儲存空間。以每日執行全備份來說,每一份備份資料中,即有相當大比例的重複,以重複資料刪除技術來說,就可以不讓這些重複的資料占據儲存空間。

我們在去年已經報導這項新技術,當時主要是幾家新創公司在研發,不過,今年已經有多家儲存廠商,或藉由購併、或自行研發推出這項技術,而且,在臺灣已經有企業開始將重複資料刪除技術運用在磁碟備份。

重複資料刪除技術目前最主要的應用以資料備份為主,雖然目前受限於效能考量而較少應用於線上儲存,不過,這項技術的興起,已經對於未來資料累積量即將超越儲存空間的困境,指引出一個新的方向,請見本期的 新聞報導

http://www.ithome.com.tw/itadm/article.php?c=42986

Exchange Server 2007變身通訊總樞紐
文/ 羅健豪 (記者) 2007-04-23

時至今日,Exchange已經不只是代表傳送郵件的伺服器,更是能夠提供整合企業內部協同作業的主要角色。


2000年11月 2003年9月 2006年12月
Exchange 2000Exchange 2003 Exchange 2007

>>>微軟郵件與協同作業系統發展年表

企業的通訊管道越來越多也越複雜,為了整合這些管道,企業往往需要付出相當大的成本與人力,安裝不同廠商的設備,以建置並維持正常運作,有時候也不能完全達到想要的目標。

但微軟認為在推出Exchange 2007之後,這些狀況會得到改善,並且更有效率。Exchange Server 2007分為集線傳輸、整合訊息、郵件信箱、用戶存取與邊緣傳輸等5種角色,各自負責郵件分類傳輸、接取語音及數據通訊、儲存各項訊息資料和提供用戶存取 通道等功能,邊緣傳輸伺服器則位於組織外部,與其他角色不同。這些角色讓Exchange Server 2007管理更簡單,應用更廣泛,使用上更安全便利。

通訊整合、行動郵件、備份歸檔、過濾SAPM一次到位
除了延續先前Exchange的功能之外,Exchange 2007也添加了不少新功能,讓Exchange 2007在整合通訊與機動性、資訊安全、訊息保護及管理效率等4方面,有著令人耳目一新的感覺。

整合VoIP與多種存取管道,讓訊息交換更密切
整合企業目前所有的通訊管道與方式,融入Exchange 2007與Active Directory的管理之中,藉由單一功能伺服器簡化使用者的操作步驟,並提供強而有力的用戶端軟體。

增強垃圾郵件過濾,提高防毒效能
Exchange 2007中新增加的反垃圾郵件機制可以過濾收件者、寄件者與IP位址,也會參考網路上RBL清單,阻斷已知的垃圾郵件業者IP位址,藉此可以解決大多數的郵件。

新管理介面讓操作更方便
對於習慣使用命令列的管理者而言,新的介面很方便愉快,對習慣使用圖形化介面的管理者來說,雖然操作上稍微困難了點,但是搭配上良好的指令與步驟說明,就算是初學者也不會感到太困難。

功能雖強大,導入前應妥善考慮
導入Exchange 2007之前,企業首先需要留意的就是32位元與64位元上軟硬體的問題。

達成永不停頓的郵件系統
Exchange 2007中提供多項高可用性技術,最重要的2項技術就是本機連續複寫(LCR)與叢集連續複寫(CCR)。

整合資訊網路與電信網路的整合訊息架構
藉由整合訊息角色,微軟將整合訊息架構的重心放在Exchange 2007上,讓使用者僅需單一應用程式或裝置,就能夠存取所有訊息。

通訊整合、行動郵件、備份歸檔、過濾SAPM一次到位
微軟的Exchange Server(以下簡稱Exchange)與IBM的Lotus是企業內訊息交換與協同作業的兩大主流,以Radicati Group在2006年度的調查來看,有一半以上的受訪者採用這兩套系統作為訊息平臺,其中採用Exchange做為平臺的更是佔了31%,企業內部頻繁 的訊息交換,藉由這兩種平臺而得以順暢地進行。

許多人對Exchange的第一印象,就是負責傳送郵件的伺服器,但其實Microsoft Mail這套產品才是專門負責處理郵件,它最後版本為1995年推出的3.5版。第一套Exchange的版本為4.0版,到5.5版推出後,才正式導入 了目錄架構的概念,這項概念也就是Active Directory的原型。Exchange系列產品除了提供郵件交換的功能之外,還加上訊息傳遞、名單派送與公用資料夾等功能,是企業內部協同作業的初 衷。

早期的Exchange功能並不完全到位,並且需要多種用戶端軟體才能完整使用Exchange所提供的功能,一直到1997年11月推出Exchange 5.5之後才算是底定,整合結果也就是現在我們所看到的Exchange與Outlook互相搭配的所有功能。

Exchange系列其實在很早之前就提供多項有用的功能,包含我們所看到的Outlook Web Access、行事曆及公用資料夾等,現在這些功能看來稀鬆平常,但是在當時卻是相當大的創舉。Exchange系列也一直不斷改善用戶端的操作感受,並 提供多樣的個人功能;而在企業端,也藉由公用資料夾與表單等項目,整合企業內部的操作模式與流程,讓溝通更順利。

Exchange 2007的新改變
時至今日,Exchange已經不只是代表傳送郵件的伺服器,更是能夠提供整合企業內部協同作業的主要角色。新一代的Exchange 2007在硬體上就有完全不同的需求,在這個版本中,正式營運伺服器建議使用64位元架構的設備,測試或教學則使用32位元的設備。

這是因為64位元的硬體架構可以讓Exchange 2007發揮最大效能,而不會受到4GB記憶體上限的硬體限制。不過相對的,企業也需要考量64位元設備的支援性是否良好,避免硬體升級之後反而造成維護上的問題。

除了延續先前Exchange的功能之外,Exchange 2007也添加了不少新功能,可說是近年來微軟在訊息與協同作業項目中重要的里程碑。這些新功能讓Exchange 2007,在整合通訊與機動性、資訊安全、訊息保護及管理效率等4方面,有著令人耳目一新的感覺。

訊息交換並不侷限於企業內部,外部員工也需要取得總公司內的相關訊息,這時候就需要整合其他軟硬體廠商提出的解決方案,並且為了降低使用難度,必須要使用共通的通訊協定,無論是建置或是管理,對資訊管理人員來說,一直都是相當大的難題。

在整合通訊與機動性上,Exchange 2007不但搭配日趨成熟的Outlook與OWA,讓用戶端存取資料更便利;更加強與VoIP環境的整合能力,讓電信網路上的語音留言及傳真,能夠融入 電子郵件訊息系統之中,使用者只需要單一窗口能得到所有資訊,完成整合通訊的理想。

整合通訊並非新名詞,事實上硬體廠商已開始推動的「Triple Play」,希望整合數據、語音及影像的方式,而微軟的策略和上述方式不盡相同,他們的整合通訊功能主要是以Exchange 2007為主,讓行動工作者可以使用不同裝置,透過不同的方式存取訊息。

這種改變讓採用Exchange 2007的企業,可以將工作範圍有效的延伸至外部網路,並且縮短使用者的反應時間,讓溝通更方便。整合通訊可以區分成語音與數據整合及行動能力增強等2個部分,這兩部分並非缺一不可,可以分頭進行。

導入VoIP架構之後,就可以整合電信與數據網路,並透過Exchange 2007作為通訊樞紐,無論是PC-to-Phone或是Phone-to-Phone,都可以使用Outlook操作。

如果再搭配上Live Communications Server(LCS),還可以將通訊範圍延伸至即時通訊網路上,無論是語音、郵件或即時通訊都暢行無阻。LCS不但可以提供良好的機動性,同時也可以提 供加密且受管理的溝通管道,確保安全無虞,並且能符合各項法律規範。

Exchange 2007也會透過目錄服務,驗證企業員工所寄發的電子郵件,能夠在郵件上加入特殊的電子簽章,讓收件方可以檢查並驗證信件的真實性。在雙方Exchange上都安裝憑證的情況下,更可以透過PKI機制加密傳遞通道,讓竊聽者無從下手。

而藉由Forefront Security for Exchange Server的協助,Exchange 2007就能夠在伺服器端直接過濾病毒、蠕蟲與垃圾郵件,不需要其他第三方軟體或硬體設備輔助,除了能夠降低架構複雜度之外,也可以降低單點錯誤發生的機 率。防範垃圾郵件的機制也是本次新版本的重點之一,除了讓Outlook內建的垃圾郵件篩選器辨識垃圾郵件之外,從伺服器端直接分類可以增強使用者的好 感,因為這些分類技術除了可以區辨垃圾郵件之外,更可以協助企業與使用者分類各種郵件,便於訊息歸檔與儲存。

既然能夠有效地將訊息分類歸檔與儲存在伺服器上,伺服器的資料備分與還原就更為重要了。在Exchange 2007中,也新增了本機與叢集架構可使用的連續備分技術,能夠加速備分並減少錯誤發生,也同時能夠縮短還原時間,確保訊息記錄不會有中斷期。

藉由這些功能,可以讓企業資訊交換範圍,有效地延伸到外部網路;解決垃圾郵件問題之外,更提供郵件加密及身分檢核功能;提供良好的歸檔及保護措施,便於日後檢索及備分還原所需;更進一步提供整合的管理介面,讓管理Exchange更為簡單。

另外在Exchange 2007中,可以定義不同的傳輸規則,並在寄發信件時檢查並處置。例如主動插入企業免責聲明、更改含有關鍵字的主旨或內容、強制退信並告知違規事項等措施,根據企業規範打造一道「道德牆」,避免員工在無意之間違反各項規定。

與Exchange 2007相關的微軟產品簡表

產品名稱 負責項目 功能說明
Live Communications Server / Communicator 整合訊息 專屬企業內部使用的即時通訊系統,使用操作上與免費的MSN Messenger類似。
SharePoint Portal Server 整合訊息 結合Exchange 2007之後,可提供良好的訊息平臺,讓使用者可以在網頁上存取各項訊息。
Forefront Security for Exchange Server 訊息安全 與Exchange 2007共同安裝在Windows Server 2003上,可過濾病毒、蠕蟲及垃圾郵件,加強安全性。
Windows Mobile 整合訊息 用戶端作業系統,藉由ActiveSync讓行動工作者使用手持裝置與Exchange 2007連線。
ISA Server 訊息安全 可作為Exchange 2007前方的防火牆,不但可阻擋非法連線,也可以過濾應用程式。
ActiveSync 整合訊息 個人電腦與手持裝置間的同步程式。使用者可以利用ActiveSync與Outlook同步。
Outlook 2007 整合訊息 個人端應用程式,可藉此存取Exchange 2007中的各項訊息。
Exchange管理主控臺 管理效率 特有的管理介面,加強管理效能,步驟更簡單。
Exchange Management Shell 管理效率 以PowerShell技術為基礎的管理命令介面,讓管理者可以編寫各種腳本指令。

整合VoIP與多種存取管道,讓訊息交換更密切 企業內部對於訊息交換的要求是相當嚴格且多樣化的,在網路連線尚未普及之前,電話、傳真與信件是最常使用的通訊管道。不過隨著需求提升,人不再需要固定在一個地點才能收發訊息,技術的演進讓使用者可以隨時隨地接聽電話,而網際網路的發展更讓使用者到處可以收發電子郵件。

微軟的整合通訊架構,就是整合企業目前所有的通訊管道與方式,融入Exchange 2007與Active Directory的管理之中,藉由單一功能伺服器簡化使用者的操作步驟,並提供強而有力的用戶端軟體,就不需要額外安裝其他的應用程式了。

雖然收發訊息對個人而言相當簡便,但是企業環境中的訊息整合一直遇到相當多難題,除了整合難度高之外,需求項目不同以及相關法律的規範,例如美國沙賓法案與證券交易委員會,都有要求企業必須依法管理電子郵件記錄與電子通訊內容,也是讓企業內部協同作業難以實現的原因。

一般來說,企業都會同時使用電信與數據網路,作為資訊交換的管道,在電信網路部分會使用電話與傳真,數據網路部分則包羅萬象,主要使用的服務則是電子郵 件、檔案傳輸與資料查詢等。但同樣是資訊傳遞,這兩套網路在企業內部卻是分屬兩個部門管理,電信網路多半屬於總務部門負責,而數據網路則是歸屬資訊網路管 理,不但管理麻煩,當要整合時更是會遇到管理責任歸屬的問題。

整合三部曲:語音、數據而後協同作業
有許多廠商就試圖提供可以整合通訊系統的解決方案。最早是由VoIP(Voice over IP)廠商提出相關解決方案,主要是解決傳統電信網路與數據網路整合的問題。雖然這樣可以提供部分郵件功能,但是其功效依然受限,整合效果不夠完整。而後 相關解決方案繼續試圖結合了行動電話與固網業者,讓行動、有線與網路電話這三種網路結合得更緊密。

不過單只有整合語音,只能讓以電話溝通的工作者加速處理速度,為了提供更好的處理效果,廠商便推出以行動電話接收電子郵件的解決方案。最早是以簡訊方式提供服務,但是受限於技術與硬體問題,無法依據郵件的重要程度發送,因此鮮少有人採用。

當技術與硬體問題逐漸解決之後,便有廠商利用中介硬體設備,讀取郵件伺服器內的信件,然後利用行動電話上網瀏覽,便可以讀取相關信件,但是這種作 法只能仰賴使用者定期上線檢查信件,如果時間上有落差,往往會延誤處理時間。目前,新一代的郵件整合解決方案,就是稱為「Push Mail」的方式,利用可客製化的應用程式,讓使用者可以自行決定何種信件與寄件者的信需要主動派送到行動電話上。

在微軟規劃的架構中,則是利用Exchange 2007搭配IP-PBX,或是以VoIP閘道器搭配傳統PBX等2種方式,將訊息交換的管道延伸至電信網路,如此可以不需改變現有的行政分工架構,但是也能夠提高整合通訊的工作效率。

為了能夠有效管理這些改變,Exchange 2007不再像過去由單一伺服器角色管理所有功能,而是分為Hub Transport(集線傳輸)、Mailbox(郵件信箱)、Unified Messaging(整合訊息)及Client Access(用戶存取)等4種角色。這4種伺服器角色可以全部安裝在同一臺伺服器中,也可以分別安裝,端看企業的需求與硬體效能而定。

Mailbox整合各項資訊來源
Exchange 2007的整合訊息功能,主要讓所有資訊集中儲存在使用者信箱中。無論是語音留言、傳真、電子郵件、會議邀請或是聯絡人,都可以在收件夾中取得,使用者不 再需要透過不同方式取得各類訊息。Unified Messaging伺服器會將語音留言轉成附加檔,寄送至使用者信箱中,使用者就能夠直接聽取並保存。

單以Exchange 2007來說,能夠整合的主要是語音及郵件等相關訊息,搭配Live Communications Server(LCS)後,更可以將服務範圍延伸至即時通訊上。LCS是微軟推出的企業內部即時通訊中心,用戶端電腦則需要加裝Office Communicator軟體。與Exchange 2007整合之後,員工使用Outlook時,就可以同時查看聯絡人是否在線上,而在搭配網路攝影機及麥克風,即可進行視訊會議,同時不需要電話也能夠留 下語音訊息。

更快得知使用者狀態,減少時間浪費
藉由Exchange 2007與LCS整合,一項最明顯的好處就是可以立即得知使用者狀態。Office Communicator與免費的MSN Messenger有著很類似的功能,使用者可以設定目前的工作狀態,讓其他員工可以在Communicator主畫面中得知相關訊息,並選擇最適合的聯 絡方式。

對行動工作者而言,存取相關資訊也更為方便。僅需要開啟Outlook,就可以同時收取所有訊息。就算沒有可供連接網路的裝置,使用者僅需要撥打 電話回公司,就可以透過Exchange 2007聽取留言或信件,這項功能稱之為Outlook Voice Access(OVA),讓使用者不僅可以利用電腦,也可以透過電話存取並修改相關資訊。透過網頁存取Exchange的Outlook Web Access(OWA),也伴隨著Exchange改版而有所改變,操作介面與Outlook 2007幾乎一模一樣,也更為直覺化。

更重要的是,使用者透過OWA不但可以存取郵件、會議邀請或聯絡人,想要檢視附件中的Word、Excel、PowerPoint或PDF檔案, 也不必擔心公用電腦沒有安裝Office或PDF閱讀器,因為在開啟OWA時,會自動安裝的ActiveX套件,就已提供WebReady文件檢視功能, 讓使用者在瀏覽器上就可以直接瀏覽相關Office檔案,操作上更為便利。

將郵件直接傳遞至行動裝置上
在Exchange 2007中,另一項特色就是稱為「Push Mail」的主動派送機制。雖然這項功能在Exchange 2003中就已經出現,但是在Exchange 2007中,Push Mail的功能更多樣了。採用Windows Mobile系列作業系統的行動裝置,可以直接透過ActiveSync與Exchange 2007連線,而非Windows Mobile作業系統的行動裝置,也有相對應的套件可供安裝,如Nokia提供的Mail for Exchange套件等,讓採用不同作業系統的行動裝置,也能夠享有Exchange 2007的便利性,但並不是每一臺非微軟產品都可以支援,有連線需求時需要特別留意這一點。

或許有人會擔心不小心遺失行動裝置,就會造成機密資訊外洩。在Exchange 2007中,只要是跟伺服器同步過的手持裝置,都會留下連線記錄,透過OWA我們都可以查閱相關連線記錄。倘若真的不幸遺失了載有手持裝置,使用者就可以 使用OWA中的行動裝置管理功能,由Exchange發出指令,藉由Push Mail方式,強制清除該裝置上同步過的所有資料,避免造成資料外洩。

增強垃圾郵件過濾,提高防毒效能
垃圾郵件一直為人詬病,使用者花在處理郵件上的時間與日俱增,相對也造成工作效率的降低,每個企業都深受其擾。雖然Outlook內建垃圾郵件篩選器,但是垃圾郵件變化太快,效果畢竟有限。

而在Exchange 2007中,伺服器端也提供反垃圾郵件元件,透過多項管理手段,盡量減少垃圾郵件的侵害。Exchange 2007中新增加的反垃圾郵件機制可以過濾收件者、寄件者與IP位址,也會參考網路上RBL清單,阻斷已知的垃圾郵件業者IP位址,藉此可以解決大多數的 郵件。

而微軟在Exchange內建功能之外,還有其他產品可以協助增強安全防護。Forefront是微軟資訊安全系列產品的總稱,而其中 Forefront Security for Exchange Server就是專供Exchange 2007使用的套件。該套件包含多種掃瞄引擎,可以防止病毒、蠕蟲與垃圾信件,盡可能在伺服器端處理相關問題,減少使用者的負擔。

提供符合法令的郵件歸檔及備分方法
許多已開發國家逐漸認為電子郵件也是正式文件的一種,因此規範電子郵件行為的法案也相繼出現,例如美國的沙賓法案、日本的個人情報保護法及巴賽爾新協定等,都有明文規定與電子郵件相關的內容。在這些法律規範之下,電子郵件與相關訊息的規範與保存就相當重要。

電子訊息的記錄管理一般來說可以分為3個階段,第一階段偏重在使用者本機上的管理,使用者自行在Outlook中建立各種不同名稱的資料夾,區隔並儲存電子郵件、會議邀請或聯絡人等相關電子記錄;第二階段則由提升至與伺服器共同運作;第三階段則是訊息歸檔與備分。

以Exchange 2007為例,在伺服器上可以開設一個公用資料夾,稱為「受管理的資料夾」,其中開放各使用者自行儲存需要保管的重要資訊內容。當使用者將資訊拖拉至該資料夾後,就會由伺服器負責保存並歸檔,並在第三階段時讓伺服器自動封存。

按部就班做好記錄管理
企業中所有員工在發送訊息時,理當受到各項法律與企業規範的限制,原先這些規範都只能由用戶端自行執行,伺服器部分無法強制作業。因為當員工收到 信件時,除了在自己的收信程式中保有一份資料外,其他地方難以同步保存,因此第一階段的記錄管理,無論依照時間或項目分類,都必須要由使用者自行負責,在 Outlook上建立特定的資料夾,並保存相關記錄。

而信件並不是寄出之後就不用管理,在特定產業中,電子郵件是需要彙整並歸檔處理,以因應後續查詢之用。在Exchange 2007中,可以由伺服器端定義不同的分類標籤,員工在使用Outlook或OWA 2007時,就可以套用這些分類標籤,做好本機上的郵件分類管理。同時,Exchange 2007也可以根據這些分類標籤,做好郵件歸類的動作,接下來更能做到記錄管理。

設定記錄管理之後,使用者的Outlook中就會出現「受管理的資料夾」這個項目,只要將重要的信件或項目拉至該資料夾,就會在伺服器部分自動留 存,就算本機上刪除了相關訊息,也可以在伺服器上找到。之後就可讓Exchange 2007自動封存相關內容,不但保存重要資料,也可以節省存放的硬碟空間。

新備分方式讓還原更容易
縱使有新的記錄管理方式,沒有良好的備分還原機制也是枉然。Exchange 2007中提供了新的備分還原作法,不論是本機或叢集都能避免災害的發生。

這套備分還原技術分為本機與資料中心兩種架構,稱為LCR(Local Continuous Replication,本機不間斷複寫備分)與CCR(Cluster Continuous Replication,資料中心叢集備援)。

不論是LCR或CCR,在備分的過程當中,並不是備分完整的資料,而是備分載有所有相關變動的記錄檔,需要備分的檔案數少,容量也較小,因此所需 的備分時間更短。藉由這項技術,Exchange 2007就能夠提供更良好的備分還原機制,並且不必擔心還原過程中會有太長的記錄空窗期。

新管理介面讓操作更方便 Exchange的管理操作相當繁瑣,向來是最讓資訊管理人員頭痛的地方,不過在Exchange 2007中這項問題已經有了明顯的改善,這要歸功於管理主控臺與命令介面。

過去必須透過Active Directory的「使用者及電腦」管理的方式,改以新的管理主控臺(Management Console)取代。在該主控臺中,管理者可以輕鬆地新增或移除使用者,在AD中的使用者帳號也會同步新增或刪除,不用再像以往要重複多個步驟才能新增 一名使用者。

不過在Exchange 2007中,有許多功能並不能在主控臺中操作,而必須要搭配命令介面才能執行。對於習慣使用命令列的管理者而言,新的介面很方便愉快,對習慣使用圖形化介 面的管理者來說,雖然操作上稍微困難了點,但是搭配上良好的指令與步驟說明,就算是初學者也不會感到太困難。而未來Service Pack 1推出時,會將部分過於繁瑣的指令,改成圖形化的方式,讓使用者操作更簡單,進一步降低操作難度。

功能雖強大,導入前應妥善考慮 導入Exchange 2007之前,企業首先需要留意的就是32位元與64位元上軟硬體的問題。微軟表示,Exchange 2007分為32位元與64位元兩種版本,32位元版僅供測試及教育訓練之用,微軟不支援正式上線使用。

Exchange 2007是少數可完全支援64位元平臺的應用系統,也因此微軟認為企業正式營運設備應採用64位元平臺。因為使用64位元平臺,可以突破最多4GB的可配 置記憶體限制,並能獲得更大的暫存空間,對系統穩定及工作效率有明顯幫助。另一項好處是每秒輸出入作業的數量(Input/Output Operations per Second,IOPS)也會大幅下降。

在微軟早期的測試中指出,同樣在64位元平臺上執行,Exchange 2007所需要的I/O效能(IOPS數)與Exchange 2003相比,減少了約75%,也就表示如果要達到同樣的效能表現,Exchange 2007所需的硬碟容量,約只為Exchange 2003的四分之一。因此Exchange 2007可以支援更多且容量更大的資料庫,企業能夠儲存的訊息量也更多了。不過目前能夠完整支援64位元的應用程式還相當少見,值得企業妥善評估。

管理與維護Exchange 2007也是需要仔細思考的部分,雖然整體管理介面與操作較Exchange 2003簡易,但是有許多重要動作需要在PowerShell上執行,這也是為什麼在安裝Exchange 2007之前,需要先行安裝PowerShell的原因。

Exchange 2007並不是獨立使用就能有如此強大的功能,雖然用戶端可以支援Outlook 2003,但還是需要以Outlook 2007存取才能完整發揮特色。而相關軟硬體升級就勢不可免,對企業而言,這又是另一筆不小的開銷。

另外在Exchange 2007中,正式區分出5項不同的伺服器角色,以中小型企業而言,固然可以用一臺伺服器解決這些角色扮演問題。但對大型企業而言,能夠獨立安裝郵件信箱, 並加強備分還原機制是很重要的,原Exchange管理者也需要經過一段時間的教育訓練及操作,才能夠重新調整並適應新的Exchange架構,這也是需 要考量進去的。

另外搭配上整合通訊的新功能,可以讓已經建置好VoIP的企業進一步增強溝通聯繫的能力,但對管理者而言,該如何定義Active Directory的使用者,帳號與電話分機的整合,甚至是新建置SharePoint Portal Server以提供更即時的服務,這些也都是新的挑戰。

達成永不停頓的郵件系統 郵件系統是相當重要的資訊傳遞工具,就像電話系統一樣是企業不可或缺的要素,既然電話都要求要達到99.999%的可用度,郵件系統也應當要永不停頓才對。但我們都知道,這是不可能做到的事情,因此就需要有備分還原技術協助,讓停機時間(downtime)減至最小。

無論是軟體錯誤或硬體失效,都是會造成郵件系統停機的原因,有時候重新啟動就沒事了,但最害怕的狀況是必須重新建置系統,而所有通訊記錄全部消失,重要資 料也隨之煙消雲散。此外,無論日本、美國或歐盟,都相繼訂定法律與規章,規範電子訊息記錄的傳送、歸檔與保存年限等相關事項,現在的郵件系統不能僅負責收 發信件,還必須要兼顧記錄與存檔的功用。

除無法控制的硬體毀損因素之外,微軟試圖將軟體部分的影響降至最低,就算一旦發生問題,也有良好的備分還原機制可以補救。Exchange 2007中提供多項高可用性技術,最重要的2項技術就是本機連續複寫(Local Continuous Replication,LCR)與叢集連續複寫(Cluster Continuous Replication,CCR)。

搭配叢集服務自動備分還原
基本上這2種技術都是基於Windows Server 2003作業系統中的複寫服務而來,基本原則也都相同。在CCR部分來說,與Exchange 2003的叢集解決方案相比,CCR技術已經不需要共用的儲存區,因為每個節點都另外保存了一份複本,而且支援DAS、SAS或SAN等多種儲存方式,可 以直接使用現有的儲存設備,能降低新建置成本。

當CCR進行備分時,並不是複製整個資料庫,而是採用類似SQL Server,備分資料記錄檔的方式處理。記錄檔有固定大小,當記錄檔滿了之後,會自動更名並且建立新的檔案繼續記錄。當需要回復時,僅需要將變更過的記錄檔還原即可,因此可以大幅降低還原時間。

叢集服務的Active-Active模式,因為太少用戶使用而已經取消,在Exchange 2007中,全部採用Active-Passive模式。如果主動節點發生問題,叢集服務就會自動將掛載點轉向,被凍結點就會提升為主動節點,並繼續提供相關服務。

本機即可備分,降低建置成本
LCR算是CCR的簡易版,同樣會在本機上保有另一份複本。不過與CCR不同的是,在遇到故障時,CCR會因為叢集服務的連動關係,會自動複寫還原,而LCR就必須自行手動還原。

對於中小型企業來說,採用LCR也不需要花費太多硬體成本,需要花費的就是儲存第二份複本的外部儲存裝置,如此可兼顧成本效益與效率。雖然在協定 設計上,就算收件方沒有回應,寄件方也會在等待一段時間後重發並告知原寄件者,但這樣時效上就會有落差,透過叢集服務與CCR技術,企業可以快速地打造出 不會停頓的郵件系統。

整合資訊網路與電信網路的整合訊息架構 過往大多數整合通訊(UM)解決方案都是由硬體廠商推出的,因此整合現有設備成為最重要的課題。雖然Exchange本身就提供訊息統整的功能,可以提供電子郵件與企業內部的訊息發布所需,但是在整合通訊環境中還是有所欠缺,不能滿足企業中各種需求。

伺服器角色確立,各司其職
在Exchange 2007中,明確地在安裝時就區分成Hub Transport(集線傳輸)、Mailbox(郵件信箱)、Unified Messaging(整合訊息)及Client Access(用戶存取)等4種伺服器角色,每種角色各司其職,並且互相協同處理,構成整個Exchange核心架構。

郵件信箱這個角色主要工作就是儲存網域使用者的所有訊息,只有內部網路上的Outlook使用者才能直接與郵件信箱伺服器連線。而集線傳輸的角色 則可以說是Exchange裡頭的「郵政總局」,會依據原始郵件內容與目的地位址處理郵件,其中並含有分類程式,會依據設定好的規則,檢閱所有送來處理的 信件,並自動給予最好的決策。

整合訊息的角色對微軟系列產品而言是一個全新的概念,絕大部分的整合訊息功能都是由此角色負責。它位於Exchange架構與VoIP環境的邊界 上,接收由VoIP閘道器或IP-PBX傳來的語音內容,並且與目錄伺服器中的資料比對,找到對應的使用者後,就會透過SMTP協定將訊息送至集線傳輸伺 服器,或是直接透過MAPI協定送到郵件信箱中。

整合訊息角色並不只是單向接收語音訊息而已,使用此機制,員工在企業外部能以電話撥入的方式,要求整合訊息角色協助存取文字類型的內容,並且以語音方式傳送,如此即可藉由雙向互動提供更佳的服務能力。

用戶存取角色就像是櫃臺招待一樣,負責處理除了使用MAPI的Outlook連線外,其他如POP3、IMAP4與HTTPS等協定,及 ActiveSync應用軟體或硬體的連線要求。而所有外部連線要求,都會透過用戶存取角色,向後方其他伺服器角色轉送訊息,因此只要有非MAPI連線需 求,就一定要安裝用戶存取角色才能使用。

藉VoIP打造整合通訊
對微軟而言,整合自家各系列產品,也僅能提供協同作業部分的訊息傳遞,要能夠全方位整合通訊環境,不能缺少的就是VoIP閘道器、傳統或IP-PBX, 只要透過H.323或SIP等共通的通訊協定,要整合外部設備就不是難事。

當與VoIP環境整合之後,Exchange 2007才算是達到整合通訊的目標,而在整個架構下,整合訊息角色的責任最為吃重,但也是以往Exchange管理員最不熟悉的一塊拼圖,也將會是最難掌控的一項功能。

行動工作者有3種管道與Exchange交換訊息。採用Windows Mobile系列作業系統的行動裝置,可以透過內建的ActiveSync與個人電腦或Exchange伺服器連線,透過HTTPS的加密連線,可以確保安全性,而又不會影響連線效能。

如果沒有行動裝置,得使用公用電腦的話,也可以藉由HTTPS連線,連接Exchange伺服器提供的Outlook Web Access 2007網頁服務。新一代的Outlook Web Access外觀已經與Outlook 2007幾乎一模一樣,功能與操作都沒有太大的差別,能夠讀取郵件中的附件,整合SharePoint Portal Server 2007後,所建構出的資訊平臺會協助使用者存取Exchange 2007上的各項資料,只要透過OWA 2007連線,就能夠存取在企業內部公用資料夾上的文件,不需要另外建立VPN連線。另外OWA 2007也支援SSL加密,不必擔心資料會在傳輸過程中被竊取。

藉由UM填滿遺失的缺口
雖然我們已經十分依賴電子郵件,畢竟以目前溝通管道而言,最主要的還是語音通訊,因為電話也是隨手可得的工具,因此我們也可以看到許多手機廠商或服務商,不斷推動「Push Mail」或是相關的加值服務,藉由行動電話與通訊網路,讓溝通及資料傳輸更方便。

以Exchange的功能與定位來看,我們認為的確有資格往整合通訊範疇邁進,但在Exchange 2007之前的產品,都沒有辦法完整涵蓋整個通訊領域,缺的最大一塊拼圖就是語音領域的技術。在Exchange 2007推出整合訊息伺服器技術之後,才把這部分補上,構成完整的圖案。

藉由整合訊息角色,微軟將整合訊息架構的重心放在Exchange 2007上,讓使用者僅需單一應用程式或裝置,就能夠存取所有訊息。而搭配上SharePoint Portal Server,能夠提供更便利的存取管道與實用性的協同作業環境,無論何時何地,只要能夠連接網路,就能夠存取訊息。

微軟郵件與協同作業系統發展年表
發表時間 產品名稱 主要功能與說明
1995年9月Microsoft Mail 3.5 微軟早期的郵件伺服器產品,最初設計也是供Mac使用,而後也支援Windows系統。當初在PC端的競爭對手為Lotus的cc:Mai。發展到3.5版本後,PC部分版本改名為 Exchange,Mac版本則售出,不再繼續維護。
1996年6月Exchange 4.0此版本接續 Microsoft Mail,並更名為Exchange,初始版本即為4.0版,支援Client-Sever架構的X.400郵件設定,並以單一資料庫儲存。同時也支援X.500目錄服務協定。
1997年5月 Exchange 5.0 推出Exchange管理主控臺與Exchange Web Access功能。用戶端部分則推出Outlook 8.01 、Exchange Client 5.0與Schedule+ 7.5。
1997年11月 Exchange 5.5 將Exchange Web Access改名為Outlook Web Access,並提供行事曆功能。支援IMAP4與LDAP v3協定。同步推出Outlook 8.03版本,整合Exchange Client與Schedule相關功能,構成現今Outlook的雛形。
2000年11月 Exchange 2000 提升資料庫的最大容量限制,並將叢集中可容納的伺服器數量可達4臺。不再獨立擁有並維護一份目錄,而轉納入Active Directory架構之下。
2003年9月 Exchange 2003 增強災難復原能力。提供Outlook Mobile Access與ActiveSync功能,並增強防毒與垃圾郵件過濾機制。在協同作業部分則同步提供新版本的Office、LCS、SharePoint Portal與Live Meeting等應用程式。
2006年12月 Exchange 2007 提供整合訊息、加強歸檔與備分、整合資訊安全防護相關產品,並提供更簡單有效率的管理工具。





--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!


--
萬歲!您的郵件已被捨棄。一封垃圾郵件也沒有!