三个话题 – 应用，系统，平台
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 – 太远了
Comments are closed.