国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

系統(tǒng)集成需要用到廣泛的信息技術(shù)（請看圖1）：

企業(yè)應(yīng)用集成（Enterprise application integration， EAI）：直接通過Intranet連接兩個或者多個商務(wù)應(yīng)用（更確切地說，是跨越企業(yè)防火墻的連接）

B2B集成（Business-to-business integration ，B2BI）：直接通過Internet或是虛擬專用網(wǎng)（virtual private network，VPN）連接企業(yè)及其商務(wù)伙伴的應(yīng)用。

用戶界面集成（User interface (UI) integration）：整合并且個性化多個應(yīng)用系統(tǒng)的用戶界面，使用戶可以使用一個統(tǒng)一的“Web流”（比如一個門戶中的Java頁面流），從而把這些全異的后端系統(tǒng)整合到一塊。

       數(shù)據(jù)集成（Data integration）：把全異的應(yīng)用以及數(shù)據(jù)存儲中的數(shù)據(jù)整合到一起，從而定義一個統(tǒng)一的業(yè)務(wù)對象視圖——比如，通過合并客戶關(guān)系管理（CRM）系統(tǒng)以及企業(yè)資源規(guī)劃（ERP）系統(tǒng)等多個系統(tǒng)中的數(shù)據(jù)從而創(chuàng)建一個統(tǒng)一的“客戶”模式。

（注意：因為專有的系統(tǒng)集成技術(shù)通常需要用戶在所有參與節(jié)點運行特定供應(yīng)商提供的軟件，說服一個跨國企業(yè)以及它所有的商業(yè)伙伴運行同一個專有的系統(tǒng)集成軟件是不可能的事情。）同時，系統(tǒng)集成費用仍然是高昂的——通過各種方式它消耗了70%以上的IT建設(shè)自由支配資金，但是仍然保持著十分混亂的狀態(tài)，從而使企業(yè)傾向于僅僅把各種各樣的應(yīng)用連接到一起，好象這變成了一種商業(yè)義務(wù)。

很顯然，這個行業(yè)必須做得更好才行。我們堅信它會更好，因為我們可以從用戶界面平臺中擴展出Web應(yīng)用（也就是現(xiàn)在的瀏覽器到數(shù)據(jù)或應(yīng)用的體系結(jié)構(gòu)），從而造就一個統(tǒng)一的集成平臺。目前，大多數(shù)新的應(yīng)用已經(jīng)從一開始就具備了“支持web”的能力——即支持瀏覽器前端。我們主張將來的系統(tǒng)從一開始就要具備“支持web集成”的能力，也就是說，能夠被插入到新興的“基礎(chǔ)體系”中，這個“基礎(chǔ)體系”是由可擴展標記語言（XML）和Web 服務(wù)組成的，這兩項技術(shù)能夠使應(yīng)用程序和基于Web的其他應(yīng)用程序無縫地整合到一起。

       但是XML和Web服務(wù)僅僅定義了協(xié)議，也就是說，僅僅定義了標準的wire格式來保證互操作性。企業(yè)如何去做，才能在業(yè)務(wù)運行邏輯的規(guī)劃過程中，保護自己的投資呢？業(yè)務(wù)運行邏輯的任務(wù)是將web應(yīng)用粘合到一起。如同Servlet，JSP，以及ASP這樣的應(yīng)用編程標準對于Web的成功十分重要一樣，集成規(guī)劃標準對于基于Web的系統(tǒng)集成也是至關(guān)重要的。

       事實上，很多在這種“巨大改變”中必不可少的基礎(chǔ)結(jié)構(gòu)標準都已經(jīng)存在了。

