個性化伺服器統一用戶特徵集的製作方法
2023-07-22 00:05:46 2
專利名稱：個性化伺服器統一用戶特徵集的製作方法
技術領域：
一般地，本發明涉及來自多個資源的數據的集成。
背景技術：
企業一直在尋找更好的方法，以將新信息與其現存數據集成，如可以從第三方資源獲取的有關當前或可能客戶的信息。為使這種集成有效，公司必須能夠簡化該集成過程，去除不必要的費用或採購，並去除中斷時間，一般需要該中斷時間以實現新的數據系統或修改現存數據結構。
例如，一個企業可能希望將額外的用戶特徵集數據整合到其已確立的用戶數據中。該額外的特徵集數據可以被分離的資源(如個性化伺服器)所配置與維護。經常該企業具有原來就存在的企業客戶或用戶數據，這些數據在該個性化伺服器範圍之外。該數據一般位於現存企業資料庫中，可能包括每個客戶的信息，如名稱、社會保險號碼、和/或公司特有的信息，例如特定航空公司的常客的飛行裡程。該企業會希望將該數據無縫地集成到其個性化解決方案之中，從而儘可能地避免數據遷移的困難。
因此本發明的目的在於為來自現存數據源的數據與來自外部來源的數據之間的集成，開發一種無縫的方法。
發明內容
本發明包括一種用來生成統一用戶特徵集(unified user profile)的系統。該系統包括第一數據源與第二數據源。用伺服器來訪問第一與第二數據源。該伺服器使用用戶組件，該用戶組件適用於將來自第一與第二數據源的數據聚合到統一用戶特徵集中。
本發明還包括用來生成統一用戶特徵集的結構。該結構可以建立在基本用戶企業Java Bean之上，該基本用戶企業Java Bean可以被擴展以整合來自用戶數據存儲的現存用戶數據。然後可以生成用戶特有企業Java Bean，其允許對現存用戶數據的透明讀和寫訪問。
本發明還包括一種用來生成統一用戶特徵集的方法。在一個實施例中，取得了適用於通過個性化伺服器工作以訪問個性化資料庫的基本用戶JavaBean。該基本用戶Java Bean提供了一種透明接口，通過該接口可以檢索並更新隱式與顯式的屬性。然後創建企業Java Bean，以擴展該基本用戶JavaBean，以便也可以從外部用戶資料庫檢索並更新隱式與顯式的屬性。
本發明還包括一種用來透明地訪問多個數據源的方法。在該方法中，取得了適用於通過伺服器工作以訪問內部數據源的基本用戶Java Bean。該基本用戶Java Bean提供了一種透明接口，通過該接口可以從該內部數據源檢索並更新隱式與顯式的屬性。然後擴展該基本用戶Java Bean，以便可以進一步提供一種透明接口，通過該接口可以從至少一個外部數據源中檢索並更新隱式與顯式的屬性。
本發明還包括一種用來透明地訪問多個數據源的系統。該系統使用伺服器與多個數據源通信。在該系統中包括了擴展的用戶Java Bean，該Java Bean適用於提供通過該伺服器的對數據源的透明訪問。
圖1示出根據本發明的一個實施例的UUP配置；圖2示出根據本發明的一個實施例的UUP配置；圖3示出根據本發明的一個實施例的UUP配置；圖4示出根據本發明的一個實施例的UUP配置；圖5(a)與5(b)的流程圖示出根據本發明的一個實施例的為隱式與顯式的情況調用setUserPoints的步驟；
圖6的流程圖示出根據本發明的一個實施例的運行ejbFind例程的步驟。
具體實施例方式
根據前面對本發明的概述，以下給出本發明實施例的詳細描述，該實施例目前被認為是最好的模式。
本發明的結構定義了現存用戶數據可以與更易動態變化的個性化數據進行整合的途徑。在伺服器中，例如用來為特定用戶或用戶組個性化內容或服務的個性化伺服器，系統用戶一般由用戶特徵集表示。用戶特徵集提供了用戶ID(標識)以及對用戶屬性的訪問，如年齡或電子郵件地址。屬性值可以是單值的或多值的，並可以通過將屬性名稱作為鍵值的getProperty函數或類似方法請求。
本發明的用戶特徵集的優點在於其可以被擴展並定製，以從現存數據源檢索用戶信息。例如，與伺服器(如個性化伺服器)或解決方案一起裝上的用戶特徵集，可以將用戶屬性(如來自個性化伺服器資料庫的屬性與來自LDAP伺服器或本領域已知的遺留資料庫的用戶屬性)組合到單一用戶特徵集之中，以備在應用中使用。然後，開發人員與系統用戶就不必擔心不同的底層數據源。為取得用戶信息，該用戶特徵集是唯一需要訪問的地方。
本發明的統一用戶特徵集(Unified User Profile，UUP)包括這種屬性聚合，其將來自現存數據源與個性化伺服器資料庫表的屬性聚合到單一的定製的用戶特徵集之中。更具體地，UUP通過擴展用戶組件，結合了現存用戶/客戶數據。通過將該個性化伺服器資料庫表裝入現存資料庫實例之中，並且擴展用戶實現，開發人員就能夠迅速創建定製的UUP，其能夠從現存資料庫中檢索屬性，並將屬性存儲/更新到現存資料庫中。需要這種靈活性是因為其允許對現存數據的訪問，而不對使用該數據的現存應用進行數據遷移或中斷。然而應該理解，如果需要，現存數據可以被遷移到分離的個性化伺服器資料庫實例中。
與其他伺服器解決方案相比，該UUP的一個主要優點在於該UUP不需要在資料庫管理系統(如客戶的關係型資料庫管理系統)中進行資料庫模式更新或數據遷移。該UUP最好通過編寫擴展EJB來創建，而不是通過更新資料庫表，或運行數據遷移腳本。現有技術的伺服器經常要求為額外的用戶屬性而更新用戶資料庫表模式。
圖1-4顯示本發明的UUP系統的可能配置。在圖1的第一配置100中，企業、遺留(legacy)、或其他外部資料庫102與個性化伺服器資料庫104向個性化伺服器110提供屬性數據。個性化伺服器110還從用戶數據存儲106接收信息，如驗證信息、用戶列表、組列表、以及組成員。該用戶數據存儲可以是任何適當的系統，如本領域已知的LDAP、Unix或NT系統。用戶數據存儲106還包括用於驗證的安全區108。個性化伺服器資料庫104與安全區108在本配置中保持分離，因為可能需要這種對驗證與檢索的分離，然而這對本發明的實現不是必須的。當用戶或組已經存在於某類數據存儲時，如LDAP目錄，可以使用該配置。然後該現存的用戶屬性數據被個性化伺服器110所取得，並被與個性化數據合併以生成UUP 112。
當用戶或組已經存在於用戶數據存儲204(如LDAP目錄)中，並且沒有現存用戶數據必須被結合到UUP 210中時，如圖2所示的第二配置200可能有用。此時，所有的用戶與組屬性數據最好都存儲在個性化伺服器資料庫202中。在本配置中，個性化伺服器208最好仍利用用戶數據存儲204的安全區206。
在沒有現存用戶與組的存儲的情形，如圖3所示的第三配置300可能有用。個性化伺服器資料庫302的表包含所有的用戶與組數據，並且最好還包含獨立的安全區304。此時個性化伺服器306在生成UUP 308時只需要查看個性化伺服器資料庫302。
當用戶、組、以及屬性數據位於企業、遺留、或其他外部資料庫402中，並且必須由個性化伺服器408聚合到UUP 410中時，如圖4所示的第四配置400可能有用。此時必須創建定製安全區404以通過個性化伺服器使用現存用戶與組。該定製安全區不必一定與外部資料庫402存儲在一起，但可以被聚合到個性化資料庫406之中。同樣，檢索與驗證區最好保持分離。
本發明的結構的一個實施例依賴於三個主要來源以將數據聚合到UUP中(1)基本用戶企業Java Bean(EJB)，(2)用戶數據存儲，以及(3)用戶特用企業Java Bean(EJB)。
基本用戶EJB為最好由個性化客戶所擴展的JAVA類，以將現存用戶數據聚合到個性化解決方案之中。
基本用戶EJB最好提供單一的透明接口，通過該接口可以檢索或更新隱式的屬性與顯式的屬性。該基本用戶EJB利用屬性集合，可以使用該集合以給出屬性的命名空間限定，以及定義屬性類型、允許值等等。屬性集合的行為類似用於用戶屬性的數據模式。此處所指的透明性一般指用戶或應用可以進行調用或請求，而不用關心數據存儲在哪裡或者該數據使用哪種命名約定(naming convention)。如果該數據在遺留資料庫中而不是個性化資料庫中，則UUP將自動處理該請求，而該用戶或應用永遠不用知道其位置或名稱。
在本發明的一個實施例中，基本用戶EJB的子類使用兩種方法以檢索或更新getProperty與setProperty。這些方法對隱式的或顯式的屬性都可以檢索和/或更新。這些方法可以設置如下public Object getProperty(String propertySetName，Stringproper tyName)；public void setProperty(String propertySetName，StringpropertyName，Object propertyValue)；這些方法最後使用兩個主要的屬性propertySetName與propertyName。propertySetName屬性指明此調用所採用的數據模式。這樣，propertySetName作為待檢索或更新的屬性的命名空間。propertyName屬性指明待更新或檢索的屬性的名稱。使用propertySetName-propertyName對的一個優點是可以在多個應用或子應用範圍內使用單一的propertyName。屬性名稱的多個實例也可以對應不同的定義。從基本用戶Bean檢索的屬性將被稱為隱式屬性。
用戶數據存儲可能在聚合之前就已經存在，一般是其中存儲有關當前用戶或客戶數據的資料庫或表。該表可以與個性化伺服器的資料庫實例位於一處。該現存用戶數據存儲可以包含獨立於個性化伺服器資料庫表而存在的用戶數據。該個性化伺服器可以要求現存用戶數據存儲與個性化伺服器表存在於同一RDBMS實例中。
表1顯示了示例的「AcmeCustomer」RDBMS表。該表為每個客戶定義三個值(1)Customer_Name(客戶名稱)，(2)Acme_Point(頂點)，以及(3)Acme_DisCount(頂點折扣)。Customer_Name被用作每個客戶的唯一標識符。一旦集成完成後，該唯一標識符最好被用來在整個個性化伺服器內唯一地辨別用戶。Acme_Points為樣品客戶價值。頂點客戶(Acme customer)可能在他或她購買頂點產品(Acme products)時收集點數。Acme_Discount為客戶在每次購買頂點產品時所獲得的折扣。
表1-AcmeCustmer(頂點客戶)RDBMS表
一旦完全理解了現存數據存儲，則可以編寫擴展基本用戶EJB的EJB，其利用透明的值檢索與更新服務。計算機領域的技術人員應該熟知擴展JavaBean的方法。
為集成現存用戶數據與由個性化伺服器所提供的個性化表，可以編寫EJB以擴展用戶Bean，該用戶Bean可以與個性化伺服器一起提供。一旦完成了該Bean，個性化伺服器的客戶就具有對以前存儲在用戶特有資料庫表(顯式的屬性)中的屬性、以及存儲在個性化伺服器的屬性表集合中的屬性(隱式的屬性)的透明讀和寫訪問。
繼續「頂點客戶」數據存儲的例子，可以編寫AcmeUser EJB(頂點用戶EJB)，其提供對現存表的數據更新與檢索機制。為在本發明的限定內運行，該AcmeUser EJB可以定義如下方法public Long getAcmePoints-返回客戶到目前為止所收集的點數。
public void setAcmePoints(Long newAcmePointsValue)-更新客戶的頂點點數。
public Double getAcmeDiscount-返回客戶當前的折扣。
public void setAcmeDiscount-更新客戶的頂點折扣。
從擴展的用戶Bean所檢索的屬性被稱為顯式的屬性。
一旦實現了擴展Bean的方法，則頂點點數與頂點折扣都可以用由基本用戶EJB所實現的getProperty與setProperty的繼承方法進行檢索。
因此，例如對用戶bsmith，下面的兩個方法都返回一包含值50000的長整形public Long getAcmePoints；
public Object getProperty(anyPropertySetName，「acmePoints」)；類似地，下面的每個方法都將bsmith的頂點點數更新為60,000public void setAcmePoints(new Double(60000))；public void setProperty(anyPropertySetName，「acmetPoints」，newDouble(60000))；在其對透明屬性更新與檢索的實現中，UUP最好使用Java自反性(reflection)的概念，以在將屬性當作隱式的處理並使用屬性集合的概念之前確定該屬性是否為顯式的。自反性是Java程式語言的一項特點，其使運行的Java程序能夠檢查或反省自身，以操縱該程序的內部屬性。如果propterName對應顯式的屬性，則最後在隱式的屬性之前進行顯式的屬性的更新與檢索。由於此搜索順序，如果正在更新或檢索顯式的屬性，則實際屬性集合的名稱無關緊要。
下面的例子展示了假想公司使用UUP以利用現存客戶數據。該例子擴展了用戶Bean並且從先前存在的資料庫中檢索數據。該例子顯示了如何能夠相對較容易地創建滿足應用的保存(persistence)需求的定製的UUP。下面的表2解釋了可以擴展什麼以創建定製UUP。
表2-示例擴展以創建定製UUP
UUP為ConfigurableEntity這一事實意味著用戶特徵集具有顯式地或隱式地設置與獲取屬性的概念。此處所稱的顯式地設置屬性指直接調用屬性的設置方法。隱式地設置屬性指在沒有顯式的設置方法時，通過setProperty方法來設置屬性。例如，如果UUP包含屬性「userPoints」，直接調用setUserPoints將顯式地設置userPoints屬性。用鍵值「userPoints」調用setProperty將隱式地設置userPoints屬性。在被調用時，setProperty先在用戶特徵集中查找setUserPoints設置方法來調用。如果存在這種設置方法，則該方法被調用，以設置該屬性，並進行任何與值中修改有關的必要處理。最終，由UUP實現來負責保存被顯式設置的屬性值，即使其是通過setProperty被隱式調用的。最好只有在不存在顯式的設置方法時，ConfigurableEntity才處理被隱式設置的屬性的保存。
圖5(a)與圖5(b)分別畫出了對setUserPoints的顯式550與隱式500調用。在這兩種情況中，由UUP Bean負責存儲userPoints值。如果在UUP Bean中不存在setUserPoints方法，則ConfiruableEntity實現將處理userPoints值的存儲。在圖5(a)的隱式情況中，調用setProperty502。系統檢查是否存在serUserPoints方法。如果存在，則調用setUserPoints506。如果不存在，則系統繼續執行setProperty 508。對於圖5(b)的顯式情況，對setUserPoints552的調用將只調用setUserPoints554。
這種隱式與顯式地設置屬性的概念允許在UUP實現中更高的靈活性。如果在獲取或設置屬性時需要發生任何特殊的邏輯，例如計算另一個值，則可以使用該屬性的設置或獲取方法來實現之。UUP之外的功能可以確信具有用於屬性訪問的setProperty方法與getProperty方法，從而不再需要知道屬性是否有自己的設置或獲取方法。例如，即使UUP只提供了getUserPoints方法來檢索userPoints，umgetpropertyJSP標記也可以檢索userPoints屬性值。這是因為UUP的getProperty方法可以在檢查其他地方之前先檢查其是否具有getUserPoints。具有顯式的設置與獲取方法的屬性被稱為「顯式屬性」，而只能通過調用setProperty來進行設置的屬性被稱為「隱式屬性」。
在實現定製UUP EJB時，可能只需要為UUP的顯式屬性實現顯式的獲取與設置方法。然後，這些設置與獲取的實現將在現存數據存儲中設置並檢索這些屬性值。
在一個實施例中，對UUP中所有的顯式屬性設置與獲取都採用了獲取PropertyName/設置PropertyName的方式。如果UUP具有顯式userPoints屬性，則提供顯式getUserPoints方法，因為retrieveUserPoints將不工作。類似地，用setUserPoints方法設置userPoints。在該實施例中，當通過隱式調用獲取和設置屬性時，getProperty與setProperty方法查找符合此約定的獲取與設置方法。不允許重設setProperty或getProperty。對顯式屬性的獲取與設置通過獲取與設置方法完成。顯式獲取與設置方法使用並返回對象。基本數據類型如長整形與浮點數被包裹起來，如在java.lang.Long與java.lang.Float對象中，以與ConfigurableEntity的getProperty與setProperty方法相容。
如果提供了獲取方法，則最好也提供設置方法，反之亦然，這是因為不能預測用戶或應用何時會想設置或獲取屬性。例如，如果提供了獲取方法用來從資料庫表中檢索屬性值，但沒有相應的設置方法，則調用setProperty將把該屬性存儲到個性化伺服器表中。這不是我們所需要的，因為該值是從一個地方檢索的，但是在另一個地方設置。下次檢索該屬性時，其將具有原來的值—而不是已設置的值。如果要提供只讀屬性，則可以實現空設置方法。
ConfigurableEntity的getProperty方法的優選定義如下Public Object getProperty(String propertySet，String propertyName，ConfigurableEntity explicitSuccessor，Object defaultValue)；getProperty方法最好按特定順序搜索屬性。例如，如果對用戶沒有發現屬性，則可查詢組來找該值。在這種情況中，該用戶將從組繼承該屬性值。用ConfigurableEntity的術語來說，組是用戶的「後繼(successor)」。如果在ConfigurableEntity中未發現屬性，則查詢ConfigurableEntity的後繼。這樣，ConfigurableEntity可以從父輩實體繼承並重設值。
後繼可以是隱式或顯式的。隱式後繼是ConfigurableEntity的預設後繼，或者為特定屬性集所設定的後繼。顯式後繼最好是可以作為參數傳遞給getProperty方法的ConfigurableEntity。下面是在優選ConfigurableEntity中存在的getProperty屬性搜索的順序為所指明的屬性集合的該屬性查看該實體。
為預設(空)屬性集合中的該屬性查看該實體。
為保留的屬性集合中的該屬性(如果使用LDAP域，則為來自LDAP的屬性)查看該實體。
在該實體的顯式後繼(如果已指明)中尋找該屬性。
在所指明的屬性集合的該實體的後繼中尋找該屬性。
在該實體的預設後繼中尋找該屬性。
如果指明了(非空)屬性集合，則尋找在該屬性集合中所定義的預設值。
返回傳入getProperty方法的defaultValue(預設值)。
ConfigurableEntity的setProperty方法的優選定義如下所示
Public Object setProperty(String propertySet，String propertyName，Object value)；如果在該優選方法中，setProperty被用來為屬性集合設置不符合屬性集合定義的屬性，則拋出異常。例如，假設「UnifiedUserExample」屬性集合被定義為具有整型的userPoints屬性。如果有人試圖為將「UnifiedUserExample」屬性集合的userPoints屬性設置為「abc」，則拋出異常，這是因為userPoints被定義為整型，而「abc」為文本。類似地，將布爾型屬性值設置為「bar」也將導致異常，這是因為布爾型值限定於布爾型對象。
如果調用setProperty並且傳遞空作為屬性集合，則可以在空屬性集合中設置該屬性值，該空屬性集合被稱為預設屬性集合。如上所述的getProperty搜索循序，最好在「保留」屬性集合與後繼中查找該屬性值之前搜索該預設屬性集合。
「保留」屬性集合最好為可以用來承載來自外部數據存儲的屬性值的只讀屬性集合。「保留」屬性集合可以在個性化伺服器中使用，如當從LDAP目錄檢索屬性值時。試圖設置「保留」屬性集合中的屬性可以導致拋出異常。「保留」屬性集合中的屬性及保留屬性集合本身不能通過用戶管理工具編輯。優選的用戶管理工具使用戶與組的屬性規範可以從LDAP或其他伺服器中檢索。然後在運行時，只檢索這些屬性。
可以通過setProperty用不存在的特定屬性集合設置屬性。這可能不是我們所希望的。當這樣做時，並沒有為所指明的屬性集合名稱臨時創建屬性集合。而是所指明的屬性集合名稱只作為該屬性的命名空間。類似地，我們可能不希望通過setProperty來為現存屬性集合設置在該屬性集合中不存在的屬性。通過這些途徑設置的屬性不能通過用戶管理工具編輯，而在「空」或「預設」屬性集合中的屬性可以用戶管理工具編輯。
如果調用setProperty時傳遞java.lang.Integer對象值，則調用getProperty時最好返回java.lang.Long對象。檢索此類屬性的代碼可能如下所示Object value＝myUser.getProperty(「my_property_set」，「my_integer_property」，null，null)；Number tempNumber＝(Number)value；
int realValue＝tempNumber.intValue；如果以java.lang.Float對象調用setProperty，則調用getProperty時最好返回java.lang.Double對象。檢索此類屬性的代碼可能如下所示Object value＝myUser.getProperty(「my_property_set」，「my_float_property」，null，null)；Number tempNumber＝(Number)value；float realValue＝tempNumber.intValue；用戶對象最好提供用於EJB查找操作的功能，該功能將簡化UUP與個性化伺服器的集成。圖6示出ejbFind操作的流程圖。擴展的UUP ejbFind在現存數據存儲中搜索記錄602。如果成功，則調用super.ejbFind604，即用戶對象ejbFind。如果成功，則該用戶對象ejbFind將為該UUP在個性化伺服器資料庫表中創建所需的記錄(如果這些記錄不存在的話610)，並返回適當的主鍵。如果用戶對象ejbFind失敗，則檢查的底層安全域608，以確定該用戶名是否與有效用戶對應。如果是，則用戶對象ejbFind創建所需記錄610，由此消除了查找方法錯誤以及原來將用戶數據遷移到個性化伺服器用戶資料庫表中所需的時間。如果ebjFind失敗或者該域中不存在該用戶，則會遇到查找方法錯誤606。如果沒遇到查找方法錯誤，則返回適當的主鍵612。
如果此配置中該域無法確認用戶的存在，但又必須創建該用戶，則可由EJB負責來創建原來未找到的超類記錄。
在生成定製UUP的一個實施例的最後一步，要求將UUP在個性化或其他伺服器上註冊，例如通過用戶管理工具。為了註冊該UUP，優選的用戶管理工具使用下表3表3-註冊UUP(例子)
通過將UUP在個性化伺服器上註冊，便可以用umgetprofileJSP標記請求該新特徵集類型umgetprofile profileType＝「UnifiedUserExample」profileKey＝「％＝username％」/
這樣便可能通過umgetproperty與umsetpropertyJSP標記使用UUP。
LDAP屬性檢索支持除對隱式與顯式屬性的透明檢索/更新外，統一用戶特徵集機制的一個實施例還支持從LDAP伺服器檢索用戶數據，而不需要來自個性化伺服器客戶的Java代碼。藉助一組管理工具，可以在應用運行時用屬性請求從LDAP伺服器檢索用戶與組屬性的規範。優選的方案是對個性化伺服器客戶檢索LDAP屬性的唯一要求就是該客戶部署LDAP安全域。在運行時，UUP查詢特定配置信息，以檢測當前是否在使用LDAP安全域。如果是，則待檢索的用戶與組屬性的名稱可以從LDAPConfiguration(LDAP配置)會話Bean得到，並且f檢索當前用戶的適當屬性。可以不要求客戶使用LDAP安全域，也能獲得其他UUP功能的好處。
本發明的其他特徵、方面與目標可以從附圖與權利要求中發現。應該理解可以開發本發明的其他實施例，而其都落入本發明與權利要求的精神與範圍內。
以上對本發明優選實施例的描述用於顯示與說明目的。其並非窮盡，也非用來將本發明限定於所公開的具體形式中。顯然，對本領域的普通技術人員來講，明顯可有許多改進與變化。選擇並描述實施例是為了最清楚地解釋本發明的原理及其實際的應用，以使本領域其他技術人員能夠理解本發明，其可應用於與所構想的特定用途相適應的各種實施例與各種修改。本發明的範圍由所附權利要求界定。
權利要求
1.一種用於生成統一用戶特徵集的系統，以允許對多個數據源的透明訪問，該系統包括(a)第一數據源；(b)第二數據源；以及(3)伺服器，適用於訪問所述第一與第二數據源，所述伺服器包括組件，該組件適用於將來自所述第一與第二數據源的數據聚合到統一用戶特徵集內。
2.根據權利要求1的系統，其中所述第一數據源選自包括遺留資料庫、企業資料庫以及用戶數據存儲的組。
3.根據權利要求1的系統，其中所述第一數據源包含選自包括驗證信息、用戶列表、組列表、與組成員的組的數據。
4.根據權利要求1的系統，還包括安全域，該安全域適用於允許對在所述第一數據源與第二數據源中至少一個中的數據的驗證。
5.根據權利要求1的系統，其中所述伺服器為個性化伺服器。
6.根據權利要求1的系統，其中所述組件包含企業Java Bean。
7.根據權利要求6的系統，其中所述企業Java Bean使用選自getProperty與setProperty組的方法，檢索並更新在所述第一數據源與第二數據源中至少一個中的數據。
8.根據權利要求1的系統，其中所述組件包含擴展的Java Bean。
9.根據權利要求1的系統，其中所述組件提供透明接口，通過該接口可以檢索並更新隱式與顯式的屬性。
10.根據權利要求9的系統，其中所述組件包含屬性集合，所述屬性集合適給出所述隱式與顯式的屬性的命名空間限定。
11.根據權利要求1的系統，其中所述組件包含獲取方法與設置方法屬性。
12.根據權利要求1的系統，其中所述組件提供透明接口，該接口適用於從所述第一數據源與所述第二數據源存儲並檢索數據。
13.根據權利要求1的系統，其中所述第二數據源為個性化資料庫。
14.一種用於生成用來透明訪問現存用戶數據的統一用戶特徵集的結構，該結構包括(a)基本用戶企業Java Bean，所述基本用戶企業Java Bean能夠被擴展以整合所述現存用戶數據；(b)用戶數據存儲，適用於包含所述現存用戶數據；以及(c)用戶特有企業Java Bean，適用於提供對所述現存用戶數據的透明讀和寫訪問。
15.根據權利要求14的結構，還包括包含所述現存用戶數據之外的數據的數據源。
16.根據權利要求15的結構，其中所述用戶特有企業Java Bean還允許對所述數據源內的所述數據的透明讀和寫訪問。
17.根據權利要求14的結構，還包括伺服器，該伺服器適用於向所述統一用戶特徵集的用戶提供所述讀和寫訪問。
18.根據權利要求17的結構，其中所述伺服器為個性化伺服器。
19.根據權利要求14的結構，其中所述用戶數據存儲為內部數據源中的表，該內部數據源選自包括遺留資料庫、企業資料庫以及客戶資料庫的組。
20.根據權利要求14的結構，其中所述用戶數據存儲包含選自包括驗證信息、用戶列表、組列表、與組成員的組的數據。
21.根據權利要求14的結構，還包括安全域，該安全域適用於允許對所述用戶數據存儲內的數據的驗證。
22.根據權利要求14的結構，其中所述用戶特有企業Java Bean利用屬性集合，所述屬性集合適用於給出所述現存用戶數據的隱式與顯式的屬性的命名空間限定。
23.根據權利要求14的結構，其中所述用戶特有企業Java Bean利用獲取方法與設置方法屬性。
24.一種用於生成用來提供對個性化資料庫與外部用戶資料庫的透明訪問的統一用戶特徵集的方法，所述方法包括下列步驟(a)取得基本用戶Java Bean，該基本用戶Java Bean適用於通過個性化伺服器工作，以訪問所述個性化資料庫，所述基本用戶Java Bean適用於提供透明接口，通過該接口可以從該個性化資料庫檢索並更新隱式與顯式的屬性；以及(b)創建企業Java Bean，以擴展基本用戶企業Java Bean，使可以進一步從外部用戶資料庫檢索並更新隱式與顯式的屬性。
25.根據權利要求24的方法，還包括通過所述擴展的基本用戶JavaBean，生成對所述外部資料庫的透明讀和寫訪問。
26.根據權利要求24的方法，還包括配置伺服器以提供所述讀和寫訪問。
27.根據權利要求26的方法，其中所述伺服器為個性化伺服器。
28.根據權利要求24的方法，其中所述外部用戶資料庫選自包括遺留資料庫、企業資料庫以及客戶資料庫的組。
29.根據權利要求24的方法，其中所述外部用戶數據包含選自包括驗證信息、用戶列表、組列表、與組成員的組的數據。
30.根據權利要求24的方法，還包括步驟獲取安全域，該安全域適用於允許對所述個性化資料庫與所述外部用戶資料庫內的數據的驗證。
31.根據權利要求24的方法，其中所述擴展的基本用戶Java Bean利用屬性集合，所述屬性集合適用於給出所述個性化資料庫中所述數據的隱式與顯式的屬性的命名空間限定。
32.根據權利要求31的方法，其中所述隱式與顯式的屬性包含獲取方法與設置方法屬性。
33.一種用來透明地訪問多個數據源的方法，所述方法包括以下步驟(a)取得基本用戶Java Bean，該基本用戶Java Bean適用於通過伺服器工作，以訪問內部數據源，所述基本用戶Java Bean適用於提供透明接口，通過該接口可以檢索並更新隱式與顯式的屬性；以及(b)擴展基本用戶Java Bean，使所述基本用戶Java Bean進一步適用於提供透明接口，通過該接口可以從至少一個外部數據源檢索並更新隱式與顯式的屬性。
34.根據權利要求33的方法，還包括步驟配置伺服器，以操作所述透明接口。
35.根據權利要求33的方法，還包括步驟獲取安全域，該安全域適用於允許對所述內部數據源與所述外部數據源內的數據的驗證。
36.根據權利要求33的方法，還包括步驟為擴展的用戶Java Bean配置屬性集合。
37.根據權利要求35的方法，其中所述屬性集合適用於給出所述內部數據源與外部數據源內所述數據的隱式與顯式的屬性的命名空間限定。
38.根據權利要求37的方法，其中所述隱式與顯式的屬性包含獲取方法與設置方法屬性。
39.根據權利要求37的方法，還包括步驟使用自反性以確定所述內部數據源與外部數據源內所述數據的屬性是否為顯式的。
40.一種用於透明地訪問多個數據源的系統，所述系統包括(a)多個數據源；(b)與每個所述數據源進行通信的伺服器；以及(c)擴展的用戶Java Bean，該擴展的用戶Java Bean適用於提供通過所述伺服器對所述多個數據源的透明訪問。
41.根據權利要求40的系統，其中所述數據源中至少一個選自包括遺留資料庫、企業資料庫以及用戶數據存儲的組。
42.根據權利要求40的系統，還包括安全域，該安全域適用於允許對所述多個數據源中至少一個內的數據的驗證。
43.根據權利要求40的系統，其中所述伺服器為個性化伺服器。
44.根據權利要求40的系統，其中所述擴展的用戶Java Bean使用選自包括getProperty與setProperty組的方法，檢索並更新在所述多個數據源中至少一個中的數據。
45.根據權利要求40的系統，其中所述擴展的用戶Java Bean適用於允許對所述多個數據源內的數據的隱式與顯式的屬性的檢索與更新。
46.根據權利要求45的系統，其中所述擴展的用戶Java Bean用屬性集合，所述屬性集合適用於給出所述隱式與顯式的屬性的命名空間限定。
47.根據權利要求45的系統，其中所述隱式與顯式的屬性包含獲取方法與設置方法屬性。
48.一種用於統一多個數據源的系統，所述系統包括(a)一套命名約定，在存儲與訪問數據源內的數據時應該遵守該約定；(b)多個數據源，至少一個數據源包含不遵循所述命名約定的數據項；(c)標識符對集合，每對標識符相應於不遵循所述命名約定的數據項，該標識符對包括項名稱及遵循命名約定的相應名稱；以及(d)與每個所述數據源及標識符對集合進行通信的伺服器，該伺服器適用於允許遵循所述命名約定的請求對數據源的訪問。
49.根據權利要求48的系統，其中所述多個數據源中的至少一個選自包括遺留資料庫、企業資料庫以及用戶數據存儲的組。
50.根據權利要求48的系統，還包括安全域，該安全域適用於允許對在所述多個數據源的至少一個中的數據的驗證。
51.一種用於生成適用於允許對多個數據源的透明訪問的統一用戶特徵集的系統，該包括伺服器的系統包括(a)第一組件，適用於訪問第一數據源；(b)第二組件，適用於訪問第二數據源；以及(c)用戶組件，適用於將來自第一與第二數據源的數據聚合到統一用戶特徵集中。
52.根據權利要求51的系統，還包括組件，該組件適用於訪問安全域，以對在所述第一數據源與第二數據源的至少一個中的數據進行驗證。
53.根據權利要求51的系統，其中用戶組件包含企業Java Bean。
54.根據權利要求51的系統，其中用戶組件使用選自包括getProperty與setProperty組的方法，檢索並更新所述第一數據源與第二數據源的至少一個中的數據。
55.根據權利要求51的系統，其中用戶組件提供透明接口，通過該接口可以檢索並更新隱式與顯式的屬性。
56.根據權利要求55的系統，其中用戶組件包含屬性集合，所述屬性集合適用於給出所述隱式與顯式的屬性的命名空間限定。
57.根據權利要求51的系統，其中用戶組件包含獲取方法與設置方法屬性。
58.一種用於生成適用於提供對用戶數據的訪問的特徵集的結構，該結構包括(a)基本用戶企業Java Bean，所述基本用戶企業Java Bean能夠整合用戶數據；以及(b)用戶特有企業Java Bean，適用於提供對用戶數據的透明讀和寫訪問。
59.根據權利要求58的結構，還包括伺服器，該伺服器適用於提供對用戶數據的讀和寫訪問。
60.根據權利要求58的結構，其中所述用戶數據存儲包含選自包括驗證信息、用戶列表、組列表、與組成員的組的數據。
61.根據權利要求58的結構，其中所述用戶特有企業Java Bean利用屬性集合，所述屬性集合適用於給出用戶數據的隱式與顯式的屬性的命名空間限定。
62.根據權利要求59的結構，其中用戶特有企業Java Bean利用獲取方法與設置方法屬性。
63.一種包含指令的計算機可讀介質，該指令由伺服器執行時，使該伺服器執行以下步驟(a)取得基本用戶Java Bean，該基本用戶Java Bean適用於通過該伺服器工作，以訪問第一資料庫，所述基本用戶Java Bean適用於提供透明接口，通過該接口可以從第一資料庫檢索並更新隱式與顯式的屬性；以及(b)創建企業Java Bean以擴展基本用戶Java Bean，使所述隱式與顯式的屬性也可以從第二資料庫檢索並更新。
64.根據權利要求63的計算機可讀介質，其中該介質還使伺服器通過所述擴展的基本用戶Java Bean，生成對第二資料庫的透明讀和寫訪問。
65.根據權利要求63的計算機可讀介質，其中該介質還使伺服器獲取安全域，該安全域適用於允許對在第一資料庫與第二資料庫內的數據的驗證。
66.根據權利要求63的計算機可讀介質，其中擴展的基本用戶Java Bean利用屬性集合，所述屬性集合適用於第一資料庫中所述數據的隱式與顯式的屬性的命名空間限定。
67.根據權利要求63的計算機可讀介質，其中擴展的基本用戶Java Bean使用獲取方法與設置方法屬性。
全文摘要
本發明包括利用統一用戶特徵集(112)的系統及用來生成統一用戶特徵集(112)的方法，該統一用戶特徵集用來提供對多個數據源的透明接口。取得基本用戶Java Bean以通過個性化伺服器(110)工作，並訪問個性化資料庫(104)。該基本用戶Java Bean提供了透明接口，通過該接口可以檢索並更新隱式與顯式的屬性。然後創建企業Java Bean，以擴展該基本用戶Java Bean，使隱式與顯式的屬性也可以通過該透明接口從外部用戶資料庫進行檢索與更新。
文檔編號G06F17/30GK1516839SQ02812143
公開日2004年7月28日 申請日期2002年4月25日 優先權日2001年4月25日
發明者米歇爾·比森, 米歇爾 比森, 布裡登, 蒂莫西·布裡登, 帕克拉特, 查爾斯·帕克拉特, 斯塔姆, 湯姆·斯塔姆, 威爾科克斯, 史蒂文·威爾科克斯 申請人:Bea系統公司