煤炭企业信息化平台方案建议书

1、 467/467煤炭企业信息化平台方案建议书目 录 TOC o 1-3 u 第1部分平台技术方案 平台技术方案平台技术发展趋势概述在企业和组织信息化变革的大环境下，我们需要全新的思想，通过模块化渐进式的改变，来重新定义计算资源的使用方式、服务的提供方式，以及社会化大生产的协作过程。云计算带来了这种思想的落地机制，这种机制使我们可以组织资源以服务，组织技术以实现，组织流程以应变。而且，云计算扩大了我们对服务的定义，并带来了一个全新的计算资源管理思路，一种信息技术的系统工程理念和一次信息社会的工业化革命。信息技术正在使当代世界发生重大变化，如何让信息系统真正适应企业的发展变化？如何降低信息系统使用

2、、升级、维护、实施和开发的复杂度？如何降低信息系统建设和运营的成本、提升其应用的价值？云计算为以上关键问题的突破提供了广阔的创新空间和平台。IT架构演化如图下图所示，在传统的竖井式信息系统架构中，通常只能事先根据对各业务应用的容量预测，来规划资源和能力的分配，难以实现灵活动态的能力保障来应对快速多变的业务需求。从资源共享和隔离的粒度来看，传统IT是一个资源完全不共享的架构，用户需要管理所有的物理资源到应用的所有方面。而企业目前广泛关注的IaaS是一个利用虚拟化技术，共享计算资源、存储资源和网络资源的架构，用户需要手工管理从操作系统往上的数据库、中间件和应用。以后发展的PaaS平台，对于PaaS

3、资源共享和隔离主要分为两个方向，一个是以Openshift为代表的，继承了IaaS资源共享和隔离的思路，在操作系统层面再进行计算资源、存储资源和网络资源的细粒度的切分；另外一个方向是从中间件共享的角度，实现不同租户间应用程序运行环境的隔离以及运行时数据的隔离，用户需要手工管理从中间件往上的应用。再往后发展是基于云的SaaS，传统的SaaS应用主要采用元数据驱动的方式，强烈依赖于数据库，所有租户采用一个数据库Schema，元数据和业务数据都存储在数据库中，在性能上广泛采用数据缓存技术，主要代表为Salesforce，缺点主要是针对于某一个应用领域，比如CRM，不能灵活地重用到其他领域。未来Saa

4、S应用将基于云的架构，能够充分利用PaaS和IaaS多租用和自动弹性技术，以及 PaaS丰富的云服务，快速搭建基于云的SaaS，并且能够实现底层资源层面、操作系统层面、应用服务器层面、数据层和应用代码粒度的共享。图 企业和组织的IT架构演化路线在云计算环境下，传统的应用IT架构将发生重大变化，但SOA继承了下来，并得到了发展， SOA与云计算结合将是未来的企业应用IT架构方向。如下图所示，云计算在垂直方向上将应用和物理硬件进行了解耦，而SOA在水平方向上实现了应用之间的解耦。垂直方向上的解耦意味着云可以在水平方向上进行伸缩(通过增加/减少工作节点)，另外从应用的角度，SOA倡导的无状态化设计原

5、则也能更好地支撑云的水平扩展。水平方向上的解耦意味着应用可以在垂直方向上进行伸缩(应用的不同组件垂直分布到不同的中间件工作节点上)，最终也能够实现应用从一朵云自动迁移到另外一朵云上 (如：私有云迁移到公有云或混合云)。图 企业和组织的IT架构趋势基础设施管理技术发展趋势以前以“服务器+网络+存储”构成的IT基础设施已经形成一个很稳定的架构，但是这种 IT基础设施是静态和僵硬的。传统数据中心基础架构层面的设备之间通过标准化连接和协议互通，保证了计算、存储和网络设备的管理系统之间相互分离和独立，从而使得不同的运维团队可以按照自身业务发展与架构演进的趋势不断完善和深化各自的管理规程，满足数据中心业务

6、不断发展的要求。而今天的需求则是一种全新的动态IT基础设施，即IT基础设施要能够“按需生成、按需扩展、按需缩减、按需计费、自动生成，即时交付”。在云计算环境下，各自独立和分离的运行模式不能支持云服务的展开，新的IT运行模式对传统的管理架构提出了挑战。虚拟化 传统数据中心中每个物理服务器上只是单个或几个应用的固定运行，业务基本是与主机的绑定运行方式，对主机的管理，某种意义上也就是对业务的管理。而在云计算环境下服务器大量采用虚拟化技术，每一个物理网络端口下都会分布多达数十个虚拟机，物理主机上运行着多个不同的操作系统和应用，网络中应用密集度极大增长，对网络的性能、规格和可靠性都提出了更高要求，而虚拟

