SOA与API的分裂和统一

标签: soa api 分裂 | 发表时间:2014-11-25 17:06 | 作者:
出处:http://kb.cnblogs.com/

  英文原文: SOA and API Schism and Unification

  虽然API和SOA有着相似的商业和技术目标,许多API的支持者却坚持表示API与SOA几乎没什么关联,认为它们属于截然不同的方法。他们经常宣扬务实的REST API和SOA之间有着巨大的差异。分工限制了SOA服务和RESTful API无法干净利索地集成到一个统一的架构中。

  团队必须在SOA和API的观点之间建起一座桥梁,构建一个实际的规划去融合 API 和 SOA。

  “做REST”和“创建API”的团队通常的关注点是,以增量的外部扩展、具体的演示和不涉及复杂技术的核心业务用例来克服技术和业务的障碍。而SOA团队通常关注的是,获得扩展效率、达到商业标准、建立决策中心和满足复杂的非功能性需求。

  通过结合API和SOA的观点,当遵循商业策略和扩展需求时团队就能够迅速地交付业务解决方案了。

   务实的REST API关注点

  REST是一种系统开发的架构风格,它强制实行一系列服务交互的约束。正规的REST约束包括客户端-服务端和无状态的交互、可缓存的响应、不变的契约、分层的系统设计和按需编码。这些约束有利于特性的显现,也就是简单性、可扩展性、可变性、可靠性、可见性、性能和可移植性。满足REST约束的系统称为RESTful。RESTful设计方法能够增加许多的收益:

  • 使数据和服务更易于访问
  • 降低入门门槛
  • 尽最大可能扩展受众数量
  • 使API或服务被大量的用户代理消费
  • 使数据和服务逐步演进
  • 在运行期扩展系统
  • 对资源的修改不会影响到客户
  • 动态指导客户行为
  • 使系统可扩展、可靠和高性能
  • 简单
  • 可缓存
  • 原子性

  虽然RESTful设计有益于支撑SOA的目标,但务实的REST的战略关注点与许多SOA的举措不同。务实的REST API设计团队专注于自下而上的应用场景、友好的协议或格式(比如HTTP、JSON、DNS)、宽容的接口定义和简单的交互模型(比如在保证送达之上的重试)。

   务实的SOA关注点

  务实的SOA专注于面向服务的模式,该模式着重于增加软件资产的价值。基本的面向服务的模式是:

  • 共享和重用资产
  • 将冗余的功能固定到稳定的部件中
  • 使项目遵守公共标准和最佳实践

  应用这三种模式将减少IT环境的复杂度,带来更大的灵活性,比如,能够更加快速地构建应用、更加快速地修改以处理需求的变更。面向服务的模式推动开发团队去评估软件资产满足商业干系人需求的能力。

   务实的SOA最佳实践

  务实的SOA团队不强行推进公共(而且复杂)的标准。务实的SOA团队提供有价值的商业能力、降低应用的阻力并交付独特的服务价值。

  务实的SOA团队不鼓吹难以操作的最佳实践。他们依靠团队间的传帮带和自动化的治理以简化最佳实践的应用,这使团队可以更轻松地做正确的事情。

  务实的SOA团队会留意技能差异和应用的障碍。他们提供加速器包(比如架构、工具、框架和API或服务构建块)减少培训、增加自助服务的应用,以及加快项目的交付速度。

  务实的SOA团队会平衡企业治理与项目的自主权。而不是竖立开发和注册门槛,成功的团队引入若干机制去改进服务、间接的交互、硬性服务水平并促进自助服务的应用,通过引入这些机制使团队促进服务的开发、服务的共享和服务的应用。你可以把这些机制当成现有API管理的核心。

   务实的调和

  REST与SOA是不同的,虽然它们并非格格不入。服务可以成为RESTful,RESTful资源也可以成为服务。像SOA一样,REST是由一组设计原则定义的架构规程,REST还强制施行一组架构约束。REST使用以资源为中心的模型,这与以对象为中心的模型截然相反(比如,通过资源来封装行为)。在REST中,你感兴趣的每件事物都是资源。当进行RESTful服务(也叫作API)的建模时,以一组资源来封装和暴露服务的能力。

  因为SOA所呈现的架构目标状态通常与目前遗留的IT资产是有一定差异的,所以SOA是一个漫长的架构之旅,而不是一种短期实现。因为API使组织内外的业务能力相互连通,所以API能够为商业干系人提供一个平台,使他们可以在其上发起企业IT革新以及实行务实的业务。

   什么时候去创建服务或者去创建API

  当正要创建一个同时包含SOA和REST的统一架构策略时,下一个合乎逻辑的问题是:什么时候去创建服务或者去创建API呢?从消息传递的观点来看,服务和API有相似的属性。它们都是可访问的的网络终端,通过访问交付数据或触发事务。从架构的观点来看,服务和API都提供了分离关注点、创建松耦合解决方案的机会。许多架构师和开发人员都想要随着API一起扩展他们面向服务的架构(SOA),但并不清楚什么时候去创建服务或者去创建API。

   什么时候创建服务?

  作为一个可访问的网络终端,一项服务是一项已经发布的业务或者数据。当团队要 网络域或运行期应用共享业务能力或业务数据时,创建服务。

  服务应当实现一个适当自动化的业务任务,不应该设计成与其他组件交互的精细化组件。当服务暴露了业务流程中的一项独立任务时,开发人员和业务分析师更喜欢去获悉服务的目标。以业务任务的粒度去设计服务,减少服务的交互复杂度,简化应用的维护工作。举一些适合于面向服务的方法的业务任务的示例,它们包括“提交订单”、“检索客户记录”以及“缴费”。

   接口与实现分离

  服务封装了特定的实现,服务终端通常在服务与后端业务逻辑之间有一个一对一的关联关系。服务应该通过多种接口风格(比如面向资源的、发布/订阅的、方法调用的)暴露业务能力或数据。为了最大化有效性和范围,服务实现应该通过多种消息协议(比如HTTP、JMS、MQ)和消息格式(比如JSON、XML、CSV)去发布可访问的接口。

   RESTful 是一种接口风格。这种网络非常适用于移动应用、瘦JavaScript客户端应用以及跨网络和所有域的bash脚本访问函数。

  理想情况下,接口风格不仅是详细的解决方案,还是重要的管理特性(比如安全性、服务层的强制实施、用法跟踪等),在所有接口风格(比如面向资源的、发布/订阅的、方法调用的)中这些特性都是有效的。图1展示了外观模式,连接了一个单一的服务实现和多个消费者:

