服务元素
面向服务的架构根据不同类型有不同的区分
1.服务
2.服务组合
3.服务目录
4.面向服务的企业
SOA的定义
1.一组与面向服务计算相关的战略目标
2.这些目标代表了明确的战略状态
3.面向服务是一种范式，它为实现目标状态提供了已证实的方法
4.当我们面向服务应用与软件设计时，我们所构建的逻辑单元就是“服务”
5.面向服务的解决方案包括一个或是多个服务
6.为构建成功的面向服务的解决方案，我们需要一个分布式技术架构，它具有一些具体的特征
7.具有这些特征的技术架构就是面向服务，就是SOA。
概念详解：
1.服务：对外暴露服务契约，自身承载核心服务逻辑的单元
2.面向服务：一种用来创建解决方案的逻辑单元的设计范式，逻辑单元是单独设计的，便于组合和重复使用
3.服务目录：在某个边界之内独立进行标准化和管理的一组辅助服务，该边界表示一个企业或是企业的部门。通常是自顶向下的交付流程而创建的。
服务设计的原则
服务的展示形式上：
1.服务抽象：只包含服务契约中的必要因素，对于服务相关的信息只在于服务的契约上
2.标准化的服务契约：双方基于契约进行通信，对于契约之外的信息一概不负责，例如不维护双方的一些通信信息，契约化的编程风格。
3.服务的无状态：无状态能保证服务的三个优点
3.1 可见性：客户端和服务端都不保存对方的详细信息
3.2 可靠性：服务能够容易的从失败回复
3.3 可伸缩性：因为无状态，服务端可以很轻松的释放资源。
4.服务的可发现性：通过服务自带的元信息，可以很轻松的发现和查询服务，就是语义化的编程由于参数类型化
5.服务的松耦合：只要体现的是接口隔离，要求自身与周边环境解耦。
服务的组织形式上：
1.服务可重用性：服务包含并表达无关性逻辑，并且可作为可重用的资源。
2.服务的可组合性：无论组合的大小和复杂度，服务都是有效的组件装
3.服务的自治性：服务对底层执行环节实施高层控制。这点理解的还不是很深。
服务模型：
1.任务模型：它的功能上下文是关联的，具有单一目的上层业务逻辑控制，通常需要封装和组合其他服务的组合逻辑。实际例子：针对用户在不同阶段的推荐，在个人中心、商户页、首页都会出现
2.实体服务：一种可重用的服务，它的功能上下文是无关的，通常与一个实体或是多个实体进行关联。实际例如：用户实体，包含用户的基本操作。
3.公用服务：可重用，功能上下文无关，需求并非来源于实际需求。实际例子：日志，安全，缓存等。
服务相关的粒度
1.服务粒度：代表服务的功能范围，也可以认为包含业务逻辑的多少
2.能力粒度：单个服务能力的功能范围，例如getDetail服务能力比getDocument具有更细的粒度
3.约束粒度：校验逻辑的细化程度，就是契约化编程的要求粒度
4.数据粒度：所处理数据的量的大小。
服务粒度就决定了服务的功能范围，所以服务粒度通常在服务契约设计之前的分析和建模阶段就已经确定了。
服务的粗和细都是相对的。
服务概要：记录服务在整个生命周期中的详细信息的文档
1.服务目录的蓝图定义 — 服务目录
2.服务建模 — 候选服务
3.服务契约设计 — 技术文档
4.服务逻辑设计
5.服务开发 — 服务规范
6.服务测试 — 测试用例
7.服务部署和维护 — 服务水平协议
8.服务的发现 —服务注册库
实际的构建案例
1.web 服务层主要同任务服务和实体服务交互，用于访问主机系统的信息并执行业务逻辑单元。
2.具体的任务服务和实体依赖一些公共服务
3.安全方式基于集中式的处理，所有请求的鉴权通过统一的服务接口。
SOA的设计模式
只是简单的枚举了些，具体还需要看后面的章节。
0 条评论。