詳細介紹使用XML化的思維組織資料（圖）

前言

時代變了。

以往資料更多的透過人工錄入，從專用網路協定的終端轉移到「玻璃屋」裡的大鐵盒子，現在資訊無所不在、無時不在，不過不一定都會匯總到您公司裡，很多時候大家是在一個「平」的世界分享數據，資訊來源的管道多了、資訊本身的變化也更加頻繁。不僅如此隨著Web 2.0、Enterprise 2.0和Internet Service Bus等一系列概念的出現，您發現單單從自己的「玻璃屋」找供貨商提供的倉庫地址遠不如Google Map方便。

似乎以往桎梏數據的各種枷鎖在互聯網下被一一打破，但作為IT從業者，我們的工作是為用戶提供它們所需的數據和他們希望獲取信息的手段，因此應用必須能夠經得起各種變化，包括以往我們關心的使用者介面的變化、應用程式間呼叫的變化、應用內部邏輯的變化，還有步伐越來越快但又是最根本變化——資料本身的變化。

關係模型告訴我們要用二維表格描述訊息世界，但這是太「不」自然不過了，看看手邊的一本書或是家裡的裝修計畫、馬上要開工專案的任務分解，好像套到一個二維表格裡總不合適，而且即便透過「實體－關係」生硬的削足適履後，在快速變化的環境下又總是要牽涉到「數據——應用——前端互動」一系列變動，而且經常是牽一發動全身。

似乎許多新一代應用程式已經找到了更適合新趨勢的方案—XML，以更貼近我們自己思維的方式組織應用程式、組織使用者體驗。那麼對於企業而言，組織資料這種相對基礎的工作是否也可以用XML的思維進行呢？應該可以。

應對資料實體本身的變化

資料實體過去總是被假設為應用中最為穩定的部分，無論我們用設計模式還是採用各種開源的開發框架（包括這些框架本身）都是盡量適應應用程式本身變化的問題，那麼現實的情況又是如何呢？

l 我們需要交換的資料實體經常要根據自身、合作方的需要變化；

l 合作方給我們的資料實體也常常變化；

l 隨著SOA和Enterprise 2.0概念的推出，資料實體本身從多個來源mash up出來，同時資料實體本身也被反覆的拼裝和組合；

l 隨著業務的細化，我們自己的員工總是希望獲取越來越豐富，同時也越來越詳盡的信息；

因此，以往視需求也好、設計也好認為可以最早固定下來的數據實體在愈發敏捷的技術和業務現況前需不斷調整。為了適應這個要求我們可以自頂向下入手，不斷調整應用自身的柔性；另一個方式是從「根」上處理這個問題，採用自身就可以不斷適應這些變化的新資料模型，例如：XML資料模型和XML相關技術家族。

例如，定義使用者實體的時候，最初下面的資訊就夠了，其中ICustomer是應用程式會使用的使用者介面，而CUSTOMER為關係資料庫方式下的表示，為XML方式：

不過緊接著我們就發現這個實體設計有些問題，因為還要增加用戶的辦公室電話、住宅電話，還有可能1、 2個電子郵件，他的MSN或Skype號碼等。不考慮其他問題，僅僅從關係模型範1的要求，那麼RDBMS和XML兩個模型發展的結果就成了：

不難看出，雖然僅僅只是「客戶」資料實體末節「聯絡資訊」的一個變化，關係模型和XML模型在適應性方面就有非常大的區別，關係模型需要不斷擴展出新的關係用來描述不斷細化的資料實體，而XML模型本身的層次性可以提供變化條件下，自身的不斷延伸與擴展。實際專案中，「學歷狀況」、「工作經驗狀況」等資訊也存在類似的問題，關係模型下即便某位客戶希望把某階段工作狀況的「借調」方式補充進去，也會發現因為設計上沒有預留相應的字段，因此只好把它作為字符串“揉”在“工作單位”字段裡，後面補充個“（借調）”，這等於僵化的數據模型本身抹殺了數據的商業語意中包含的資訊；而層級模型可以把它當作一個子節點或屬性來描述，這不僅可以把關係模型下需要多個關係（客戶、學歷狀況、工作經驗、聯絡資訊）集中在一個資料實體內部，而且可以把每個實體本身的擴展資訊（例如「工作模式」：借調、交流、短期集中）等也描述在資料實體內部，同時從外部應用看「客戶」實體本身依然是一個實體，這樣用更貼近現實業務情境的資料實體才能更有效的適應外部變化。

