收藏 分销(赏)

新一代XXXX省短期气候预测业务支撑平台技术方案书V10.docx

上传人:xrp****65 文档编号:8945008 上传时间:2025-03-08 格式:DOCX 页数:67 大小:642.23KB
下载 相关 举报
新一代XXXX省短期气候预测业务支撑平台技术方案书V10.docx_第1页
第1页 / 共67页
新一代XXXX省短期气候预测业务支撑平台技术方案书V10.docx_第2页
第2页 / 共67页
点击查看更多>>
资源描述
1. 项目综述 1.1. 项目背景 短期气候预测是气象业务的重要组成部分,是当今人类社会面临的一项重大课题,也是当前气象科学研究和发展的重点。全国气候变暖已是一个不争的事实,气候问题日益受到关注,气候变化与社会、经济发展关系密切,近年来各种气候极端事件如干旱、暴雨洪水、低温冷害、沙尘暴、雪灾等频繁发生,呈现加剧趋势,随着我国经济社会的快速发展,社会进步,人民生活水平的提高,政府和公众防灾减灾对短期气候预测产品的需求在急速增长,短期气候预测的需求越来越迫切。短期气候预测在国民经济建设和防灾减灾中的作用越来越重要。 我国经过几十年对气候预测业务的不懈努力,也取得了很大的进步,现在主要制作并发布月、季、年时间尺度的气候趋势预测业务,主要的预测产品包括《月、季气候预测》、《汛期气候预测》和《年度气候预测》。从常规的温度、降水预测出发,发展了冷空气、霜冻、台风、春播天气等专项气候预测。产品内容包括:全市月平均温度趋势预报,月降水量预报、月降水距平百分率预报,夏季高温,伏旱,台风等等。产品形式以文字叙述为主,辅以预报要素(温度、降水等)的图表。产品主要为政府有关部门提供决策服务,同时也为相关行业提供技术指导和参考。 众所周知,由于受到对长期天气过程认识水平的制约,50年来,虽然在短期气候预测方面做了大量工作,短期气候预测实际业务工作主要依靠经验和相关统计的方法。目前,对各种资料的收集、整理以及各种相关统计工作虽然在工作中使用计算机处理,但尚处于初期半自动化的状态,预报员在长期预报实践中积累的工作经验和方法未实现自动化,建立比较完善的、网络化的、适用的短期气候预测业务系统是摆在我们面前的迫切任务。短期气候预测业务是根据大气科学的原理,运用现代气候动力学、统计学等方法和电子计算机、数据库、通信技术等手段,在研究气候变异成因的基础上,对月、季、年际时间尺度的气候趋势和气候灾害进行科学预测。随着现代科学技术与管理技术的提高、生产信息的多元化和复杂化,使得信息的处理和管理工作也越来越重要。人类进入21世纪后,信息化水平高低成为衡量一个地区的现代化水平,一个国家的综合国力的重要指标。因此,建立一个短期气候预测业务平台,非常有意义。 2. 项目建设目标与任务 2.1. 建设目标 在目前已经建立的基于统计、动力、以及动力-统计相结合的多方法月、季气候客观化预测模型以及气候趋势业务系统基础上,融合最新的业务能力建设成果,开发新一代XXXX省短期气候预测业务支撑平台,包括数据收集处理、诊断分析、历史个例查询、各种预测方法运行、预测效果评估检验、预测产品加工分发等功能。该平台的建设有利于推动短期气候预测业务向客观化、定量化、精细化方向发展,将短期气候预测方法与工作流程相结合,贴近业务实际需要,为短期气候预测工作提供一个综合业务平台和科研环境,为现代化短期气候预测业务提供有效的技术支撑。 2.2. 建设任务 2.2.1. 总体任务 新一代XXXX省短期气候预测业务支撑平台主要实现气候预测相关数据收集处理、诊断分析、历史个例查询、各种预测方法运行、预测效果评估检验、预测产品加工分发等功能,建立的一个集资料处理、预报、产品发布、评分检验于一体的、自动化程度较高、操作直观简便、可扩展性较好、界面简洁友好的集约化气候预测业务系统。要求其运行稳定可靠、操作简单、界面清晰、产品规范,具有模型扩展功能,留有专题数据与程序模块接口,具有较好的可升级功能。 2.2.2. 数据收集处理 2.2.2.1. 数据内容 (1)(华南区域)XXXX省常规气象要素数据集。包括平均气温、最高气温、最低气温、降水量、风速、气压、相对湿度、日照等多要素的各站(XXXX省86站、华南192站,下同)逐日、候、旬、季、年多时间尺度的数据集。 (2)(华南区域)XXXX省常规气象要素统计数据集。包括各站逐月高温日数(多个特定阈值,下同)、低温日数、暴雨日数、降水日数;春播期低温阴雨日数、寒露风期间低温阴雨日数、冬季低温(冷空气,含寒潮)等。 (3)(华南区域)XXXX省特定时段气象要素统计数据集。包括龙舟水、春播期、双夏、寒露风等时段的平均气温、最高气温、最低气温、降水量、风速、气压、相对湿度、日照等多要素的各站的统计数据集。 (4)热带气旋数据集。包括1951年以来逐月西太平洋生成、中国登陆、华南登陆、XXXX登陆等热带气旋个数、最大强度(中心最低气压)等,以及逐年初旋和终旋。 (5)大气环流、海洋、冰雪等特征指标数据集。 (6)多种大气环流再分析数据集、海温数据集。 (7)其他气候预测数据。 2.2.2.2. 建设要求 (1)整理并建设历史数据集。 (2)实现数据集的采集续补。 (3)实现相关数据的查询显示,包括表格以及图形格式等。 2.2.3. 监测和诊断分析 2.2.3.1. 主要内容 (1)月季气候异常监测以及诊断分析。 (2)关键时段和气候过程的监测诊断,包括前汛期集中期、春播期低温阴雨、寒露风期间低温阴雨、龙舟水程度监测以及诊断分析,华南前/后汛期过程中的监测和诊断分析,冬季低温寒冷过程的监测和诊断分析。 (3)热带气旋情况监测和诊断。 (4)与本区域有关的关键区大气、海洋、冰雪等指标的监测以及诊断分析。 2.2.3.2. 建设要求 (1)依照相关监测指标,实现上述内容监测。 (2)运用相似分析和合成、相关、回归分析、EOF、滑动平均等统计手段,实现诊断分析功能。 (3)实现相关数据的查询显示,包括表格以及图形格式等。 2.2.4. 定量预测 2.2.4.1. 主要内容 (1)延伸期、月、季、年多时间尺度的平均气温、降水量。 (2)关键时段平均气温、最高气温、最低气温、降水量。 (3)关键时段高温日数、低温日数。 (4)热带气旋相关要素,包括各月个数、初/终旋以及强度。 2.2.4.2. 建设要求 实现多种预测方法的自动运行,以及计算结果的查询显示,包括表格以及图形格式等。 2.2.5. 预测检验 2.2.5.1. 主要内容 (1)月、季降水和平均气温。 (2)延伸期内降水过程、冷空气过程。 (3)热带气旋相关要素检验。 2.2.5.2. 建设要求 (1)采用统一的评分标准体系,针对不同预测方法结论以及主观预测结论,对月、季降水和平均气温进行回报检验和实时检验。 (2)发展延伸期内降水过程、冷空气过程等预测检验方法,对开展不同预测方法结论以及主观预测结论在不同时段对不同预报对象的预测能力进行回报检验和实时检验。 (3)发展热带气旋相关要素预测检验方法,对开展不同预测方法结论以及主观预测结论回报检验和实时检验。 (4)包括历史评估情况查询和实时检验等功能开展不同预测方法在不同时段对不同预报对象的预测能力进行回报检验和实时检验。 (5)检验结果的查询显示,包括表格以及图形格式等。 2.2.6. 网络预测、监测产品获取和显示 2.2.6.1. 主要内容 (1)国内外多种数值预报产品。 (2)国内外多种数值预报产品。 2.2.6.2. 建设要求 (1)网络预测、监测产品地址清单和执行情况管理。 (2)网络预测、监测产品自动获取。 (3)网络预测、监测产品查询显示。 2.2.7. 预测产品制作和分布 2.2.7.1. 主要内容 (1)多种格式的月、季气候预测产品生成,包括预测图形、表格和格式型文字产品,格式包括WORD文档和HTML超文本等。 (2)降水/冷空气过程预测图形。 (3)上报国家局数据文件。 2.2.7.2. 建设要求 (1)实现多种预测产品的制作。 (2)按照各种业务要求,完成预测产品的发送。 3. 项目建设原则和技术选型 3.1. 项目建设原则 为了确保新一代XXXX省短期气候预测业务支撑平台的高效运行,在项目的建设过程中必须坚持统一标准、注重效率、实用先进、安全可靠的总体原则,遵循国家的软件开发技术标准和规范,结合气象行业的工作实际和需求,软件设计与开发必须遵循以下原则: 3.1.1. 实用性原则 系统设计必须严格的根据平台所要求达到的功能和业务实现上的一些特点,采用切实可行的技术和设备,满足各种业务系统的要求,保证系统适用、实用、方便、具有良好的性能价格比的前提下进行建设,使系统的配置具有易操作性、易管理维护性,达到整体优化和可持续发展的目标。 3.1.2. 整体性原则 系统必须在先进的软、硬件平台上采用符合用户特点的高效应用软件,并提供良好的接口,使现有的各种系统能有机地集成,实现多种业务的集成,发挥整体效益。 3.1.3. 安全性原则 系统运行的安全性包括硬件平台的安全和内网管理的安全。系统建设首先遵循安全可靠的原则,最大可能减少因信息基础设施故障而造成的业务无法正常进行的现象的发生;同时,系统建设中注重安全体系的建设,提高数据的整体安全性,进一步保证数据安全。 3.1.4. 先进性原则 系统要有先进的设计思想、网络架构和开发工具,尽量采用先进而成熟的技术和设备,在保证系统高效、可靠安全运行的同时,使软件的生命周期具有持续发展潜力,以适应信息技术日新月异、业务发展和平台扩展功能的需要。 3.1.5. 可管理性原则 应用软件应选用基于TCP/IP的标准管理协议,能够进行远程监控和管理,支持B/S体系结构。同时还要保证系统和应用软件全中文界面,而且功能完善,界面友好,兼容性强,能使用户最方便地实现各种功能。 3.1.6. 可扩展性原则 系统结构采用模块化设计,“软总线”可插拔部署方式,支持分布式运行,系统在容量和功能上不仅能满足目前系统平台的需求,还可以提供良好的二次开发扩展。随着项目的实施,数据不断增多、业务应用系统的范围不断扩大,系统将承担更大的数据管理和数据支撑任务。为此,整个系统必须提供足够的扩展能力以满足未来业务增长的需要。 3.1.7. 实时性原则 为确保平台能及时地为各类用户提供有效服务,平台在操作系统、数据库的选型以及各功能模块的设计方面,应充分考虑到平台整体性能的优化,以确保能为用户提供实时服务。 3.1.8. 开放性原则 平台应采用开放性的技术建设,应支持目前流行的通讯协议,硬件接口必须符合行业标准、国家标准和国际标准,并应当是网络技术发展的主流,使系统能够跨平台运行在各种操作系统平台上。 3.1.9. 稳定性原则 平台能够连续7 x 24小时不间断工作,出现故障能及时告警,具有完整的操作权限管理功能和完善的系统安全机制。应用系统具备自动或手动恢复措施,以便在发生错误时能够快速地恢复正常运行。 3.1.10. 可靠性原则 系统硬件平台稳定、可靠,能够满足“数据集中”系统业务的要求。系统的可靠性同时也包括系统所具有的具体功能、系统所能支持的大数据容量和在复杂的运行环境里稳定、可靠的运行,在出现异常情况下系统具有相应的应急措施等。 3.1.11. 共享性与保密性原则 信息共享具有严格的保密级别和用户权限。通过提供的软、硬件安全设施,实现对用户名/口令、权限控制、数据加密及备份,以满足系统数据的完整性和保密性的要求,保护信息系统的数据免遭泄露。软件系统必须具有能实现跨区域、多业务、多资源的共享,并能保证系统的安全。 3.1.12. 易用性原则 系统采用B/S(浏览器Browse/服务器Server)体系结构,操作界面简洁、直观,有利于简化操作,并提高操作效率。支持方便多样的输入方式(手写、键盘、语音、扫描等);预设常用词库,支持办理意见鼠标选择,避免手工输入。 3.2. 项目技术选型 考虑到今后业务扩展的需要,新一代XXXX省短期气候预测业务支撑平台建设拟选用面向服务的体系结构(SOA架构)构造应用系统,提供标准化接口服务,为今后扩展系统功能奠定基础,确保系统建设的整体性,各应用系统的建设坚持实用、安全的建设原则,保证系统功能完善、使用与管理方便、切合实际、运作高效。 3.2.1. 面向服务的体系结构(SOA架构) 面向服务的体系结构(SOA架构)是一个组件模型,它将应用程序的不同功能单元,通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 3.2.1.1. 为什么需要SOA SOA 提供了一种构建 IT 组织的标准和方法,通过建立可组合、可重用的服务体系来减少 IT 业务冗余,并加快项目开发的进程。SOA 允许一个企业高效地平衡现有的资源和财产,这种体系能够使得 IT 部门效率更高、开发周期更短、项目分发更快,在帮助IT技术和业务整合方面有着深远的意义,它可以: l 缩小业务和技术的鸿沟——以业务为中心 SOA 改变了以往以技术为中心的信息系统建设模式,使得 IT 技术重新回到业务支撑的角色。IT 技术的目标是为业务、应用服务,而不是 IT 技术本身的发展。业务人员可以像组装硬件一样从业务角度即时构造应用,从而缩小业务和技术的鸿沟。 l 软件资源的共享与重用 SOA提供了一种把原有的组件按一定的标准封装为具有文档形式接口描述的服务,而使服务的使用者和服务之间是一种松耦合关系。这样,一方面可以把遗留系统封装服务加以复用,提高了投资回报率;另一方面,可以直接调用外部服务提供商提供的服务从而起到复用的作用。 l 应用的随需扩展——灵活性和敏捷性 SOA的松耦合特性给应用带来了极大的灵活性。服务使用者和服务提供者在保持接契约一致性的情况下,可以独立演化。基于 SOA 的应用可以看成是一组服务以及服务之间松散耦合的集合。因此,一方面新的服务可以很容易地加入这个松散集合,另一面也可以根据业务需求重新编排集合内的服务,以生成新的复合服务。因此基于SOA应用具有易于改变、易于扩展的特点,从而支持了业务的快速反应和敏捷性。总之,面向服务架构(SOA)试图将网络上需要共享的各种资源统一以服务的形式进行封装和接入,让它们在物理上保持分布自治的同时实现以“虚拟信息中心”为基础逻辑上的一体化管理,以透明的方式进行资源的优化选取、按需中介和有效访问,并能够支持用户主动参与应用配置。 SOA 主要通过复用性、灵活性和共享性从技术上支持上述目标。SOA 以服务为基本单元,更加贴近于企业的商业活动,业务建模和流程编排的复杂度会有效降低,重用性也会有效提高。因此,采用SOA可以让IT更加关注于业务流程而非底层IT基础结构,从而获得竞争优势的更高级别的应用程序开发架构。 3.2.1.2. SOA 的特点 ü 重点关注服务 SOA支持面向服务的开发方法,是对前续的面向过程、面向消息、面向数据库和面向对象开发方法的补充。 服务从更高抽象层次上定义,直接与业务相对应,且其实现可采用面向过程、面向消息、面向数据库和面向对象等不同开发方法。 与面向对象的调用接口相比,服务一般定义成较粗粒度的接口,会接收更多的数据,消耗更多的计算资源。服务一般是用来解决应用间互操作问题,以及将服务组合成新应用或新的应用系统,而不是为应用创建具体的业务逻辑。 通过 SOA,围绕服务构建IT系统,有利于IT系统更靠近实际业务要求,使 IT 系统更容易适应业务变化的要求,另外,对已有应用系统,通过服务化封装,可以使这些系统得到更好的重用,能有效保护对已有应用系统建设的投资。 ü 松耦合 松耦合是软件设计中一个重要概念,SOA 强调服务间的松耦合。在SOA中松耦合包括以下三个方面: l 接口松耦合 接口耦合是指服务请求者与服务提供者之间的耦合。度量的是请求者与服务提供者的依赖性。接口松耦合强调服务请求者仅需要根据已发布的服务契约和服务水平协议(或称服务等级协议)就可以请求一个服务,任何时候服务请求者都不需要了解服务提供者对内部实现的信息。即服务接口封装了所有的实现细节,使服务请求者看不到这些实现细节。 l 技术松耦合 技术耦合度量的是服务对特定技术,产品或开发环境的依赖程度。技术松耦合强调服务请求者和服务提供者的实现和运行不需要依赖与特定的某种技术,或某个厂家的解决方案或产品,从而减少对某个厂商的依赖。在 SOA 系统中服务请求者和服务提供者可以使用不同技术实现,可以在不同厂商的环境中运行。 l 流程松耦合 流程松耦合度量的是服务与特定业务流程的依赖程度。强调服务不应与具体的业务流程相关,以便能够被重用于多种不同的业务流程与应用。这一点强调的是服务的可重用性,在SOA系统中对业务服务的合理规划,使得一个业务服务可以在多个业务流程中得到复用,并且随着业务要求的改变,一个服务可以在变化后的新的业务流程中能够得到继续使用。 ü 重构的灵活性 在SOA系统建设中,基本的单位是实现业务功能的服务,而不是实现业务逻辑的对象、过程、函数等较小的技术单位。 服务与实际业务功能相关,具有明确的接口。这些服务可在不同的业务流程中得到重用,提高了服务的价值;其次在使用中只需按其接口要求进行访问,屏蔽服务实现细节,服务实现的修改不会影响到服务访问方的逻辑,提高了业务流程的适应性;另外,一旦业务流程变更,仅需对服务进行重新编排,并不修改服务本身,提高了业务流程实现的灵活性。 重构的灵活性,不仅可以使业务服务可以有更好的重用性,也使得业务流程更容易重构,使IT系统具有了更好的灵活性,可以快速面对变化的市场需求。 ü 对标准的支持 为了强调互操作性,在SOA系统中,服务需要尽量符合开放标准。与服务相关的技术几乎都存在相应标准,通过对标准的使用可以得到众多好处,包括: l 减少对特定厂商的依赖; l 为服务请求者增加了使用不同服务提供者的机会; l 为服务提供者增加了被更多服务请求者使用的机会; l 增加了使用开放源代码的标准实现,以及参与这些实现的开发机会; 在SOA系统中,除强调需要遵守技术标准(如 SOAP,WSDL,UDDI 和 WS-*)外,服务层的数据模型和流程模型也有需尽可能基于一些成熟的业务领域标准或纵向的行业标准。 3.2.1.3. SOA的优势 用SOA方法构建应用系统,可获得技术、业务层面的不同优势。 1) 技术层面好处: l 开发过程更有效,缩短开发周期; l 更利于重用; l 简化维护; l 增量采纳,在统一的规划下,系统可以通过试点后分步骤建立; l 编码灵活性; l 流畅的演进,可以逐步改进业务目标; 2) 业务层面好处: l 增强业务机动性,有更好敏捷性; l 更好的配合业务,可以优化业务框架; l 改善客户满意度; l 提高现有IT资产的投资回报率; l 降低集成成本,节省费用; l 降低对厂商的依赖和降低转换成本,获得技术的独立性; 3.2.1.4. SOA 技术架构 采用SOA技术架构设计具有统一接口定义方式的组件服务,提高系统的适应性、扩展性和灵活性。SOA技术架构分为协同层、流程层、服务层、逻辑层、资源层等五层,以及相关的基础设施。SOA企业架构的基础设施包括企业应用集成机制和管理功能,如服务质量、安全、SOA服务管理、组合管理、监视等。 SOA技术架构图如下图所示: l 资源层 资源层包含现有的自定义构建的应用程序(遗留系统),现有的CRM和ERP打包应用程序,以及原有的面向对象的系统实现、业务智能应用程序。SOA利用现有系统并且用基于服务的集成技术来集成它们。资源层解决如何整合数据的问题,需要通过一个统一的数据编程模式统一对不同数据源的访问。 l 逻辑层 逻辑层实现了具体的业务逻辑,包括UI逻辑和后台逻辑。逻辑层由多个构件组成,这些构件将以可插拔的方式部署,使用AOP、依赖注入的方式编程,提供逻辑的编排能力。 l 服务层 服务层将应用系统提供的逻辑以标准化的方式暴露出来,使开发者不需要关心逻辑的对外协议、逻辑的实现方式、逻辑的部署位置,并提供事件的方式降低逻辑间的耦合度,为非侵入式的操作提供基础。 l 流程层 流程层维护跨系统之间的业务状态,企业应用的核心是业务流程,流程包括端到端流程和人工参与的流程,流程会产生任务,推送到工作平台。流程把企业中多个应用连接起来。 l 协同层 协同层为用户提供了一个统一的交互门户和工作平台,通过RIA(Rich Internet Application)的方式在应用程序人机接口或者表现层来利用 Web 服务,以服务的形式进行界面的组装和重用,提升用户体验,用户通过协同层更容易与其他人进行协作,例如即时通信、查看任务列表、查看发布信息,也能够把已有数据、服务或界面快速组合到新应用中。通过协同层,用户不再与多个孤立的系统进行交互,而是面对一个有机的整体。 3.2.2. 基于J2EE平台,分布式、高可靠性、先进的解决方案 J2EE提供了一套企业级Java应用框架(一种标准),是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。 J2EE平台是目前为企业级应用所提供的分布式、高可靠性、先进的解决方案。J2EE也是一个已经被实践证明的、成熟的、成功的企业级应用解决方案,并拥有大量的成功案例。J2EE架构一般在大中型应用中使用比较多,选择了J2EE也就意味着选择了一个开放、自由、大型的技术应用平台。 J2EE平台架构图如下图所示: J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java 2平台的标准版,J2EE不仅巩固了标准版中的许多优点,例如“编写一次、随处运行”的特性、方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中保护数据的安全模式等等,同时还提供了对 EJB(Enterprise JavaBeans)、Java Servlets API、JSP(Java Server Pages)以及XML技术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台,J2EE降低了开发多层应用的费用和复杂性,同时提供对现有应用程序集成强有力支持,完全支持Enterprise JavaBeans,有良好的向导支持打包和部署应用,添加目录支持,增强了安全机制,提高了性能。 由于企业必须适应新的商业需求,利用已有的企业信息系统方面的投资,而不是重新制定全盘方案就变得很重要。这样,一个以渐进的(而不是激进的,全盘否定的)方式建立在已有系统之上的服务器端平台机制是公司所需求的。J2EE架构可以充分利用用户原有的投资,如一些公司使用的BEA Tuxedo、IBM CICS、IBM Encina、Inprise VisiBroker 以及Netscape Application Server。这之所以成为可能是因为J2EE拥有广泛的业界支持和一些重要的企业计算领域供应商的参与。每一个供应商都对现有的客户提供了不用废弃已有投资,进入可移植的J2EE领域的升级途径。由于基于J2EE平台的产品几乎能够在任何操作系统和硬件配置上运行,现有的操作系统和硬件也能被保留使用。 基于J2EE架构开发的优势主要体现在以下几个方面: l 高效的开发 J2EE允许公司把一些通用的、很繁琐的服务端任务交给中间件供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上,相应地缩短了开发时间。 l 状态管理服务 让开发人员写更少的代码,不用关心如何管理状态,这样能够更快地完成程序开发。 l 持续性服务 让开发人员不用对数据访问逻辑进行编码就能编写应用程序,能生成更轻巧,与数据库无关的应用程序,这种应用程序更易于开发与维护。 l 分布式共享数据对象CACHE服务 让开发人员编制高性能的系统,极大提高整体部署的伸缩性。 l 支持异构环境 J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的组件,把他们部署到异构环境中,节省了由自己制订整个方案所需的费用。 l 可伸缩性 企业必须要选择一种服务器端平台,这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与大型机系统,这种系统单机可支持64至256个处理器。(这是NT服务器所望尘莫及的)J2EE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈,允许多台服务器集成部署。这种部署可达数千个处理器,实现可高度伸缩的系统,满足未来商业应用的需要。 l 稳定的可用性 一个服务器端平台必须能全天候运转以满足公司客户、合作伙伴的需要。因为INTERNET是全球化的、无处不在的,即使在夜间按计划停机也可能造成严重损失。若是意外停机,那会有灾难性后果。J2EE部署到可靠的操作环境中,他们支持长期的可用性。一些J2EE部署在WINDOWS环境中,客户也可选择健壮性能更好的操作系统如Sun Solaris、IBM OS/390。最健壮的操作系统可达到99.999%的可用性或每年只需5分钟停机时间。这是实时性很强商业系统理想的选择。 J2EE使用多层的分布式应用模型,应用逻辑按功能划分为组件,各个应用组件根据他们所在的层分布在不同的机器上。事实上,SUN设计J2EE的初衷正是为了解决两层模式(client/server)的弊端。在传统模式中,客户端担当了过多的角色而显得臃肿,在这种模式中,第一次部署的时候比较容易,但难于升级或改进,可伸展性也不理想,而且经常基于某种专有的协议――通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。现在J2EE 的多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层,以下是 J2EE 典型的多层结构,如下图所示:   运行在客户端机器上的客户层组件;   运行在J2EE服务器上的Web层组件;   运行在J2EE服务器上的业务逻辑层组件;   运行在EIS服务器上的企业信息系统(Enterprise information system)层软件; J2EE多层分布式应用程序模型,力求根据功能的不同把应用程序逻辑划分成各个组件,常用的方式是通过JSP/Servlet+JavaBeans来处理表示层和业务层逻辑的,但这种方式往往存在如下缺点:层与层之间逻辑不清楚;表示同应用逻辑混合,使得程序员既要开发应用逻辑部分,又要懂得用户界面(UI)设计;不利于应用的开发维护以及应用的扩充。而MVC结构是一种用于分离出数据维护和数据表现的方式,在J2EE中引入MVC框架,有助于把应用分成合理的组件,从而可方便开发、维护和扩充。 J2EE应用程序是由组件构成的。J2EE组件是具有独立功能的软件单元,它们通过相关的类和文件组装成J2EE应用程序,并与其他组件交互。 应用客户端程序和applets是客户层组件。   Java Servlet和JavaServer Pages(JSP)是web层组件。   Enterprise JavaBeans(EJB)是业务层组件。 因为业务逻辑被封装成可复用的组件,并且J2EE 服务器以容器的形式为所有的组件类型提供后台服务,即应用服务器的容器服务,容器设置定制了J2EE服务器所提供得内在支持,包括安全、事务管理,JNDI(Java Naming and Directory Interface)寻址、远程连接等服务,所以开发人员不用自己开发这种服务,只要集中精力解决手头的业务问题。 各层组件调用关系流程,如下图所示: 3.2.3. 采用中间件技术 中间件具有以下的一些特点:满足大量应用的需要;运行于多种硬件和OS平台;支持分布式计算,提供跨网络、硬件和OS平台的透明性的应用或服务的交互功能;支持标准的协议;支持标准的接口。程序员通过调用中间件提供的大量API,实现异构环境的通讯,从而屏蔽异构系统中复杂的操作系统和网络协议。针对不同的操作系统和硬件平台,它们可以有符合接口和协议规范的多种实现。由于标准接口对于可移植性和标准协议对于互操作性的重要性,中间件已成为许多标准化工作的主要部分。对于应用软件开发,中间件远比操作系统和网络服务更为重要,中间件提供的程序接口定义了一个相对稳定的高层应用环境,不管底层的计算机硬件和系统软件怎样更新换代,只要将中间件升级更新,并保持中间件对外的接口定义不变,应用软件几乎不需任何修改,从而保护了企业在应用软件开发和维护中的重大投资。 中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源。中间件软件管理着客户端程序和数据库或者早期应用软件之间的通讯。 中间件在分布式的客户和服务之间扮演着承上启下的角色,如事务管理、负载均衡以及基于Web的计算等。 利用这些技术有助于减轻开发者的负担,使他们利用现有的硬件设备、操作系统、网络、数据库管理系统以及对象模型创建分布式应用软件时更加得心应手。由于中间件能够保护企业的投资,保证应用软件的相对稳定,实现应用软件的功能扩展;同时中间件产品在很大程度上简化了一个由不同硬件构成的分布式处理环境的复杂性,所以它的出现正日益引起用户的关注。 3.2.3.1. 消息中间件(MTS) MTS 是一种基于互联网架构的消息中间件(Message Transfer System),即消息传递功能。在企业、金融、制造、政府等需要传递大量敏感数据的场合得到广泛应用。在互联网环境下,如何以最小的成本和代价高效、安全、可靠地将数据和信息从一个应用程序传送到另一个或多个应用程序,成为广大应用厂商和最终用户需要面对的共性问题。 消息代理中间件主要提供应用集成所必须的数据的递送、收集、翻译、过滤、映射和路由等功能,屏蔽不同的硬件平台、数据库、消息格式、通信协议之间的鸿沟与差异,提供应用到应用之间的高效、便捷的通信能力。 系统提供了完备的监控管理工具,包括证书管理、地址管理及系统监控等;提供简单易用的消息API和控制API,实现发送消息、接收消息和查询消息等功能,支持客户端程序可以调用控制API无缝地将对消息的动态配置管理集成到其中。 MTS 消息中间件的核心由消息服务和传输服务组成。 消息服务支持消息队列的消息组织形式。消息服务负责创建、配置、删除发送队列和接收队列。增加、删除、查询队列中的消息,修改和查询消息状态(未发送、已发送、过期等)及其他的维护消息队列的功能。 传输服务实现发送和接收消息的功能。传输服务基于TCP/IP,支持多种传输方式,包括HTTP、FTP、JMS等,传输服务还提供可选择的基于证书的安全连接方式:包括身份认证、数据加密、数字签名等。 消息中间件通信传输类型: l 可靠传输可以在保证报文正确性的前提下实现相对的实时传输。每个报文有相对的生命周期,在网络超时或者接受方当机时终止发送请求,即报文有可能丢失或非顺序到达。可靠传输对处理机和网络的开销较小,一般适用于对传输速率要求较高的准实时系统,而对报文的丢失有一定的冗余度。 l 确保传送可以保证信息的无丢失、按顺序传送。在信息的发送者与接受者之间的网络出现中断或者接受者方的机器出现故障,在网路恢复连接后,仍然能保证在故障时期内的所有信息按顺序的正确到达。确保传送的高可靠性是以较多的资源开销(处理机、网络)作为代价的。因此,确保传送一般是用于传送频率比较低,但传送可靠性要求高的信息传输,如重要文件的传输等,该传输类型类似于电子邮件的传输方式。 3.2.3.2. 数据库中间件 数据库中间件是处于底层数据库和用户应用系统之间的,主要用于屏蔽异构数据库的底层细节问题的中间件,是客户与后台的数据库之间进行通讯的桥梁。当客户向Web Server发出对某个数据库的SQL请求时,通过数据库中间件搜索匹配的数据库连接,并将SQL请求转发给对应的数据库服务器,通过其对数据库进行操作。 数据库中间件的主要功能: 1) 支持常用大型数据库的各种操作。如ORACLE、DB2、MYSQL等常用数据库。 2) 提供统一接口,屏蔽数据库之间的操作差异。 3) 封装复杂烦琐的数据库应用接口和数据库操作过程,简化应用程序的数据库操作,提高应用程序开发效率。 4) 支持常用的操作系统。如Windows、UNIX、Linux等,便于应用代码在各平台之间的移植。 5) 支持多线程,可以提供多线程与线程库,满足各种场合应用。 3.2.3.3. XML-RDBMS中间件 XML-RDBMS实现了由 XML 数据到关系数据库的双向映射,即数据从关系数据库中生成并转换为 XML,或将XML 数据转换到关系数据库中。另外,该中间件还实现了 XML-XML 之间的映射。该中间件支持多种数据格式之间的转换,包括XML,SQL,CSV 和所有主流的数据库系统。引擎所采用的转换算法具有速度快和占用内存少的优点,无论是做大量的数据转换还是大数据文件转换都不会因占用过多资源而使得系统性能下降。中间件支持所有 XML 现行标准,包括 Namespace, XPath, W3C schema, DTD, X-Query 等。允许用户自定义数据转换规则,并提供用于数据处理的大量系统函数同时支持用户自定义函数以实现扩展性。 XML-RDBMS 中间件提供了很方便的工具来实现数据之间的映射与转换,通过在源数据和目标数据之间建立连线,即可实现数据的映射,这只需简单的鼠标操作即可完成,另外,还可以利用内置的函数或是自己设计函数来定义转换的格式,实现数据的有效转换。 3.2.4. 基于业务基础平台快速构建应用 业务基础平台提供面向业务领域的技术基础框架,并具有可进化性、技术无关性、大粒度构件复用、业务对象复用等一系列新的特点,解决了软件复用度低、构建复杂、通用性较差等关键问题,为快速定制和开发企业级管理类应用软件提供强大支持。图形化的分析过程贯穿项目生命周期,通过流程挖掘过程来准确分析和表达用户需求,进而使得用户及开发人员形成一个良好的沟通平台。 3.2.5. 采用三层(多层)应用技术 由于传统的二层C/S结构存在以下几个局限:它是单一服务器且以局域网为中心的,所以难以扩展至广域网范围或Internet的大型应用模式;难以管理大量的客户机;受限于供应商,整个系统与特定的应用程序联系紧密;软、硬件的组合及集成能力有限。 三层结构是将应用功能分成表示层、业务逻辑层和数据层三部分。其解决方案是对这三层进行明确分割,并在逻辑上使其独立。各层说明如下: l 表示层 表示层担负用户与应用间的对话功能,通过浏览器模式实现表示层,组成的B/S结构;或使用可以自动更新的瘦客户端软件实现表示层,组成基于三层体系的“瘦客户/服务器”结构; l 业务逻辑层 业务逻辑层包含了具体的业务处理逻辑程序相当于应用的本体; l 数据层 数据层负责对数据库数据的读写管理。主要是利用大型关系型数据库进行迅速、大量的数据处理。 选用三层结构具有以下优点: l 系统管理简单,大大减少客户机维护工作量。 基于B/S结构的应用模式无需客户端维护工作;基于“瘦客户/服务器”结构的客户端可以实现自动更新下载,也无需客户端维护工作。 l 具有灵活的硬件系统构成 对于各个层可以选择与其处理负荷和处理特性相适应的硬件,方便的实现负载均衡。清晰、合理地分割三层结构并使其独立,可以使系统构成的变更非常简单。因此,被分成三层的应用基本上不需要修正。 l 提高程序的可维护性 三层C/S结构中,应用的各层可以并行开发,各层也可以选择各自最适合的开发语言。因为是按层分割功能,所以各个程序的处理逻辑
展开阅读全文

开通  VIP会员、SVIP会员  优惠大
下载10份以上建议开通VIP会员
下载20份以上建议开通SVIP会员


开通VIP      成为共赢上传
相似文档                                   自信AI助手自信AI助手

当前位置:首页 > 包罗万象 > 大杂烩

移动网页_全站_页脚广告1

关于我们      便捷服务       自信AI       AI导航        抽奖活动

©2010-2025 宁波自信网络信息技术有限公司  版权所有

客服电话:4009-655-100  投诉/维权电话:18658249818

gongan.png浙公网安备33021202000488号   

icp.png浙ICP备2021020529号-1  |  浙B2-20240490  

关注我们 :微信公众号    抖音    微博    LOFTER 

客服