• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 181, 文章 - 2, 評論 - 85, 引用 - 0
            數據加載中……

            面向服務體系結構中的信息管理,第 2 部分: 研究 SOA 中信息管理的不同方法

            利用信息管理的強大功能來用于基于面向服務體系結構(Service-Oriented Architecture,SOA)的建模、構架、設計和實現。在本文的棧視圖中,展示了信息管理提供的各種服務,并有每種服務的詳細描述。作者從元數據管理和元數據集成的重要性說起,再轉到信息管理所提供服務的檢驗,然后是 SOA 案例學習。最后,作者將列出一些與所討論服務相關的工具。

            引言

            在本文的后半部分中,我們將對每種特定服務進行更深入的討論,例如:

            • 元數據管理
            • 提取、轉換和加載(Extract Transformation Load,ETL)
            • 聯(lián)合
            • 數據安置(如復制和緩存)
            • 數據建模
            • 搜索
            • 分析

            之后,我們將學習使用 SOA 來驗證數據質量的案例,并在最后列出用于各種服務的工具清單。在閱讀完本文之后,您將能更有效的利用信息管理的功能,來構建健全且均衡的 SOA,并進行信息和業(yè)務集成,避免常見錯誤,比如孤立的數據筒倉(silo)、數據不一致和未使用的信息資產等。







            SOA 不僅僅是 Web 服務

            圖 1 展示了信息管理提供的服務分類邏輯視圖,這些服務是基于以下方面進行分類的:

            • 安全性
            • 協(xié)作
            • 可用性
            • 可管理性
            • 信息消耗

            雖然沒有哪種單獨的產品能提供以上所有的服務,但將這些服務合在一起就可以創(chuàng)建 SOA 的完整信息管理框架。特別值得注意的是,某些文章將元數據管理置于信息管理棧的底部,在本文中我們認為,元數據管理是滲入其他服務并與其他服務緊密聯(lián)系的。事實上,SOA 是元數據驅動的構架(參見參考資料部分的文章 “Metadata Evolution Management in Your SOA")。因此,我們將在本文的后半部分從元數據管理開始說起。


            圖 1:SOA 中的信息管理
            SOA 中的信息管理






            元數據管理

            元數據、元模型以及元-元模型

            最常見的元數據定義是關于數據的數據——其實并不然。根據規(guī)范的不同,元數據所指的含義也將不同。基本上,元數據是關于數據的結構(語法)和含義(語義)的信息。元數據結構化方法的例子有關系數據庫管理系統(tǒng)(RDBMS)目錄、Java 庫目錄和 XML DTD 和 schema。這些每個都定義了數據是如何表示和使用的。從語義的角度來說,元數據提供了數據的含義。例子包括用數據字典、注釋或本體論(ontology)來描述。

            此外,還有用于內容管理的實例和類的元數據。實例元數據只是儲存在內容管理元數據儲存庫中的數據,并引用存儲在別處的對象,例如文檔、Web 頁面、音頻和視頻文件。分類和索引中的條目也同樣被認為是實例元數據。類元數據,從某種角度來說,和 RDBMS 目錄和 XML schema 意義相同,用來描述實例元數據的結構。

            元模型(也稱元-元數據)定義了元數據的結構和語義。標準元模型的例子包括 Unified Modeling Language(UML)和 Common Warehouse Meta-model(CWM)。元-元模型層由元-元數據的結構和語義描述組成。目前正試圖提供一種可以描述所有其他信息模型的通用語言。Meta Object Facility(MOF)是元-元模型的一個標準(參見參考資料部分)。


            圖 2:MOF 元數據構架
            MOF 元數據構架

            對元數據的生產者來說,遵循元模型、元數據接口、元-元模型和查詢語言方面的標準是非常重要的。通過這些標準,才能實現最大限度的互操作性,并可以服務于更多的元數據消費者,例如數據倉庫、分析和建模工具。SOA 正是依靠這些標準來實現生產者和消費者之間的動態(tài)匹配、監(jiān)控 BPEL 流,以及增強對 IT 資源和業(yè)務流程的跟蹤能力。

            元數據管理注意事項

            當我們重新設計元數據管理時,由于 XML 的普及,它顯然是元數據的缺省數據格式。對于單個供應商或是組織來說,通常首選是集中方式,用來實現元數據資產的重用,并減少開發(fā)的工作量,避免出現混亂。同樣,標準就是這個首選的方法。例如,IBM? 使用開放源代碼的 Eclipse Modeling Framework(EMF)作為通用的元數據集成技術。EMF 為工具和運行時提供了元數據集成。因此,在 EMF 基礎上開發(fā)的所有軟件都可以共享其它應用程序的通用方法。在理想的環(huán)境中(在短期內實現可能比較困難),元數據儲存庫可以儲存所有的元數據構件。服務由信息管理體構,例如在需要時,可以調用信息管理提供的服務(比如 SSO、ETL、聯(lián)合、質量、搜索、版本控制和工作流)以獲取數據、內容和元數據管理。

            對于 XML 儲存庫而言,有兩種常用的用來儲存 XML 元數據的儲存機制。分別為 RDBM 和固有的 XML 儲存庫。每種儲存機制都有優(yōu)缺點。起決定作用的因素包括性能、靈活性、帶寬、互操作性、用戶定義數據類型的支持以及數據質量的保證等。

            無論對于供應商、企業(yè)或是行業(yè)級別而言,在進行元數據管理時,聯(lián)合的方法都是更加實用的。虛擬的元數據儲存庫允許應用程序通過單個 API 訪問并聚集不同種類的元數據源。物理元數據構件可以被儲存在其初始的位置,也可以通過 ETL/replication/cache 方法來改進性能和元數據安置。在不同元數據源之間進行自動發(fā)現、映射和轉換對改進元數據的可管理性都是非常重要。

            數據、內容和元數據管理之間的關系

            一方面,元數據使程序間可以互相對話(實際上,供應商可調用它的元數據儲存庫 SuperGlue)。另一方面,元數據管理的需求與數據和內容管理是十分類似的。元數據管理需要提供關于安全性、協(xié)作、 QoS 和可管理性的相同的服務類型。元數據管理還要將 SSO、ETL、聯(lián)合、質量、搜索、版本控制、工作流和儲存持久性結合在一起。元數據管理在自動操作和編制(orchestration)方面的需求比數據和內容管理更多,因為元數據所服務的對象主要是計算機程序。

            不管怎樣,資產重用和服務編制可以通過在基于 SOA 且架構完善的信息管理基礎上構建元數據管理來實現。這就證明了將信息管理重新設計為基于 SOA 的可重用構件的重要性。

            元數據集成的難題

            前面已經說過,集成元數據比集成數據和內容更加復雜。許多因素都增加了元數據集成的難度。這些因素包括:

            • 元數據無處不在,且在許多情況下對用戶是不可見的。
            • 許多產品中的元數據和元模型都有其專有格式,特別是內容管理。
            • 在內容管理中,向內容中添加元數據。許多內容都缺乏元數據來進行集成和搜索。
            • 元數據集成相對數據和內容集成來說,需要更高級別的自動化和編制。這就依次需要更高級別的自動發(fā)現、轉換、映射和語義理解。
            • 為了避免失去當前客戶,供應商還可以選擇保持客戶的專有元數據格式。
            • 轉換到元數據標準(例如 MOF)需要時間和工作量。

            元數據集成的業(yè)務價值

            SOA 在很大程度上是元數據驅動的構架。要理解元數據集成的高級別業(yè)務價值,讓我們先進行全方位的概覽。圖 3 闡明了隨需應變業(yè)務上下文中元數據集成的重要性。基于信息標準,元數據可以實現無縫信息交換。給出良好集成的元數據后,信息可以在由操作系統(tǒng)、編程語言、位置和數據格式組成的邊界之間自由流動。因此元數據可以被認為是信息集成的“大腦”。此外,信息集成使得可以進行業(yè)務集成,業(yè)務集成既可以是跨企業(yè)中各部門的,也可以是跨企業(yè)邊界的。它提供以下內容:

            • 通過數據倉庫或聯(lián)合的方式,提供單一且完整的客戶、伙伴、產品和業(yè)務視圖。
            • 通過使用分析服務,使業(yè)務性能管理更加便利。
            • 通過廣泛的信息訪問來增強業(yè)務應用程序。
            • 通過持續(xù)的信息服務實現業(yè)務流程轉換。

            最后,業(yè)務集成是隨需應變業(yè)務的基礎之一。通過使用 IT 技術服務于業(yè)務目標(而不是相反),使業(yè)務集成與之前的 Enterprise Application Integration(EAI)區(qū)別開來。因此,說元數據集成是隨需應變業(yè)務的“大腦”一點都不夸張。


            圖 3:元數據集成是隨需應變業(yè)務集成的大腦
            元數據集成是隨需應變業(yè)務集成的大腦

            高級元數據集成價值的例子包括:

            • 有助于來自不同源的數據/內容集成。
            • 縮短新應用程序的上市時間,并允許更快速的應用程序集成
            • 改善企業(yè)內部或企業(yè)之間的業(yè)務集成流程
            • 通過完整的集成信息分析,提供了全新的認識
            • 通過變更管理和預測分析,進行結果分析





            數據和內容聯(lián)合:分散式方法

            聯(lián)合的概念是指將資源集看作單個資源來進行查看和操作,且保持其自治(對當前的應用程序或系統(tǒng)影響極少或沒有影響)和完整性(不會破壞當前應用程序或系統(tǒng)中的數據或內容)。不用說,自治和完整性是聯(lián)合的兩個重要前提。

            自 20 世紀 90 年代后期,數據聯(lián)合已經作為與集中方法截然不同的一種方法而出現了。在分散方法中,使用了數據市場(mart)和倉庫。數據聯(lián)合力圖將數據放在其原始位置上,并創(chuàng)建虛擬數據庫。類似地,最近出現的內容聯(lián)合可以用來訪問并聚集不同的內容源。這些分散的方法相比集中化方法而言,減少了數據和內容冗余、帶寬、儲存、實時同步以及額外的管理費用。對分布式信息源的實時訪問同樣為業(yè)務智能帶來了新的性能,這應該遵循法定和管理需求。對于開發(fā)人員來說,數據聯(lián)合減少了為不同的數據源編寫和維護自定義 API 的需求,以及對高度專門技能的需求。

            對于數據聯(lián)合而言,最需要關注的就是其性能。要改進性能,聯(lián)合需要經常使用緩存、物理查詢表(MQT)以及分布式查詢優(yōu)化和執(zhí)行。高速緩存和 MQT 在聯(lián)合的服務器上創(chuàng)建并管理表,這些服務器可以是目標聯(lián)合數據源的全部或是其中的一部分。作為一種 cutting-edge 工具,IBM WebSphere? Information Integrator 考慮了以下方面:

            • 源數據(例如基數或是索引)的標準統(tǒng)計
            • 數據服務器性能(例如連接特性和內置功能)
            • 數據服務器容量
            • I/O 容量
            • 網速(請參閱參考資料部分的 IBM Redbook,“DB2II: Performance Monitoring, Tuning and Capacity Planning Guide”)






            ETL:集中方法

            提取-轉換-加載(Extract-transform-load,ETL)是用于數據集成的最古老的技術之一,且和數據儲存和業(yè)務智能緊密結合。該方法可以用于數據合并、遷移和傳播。ETL 工具從一個或是多個數據源中提取、轉換和加載數據至其它目標。ETL 曾經一段時間是信息集成的主要方法且至今仍舊運用十分廣泛。與直接的提取和加載操作不同,轉換是最復雜的部分。因為在此過程中需要對數據進行理解、轉換、聚集和計算。由于高費用、較慢的周轉周期以及數據源中不完整的信息集而使 ETL 和數據倉庫的優(yōu)勢大打折扣。

            集中式和分散式方法互補,將兩者結合在一起會產生很多的優(yōu)勢。

            集中式方法包含了以下一些方面:

            • 訪問性能或可用性需求需要集中數據。
            • 當前需求要求時間點一致性,例如業(yè)務關閉。
            • 需要進行復雜轉換,以實現數據的語義一致性。
            • 集中化方法通常用于生產應用程序、數據倉庫和操作數據存儲庫。
            • 集中化方法通常由 ETL 或是復制技術來管理。

            分散式方法包含了以下需要考慮的事項:

            • 源系統(tǒng)的訪問性能和負載的提高可以降低整體實現的費用。
            • 當前需求需要數據的最新副本。
            • 數據安全性、許可限制或行業(yè)規(guī)則限制了數據傳輸。
            • 分散化方法可以結合復合格式數據,例如客戶 ODS 與相關的契約文檔或是圖象相結合。
            • 查詢需要實時數據,例如股票報價、現有存貨目錄






            數據復制和事件發(fā)布

            數據復制使數據的副本從一個位置移到另一個位置。目標位置可以是集中的位置,例如數據倉庫,也可以是網絡上另一個分布式位置。在網格環(huán)境中,復制和緩存服務用來創(chuàng)建 Placement Management Service 以滿足服務質量 (QoS) 目標。根據訪問模式和消費應用程序位置的不同,Placement Management Service 通過創(chuàng)建緩存或是副本(參見參考資料部分中的 “Towards an information infrastructure for the grid” 一文)來提高相應時間以及信息可用性。在 Web 應用程序環(huán)境中,當數據或是內容已經準備好被發(fā)布用于公共消費時,數據和內容復制通常用來將數據或內容從分段服務器(通常只是管理員使用的服務器)轉移到生產服務器。分段數據管理使組織能夠更好的控制信息流和信息的生命周期。例如,一個 Web 站點支持多國語言。當一段數據或內容元素需要在網站上發(fā)布之前被翻譯,則首先需要將其傳給分段服務器。只有在被翻譯完并被管理員許可以后,才可以復制給生產服務器并進行發(fā)布。

            復制可以與集中式或分散式方法共同使用。ETL 和數據復制間主要的區(qū)別是, ETL 通常在應用了數據過濾和轉換規(guī)則后,將數據移動到集中位置,這要花費更長的時間,并移動更多的數據。數據復制移動的數據集就小很多,可以更自動化的方式移動到集中的或是分散的位置。數據復制可以對數據進行實時或是近實時訪問。ETL 的主要目的是分析并監(jiān)控數據,并生成業(yè)務智能。但數據復制的目標更多的與性能、數據管理和數據可用性相關。最后,ETL 和數據復制可以互補,換句話說,可以使用數據復制功能更快地將數據移動到數據市場或是存儲庫,ETL 中的數據轉換功能可以提供數據復制領域更大的靈活性和更高的數據質量。為了重用不同工具的邏輯,需要有易于調用且松耦合的信息服務。

            和 ETL 以及數據復制不同,事件發(fā)布并不清楚數據的去向以及如何使用數據。源表的變更將以 XML 格式或是其它數據格式發(fā)布到消息隊列。應用程序負責檢索已發(fā)布的事件并采取適當的操作,例如觸發(fā)業(yè)務流程或在將數據應用到目標數據源之前對數據進行轉換。松耦合架構將服務提供者和消費者分離,并允許數據事件獨立于應用程序。







            邏輯數據和語義信息建模

            邏輯數據建模是軟件開發(fā)的最佳實踐之一,也是當開發(fā)組織在時間和預算壓力之下很容易被忽視的地方。雖然在內部開發(fā)過程中經常忽略邏輯數據建模,但組織經常購買獲得 企業(yè)資源規(guī)劃(Enterprise Resource Planning,ERP)、客戶關系管理(Customer Relationship Management,CRM)或是其他類型的包。結果是,許多版本的數據模型引用了組織內的同一個事物,且每個數據源都有自己的數據模型和元模型。例如,引用了客戶的不同的項,CRM 稱其為 customer,記賬系統(tǒng)中稱其為 client,而銷售系統(tǒng)中稱之為 buyer,這種情況并不少見。教科書和理論家力圖從邏輯企業(yè)數據模型開始,再轉至物理數據模型(例如實體關系圖)、代碼生成和開發(fā),但是在實際中順序卻經常顛倒過來。

            在實踐中,組織常分階段構建、購買或是獲取數據庫,且數據保持被隔離的狀態(tài)。有時這些組織認識到需要對數據進行集成。那么接下來要怎樣實現呢?通常會鉆研大堆的文檔、成千上萬的代碼行以及海量的數據,來發(fā)現其生產和消費的信息類型,更不用說這些組織要發(fā)現和記錄各種數據模型和業(yè)務流程之間的相互關系了。在這種情況下,自動數據發(fā)現和概要工具可以加快這些流程,并減輕執(zhí)行這些任務的復雜性。許多組織在最后將得到邏輯企業(yè)數據模型,這樣單獨的系統(tǒng)就可以被映射到公共邏輯模型上。轉換在一些案例中需要用到,例如貨幣間的轉換。最終,物理數據模型被映射到企業(yè)數據模型——即企業(yè)共享的公共邏輯數據模型。如果企業(yè)數據模型在一開始就被設計為模型驅動架構(Model Driven Architecture)的一部分,那么該模型就可以最大限度的發(fā)揮其優(yōu)勢。不過,逆向的工程步驟也是非常有價值的。企業(yè)數據模型的主要優(yōu)勢在于:

            • 提供企業(yè)信息資產的概覽。
            • 增強使用 IT 技術來支持業(yè)務流程的實踐。
            • 減少企業(yè)信息集成(Enterprise Information Integration,EII)、企業(yè)應用程序集成(Enterprise Application Integration,EAI)以及數據存儲的費用和風險。
            • 提供對數據、元數據和元模型的基于資產的重用。
            • 提高數據和元數據質量。
            • 便于業(yè)務分析員、數據建模者、開發(fā)人員和數據庫管理員之間的通信。

            語義信息建模(本體)不屬于邏輯數據建模,它對數據的語義(含義)和關系建模。它合并了多個知識領域的詞匯(術語和概念)。語義信息建模可以出色地解決許多難題,例如以下問題(參見參考資料部分中的 “Sematics FAQs” 一文):

            • 信息集成
            • 模型轉換
            • 解釋
            • 數據凈化
            • 搜索
            • 導航
            • 文本理解
            • 文檔準備
            • 語音理解
            • 問答






            數據概要(Data profiling)

            數據概要是發(fā)現以下方面的流程:

            • 數據格式
            • 模式
            • 特性
            • 規(guī)則
            • 隱含關系

            數據概要同樣提供了很多的優(yōu)點,包括:

            • 改善組織對數據的理解。
            • 有助于電子數據管理(Electronic Data Management,EDM)。
            • 便于數據映射和轉換。
            • 提高數據質量。
            • 構建性能調整的基線。
            • 協(xié)助語義建模。

            數據概要旨在更好的理解信息并創(chuàng)建關于對象的更多元數據。






            數據、內容和元數據質量

            數據質量將影響企業(yè)信息管理策略的成功與否,企業(yè)信息管理策略決定了其業(yè)務集成策略的成敗。數據質量問題被認為是數據儲存項目失效的主要原因之一。低質量的數據會導致誤傳的決策、無效的操作和錯失機遇,并且有時還會受到來自組織或市場的懲罰。 數據質量并非華而不實,它已經成為業(yè)務的關鍵操作要素。

            數據質量問題的例子如下:

            • 丟失所需域的數據
            • 不一致的數據條目
            • 不正確或不準確的數據條目

            由于數據質量工作固有的復雜性,一些組織選擇將這些工作外包給第三方服務提供商。我們將在本文后面部分的案例學習中看到。

            內容質量經常被部分忽視,這是因為評估內容質量比評估數據質量更困難。畢竟內容是非結構化的,且質量標準更加主觀和隨意。內容質量通常不包含在技術項目范圍之內。從組織的角度來說內容質量并未得到重視。但是,在 SOA 環(huán)境中,因為 SOA 不固定的特性而使內容質量變得更加重要。如果錯誤數據或是質量次的內容沒有及時發(fā)現,就會到處傳播。內容質量標準由于內容類型的不同而有所區(qū)別,但是評估內容質量還是有一些共同的標準,如以下所示:

            • 關聯(lián)
            • 及時
            • 截止時間
            • 內容確認
            • 等級
            • 副本
            • 鏈接檢查

            由于對元數據管理能力需求的增長,元數據質量最近受到更多的關注。改進數據質量的技術,例如標準化、概要、審查、凈化、轉換和確認,都可用來改進元數據質量。

            強數據類型是跨不同的編程語言和硬件確保 XML 數據值一致性的關鍵。但是,當前 XML 技術只允許單個文檔的 schema 確認,卻沒有一種有效的方法來跨不同的 schema 和數據源(比如在關系數據庫和 OO 數據類型工具之間)驗證數據類型(包括用戶定義的數據類型)并實施語義強類型。僅僅 XML 文檔類型定義(DTD)或 schema 的標準化(許多行業(yè)試圖用這種標準化來作為該問題的解決方案)是不夠的,因為當需要在多個行業(yè)之間集成數據時(這是隨需應變業(yè)務的一個基本需求。),XML DTD 或 schema 驗證、語義一致性和兼容性方面的問題仍舊存在。







            搜索和查詢

            在企業(yè)搜索中,搜索分許多類型:關鍵字、布爾值、范圍、多層面元數據(faceted metadata)、語義、自然語言和參數化。不論用哪種搜索,目的都是為了提供統(tǒng)一、相關并排序的結果集,從而可以快速且方便的訪問信息。為便于搜索,可以使用索引(indexing,請不要與關系數據庫中的索引混淆)來索引非結構化內容(例如 Web 頁面、電子郵件數據庫或是文件系統(tǒng))的關鍵字、概念和實例元數據,使這些內容可以被搜索和檢索。關系數據庫也可以被編入索引,以進行更快和更靈活的搜索。

            雖然許多組織認識到集成結構化和非結構化信息的重要性,但目前的搜索結果仍舊互不相干。用戶想要的是指向潛在相關信息的一系列鏈接。用戶不得不對搜索結果慢慢的瀏覽檢驗,以找到所需的信息并與其最初的查詢目的聯(lián)系在一起。這基本上是手動的流程。我們認為迫切需要研究使用搜索和查詢在數據和內容之間實現一項查詢,一組結果集

            數據庫通常都自帶搜索功能。最常見的搜索功能是使用 SQL 和 XQuery 之類的查詢語言。用數據庫搜索來檢索結構化且嚴格匹配的數據十分管用,但這需要對查詢結構和數據模型十分熟悉和了解才行。數據庫搜索的用戶大都是開發(fā)人員或是數據庫管理員。另外,數據庫搜索不適合于相關排序、模糊搜索和多關鍵字。因此,數據庫搜索的使用受到了很多限制。為實現高性能、靈活性以及相關排序等,一些搜索引擎與數據庫直接相連,從數據庫提取數據并生成索引。一個例子就是 IBM WebSphere OmniFind。







            分析

            在先前 ETL 部分我們已經闡明,數據倉庫將數據合并到中央位置以確保更好的進行決策、跨部門報告和數據挖掘。傳統(tǒng)的分析包括報告、數據挖掘、儀表板(dashboard)、記分卡和業(yè)務性能管理。隨著競爭日趨激烈,操作變得越來越復雜,規(guī)則也隨著更加嚴格。組織需要實時訪問不同的數據源來做以下改進:

            • 使用集成信息預測市場趨勢。
            • 更好的了解客戶。
            • 提高操作效率。
            • 確保遵循規(guī)則。
            • 獲取新知識。

            所有這些趨勢使得對信息管理分析能力的需求不斷增加。分析變得越來越重要。例如,如果銷售商知道現有客戶的合同、服務經驗和其行業(yè)趨勢、其競爭者和客戶,他(或她)就可以更好地為客戶定制專門的銷售建議。最近,分析經常需要在不同的信息源間進行信息集成。例如,要評估質量,汽車制造商需要將事故報告(存在文檔管理系統(tǒng)內)、經銷商的修理記錄(存在關系數據庫內)、司機的風險因素以及環(huán)境因素(存在知識管理系統(tǒng)內)相關聯(lián)。在未來,通過分析將能夠更加智能化的訪問并關聯(lián)不同的信息源的信息,從而提供新的市場洞察和業(yè)務決策。







            相關服務

            以下服務被稱為“相關”服務,并不是因為它們對于信息管理而言不重要,而是因為他們對于業(yè)務流程和應用集成來說十分常見。

            SSO、訪問控制和審查

            單點登錄(SSO)到不同信息源、訪問控制、審查對信息的查看和修改,這些共同構建了信息管理安全環(huán)境的基礎。SSO 對用戶提出您是誰的問題,訪問控制則提出您可以做什么,審查隨時跟蹤您已完成的操作。SSO 的優(yōu)點很多:減少用戶受挫的可能、降低開發(fā)工作量并提高效率。訪問控制確保只有擁有正確權限的用戶才能訪問數據和內容。一些業(yè)務需要非常復雜的訪問權限管理,例如 Digital Rights Management。審查服務為數據和內容提供了額外的保障。查看、插入、修改和刪除信息操作都能被審查并被報告。隨著對安全性和規(guī)則靈活性的需求不斷增長,SSO、訪問控制和審查服務的結合為企業(yè)信息管理打下堅實的基礎。

            工作流和版本控制

            工作流和版本控制都設計為促進團隊環(huán)境中的協(xié)作。在通過版本控制建立一致點時,數據、內容和元數據管理、應用程序代碼開發(fā)和流程都需要工作流,從而允許人們進行協(xié)作,以便之后將這些一致點返回給版本控制。工作流將用戶、流程和信息鏈接在一個系統(tǒng)中。系統(tǒng)的每個部分——人、流程和信息——都是高度交互的,且它們之間的交互甚至更加動態(tài)。例如,一家公司編寫了一個程序使每個雇員都可以提交自己對任何主題的建議。根據建議類別的不同(信息),這些建議將被不同的人發(fā)送、評審和處理(流程)。因此,需要一個高度健全且合適的工作流來處理不能預料的情況。一旦開發(fā)了這樣的工作流服務,不用的應用程序可以對其進行調用,這些應用程序包括文檔管理、HR 系統(tǒng)或者知識管理。

            門戶

            業(yè)界分析家預測,結合了 Web 服務的企業(yè)門戶將未來的十二個月內實現。門戶集成了應用程序和信息,并通過統(tǒng)一的視圖將其呈現給最終用戶。由于 EII 提供了抽象層,開發(fā)人員可以訪問并匯集不同的信息源、維護代碼并實現性能和安全性需求,而無需編寫自定義適配器。因此,應用程序開發(fā)可以節(jié)省大量的時間、花費和技能需求,且門戶用戶可以輕松訪問各種廣泛的信息。最重要的是,可以對端到端業(yè)務流程進行輕松且快速的集成。







            案例學習:數據質量服務實例

            信息管理棧中的企業(yè)搜索、數據質量與驗證,以及分析等服務通常是外購的不錯選擇。SOA 下的信息管理框架確立了一個新的業(yè)務模型,該業(yè)務模型越來越受到使用者的歡迎。讓我們看一個案例學習,該案例通過 SOA 提供了數據驗證服務,這種服務也是一種數據質量服務。

            為了防止出錯和欺詐行為,或是為了遵循相關法律和規(guī)定(比如 Sarbanes-Oxley),許多電子商務公司需要實時檢驗地址、電話號碼以及社會安全號碼等識別信息。由于數據質量確認的復雜性,一些公司訂購了由第三方提供的數據驗證服務,而不是開發(fā)內部解決方案。一些公司提供數據驗證和質量服務,并提供網上的實時地址和電話號碼驗證。在客戶填寫了電子商務應用程序并在線提交后,電子商務公司將客戶信息封裝至 XML 文檔并通過 Web 服務、簡單對象訪問協(xié)議(Simple Object Access Protocol,SOAP)和 Web 服務描述語言(Services Description Language,WSDL)將其發(fā)送到數據驗證公司。數據驗證公司將在相同的客戶事務中,對數據進行實時驗證。對于客戶而言,他們將獲得及時的反饋,并能夠糾正或取消事務。

            在過去,如果在流程中數據出錯,電子商務要在數天甚至數月以后才能收到不能投遞的地址或是電子郵件。同時,客戶還不明白他們的帳戶出了什么問題。使用 SOA 進行數據驗證服務,使電子商務公司從維護和更新數十億字節(jié)的數據庫信息的重擔中解脫出來,這些數據庫信息包含數百萬來自不同城市和地域的用戶姓名、電話號碼和有效地址。







            結束語

            作者闡述了信息管理提供的每個服務,并特別關注元數據管理和集成。雖然服務的種類有很多,但這些是至關重要的,如果您還記得下列價值取向,可以參閱信息管理的要點:

            • 安全性
            • 協(xié)作
            • 服務質量
            • 可管理性
            • 消費

            希望本文可以使您意識到信息管理的重要性和其涉及的廣泛領域。通過掌握單個部分和它們之間交互的知識,您將能更有效的利用信息管理的優(yōu)勢,以構建健全且均衡的 SOA。

            致謝

            在此,作者感謝 Susan Malaika 和 Norbert Bieberstein 對本文提出的有價值的反饋,并感謝 Robert D. Johnson 的支持。

            IBM 信息管理產品

            下表展示了信息管理服務和實現這些服務所需的 IBM 相關產品

            表 1. IBM 信息管理產品

            信息管理服務 IBM 產品
            分析 DB2? Data Warehouse Edition; DB2 Cube Views; DB2 Alphablox; DB2 Entity Analytics
            內容聯(lián)合 WebSphere? Information Integrator, Content Edition
            數據聯(lián)合 WebSphere Information Integrator
            數據建模 Rational? XDE; alphaWorks Data Architect for DB2 Document Management
            數據概要 WebSphere ProfileStage
            數據質量 WebSphere QualityStage
            ETL WebSphere DataStage;DB2 Warehouse Manager
            邏輯和語義信息建模 IBM Research Ontology management system (Snobase)
            元數據儲存庫 WebSphere MetaStage;alphaWorks XML Registry
            搜索 WebSphere Information Integrator OmniFind Edition

            posted on 2006-04-17 03:36 wsdfsdf 閱讀(160) 評論(0)  編輯 收藏 引用 所屬分類: 技術文章

            四虎国产永久免费久久| 色综合久久无码五十路人妻| 久久亚洲国产精品一区二区| 99久久精品免费看国产一区二区三区| 久久精品国产免费一区| 久久国产精品一区| 99久久国产宗和精品1上映| 久久精品中文闷骚内射| 狠狠色伊人久久精品综合网 | 精品无码久久久久久尤物| 久久久久久亚洲AV无码专区| 狠狠色噜噜狠狠狠狠狠色综合久久| 久久成人精品| 国内精品久久久久久久97牛牛| 久久中文字幕无码专区| 九九99精品久久久久久| 色综合久久夜色精品国产| 97超级碰碰碰久久久久| 久久精品国产乱子伦| 国产精品免费久久| 波多野结衣中文字幕久久 | 久久99免费视频| 久久久这里有精品| 久久精品人妻一区二区三区| 成人综合伊人五月婷久久| 一本久道久久综合狠狠爱| 欧美午夜A∨大片久久| 99久久精品免费| 成人亚洲欧美久久久久| 精品久久久久久中文字幕| 久久免费的精品国产V∧| 久久久国产精华液| 亚洲国产精品综合久久网络| 久久久国产精品| 久久久久久一区国产精品| 久久精品一区二区三区中文字幕| 国产99久久精品一区二区| 69久久精品无码一区二区| 久久精品人人做人人爽97| 久久国产精品成人片免费| 久久亚洲欧美国产精品|