上面我們討論的只是一個資料實體，進一步發展到具體業務領域模型模型的時候，往往需要同時綜合多個資料實體協作完成業務功能，這時候情形又如何呢？例如：保單需要客戶提供除了上述資訊外的個人健康信息，子女、父母、伴侶家庭主要成員信息，同時會從其他從業機構獲取用戶的信用信息等，而且不同的數據實體組合主要用於企業內部的各異的應用領域，因此從數據使用角度看為了盡量讓應用部分穩定，最好是數據實體穩定，但僅僅用戶信息的聯繫方式部分就可能會反复的變化，如果讓應用完全依賴這些變化因素組合後的結果，那麼應用的穩定性確實難以保證，那麼從源頭上第一步先盡量保證不同應用盡量僅依賴於具體一個實體也許是有效改進的第一步，這時候XML的層次特性優勢又顯示出來了，例如我們可以根據不同的應用主題，自由組合這些資訊：

這樣應用程式面對的就是一個統一的實體，對應的採用專用的XML技術可以確保應用框架不變的情況下，新的業務可以動態回應變化的資料實體。

應對資料和內容的整合

上面提的資料實體更多是在一個已經集中後的語境下討論的，但除了概念上的設計外，使用中還有一個具體的問題就是如何把他們「聚集」到一起，這個一般透過資料集成實現。

（不過就像「架構」一詞被過度濫用一樣，「資料整合」同樣被各個廠商根據自己的產品特徵被定義成不同概念的組合，例如BI#廠商力圖把它描繪成ETL的代名詞、提供資料交換平台的廠商描述為實現BizTalk Framework的產品、對於SOA產品公司而言，資料集成則更多在於如何保證在有效治理的前提下提供資料服務，另外對於一些廠商而已，資料集成還包括業務語意組合等。我們要著重關心什麼問題呢？

l 資料實體的對應關係；

l 資料來源的在各種交換協定、產業資料標準、安全控制約束下的互聯；

l 資料交換過程的編排；

l 資料實體的驗證與重構；

l 資料媒體、資料載體的轉換；

雖然理論上這些工作用編碼完成不成問題，但隨著企業集成邏輯越來越複雜且變化越來越快，修改程式碼即便可以應付一下1：N的集成，但如果經常是M：N的情況，那麼就顯得力不從心了。是否可以有更簡化的方法呢？僅從「映射」的邏輯層次說：

l

物件導向

想法告訴我們依賴倒置，要盡量依賴抽象而不是具體，例如依賴介面而非實體類型；

l 設計模式告訴我們，不相容介面間適配器（Adapter）是個不錯的途徑；

那麼資料領域是否也有類似的技術呢？ XML Schema +

XSLT

也許就是個選擇。

上面是為了相容新、舊用戶實體所做的轉換，同樣的如果需要進行上部分針對不同主體的資料實體聚合操作也完全可以藉助在抽象資料定義（Schema）層級透過XSLT（Schema間的適配關係）完成。

這樣，我們可以在資料實體層次看到資料是如何聚合在一起的，但之前還需要解決一個問題：車輛資訊、信用資訊還有遺留系統的客戶資訊都是分別保存在關聯式資料庫和合作夥伴的Web Service中，如何連結這個資料管道呢？從現在看XML還是不錯的選擇。

不同資料媒體上的資料可以以他們本來源的形式提取，例如平文本、關聯式資料庫、EDI訊息或是SOAP訊息，透過不同的資訊管道傳遞到資料集成的匯聚點，然後根據目的資料來源的需要，透過一個適配器轉換異質的資料來源。