7、机网络属性的可管理性更是面临巨大挑战。动态性传统数据中心的业务针对物理主机展开，而物理服务器一般固定连接在某个网络端口上，并且业务属性单一，无论是网络策略、安全控制都比较固定。只要主机与网络运维界面清晰、系统归属明确，业务就容易展开，并能平稳运行。但是云计算环境中部署着高密度的虚拟机，在虚拟化环境下，基于服务变更、容灾、分布式计算等业务运行要求使得虚拟机动态迁移成为必备属性。如果网络无法感知这种动态性计算方式，持续的运行必将造成业务的紊乱、运维的不可控，这就要求管理系统能够具备动态计算的感知能力。关联性当前的网络与计算之间以一种松耦合方式运行，网管与主机管理系统之间基本上没有信息关联交互。而虚

8、拟机的动态计算特性，将使得当前的网络管理系统无法对虚拟机进行定位，网络对业务的安全、控制、配置、监管也就无法关联到虚拟机，也就无法实现云计算下的灵活部署和扩展性。另外在云计算环境下，应用是根据租户的订购请求，动态地部署到各个虚拟机中的，再加上应用程序与组件是多对多的依赖关系，一个应用程序出了故障，很难快速地准确定位是哪一个组件出现了问题，在哪一台虚拟机上和哪台物理机上，因此问题故障的定位是云计算环境下数据中心管理的又一大挑战。这里面涉及租户到应用的关联，组件和应用的关联，应用到虚拟机的关联，虚拟机到物理机的关联等信息的动态维护。自动化在非虚拟化环境中，业务部署后一般都具有相对的固定性，即主机位

9、置、网络接入比较确定，运行维护的目标与物理机、物理端口一致，主机系统、网管系统分别部署，调试对接相对比较容易。但在大规模云数据中心，基于传统的分离调试无法有效支持云服务的业务模式，这就要求整个服务的供应能够简单提交，且不同系统(基础的计算、网络，上层的主机、网络管理系统)之间能够交换服务信息，并基于一致的业务要求完成所有部件的自动化部署与运行。多租用在云计算环境下，计算、存储和网络资源被汇集成资源池，然后将不同的物理和虚拟资源动态地分配或再分配给多个租户使用。多租用的目的是为了服务多租户而实现计算和数据隔离的技术。如何最大限度地让各租户共享资源，降低运营成本，同时保证多个租户的计算和数据相互隔

10、离是云计算环境下数据中心管理上的又一大挑战。为了支持云计算环境下的虚拟化、动态化、关联性、自动化和多租用服务要求，整个云计算系统将需要有一个统一的操作运行管理平台，可称之为云管理平台，能够对云服务进行端到端自动化部署，同时快速响应资源调度与业务变更的服务需求。云管理平台能够屏蔽云服务供应层面对底层不同架构的差异，使得用户或业务运营部门聚焦在服务层面，不必关注底层资源(计算、网络、存储)本身的技术属性。软件架构的发展趋势1996年是HTML发展的一个里程碑，JavaScript和层叠样式表（CSS）相继诞生，W3C制定的 HTML3.2规范出炉。此时的Web UI可以与用户的操作进行交互，根据用

11、户的行为方便地修改UI元素和调整样式，从而实现动态的DHTML页面，此时的内容还都是所谓的静态页面，无法根据不同的外部条件展示不同的内容。随后，CGI、ASP、JSP和PHP等服务器端脚本技术相继涌现，真正的动态页面出现了。服务器端代码分析用户提交的请求参数，从数据库服务器获取相应的业务数据，动态地将网页和数据组合拼装出网页的HTML文本推送到客户端浏览器。此时的服务器端页面不再是一个单纯的UI模型，而是一个服务器端脚本引擎来处理生成客户端UI模型的模板，其中包括HTML片段、脚本块和标签等元素，比如Struts、Tapestry和WebWork等基于Java EE技术的Web框架就是此类技术

12、的集大成者。随着Web开发技术的进一步发展，又出现了服务器端UI 组件技术，例如ASP.NET中的服务器端UI组件和JSP中的JSF组件。其使用服务器端脚本技术，封装部分HTML、JavaScript和CSS片段构建一个完整的UI组件模型，在运行期间解释并与数据进行整合，最终输出为实际的HTML代码(资料来源：百度百科)。这就是目前企业和组织的UI层技术现状，存在的问题是UI的技术百花齐放。如下图所示是目前企业和组织的软件架构现状，在中间件这一层存在的主要问题是各种中间件都严重依赖于应用服务器，并且在企业应用中应用服务器不能很好地水平扩展，关键在于应用的状态化。另外现有的应用性能强烈依赖数据库

13、的性能，比如Oracle RAC。图 企业和组织的软件架构现状以上是软件架构的现状，但是技术总是在不断演进。随后的HTML5是用于取代1999年所制定的HTML4.01和XHTML1.0标准的，现在仍处于发展阶段，但大部分浏览器已经支持某些HTML5技术。HTML5强化了Web网页的表现性能，并且追加了本地数据库等Web应用的功能，提供更多能有效增强网络应用的标准集，与HTML5类似的厂商技术如Adobe Flash、Microsoft Silverlight以及JavaFX技术。另外基于JavaScript的UI技术的出现，将Web UI的控制权从界面设计人员递交给了程序员，即可以直接在We

