12 月 5 日，Todd Biske张贴了一个 Gartner 应用体系结构开发与集成高层会议的摘要。这个会议讨论了 SOA 的资助问题。
从基础设施，技巧和组织变动上来看，面向服务架构的足迹令人生畏。值得注意的是， REST 社区正试图通过最大限度地减少成本和最大化利用表现层组合能力来解决这个问题。
一项在 Web 上的快速搜索表明，极少有与资助SOA 相关的话题。这个话题几乎像个禁忌一样很少有人提到。
Todd 报道说， SOA Consortium 资助调查的初步结果表明：
启动 SOA 项目的方式多种多样。其中一些利用一个 SOA 程序，还有一些希望服务开发能脱离现有项目。
以 [他] 的经验，[他] 从未遇到过一个以 SOA 为唯一目的的资助项目。 [他] 经常致力于一些商业项目和程序，它们希望能够把服务作为他们成果的一部分。
Todd 评论说，虽然有可能解决初期的资金问题，但是进行中的 SOA 的资金仍然经常是一个问题。
该小组随后讨论了度量指标：
没有 [度量指标] ，我们怎么能说明我们已经完成了一些事情了呢？为了展示我们更敏捷，[以及我们更具生产力的的开发解决方案] ，我们需要指标来衡量事情目前如何，未来会如何。
目前也有关联服务消费的度量指标：消费者数量，消费者使用率，最小 / 平均 / 最大响应时间等等。以我自己的经验，仅仅使这些度量指标可用，并使之达到一个比 Web 应用的入口点更精细的粒度水平就已经是非常有益了。
小组的第三个话题是服务的所有权。Todd 评论到：
听到其他人说基于项目的 IT 文化会阻碍 SOA 的成功是很棒的事情。
如果你没有一个独立于客户的服务拥有者，那么每个客户都会尽可能的把事情推向对他们的项目有最大利益的方向，但却没有人会拥有自己的服务。这种内耗对 SOA 非常有害。
最后一个话题是服务组合管理（SPM）。Todd 比较了服务组合管理和应用组合管理，并建议尽早把重点放在服务组合管理，以避免因应用组合管理的不足造成混乱。在他的观点里：
如果有人说，他们暂时还不需要注册 / 仓库是因为他们还没有达到“临界规模”，这实在是犯了一个潜在的大错。
总体上讲，这方面的讨论说明，无论您选择了什么技术，与传统解决方案（打包或者定制）相比，服务的“形式因素”在 SOA 中的变化至少有三个层面：
- 项目管理：一个服务实施项目比一个典型的解决方案要小，然而它需要有严格的项目管理能力，这会在服务实现的顶层增加开销
- 一致性程度：企业层次的服务一致性程度远远高于一个典型的解决方案。一个成功的服务实施需要许多业务的代表理清他们的需求的主次以及路线图。
- 资金和所有权：这往往被划到项目领域之外。按照既定的进度安排、路线图和资金可能会造成交叉业务单元的冲突。
理解如何最有效地应对这一新的 IT 领域的形式因素很可能是值得的。因为有些人，如 Dave Frankel，SAP 实验室标准体系架构的负责人，认为 SOA 范式为支持新世纪正在兴起的主导性业务做了很好的调整。
查看英文原文： Funding SOA
译者简介：王锐，曾就读于西安交通大学，目前在北京航空航天大学计算机系攻读博士学位，主要从事新型网络体系结构方面的研究工作，曾经在多个平台下进行过企业级软件的开发，并有嵌入式软件开发经历。关注 SOA 和 P2P。您可以通过 rui.wang@jsi.buaa.edu.cn 与他联系。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论