图1:API外观模式

  内在表征与外部契约和外部协议的分离,肯定会影响随着时间去演变服务实现的能力。当从已有的实现中清晰地分离出接口时,开发人员就可以修改其实现而不会影响到使用该服务的应用调用了。

  然而,从共享的应用平台消除消费者和提供者的耦合,以及从实现中消除接口耦合都会增加额外的关注点。例如,如果试图使操作语义(比如身份、服务层、授权)跨不同的平台和分布式环境无缝地流转,那么难度就增大了。团队依靠中间件基础设施去桥接跨所有参与者和组件的语义。

  因为从实现中分离接口引入了复杂度和额外的工作量,许多团队把接口紧紧地绑定在实现上。通过下述的架构最佳实践,并引入API外观或代理终端(使用自动化开发),团队可以增强解决方案的可维护性和适应性。

   什么时候创建RESTful API?

  RESTful API是一种与服务实现互补的接口风格。可在以下时机创建RESTful API,当要共享控制领域(比如业务单元、组织)之外的服务时,当以扩大影响范围和消费群体为目标时,当要提供跨本地web基础架构的服务时,或者对服务端、接口和实现的不对称演进极其感兴趣时。

  如果开发团队发布已有服务前的API外观,他们要从服务的实现中分离出服务的接口。API端点是实施安全、监控使用和流量整形的轻量级代理。代理使消费者接口合约和后端服务的实现可以清晰地分离。

  当应用服务器、企业服务总线节点或者数据服务主机可以发布API端点的时候,API网关是由API传送机制优先管理的。托管的API是:

  • 可主动发布和订阅
  • 与相关已经发布的服务级协议(SLA)一起有效
  • 安全的、已认证的、已授权的且受保护的
  • 通过分析可监控和可货币化

   服务接口或RESTful API接口

  RESTful API与服务是不一样的,虽然它们并非格格不入。服务可以成为RESTful,RESTful资源也可以成为服务。像SOA一样,REST是由一组设计原则定义的架构规程,REST还强制施行一组架构约束。

  RESTful API接口是服务接口中一个有约束的子集。RESTful API暴露面向资源的接口,理想情况下符合HATEOS(超媒体作为应用程序状态引擎)。RESTful API发布资源为中心的模型,它与对象为中心的模型相反(比如,行为是以资源来包装的)。在REST中,感兴趣的每样“事物”都是一个资源。当对一个RESTful服务(也叫做API)建模时,服务的能力作为一组资源进行包装和暴露。

  去创建一个RESTful API:

  1. 为所有事物指定“ID”
  2. 将所有事物链接在一起
  3. 使用标准HTTP方法
  4. 允许多种消息格式的表述
  5. 减少共享的状态

  新兴的API设计工具将帮助你把一个服务实现转换成一个RESTful API。

相关 [soa api 分裂] 推荐:

SOA与API的分裂和统一