14、b的前端使用JavaScript脚本来描述一个UI组件模型，然后在运行时，由浏览器的脚本解释器调用核心的UI技术框架来将其转换成HTML的UI界面。此类UI技术框架跟服务器端UI技术的思路一致，只是在客户端浏览器中封装了一套UI模型。这样界面设计不需要服务器端的支持，在开发期间能更好地展示和测试界面效果。同时由于UI界面的构建和控制都在客户端，只需要和服务器端传递请求参数和数据，这样就能比服务器端UI技术大大降低服务器端的压力和网络数据的传递量。这类基于JavaScript的UI技术目前有模块化框架的代表oz.js， MVC框架的代表backbone.js、AngularJS和Ember.js

15、，标准化框架的代表Jquery.js，UI框架的代表underscore.js。另外以前的IT是以PC端为中心进行UI设计的，应用都是以功能为中心。在云计算环境中，服务能力都通过网络来提供，可将服务扩展到不同类型的客户端平台，如手机、PAD等。这种端的变化，使传统IT转变为以移动为中心来设计UI，同时应用变为以用户为中心。这就要求企业应用的UI层越来越需要朝着HTML5、JavaScript和CSS3的方向演变和发展，也就是说UI层对于传统的应用服务器端来说将变得越来越轻量化。另外由于UI的轻量化将导致传统的应用服务器中的JSP容器等逐渐变得不再需要了，更不用说EJB容器早就被大部分企业抛弃，

16、因此未来的应用服务器有退化成Web服务器的趋势。以前应用服务器提供的事务、日志、缓存、持久化、JMX和集群等功能将会下沉到OSGI等模块化框架中去，从而实现中间件服务器的轻量化。另外从企业业务本质上来说，大部分企业业务都是有状态的，那么这些状态将保存到哪里呢？在云计算环境下这些状态将存放在内存数据网格中，内存数据网格除了要承担分布式数据缓存和状态复制等功能外，还将融合传统的数据持久化（ORM）和类SQL查询以及并行计算的功能。内存数据网格通过数据缓存将大大缓解现有企业应用读数据库数据的性能问题，从而使得应用性能将不再强烈依赖数据库的性能，最终实现数据库服务器的轻量化，为数据库在云上的应用铺平道

17、路。企业与组织的软件架构趋势如下图所示。图 企业与组织的软件架构趋势总体技术平台方案产品需求分析根据技术规范中的采购内容，本次产品需求如下Java 开发平台产品 企业级流程平台企业级移动开发框架定制化开发其中，Java 开发平台产品即业界的“综合开发平台产品”，包括企业级的统一应用开发框架（统一应用平台）；企业级流程平台即业界的面相企业的大型综合“业务流程管理（BPM）”平台产品；企业期移动开发框架，针对广核工程公司的基本现状，需要“面向企业”的综合移动开发平台产品；定制化开发是对“企业应用开发框架”的适应性改造。iUAP平台的开发平台，集成平台中的BPM产品，移动平台能否覆盖采购需求，产品方

18、案如下：产品方案iUAP开发平台业务流程管理（BPM）平台企业移动平台下面3.3到3.5章节按照产品方案中的产品体系分别描述具体技术方案。总体技术能力支持业界主流标准规范支持SOA、SDO、SCA规范SOA-面向服务的架构，可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容

19、地面对业务的急剧变化。SCA（Service Component Architecture，SCA）是实现SOA的服务组件模型。这是一种全新的、跟语言无关的编程模型，它提供了一种统一的调用方式，从而使得客户可以把不同的组件类型，比如POJO, EJB, 流程组件，人工交互组件等都可以通过一种标准的接口来封装和调用。结合SDO的数据模型，SCA服务组件的编程模型就可以简化编程，提高应用的灵活性。这就是面向服务组件的架构。基于组件编程是软件业简化编程和提高效率和质量的一个重要方法，但是对于不同语言有不同的组件模型，需要不同的调用方式。为了给这些不同的接口提供一个统一的调用方式，面向服务的组件模型（

20、Service Oritented Architecture, SCA）应用而生。SCA使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用。这种方式也使得客户的企业应用具有良好的分层架构，能够很好的分离应用的业务逻辑和IT逻辑，不但易于应用的构建，也易于应用的更改和部署。iUAP 支持基于Java技术实现对SOA规范的支持，采用组件化的编程规范和模式，使得iUAP可开发出具有架构优化、高灵活性、高扩展性的企业应用。运用iUAP对SOA规范（SCA，SDO）的支持，可以开发出高可用、架构优化的大型企业应用，NC大型ERP产品就是iUAP开发平台基于SO

21、A架构实现的企业应用的典型范例。支持JAVA EE规范JAVA EE规范总结起来包括事务管理、资源，命名和注入、应用程序编程接口，互用性、应用程序组装与部署等。事务管理：开发平台提供基础事务和扩展事务的支持，扩展事务采用接口形式定义。资源，命名和注入：开发平台引用了资源管理器连接工厂的设计理念，引用了JNDI命名上下文环境，EJB的支持以及web服务的引用。应用程序编程接口：开发平台支持Servlet3.0标准规范，JMS标准，JSP标准以及企业级JavaBeans标准。互用性：为保障产品的互用性，开发平台支持但不限于Internet和Web协议、Java技术协议、Http协议等。应用程序组装

