在实际工作中构建大型的应用很难通常你会把门户（portal）和企业集成（EAI）搞混这样你的工作更难完成你必须做出一系列的困难决定很多决定也许会对项目的其余部分产生或好或坏的影响
在你做出架构性的重要选择之前都应该深入考虑你构建的应用的每一层（ 从前端的负载平衡系统到后端的企业级的系统也许是全球性的）即使只是处理这些问题的一个子集（也许只是代表那些与门户集成相关的一些问题）你也将面临很多棘手问题
为了得到最好的效果我是不是应该把我的web层和一些流程组件连接起来让这些组件充当工作流和应用集成层的业务代理让集成层处理EAI的复杂问题？是不是每次都可以按这样的套路进行呢？
我的web层和工作流层是不是应该采用松耦合（例如使用JMS）或者在某种情况下为了利用BMP（Business Process Management）的API提供的工作列表（worklist）功能的好处是否可以不用松耦合？
在创建统一用户资料（Unified User Profile）时我如何精确的和CRMERP和安全系统打交道？
门户内容管理参考实现是否提供了足够多的功能？我是不是需要评估一下第三方的解决方案？
我们是否应该利用新的证书映射提供者（credential mapping provider）通过JEE CA Adapters传递认证信息？还是用Web services的SAML （Security Assertion Markup Language）？我们的第三方单点登陆（Single SignOn （SSO））安全系统是否支持这些机制？我有没有SSO？我是否需要一个呢？
幸运的是这只是一篇杂志中的文章所以我们可以先把一些问题放在一边以利于我们集中精力减少篇幅本文描述了WebLogic Enterprise Platform里可以用来在门户中用Web services进行集成的一些工具和技术在一个简要的原型系统例子中我们对这些技术进行了演示这里我定义的门户集成是指把从不同的资源（通常是外部的）中获得的信息通过检索转换组织显示形成统一的个性化的整体本文主要是讨论Web service所以只是简要介绍这些门户集成功能中对第三方的内容和文档的管理的功能该功能在企业架构中应当被考虑我将简要介绍以下内容
JEE CA 应用视图（JEE CA Application Views）
Workshop Application集成控制（Workshop Application Integration Controls ）
Liquid 数据视图和源 （Liquid Data Views and Sources）
应用集成和Web services 工作流插件（Application integration and Web services workflow plugins）
统一用户资料框架（The Unified User Profile Framework ）
Web services Portlet向导 （The Web Services Portlet Wizard ）
以上内容为使用Web services进行松耦合的企业门户集成提供了非常强大的框架请注意本文假设读者对WebLogic Portal 和Integration 非常熟悉在和BEA WebLogic Developers Journal杂志中都有关于WebLogic Portal 和Integration 的丰富的资料
门户集成（Portal Integration）一个原型示例
我们的例子是一个IT技术支持部门的案例管理门户问题单根据技术支持工程师的专业（例如数据库用户界面事务管理）和技术等级（一级二级等）分发每个工程师有一个相关的资料资料同时存在于一个安全的关系数据库和一个外部的CRM系统中资料中有该工程师的专业和技术等级信息也可能有工程师的管理者——高级工程师的信息高级工程师可以分析下属的案例历史包括完成案例的平均时间和案例数量增长的百分比每个案例的实际数据存在两个外部问题单系统中一个系统相对较新使用了Web services另一个系统较旧有一个专有界面除了核心的案例管理功能每个工程师的门户都可以个性化使用另外的含有公开技术论坛的Portlet含有内部错误报告更新的Portlet以及类似的Portlet
应用视图（Application Views）实际上所有的内容都可以展示
JEE Connector Architecture （JEE CA） 适配器是连接JEE组件和外部企业信息系统（EIS）的桥梁EIS所需的适配器接口经常使用专有的协议数据格式和认证机制WebLogic JEE CA适配器处理协议转换也常用于处理数据格式的转换或者利用WebLogic里的证书映射提供者传递认证信息到EIS中如果EIS含有XA那么XA事务也可以传递
JEE CA 规范没有规定适配器的标准的接口（只提供了一个可选的接口）也没有规定一个标准的信息格式或者EIS发出的异步事件规范（现在是建议最终草稿版的第二版）修补很多类似的漏洞版规范会包括在JEE 中
WebLogic 集成应用视图框架（WebLogic Integration Application View Framework）在JEE CA 适配器之上提供了一层弥补了规范中的不足（规范中的改进在此由应用视图提供）当你创建一个应用视图的时候你也指定了一个和相关业务服务以及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 serviceWebLogic Workshop的开发人员可以利用一些特殊的控制（controls）轻松的把后端的JEE组件发布为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 servicesLiquid Data的理论基础建立在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 servicesBMP（业务流程管理）集成
工作流控制着企业业务处理的流程它通过集成插件接入点和实际的业务逻辑紧密地联结在一起工作流通过BPM Studio GUI创建Studio的界面有些像Visio可以通过拖放的方式创建工作流从工作流中可以直接呼叫应用视图服务（Application view services）应用视图事件可以通过应用集成插件来触发工作流事件节点同样从工作流事件中可以通过一个可以从BEA的开发人员站点 （） 下载的插件调用Web servicesdevdev的Web service插件提供一个GUI允许开发人员把应用视图服务发布为Web service（Workshop AI 控制的一个有限子集）
在我们例子中的portal通过在流水线组件中调用BPM API与问题票务分派工作流打交道一个工作流任务从两套问题票务系统中获取问题票务信息该工作流在较新的系统中激活适当的Web service在另一个系统中激活应用视图服务（application view services）该工作流可以直接在BPM Studio GUI中创建不需要任何手工编程
统一用户资料（Unified User Profile）分类化和个性化集成
门户中的包含用户资料的属性位于一个预先定制好的关系数据库中门户的个性化和分类化组件（这些组件用来判断你是谁是什么有什么兴趣等等）使用用户的资料属性你可以通过门户的统一用户资料（UUP）框架来把用户资料扩展为企业级的资料该框架允许一个开发人员从另一个可选资源（例如LDAPCRM/ERP系统）中把用户属性插入进来简而言之开发人员只要执行一个EntityPropertyManager EJB就可以使用它来获得扩展的用户属性这个EJB以ProfileManager EJB为基准（你在这个EJB的部署描述环境中加入你的EntityPropertyManager信息）
现在你开始使用EntityPropertyManager EJB那你实际上要使用什么技术来获得用户的属性？
如果外部系统的Web service是处于激活状态或者同样的你使用WorkshopLiquid Data或者Web service BMP插件的GUI界面发布的Web service的话你可以使用JAXRPC从Web service中获得信息 你可以使用Liquid Data Query API来把外部系统发布为Liquid Data View 如果外部系统有相应的由应用视图（Application View）公布的JEE CA 适配器的话你可以使用应用集成API 你可以直接和JEE CA 适配器交互 你可以使用私有的方法
示例中的门户根据Unified User Profile中的专业和资历来进行问题单的分配某个专业的工程师被指派为管理者的同时也成为一个管理权力集团（Management Entitlement Segment）的成员可以访问Engineer Case History Portlets这些portlet允许管理人员根据某个工程师过去的案例处理情况来分析他或她的工作表现就像刚才讲的本例中的EntityPropertyManager EJB可以使用JAXRPC来获得我们的用户信息发布为Liquid Data Web Services View
Web Services Portletsweb层的集成
Web Services Portlets如同它的名字所暗示使用Web Services然后以内容的形式把结果显示出来这些portlet可以用Portal EBCC Portlet Wizard快速开发从非常基本的portlet类型到和使用用户定义的数据类型进行动态的异步交互的portlet类型Web Services Portlets也可以参与到Workshop类型的交互中
当今大多数精心设计的Web应用都采用Model Web层结构模式被广泛使用的Apache Jakarta的Struts就是这种模式的很好应用门户的Webflow/Pipeline框架的工作模式与此类似Model 模式的基本原则是分离业务（controller model and view）和view（我们的例子中是portlet）的分离view的主要业务是显示现在相关的model的内容从一个portlet中激活和使用一个或多个Web Service似乎会和以上原则沖突实际上有时会有沖突发生不过某些情况下不会有沖突发生
使用的portlet单独存在（一个单独的小型应用） Web Service提供model的当前状态（JEE设计模式中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
