个性化服务器统一用户特征集的制作方法

专利名称：个性化服务器统一用户特征集的制作方法
技术领域：
一般地，本发明涉及来自多个资源的数据的集成。
背景技术：
企业一直在寻找更好的方法，以将新信息与其现存数据集成，如可以从第三方资源获取的有关当前或可能客户的信息。为使这种集成有效，公司必须能够简化该集成过程，去除不必要的费用或采购，并去除中断时间，一般需要该中断时间以实现新的数据系统或修改现存数据结构。
例如，一个企业可能希望将额外的用户特征集数据整合到其已确立的用户数据中。该额外的特征集数据可以被分离的资源(如个性化服务器)所配置与维护。经常该企业具有原来就存在的企业客户或用户数据，这些数据在该个性化服务器范围之外。该数据一般位于现存企业数据库中，可能包括每个客户的信息，如名称、社会保险号码、和/或公司特有的信息，例如特定航空公司的常客的飞行里程。该企业会希望将该数据无缝地集成到其个性化解决方案之中，从而尽可能地避免数据迁移的困难。
因此本发明的目的在于为来自现存数据源的数据与来自外部来源的数据之间的集成，开发一种无缝的方法。

发明内容
本发明包括一种用来生成统一用户特征集(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)的隐式情况中，调用setProperty()502。系统检查是否存在serUserPoints()方法。如果存在，则调用setUserPoints()506。如果不存在，则系统继续执行setProperty 508。对于图5(b)的显式情况，对setUserPoints()552的调用将只调用setUserPoints()554。
这种隐式与显式地设置属性的概念允许在UUP实现中更高的灵活性。如果在获取或设置属性时需要发生任何特殊的逻辑，例如计算另一个值，则可以使用该属性的设置或获取方法来实现之。UUP之外的功能可以确信具有用于属性访问的setProperty()方法与getProperty()方法，从而不再需要知道属性是否有自己的设置或获取方法。例如，即使UUP只提供了getUserPoints()方法来检索userPoints，<umgetproperty>JSP标记也可以检索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.ejbFind()604，即用户对象ejbFind()。如果成功，则该用户对象ejbFind()将为该UUP在个性化服务器数据库表中创建所需的记录(如果这些记录不存在的话610)，并返回适当的主键。如果用户对象ejbFind()失败，则检查的底层安全域608，以确定该用户名是否与有效用户对应。如果是，则用户对象ejbFind()创建所需记录610，由此消除了查找方法错误以及原来将用户数据迁移到个性化服务器用户数据库表中所需的时间。如果ebjFind()失败或者该域中不存在该用户，则会遇到查找方法错误606。如果没遇到查找方法错误，则返回适当的主键612。
如果此配置中该域无法确认用户的存在，但又必须创建该用户，则可由EJB负责来创建原来未找到的超类记录。
在生成定制UUP的一个实施例的最后一步，要求将UUP在个性化或其他服务器上注册，例如通过用户管理工具。为了注册该UUP，优选的用户管理工具使用下表3表3-注册UUP(例子)

通过将UUP在个性化服务器上注册，便可以用<umgetprofile>JSP标记请求该新特征集类型<umgetprofile profileType＝“UnifiedUserExample”profileKey＝“<％＝username％>”/>
这样便可能通过<umgetproperty>与<umsetproperty>JSP标记使用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系统公司