三个话题 - 应用，系统，平台

soa规划
应用级：pojo，当团队更大，重新组织。应用级内部面向服务的问题 - 通过组件平台
企业级：系统之间的集成，支撑平台：bpm,esb,epm。企业服务库
产业级：变化快，更好的协同。作为服务提供者和协调者

application object -- facade（策略+决策）-？
business object -- manager（能力+操作）

spring帮助我们解决了关注点的分离

pojo编程模型 - validator的例子，todo：思考

组件模型抽象：
对象 - 操作和属性
组件 - 更多：生命周期，服务，扩展点，属性

交易流程 - 流程引擎组件

OSGi - java动态模块规范
bundle - 部署单元（模块）

既要引用模块化组件引入，又要让开发人员适应这种组件开发
spring dynamic modules
每个bundle独立的上下文-bean factory
只有允许发布服务的应用才可以被引用

三者的整合

jvm - 开发的场景
组件支持层 - 组件支持模型

交易支持不同交易方式 - 作为插件

安全可靠 -》互联网，用户需求，行业需求变化快

三层结构中，服务集成是最核心的部分，也是最难的部分
怎样把握服务内容以及抽象，从而更容易集成是目前我们有待解决的问题

《服务仓库》 -- 不是很明白
从组件到服务，首要是组件模型的搭建，如果搭建好，自然很容易的国度
甚至可以对开发人员是透明的 - -我们目前可以做到吗？应该不可以

具体的例子《服务@alipay》
多个系统的协作
请求交易核心 - 创建交易
想银行集成平台请求，组装请求报文给银行请求划拨
银行向账户充值
银行向交易核心确认
支付宝内部的账户更新
返回商户平台
商户平台发出通知

在这样的规模（1秒以下）是可以做到的。

业务整理的过程
达到产品和业务核心的区分，核心全部通过服务完成

支付宝整合方式 - ESB企业服务总线（mule开源实现）
我们用esb做了什么？

<服务总线应用@alipay》
统一的事件封装和元数据模型，通过事件机制达到很好的协调

业务分布，数据分布 - 难题 - 事务

事务ACID -》BASE
BA - 业务处理主题必须是可用的，其他的可能不是可用的
交易，资金处理必须可用，消息发送可以不做，或滞后做

Soft state允许业务有偏出 - 只要不是关键部分
E - 对某些业务操作允许过一段时间再一致

“柔性事务” - “补偿性事务”

在大的业务里，对子业务进行区分，有些可以允许时间稍微晚一些，比如会计分录和交易通知
处理一致性的方法 - TCC模型
转钱的例子：1.完成检查，钱是否足够 2.预留钱
cancel或者confirm完成

有了服务的支持，通过协调框架完成协调 - 可以满足每天上千万的处理要求

第三部分：
生态圈的服务

企业内部服务化

开放平台，和合作伙伴更好的协同，超越企业的边界
传统网关方式三种：不需要讲
1.表单post
2.web rpc
3.异步通知

mashup - 太远了

• 利用显式的与实现无关的接口来定义服务 - 达到异构环境的交互
• 利用强调位置透明性和可互操作性的通信协议
• 封装可重用业务功能的服务的定义

...
为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个 服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是 ESB 的许多功能中的一部分。
...
ESB 有时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述为中心辐射型（hub-and-spoke）。然而，这并不是真正的差别。
...
毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束——有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可能更适 合于部署在本地群集中，以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是 ESB 设计的一个重要方面。另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。
...
最被普遍认同的 ESB 定义的原理：

• ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。
• SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。
• ESB 可以作为分布式的异构基础架构进行实现。
• ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

