<ruby id="rxdll"></ruby><strike id="rxdll"></strike>

    <rp id="rxdll"></rp>
      <del id="rxdll"><meter id="rxdll"></meter></del>
      <pre id="rxdll"><font id="rxdll"></font></pre>
        <pre id="rxdll"></pre>
      <p id="rxdll"><thead id="rxdll"></thead></p><dl id="rxdll"><progress id="rxdll"><form id="rxdll"></form></progress></dl>

      <ol id="rxdll"><thead id="rxdll"><track id="rxdll"></track></thead></ol>
      <i id="rxdll"><dfn id="rxdll"></dfn></i>
      <font id="rxdll"><meter id="rxdll"></meter></font>

        <mark id="rxdll"><dfn id="rxdll"></dfn></mark>
        • 軟件測試技術
        • 軟件測試博客
        • 軟件測試視頻
        • 開源軟件測試技術
        • 軟件測試論壇
        • 軟件測試沙龍
        • 軟件測試資料下載
        • 軟件測試雜志
        • 軟件測試人才招聘
          暫時沒有公告

        字號: | 推薦給好友 上一篇 | 下一篇

        IBM專家:好公司中的SOA[2]

        發布: 2008-7-17 11:02 | 作者: 網絡轉載 | 來源: csai | 查看: 49次 | 進入軟件測試論壇討論

        領測軟件測試網 在我看來,可能沒有受到足夠重視的一項技術是“信息作為服務”或 IaaS。其原理非常簡單:從技術和組織的角度將應用程序同信息分離,在應用程序與其使用的信息之間引入代理服務。應用程序領域屬于應用程序開發組織,而數據管理(或信息)則屬于數據團隊。應用程序團隊通過從接口規范派生的項訪問規范形式(還記得服務信息模型嗎?)的信息,對信息如何產生并不關心。數據管理團隊決定信息如何存儲及其存儲位置。

          在這二者中進行更改時,并不會對彼此造成影響。例如,在現有企業中一種常見的情況是,信息存在于數據中心中的多個位置。財務與采購部門可能具有自己的半自動數據庫,并具有自己的“供應商”定義的變體,所表示的供應商信息大量重復,但并不完全相同。業務部門可能會在某一點就“供應商”的規范定義達成一致。將通過信息服務訪問供應商(創建 (Creat)、讀取 (Read)、更新 (Update)、刪除 (Delete) 和搜索 (Search);簡稱 CRUDS);此信息服務使用從業務信息模型派生的服務信息模型。所有新應用程序應該使用規范形式,而且在可能的情況下,所有更新的應用程序也應該采用此形式。為了盡可能減小“對象模型阻抗”(對象模型間轉換的運行時與維護開銷),應用程序應該將供應商服務信息模型內部化。此工具可通過使用工具來方便地完成,此類工具可方便地生成服務接口中使用的元素的應用程序技術表示形式。例如,如果 IaaS 服務接口以 WSDL 表示,而應用程序技術是 Java™,大量工具都支持從 WSDL 接口定義生成 Java 類。無疑,應用程序可能需要根據其用途通過派生或封裝對生成的類進行擴展。

          現在讓我們回到供應商服務。數據團隊具有生成供應商服務的責任,而在 IBM Information Server 之類的產品中提供了支持此工作的工具。服務可能是熟悉的數據訪問技術上的 thin Facade,如嵌入式 SQL 或 SQL,或者最好是提供聯合、清理和轉換功能的現成軟件包。后一種方法將更好地促進對整個企業內的供應商不同表示形式的收集,并能幫助采用規范形式將其重新公開。此外,可以切實地通過工具的集成來優化數據治理的某些方面,以捕獲業務術語表、派生業務信息模型、管理信息服務和創建清理與轉換規則。

          順便提一句,我某天遇到過一個公司,他們的應用程序開發團隊非常關心對象到關系映射(Object to Relational Mapping,ORM)技術。讓應用程序開發團隊關心 ORM 是與封裝及分離對立的。ORM 可能(我并不推薦這種方法)在服務實現中會起到作用,而這是我們認為屬于數據團隊領域內的內容(您也這樣認為,對吧?)。我強烈建議使用框架或工具來避免這種有問題的數據管理方式。

          業務與 IT 的一致性

          讓我們把注意力轉到 SOA 引入耦合需求的另一個方面,營銷材料中將其稱為“一致性”。我將其目標視為業務與 IT 中的可變點的一致性。業務領域中的變量不應作為 IT 領域中的變量實現。我之所以在討論 SOA 時提到這個問題,是因為我們有時候會在討論服務接口定義(這對 IT 人員而言是變量)時遇到這個問題。

          以下是我最近看到的一個例子:某公司希望在整個企業和渠道內進行一致業務決策。他們明智地將業務邏輯提取到業務規則引擎中,并通過 Web 服務提供對業務邏輯的訪問。假定該服務為“getEligibleProducts”服務,業務規則使用關于客戶的已知事實來向客戶提供其可能感興趣的公司產品列表。第一天,當 IT 部門與業務部門一起決定服務的接口情況時,業務部門表示出了對在業務規則中使用客戶體重、身高和郵政編碼來計算合適的產品的興趣。創建、部署服務并至少由一個解決方案使用后,業務團隊提出他們希望添加規則,以將客戶年齡考慮進來。服務接口接受體重、身高和郵政編碼,但不接受年齡。IT 團隊估計至少需要一個月(有可能需要兩個月)來對服務提供者和使用者進行更改和執行必要的測試?上攵,業務團隊非常失望,因為“這個 SOA 原本應該讓 IT 更為靈活,但它卻使其變得更糟糕”。

          在我看到的這個特定示例中,IT 通過將關于客戶的每個已知事實(約 800 個元素)傳遞給服務,然后服務將使用其中很少的一部分(約 5 個元素)。其基于的想法是,無論業務部門希望在規則中包含任何事實,這些事實都對服務可用。由于 XML 具有非零處理開銷,而這增加了元素的復雜性和基數性(具體取決于服務的使用模式),因而此解決方案可能會帶來性能問題。從學術角度而言,它僅僅延遲了遲早需要解決的問題,因為在將來某個時間收集更多的事實時,將需要對接口進行更改。有很多替代解決方案的變體,但都歸結為,不要在 IT 領域的不可變概念中實現可變業務概念。一個建議的解決方案是,提高客戶機的復雜程度,從而在所需的變量中包含變量。服務接口將公開屬性容器,其中可以隨意包含與業務設想一致的屬性數量?蛻魴C將在服務注冊中心查找相關信息來確定服務需要哪些事實,并將其包含在容器中。顯然,這種方法缺少在服務接口中準確制定參數所帶來的開發類型安全,從而引入了對服務中進行更為安全的錯誤處理的需求,但您得做必須做的事。

          這些僅是眾多示例中的一部分而已,說明了 SOA 可能會如何影響組織間的耦合、關系以及交互(這些組織以前沒有交互,或者沒有很正式地進行此工作)。推出 SOA 可能是個挑戰,但其中充滿了樂趣,因此可以讓我知道您的 SOA 工作情況。

        延伸閱讀

        文章來源于領測軟件測試網 http://www.k11sc111.com/

        TAG: ibm IBM soa SOA 專家


        關于領測軟件測試網 | 領測軟件測試網合作伙伴 | 廣告服務 | 投稿指南 | 聯系我們 | 網站地圖 | 友情鏈接
        版權所有(C) 2003-2010 TestAge(領測軟件測試網)|領測國際科技(北京)有限公司|軟件測試工程師培訓網 All Rights Reserved
        北京市海淀區中關村南大街9號北京理工科技大廈1402室 京ICP備2023014753號-2
        技術支持和業務聯系:info@testage.com.cn 電話:010-51297073

        軟件測試 | 領測國際ISTQBISTQB官網TMMiTMMi認證國際軟件測試工程師認證領測軟件測試網

        国产女主播精品_国产片婬乱18一级毛片视频_国产午夜激无码av毛片不卡_国产精品欧美久久久天天影院
          <ruby id="rxdll"></ruby><strike id="rxdll"></strike>

          <rp id="rxdll"></rp>
            <del id="rxdll"><meter id="rxdll"></meter></del>
            <pre id="rxdll"><font id="rxdll"></font></pre>
              <pre id="rxdll"></pre>
            <p id="rxdll"><thead id="rxdll"></thead></p><dl id="rxdll"><progress id="rxdll"><form id="rxdll"></form></progress></dl>

            <ol id="rxdll"><thead id="rxdll"><track id="rxdll"></track></thead></ol>
            <i id="rxdll"><dfn id="rxdll"></dfn></i>
            <font id="rxdll"><meter id="rxdll"></meter></font>

              <mark id="rxdll"><dfn id="rxdll"></dfn></mark>