欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

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

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

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

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

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

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

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

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

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

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

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

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

中間件基礎結構

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

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

應用對外連接層

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

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

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

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

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

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

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

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

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

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

適配器

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

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

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

轉換、整合以及映射層

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

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

程序開(kāi)發(fā)層

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

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

·

一下是一些值得密切關(guān)注的熱點(diǎ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 (來(lái)自BEA的開(kāi)放源碼)

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

在業(yè)務(wù)流程控制級最容易理解的技術(shù)就是業(yè)務(wù)流程管理（Business Process Management ，BPM），BPM利用圖形語(yǔ)言和工具來(lái)定義工作流——即一個(gè)由各種任務(wù)和異常處理構成的計算序列?？梢钥隙ㄆ髽I(yè)將會(huì )需要各種各樣的工作流表示語(yǔ)言：

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

       與Java無(wú)縫集成的工作流表示語(yǔ)言（Process Definition for Java/JPD）

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

BPEL4WS在Java和.NET之間提供了一定的獨立性，不過(guò)需要付出的代價(jià)是必須引入一種新的XML編程語(yǔ)言?？梢灶A見(jiàn)PDJ 和 BPEL將會(huì )合并——PDJ將會(huì )變成BPEL工作流的Java實(shí)現。

集成代理及管理層

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

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

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

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

結論

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

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

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

那么，各個(gè)企業(yè)和單位如何為基于Web2.0的集成做好準備呢？答案是可以同時(shí)從戰術(shù)和戰略?xún)煞矫鎸Υ傻奶魬穑簯鹦g(shù)上，利用最合適的標準和專(zhuān)有技術(shù)的混合來(lái)完成工作；戰略上，把注壓在新興的Web 2.0集成平臺之上。

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

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

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