22、与部署：开发平台可与其他web中间件联合管理应用程序的生命周期、应用程序的组装、类库的支持以及类加载标准等。SOA编程模型SCA模型服务组件模型（SCA）包括服务组件，模块，共享库，导入和导出。服务组件服务组件即业务逻辑。使用服务组件的客户端可以选择使用WSDL接口或Java接口。服务组件提供给别的服务调用的入口为Interface，而服务组件调用出口为Reference。服务组件的接口模型请参考服务模块（Module）服务模块由一个或多个具有内在业务联系的服务组件构成。模块可以独立部署，只要保持模块接口不变，就可通过重新部署新的模块而替换原有的业务逻辑，而不影响应用的其它部分。导入（Impo

23、rt）和导出（Export）实际的应用通常需要多个模块才能满足要求，而且这些模块之间又往往存在相互调用的关系。在模块中引入了两个特殊的端点，一个是导入（Import），使得模块中的服务组件可以调用模块外部的服务。另一个是导出（Export），使得模块外部的应用可以调用模块中的服务组件。由于涉及到模块内外的调用，因此需要指定专门的绑定信息。导入端点提供了四种绑定方式，包括：JMS绑定，Web Service绑定，SCA绑定和无状态会话BEAN的绑定。导出端点提供了三种绑定方式，包括：JMS绑定，Web Service绑定和SCA绑定。对于SCA模块之间的调用，把绑定方式设置为SCA绑定，对于非S

24、CA模块与SCA模块之间的调用选择其它绑定方式。共享库（Library）如果有一些资源可以在不同模块之间共享，可以选择创建一份可以在不同模块之间进行共享的资源，共享库存放这些共享资源。共享库通过与模块类似的方式创建，共享库包含的内容只有：数据定义，接口定义，数据映射和关系。共享库不包含服务组件，不包含业务逻辑。当一个模块需要用到共享库中的资源的时候，使模块依赖于共享库。一个共享库会对应一个JAR包。在部署的时候，模块所对应的J2EE企业应用会会自动包含所依赖的共享库JAR包。调用方式SCA采用异步调用方式。有三种方式的异步调用，它们分别是：1 单向调用方式。2 延迟响应方式。3 请求回调方式。

25、单向调用单向调用方式是最为简单的异步调用方式，客户端发出请求之后就不再关心服务端的情况，包括是否执行成功，返回值是什么等等。单向调用方式是一种不管调用结果的方式。延迟响应方式延迟响应方式是客户端在发出调用请求之后继续执行，经过一段时间之后，再调用相应的方法去检索返回结果，并通过参数指定如何根据调用的结果而执行进一步动作。在第一次发出调用请求的时候，服务端需要返回一个称为票据（Ticket）的对象，这个对象会作为第二次发出检索结果请求时的一个参数。请求回调请求回调方式的响应是由服务端通过回调方式来触发的。我们可以用图6来表示请求调用方式：SCA客户端调用方式SCA的客户端编程模型有两种方式：1

26、静态调用方式2 动态调用方式静态调用方式静态调用方式是示例如下：动态调用方式动态调用方式与静态调用方式相对，示例如下：当提供的接口类型是WSDL类型的，那么客户端的调用方式只能是动态调用方式。如果提供的接口类型时Java类型的，那么客户端的调用方式可以是动态调用方式，也可以是静态调用方式。组件开发标准组件设计业务组件和开发组件设计：图：业务组件说明：业务组件是产品的组装单元。业务目的：组件需要实现的业务功能；业务服务：组件提供的服务；业务活动：一个业务活动可以包含一组操作，每个业务活动的执行结果使业务对象具有业务上的一致性状态，符合一致性状态要求的数据是可以访问的；业务活动通常完成一项业务职责

27、。业务数据：组件内业务处理涉及的数据对象；业务策略：（一组）业务活动的Selector，不同的场景可能使用不同的业务策略；组件治理：根据组件自身的治理要求，独立对组件的内容进行约束及管理；业务组件的分类：基础组件基础数据、基础规则业务管理组件业务执行、业务检查、监控业务分析组件业务分析决策注：公共技术组件不属于业务组件，可与业务组件并列。图：服务组件与开发组件业务组件与开发组件：每个业务组件可以包含一组开发组件。开发组件包括：UI组件业务服务组件业务活动组件业务实体组件引用组件其它组件业务组件、业务单元与业务活动的关系：业务单元：一个在业务组件内部具有更紧密关系的业务活动的集合。1）一个业务组

28、件可以有多个业务单元，每个业务单元可以有多个业务活动2）业务单元之间推荐采用松散耦合的方式3）业务单元可以共享公共的技术设计及实现4）业务单元可以访问组件内，本单元外的公共业务实体的表结构业务组件划分以主设计为主，应用架构师、需求、设计、开发等参与。多角色多维度分析之后的结果。如何划分业务组件的原则：1）业务组件的业务目的和业务场景，确定业务边界；2）业务组件之间松耦合、业务组件内部的内聚性；3）业务的可独立配置单位；4）业务的可独立部署单位；5）业务组件的可替换性；6）每个业务活动只能唯一属于一个业务组件，不同业务组件的业务活动不应重复；业务活动应基于角色进行划分。7）从开发角度的一个约束：

