MoDoFo.println(”

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 – 对某些业务操作允许过一段时间再一致
“柔性事务” – [...]

摘自支付宝架构师程立的演讲ppt – SOA在互联网系统中的应用

SOA定义了一种体系结构
参考
来自：理解SOA体系结构中ESB场景和解决方案
SOA 适用原则：

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

…
为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个 服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是 ESB 的许多功能中的一部分。
…
ESB 有时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述为中心辐射型（hub-and-spoke）。然而，这并不是真正的差别。
…

两个时髦的玩意，原来就是一回事。并不是很难理解，只是大家习惯了接受各种各样新名词，而又惯性的没有去把二者联系起来。知道在wikipedia的SOA词条里看到这句话：
A mature rollout of SOA effectively defines the API of the organization.
任何系统无论是复杂的商用系统还是简单的个人博客，都在提供或多或少的服务。将这些服务分割成独立的，无状态的服务单元，然后通过HTTP（webservice）或者是其他的连接方式连起来。接下来，如何compose这些服务单元又是新的问题，ESB和BPM就大行其道了。将来有一天，用网站提供的OpenAPI进行网站之间的整合，互操作，信息交换一定会催生出更多有趣的东西。
中心思想：互联网和企业应用同样都需要整合，而且整合方向和方法应该都是一样的。
纯属YY

今天被一位兄台问起什么是SOA，虽然知道这个名词，但还是很老实的说不了解。既然不了解，那就再去尝试了解一下。SOA是针对企业架构（EA）或者整个IT系统网络。Webservice只是一个工具去把这些服务连接起来。另一个重要的工具是message，或者说的牛x一点 – message-oriented middleware，面向消息的中间件。message体现在哪里呢？
举个简单的例子，平时在写程序的时候常常说方法调用，这方法调用有两种形式，主动和被动。主动调用很简单就是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将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。