據我了解的一些企業，這最近幾年企業資訊化過程中系統沒有少上，什麼
erp，
pdm，
csm，
dserp
等算起來將近有七八套，在一定程度上提高了企業的資訊化管理水平，但是又迎來了另乙個問題。企業的許多資料在不同的系統中需要維護，經常會出現不同的系統間資料不一致的問題，這就需要各系統之間進行整合。由於各系統架構不一致，所以目前採取的方式主要是資料級別的整合。
我總結了一下，根據實時性資料整合可以分為兩種，實時性和非實時的。目前採取的方案是非實時的，對於各系統間需要整合的資料，是由乙個系統定時匯出成
xml格式的資料，然後由另乙個系統定時來處理。非實時的系統比較容易實現，不好的地方就在於不能實時實現各系統的無縫整合。而實時的系統資料整合就可以採用資料庫層的直接整合或者通過面向服務架構（
soa）來實現，對於不同廠家的產品，開放資料庫介面給其他廠商一般來說不太好接受，就是乙個公司的各個產品之間專案開放介面也比較難接受，個人感覺未來發展的趨勢主要還是利用
soa來實現資料整合。
關於soa，業界這兩年炒得很火熱，很多公司
ibm，
sap，
oracle
等都給出了自己的解決方案，方案多了讓人眼花繚亂，也不太好選擇，不過在
oracle
公司收購了
bea以後，他們在伺服器
+資料庫上的優勢使得他們的方案跟其他公司相比佔了不小優勢。
下面是我收集整理的一點對
oracle
的實時資料整合方案的資料，跟大家分享一下。
實時資料整合一般分為兩個處理過程：一是對資料按照
soa架構的需要進行整合加工形成可用的資訊，二是將資訊以符合
soa規範的方式發布出去。具體的實時資料整合模式可以按照對這兩個處理過程的不同分為以下四種：
第一種是在
中介軟體層上進行資料的加工整合，同時通過中介軟體層的標準介面將整合後的資料以標準介面發布。
在中間層上存在乙個虛擬的資料服務層，該層通過
jdbc
，file
適 配器、應用介面卡等與資料層的各種資料來源實現連線，將資料來源中的各種資料實體對映成中介軟體的虛擬資料層的表，虛擬資料層中的表都只有元資料，而不儲存實際 的生產資料。使用者可以在虛擬資料層上採用視覺化圖形介面定義資料對映關係，進行資料加工整合，這些資料加工邏輯一般會以檔案或者
資料庫方式儲存。定義好的資料可以通過
web service
，jdbc,
資料物件等多種方式發布出去。當使用者通過中介軟體訪問虛擬資料層的資料時，虛擬資料層會根據系統定義的邏輯首先將需要加工的細節資料從各個資料來源抽取到虛擬資料層，然後中介軟體根據設計時的資料加工邏輯對其進行加工，最後中介軟體將加工好的資料以呼叫介面要求的格式返回。
採用虛擬資料服務層的優勢為：
1.處理都在中介軟體伺服器上，相對來講，對資料的處理會比較靈活，應用和底層的資料實現松耦合。
2.當乙個請求涉及到多個底層資料來源時，對底層的資料訪問可以採用併發方式進行。
3.借助中介軟體的靈活性，資料可以採用多種方式對外提供介面，從而大大方便各種應用的開發。
4.所有的資料都是實時從資料來源取來，保證資料的時效性。
這樣做的問題是資料的處理在中介軟體層進行，一是帶來從資料來源到中介軟體層的資料傳輸，二是中介軟體一般都是
j2ee
架構，其強項並不是資料處理，在資料量不大時並無大礙，當資料量非常大時，其實現機制就注定了效率會出現問題。
第二種是在
資料來源層負責資料的加工處理，然後將整合後的資料以標準的介面發布到中介軟體層，由中介軟體層負責資料的訪問。
這種處理方式一般是
資料庫廠商或者
etl廠商推薦的方式，根據使用者的業務需求邏輯，首先在資料來源層通過
etl工具
設計資料轉化流程，然後將流程的轉化邏輯發布成
web 服務，同時將轉化後的資料也發布成
web服務，然後將這些服務註冊到中介軟體層，當前端使用者需要資料服務時，它需要呼叫兩個
web服務，第乙個是轉化
web服務，該
web服務呼叫相應的
etl工具對資料進行整合加工，然後將整合的資料儲存在臨時表中。第二個服務是呼叫資料服務，直接從臨時表中取出加工後的資料，與第一種模式的區別在於，它將資料的加工處理放在了資料來源層，其優勢在於：
1.etl
工具天生就是做資料整合的，而且適合大資料量的整合，所以針對大資料量效率會非常高。
2.在資料來源層整合可以充分利用資料庫的處理能力，畢竟資料庫才是做資料處理的行家。
3.依靠
e-lt
工具的變化資料捕捉功能，可以進行增量資料的處理。
4.資料轉化和資料獲取松耦合，可以實現非同步處理。
該模式的問題在於：
1.由於資料的加工處理依賴於資料庫的處理能力，因此在所有的資料來源中，必須有乙個為關係型資料庫系統，而第一種模式由中介軟體負責資料處理，資料來源沒有限制。
2.在應用的流程設計中，需要呼叫兩次
web服務，一次為轉化，一次為取資料讀取，資料量非常小的情況下，有點畫蛇添足的味道。
第三種是
將分散在資料層的資料先整合到
ods或者資料倉儲中進行整合加工，然後再將加工整理後的資料以標準介面發布到中介軟體層。
為了保證為企業提供乙個全域性的資料檢視，我們可以通過建立乙個全域性的操作型
資料庫ods(operational data storage)
，該資料庫與企業內的其它資料來源通過變化資料捕捉（
change data capture
）方式保持實時同步，當資料來源內的資料發生變化時，
cdc會捕捉到變化的資料並通過
etl工具或者其它手段（如主資料
管理工具）同步到
ods資料庫中。
最後一點就是資料的發布格式，在該模式中，中介軟體層負責資料的接入訪問，
ods裡的資料可以封裝成
web服務發布在中介軟體層。當前端業務流程需要整合的資料時，可以直接訪問
ods內的資料，如果資料整合比較複雜，我們可以根據使用者的業務需要，通過
etl工具或者其它工具（第二種模式）對統一模型層的資料進行加工放到彙總資料層，然後再從彙總資料層訪問資料。
第四種是
採 用資料網格的方式將資料層的資料整合在中間層，形成資料網格，中介軟體負責資料的加工，整合，然後以標準的方式發布出去。它和第一種方式非常相似，資料的整 合加工和發布都在中介軟體層上，唯一不同的是我們採用資料網格技術在中間層增加了一層物件快取層，資料的整合加工和訪問接入都發生在中介軟體層，當客戶端訪問 資料時，所有的流程方式都和第一種模式沒什麼區別，但需要訪問的資料都通過資料網格層快取在了中介軟體層，因此減少了資料來源訪問和網路傳輸的時間，訪問速度 會大大加快，從而可以在一定程度上解決第一種模式的不足，但資料處理仍然發生在中介軟體層，如果中介軟體處理能力有限，系統的效率還會受到侷限。
該模式的優勢：
1.系統擴充套件性好，資料網格層的擴充套件性決定了整個系統的擴充套件性。
2.當機器的處理能力不足時，通過集群方式可以大大提高效能。
3.真正實現了前台資料與後台資料來源的松耦合。資料網格負責與各種後台資料來源的互動。
他的問題是：
1.中介軟體層資料的加工整理過程仍然存在。
2.如果應用已經上線，需要針對資料網格提供的介面修改應用。
以上四個模式各有自己的應用範圍，從總體上看，資料的處理越靠近底層，效率越高，靈活性越差；越往上走，效率越低，靈活性越好；其實各種資料整合模式無所謂好壞，關鍵是看業務需求，只要能夠滿足業務需求就夠了。
系統整合的2種方式
我以前是不是寫過一篇類似的東西，說系統整合的 今天做乙個別的事情的時候，突然想到系統整合的問題。我覺得系統整合歸結來說只有2種方式。分別畫圖說明，圖略粗糙 1 從天上走 這張圖里，系統a和系統b，都開放了一些介面。實現方式可以有很多，web service rpc rmi，都有可能，總之是發布了介面...
Spring Struts整合的四種方式
1.在action中取得beanfactory物件，然後通過beanfactory獲取業務邏輯物件 web.xml 2 將業務邏輯物件通過spring注入到action中，從而避免了在action類中的直接 查詢,web.xml配置同上 在struts config.xml檔案中配置action 標...
CSS 清除浮動的N種方式
清除浮動主要是為了解決，父元素因為子級元素浮動引起的內部高度為0的問題。舉個例子 class content class incont div div content incont 此時元素是這樣的 如果我們讓其中的子元素浮動，那麼就會變成下面這樣，我們會發現父元素的內容區的高度不見了 接下來我們要...