如同先前曾經(jīng)出現(xiàn)的情況——大家都來支持Web應(yīng)用的開發(fā)——一樣，系統(tǒng)集成市場在橫掃一切的標準化進程中也達到了平衡和統(tǒng)一。BEA已經(jīng)和我們的平臺競爭對手（主要是IBM和Microsoft）以及同盟進行了合作，目標就是把Web加入到系統(tǒng)集成的開發(fā)以及系統(tǒng)集成平臺——Web2.0中去。如果你愿意，你同樣可以加入這個聯(lián)盟！假設(shè)我們成功了（如同行業(yè)分析家們預(yù)測的那樣），Web應(yīng)用服務(wù)器（目的是為了支持web應(yīng)用程序的開發(fā)和托管）將會被Web應(yīng)用平臺所取代，后者包括了緊密集成的門戶、EAI、B2BI、以及數(shù)據(jù)集成技術(shù)。那時候，Web2.0對企業(yè)信息技術(shù)產(chǎn)生的影響將會遠遠超過Web1.0！

集成技術(shù)的層次關(guān)系

系統(tǒng)集成所需的各種技術(shù)的層次關(guān)系比較容易理解。我們推薦的分層方式如圖2所示。讓我們從下至上逐層分析。

中間件基礎(chǔ)結(jié)構(gòu)

所有系統(tǒng)集成產(chǎn)品（包括傳統(tǒng)的專有技術(shù)以及新出現(xiàn)的Web平臺技術(shù)）的基礎(chǔ)都是中間件總線，它提供了互連互通的機制并且保證了服務(wù)質(zhì)量。過去，系統(tǒng)集成行業(yè)廠商們選擇了工業(yè)標準的中間件（Java企業(yè)第二版：J2EE，或是基于.NET的技術(shù)）來開發(fā)和托管Web應(yīng)用，可是，當(dāng)整合多個應(yīng)用的時候它們卻采用了專有的中間件技術(shù)。

但是，web2.0將會構(gòu)建在一個既是開發(fā)平臺也是托管平臺的統(tǒng)一平臺之上。因此，標準的Web應(yīng)用服務(wù)器（Weblogic、WebSphere、.NET、等等）正在取代專有的集成中間件：目前已經(jīng)證明，對標準的Web應(yīng)用服務(wù)器進行擴充以進行集成比重新把專有集成方案的代理組件嵌入到符合Web標準的應(yīng)用服務(wù)器中要容易得多。（注意：大多數(shù)以往的專有集成方案提供商正在把應(yīng)用服務(wù)器技術(shù)納入到他們的下一代集成方案中去，這一事件成為這種融合趨勢的最好證明。當(dāng)然，這些供應(yīng)商也面臨著巨大的挑戰(zhàn)，因為，Web應(yīng)用平臺的領(lǐng)頭羊[BEA, IBM, Microsoft]多年前就已經(jīng)將該領(lǐng)域圈定為自家的“后花園”。）

應(yīng)用對外連接層

Web服務(wù)和適配器把Web集成平臺和其他應(yīng)用以及數(shù)據(jù)源連接到一起。在圖2中，盡管中間件層是綠色的（表示J2EE和.NET現(xiàn)在是成熟可靠的），但本層卻是紅綠結(jié)合的，這是因為必需的Web服務(wù)標準仍在不斷擴充。

XML/Web服務(wù)
Web服務(wù)只是簡單地在不同應(yīng)用之間傳遞XML信息。圖3顯示了Web服務(wù)所處的時間和位置，Web服務(wù)應(yīng)該成為應(yīng)用之間互操作的最佳方式。定義理想的粗粒度且持續(xù)穩(wěn)定的、能夠完美封裝應(yīng)用的業(yè)務(wù)接口是一種高超的技術(shù)，或者說是藝術(shù)。

商業(yè)應(yīng)用系統(tǒng)的架構(gòu)師們應(yīng)該仔細審視Web服務(wù)的這種候選方案。讓我們來看一下圖4中描述的一整套新興的XML/Web服務(wù)標準（也被稱為acronym soup，意為一鍋縮寫字頭組成的湯，這是因為這些標準又是建立在一大堆有縮寫字母表示的標準之上，其中包括SOAP、RPC、XML-RPC、以及HTTP等）。和前面的Web層次一樣，我們推薦采用一組基本的核心標準，通過這些標準“集成Web”將達到臨界狀態(tài)。

