北京市应急指挥系统BEA技术建议V1.0BEA系统（中国）有限公司2006-01---本文来源于网络，仅供参考，勿照抄，如有侵权请联系删除---目录1项目总体要求32信息平台技术要求4用户需求的服务媒介：4互联网4呼叫中心43北京市应急指挥系统BEA技术方案53.1北京市应急指挥系统SOA架构总体设计53.2应用支撑平台与集成环境63.3信息资源共享环境73.3.1数据服务平台73.4工作流平台153.5门户系统方案173.5.1内容管理173.5.2搜索功能183.5.3多渠道访问193.5.4门户安全管理203.5.5统一用户档案223.5.6单点登录233.6系统部署和管理243.6.1高性能243.6.2集群和可靠性253.6.3系统监控，保证SLA263.7BEA实现的SOA架构优势273.7.1全面、统一的平台273.7.2基于标准的开放平台273.7.3简单、高效率实施294成功案例30---本文来源于网络，仅供参考，勿照抄，如有侵权请联系删除---1项目总体要求项目要求见项目需求书，此处略。---本文来源于网络，仅供参考，勿照抄，如有侵权请联系删除---2信息平台技术要求用户需求的服务媒介：互联网用户需要通过互联网满足对信息的浏览、查询、决策、指挥、邮件服务、即时通讯等的需求。无线网络用户需要通过无线服务，满足随时随地浏览信息、查询信息、视频会议等的需求。呼叫中心用户需要通过人工和语音的呼叫服务满足信息服务，情况报告等语音服务需求。---本文来源于网络，仅供参考，勿照抄，如有侵权请联系删除---3北京市应急指挥系统BEA技术方案3.1北京市应急指挥系统SOA架构总体设计根据项目的需求，该项目的应用可以分为几个层面：1.底层的数据层——通过数据库系统存储共享的业务数据，共享数据从各自业务数据库中提取，数据源之间进行复制和交换；2.应用支撑层——通过应用服务器支持程序组件的建立和运行；3.数据服务层——针对不同的应用，应用对数据的访问需要一个数据服务层，通过数据服务层，应用能够做到透明访问异构的和分布的数据库和文件系统，应用逻辑和数据源之间是松耦合的，通过中间的数据服务层提供跨数据库的关联和映射；4.服务总线层——通过服务总线，连接各类可重用服务模块，完成消息传递，数据转换，服务路由等功能；5.工作流层——穿接应用模块，按照工作流程构建业务流程，支撑部门内部和跨部门的流程建模，执行和管理，并结合门户系统构建流程门户，构建SOA构架应用，工作流平台是必须的；6.门户展现层——可以针对不同类型的用户提供灵活的访问形式，根据不同用户类型提供个性化服务。北京市应急指挥系统，其逻辑结构可以按照上述六层来构建。其好处在于，从纵向结构上看，应用具有松耦合架构。具体的介绍如下：1.在数据层——数据库或文件系统可以进行数据交换；2.应用支撑层——通过开发基于J2EE的应用程序组件实现应用模块功能，组件可以封装为服务，组件的构建，运行和管理由本层支撑，应用支持层通过WebLogicServer实现；---本文来源于网络，仅供参考，勿照抄，如有侵权请联系删除---3.在数据服务层——数据的访问基于统一的入口，被访问数据则可以分布在外部相关单位的共享数据库和北京市应急指挥系统的数据库中，通过数据服务层进行跨数据库的关联，数据服务层的访问可以通过Java接口或Web服务实现，数据访问层通过AquaLogicDataServicePlatform产品实现；4.服务总线层——业务应用通过组件方式构建，组件可以方便的封装成Web服务，在系统之间被相互调用，服务总线层通过AquaLogicServiceBus实现；5.在工作流层——工作流层支撑流程建模，执行和管理，灵活的流程管理工具使生成和改变工作流程变得简单；6.在门户展现层——通过门户技术，北京市应急指挥系统门户中建立的各类应用展现portlet，信息内容的展现个性化。北京市应急指挥系统基于SOA的统一技术架构---本文来源于网络，仅供参考，勿照抄，如有侵权请联系删除---要实现上述的系统层次和功能，需要SOA的构架设计和相应的BEA产品支持，做到开放、灵活和敏捷。下面分层介绍BEA的方案和产品技术特点。3.2应用支撑平台应用支撑平台是通过BEAWebLogicServer应用服务器实现。具体的技术指...