笔记 – SOA架构
SOA在互联网系统中的应用
三个话题 – 应用，系统，平台
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 -》BASEBA – 业务处理主题必须是可用的，其他的可能不是可用的交易，资金处理必须可用，消息发送可以不做，或滞后做
Soft state允许业务有偏出 – 只要不是关键部分E – 对某些业务操作允许过一段时间再一致
“柔性事务” – [...]
