Liquid Data & Portal 白皮书系列
统一用户配置文件（Unified User Profile, UUP）是BEA门户产品的重要组件，因为它考虑了基于存储在异构数据源的用户属性的用户体验的个性化。尽管UUP提供了丰富的个性化能力，但是将UUP与大量的包含用户信息的数据源连接起来仍颇具挑战性。
在此技术白皮书中，介绍了基于Liquid Data的用于集成多后端源的UUP信息的方法如何降低构建UUP的成本和复杂性，同时提高其可用性和可维护性。
UUP－门户中丰富个性化的关键
传统门户的个性化服务是基于企业LDAP服务器的可用信息。LDAP通常包含用户的登录信息和其他信息，如用户的角色、用户的部门等。
这种方法的优点是简单和易于部署。缺点是它并不能对其他的、通常是多个后端数据源的信息进行复杂的概要分析（profiling）。
BEA UUP 超越了这个简单的方法，因为它不仅可以集成一个LDAP服务器的个性化服务信息，而且可以集成多数据源的个性化服务信息。UUP可让BEA WebLogic Portal对根据用户配置文件中的数据进行动态个性化服务。用户配置文件也可以存储用户地址、联系信息以及特定于应用程序属性的信息。用户配置文件信息是从多种外部数据源集成而来的，包括自定义用户数据库和LDAP。
如果数据源的数量较少（1-3个），则UUP的配置就很简单。但是大多数公司通常要从更多数据源中提取UUP数据。例如，在最近的一次业务中，一个客户需要从8种不同的数据源中提取UUP数据：LDAP系统、两个CRM系统、一个订单跟踪系统、web日志、一个呼叫中心应用程序和一个金融应用程序。
尽管UUP对于LDAP来说是前进了一大步，但是当与大量的数据源相连时，它有以下几个主要问题：
· 长开发周期：UUP方法要求从多后端系统中构建自定义集成。对于一个典型的企业级的门户工程来说，如果该工程需要的UUP信息的数据源超过10个，那么集成就需要3个月以上的时间。
· 可维修性：而且，UUP集成是脆弱的。一旦UUP需求有变，或某个底层数据源的架构有变，那么用于访问数据源的EJB就会崩溃。在一个访问多种数据源的典型的企业级门户中，它会发现自己已陷入一个永不停止的过程，那就是不停的重建和重测试UUP集成。
· 有限用户自定义：由于构建和维护UUP信息是困难的，所以用户并没有充分利用UUP的所有功能，而只是局限在那些“必要”的信息上，这也就限制了公司从基于UUP的个性化服务中可获得的效益。
· 可重用性：用硬编码数据访问构建的UUP意味着投入到构建UUP的集成工作不能被同一数据源中的其他数据访问所利用。
用Liquid Data的UUP
Liquid Data作为一个虚拟数据源，它使得对所有后端信息的操作就像对一个单一的综合的全局数据源操作一样。
在本方法中，UUP并不直接查询底层数据源，而是查询作为虚拟数据源的Liquid Data。反过来，Liquid Data会将查询分解为针对每个独立数据源的子查询和函数调用。这样一来，门户应用程序现在就可以构建简单的UUP 应用来访问多数据源（>3）的数据了。
Liquid Data可让您对物理源中的信息进行可视化，并将其映射到您希望的UUP格式中。Liquid Data的图形工具可让您对多数据源中的信息进行访问、转换和连接，所以您就可以很合算地构建更全面的UUP，并为用户提供更加丰富的个性化服务和更好的体验。
门户中基于Liquid Data方法的UUP的好处
· 开发周期短：Liquid Data加速多数据源的集成。例如， 在最近的POC中，我们看到一些工程如果使用Liquid Data只需两周时间即可，而如果不用Liquid Data则需要三个月的时间。
· 较好的可维护性：当UUP需求有变，或底层数据源的架构有变，那么该数据体系结构就会相应的改变Liquid Data中的映射以反映这些变化。因此，基于Liquid Data的UUP信息更易维护。
· 较好的用户自定义：一旦构建和维护UUP信息变得容易，那么企业就会充分利用UUP的功能，而不只是局限在那些“必要”信息上。
· 重用Liquid Data和构建portlet的统一观点：一旦部署，Liquid data就可用来支持客户服务门户、HR门户、SFA系统、多渠道配送服务、外部化的web服务等。
结束语
实现UUP的关键挑战是对不同数据源的访问。基于Liquid Data的方法能够简化UUP的开发，并且很合算地构建更全面的UUP，因此为用户提供更加丰富的个性化服务和更好的体验。
|