29、一个业务组件内的开发组件（操作、服务的实现类） 可以直接访问本组件的业务实体的表结构。表结构对外是不可见的（报表除外）。8）每个业务组件有一个独立的SRC目录，不同业务组件的代码必须隔离开；如何划分业务组件，需要深入了解业务之间的关系，并根据管理模式、应用场景、与其它业务组件的关系等各个层面的需求来进行分析。分析业务之间的关系，紧密耦合的组件考虑合并，例如继承关系。关于组件的设计组件的变化性方面：支持变化性的组件（开发组件）的详细设计有以下两种选择：将变化性的多个变化项设计为多个组件实现。这样接口清晰、组件设计简单、没有冗余代码。把所有的变化性情况设计到同一个组件中，用一种机制来处理所有的变化

30、项。这样组件设计复杂，但是使用和演化比较灵活，组件的复用性也较高。组件的详细设计建议采用以下方案：组件有一致的接口：设计多个组件实现来对应变化项；采用参数化机制。组件的接口是变化的：采用组件技术提供的一些变化性控制机制；组件定制、组件集成框架等。对于支持变化性的组件的两种复用方式：使用大量小的专用代码，通过胶合代码(glue code)组装这些组件来实现变化性使用内含一定变化性的大组件大粒度组件和小粒度组件（代码小片断）复用：支持变化性的组件带来更多好处管理：少量大粒度组件更加容易管理成本效益：集成、组装大量小粒度组件使得成本效益减少用大粒度组件的成本效益比较好，但是变化性的增加会导致投入的增

31、加另外，开发组件内代码的名称空间中不反映业务组件，直接在模块下。这样在业务组件之间移动业务实体/业务操作时，不影响引用它们的代码。业务服务的分析及设计业务服务和接口之间是1:1的关系，实现业务服务与软件服务的对齐。分析业务服务及粒度：服务功能范围的粒度是由其功能上下文所决定的。一个服务的整体粒度并不反映它当前封装的逻辑的数量，而是反映它基于上下文能够封装的潜在逻辑的数量。从业务流程中发现服务；业务服务是对外提供的业务活动；从服务消费者的使用需求，不同的使用场景，不同的使用角色对服务的要求可能不同，将导致需要细分服务；从授权角度，服务包含的方法的范围将作为一个整体进行服务授权，过大或过小将导致服

32、务授权存在问题；服务从重用角度看，经常一起使用的服务，可能需要考虑服务的合并；从业务活动角度看，一个服务是一个业务活动，需要从完成一个业务活动的业务操作的完整性上来考虑服务的范围；服务的可替换性考虑服务粒度从四个角度考虑：服务范围；服务能力；服务数据和服务约束。服务设计原则：分为两类，包括主要导致实现具体服务设计特性的原则和主要用来塑造和控制如何应用其他原则的原则。主要导致实现具体服务设计特性的原则包括：标准化服务合约。实现一个标准化合约，以支持服务的运行时（被消费）一个服务合约可以包含一组服务描述文档，其中每个文档都描述了服务的一部分。例如，一个Web服务的合约可以包含以下的服务描述文档：1

33、）WSDL定义2）XML Schema定义3）WS-Policy描图：服务合约服务的可复用性。实现通用的合可复用的逻辑与合约服务自治。实现独立的功能边界和运行时环境服务无状态性。实现可适应的和状态管理无关的逻辑服务的可发现性。实现可交流的元信息主要用来塑造和控制如何应用其他原则的原则包括：服务松散耦合。最小化依赖关系服务抽象。最小化元信息的可用性服务可组合性。最大化可组合性组件依赖两个业务组件之间可能存在下图的依赖关系：采用依赖倒置的原则，组件应依赖于抽象，而不是实现。所以一个组件应只依赖另一个组件的public部分。在开发环境下，跨模块的组件依赖采用Jar包依赖的方式，业务组件之间的调用必需

34、是调用public部分的调用。关于组件间Public部分的循环依赖，有以下要求：1）原则NC业务组件间的Public部分尽量避免循环依赖，将循环依赖降至最低；存在Public部分循环依赖的业务组件必须提交设计评审；2）调整设计通过调整设计消除组件之间的Public部分循环依赖考虑是否可合并组件；考虑将一方的VO的属性/方法的参数改为弱类型，元数据中记录业务对象类型；将Public依赖改为实现依赖另一方的Public；考虑使用动态属性；3）如果考虑2）后依然不能解决存在的问题，可选择下面的编译方法：手工编译：假如组件A和B存在循环依赖：先将A的VO属性/方法的参数改为弱类型，这样B就可以编译；等

