在实际工作中构建大型的应用很难。通常你会把门户（portal）和企业集成（eai）搞混，这样你的工作更难完成。你必须做出一系列的困难决定，很多决定也许会对项目的其余部分产生或好或坏的影响。

    在你做出架构性的重要选择之前，都应该深入考虑你构建的应用的每一层（ 从前端的负载平衡系统到后端的企业级的系统，也许是全球性的）。即使只是处理这些问题的一个子集（也许"只是"代表那些与门户集成相关的一些问题），你也将面临很多棘手问题：

    为了得到最好的效果，我是不是应该把我的web层和一些流程组件连接起来，让这些组件充当工作流和应用集成层的业务代理，让集成层处理eai的复杂问题？是不是每次都可以按这样的套路进行呢？

    我的web层和工作流层是不是应该采用松耦合（例如，使用jms），或者在某种情况下，为了利用bmp（business process management）的api提供的工作列表（worklist）功能的好处，是否可以不用松耦合？

    在创建统一用户资料（unified user profile）时，我如何精确的和crm，erp和安全系统打交道？

    门户内容管理参考实现是否提供了足够多的功能？我是不是需要评估一下第三方的解决方案？

    我们是否应该利用新的证书映射提供者（credential mapping provider）通过j2ee ca adapters传递认证信息？还是用web services的saml （security assertion markup language）？我们的第三方单点登陆（single sign-on （sso））安全系统是否支持这些机制？我有没有sso？我是否需要一个呢？

    幸运的是，这只是一篇杂志中的文章，所以我们可以先把一些问题放在一边，以利于我们集中精力，减少篇幅。本文描述了weblogic 7.0 enterprise platform里可以用来在门户中用web services进行集成的一些工具和技术。在一个简要的原型系统例子中我们对这些技术进行了演示。这里我定义的门户集成是指：把从不同的资源（通常是外部的）中获得的信息，通过检索、转换、组织、显示，形成统一的、个性化的整体。本文主要是讨论web service，所以只是简要介绍这些门户集成功能中对第三方的内容和文档的管理的功能，该功能在企业架构中应当被考虑。我将简要介绍以下内容：

    j2ee ca 应用视图（j2ee ca application views）

    workshop application集成控制（workshop application integration controls ）

    liquid 数据视图和源 （liquid data views and sources）

    应用集成和web services 工作流插件（application integration and web services workflow plug-ins）

    统一用户资料框架（the unified user profile framework ）

    web services portlet向导 （the web services portlet wizard ）

    以上内容为使用web services进行松耦合的企业门户集成提供了非常强大的框架。请注意，本文假设读者对weblogic portal 4.0和integration 2.1非常熟悉，在http://e-docs.bea.com和bea weblogic developer's journal杂志中都有关于weblogic portal 4.0和integration 2.1的丰富的资料。

    门户集成（portal integration）：一个原型示例

    我们的例子是一个it技术支持部门的案例管理门户。问题单根据技术支持工程师的专业（例如数据库，用户界面，事务管理）和技术等级（一级，二级等）分发。每个工程师有一个相关的资料，资料同时存在于一个安全的关系数据库和一个外部的crm系统中，资料中有该工程师的专业和技术等级信息，也可能有工程师的管理者――高级工程师的信息。高级工程师可以分析下属的案例历史，包括完成案例的平均时间和案例数量增长的百分比。每个案例的实际数据存在两个外部问题单系统中，一个系统相对较新，使用了web services，另一个系统较旧，有一个专有界面。除了核心的案例管理功能，每个工程师的门户都可以个性化，使用另外的含有公开技术论坛的portlet，含有内部错误报告更新的portlet，以及类似的portlet.

    应用视图（application views）：实际上所有的内容都可以展示

    j2ee connector architecture （j2ee ca） 适配器是连接j2ee组件和外部企业信息系统（eis）的桥梁。eis所需的适配器接口经常使用专有的协议、数据格式和认证机制。weblogic j2ee ca适配器处理协议转换，也常用于处理数据格式的转换，或者利用weblogic里的证书映射提供者传递认证信息到eis中，如果eis含有xa，那么xa事务也可以传递。

    j2ee ca 1.0规范没有规定适配器的标准的接口（只提供了一个可选的接口），也没有规定一个标准的信息格式或者eis发出的异步事件。1.5规范（现在是建议最终草稿版的第二版）修补很多类似的漏洞，1.5版规范会包括在j2ee 1.4中。

    weblogic 集成应用视图框架（weblogic integration application view framework）在j2ee ca 适配器之上提供了一层，弥补了1.0规范中的不足（1.5规范中的改进在此由应用视图提供）。当你创建一个应用视图的时候，你也指定了一个和相关业务服务以及eis中的事件相对应的xml schema，当与请求schema相应的xml文件传过来时，服务被激活，返回结果根据响应schema以相应的xml文件返回。事件以异步的方式分发到客户端，同样是按照协商好的schema，以 xml文件的形式传递。我们通过基于浏览器的应用集成控制台（application integration console）来创建应用视图，在控制台里把服务和事件同适配器连在一起，指定相应的schema.

    应用视图服务可以被激活，事件监听器使用的是应用集成api.应用视图可以在业务流程管理（bpm）工作流中使用，也可以做成web services，相应的技术稍后介绍。

    在我们的案例管理门户示例中，我们把遗留系统的问题单和crm系统的专有界面发布为应用视图，每个视图提供与相关系统对应的一套业务服务和异步事件。

    workshop应用集成控制：应用视图发布为web service

    使用weblogic workshop的ide简化了web service的开发、部署和调试。 workshop还提供了透明信息缓冲和带对话功能的有状态web service.weblogic workshop的开发人员可以利用一些特殊的控制（controls）轻松的把后端的j2ee组件发布为web service.其中的一个控制允许workshop的开发人员将应用视图服务和事件发布为web service.这样，开发人员就可以通过web service和所有的外部系统进行交互。

    在我们的案例管理门户示例中，我们使用workshop应用集成控制把我们的遗留系统的专有界面对应的应用视图发布为web service，这样我们面对的两种系统就有相同的风格。

    liquid data：实际上所有的事情都可以转变为其他的形式

    liquid data，是weblogic platform中新的功能强大的组件，提供在众多的数据源（应用视图、数据视图、ftp站点、web services等）之上创建视图的能力。这些视图可以串在一起（例如，视图的视图）。liquid data一旦定义，可以对这些视图创建预先存储的和动态的查询。查询可以通过已经提供的ejb和基于jsp标记库的api来配置和激活。查询也可以发布为web services.liquid data的理论基础建立在xquery（http://www.w3.org/tr/xquery）规范的一个实现之上。data view builder包括liquid data的ide（集成开发环境）和类似workshop的gui（图形用户界面），你可以创建针对数据源的视图，针对视图的预先存储的查询（开发人员可以使用xquery语法来手工编写高级查询）。data view builder还提供测试和调试这些视图和预先存贮的查询的能力。

    本文的目的之一就是介绍一种关键能力，即创建基于已有的应用视图和web services 的liquid data复合视图。一个视图可以传递特殊的portlet或用户资料（user profile）所需的信息，转换需要调整的信息，相应的设置可以公开进行，并不需要修改实际的应用视图或web services（或文件，数据库等等）。

    在我们的案例管理门户示例中，可以创建支持工程师的统一用户资料视图，该视图对应于安全关系数据库和含有适配器的可以发布为crm系统的应用视图。同样，可以创建一个或多个案例信息视图来映射基于web service的问题单和遗留系统，遗留系统的接口通过一个应用视图发布。

    工作流（workflow）和web services：bmp（业务流程管理）集成

    工作流控制着企业业务处理的流程，它通过集成插件接入点和实际的业务逻辑紧密地联结在一起。工作流通过bpm studio gui创建，studio的界面有些像"visio"，可以通过拖放的方式创建工作流。从工作流中可以直接呼叫应用视图服务（application view services），应用视图事件可以通过应用集成插件来触发工作流事件节点。同样，从工作流事件中可以通过一个可以从bea的开发人员站点 （http://dev2dev.bea.com） 下载的插件调用web services，dev2dev的web service插件提供一个gui，允许开发人员把应用视图服务发布为web service（workshop ai 控制的一个有限子集）。

    在我们例子中的portal通过在流水线组件中调用bpm api与问题票务分派工作流打交道。一个工作流任务从两套问题票务系统中获取问题票务信息，该工作流在较新的系统中激活适当的web service，在另一个系统中激活应用视图服务（application view services）。该工作流可以直接在bpm studio gui中创建，不需要任何手工编程。

    统一用户资料（unified user profile）：分类化和个性化集成

    门户中的包含用户资料的属性位于一个预先定制好的关系数据库中。门户的个性化和分类化组件（这些组件用来判断你是谁，是什么，有什么兴趣等等）使用用户的资料属性。你可以通过门户的统一用户资料（uup）框架来把用户资料扩展为企业级的资料。该框架允许一个开发人员从另一个可选资源（例如，ldap，crm/erp系统）中把用户属性插入进来。简而言之，开发人员只要执行一个entitypropertymanager ejb，就可以使用它来获得扩展的用户属性。这个ejb以profilemanager ejb为基准（你在这个ejb的部署描述环境中加入你的entitypropertymanager信息）。

    现在你开始使用entitypropertymanager ejb，那你实际上要使用什么技术来获得用户的属性？

    。 如果外部系统的web service是处于激活状态，或者同样的你使用workshop、liquid data或者web service bmp插件的gui界面发布的web service的话，你可以使用jax-rpc从web service中获得信息。。 你可以使用liquid data query api来把外部系统发布为liquid data view.。 如果外部系统有相应的由应用视图（application view）公布的j2ee ca 适配器的话，你可以使用应用集成api.。 你可以直接和j2ee ca 适配器交互。。 你可以使用私有的方法。

    示例中的门户根据unified user profile中的专业和资历来进行问题单的分配。某个专业的工程师被指派为管理者的同时也成为一个管理权力集团（management entitlement segment）的成员，可以访问engineer case history portlets，这些portlet允许管理人员根据某个工程师过去的案例处理情况来分析他或她的工作表现。就像刚才讲的，本例中的entitypropertymanager ejb可以使用jax-rpc来获得我们的用户信息，发布为liquid data web services view.

    web services portlets：web层的集成

    web services portlets，如同它的名字所暗示，使用web services，然后以内容的形式把结果显示出来。这些portlet可以用portal ebcc portlet wizard快速开发，从非常基本的portlet类型到和使用用户定义的数据类型进行动态的、异步交互的portlet类型。web services portlets也可以参与到workshop类型的交互中。

    当今大多数精心设计的web应用都采用model 2 web层结构模式。被广泛使用的apache jakarta的"struts"就是这种模式的很好应用。门户的webflow/pipeline框架的工作模式与此类似。model 2模式的基本原则是：分离业务（controller， model， and view）和"view"（我们的例子中是portlet）的分离，view的主要业务是显示现在相关的model的内容。从一个portlet中激活和使用一个或多个web service似乎会和以上原则冲突，实际上有时会有冲突发生。不过，某些情况下，不会有冲突发生：

    。 使用的portlet单独存在（一个单独的"小型应用"）。。 web service提供model的当前状态（j2ee设计模式中front controller的view helper策略）。。 web service激活的结果的格式是portlet用户界面的形式。

    在我们的原型示例系统中，一个支持工程师专门接收他们使用的关系数据库的厂商发布的技术公告。该公告在门户中的一个portlet中显示。这是一个单独的服务，和门户中的其他portlet无关，而且信息是调用外部的web service获得的。在这种情况下使用web services portlet的另一个主要原因是从这个web services获取信息就是用户接口。

    总结

    本文介绍了weblogic enterprise platform的一些在构建企业门户解决方案的时候可以使用的功能。本文的目的不是提供一个单一的，完整的结构（类似"宠物商店"的门户集成简单示例），也不是暗示在所有情况下（或者大多数情况下）必须使用某些工具和技术。在一个给定的环境中有太多的因素需要考虑。使用web service进行比较明智的门户集成时，可以创建一个非常灵活的架构。但是如果不进行全盘考虑，一些重要的问题（例如性能、可扩展性、安全和事务协同性）就可能发生。这一点上，web service和其他的技术一样。一个有经验的架构师明白这一点，所以既不会对web service过分狂热，也不会因为web service的缺点而怀疑web service.