技术专家谈SOA——转载

一篇引用了Brenda Michelson的blog的文章，其中谈到“SOA的难点”。这些难点是由应用基础设施厂商的企业实践者和领导地位的思想家，技术专家而非市场人士指定的。这篇文章认为厂商正试图掩盖以下这些问题的存在。

　　下面分别介绍了这三个问题，并且提出了一些潜在的解决方案。

　　1. Service Definition 服务定义

　　很多企业发现很难决定业务服务的正确边界(工作和任务)以及粒度(协作)。而正确性是由可重用性和灵活性决定的。业务服务应该在服务流程中，跨流程服务甚至有些情况下在企业级别上进行重用。业务服务还应该能很容易的改变(替换、增加、组合)，以满足业务需求。

　　企业在创建服务时总是犯错误，粒度不是太细，就是太粗。通过服务协作，细粒度的错误依然可以重用，但是在实际工作中会造成性能上的低效率。而粗粒度的错误带来了与用户相关的服务，而不是通用的业务服务。

　　2. Semantic Understanding 语义理解

　　对于人与机器的结合，语义总是一个难题。尽管接受信息(对话、消息、数据交换)还显得相对容易，但理解发送者的真实想法就不那么容易了。例如，在用到“customer”一词时，它的意思是最终用户还是消费者呢?

　　随着应用和业务之间的信息交换变得越来越常见，产业界和公司的用语被用来定义常用的术语、语法以及信息元素的含义。这些术语的最初目的(技术集成)是由技术专家来定义并管理的。于是，很多术语由于出自应用和信息领域，显得不太好懂，并非一种真正的业务语言。

　　有了SOA，语义理解的需求变得更强烈了，因为不同的服务需要交互，而且面向服务的语言的自描述性质也需要描述服务、合约、策略以及编排。

　　3. SOA Program SOA程序

　　SOA程序的目的是要说清并执行懂得你业务的一个SOA策略。通常的活动包括普及SOA思想、建立并推行标准(技术、方法)，选择应用的基础设施和工具，建立通用(面向服务)的服务，建立样例工程以及编写服务手册。

　　架构师、技术领导和业务解决方案项目领导认为最大的困难在于部署SOA必须在架构需求和业务项目自然属性(按时、预算内)之间作出权衡。

　　显然，最简单的办法是给你的架构团队一个良好的开始。比如，足够的资金、员工、以及在业务项目前三个月到六个月开始工作等等。越是关键的业务项目，就越要提前开始。

　　你是怎么想的呢?SOA架构看上去好像一颗银弹，但是一些Ms. Michelson列举的问题却被掩盖了。她的分析有道理吗?厂商如何做才能更好的解决这些问题?