35、B编译过后，A依赖B的public 的jar包，A再将弱类型改为强类型进行编译，以后双方均依赖jar包进行编译；工具编译。编写辅助编译工具，将两个循环依赖的public部分的源码进行联编。产生这两部分的Jar包；注：组件Public 部分的循环依赖编译问题只存在于同时没有编译的情况。当编译后彼此只采用public 部分的Jar包依赖，此问题将不复存在JAVA程序编码规范平台采用JAVA作为程序开发语言，经过自身和大量用户使用过程中总结如下基本编码规范，如下：通用规则任何时候都必须遵照本规范的建议执行，除非你有更好或者特殊的理由，如果有请将它反馈给我们，我们将根据您的建议修改该文档，或者给您修改

36、建议。任何时候都不要将一些不相干的代码放到一个文件里，代码应该按照逻辑来组织保存在文件中。命名规则与约束一般规则所有的标识符都必须用英文命名。当对集合变量命名时，请使用复数形式，用以描述该变量是一个集合。命名const变量时请保持所有的字母大写，并且每个单词之间用“_”连接。不推荐：private const int Max_Account = 100;推荐：private const int MAX_ACCOUNT = 100;请使用大家认识一致的缩写，不要自己随意发明缩写，这样理解上会比较困难并且会产生歧义。不推荐：GetH()：H的具体含义请看下面的推荐方案UserInterface：这

37、里应该用缩写推荐：GetHandler()UI：大家都是知道UI指的是User Interface虽然private是默认的访问控制，但是建议不要省略这个关键字，请严格根据您设计的类的访问控制规约明确的给出是否使用该关键字。不推荐：public class SomeClassstirng s;推荐：public class SomeClassprivate string s;每个变量的声明必须占一行，避免一行声明多个变量。不推荐：private string s,s1,s2;推荐：private string s;private string s1;private string s2;请不要只

38、用大小写来区分标识符，请使用明确的语义。不推荐：private Bus bus;private Bus bUs;推荐：private Bus PublicBus;private Bus InternalBus;声明必须使用Java内置的类型，不要使用类型的别名（这些别名在System命名空间）使用object 而不是Object使用string 而不是 String所有的本地变量和参数都是用Camel Case（请参考术语定义）。推荐：private void SomeMethod(string someParam)string localVariable = “Example local v

39、ariable”;类和结构必须使用名词或者名词短语来命名。推荐：public class Carpublic class RedCar例外：如果是为继承的组件命名，则可以使用继承的组件名称以及扩展特性来命名，例如，从Button继承的ClickOnceButton。当一个类作为某个接口的默认实现时，请使用和接口相似的名称命名。推荐：public class Component:IComponent或者public class DefaultProvider:IProvider所有的接口必须使用I作为前缀public interface IMyInterface所有的局部成员变量都推荐用m_作为

40、前缀，其他单词部分遵循Pascal Case。变量的命名中请不要包含变量的类型信息（前缀后缀都不要包含）。不推荐：public enum GCCollectionModeEnumpublic class clsBuspublic struct RectangleStruct推荐：public enum GCCollectionModepublic class Buspublic struct Rectangle所有派生于Attribute的类均使用Attribute作为后缀，关于本条目可以参考微软所有的Attribute类的设计，都有这个潜在的约束在里面。推荐：MyCustomAttribut

41、e:Attribute始终使用具有描述特性的变量名而不是用类型命名避免使用单个字符作为变量名。例如：index尽量避免写成i，temp尽量避免写成t。例外：循环变量。不要使用缩写。例如：number不能缩写成num，缩写一定不要声明成public的，一定不要存在暴露给外界语义不明确的缩写。不要使用类型来描述变量不推荐：public void Render(int intValue); 推荐：public void Render(int Value);属性方法方法的命名必须使用动宾结构的短语。推荐：private void DoSomething()带有返回值的方法名称中必须有返回值的描述信息。

42、推荐：private State GetViewState(); / 这里返回的是一个状态命名空间请使用有准确含义的的命名空间，例如：单位.产品.模块.XX UAP.Portal.SubModule。推荐：.在类型、枚举、接口的命名上尽量避免和系统的同名。即使在不同的命名空间下，在使用这些类型的时候也可能存在定义不明确的问题。控件命名规则控件命名建议采用控件名缩写+英文描述的形式，下表为控件缩写对照表。控件类型缩写对应UF控件类型UF空间缩写LabellblUFLableuflblTextBoxtxtUFTextBoxuftxtButtonbtnUFButtonufbtnUFButtonNor

43、malufbtnnCheckBoxchkUFCheckBoxufchkCheckBoxListchksUFCheckBoxListufchksDropDownListddlUFDropDownListufddlImageimgUFImageufimgLinkButtonlnkUFLinkuflnkListBoxlbUFListBoxuflbRadioBoxListrblUFRadioBoxListufrblWebControlwebctlUFWebControlufwebctlPanelpnlUFPanelufpnlGridgrdUFGridufgrd代码风格代码风格约束编码时应该遵循的大多数

