在實際工作中構建大型的應用很難。通常你會把門戶（portal）和企業(yè)集成（EAI）搞混，這樣你的工作更難完成。你必須做出一系列的困難決定，很多決定也許會對項目的其余部分產(chǎn)生或好或壞的影響。
在你做出架構性的重要選擇之前，都應該深入考慮你構建的應用的每一層（ 從前端的負載平衡系統(tǒng)到后端的企業(yè)級的系統(tǒng)，也許是全球性的）。即使只是處理這些問題的一個子集（也許“只是”代表那些與門戶集成相關的一些問題），你也將面臨很多棘手問題：
為了得到最好的效果，我是不是應該把我的web層和一些流程組件連接起來，讓這些組件充當工作流和應用集成層的業(yè)務代理，讓集成層處理EAI的復雜問題？是不是每次都可以按這樣的套路進行呢？
我的web層和工作流層是不是應該采用松耦合（例如，使用JMS），或者在某種情況下，為了利用BMP（Business Process Management）的API提供的工作列表（worklist）功能的好處，是否可以不用松耦合？
在創(chuàng)建統(tǒng)一用戶資料（Unified User Profile）時，我如何精確的和CRM，ERP和安全系統(tǒng)打交道？
門戶內(nèi)容管理參考實現(xiàn)是否提供了足夠多的功能？我是不是需要評估一下第三方的解決方案？
我們是否應該利用新的證書映射提供者（credential mapping provider）通過J2EE CA Adapters傳遞認證信息？還是用Web services的SAML （Security Assertion Markup Language）？我們的第三方單點登陸（Single Sign-On （SSO））安全系統(tǒng)是否支持這些機制？我有沒有SSO？我是否需要一個呢？
幸運的是，這只是一篇雜志中的文章，所以我們可以先把一些問題放在一邊，以利于我們集中精力，減少篇幅。本文描述了WebLogic 7.0 EntERPrise Platform里可以用來在門戶中用Web services進行集成的一些工具和技術。在一個簡要的原型系統(tǒng)例子中我們對這些技術進行了演示。這里我定義的門戶集成是指：把從不同的資源（通常是外部的）中獲得的信息，通過檢索、轉換、組織、顯示，形成統(tǒng)一的、個性化的整體。本文主要是討論Web service，所以只是簡要介紹這些門戶集成功能中對第三方的內(nèi)容和文檔的管理的功能，該功能在企業(yè)架構中應當被考慮。我將簡要介紹以下內(nèi)容：
J2EE CA 應用視圖（J2EE CA Application Views）
Workshop Application集成控制（Workshop Application Integration Controls ）
Liquid 數(shù)據(jù)視圖和源 （Liquid Data Views and Sources）
應用集成和Web services 工作流插件（Application integration and Web services workflow plug-ins）
統(tǒng)一用戶資料框架（The Unified User Profile Framework ）
Web services Portlet向導（The Web Services Portlet Wizard ）
以上內(nèi)容為使用Web services進行松耦合的企業(yè)門戶集成提供了非常強大的框架。請注意，本文假設讀者對WebLogic Portal 4.0和Integration 2.1非常熟悉，在BEA WebLogic Developer's Journal雜志中有關于WebLogic Portal 4.0和Integration 2.1的豐富的資料。
門戶集成（Portal Integration）：一個原型示例
我們的例子是一個IT技術支持部門的案例管理門戶。問題單根據(jù)技術支持工程師的專業(yè)（例如數(shù)據(jù)庫，用戶界面，事務管理）和技術等級（一級，二級等）分發(fā)。每個工程師有一個相關的資料，資料同時存在于一個安全的關系數(shù)據(jù)庫和一個外部的CRM系統(tǒng)中，資料中有該工程師的專業(yè)和技術等級信息，也可能有工程師的管理者——高級工程師的信息。高級工程師可以分析下屬的案例歷史，包括完成案例的平均時間和案例數(shù)量增長的百分比。每個案例的實際數(shù)據(jù)存在兩個外部問題單系統(tǒng)中，一個系統(tǒng)相對較新，使用了Web services，另一個系統(tǒng)較舊，有一個專有界面。除了核心的案例管理功能，每個工程師的門戶都可以個性化，使用另外的含有公開技術論壇的Portlet，含有內(nèi)部錯誤報告更新的Portlet，以及類似的Portlet。
應用視圖（Application Views）：實際上所有的內(nèi)容都可以展示
J2EE Connector Architecture （J2EE CA） 適配器是連接J2EE組件和外部企業(yè)信息系統(tǒng)（EIS）的橋梁。EIS所需的適配器接口經(jīng)常使用專有的協(xié)議、數(shù)據(jù)格式和認證機制。
WebLogic J2EE CA適配器處理協(xié)議轉換，也常用于處理數(shù)據(jù)格式的轉換，或者利用WebLogic里的證書映射提供者傳遞認證信息到EIS中，如果EIS含有XA，那么XA事務也可以傳遞。
J2EE CA 1.0規(guī)范沒有規(guī)定適配器的標準的接口（只提供了一個可選的接口），也沒有規(guī)定一個標準的信息格式或者EIS發(fā)出的異步事件。1.5規(guī)范（現(xiàn)在是建議最終草稿版的第二版）修補很多類似的漏洞，1.5版規(guī)范會包括在J2EE 1.4中。
WebLogic 集成應用視圖框架（WebLogic Integration Application View Framework）在J2EE CA 適配器之上提供了一層，彌補了1.0規(guī)范中的不足（1.5規(guī)范中的改進在此由應用視圖提供）。當你創(chuàng)建一個應用視圖的時候，你也指定了一個和相關業(yè)務服務以及EIS中的事件相對應的XML schema，當與請求schema相應的XML文件傳過來時，服務被激活，返回結果根據(jù)響應schema以相應的XML文件返回。事件以異步的方式分發(fā)到客戶端，同樣是按照協(xié)商好的schema，以 XML文件的形式傳遞。我們通過基于瀏覽器的應用集成控制臺（Application Integration console）來創(chuàng)建應用視圖，在控制臺里把服務和事件同適配器連在一起，指定相應的schema。
應用視圖服務可以被激活，事件監(jiān)聽器使用的是應用集成API.應用視圖可以在業(yè)務流程管理（BPM）工作流中使用，也可以做成Web services，相應的技術稍后介紹。
在我們的案例管理門戶示例中，我們把遺留系統(tǒng)的問題單和CRM系統(tǒng)的專有界面發(fā)布為應用視圖，每個視圖提供與相關系統(tǒng)對應的一套業(yè)務服務和異步事件。
Workshop應用集成控制：應用視圖發(fā)布為Web service
使用WebLogic Workshop的IDE簡化了Web service的開發(fā)、部署和調(diào)試。 Workshop還提供了透明信息緩沖和帶對話功能的有狀態(tài)Web service.WebLogic Workshop的開發(fā)人員可以利用一些特殊的控制（controls）輕松的把后端的J2EE組件發(fā)布為Web service.其中的一個控制允許Workshop的開發(fā)人員將應用視圖服務和事件發(fā)布為Web service.這樣，開發(fā)人員就可以通過Web service和所有的外部系統(tǒng)進行交互。
在我們的案例管理門戶示例中，我們使用Workshop應用集成控制把我們的遺留系統(tǒng)的專有界面對應的應用視圖發(fā)布為Web service，這樣我們面對的兩種系統(tǒng)就有相同的風格。
Liquid Data：實際上所有的事情都可以轉變?yōu)槠渌男问?/strong>
Liquid Data，是WebLogic Platform中新的功能強大的組件，提供在眾多的數(shù)據(jù)源（應用視圖、數(shù)據(jù)視圖、FTP站點、Web services等）之上創(chuàng)建視圖的能力。這些視圖可以串在一起（例如，視圖的視圖）。Liquid Data一旦定義，可以對這些視圖創(chuàng)建預先存儲的和動態(tài)的查詢。查詢可以通過已經(jīng)提供的EJB和基于JSP標記庫的API來配置和激活。查詢也可以發(fā)布為Web services.Liquid Data的理論基礎建立在XQuery規(guī)范的一個實現(xiàn)之上。Data View Builder包括Liquid Data的IDE（集成開發(fā)環(huán)境）和類似Workshop的GUI（圖形用戶界面），你可以創(chuàng)建針對數(shù)據(jù)源的視圖，針對視圖的預先存儲的查詢（開發(fā)人員可以使用XQuery語法來手工編寫高級查詢）。Data View Builder還提供測試和調(diào)試這些視圖和預先存貯的查詢的能力。
本文的目的之一就是介紹一種關鍵能力，即創(chuàng)建基于已有的應用視圖和Web services 的Liquid Data復合視圖。一個視圖可以傳遞特殊的Portlet或用戶資料（User Profile）所需的信息，轉換需要調(diào)整的信息，相應的設置可以公開進行，并不需要修改實際的應用視圖或Web services（或文件，數(shù)據(jù)庫等等）。
在我們的案例管理門戶示例中，可以創(chuàng)建支持工程師的統(tǒng)一用戶資料視圖，該視圖對應于安全關系數(shù)據(jù)庫和含有適配器的可以發(fā)布為CRM系統(tǒng)的應用視圖。同樣，可以創(chuàng)建一個或多個案例信息視圖來映射基于Web service的問題單和遺留系統(tǒng)，遺留系統(tǒng)的接口通過一個應用視圖發(fā)布。
工作流（Workflow）和Web services：BMP（業(yè)務流程管理）集成
工作流控制著企業(yè)業(yè)務處理的流程，它通過集成插件接入點和實際的業(yè)務邏輯緊密地聯(lián)結在一起。工作流通過BPM Studio GUI創(chuàng)建，Studio的界面有些像“Visio”，可以通過拖放的方式創(chuàng)建工作流。從工作流中可以直接呼叫應用視圖服務（Application view services），應用視圖事件可以通過應用集成插件來觸發(fā)工作流事件節(jié)點。同樣，從工作流事件中可以通過一個可以從BEA的開發(fā)人員站點下載的插件調(diào)用Web services，dev2dev的Web service插件提供一個GUI，允許開發(fā)人員把應用視圖服務發(fā)布為Web service（Workshop AI 控制的一個有限子集）。
在我們例子中的portal通過在流水線組件中調(diào)用BPM API與問題票務分派工作流打交道。一個工作流任務從兩套問題票務系統(tǒng)中獲取問題票務信息，該工作流在較新的系統(tǒng)中激活適當?shù)腤eb service，在另一個系統(tǒng)中激活應用視圖服務（application view services）。該工作流可以直接在BPM Studio GUI中創(chuàng)建，不需要任何手工編程。
統(tǒng)一用戶資料（Unified User Profile）：分類化和個性化集成
門戶中的包含用戶資料的屬性位于一個預先定制好的關系數(shù)據(jù)庫中。門戶的個性化和分類化組件（這些組件用來判斷你是誰，是什么，有什么興趣等等）使用用戶的資料屬性。你可以通過門戶的統(tǒng)一用戶資料（UUP）框架來把用戶資料擴展為企業(yè)級的資料。該框架允許一個開發(fā)人員從另一個可選資源（例如，LDAP，CRM/ERP系統(tǒng)）中把用戶屬性插入進來。簡而言之，開發(fā)人員只要執(zhí)行一個EntityPropertyManager EJB，就可以使用它來獲得擴展的用戶屬性。這個EJB以ProfileManager EJB為基準（你在這個EJB的部署描述環(huán)境中加入你的EntityPropertyManager信息）。
現(xiàn)在你開始使用EntityPropertyManager EJB，那你實際上要使用什么技術來獲得用戶的屬性？
如果外部系統(tǒng)的Web service是處于激活狀態(tài)，或者同樣的你使用Workshop、Liquid Data或者Web service BMP插件的GUI界面發(fā)布的Web service的話，你可以使用JAX-RPC從Web service中獲得信息。你可以使用Liquid Data Query API來把外部系統(tǒng)發(fā)布為Liquid Data View。如果外部系統(tǒng)有相應的由應用視圖（Application View）公布的J2EE CA 適配器的話，你可以使用應用集成API。你可以直接和J2EE CA 適配器交互。你可以使用私有的方法。
示例中的門戶根據(jù)Unified User Profile中的專業(yè)和資歷來進行問題單的分配。某個專業(yè)的工程師被指派為管理者的同時也成為一個管理權力集團（Management Entitlement Segment）的成員，可以訪問Engineer Case History Portlets，這些portlet允許管理人員根據(jù)某個工程師過去的案例處理情況來分析他或她的工作表現(xiàn)。就像剛才講的，本例中的EntityPropertyManager EJB可以使用JAX-RPC來獲得我們的用戶信息，發(fā)布為Liquid Data Web Services View。
Web Services Portlets：web層的集成
Web Services Portlets，如同它的名字所暗示，使用Web Services，然后以內(nèi)容的形式把結果顯示出來。這些portlet可以用Portal EBCC Portlet Wizard快速開發(fā)，從非�；镜膒ortlet類型到和使用用戶定義的數(shù)據(jù)類型進行動態(tài)的、異步交互的portlet類型。Web Services Portlets也可以參與到Workshop類型的交互中。
當今大多數(shù)精心設計的Web應用都采用Model 2 Web層結構模式。被廣泛使用的Apache Jakarta的“Struts”就是這種模式的很好應用。門戶的Webflow/Pipeline框架的工作模式與此類似。Model 2模式的基本原則是：分離業(yè)務（controller， model， and view）和“view”（我們的例子中是portlet）的分離，view的主要業(yè)務是顯示現(xiàn)在相關的model的內(nèi)容。從一個portlet中激活和使用一個或多個Web Service似乎會和以上原則沖突，實際上有時會有沖突發(fā)生。不過，某些情況下，不會有沖突發(fā)生：
使用的portlet單獨存在（一個單獨的“小型應用”）。 Web Service提供model的當前狀態(tài)（J2EE設計模式中Front Controller的View Helper策略）。Web Service激活的結果的格式是portlet用戶界面的形式。
在我們的原型示例系統(tǒng)中，一個支持工程師專門接收他們使用的關系數(shù)據(jù)庫的廠商發(fā)布的技術公告。該公告在門戶中的一個portlet中顯示。這是一個單獨的服務，和門戶中的其他portlet無關，而且信息是調(diào)用外部的Web Service獲得的。在這種情況下使用Web Services Portlet的另一個主要原因是從這個Web Services獲取信息就是用戶接口。
總結
本文介紹了WebLogic EntERPrise Platform的一些在構建企業(yè)門戶解決方案的時候可以使用的功能。本文的目的不是提供一個單一的，完整的結構（類似“寵物商店”的門戶集成簡單示例），也不是暗示在所有情況下（或者大多數(shù)情況下）必須使用某些工具和技術。在一個給定的環(huán)境中有太多的因素需要考慮。使用Web Service進行比較明智的門戶集成時，可以創(chuàng)建一個非常靈活的架構。但是如果不進行全盤考慮，一些重要的問題（例如性能、可擴展性、安全和事務協(xié)同性）就可能發(fā)生。這一點上，Web Service和其他的技術一樣。一個有經(jīng)驗的架構師明白這一點，所以既不會對Web Service過分狂熱，也不會因為Web Service的缺點而懷疑Web Service。
轉載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題：用Web Service進行企業(yè)級的門戶集成
本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839317699.html
相關文章
