2009年10月9日 星期五
下載時加密(Encryption on download)是個好主意? 歡喜就好!
既然又被問到了, 乾脆把它寫出來好了.
首先, 我個人是不贊成採用下載時加密(Encryption on download)這種方式來整合DRM 與 Windchill.
第一個理由是偏學術性的. 簡單來說就是只需做一次的不需做第二次.
一旦採用下載時加密, 同一份內容檔(content) 勢必因為不同的使用者, 或為了某些原因需要再次下載等因素, 造成多次加密. 對系統效能而言, 當然是不必要的負擔. 以現在節能減碳的觀點 ,這當然也不是一個愛地球的表現.
第二個理由, 與原產品設計理念衝突.
從TrustView或其他DRM系統的設計理念出發, 一個檔案基本上就是佔用一個TrustView DOC ID. 反覆對同一個檔案加密, 除了只增加系統負擔外, 沒有任何好處! 雖然TrustView RD已經把資料庫相關欄位放得夠寬, 理論上以每個檔案會被加密一千次來算 TrustView DOC ID應該也沒那麼快用完. 但是試想在一個充斥垃圾的資料庫中, 一些普通的SQL指令, 效能上即可能也會打折扣.
第三個理由, 永遠要考慮例外狀況.
尤其是系統整合. 看過我以前文章的話, 多少感覺得到, 造成檔案無法順利加密的理由很多. 在規畫整合時, 例外處理絕對是不能忽略的! 比起其他常用的整合模式, 下載時加密的例外處理最難做. 因為下載的那當下, 使用者已經期待要拿檔案來用了! 一旦無法加密, 那怎麼辦? 不讓使用者拿檔案, 他可能鬧翻天! 讓他把未加密的檔案流出去, 那文件安全似乎又白玩一場? 理論上, 我們必須正視例外處理, 而不是假設它不會發生. 其它方案如流程中加密與上傳時加密(encryption on upload), 因為文件基本上還未結束審核流程, 例外處理在設計與實作時較容易與現行的審核流程整合在一起. 也就是說, 一旦不可抗拒的例外發生, 也有辦法由系統自動攔下錯誤, 並將流程導向例外處理, 自動通知系統管理員與相關使用者解決, 甚至留下決策記錄. 更因為問題發現得早, 審核流程也還在進行 要解決問題, 在時間上相對充裕.
當然, 傾向下載時加密方案的最大理由是擔心TrustView server不穩定, 或遭逢天災人禍, 意外掛點? Windchill裏被加密的檔案會不會從此打不開? 這個課題一方面牽涉到幾種不同程度的災難復原, 一方面也牽涉到日常的系統備份, TrustView的系統管理手冊皆有詳盡的說明, 在此不多費言. 但我們不妨從另一個角度來了解:
第一, 同樣的天災人禍可能也會造成Windchill server的損壞. 因此日常的系統備份與災難復原的演練操作本來就不可免, 什麼系統都一樣!
第二 TrustView的系統架構, 資料庫表格數量, 資料量, 比起Windchill相對簡單的太多了. 這也難怪在幾個系統整合的客戶那, 比起Windchill, TrustView出問題的機率較小, 或是問題相對單純, 系統也相對穩定. 簡單來說,做的事情少得多嘛! 同樣的, 在備份與災難復原上, 比起Windchill, 備份或回復TrustView系統相對容易.
所以那些擔心TrustView server不穩定的朋友, 某些方面想得稍微多了些?
當然, 有一種說法, 我完全贊同: "Windchill (or PTC)會活得比較久! 過幾年誰想知道TrustView還在不在?" 關於這點, 我想我不只是口頭贊成, 我還付出了行動!!!
在此, 不過就技術或設計理念與大家交流交流. 至於, 最後要採用什麼做法, "歡喜就好(台語)!"
首先, 我個人是不贊成採用下載時加密(Encryption on download)這種方式來整合DRM 與 Windchill.
第一個理由是偏學術性的. 簡單來說就是只需做一次的不需做第二次.
一旦採用下載時加密, 同一份內容檔(content) 勢必因為不同的使用者, 或為了某些原因需要再次下載等因素, 造成多次加密. 對系統效能而言, 當然是不必要的負擔. 以現在節能減碳的觀點 ,這當然也不是一個愛地球的表現.
第二個理由, 與原產品設計理念衝突.
從TrustView或其他DRM系統的設計理念出發, 一個檔案基本上就是佔用一個TrustView DOC ID. 反覆對同一個檔案加密, 除了只增加系統負擔外, 沒有任何好處! 雖然TrustView RD已經把資料庫相關欄位放得夠寬, 理論上以每個檔案會被加密一千次來算 TrustView DOC ID應該也沒那麼快用完. 但是試想在一個充斥垃圾的資料庫中, 一些普通的SQL指令, 效能上即可能也會打折扣.
第三個理由, 永遠要考慮例外狀況.
尤其是系統整合. 看過我以前文章的話, 多少感覺得到, 造成檔案無法順利加密的理由很多. 在規畫整合時, 例外處理絕對是不能忽略的! 比起其他常用的整合模式, 下載時加密的例外處理最難做. 因為下載的那當下, 使用者已經期待要拿檔案來用了! 一旦無法加密, 那怎麼辦? 不讓使用者拿檔案, 他可能鬧翻天! 讓他把未加密的檔案流出去, 那文件安全似乎又白玩一場? 理論上, 我們必須正視例外處理, 而不是假設它不會發生. 其它方案如流程中加密與上傳時加密(encryption on upload), 因為文件基本上還未結束審核流程, 例外處理在設計與實作時較容易與現行的審核流程整合在一起. 也就是說, 一旦不可抗拒的例外發生, 也有辦法由系統自動攔下錯誤, 並將流程導向例外處理, 自動通知系統管理員與相關使用者解決, 甚至留下決策記錄. 更因為問題發現得早, 審核流程也還在進行 要解決問題, 在時間上相對充裕.
當然, 傾向下載時加密方案的最大理由是擔心TrustView server不穩定, 或遭逢天災人禍, 意外掛點? Windchill裏被加密的檔案會不會從此打不開? 這個課題一方面牽涉到幾種不同程度的災難復原, 一方面也牽涉到日常的系統備份, TrustView的系統管理手冊皆有詳盡的說明, 在此不多費言. 但我們不妨從另一個角度來了解:
第一, 同樣的天災人禍可能也會造成Windchill server的損壞. 因此日常的系統備份與災難復原的演練操作本來就不可免, 什麼系統都一樣!
第二 TrustView的系統架構, 資料庫表格數量, 資料量, 比起Windchill相對簡單的太多了. 這也難怪在幾個系統整合的客戶那, 比起Windchill, TrustView出問題的機率較小, 或是問題相對單純, 系統也相對穩定. 簡單來說,做的事情少得多嘛! 同樣的, 在備份與災難復原上, 比起Windchill, 備份或回復TrustView系統相對容易.
所以那些擔心TrustView server不穩定的朋友, 某些方面想得稍微多了些?
當然, 有一種說法, 我完全贊同: "Windchill (or PTC)會活得比較久! 過幾年誰想知道TrustView還在不在?" 關於這點, 我想我不只是口頭贊成, 我還付出了行動!!!
在此, 不過就技術或設計理念與大家交流交流. 至於, 最後要採用什麼做法, "歡喜就好(台語)!"
2009年10月1日 星期四
PDMLink 9 建立物件時屬性欄位間的互動研究(一)
愈來愈多R9客戶反映使用者需要在建立物件(如文件, 零件)時, 屬性的輸入欄位(attribute's input)間需要有互動關係 相信老Windchill users與老PTC應該對這類的需求再熟也不過了. Template processor時代做這方面的客製司空見慣. 不要說大師兄Wayne, David Su老大, Michael等前輩熟得不要再熟了, 就連客戶那邊的IT自己都玩得興高采烈! 像Joseph, James, Xavier..
PDMLink系列好像從7版開始, 自訂物件類型(Soft type)會自動出現在建立時的類型選項(Type options)中, 而自訂物件類型所包含的自訂屬性(IBA)也會直接顯現在屬性的輸入頁面. 也就是說Windchill R7 為此提出一標準機制, 認為足以供Windchill的黎民百姓使用.
這真是標準的.... 想太多...
這個屬性輸入頁面的第一個問題是很溫柔(以歌手趙傳的語言來說)! 或太溫柔了!!!
這標準界面到 R8 時印象中還是有點陽春(也就是長得有點抱歉).
第二個問題最要命! 因為他這個標準界面是個大黑箱!!! R&D似乎沒打算開放出來讓大家來客製. 個人在過去幾個案子曾經有被逼著做過一些客製, 雖然成功了, 但是必須承認客製的難度比Windchill 626 Template processor時要高, 風險也較大. 更重要的是, 這類的客製, 理論上PTC應該是不負責的.
到了R9 有更多壞消息, Template processor幾乎不見了!!! 取而代之的是WCA. WCA基本上是PTC綜合二年前甚至三年前一些蠻"火"的技術, 關起門來硬搞出來的一套MVC架構, 像個萬花筒一樣. 以周董的說法: "其實還蠻屌的!". 但是上過課的人都認為:更難學了!
至於屬性輸入介面的部分, 有好消息, 也有壞消息. 好消息是這一代界面比較漂亮, 也較好用. 例如日期的輸入終於有日曆了(不過不是萬年曆就是了)! 壞消息是, 這些屬性輸入背後的HTML "INPUT"又更複雜了. 例如做互動效果常需要依賴的輸入名稱(element name), 複雜的嚇人. 例如下圖就是個例子. 對屬性"DemoAttr01", Windchill很貼心的為他取名為...咦? 好像怪怪的是嗎?
"name="components$loadWizardStep$OR:wt.inf.library.WTLibrary:14160$|..."這是什麼東東啊~
其實這張圖我們只看到一小段 後會還有哩
我把其中幾個關鍵字框起來, 至少讓我們分辨的出這個"名字長的不像話的傢伙", 真的是上面那個看來很單純的TextArea! 你若問我為什麼RD要取那麼長的名字? 我只能說我不知道 (其實多少猜得出, 但是算了..)! 但重要的是, 這代表了"互動效果"看來沒像從前那麼好搞定! 這一長串的名字 有些部分還好猜, 有些部分就不一定了? 如下圖:
"4753366976990569820"又是幹什麼的? 好像每次還不一樣?
我在研究這個主題時, 我想過幾種策略. "傳統的"做法: 掌握屬性輸入欄位背後的命名規則(Naming Rule)後再來做加工, 是其中一種. 另一種做法是"訂自己的屬性輸入欄位命名規則". 這種作法還需要配合其他部份的客製: 製做自己的屬性輸入頁面, 並把Windchill後端(server side)建立物件的"Form Proccessor"也同時換成自己客製的Form Proccessor. 簡單來說, 也就是擴大客製Wizard的範圍, 但是說不定比較划算!
由於自訂屬性輸入欄位命名規則與客製Form Proccessor我有一些相關經驗, 所以本月初在訂研究題材時, 我就想試試第一種策略. 目前已有一些進展.
如下面的圖片所示, 我定義了一種文件類型並加入了幾個屬性:
假設使用者希望 demoAttr02 的選項會決定demoAttr03的合法選項. 規則如下:
當 demoAttr02 = option1 時 demoAttr03僅有option1_1, option1_2, option1_3可選
當 demoAttr02 = option2 時 demoAttr03僅有option2_1, option2_2可選
當 demoAttr02 = option3 時 demoAttr03僅有option3_1可選
若用R9預設的建立文件界面 毫無意外 欄位間無互動效果
再加入了一些客製之後, 達到了上述的互動.
關鍵的作法, 下篇文章在介紹.
PDMLink系列好像從7版開始, 自訂物件類型(Soft type)會自動出現在建立時的類型選項(Type options)中, 而自訂物件類型所包含的自訂屬性(IBA)也會直接顯現在屬性的輸入頁面. 也就是說Windchill R7 為此提出一標準機制, 認為足以供Windchill的黎民百姓使用.
這真是標準的.... 想太多...
這個屬性輸入頁面的第一個問題是很溫柔(以歌手趙傳的語言來說)! 或太溫柔了!!!
這標準界面到 R8 時印象中還是有點陽春(也就是長得有點抱歉).
第二個問題最要命! 因為他這個標準界面是個大黑箱!!! R&D似乎沒打算開放出來讓大家來客製. 個人在過去幾個案子曾經有被逼著做過一些客製, 雖然成功了, 但是必須承認客製的難度比Windchill 626 Template processor時要高, 風險也較大. 更重要的是, 這類的客製, 理論上PTC應該是不負責的.
到了R9 有更多壞消息, Template processor幾乎不見了!!! 取而代之的是WCA. WCA基本上是PTC綜合二年前甚至三年前一些蠻"火"的技術, 關起門來硬搞出來的一套MVC架構, 像個萬花筒一樣. 以周董的說法: "其實還蠻屌的!". 但是上過課的人都認為:更難學了!
至於屬性輸入介面的部分, 有好消息, 也有壞消息. 好消息是這一代界面比較漂亮, 也較好用. 例如日期的輸入終於有日曆了(不過不是萬年曆就是了)! 壞消息是, 這些屬性輸入背後的HTML "INPUT"又更複雜了. 例如做互動效果常需要依賴的輸入名稱(element name), 複雜的嚇人. 例如下圖就是個例子. 對屬性"DemoAttr01", Windchill很貼心的為他取名為...咦? 好像怪怪的是嗎?
"name="components$loadWizardStep$OR:wt.inf.library.WTLibrary:14160$|..."這是什麼東東啊~
其實這張圖我們只看到一小段 後會還有哩
我把其中幾個關鍵字框起來, 至少讓我們分辨的出這個"名字長的不像話的傢伙", 真的是上面那個看來很單純的TextArea! 你若問我為什麼RD要取那麼長的名字? 我只能說我不知道 (其實多少猜得出, 但是算了..)! 但重要的是, 這代表了"互動效果"看來沒像從前那麼好搞定! 這一長串的名字 有些部分還好猜, 有些部分就不一定了? 如下圖:
"4753366976990569820"又是幹什麼的? 好像每次還不一樣?
我在研究這個主題時, 我想過幾種策略. "傳統的"做法: 掌握屬性輸入欄位背後的命名規則(Naming Rule)後再來做加工, 是其中一種. 另一種做法是"訂自己的屬性輸入欄位命名規則". 這種作法還需要配合其他部份的客製: 製做自己的屬性輸入頁面, 並把Windchill後端(server side)建立物件的"Form Proccessor"也同時換成自己客製的Form Proccessor. 簡單來說, 也就是擴大客製Wizard的範圍, 但是說不定比較划算!
由於自訂屬性輸入欄位命名規則與客製Form Proccessor我有一些相關經驗, 所以本月初在訂研究題材時, 我就想試試第一種策略. 目前已有一些進展.
如下面的圖片所示, 我定義了一種文件類型並加入了幾個屬性:
假設使用者希望 demoAttr02 的選項會決定demoAttr03的合法選項. 規則如下:
當 demoAttr02 = option1 時 demoAttr03僅有option1_1, option1_2, option1_3可選
當 demoAttr02 = option2 時 demoAttr03僅有option2_1, option2_2可選
當 demoAttr02 = option3 時 demoAttr03僅有option3_1可選
若用R9預設的建立文件界面 毫無意外 欄位間無互動效果
再加入了一些客製之後, 達到了上述的互動.
關鍵的作法, 下篇文章在介紹.
訂閱：
文章 (Atom)