2、控件访问：允许调用者在IDE（集成开发环境）中开发Web应用、门户、工作流和Web服务时使用访问服务控件；

3、Web服务访问：允许访问服务作为Web服务进行发布，以便于被任何使用标准WSDL和SOAP接口的调用者访问；

4、SQL/JDBC访问：通过SQL/JDBC接口，访问服务以关系数据库表的形式被访问，参数化的访问服务以存储过程的形式被访问。 6.3.3 数据服务

（一）数据服务通过调用访问服务访问企业的各种数据资源。 （二）数据服务设计原则包括但不限于：

1、数据访问和业务逻辑处理必须清晰地分离，数据服务通过访问服务从各种数据源收集和返回相关的数据；

2、数据在企业范围内流动与共享，其准确性、一致性、完整性应由数据的生成者保证；

3、数据服务应与南方电网企业信息资源规划定义的数据模型保持一致，使得数据在应用层面具有语义标准化的特性，便于复用；并保证数据使用者与生成者的松耦合，使得数据源模型变化不会影响到数据的使用者；

4、当需要进行大批量的数据复制、移动或转换时，允许将批处理作业的控制操作发布成一个数据服务，而大量数据的批处理操作仍然采用ETL或专用接口等效率更高的方式来实现；

5、当数据服务需要交换大量数据时，允许通过FTP或消息中间件（可提供数据压缩、传输安全、分组传输、缓存等高级功能）以附件的形

式进行交换。 6.3.4 业务服务

（一）业务服务是指满足特定业务处理需求的服务，业务服务包含一个或多个业务处理功能，业务服务包含的业务功能数目决定了业务服务的“粒度”以及可重用性。业务服务的“粒度”大，则服务集成成本低，但业务服务的可重用性也低；业务服务的“粒度”小，则服务集成成本高，但业务服务的可重用性也高。业务服务的“粒度”应该在服务集成成本与服务可重用性之间取得合理的平衡。

（二）业务服务设计要求遵循但不限于下述原则： 1、业务服务操作是非长时间的动作；

2、业务服务表达一定的业务逻辑和业务规则，并具有完整业务事务处理的功能； 3、业务服务安全的认证和授权等控制逻辑必须与业务逻辑分开； 4、事务处理必须在服务内部完成，事务不能跨越服务的边界； 5、业务服务的操作重复执行时其结果是相同的。 （三）业务服务是管理与决策应用功能的基础，业务服务设计应保证业务服务能力的高可用与高性能等质量要求。

（四）业务服务除了满足其所在的业务职能域的业务处理功能外，还应同时考虑便于满足集成跨业务职能域的业务处理功能的需求。 6.3.5 流程服务

（一）流程服务封装完整的业务流程或独立定义的子流程，流程服务设计要求遵循但不限于下述原则：

1、所有需要保存服务调用之前的状态和调用结束之后的状态，并最

终向客户应答的服务，都应该设计为流程服务；

2、流程服务的状态在任何一个时间点都应该是能够监控的； 3、流程服务可以长期处于运行状态，可涉及到人工工作流，并包含多个原子事务； 4、流程服务遵循BPEL，BPMN等规范。 6.3.6 综合服务 综合服务分为两大类：

（一）以提升企业综合管理职能为导向的、基于业务系统的跨系统、跨业务管理职能域、跨单位的组合服务，这类综合服务可由访问服务、数据服务、业务服务及流程服务组合而成。

（二）以企业价值链为导向的、基于数据仓库综合分析功能而封装的跨业务管理职能域、跨时间过程域的服务，这类综合服务一般由各类综合分析模型功能封装而成。 6.3.7 展现服务

（一）展现服务处理应用信息的表示，服务体系所有底层的服务都可以通过展现服务暴露给最终用户使用。

（二）展现服务必须将数据和其表现格式区分开。

（三）展现服务包括：企业信息门户中可配置、可重用的门户组件，用于支持门户应用的开发；以及人机交互组件、网页组件、报表组件等，以实现对不同客户接入方式的支持。

（四）展现服务可以集成商品化的前端展现工具，以满足丰富、灵活的客户端展现需求。 6.4 服务实现

6.4.1 服务封装原则

（一）服务封装是SOA服务实现的手段，服务封装将应用系统可重用的功能或数据“剥离”出来，对外以相关的接口方式以及约束这个接口的契约提供给消费者调用。接口和契约的定义是中立的及基于标准的，并独立于实现服务的硬件平台、操作系统与编程语言。 （二）服务封装必须遵循包括但不限于下述原则：

1、无状态原则：最大限度减少服务管理的状态信息的内容以及状态的期限； 2、单一实例原则：避免功能冗余； 3、接口定义原则：使用WSDL定义服务接口，使用WS-Policy描述服务契约，使用XML模式 （Schema）定义服务交换的消息格式（即服务的公共数据）。服务消费者依赖服务契约调用服务。服务定义必须相对稳定，修改必须通过审核批准；

4、自包含和模块化原则：服务封装的是那些在业务上稳定的、重复出现的活动和组件，组成服务的功能实体是完全独立自主的，可以独立进行部署、版本控制、自管理和恢复；

5、粗粒度原则：服务粒度指抽象级别或者服务包含的功能。确定服务粒度时需要考虑性能需求，以及未来可能进行的更改对服务实现的影响。应尽可能使用粗粒度模式隐藏其中的细粒度服务，这样有利于将服务与其实现的更改隔离开来。服务数量太多会带来服务管理的复杂性；

6、松耦合性原则：服务消费者使用服务接口调用服务，服务的位置、实现技术、当前状态以及服务的私有数据对服务消费者是透明的；