我們把一些特定的技術(shù)納入到了這組核心技術(shù)中，這些技術(shù)的基本規(guī)范中包括了對Web服務(wù)的互操作性（WS-I）進行驗證。（注意：目前，容器間的Web服務(wù)互操作應(yīng)該遵守XML Schema、SOAP1.1、以及WSDL 1.1這幾個標準中針對Web服務(wù)互操作的基本規(guī)范。如果你甘冒供應(yīng)商已經(jīng)作過測試的范圍之外的風(fēng)險，你很可能會在不同的容器之間遇到互操作問題——例如，WebLogic 和.NET之間的容器內(nèi)部互操作問題。然而，新的Web服務(wù)標準將不再有這樣的問題出現(xiàn)。）

針對Web服務(wù)的負載能力，一種以XML Schema為代表的，基于XML的模式語言，是最為適合它的。如果說XML Schema正在變成一種支持可互操作商務(wù)對象的混合語言，那么簡單對象訪問協(xié)議（SOAP）就是“可組合的”消息頭的框架，它可以提高在不同應(yīng)用之間傳遞那些商務(wù)對象的服務(wù)質(zhì)量（比如，安全性和傳遞可靠性。）

在利用Web服務(wù)時，程序員們不應(yīng)該為了得到松耦合特性而“生硬改寫”模式去適應(yīng)業(yè)務(wù)邏輯，盡管松散耦合曾經(jīng)造就了Web的巨大成功。

但是，松耦合并不是Web服務(wù)的固有特性——你必須通過編寫程序來實現(xiàn)它。（注意：Web的松耦合是指Web站點可以進行根本性的改變[比如從.NET移植到Java]，但是不會影響到最終用戶[用戶甚至不會感覺到ASP網(wǎng)頁已經(jīng)變成了JSP網(wǎng)頁]）。Web服務(wù)的松耦合是十分難以達到的。因為，盡管我們期望Web服務(wù)的“連接通道”的兩端可以各自接受修改，但Web客戶端[瀏覽器]以及瀏覽模式[HTML]是確定不變的。

如果你使用Java編程環(huán)境作為你的Web服務(wù)“設(shè)計中心”（就是說，從Java類自動生成Web服務(wù)定義語言[WSDL]），我們建議您使用“包裝器”類，而不是直接導(dǎo)出應(yīng)用對象。我們還建議您利用XML Schema的可擴展性模型，并且盡量使用上層的綁定方式，比如采用XML Query以及諸如XML Beans, JAX-B,和JAX-RPC這類的“模式編譯器”。這樣，開發(fā)者就能夠保證應(yīng)用程序或者Web服務(wù)接口的改變對另一方產(chǎn)生的影響最小。

我們建議在最終將會成為Web服務(wù)核心的那些標準上應(yīng)用以上這些由WS-I定義的基本規(guī)范。WS-Security提供了可選擇的加密方式（私有的）、認證方式，并且支持委托授權(quán)機制（安全上下文的傳播）。這些正在形成的OASIS（Organization for the Advancement of Structured Information Standards，

WS-RM和WS尋址使用存儲和轉(zhuǎn)發(fā)機制進入Web服務(wù)層，這一領(lǐng)域以往一直被像MQSeries這樣的面向消息的中間件產(chǎn)品所占據(jù)。盡管對于查詢操作來說，同步的Web服務(wù)更為適合，BEA仍然肯定地認為這種異步的Web服務(wù)是針對事務(wù)/更新的“最佳處理位置”。這也就是我們投入大量的精力，希望能夠使異步的Web服務(wù)可以像同步的Web服務(wù)一樣被容易編程使用的原因。

適配器