這時候如果為每兩種類型都設計一個點對點的適配器，整體規模將沿著N^2級的趨勢發展，為此不妨先把他們統一為兼容這些信息的XML，然後用上面介紹的XSLT技術進行資料實體間的映射後，接著把XML再轉換成目標資料來源所需的形式，這樣整個適配體系複雜度降為N級。

接著，我們來看看XML技術如何滿足只前提的那些資料整合要求：

l 資料實體的對應、資料媒體、資料載體的轉換、資料實體的驗證與重構：

如上，先把資料統一轉換成XML，再透過XML層次型優勢，結合XML專用技術處理。

l 資料來源的在各種交換協定、行業資料標準、安全控制約束下的互聯；

XML資料不僅可以跨越網路、防火牆，而且可以很容易的用於互聯網環境（，不過您依然可以用訊息佇列方式把他們定義為封包），資料本身不會因為特殊的二進位作業需要受到交換協定的限制。目前，各個行業標準基本上都在使用XML描述自己的行業DM（Data Modal），即便您企業內部的系統本身數據實體由於數據庫設計、歷史遺留等問題，本身不是符合這些DM的數據，但各種XML資料統一治理的協定和標準可以比較方便的實作轉換。對於安全性，似乎還有沒比基於WS-*相關協定更適合於網路環境下的安全標準家族，其中所有的標準無一例外都可以用XML實體定義資料和額外安全機制間的組合關係。

l 資料交換過程的編排；

對於同構系統環境，或僅基於相容中間件系統的平台，可以採用遺留的工作流程機制實現數據交換過程的編排，但為了適應服務化的時代，可以採用更通用的BPEL標準，此時XML不僅僅是數據，同時他也作為執行指令的形態出現，相比較一直標榜跨平台的Java技術而言，採用XML定義的交換過程更是跨語言的。

似乎整合已經解決了很大的問題，但一個顯而易見的問題是所有的工作我們可能都要自己做一些實現，一步步告訴應用怎麼做，那麼當我們不再把Web僅僅當成“新事物”，而把它考慮成一個服務於我們資訊內容，並且可以互動的系統時，如何把這些散落的服務能力呈現給我們自己呢？這時候也許XML開放的元資料定義的優勢才真正體現出來。

應對語意網路的複雜性

除去各種語意演算法以外，如何讓分散的各種繁多的服務聚合在一起為我們提供服務，其中XML一個非常關鍵的因素就是找到資料線索的主幹，而且明確這條主幹上實體間的關聯關係及其逐步分解細化的過程。這個層次的資料不僅是被動由應用程式呼叫的對象，他們本身為應用共了進一步推論的支持。例如：

這裡首先應用了解到目前處理的這個對像是鵝肉，由於鵝肉是一種黑肉，而黑肉是某種禽肉（fowl），禽肉可以食用，因此應用可以逐步推斷鵝肉可以食用。上面的推論過程並不複雜，但如果用關係資料庫實現卻相對比較複雜，用平文本書寫那就更難於實現了，試想一下如果同時把禽肉與蔬菜、甜點、海鮮間的關係全部用關係資料庫或文本書寫，那實在太「難為」應用了。而XML不同，它可以很自然的貼近我們思維的習慣，以一種開放但又交織的辦法描述我們熟悉的語義，無論是企業ERP環境的生產材料準備過程，還是為了一次生日Party準備自己下廚的採購計劃，亦然。

小結

也許受限於二維格子的約束太久，我們對於應用的設計和想法越來越桎梏於計算機的處理本身，但隨著業務環境的變化，從業務需求發生到應用實現並上線的間隔越發短促，我們要更多把自己的思維重新從計算機中抽回來，這時候採用一種更開放並貼近我們發散型思維的數據技術似乎更可取。對於資料落地後的組織，我們可以繼續採用各種成熟的技術完成，但在更貼近業務的層面、貼近這種更易變的環境下，似乎XML柔性和力道都不錯。

以上是詳細介紹使用XML化的思維組織資料（圖）的詳細內容。更多資訊請關注PHP中文網其他相關文章！