- - 博客园_知识库
  英文原文: SOA and API Schism and Unification.   虽然API和SOA有着相似的商业和技术目标,许多API的支持者却坚持表示API与SOA几乎没什么关联,认为它们属于截然不同的方法. 他们经常宣扬务实的REST API和SOA之间有着巨大的差异. 分工限制了SOA服务和RESTful API无法干净利索地集成到一个统一的架构中.

SOA资料学习

- - 人月神话的BLOG
从对象到组件,首先可以把对象理解为更细粒度东西,而组件是更加粗粒度的模块,对象更多关注技术,而组件应该更加关注业务. 前面我们谈过技术组件和业务组件,在SOA思想下业务组件化的思想就更加重要. 组件本身而言很简单,南向接口和北向接口,或者再有底座平台支撑. 接口通过服务方式来实现,组件通过OSGI等技术实现高度的解耦和可热插拔性.

SOA架构咨询

- - 人月神话的BLOG
对于SOA架构咨询,其核心还是在于组件化和服务化,然后才是服务管控和治理,基于服务化思想对传统软件开发生命周期过程的改进. SOA架构大家刚接触时候很容易将其理解为一种单纯的技术架构,或者更多的人仅仅是将SOA理解为service服务接口,这些都是对SOA方法论很大的误解. SOA咨询一个重点就是业务驱动IT,而非单纯的IT架构咨询,SOA咨询一般都会结合企业架构和云的思想,结合组件化架构和领域服务的思想,高层结合BPM端到端流程整合目标,并对这些内容进行有效的融合.

Api Blocking

- - xiaobaoqiu Blog
4.RateLimiter实现限流. 接口限流是保证系统稳定性的三大法宝之一(缓存, 限流, 降级).. 本文使用三种方式实现Api限流, 并提供了一个用Spring实现的Api限流的简单Demo, Demo的git地址: https://github.com/xiaobaoqiu/api-blocking.

从流水程序到SOA

- Allen - 阿朱=行业趋势+开发管理+架构
咱就从函数代码开始谈起,更史前的Goto和汇编代码咱就不谈了. 函数和变量写多了,自然也就发现有些函数和变量互相粘在一起很高耦合,而与其它的一些却没多达关系,于是为了显性化让其他的开发人员知道哪些函数和变量确实关联性很紧密,于是创造了类. 面向对象在80年代的国外代码开发界颇为流行. 但接口思想的风潮在90年代刮起了.

eBay开源SOA-Turmeric架构

- - 人月神话的BLOG
参考: https://www.ebayopensource.org/wiki/display/TURMERICDOC/Turmeric+Documentation+Overview. Turmeric是一个综合的、由策略驱动的SOA平台,提供了对SOA服务及其消费者的开发、部署、保护、运行和监控等方面的支持.

SOA面向服务架构

- - 人月神话的BLOG
今年在这点上谈的比较多,也逐步开始落地实施,将SOA咨询和实施方法论从系统间真正的引入到系统内,将面向对象的需求分析方法和SOA思想进一步融合,从业务建模到系统用例建模,从流程分析到服务识别和分析,从业务组件化到系统模块化,这些工作都逐步开始落地实施. 这样做的好处就是进一步的体现SOA可复用组件的价值,真正的做到业务组件化和组件能力化.

[SOA] Mule ESB Linux 部署

- - CSDN博客架构设计推荐文章
本文介绍如何在 Linux 上部署 Mule ESB. Mule 是一个以Java为核心的轻量级的消息框架和整合平台,基于EIP(Enterprise Integeration Patterns,由Hohpe和Woolf编写的一本书)而实现的. Mule的核心组件是UMO(Universal Message Objects,从Mule2.0开始UMO这一概念已经被组件Componse所代替),UMO实现整合逻辑.

集成ESB实现SOA

- - 企业架构 - ITeye博客
  服务消费者,服务提供者, 服务注册中心(UDDI模型). 由于UDDI模型过于复杂,而服务提供者与消费者点对点的进行协作依赖性大大增强,因此产生演变.    服务代理 -- ESB.    基于ESB总线,使得服务请求者统一入口,而ESB管理服务,使得耦合降低,由ESB来应对提供者提供的服务的改变而服务请求者不需要进行任何的修改.

SOA实施收益分析

- - 人月神话的BLOG
远行科技自2007年开始即参加了中国移动集团SOA接口平台的建设和实施工作,在SOA规划咨询,建设实施方面有丰富的实践经验积累. 对于SOA实施收益,先以某客户的一个真正业务背景进行分析:. 业务场景:我们现在的工程项目管理,其规划,立项和工程实施计划在项目管理相关系统;工程物资采购在采购管理系统;审批在 OA系统,财务的信息又在ERP核心系统.