適配器解決了集成最后階段的難題：它們提供了Web技術(shù)到非Web技術(shù)或者“遺留技術(shù)”（比如COBOL/CICS）的連接方式。（注意：使用“遺留技術(shù)”這個詞我沒有任何不敬的意思：成為一種長久被人們使用的遺留技術(shù)是軟件的最高目標[當(dāng)然，很多軟件沒有達到這個目標]，而且，從真正意義上說，所有的生產(chǎn)應(yīng)用都是遺留的。）即使在XML和Web服務(wù)出現(xiàn)之后，適配器仍保持著重要的地位，因為目前只有十分少的遺留系統(tǒng)直接擴展了對Web服務(wù)的支持。（相反，遺留系統(tǒng)將會被Web服務(wù)和新的業(yè)務(wù)邏輯 “包裝”起來，然后部署到WebLogic, WebSphere, 和.NET這樣的容器中去）。

如果沒有一個標準的適配器模型，集成平臺幾乎不可能到達臨界狀態(tài)。這一點可以參照通用的數(shù)據(jù)庫適配器，即Java數(shù)據(jù)庫連接 (JDBC)，對Java的成功所產(chǎn)生的巨大影響。

J2EE連接器架構(gòu)（Connector Architecture，CA）對JDBC進行了泛化處理，從而為Java適配器定義了一個通用的模型。J2EE連接器架構(gòu)（或者.NET）消除了m x n 式的費用支出方式，m x n是指每一個集成供應(yīng)商（m）都必須為每一個遺留系統(tǒng)（n）提供一個不同的專有的適配器。除此之外，J2EE連接器架構(gòu)還保護了您在集成方案中的程序設(shè)計投資，就好比JDBC保護了數(shù)據(jù)庫應(yīng)用系統(tǒng)的投資一樣。

轉(zhuǎn)換、整合以及映射層

一個期望深深根植于我們關(guān)于Web2.0的觀念中，那就是使XML成為跨越不同系統(tǒng)的數(shù)據(jù)表示方式。不管市場營銷如何地夸大了XML的這一功能，XML自身并不能避免不同數(shù)據(jù)表示之間的不匹配，而且我們也正在目睹多的數(shù)不清的XML Schemas在企業(yè)之間泛濫。（在一些大型公司中，僅僅是用來表示“客戶”這一結(jié)構(gòu)的模式的數(shù)量可能就已經(jīng)超過了100個。）XML只是定義了一種通用的構(gòu)造文件的字母元素（就好比是“結(jié)構(gòu)化的ASCII”）；仍然需要各個公司和行業(yè)去定義詞匯表（從XML到業(yè)務(wù)對象的語義映射），從而使快捷的轉(zhuǎn)換成為可能。一些這樣的詞匯表將會采取“從上至下”的方式定義，它們由行業(yè)標準制定機構(gòu)或是行業(yè)工會來定義。另外一些則采取“從下至上”（就像自然語言的產(chǎn)生）的方式逐漸成型，個別的公司或是一小群公司制定了與其進行交易的Web服務(wù)的必要組成部分，然后逐漸形成了詞匯表。

盡管基于XML的EAI總是在一個單獨的公司之內(nèi)實施，但是也面臨著同樣的問題。能夠把一個詞匯表映射為另一個詞匯表的工具能夠在很大程度上減輕這種負擔(dān)——這個工具就是XML Query，它正在成為XML處理領(lǐng)域的“SQL”。盡管XML轉(zhuǎn)換正在變得容易和快速，你還是應(yīng)該通過在企業(yè)應(yīng)用架構(gòu)中引入審查/批準的流程，從而盡量限制XML Schema數(shù)量的過分膨脹。

程序開發(fā)層

