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

1. 项目综述
1.1. 项目背景
短期气候估计是气象业务关键组成部分，是当今人类社见面临一项重大课题，也是目前气象科学研究和发展关键。全国气候变暖已是一个不争事实，气候问题日益受到关注，气候改变和社会、经济发展关系亲密，多年来多种气候极端事件如干旱、暴雨洪水、低温冷害、沙尘暴、雪灾等频繁发生，展现加剧趋势，伴随中国经济社会快速发展，社会进步，人民生活水平提升，政府和公众防灾减灾对短期气候估计产品需求在急速增加，短期气候估计需求越来越迫切。短期气候估计在国民经济建设和防灾减灾中作用越来越关键。
中国经过几十年对气候估计业务不懈努力，也取得了很大进步，现在关键制作并公布月、季、年时间尺度气候趋势估计业务，关键估计产品包含《月、季气候估计》、《汛期气候估计》和《年度气候估计》。从常规温度、降水估计出发，发展了冷空气、霜冻、台风、春播天气等专题气候估计。产品内容包含：全市月平均温度趋势预报，月降水量预报、月降水距平百分率预报，夏季高温，伏旱，台风等等。产品形式以文字叙述为主，辅以预报要素（温度、降水等）图表。产品关键为政府相关部门提供决议服务，同时也为相关行业提供技术指导和参考。
众所周知，因为受到对长久天气过程认识水平制约，50年来，即使在短期气候估计方面做了大量工作，短期气候估计实际业务工作关键依靠经验和相关统计方法。现在，对多种资料搜集、整理和多种相关统计工作即使在工作中使用计算机处理，但尚处于早期半自动化状态，预报员在长久预报实践中积累工作经验和方法未实现自动化，建立比较完善、网络化、适用短期气候估计业务系统是摆在我们面前迫切任务。短期气候估计业务是依据大气科学原理，利用现代气候动力学、统计学等方法和电子计算机、数据库、通信技术等手段，在研究气候变异成因基础上，对月、季、年际时间尺度气候趋势和气候灾难进行科学估计。伴随现代科学技术和管理技术提升、生产信息多元化和复杂化，使得信息处理和管理工作也越来越关键。人类进入二十一世纪后，信息化水平高低成为衡量一个地域现代化水平，一个国家综合国力关键指标。所以，建立一个短期气候估计业务平台，很有意义。
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 二十四小时不间断工作，出现故障能立即告警，含有完整操作权限管理功效和完善系统安全机制。应用系统含有自动或手动恢复方法，方便在发生错误时能够快速地恢复正常运行。
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结构中，应用各层能够并行开发，各层也能够选择各自最适合开发语言。因为是按层分割功效，所以各个程序处理逻辑变得比较简单。
l 进行严密安全管理
涉密关键应用安全管理很关键。在三层C/S结构中，识别用户机构是按层来构筑，对应用和数据存取权限也能够按层进行设定。比如，即使外部入侵者突破了表示层安全防线，若在功效层中备有另外安全机构，系统也能够阻止入侵者进入其它部分。
MVC (模型－视图－控制器)是一个现在广泛流行软件设计模式，现已正成为J2EE平台上常见设计模型。MVC模式融合了很优异设计思想，不管你选择哪种语言，不管应用多么复杂，MVC模式全部能为你了解分析应用模型时提供最基础分析方法，为你结构产品提供清楚设计框架，为你软件工程提供规范依据。
MVC设计模式由三部分组成：模型(Model)，视图(View)和控制器(Controller)，基础描述以下：
组件
描述
模型(Model)
封装数据对象，模型用来封装和显示数据对象
视图(View)
作为模型显示，它表示数据对象目前状态
控制器(Controller)
定义对用户输入实施对应操作接口，它用来操作模型（model）和数据对象

MVC设计模式中模型，视图，控制器之间关系和功效以下图所表示：

基于MVC模型开发，其好处关键表