剖析服务交付平台

  • Jean-Jacques Dubray
  • 胡键

2007 年 11 月 24 日

话题:SOA架构

软件即服务(SaaS)正获得业界的认同。在上周发表的一篇文章中,Frederick Chong(来自微软的架构战略团队)和他的同事详细描述了软件交付平台的能力

他们辩解说,独立软件提供商(ISV)常常从基于客户特定需求由他们的专业服务组织来处理的部署进化到:

……这些软件厂商自制的托管解决方案……[其中] 服务交付组件,如计费、计量和日志由应用厂商构建,并集成到应用组合中。

他们将这种情形比作开发者似乎不得不要书写操作系统级别代码来处理“多任务”或“虚拟内存管理”的时代。

当 SDP(译注:服务交付平台)在商业可用性上能与操作系统和数据库引擎一样的时候,软件厂商就能更关注于核心应用开发任务,这样就减少了投入市场的时间和成本。

这篇文章从访问控制、单点登陆和身份管理,到订单管理、计量、计费,到应用租户入驻和支持基础设施(呼叫中心和系统)详述了 SDP 的能力,。

他们声称,一个 SDP 应该暴露一个 SDK 来帮助 ISV 进行应用设计,这样就能最大限度利用 SDP 能力。他们特别推荐 SDK 实现依赖注入模式:

……进一步在应用开发和操作性任务间分离关注点

以下是他们总结的 SaaS 托管行业的动机和原则:

  • 考虑到托管行业的激烈竞争,托管商自身会进行分化和优化,这是通过在一个共享的软件服务交付平台中巩固和利用他们现有托管环境中的多种组件来实现的。
  • 通过采用一个共享的 SDP,软件服务提供商可以订阅一个更有效利用成本的软件交付平台,尤其是在他们能遵循由他们的 SDP 托管商制定的服务交付指南,并在共享的基础设施的限制中运营的时候。
  • 软件厂商的 SaaS 托管决策并不总是二元的,可以是混合的,通过一个在完全依赖一个共享 SDP 到完全自托管区间选择中的连续集就可实现。

Fred 和其他人(如Gabriel Morgan)都建议从电信行业学习经验,该行业已经基于故障(Fault)、配置(Configuration)、计费(Accounting)、性能(Performance)和安全(Security)管理发展了一个管理框架(FCAPS)。

查看英文原文:Anatomy of Service Delivery Platforms

SOA架构