開發(fā)連接集成業(yè)務(wù)流程（業(yè)務(wù)流和web流）和底層的商業(yè)應(yīng)用的粘合程序的花銷仍然主宰著集成解決方案的開支。不幸的是，目前的處理技巧與理想的境界仍然相差很遠——如果達到理想境界，業(yè)務(wù)分析員只需要定義高層的業(yè)務(wù)流程，基礎(chǔ)結(jié)構(gòu)就能夠“神奇地”自動生成必要的粘合程序。歷史上，集成項目最大的一個風(fēng)險在于：粘合程序的編寫過分地依賴于專有應(yīng)用的編程接口（API）。在沒有標準API的情況下，根本無法保護在集成代碼以及程序員身上所作出的投入。而且，根本就沒有足夠豐富的符合API標準的工具（如同為了開發(fā)SQL和J2EE而產(chǎn)生的開發(fā)工具）。獨立軟件供應(yīng)商們（Independent software vendors ，ISVs）竭盡全力地構(gòu)建能夠部署于多個容器中的集成解決方案。（比如，可以移植到WebLogic 和WebSphere上的方案）。

當(dāng)然，Java和XML組織已經(jīng)在擴展Web應(yīng)用平臺標準方面做出了巨大的努力，以便保護集成工作中所作出的投資。

·

一下是一些值得密切關(guān)注的熱點：

XML Query (W3C)

·  Java Web 服務(wù) (JWS) (JSR-181)

·  Process Definition for Java (JSR-208)

·  BPEL4WS (由BEA, IBM, 和Microsoft發(fā)布)

·  Java Meta Data (JSR-175)

·  XML Beans (來自BEA的開放源碼)

·  Portlets (JSR-168)

·  Content Management Interface (JSR-170) （JSR-170)

·  Apache Struts and Java Server Faces (JSR-127)

·  Web Services for Remote Portlets (WSRP; OASIS)

業(yè)務(wù)流程編制層/ Orchestration層

在業(yè)務(wù)流程控制級，我們向集成項目加入了必需的說明性粘合指令：包括工作流，“Web流”，“工作列表”（貫穿整個組織的一系列相互協(xié)作的文檔），以及流程的編排——抽象的消息序列，它定義了工作流如何在企業(yè)內(nèi)部以及企業(yè)之間組合。

在業(yè)務(wù)流程控制級最容易理解的技術(shù)就是業(yè)務(wù)流程管理（Business Process Management ，BPM），BPM利用圖形語言和工具來定義工作流——即一個由各種任務(wù)和異常處理構(gòu)成的計算序列。可以肯定企業(yè)將會需要各種各樣的工作流表示語言：

       關(guān)注業(yè)務(wù)分析的工作流表示語言語言（例如Aris）

       與Java無縫集成的工作流表示語言（Process Definition for Java/JPD）

       與編程語言無關(guān)的工作流表示語言（BPEL4WS）

BPEL4WS在Java和.NET之間提供了一定的獨立性，不過需要付出的代價是必須引入一種新的XML編程語言。可以預(yù)見PDJ 和 BPEL將會合并——PDJ將會變成BPEL工作流的Java實現(xiàn)。

集成代理及管理層

盡管集成方案仍然需要編碼，但是它的目標仍是使編碼量達到最少。在這點上安全性也具有相似特征：過去，授權(quán)過程完全是在應(yīng)用中通過手工編寫代碼實現(xiàn)的?，F(xiàn)在，處于領(lǐng)先地位的Web平臺通過面向業(yè)務(wù)的規(guī)則，從管理的角度定義了安全策略。（這種策略可應(yīng)用于特定的端點或是整個應(yīng)用）。

指令和控制方面也出現(xiàn)了相同的變化——如何路由一個特定的請求（比如一個交易）可能取決于用戶（服務(wù)的質(zhì)量），內(nèi)容（錢數(shù)），接收方（轉(zhuǎn)換和適配器應(yīng)用于其上），或者基礎(chǔ)結(jié)構(gòu)的狀態(tài)（可用性，負載）。如果這樣的邏輯處理用程序編制于應(yīng)用之中，那么不改變業(yè)務(wù)邏輯并且重新部署它就很難對應(yīng)用做出改變。通過采用管理的方式獲取這樣的元數(shù)據(jù)，就能夠非常容易和經(jīng)濟地適應(yīng)這些變化。