来自：ESB在SOA体系中的功能定位
在SOA体系中，ESB被当作一个集成平台来将企业各种各样的软件资产服务化。这种服务化即将各种各样的私有技术以现代开放，标准的形式暴露为服务供SOA体系中的更高层次（如业务流程管理BPM）使用。
...
本质上说，SOA需要ESB为服务提供者和消费者之间提供中介服务。ESB作为服务提供者和消费者之间的中介，能够对服务消费者屏蔽提供者位置，协议等技术细节，从而在有多方参与的企业应用集成场景下能够更加灵活并能适应变化的集成服务的调用方与提供方，比如，提供者位置（end point）变化时对服务消费者完全透明。而且，ESB也常常充当服务集成的统一平台，在其上统一多个被集成方的调用协议，通讯方式以及消息语义（统一消息模型），使得其上层（North bound）服务调用者如BPM流程可以以单一且一致的语言与下层（South bound）实现各种各样的会话。
围绕这中介代理这一核心功能，ESB应该具备的具体能力有：
(1)完善的服务组件模型，包括服务组件的编程模型
ESB应该提供定义统一，明确的服务组件模型，所有软件功能都被封装成服务组件。只有这样才能够实现服务之间的松耦合组装。
(2)松耦合链接服务调用者与提供者的组装模型
ESB应该提供独立的服务调用者与提供者的松耦合组装模型。这里“独立”，“松耦合”指服务调用者与提供者的连接关系完全由组装模型定义，对于调用者与提供者的内部实现逻辑完全透明。
为了实现调用者与提供者的具体连接关系对服务实现透明，消息路由，服务提供者寻址（包括分布式服务寻址），以及必要的数据转换，数据填充，同步/异步通讯模式转换等中介功能需要由ESB的组装模型提供而不需要调用者与提供者实现逻辑关心。
(3)支持多种接入方式，通讯协议转换。
包括对服务调用者提供多种调用协议，以及能够连接使用各种私有传统接口的服务提供者
...
作为SOA体系的支撑平台，ESB将成为整个架构中核心的服务使能者（Service Enabler）。因此需要ESB在提供核心中介服务的基础上，具备下面的扩展功能特性：
(1)安全——ESB需要提供认证，授权，加密等安全功能保证ESB上的服务被安全的调用，以及ESB可以以服务提供者需要的安全机制调用提供者。
(2)与服务注册库的无缝集成——可以有效的使用服务注册库提供的服务管理功能。
(3)简化开发，部署的能力——如提供图形化的开发工具，集中的提供分布式部署能力的部署工具等。
(4)监控与管理——提供必须的ESB运行时监控与管理能力。
(5)高性能，高可靠性——ESB需要是一个高性能服务中介引擎，同时必须提供足够的高可靠性保障机制。
...
从ESB的发展历史看，ESB并不是天生和SOA密切相关的，他反而更多的是由企业应用集成（Enterprise Application Integration，EAI）的需求发展而来。
...
从SOA体系的层次结构来看，我们愿意给ESB设定一个相对狭义的功能范畴，即ESB只为SOA上层构件提供透明的，标准的下层功能实体的服务化封装。而将封装好的服务进行业务编排进而实现各种业务集成功能是SOA体系中ESB之上的构件实现的，其中可以是BPM，各个ESB产品的服务编排功能等等。
...
BPM方式的优势在于：在业务服务已经被封装并能被业务人员理解的前提下，BPM提供业务人员可以理解驾驭的图形化建模手段来编排各种业务服务构成新的标准化的业务流程。BPM的引入可以有效的提升业务人员对IT系统的参与，进而实现业务主导的集成应用快速开发和随需应变。同时，BPM实现目前已经有成熟的标准支持，使用BPM实现的集成功能实现对具体产品的依赖相对较低。因此，BPM是业务层面应用集成的有力支撑技术之一，在有人工介入的长时间流程方面，其更是唯一的选择。但另外一方面，BPM实现的集成应用在运行效率方面则不如另外两种编排方式。

来自：SOA需要ESB吗？
与企业应用集成(EAI)产品一样，ESB也负责转换及发送消息。ESB厂商对自己的产品是否基于标准非常重视，目前大多数使用Java消息服务(JMS)或者某种专有的消息传送协议，目的是为了提供必要的可靠性。
...
支持者喜欢ESB是因为ESB让他们可以配置服务、管理服务之间的联系。经历了好几年没有ESB的日子后，工资单处理服务市场的巨擘ADP公司最近采用了分布式ESB，因为“很难维护大批一对一的消息传送适配器”
...
Intuit公司集成架构解决方案 部门的首席架构师Martin Moseley说，ESB适用于需要编制的长时间运行流程，譬如订单处理。在这种流程中，各步骤必须按某种次序来进行，而且整个过程都要进行验证。譬如， 在计算运费或者批准使用信用卡之前，订单流程可能需要验证顾客的地址(原因是验证信用卡往往需要地址); 只有完成了所有步骤，才可以发送货物清单。Intuit的订单处理系统就使用这样一种仲裁服务方法。
...
也有人认为ESB只是改头换面的 EAI而已，他们认为ESB有悖于SOA的开放性。伯顿集团的分析师Anne Thomas Manes认可使用ESB配置服务，甚至把细粒度服务编制成可广泛访问的粗粒度服务，但抨击了总线作为传送所有服务的网关这一概念，尤其当ESB消息的来 回传送带来额外开销时，她更是觉得不能接受。

A mature rollout of SOA effectively defines the API of the organization.

任何系统无论是复杂的商用系统还是简单的个人博客，都在提供或多或少的服务。将这些服务分割成独立的，无状态的服务单元，然后通过HTTP（webservice）或者是其他的连接方式连起来。接下来，如何compose这些服务单元又是新的问题，ESB和BPM就大行其道了。将来有一天，用网站提供的OpenAPI进行网站之间的整合，互操作，信息交换一定会催生出更多有趣的东西。

中心思想：互联网和企业应用同样都需要整合，而且整合方向和方法应该都是一样的。

纯属YY

举个简单的例子，平时在写程序的时候常常说方法调用，这方法调用有两种形式，主动和被动。主动调用很简单就是A.call(B)，这种调用很常见，但是有一个问题 - 它是同步调用，也就是在这个调用过程中程序不能做其他事情，直到调用结束。另一种被动调用，有点像是事件监听响应的意思（设计模式里的观察者），调用形式如： A.notifyListeners->[queue]->B.onEvent，或者也说异步调用，解决常见的并发问题。

那么webservice就用来定义一个统一的接口，主要是主动调用，而message queue则是用来被动调用时发送消息。SOA的目标（猜得）：所有的应用系统都被设计为对外提供服务的一个个节点，节点之间要么通过主动调用发布消息（webservice），要么通过message queue发送相应来自其他节点的消息。

SOA是从整个IT系统网络的角度去考虑分布式系统的整合，重用，优化。另一点要提到，通常的应用系统之间的webservice调用都是无状态，因为“有没有状态”不是SOA要解决的问题，而是工作流来解决的吧（也是猜得）！

面向服务架构SOA（Service-Oriented
Architecture）是一种架构模型和一套设计方法学，其目的是最大限度地重用应用程序中立型的服务以提高IT适应性和效率。它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
SOA的关键是“服务”的概念，W3C将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。