協(xié)作，“讓我們暢談”

申請免費試用、咨詢電話：400-8352-114

協(xié)作，“讓我們暢談”

協(xié)作應用使得下一代企業(yè)應用將利用Web服務相互“交談”，實現(xiàn)比點到點互動更多的功能。

協(xié)作，“讓我們暢談”

下一代企業(yè)應用

由于協(xié)作應用使多種應用和數(shù)據(jù)源可以“交談”，因此協(xié)作應用具有很多優(yōu)勢。

靈活性：應用是透明的，因此企業(yè)可以先定義業(yè)務目標，然后再開發(fā)容易改變并隨意處理的組合應用來支持它們的目標。

優(yōu)化：消除了對點到點集成的需要，應用開發(fā)人員可以更迅速地對企業(yè)用戶需求做出應答。

部件可重用：企業(yè)無需重新編寫代碼就可使用已有的業(yè)務邏輯。

擇優(yōu)性：可以部署不同的企業(yè)應用程序，不必保持完整的套件。

無附加條件限制：應用是獨立于傳輸、獨立于平臺的。

下一代企業(yè)應用可以消除傳統(tǒng)的限制，打破功能分割條塊，將客戶、供應商、財務應用以及公司防火墻內(nèi)外的其他應用無縫地連接在一起。在越來越多的數(shù)據(jù)以XML形式發(fā)布并通過Web服務連接在一起的情況下，企業(yè)正尋求將條塊分割的業(yè)務過程捆綁起來，利用已有應用的最佳部分解決業(yè)務問題。協(xié)作應用就是這樣一種“下一代企業(yè)應用”，這類新興的協(xié)作應用將來自多種應用系統(tǒng)的功能組合起來，執(zhí)行一個可作為Web服務發(fā)布的規(guī)模更大的近實時過程。

企業(yè)將不再需要定制業(yè)務過程和工作流來適應自己的erp系統(tǒng)參數(shù)。相反，它們將首先定義業(yè)務目標，然后再開發(fā)容易改變、可隨意處理的復合應用來支持隨企業(yè)發(fā)展而變化的目標。

關注應用

隨著這種新興模型的演進，廠商紛紛設法通過不同的方案支持協(xié)作應用的基礎設施搭建，支持這種下一代企業(yè)應用。傳統(tǒng)的EAI(企業(yè)應用集成)廠商正在他們的專有平臺上開發(fā)業(yè)務過程來管理這類增值服務，而應用服務器廠商則迅速通過提供集成服務來支持Web服務。此外，Oracle和SAP這樣的企業(yè)應用級廠商將他們的應用以XML的形式發(fā)布并在產(chǎn)品之間建立更緊密的集成，還有一些另類廠商則將重點放在為Web服務定制應用和為Web服務開發(fā)新應用上。

傳統(tǒng)的EAI廠商，將寶押在了業(yè)務流程管理引擎和各種Web服務上，他們認為Web服務第一次真正有希望提供一種實現(xiàn)協(xié)作應用模型獨立于傳輸、獨立于平臺和獨立于防火墻的途徑，但是將Web服務串在一起不是一個應用所能做到的，Web服務缺少的要素包括事務處理性、安全和管理,這些要素成為在防火墻之外采用協(xié)作應用的障礙。

一些廠商則選擇了利用一種更加分布式的方法實現(xiàn)協(xié)作應用，而沒有選擇集中式代理實現(xiàn)集成。例如，北美Sonic Software公司的Sonic XQ產(chǎn)品是建立在基于Java的消息架構基礎之上的，這種架構將向企業(yè)的特定部分傳送叫作ESB(企業(yè)服務總線)的“輕型”服務容器。

業(yè)界人士分析，與數(shù)據(jù)不同，這類下一代企業(yè)應用將安裝在主要受企業(yè)功能和過程驅動的服務架構中。在一個面向服務的架構中，企業(yè)可以調用服務在網(wǎng)上下訂單和執(zhí)行原始邏輯，而非來回傳送數(shù)據(jù)。

無論采用什么形式，協(xié)作應用都將對SCM(供應鏈管理)和B2B特別有價值，因為SCM和B2B過程依賴于來自多個來源的數(shù)據(jù)的組合和互動。例如，一家擁有多種產(chǎn)品線的跨國公司(每種產(chǎn)品線都有自己的來自不同廠商的銷售系統(tǒng))可以將一個Web服務附加到每個系統(tǒng)上并建設全球銷售立體網(wǎng)絡，從每個系統(tǒng)提取數(shù)據(jù)，以獲得一種銷售信息的復合視圖。