集成平臺的管理環(huán)境必須為集成代理之間的互通和平臺與其他應(yīng)用的連接提供一個功能廣泛的操作視圖。

可以預(yù)見，集成應(yīng)用的配置環(huán)境將會越來越支持自我優(yōu)化特性，以及自愈特性——只有在可用系統(tǒng)資源不足，以至于難以達到服務(wù)質(zhì)量要求的時候才會對系統(tǒng)管理員作出提醒。

結(jié)論

解決集成的花銷和復(fù)雜度可能是人們對IT業(yè)提出的最大的要求。不幸的是，世上沒有萬能藥：集成現(xiàn)在是，并且將來還會是一個固有的難題。盡管這樣，有了Web2.0，這個行業(yè)仍然可以得到巨大的改進——方式就是通過提高投資保護的程度和降低非內(nèi)在的復(fù)雜度。利用標準的集成平臺和相關(guān)工具，該行業(yè)應(yīng)該能夠使非內(nèi)在的復(fù)雜度減少10倍——使集成項目更加容易預(yù)測，更加容易成功，而且還可能更加充滿樂趣。

當(dāng)然，Web 2.0仍然需要時間去完善。Web 服務(wù)標準仍然在不斷發(fā)展：可互操作的端到端的安全性，以及可靠的傳遞機制將會在今年的年底出現(xiàn)。

如果說Web2.0標準仍然沒有到位，這是否意味著各個企業(yè)和單位需要等待它的正式出臺呢？我看很難這么做。代表Web以及Java標準集成中最前沿技術(shù)的產(chǎn)品可以為保護長期投資爭取到一個非常有利的位置。這些集成方案——比如WebLogic集成、門戶、Liquid Data、以及它們的直接競爭對手——在功能和特性上具有排它的相互競爭性。

那么，各個企業(yè)和單位如何為基于Web2.0的集成做好準備呢？答案是可以同時從戰(zhàn)術(shù)和戰(zhàn)略兩方面對待集成的挑戰(zhàn)：戰(zhàn)術(shù)上，利用最合適的標準和專有技術(shù)的混合來完成工作；戰(zhàn)略上，把注壓在新興的Web 2.0集成平臺之上。

對于那些仍然對融合了這些標準的集成方案持懷疑態(tài)度的人，我有一個故事要送給他們：在1997年，我曾做了一個不太被人們注意的預(yù)言：服務(wù)器端Java標準的融合趨勢（后來發(fā)展成為J2EE）將會對Web應(yīng)用的開發(fā)產(chǎn)生巨大的影響。

那時候，大約存在著30個獨立的Web應(yīng)用服務(wù)器供應(yīng)商，每個都在發(fā)展它們自己的專有編程模型和開發(fā)工具?？墒乾F(xiàn)在，由BEA的WebLogic和IBM的WebSphere領(lǐng)導(dǎo)的基于J2EE標準的Web應(yīng)用服務(wù)器市場擁有數(shù)十億美元的潛力。而且，至少是因為J2EE的流行，Microsoft發(fā)布了它的.NET系列。

歷史將會再次證明，花在基于We的集成項目中的錢是很值得的。對可擴展的集成方法的迫切需求、希望通過標準來保護投資的渴望、以及對符合標準的容易使用的開發(fā)工具的需求都將會促進這個大融合。就像所有的技術(shù)轉(zhuǎn)型期一樣，目前存在著獲得競爭優(yōu)勢的巨大機會，尤其是對于那些獨立軟件供應(yīng)商和專注于集成的系統(tǒng)集成商。當(dāng)然，同時也存在風(fēng)險。是的，在向一個還沒成熟的技術(shù)下注的時候風(fēng)險就會存在，但是，如果沒能把握這個即將來臨的浪潮，而錯失了賺錢良機，不同樣也是一種風(fēng)險嗎？