44、情况，这里描述的内容都是一般性的，通常情况下的，对于例外情况需要在代码中做特殊的注释说明。同样此部分内容依然遵循通用规则里面的第一条。基本布局任何时候不要将多个类放到一个源文件中，但是一个类可以分别放在多个源文件中。感谢微软为我们提供的部分类吧。任何时候一个源文件中只能有一个命名空间，也就是说在同一个源文件中不能存在两个不同的命名空间定义。按照下面的方式布局你定义的类。成员变量构造函数和析构函数（如果有）内部定义的类和枚举型等嵌套的内容属性方法如果是你自己写的代码，任何一个源文件的大小不要超过500行代码，超过500行的源代码阅读起来比较困难，可以考虑将他们按照功能分类，或者放到部分类中。任何

45、一个方法都不要超过200行，超过200行的方法通常情况下做的不是 一件事情，请将功能按照方法来划分，可以考虑使用重构的方式分解方法，请参考重构。正如通用规则里面描述的，一个文件里面不能超过一个以上的类，该文件 的文件名必须能准确的反应出文件保存的类，建议直接使用类名作为文件的名称。变量参数当给方法传递参数的时候，参数的个数应该限制在5个以内（包括5个），如果多于5个可以考虑使用结构将参数封装以后再传递。所有的私有成员变量必须放在其他成员的前面。也就是说私有的成员变量必须位于所有声明的最顶端。推荐：public class CustomClassprivate string m_Field1;p

46、rivate string m_Field2;/ 这里必须要有一个空行，用来区分代码块，增加可读性public void Method1()public void Method2()局部变量尽量在它第一次使用之前声明。请不要将局部变量的声明与使用它的地方相隔太远，不便于理解。不推荐：public void Method1()int nodeCount = 0;if(hasNode)nodeCount = GetNodeCount();if(nodeCount 10)/ Do Something推荐：public void Method1()if(hasNode)int nodeCount =

47、GetNodeCount();if(nodeCount 10)/ Do Something缩进规则行缩进请使用下面建议两种方式中的一种每个缩进用一个Tab（四个字符宽）每个缩进用四个空格不论采用何种策略，您的代码中始终应该保持唯一的一种风格。起始大括号的使用请遵守下面两种方案中的一种，请在您的代码中唯一的使用其中一种，该设置可以通过Esclipse的Option修改。起始大括号始终占一个新行。推荐：public class MyClass/ public void MyMethod()/ ./ 起始大括号在行的末尾。public class MyClass/ public void MyMet

48、hod()/ ./ 在使用匿名方法的时候，为了代码清晰，请使用下面的方式不推荐：delegate void SomeDelegate(string someString);void SomeMethod()SomeDelegate someDelegate = delegate(stirng productName)ShowString(productName); someDelegate(“wujian”);推荐：delegate void SomeDelegate(string someString);void SomeMethod()SomeDelegate someDelegate =

49、 delegate(stirng productName)ShowString(productName); /和delegate对齐someDelegate(“wujian”);代码注释任何时候注释的缩进应该保持和代码在同一个级别上。推荐：bool hasNode = HasNode(node);if(hasNode)/ 如果存在节点则为该节点添加新的子节点node.AddChildNode(childNode);/ 这里注释的缩进请保持和代码的级别一致所有的注释必须是清晰明确的。也就是说，注释能明确的解释代码的含义，请不要在代码中添加无意义的注释，绝对不要出现注释说明注释的情况，并且请确保没

50、有错别字。任何时候不要给看起来显而易见的方法添加啰嗦的注释，方法的命名，变量的命名应该尽量做到能自我解释，通常不需要对某个变量做特殊的注释。注释应该描述一些关于算法和变更日志的信息。建议使用/样式的注释，可以通过IDE的工具栏中的实现块注释。每个源文件开头的部分都必须包含文件的简要说明，并且嵌入#region#endregion。推荐：请参考命名规则于约束文件的相关内容。行注释必须在双斜线后面跟一个空格推荐：/ 这是一个标准的注释行/注释中始终应该包括，和。对于具体需要注释的内容请参照API模板文档对每种类型的要求。- add by hjf对于对外发布的类，接口，委托，枚举及其相关内容，必须采

51、用微软XML文档化注释，以便生成API文档。而不对外发布的内容尽量不要采用这种注释方法。- add by hjf尽量在需要的时候包含 和 ，效果不错。流程控制代码中一定不要出现goto语句，如果出现了一定是代码逻辑有问题，请仔细检查并使用合适的方法消除goto语句。避免在foreach里面修改枚举集合的内容。在for使用的引用型数组必须显式的初始化。所有的流程控制语句都必须保持语句块的清晰，以减少阅读上的困难。不推荐：if(b1)if(b2) Foo();else Bar();推荐：if(b1)if(b2)Foo();elseBar();所有的switch语句必须包含default标签。在sw

