EOS产品2案例清单.docx
《EOS产品2案例清单.docx》由会员分享，可在线阅读，更多相关《EOS产品2案例清单.docx（19页珍藏版）》请在冰点文库上搜索。
EOS产品2案例清单
PrimetonEOS®Platform产品案例清单
工商银行新一代CTP平台
1.1工商银行简介
中国工商银行（全称：
中国工商银行股份有限公司）成立于1984年，是中国五大银行之首，世界五百强企业之一，拥有中国最大的客户群，是中国最大的商业银行。
中国工商银行是中国最大的国有独资商业银行，基本任务是依据国家的法律和法规，通过国内外开展融资活动筹集社会资金，加强信贷资金管理，支持企业生产和技术改造，为我国经济建设服务。
1.2背景与问题
工商银行花20－30年时间走完发达国家银行业100年的历程，其前进的困难可想而知，这就要求银行的软件必须快速适应变化。
为适应这种变化同时又必须是可控，工行推出了自己的JavaEE应用开发基础技术平台CTP。
到目前为止，基于CTP平台上所开发的各类应用已经有数十个，并已经成为工行JavaEE应用的统一的基础技术平台，为工行JavaEE应用的快速开发和安全稳定运行，发挥了重要作用。
随着时间的推移，CTP平台的应用已超过五年，五年多的发展，IT业开发技术发生了很大的变化，类似的技术基础平台和相关的开发模式又面临新的挑战。
面对这种挑战，就需要对CTP平台进行升级改造，达到既保持CTP平台的技术延续性和版本连续性，又能够让CTP平台融入技术和架构方面的新元素。
现有CTP平台的核心架构是参考IBMWSBCC建立的，主要是针对交易类业务的框架，在新一代IT系统建设中要求平台的适用度更广泛，除了已有交易类业务外会有更多中间业务、信贷类、管理信息类应用的要求，为了适应新的应用类型，必须从核心架构入手进行改进，目前急需解决的问题是：
●架构的开放性和标准化
目前架构更适合交易类业务，只能支持固定接口的业务逻辑调用，也缺少对业务服务接口的定义，随着业务和技术的发展，做为更多业务的通用技术平台需要对更多实现方式的支持，需要在应用间提供更加标准化的模式。
只有在开放性和标准化的基础上，才能支撑未来的应用平台，也容易做到平台的复用和推广。
●编程模型的改进
目前绝大多数逻辑都放在存储过程中（即使是简单的增删插改），存储过程中的逻辑很难复用。
这种编程模型在交易类业务中比较适用，但不适用于管理信息类应用。
●分布式与应用间集成能力
目前还缺少平台级的集成功能，会影响到应用的分布式部署。
1.3使用产品与方案
新一代基础技术平台需要提供应用开发平台所共有的基础技术能力，以及核心技术开发工具，同时在新一代基础技术平台中，还要重点解决桌面集成，CTP与新终端平台融合，为应用平台提供平台化支撑等关键问题。
新一代Java应用基础技术平台的组成以及基础技术平台与其它平台的关系如下图：
新一代Java应用基础技术平台包括运行环境、IDE开发工具、运维管理工具：
●IDE开发工具：
为开发人员提供一体化的应用设计、开发、调试环境，包括应用模块分解，接口设计，数据设计，复用性设计，B/S应用开发、桌面应用开发、渠道接入开发啊、页面流开发，工作流开发，OPG开发，事件开发，平台扩展能力（即对应用平台的平台化支撑）等。
IDE要能够脱离RAD独立运行，并且开发期可以基于轻量级的应用服务器进行调试（如Tomact或Jetty）。
●运行环境：
是为Java应用提供运行时的支撑，如构件容器、UI框架、SEDA架构、信息推送、日志服务、运行平台扩展点等基础能力。
●运维管理：
包括管理控制台，诊断与预测分析工具以及为应用监控系统上送监控数据。
管理控制台为运维人员提供应用的部署以及应用参数配置。
诊断与预测分析工具为运维人员提供全路径的故障诊断工具，以及对应用进行日常的容量预测分析，实现对应用故障的提前预防。
所有的应用开发平台都可以基于基础技术平台进行扩展开发。
基础技术平台还可以与资产库之间实现资产同步，将资产库中的资产同步到IDE中，或者将IDE中的资产提交给资产库进行复用。
对于应用监控系统，基础技术平台可以为其上送监控数据，以及接受应用监控系统下达的控制指令。
1.4实施效果
●核心技术架构从单一B/S应用的技术架构演进到支撑应用群组的技术架构。
提高了性能与可管理性，提高横向伸缩能力，在应用内部支持分布式部署的方案，并将应用中的业务服务化，支持更容易的基于现有业务组装成新的业务。
●提高技术架构的开放性，适应更多类型的业务系统。
架构的开放性可以让平台能够更快适应新的业务场景，吸收已经积累的经验。
在数据定义、服务定义、逻辑调用方面更加开放，支持多种实现服务或逻辑的方式，支持在接口定义、服务调用、实现方式等方面的扩展。
●建设构件规范，为软件的模块化和复用提供基础。
建立构件规范的过程，是企业软件标准化的过程，技术架构本身开放的同时，必须建立一定约束，这个约束就是构件规范。
基于构件规范，才能够建立未来企业范围内更大粒度的复用。
构件规范包括构件的规格、逻辑模型、物理模型、数据定义、接口格式等等内容。
基于构件的规范，能够更容易实现软件的模块化，也为构件的复用提供了基础，同时构件规范也需要考虑系统间互联互通采用的技术标准。
构件规范符合业界已有的SCA、SDO、OSGi等标准。
●提供集成化的开发环境，保证架构、规范的落实，简化开发过程，提高开发效率。
-与已有工具、其他工具等整合。
-增加开发环境常用特性，包括重构、搜索等功能。
-提供更多的向导以提高开发的效率，降低学习成本。
●兼容性。
兼容原有的CTP版本。
建行JavaEE组件化平台咨询与实施
1.5建设银行简介
中国建设银行（简称建设银行或建行，最初行名为中国人民建设银行，1996年3月26日更名为中国建设银行）成立于1954年（甲午年）10月1日，是股份制商业银行，是国有五大商业银行之一。
中国建设银行主要经营领域包括公司银行业务、个人银行业务和资金业务，中国内地设有分支机构14,121家（2012年），在香港，台湾，墨尔本等地设有分行，拥有建信基金、建信租赁、建信信托、建信人寿、中德住房储蓄银行、建行亚洲、建行伦敦、建行俄罗斯、建行迪拜、建银国际等多家子公司，为客户提供全面的金融服务。
中国建设银行拥有广泛的客户基础，与多个大型企业集团及中国经济战略性行业的主导企业保持银行业务联系，营销网络覆盖全国的主要地区。
1.6背景与问题
建设银行在JavaEE上的实施能力在大型银行中首屈一指，他们在业务应用系统建设过程中逐步认识到需要有一个统一的开发平台来收敛建设银行的应用架构，解决应用中的非功能性需求，因此，很早就建立了JavaEE的技术规范和标准，并为了固化这些技术规范，开发了SUP1.0的开发工具平台，期望这个平台能够建立一个开放、高效、安全、稳定、统一的JavaEE架构，为JavaEE项目的设计、开发、运维提供良好的平台，从而为建设银行业务的发展提供强有力的支撑。
通过这个平台的确提高了开发效率、减少成本、降低了对开发人员的要求，满足快速变化的业务需求；降低了设计复杂度、提高设计有效性；增强系统的监控能力，提高运维的灵活性，降低运维成本。
但是，SUP1.0在设计之初的定位决定了其存在的缺陷，随着平台应用的深入，也深深感受到平台的不足之处：
1.架构级
●审视架构的视角不够完整，缺少必要维度的规划。
●系统内部的耦合性高，结构复杂，维护成本高。
●没有统一的服务接口方案，不利于业务复用。
●架构中缺少跨业务、跨页面的数据管理，完全依赖Web容器提供，对有状态逻辑的处理不方便。
●没有统一的监控框架，以及管理监控的基础设施，也不利于系统的管理、优化。
●对已有的公共系统如EAI、UAAP等，没有进行进一步的包装，各项目组自行实施，成本大、不统一。
●技术支持组件不足，如缓存、资源管理、消息等。
2.组织级
●对技术平台的研发投入不够，技术规范覆盖范围和技术平台提供的功能有限。
●缺少专门的支持、推广团队，技术平台的推广、实施速度比较慢。
●缺少专门人员持续研发，平台缺少可持续发展能力。
●对平台的维护投入不足，版本更新不及时，影响项目中使用。
3.过程级
●缺乏从已有系统中抽象可复用单元的过程保障。
●普遍偏向技术组件的提炼，业务专业化组件和面向领域的组件提炼不足。
●软件开发过程中单元测试不足，不进行每日构建与集成，不利于规模较大项目的管理。
●软件的非功能规范难于落实和检查，虽然进行了代码走查，但是过多的java代码，走查比较困难。
正是SUP早期版本的这些不足，使得建设银行高层下定决心要研发新一代SUP平台，从而满足建设银行IT系统的建设需要。
1.7使用产品与方案
建行JavaEE技术体系建设思路是通过技术标准来规范全行的业务应用系统的开发，这些规范对开发商起到了很好的约束作用，但无形中增加了应用系统开发的工作量。
因此建行决定建设统一开发平台，将这些技术标准、规范固化到平台中，并提供相应的开发流程和模板、工具，技术人员在实现业务需求的时候，不需要太关注这些标准/规范和底层技术细节，最后在全行内推广该工具平台，对全行的JavaEE环境逐步进行收敛和统一。
建行JavaEE技术体系发展路线
阶段一：
JavaEE技术架构规范
●自由开发：
每个应用用各自的JavaEE技术架构，基本上处于自由开发阶段。
●组件基本无积累：
每应用实施之后，留下来一对jar包，相关的文档，接口都不一致，基本无积累和沉淀。
阶段二：
SUP1.0
●规范手动开发。
●规范流程。
●技术组件的简单积累。
●统一应用架构。
阶段三：
普元咨询
普元是架构平台的专业厂商，在架构平台上具有一批人才，并且有很多的积累，因此，针对SUP1.0存在的不足，建行找到普元咨询，以期通过咨询更好的完成SUP2.0的发布。
阶段四：
客户化改造需求
在厂商已有平台的基础上定制开发适合建行的新一代应用平台，建行获得知识产权，厂商提供知识转移的培训和后续服务，并帮助建行建立此领域满足发展的人力资源队伍，建行的精力放在业务组件的建设和积累上，这种策略可以在别人的基础上快速自主掌控核心技术，可以最大限度满足建行需求并保证平台质量和先进性。
阶段五：
发布新一代SUP平台和推广
●随需应变的开发
●更加灵活的流程
●技术组件迅速积累
●业务组件持续积累
●建立企业级服务体系
1.8实施效果
建设银行JavaEE组件化平台的能力，可从支持的应用系统的技术架构、开发、互联等多个角度来阐述，可总结如下：
1.支持应用的设计开发，减少工作量。
2.可复用的应用框架；基础应用框架包含了菜单组件包、安全组件包（本地和UAAP）等功能模块在不同应用项目中得到了最大的复用。
3.规范系统结构；为应用系统提供统一的组件化结构视图。
4.JavaEE应用互联；为JavaEE应用系统的互联提供方便，支持将现有的JavaEE系统的POJO、SpringBean快速发布成服务。
5.工作流集成；实现了与普元工作流的业务接口集成，即通过接口封装实现了具体工作流产品无关性。
6.报表集成；实现了与建设银行的统一报表平台RIDE的集成，方便应用项目组使用RIDE报表功能。
7.兼容既有成果；兼容建设银行原有的SUP1开发平台和原有的JAVA开发规范。
支持主流的基础环境。
支持WebLogic、WebSphere多应用服务器、支持Oracle、infomix、DB2等数据库，支持Windows、Linux、HPUX、AIX等多操作系统。
截止到2010年9月份为止，基于SUP2.0平台开发的已上线业务应用系统超过20个，其中包括：
押品系统、对公客户关系管理系统、管理会计系统、操作风险管理系统、营运管理系统、对公业务审批管理平台、贷后管理流程优化等系统。
国家开发银行统一软件环境规划整合
1.9国家开发银行简介
国家开发银行（ChinaDevelopmentBank）于1994年3月成立，直属国务院领导。
目前在全国设有32家分行和4家代表处。
成立以来，开行始终认真贯彻国家宏观经济政策，发挥宏观调控职能，支持经济发展和经济结构战略性调整，在关系国家经济发展命脉的基础设施、基础产业和支柱产业重大项目及配套工程建设中，发挥长期融资领域主力银行作用。
1.10背景与问题
2008年12月16日，国家开发银行股份有限公司（以下简称开行）挂牌成立，标志着开行正式开始从政策性银行到商业银行的转变。
在这种背景下，需要开行把网络延伸到控股机构，服务延伸到海外机构，业务线会非常长。
IT已经由后台支持转为业务开展必须具备的基础设施，正因为如此，将来的IT系统会越来越多，建设IT系统与维护IT系统难度也会越来越大。
对开行IT部门提出了更高的挑战。
自2007年以来，开行每年都有大量新开发软件系统。
目前的SOA总线式架构，主要还是侧重系统之间的互联互通和整合，对应用系统内部如何构造服务、如何积累组件、如何解决应用系统内结构的松散耦合性以及如何对应用系统本身的监控和管理考虑较少。
开行应用系统建设方面面临主要挑战如下：
●如何规范开发商的技术架构，开发过程。
目前开行在应用系统的项目实施过程中，基本是各项目采用开发商自己的技术架构，采用厂商自己的设计规范、开发规范、测试规范。
这样使得开行的应用系统技术架构发散，不利于管控和维护。
●如何让应用系统在技术层面摆脱对开发商的依赖。
在开行从事应用系统开发的合作伙伴主要为几个大型的软件开发商，开发商在实施项目时都基于自己的技术方案和软件过程规范，项目完成后不利于向开行进行知识转移和传递，往往一个系统只能由一个开发商持续的支持下去，对开发商依赖性比较大。
●如何对开发商进行有效的管理和控制。
随着项目增多，开发商队伍也渐渐庞大，开发队伍可能会出现鱼目混珠的情况。
如何有效的对开发商队伍进行考评，对开发人员素质进行把关，形成对开发商的良性的考评方式，实现优胜劣汰的机制。
●如何有效的对应用系统进行监控与管理。
目前开行对应用系统的运维监控管理主要依托于JavaEE应用服务器自身提供的监控功能，只能监控到在JavaEE应用服务器的运行线程情况，不能对应用系统进行监控和统计。
●如何在IT项目实施过程中形成有效的积累，建立开行的软件资产库。
目前，由于各开发商按照自己的方式来开发软件项目，开行的IT项目实施过程中难于建立全行级的积累，长此以往，无法持续降低IT建设的总体成本。
1.11使用产品与方案
为了系统的解决上述面临的问题，开行决定以基于SOA理念的PrimetonEOS®Platform产品为基础，来建立开行自己的统一软件环境（UnifiedSoftwareEnvironment，以下简称USE），作为统一的应用开发、运行和管理平台。
USE平台中还包括统一的技术标准、规范、项目实施方法论。
本咨询项目就是为了配合开行一起制定USE平台远景规划及实施路线，帮助开行IT规划人员深入理解与掌握USE平台涉及到的理念、技术架构、规范、实施方法论等相关知识，从而使USE平台在开行更大地发挥价值。
开行已经制定了全行的IT总体规划，USE平台是此总体规划的一部分，侧重于在应用软件建设领域。
随之而来的一个问题就是需要USE平台能够与现有IT基础架构中的应用集成平台进行融合。
因此本项目的第二个目标就是将USE平台与开行中现有应用集成平台进行融合。
1.12实施效果
●完善管理评估体系和规范开发商管理。
通过USE平台进一步建立起科学有效的项目进度、质量和工作量的管理评估体系，从而规范对开发商的管理，对项目的把控力度也将大大增强。
●提升系统开发、维护效率。
目前USE平台已在9个项目中的到使用，通过基于USE平台开发的业务应用系统与以前同等规模的业务应用系统相比，USE平台的集成化开发方式、组件复用机制等可以缩短降低整体成本20％以上。
另外，通过USE平台能够实现对制定的规章制度和规范的固化，从而保障行内制度规范的落实；而且，USE平台屏蔽了很多技术细节，使得开发人员更加简单、方便、易用的完成项目开发；最后，通过USE平台自动生成的文档，保证了代码与最终文档的一致性，这样系统维护工作更加迅速，修改变更更加容易。
●引导集约化经营模式。
以USE平台建设为契机，带动统一流程平台、企业服务总线、统一授权平台、内容管理平台、统一报表平台的规划和建设，对行内的各种应用系统平台进行深入整合，包括合并、独立一些符合行内现状的基础设施，由粗放型经营转为集约化经营模式，开展深入挖潜，避免重复投资建设。
中国银行江苏省分行
1.13中国银行江苏省分行简介
中国银行江苏省分行是中国银行在江苏的一级管辖分行，成立于1979年，实行在总行领导下的行长负责制，下辖12家二级分支行和12家南京地区直属支行。
截止2002年6月末,在全省的机构网点1001个，员工17000余人。
1.14背景与问题
如何加强风险管理是金融行业永恒的话题。
随着中国银行的上市，在更高的外部监管要求之下，中行把客户贷款的风险控制提到了战略的层面，希望能够藉由信息系统的建设，将信贷的操作风险、市场风险和道德风险全面进行量化和监控。
为此，中国银行选择了信贷规模最大的江苏分行作为试点建设风险管理系统。
一期系统由中行的一家合作伙伴采用手工编码的方式进行建设，主要从功能实现的角度进行构造。
然而，这种总体架构设计的缺乏无法全面适应江苏中行业务和流程变化所导致系统的数据结构和业务逻辑变更。
系统的改动往往要在超出预期的时间内才能完成，同时质量也很难保证。
一期上线后有些流程的调整甚至难以实现。
为了克服一期系统中的诸多问题，江苏中行考虑启动客户风险管理二期项目对系统进行升级。
1.15使用产品与方案
江苏中行经过严格论证，最终决定采用面向构件技术进行系统升级。
面向构件技术使得各应用系统之间的信息沟通与整合变得更容易。
同时，开发速度的提升能使开发商更加快速地开发出原型系统，从而及时向用户求证是否满足需求。
中国银行江苏省分行风险管理部主管琚江是这个项目的负责人，他认为采用面向构件技术之后，功能增加了一倍，而费用却依然持平；开发效率提高50%以上，应用维护成本节省70%以上，构件复用率80%以上。
江苏中行采用面向构件技术的关键目标是：
●能够快速满足系统业务流程根据业务需要快速进行调整的要求。
●系统开发采用统一的面向构件技术平台，基于开放的技术标准、面向服务的架构（SOA）、面向流程的业务整合，带来系统稳定性和扩展性的提升。
●提高系统在性能上的表现。
系统必须在多用户数、大访问量、高并发性和高响应速度上有更优异的表现。
1.16实施效果
二期项目开发速度远远超越一期。
其中的在线放款审批流程为例，原来基于编码的方式来实现这样一个流程需要1个月的时间，而基于面向构件技术实现这样一个完整的流程，从页面到处理逻辑、和数据库的交互，经过完整的测试，只需要15天的时间。
同时，该系统自上线以来一直运行平稳，高峰时最高在线用户数为400人左右，业务处理平均时间不大于4秒。
基于面向构件技术开发的二期系统，体现了SOA带来的优点：
●以流程为核心整合各专业职能部门、各类系统，整个系统架构具有极强的灵活性。
业务流程能够根据客户需求的变化，快速进行调整。
●大量复用成熟构件，以组装的方式开发系统，系统开发快速，节约成本。
●可视化的软件治理。
系统运行的任何时候，都可以监控到每个构件的状态以及构件之间的参数传递，系统整个运行状态变得透明，借此，维护人员可以快速进行系统故障的定位，并监控到系统运行的瓶颈。
还可以对整个系统的安全性等方面进行调控。
华为定制运营支撑管理平台项目
1.17华为简介
华为于1987年成立于中国深圳，全球第二大通讯设备供应商，全球第三大智能手机厂商，也是全球领先的信息与通信解决方案供应商。
公司围绕客户的需求持续创新，与合作伙伴开放合作，在电信网络、企业网络、消费者和云计算等领域构筑了端到端的解决方案优势，并致力于为电信运营商、企业和消费者等提供有竞争力的ICT解决方案和服务，持续提升客户体验，为客户创造最大价值。
目前，华为的产品和解决方案已经应用于140多个国家，服务全球1/3的人口。
1.18背景与问题
华为公司近年来在海外市场进展迅速，2005年上半年华为销售额超过330亿元人民币，其中出口24.7亿美元。
在国际市场中，华为已成功跻身于领先的通信设备及解决方案供应商行列。
电信运营商一向以严格、挑剔著称，如何快速部署电信企业大型应用系统、构建统一、易用、性价比高的软件开发与管理平台，从而提高客户满意度成为华为的重要目标之一。
华为需要一个同样优秀的中国中间件软件平台供应商开展强强合作。
1.19使用产品与方案
自2005年5月始，经过广泛的考察，华为将目光锁定在普元身上，并与普元进行了全面接触，最终达成意向。
双方合作项目的开展，将使华为通过应用“面向构件”卓越特性，快速多变地部署电信级企业应用软件，这将降低华为研发成本，增加华为对客户需求变化的响应能力，从而为其全球化竞争赢得优势。
1.20实施效果
华为与普元结成平台软件战略合作伙伴，普元为其定制统一、易用、性价比高的软件应用开发与管理平台。
基于普元平台解决方案，华为已在全球40多个国家、60个多家电信运营商中得以高效部署电信级应用软件，极大降低了研发成本，增加了对客户需求变化的响应能力。
远光软件股份有限公司
1.21远光软件股份有限公司简介
远光软件股份有限公司（以下简称远光软件）是一家产品型软件商，专注于电力行业信息化领域，拥有自主研发、自主知识产权的ERP产品。
1.22背景与问题
远光股份作为电力行业较有影响力的软件厂商，有约30人左右的平台框架部门，但随着客户项目的增多、交付压力加大，底层技术支撑能力逐渐凸显不足：
1.为了迎接云平台时代，电力行业提出了业务平台大集中，即通过一个应用平台部署所有应用，这对应用治理提出了更高的要求，如何统一部署应用，减少上线复杂度，如果合理有效地监控应用平台以及应用成为了比较有挑战性的难题。
2.并行项目太多，没有形成统一的开发流程和开发规范，项目质量不统一。
3.大量重复的开发没有形成有效积累，开发效率较低。
4.没有成熟的BPM平台，无法满足日益增长的工作流程相关需求。
5.上线后业务运行情况无法有效监控。
6.关键业务无法跟踪，业务错误时无法还原轨迹。
1.23使用产品与方案
远光在与普元经过了使用普元标准平台产品的合作后，开始考虑由普元帮助其定制下一代运营支撑平台的软件平台框架。
1.基于普元的PrimetonEOS®Platform和流程产品，普元协助远光建立自己的云应用平台以及应用治理平台，解决云部署、云监控等云治理问题。
2.引入BPM产品，并与开发平台紧密结合。
3.固化开发流程和业务代码生成向导，提供规范检查工具，规范开发过程和代码。
4.建立和健全组件库以及组件积累机制，提高复用度，提高开发效率。
5.引入平台级业务监控和业务全路径跟踪机制，关键业务可还原流程轨迹。
1.24实施效果
为迎接云时代的到来，进一步提高软件质量，缩短交付周期，适应电力行业大集中的要求，远光软件与普元合作研发了EnterpriseCloudPlatform（ECP）平台，以支持云计算环境下电力软件的设计、开发、实施、运维。
远光现有应用产品已逐渐向新的ECP云平台迁移，可提供一整套的云计算解决方案，开发了适合国家电网公司一级部署的软件系统，2013年完成开发并实现在三个网省公司的试点。
中国太平洋保险公司客户投诉管理系统
1.25中国太平洋保险（集团）股份有限公司简介
中国太平洋保险（集团）股份有限公司是在1991年4月成立的中国太
升级会员 