協(xié)作的挑戰(zhàn)

ISV正在破解協(xié)作應用的難題

來自集成和應用開發(fā)領域的廠商正在應對協(xié)作應用的挑戰(zhàn)，開發(fā)他們希望將成為開發(fā)下一代企業(yè)應用平臺的新中間件層。他們的努力最終將使企業(yè)擺脫采用專有API的點到點集成，向一種基于標準的、松散連接的和業(yè)務規(guī)則驅動的軟件層發(fā)展，這種軟件層使企業(yè)能夠將已有系統(tǒng)組件連接在一起構成協(xié)作應用。

但是，若想使協(xié)作應用發(fā)揮作用，就必須解決幾個棘手的問題，這些問題包括數(shù)據(jù)轉換、業(yè)務過程協(xié)調和事務處理性。目前的努力，主要建立在已有開放系統(tǒng)接口(如XML)上，是過渡性的步驟，一旦SOAP(簡單對象訪問協(xié)議)和WSDL (Web服務描述語言)等Web服務接口和協(xié)議得到普及，將出現(xiàn)一種更加面向服務的實現(xiàn)方法。

數(shù)據(jù)轉換與同步

盡管許多遺留系統(tǒng)和套裝應用程序采用XML，但是令人失望的是，它們的數(shù)據(jù)模型和方案是不同的。例如，在SAP系統(tǒng)、自編訂單管理系統(tǒng)和SCM(供應鏈管理)系統(tǒng)中，“訂單”或“客戶”的定義可能會完全不同。此外，許多企業(yè)除了最初編寫系統(tǒng)程序的人員的記憶外，沒有保留全面的數(shù)據(jù)字典。因此，企業(yè)詞匯管理—將來自多種系統(tǒng)的數(shù)據(jù)映射和轉換到單一且一致的方案中是協(xié)作應用平臺開發(fā)商面臨的最困難的問題之一。

管理過程流

阻礙協(xié)作應用開發(fā)的另一個障礙是缺少描述和協(xié)調分布在多種系統(tǒng)上的業(yè)務過程流的標準。人們現(xiàn)在基本上是將各種應用串在一起，而不是以更加單獨的方式編寫它們，因此建模和過程流問題變得更加重要。

解決這個問題的多項標準正在制定中，Microsoft的XLANG、 IBM的WSFL(Web服務流語言)和來自業(yè)務過程管理計劃的BPMI是人們密切關注的三個競爭標準。同樣，ebXML(電子商務XML)具有一個業(yè)務過程部件，但它是基于對象模型的，因此缺少對松散連接的過程的抽象。

事務處理

第三種挑戰(zhàn)將是為跨多種后端系統(tǒng)事務處理提供支持。事務處理定義還必須與過程流定義一致，使事務處理可以退回到過程中的合適的顆粒度水平上，而這種水平必須與安全模型中的顆粒度水平聯(lián)系在一起。一種實現(xiàn)方法是XA。XA是一項建議的W3C標準，它可以在跨多種系統(tǒng)進行事務處理時鎖定系統(tǒng)，以保證交易的完整性。

基于XML的協(xié)作應用的另一個問題來自事務處理的性能。在進行高容量事務處理時，CORBA或Java RMI(遠程方式調用)可能比基于XML的應用效率更高，因為全文本XML文檔占用更多的空間。

現(xiàn)在，所有廠商都認為某些技術組合——面向XML的中間件、傳統(tǒng)的發(fā)布-訂閱消息技術以及面向服務的Web服務架構將是完成工作所必須的。企業(yè)希望利用其已有應用組件，希望業(yè)務邏輯處在中間件中而非端點上，需要獨立于任意廠商控制的中間件并且不愿意為每個新應用程序編寫大量費用昂貴的定制代碼。協(xié)作的實現(xiàn)，能夠解決這一切！

協(xié)作應用

協(xié)作應用，即組合多種已經(jīng)應用的功能或信息，在Web服務的支持下，這類應用將使企業(yè)在需要時，可以迅速地通過將信息組合在一起來創(chuàng)建和改變應用，應用可以受業(yè)務需要驅動，而不僅僅受數(shù)據(jù)驅動。