52、itch语句的default语句中必须添加Assertint busNumber = GetBusNumber();switch(busNumber)case 753:/ 开往回龙观break;case 443:/ 开往龙泽break;default:Debug.Assert(false); / 这一行是必要的break;else子句中的ifelse语句必须包括else部分，保证逻辑覆盖完整。请不要显式的判断条件的真伪，即不要显示的将bool值和true和false比较。不推荐：if(condition = false) if(condition != true) if(condition =

53、 true) = true = true) / 看着头晕推荐：if(condition)不论if语句或者else语句有多短，必须对其后的语句块使用大括号。不推荐：if(number = 1)return 0;elsereturn 1;推荐：if(number = 1)return 0;elsereturn 1;为了提高可阅读性，尽量避免非标准的，和复杂的条件缩写语句，虽然这看起来很Cool，但是可能其他人看起来会比较困难。避免一个条件语句中出现多个逻辑判断，如果必须这么做请将多个逻辑表达式赋值本地变量然后再使用本地变量进行逻辑判断。不推荐：if(条件表达式1 & 条件表达式2 | 条件表达式3

54、)推荐：bool condition1 = 条件表达式1;bool condition2 = 条件表达式2；bool condition3 = 条件表达式3;if(condition1 & condition2 | condition3)避免在条件语句中赋值语句不推荐：if(bus.Number = 753) = 443)推荐：bus.Number = 753;if(bus.Number = 443)不要访问在一个表达式里面改变多次的变量，虽然这看起来很酷，但是真的很难理解，这些看起来挺不错的优化编译器已经帮你做了，通常情况下你不需要这么做。不推荐：arrayi = +i; / 这里你是在给a

55、rrayi赋值还是给array+i 赋值i = +i +1;推荐：arrayi = +t; / 这里很清楚的说明你是在给arrayi赋值i += 2; 通用的缩写方式不但可以使代码简洁并且容易理解。不推荐：bool b1;if(val 0)b1= true;elseb1= false;bool b1;b1 = (val 0);推荐：bool b1 = (val0)? true : false;bool b1 = (val 0);避免将错误代码作为方法的返回值，方法是执行一个单一功能的逻辑单元，方法在语义上都有准确的含义。不推荐：public string GetUserName()tryret

56、urn DB.GetUserName();catch(Exception ex)return ex.Message;推荐：public string GetUserName()tryreturn DB.GetUserName();catch(Exception ex)throw;避免使用异常处理作为流程控制的一部分。不推荐：public Bus GetBus()tryreturn innerGetBus();catchreturn new Bus();推荐：public Bus GetBus()tryBus bus = innerGetBus();if(bus=null)bus = new B

57、us();return bus;catch(Exception ex)throw;JAVA WebService编码规范JAVA WebService作为SOA标准的核心实现方式，JAVA WebService 服务分为Server、Client 两部分，Server 公开Web 服务，Client 调用Web 服务，JAX-WS 的服务端、客户端双方传输数据使用的SOAP 消息格式封装数据，在后面我们会看到其实SOAP 信封内包装的就是一段XML 代码。支持主流的操作系统、中间件、数据库支持主流的操作系统包括Windows、Linux、unix等。支持主流的数据库包括Oracle、SQLSe

58、rver、MySql、PostgreSQL等。支持主流的中间件包括：中间件、WebSphere、WebLogic等。成熟的开发规范、模版平台提供完善的开发规范，包括：Java编码规法、应用开发规范、组件开发标准规范；提供移动开发相关规范；提供完善的业务开发模板；提供开发、移动、流程管理相关培训文档。详见附件：开发规范平台公共基础功能支持统一身份验证平台支持集成开发、支持普通的用户名/密码认证方式,以及支持 CA 证书、USBKEY 等多种身份认证方式多种认证方式、AD域认证完美集成UAP IDM提供统一的应用系统访问规范，支持多种认证协议或方式，加强访问方式的规范性、安全性。对内，向管控用户提

59、供单一的身份认证凭据；对外，提供身份认证服务。认证服务提供标准化、规范化服务，支持静态口令、AD域、数字证书、多因子、LDAP等多种不同强度的认证方式。UAP IDM提供与微软AD域认证完美适配，启动电脑可直接进入系统，无需手工输入用户密码认证。图：多种认证方式支持组织机构配置管理平台具有动态建模能力，可以对集团企业的组织、管控、流程等进行建模抽象，可以满足成长型集团企业的组织机构变化调整需求。1.企业结构与管控建模。实现对企业的组织地点的管理，这些地点可能或安装企业管理软件。支持针对企业结构建立企业管控的策略、模型及规则等。2.组织建模。动态组织建模功能支持企业组织变革、并购、重组。支持多级

60、集团和多组织建模，支持组织的多版本管理。每个业务单元可具有不同的组织职能，企业可以根据需要为业务单元设置其需要具有的组织职能。利用动态建模能力可以灵活的通过配置方式调整组织机构而无需修改代码，从而快速适应业务变化。丰富的通用组件开发平台开发了大量的通用技术组件，基于这些组件，可以大大降低开发成本，提高开发效率。通用组件包括：表单组件、列表组件、导航组件、打印组件、布局组件、流媒体组件、数据访问控制组件、安全处理组件等数百个组件。对于流程中间件，为了帮助快开发，提供流程树控件、流程跟踪图控件、流程跟踪列表控件、工作项领取控件、取消工作项领取控件、工作项执行控件、保存工作项控件、工作项代办控件、代