?
復(fù)雜性的簡單管理
由于其業(yè)務(wù)可見性、靈活性及知識管理方面帶來的高額利潤，門戶技術(shù)成為了用于對整個企業(yè)的商業(yè)活動進(jìn)行監(jiān)控、查找和管理的流行選擇。對于構(gòu)建高度動態(tài)的能夠聚集、組織和表示來自多個后端系統(tǒng)的信息的企業(yè)門戶來說，BEA WebLogic Platform具有很大的吸引力。不論門戶是用功能豐富的WebLogic Portal Server環(huán)境實(shí)現(xiàn)，還是通過像Jakarta Struts這樣的MVC框架實(shí)現(xiàn)，最新版的BEA WebLogic Platform 8.1提供了大量新特性用于創(chuàng)建功能強(qiáng)大的門戶環(huán)境。
但是由于企業(yè)門戶開始聚合數(shù)量不斷增長的跨越不同技術(shù)領(lǐng)域、地理界限，甚至是組織界限的服務(wù)，所以門戶架構(gòu)師將需要找到管理環(huán)境復(fù)雜性的方法。無疑，在門戶與每一個服務(wù)之間構(gòu)建一次性、可靠、點(diǎn)到點(diǎn)的集成不能從開發(fā)、部署或運(yùn)行時方面進(jìn)行伸縮。所以需要一種“服務(wù)網(wǎng)絡(luò)”的概念，它提供可靠傳輸、智能路由、高級服務(wù)管理特性，以及提供在高度分布式的聯(lián)合環(huán)境下運(yùn)作的能力。
幸運(yùn)的是，一種稱為企業(yè)服務(wù)總線（ESB；參見側(cè)欄“ESB：您的Web 服務(wù)網(wǎng)絡(luò)”）的新型基礎(chǔ)結(jié)構(gòu)提供了甚至最苛求的門戶環(huán)境所要求的復(fù)雜級別。ESB是一種基于標(biāo)準(zhǔn)的面向服務(wù)的骨干，它能夠進(jìn)行可靠連接和協(xié)調(diào)數(shù)百個應(yīng)用程序端點(diǎn)。
ESB為需要連接跨越不同數(shù)據(jù)中心分布的各種異構(gòu)系統(tǒng)的企業(yè)提供了一種理想的體系結(jié)構(gòu)，同時還保持了絕對的事務(wù)完整性。此外，它還提供幾個通過部署時構(gòu)造進(jìn)行最初配置的高級服務(wù)，從而保護(hù)了門戶應(yīng)用程序，即不必經(jīng)常對它進(jìn)行修訂和重新部署來管理后端上的更改。
即使是計(jì)劃部署一個門戶以將同構(gòu)環(huán)境中的系統(tǒng)與許多后端服務(wù)集成，將ESB合并為集成網(wǎng)絡(luò)也有明顯的好處。綜合性的ESB供應(yīng)商將會提供out-of-the-box管理、安全性、可靠性、高性能的服務(wù)請求、本機(jī)XML處理、復(fù)雜路由和轉(zhuǎn)換，以作為總線中的增殖特性。另外，作為面向服務(wù)體系結(jié)構(gòu)（SOA）的一種基于標(biāo)準(zhǔn)的實(shí)現(xiàn)，ESB提供必要的抽象層來履行SOA的全部承諾。在不犧牲同構(gòu)環(huán)境的傳統(tǒng)價值（即管理、安全性、可靠性、伸縮性和性能）的情況下，ESB提供了將底層服務(wù)實(shí)現(xiàn)無縫地重新部署到其他技術(shù)、地理或組織領(lǐng)域的能力。
本文中，我們將通過兩個關(guān)鍵用例來演示，使用BEA WebLogic Platform 8.1，將高度分布式的服務(wù)與門戶及Web應(yīng)用程序相集成時ESB的威力和靈活性。在兩部分系列的下一部分中，將展示ESB如何通過操作感知、業(yè)務(wù)活動監(jiān)控（BAM）和面向服務(wù)的業(yè)務(wù)過程管理來向組織提供附加值，從而讓門戶可以充分利用擴(kuò)展企業(yè)中的服務(wù)的全部價值。
Avitek Medical Records：擴(kuò)充其業(yè)務(wù)模型
WebLogic Platform 8.1配帶一個綜合的J2EE指南，稱作“Avitek Medical Records（Avitek醫(yī)療記錄）”，用來說明J2EE平臺的所有核心特性。該指南建模的基本思想圍繞這樣一種門戶(一種J2EE Struts應(yīng)用程序)，它為病人、醫(yī)生和管理者提供查看整個醫(yī)療記錄集合的能力。另外，該應(yīng)用程序展示了通過Web Services接口連接外部客戶機(jī)的能力，它提供了不通過表示層直接與Avitek服務(wù)交互的能力。
作為本文的前提，我們假設(shè)Avitek上的“業(yè)務(wù)量在急劇增長”并且已經(jīng)獲得醫(yī)療記錄的三個新的來源以集成到門戶中。為了使情況復(fù)雜一點(diǎn)，新的來源在地理上跨越不可靠的網(wǎng)絡(luò)分布，并且包含混合的技術(shù)環(huán)境（多種J2EE應(yīng)用程序服務(wù)器供應(yīng)商、Microsoft .NET和定制的解決方案）。實(shí)際上，Avitek類似一種能適應(yīng)變化的體系結(jié)構(gòu)，因?yàn)樗鼈兒芸赡軙隽康孬@得信息的新來源，并會隨著時間慢慢地將這些來源遷移到最新最好的技術(shù)上。
盡管Avitek Medical Records的體系結(jié)構(gòu)宣稱能夠使用HTTP/Web服務(wù)來集成新的醫(yī)療記錄來源，但是本文將通過一些關(guān)鍵用例來解釋僅僅使用Web Services環(huán)境是不夠的。
圖1
在談到純HTTP/Web服務(wù)方法的生存能力時，還存在一些與通信模型（請求/響應(yīng)模型、單向通信模型和異步服務(wù)模型等）的可靠性、性能、豐富性以及服務(wù)質(zhì)量、性能、管理和安全性相關(guān)的問題。為此，我們建議修改Avitek的體系結(jié)構(gòu)以與ESB的概念相結(jié)合（見圖1）。
ESB是基于工業(yè)標(biāo)準(zhǔn)的JMS，將會提供一種企業(yè)級的骨干，以便可靠地將服務(wù)一起鏈接到內(nèi)聚性操作單元中，它能夠服務(wù)于大多數(shù)門戶所需的全范圍的集成場景。本文將會介紹ESB就位后可用的許多場景中的幾個場景：
1.??? 前向緩存（Forward Cache）：為了低延遲、只讀訪問數(shù)據(jù)而將數(shù)據(jù)從分布式系統(tǒng)移動到靠近表示層的能力。
2.??? 聯(lián)合查詢（Federated Query）：在表示層有效地查詢多系統(tǒng)并異步地聚集響應(yīng)的能力。
前向緩存服務(wù)
“前向緩存服務(wù)”用例解決需要把數(shù)據(jù)從back-office系統(tǒng)暴露到表示層這樣的問題。盡管表示層可以容易地通過請求/響應(yīng)模型與back-office系統(tǒng)交互，但仍有一些原因使得這樣做行不通：
1.? back-office系統(tǒng)不能維持支持前端表示層所需要的負(fù)載。
2.? 請求/響應(yīng)模型的延遲超出了表示層容許的范圍。
3.? 將back-office系統(tǒng)直接暴露給表示層會有風(fēng)險——穩(wěn)定性或是對現(xiàn)有服務(wù)級別的沖擊。
4.? back-office系統(tǒng)可能與表示層處于不同的地域；在兩個數(shù)據(jù)中心之間連接斷了的情況下，數(shù)據(jù)對于終端用戶來說應(yīng)該仍然可用。
ESB可用于可靠地將變化轉(zhuǎn)發(fā)到表示層中的緩存中。這里的關(guān)鍵單詞是“可靠地”。在分布式基于SOA的環(huán)境中，需要將注意力集中到系統(tǒng)之間如何互操作以及在發(fā)生故障和停機(jī)時會發(fā)生什么事情上。很多時候，系統(tǒng)不能為這種類型的可靠性提供必要的消息重發(fā)和“未確定解決方案”。ESB可以消除系統(tǒng)中的這種復(fù)雜性（見圖2）。
圖2
從定義來看，ESB是一種可以在任意兩個實(shí)體間可靠通信的分布式服務(wù)網(wǎng)絡(luò)。ESB實(shí)現(xiàn)模塊提供的部署選項(xiàng)允許將服務(wù)質(zhì)量調(diào)整成剛好滿足應(yīng)用程序的需求?；诠I(yè)標(biāo)準(zhǔn)的JMS，兩個實(shí)體使用標(biāo)準(zhǔn)接口可靠地進(jìn)行通信；ESB處理路由的復(fù)雜性并保證更改通知的傳遞。
幸運(yùn)的是，Avitek演示不需要徹底地改變以利用ESB。給定ESB的基于標(biāo)準(zhǔn)的方法，ESB實(shí)現(xiàn)模塊通過JMS接口連接進(jìn)來。Avitek演示中包含了一個MDB，該MDB對JMS連接進(jìn)行偵聽，以將XML記錄“上載”到MedRec數(shù)據(jù)庫。一旦記錄被加載到數(shù)據(jù)庫中，這些數(shù)據(jù)就對使用標(biāo)準(zhǔn)技術(shù)對數(shù)據(jù)庫進(jìn)行查詢的前端門戶可用。當(dāng)然，這種模式還有待加強(qiáng)，以適應(yīng)記錄刪除請求，或者甚至適應(yīng)部分記錄更新（參見圖3）。
圖3
但這與標(biāo)準(zhǔn)的JMS實(shí)現(xiàn)程序的區(qū)別何在呢？JMS實(shí)現(xiàn)程序能在單一域中確保信息異步的傳遞。試圖連接多個JMS消息傳遞域通常需要某種定制的橋接，使得消息可以在多個域之間進(jìn)行可靠的轉(zhuǎn)發(fā)。然而ESB實(shí)現(xiàn)模塊在分布式聯(lián)合環(huán)境中提供本地的端到端JMS通信，這消除了對定制橋接的依賴。另外，ESB還提供附加的基于標(biāo)準(zhǔn)的連接，例如Web services和JCA適配器（參考側(cè)欄“ESB提供商：附加值服務(wù)”），這允許在ESB上的任何地方靈活地部署服務(wù)。
另外需要考慮的是在表示層中數(shù)據(jù)如何進(jìn)行緩存。Avitek演示依賴于將標(biāo)準(zhǔn)XML Schema存放在關(guān)系數(shù)據(jù)庫中。可是在有各種各樣信息單元的不同服務(wù)環(huán)境中，則更傾向于在不必定義關(guān)系結(jié)構(gòu)的情況下存儲和處理不同格式的XML。
ESB實(shí)現(xiàn)模塊也許會提供嵌入式XML數(shù)據(jù)庫，采用一種“無schema”的方法來存儲、恢復(fù)以及查詢XML文檔，徹底的減少了為適應(yīng)后端服務(wù)數(shù)據(jù)中的變化所需的數(shù)據(jù)庫管理時間。
也應(yīng)該討論一些替代方法來與ESB進(jìn)行比較和對比。BEA WebLogic 8.1也提供一些不同的方法，來滿足在不同域之間的這種松耦合和可靠的消息傳遞。
可靠的Web服務(wù)
?BEA WebLogic 8.1提供一種稱為“可靠SOAP消息傳遞”的新特性。該特性允許兩個不同的WebLogic服務(wù)器之間進(jìn)行異步可靠的消息傳遞。雖然SOAP/Web服務(wù)是一種基于標(biāo)準(zhǔn)的方法，目前WebLogic 8.1通過專有的SOAP報頭和交互協(xié)議來實(shí)現(xiàn)可靠性。也許將來的能夠用像“WS—Reliability”這樣的基于標(biāo)準(zhǔn)的方法來實(shí)現(xiàn)。即使是使用象“WS—Reliability”這樣的基于HTTP的標(biāo)準(zhǔn)方法，需要高吞吐量和低延遲的特定用例將通過真正的“端到端”JMS解決方案來獲得更好的服務(wù)。
為了可靠的連接兩個跨越不同網(wǎng)絡(luò)和地理界限的系統(tǒng)，必須在每一個域中都駐留某種基礎(chǔ)結(jié)構(gòu)，用以在發(fā)生故障時提供必要的“存儲和轉(zhuǎn)發(fā)”功能。ESB基礎(chǔ)結(jié)構(gòu)通常是“輕量級”、易管理并且重點(diǎn)只放在集成服務(wù)上。此外，將ESB基礎(chǔ)結(jié)構(gòu)部署到.NET 環(huán)境或甚至是另外的J2EE基礎(chǔ)結(jié)構(gòu)，可能會得到更好的組織結(jié)構(gòu)。預(yù)先計(jì)劃ESB當(dāng)然可以避免以后可能出現(xiàn)的很多問題。
JMS消息橋
BEA WebLogic 8.1提供能夠在兩個不同的JMS實(shí)現(xiàn)之間轉(zhuǎn)發(fā)消息的JMS消息橋。這種方法當(dāng)然提供了相對HTTP/Web服務(wù)方法的優(yōu)勢，但ESB的基礎(chǔ)結(jié)構(gòu)能在本地總線上提供必要的轉(zhuǎn)發(fā)、路由和消息優(yōu)化功能。ESB也提供內(nèi)聚管理和安全環(huán)境，簡化了部署。
聯(lián)合查詢
這種“聯(lián)合查詢”用例解決了在表示層中需要對多種后端系統(tǒng)進(jìn)行查詢的問題。與“轉(zhuǎn)發(fā)服務(wù)緩存”用例不同的是，后端系統(tǒng)中的數(shù)據(jù)不能合理地得到緩存。這是因?yàn)椋?/span>
1.?后端系統(tǒng)中數(shù)據(jù)的變化速率使得數(shù)據(jù)無法合理地得到緩存：查詢緩存的數(shù)據(jù)可能會造成數(shù)據(jù)不一致和結(jié)果錯誤。
2.?數(shù)據(jù)量太大：緩存轉(zhuǎn)發(fā)的數(shù)據(jù)在技術(shù)上和經(jīng)濟(jì)上都不可行。
聯(lián)合服務(wù)查詢模式的另一方面是：請求花費(fèi)的時間太長以至于無法完成（某些情況下，需要幾天）。例如，一個獨(dú)立系統(tǒng)可能會包含某種人工干預(yù)（例如確認(rèn)）來完成工作流。因?yàn)槠涔逃械漠惒教匦裕?/span>ESB能夠?yàn)檫@種模式提供強(qiáng)大的基礎(chǔ)。
聯(lián)合查詢模式至少有兩種變體。這里討論的變體根據(jù)查詢的持續(xù)時間進(jìn)行變化。
對于表1中討論的兩種聯(lián)合查詢模式，ESB使用JMS的基本“發(fā)布—訂閱”消息傳遞模式來將請求有效地散播到多個后端系統(tǒng)（在本例中是訂閱者）。這些模式說明了實(shí)現(xiàn)功能的非常簡單的方法，ESB提供了實(shí)現(xiàn)大量技術(shù)所需的核心工具。ESB提供了一組豐富的通信模型，它們可以采用最有效的方式來適應(yīng)門戶與后端系統(tǒng)之間的各種交互。
表1
為了闡明這個觀點(diǎn)，讓我們考慮對三個后端服務(wù)上的查詢。如果每個服務(wù)需要三秒鐘進(jìn)行處理，連續(xù)地調(diào)用這些服務(wù)將至少耗費(fèi)九秒鐘。ESB允許以并行的方式執(zhí)行服務(wù)，使得全部的服務(wù)執(zhí)行時間等于最長的服務(wù)的運(yùn)行時間（在本例中是三秒鐘）。雖然這可以使用集中式多線程技術(shù)來實(shí)現(xiàn)，但ESB允許并發(fā)處理跨總線進(jìn)行分布，這樣就消除了集中式的瓶頸，并提供了更大的可伸縮性潛力。
聯(lián)合查詢：實(shí)時請求
針對本例，我們增強(qiáng)Avitek，為醫(yī)生提供在多后端系統(tǒng)中查詢的能力，以便確定在某個時間段內(nèi)得到輸血的患者的名單。
為了實(shí)現(xiàn)這種新特性，必須使用WebLogic Server 8.1中新的“JMS包裝”支持。這種特性能直接從EJB或者servlet中有效地發(fā)送或接收JMS消息。WebLogic Server 8.1能夠有效的管理JMS連接池，以確保消息能夠在門戶應(yīng)用程序和JMS實(shí)現(xiàn)程序（或在我們例子中是ESB）之間進(jìn)行快速路由。下面給出它的工作原理：
無狀態(tài)的會話bean包含了一個方法，它實(shí)現(xiàn)了已被廣泛接受的“JMSReplyTo”模式。當(dāng)客戶端（servlet和JSP等）調(diào)用無狀態(tài)會話bean上的方法時，該方法將請求發(fā)布給ESB，ESB再將請求分發(fā)到在配置主題上偵聽的服務(wù)。這類服務(wù)的例子是JMS客戶端、Web服務(wù)或甚至是與應(yīng)用程序交互的JCA適配器。
無狀態(tài)會話bean定義了一種方法，使得客戶端可以發(fā)送任意字符串請求。在XML中可以對它進(jìn)行格式化。
public boolean sendRequest(String requestData, ArrayList a) {
JMS對象一旦建立，標(biāo)準(zhǔn)的“JMSReplyTo”模型就用于將請求與“返回地址”一起發(fā)布。所有響應(yīng)都會返回到這個無狀態(tài)會話bean的實(shí)例上（參見清單1）。
最后，這個例子將等待來自ESB上的服務(wù)的特定數(shù)量的響應(yīng)，或者直到超時發(fā)生為止（參見清單2）。
聯(lián)合查詢：長持續(xù)時間請求
對于本例，我們建立在前一個例子的基礎(chǔ)上，只是假定來自總線上的服務(wù)的響應(yīng)將以更加不可預(yù)知的方式返回。這種模式使門戶用戶可以瀏覽到Web 站點(diǎn)的其它區(qū)域，同時響應(yīng)也以異步方式聚合在用戶的會話中。用戶甚至可以注銷，然后重新登錄以檢查請求的狀態(tài)（參見圖4）。
圖4
對于本例，消息驅(qū)動bean用于異步收集響應(yīng)，并將其保存在數(shù)據(jù)庫中。另一種情況是本地XML數(shù)據(jù)庫可以派上用場。如果系統(tǒng)用變化中的XML響應(yīng)信息響應(yīng)，也許將整個XML響應(yīng)簡單地存儲到“無schema”數(shù)據(jù)庫中是最好不過的了。
ESB的一個主要特征是：所有的服務(wù)都通過一個“松耦合”的通信接口聯(lián)系在一起。與本例有關(guān)的好處是：新系統(tǒng)可以聯(lián)機(jī)進(jìn)來，并立即被包括到聯(lián)合查詢中。由于基礎(chǔ)機(jī)制是“發(fā)布—訂閱”模式，所以新服務(wù)可以簡單地訂閱相關(guān)的主題并從門戶接收查詢請求。由于ESB允許在部署時動態(tài)發(fā)現(xiàn)和智能配置驅(qū)動的路由（基于內(nèi)容和基于上下文等），所以可以保證門戶不受ESB上的服務(wù)變化的影響。
聯(lián)合查詢：實(shí)時請求與長持續(xù)時間請求的組合。有時候，可能值得在某個時間幀內(nèi)收集來自總線上不同系統(tǒng)的結(jié)果（實(shí)時請求），但在初始時間幀過期后以異步方式收集響應(yīng)（長持續(xù)時間請求）。為此，我們引入單獨(dú)的“通知主題”概念，以便當(dāng)MDB成功地將響應(yīng)保存到緩存時，允許無狀態(tài)會話bean（SSB）接收通知。SSB可以使用任意的業(yè)務(wù)邏輯來決定何時停止等待，允許門戶應(yīng)用程序從緩存中讀取數(shù)據(jù)并將結(jié)果顯示給用戶（參見圖5）。
圖5
小結(jié)
雖然BEA WebLogic Platform 8.1是一種能處理多種應(yīng)用程序方案（包括門戶）的強(qiáng)大平臺，但也有某些類型的門戶集成方案，它們是作為企業(yè)服務(wù)總線需要的。完全基于標(biāo)準(zhǔn)的基礎(chǔ)分布式網(wǎng)絡(luò)——ESB能夠創(chuàng)建敏捷、可互操作及可靠的面向服務(wù)網(wǎng)絡(luò)，以便把企業(yè)內(nèi)外的服務(wù)鏈接在一起。由于今天Web服務(wù)標(biāo)準(zhǔn)發(fā)展到合并JMS提供程序的許多可用語義，所以ESB實(shí)現(xiàn)模塊將繼續(xù)實(shí)現(xiàn)標(biāo)準(zhǔn)并創(chuàng)建可互操作的網(wǎng)絡(luò)，使JMS應(yīng)用程序能夠和Web 服務(wù)應(yīng)用程序?qū)υ?，反之亦然。同時，ESB將給某些門戶和Web應(yīng)用程序開發(fā)者添加重大的價值，他們嘗試解決涉及異構(gòu)系統(tǒng)、地理位置和組織的復(fù)雜集成方案。
下一部分中，我們將討論操作感知、業(yè)務(wù)活動監(jiān)控以及集成工作流如何可以給這些應(yīng)用程序增加附加值。
ESB：你的Web服務(wù)網(wǎng)絡(luò)
到現(xiàn)在，你可能會問，“Web服務(wù)怎樣？”。Web服務(wù)的承諾當(dāng)然是跨完全不同技術(shù)、地域以及組織界限的集成能力。把ESB看作是Web Services的健壯網(wǎng)絡(luò)。ESB建立在Java Message Service（JMS）基礎(chǔ)上，它提供所需的關(guān)鍵特性，以便為相互連接的服務(wù)建立可靠、安全、可管理及高度執(zhí)行的骨干。實(shí)際上，在許多可用的Web服務(wù)工具包中，ESB的基礎(chǔ)骨干已經(jīng)變成可以識別的SOAP傳輸。針對新出現(xiàn)的許多Web Services標(biāo)準(zhǔn)，ESB提供了自己的解釋與實(shí)現(xiàn)，使門戶開發(fā)人員看不到不同服務(wù)間的網(wǎng)絡(luò)級互操作細(xì)節(jié)。許多復(fù)雜的Web服務(wù)主題，比如路由、工作流、事務(wù)、單用戶注冊安全、審計(jì)、高級監(jiān)控和管理，都可以通過ESB基礎(chǔ)結(jié)構(gòu)處理。
ESB實(shí)現(xiàn)模塊:增值服務(wù)
如前所述，許多ESB 廠商提供增值服務(wù)以幫助建立健壯的集成環(huán)境。在“前向緩存”用例環(huán)境中，有一些需要考慮的其它問題：
l連通性：JMS中的“J”代表“Java”，這是否意味著所有的系統(tǒng)必須符合Java？當(dāng)然不是！ESB 充當(dāng)SOA 環(huán)境下的“瑞士”，將完全不同技術(shù)集成到普通的可互操作網(wǎng)絡(luò)。尋找支持本地C/C++實(shí)現(xiàn)、MS/.NET、本地HTTP/SOAP支持及更高級別的適配器（JCA或定制）的ESB 實(shí)現(xiàn)模塊，以自動化集成過程。
l轉(zhuǎn)換：Avitek演示合并了在表示層中嵌入的轉(zhuǎn)換，以便將醫(yī)療記錄的不同表示轉(zhuǎn)換成Avitek形式。然而，在聯(lián)合開發(fā)環(huán)境中，系統(tǒng)某各部分的開發(fā)者可以建立到這種XML規(guī)范形式的轉(zhuǎn)換。在本例中，將轉(zhuǎn)換重新部署在接近初始點(diǎn)（和開發(fā)人員）不是更好嗎？尋找在ESB中任何位置都可以配置轉(zhuǎn)換的ESB實(shí)現(xiàn)模塊。
關(guān)于作者：Hub Vandervoort是 Sonic Software專業(yè)服務(wù)部門的副總裁。他具有20多年的顧問和高級技術(shù)主管的經(jīng)驗(yàn)，其中涉及網(wǎng)絡(luò)、通信軟件和Internet產(chǎn)業(yè)。在以前，Hub與人共同創(chuàng)建了三個創(chuàng)業(yè)風(fēng)險投資公司，其中包括早期的面向消息中間件（MOM）領(lǐng)先廠商Horizon Strategies, Inc.。
Matt Rothera是Sonic Software（www.sonicsoftware.com）的見習(xí)經(jīng)理，同客戶一起工作，幫助規(guī)劃、設(shè)計(jì)和部署實(shí)時、面向服務(wù)的體系結(jié)構(gòu)。在超過15年的技術(shù)工作中，Matt已經(jīng)同100個客戶一起工作，把它們的服務(wù)與內(nèi)部應(yīng)用程序、商業(yè)合作伙伴和企業(yè)門戶集成。