业务SOA=SOA。技术上的SOA仅仅是SOA服务的部分技术。我们清晰地看到这样一种趋势，技术性SOA的领土正在被越来越多的业务SOA实施所占领，而且更多的智能技术解决方案取代了业务中非智能的人工操作。智能技术解决方案成本高昂，因为这些解决方案仍旧和庞大的非智能技术解决方案相关联，假如这些解决方案没有或者只有很少的业务价值，那么在全球将消耗数十亿资金。

　　这种成本的关键因素是IT专家的毅力，他们仍旧试图用不适当的统一抽象的技术编程工具合并业务信息。甚至更糟糕的是，IT人员（更确切的说是那些软件厂商的软件工程师）给予这些编程工具业务称号，从而导致了这种“荒诞的循环”。被这种“荒诞的循环”围绕着的其他开发者在正确的引导下对错误的项目花费了数百万来适应技术。而且，很显然，最终失败了。下面是最近一些已经形成的“荒诞的循环”：

　　Web服务：该项技术并没有从事服务，只是服务于接口，而且那是Web执行非必需的部分。

　　SOA：面向服务架构，已经由不同的技术所替代，而这些技术并不需要提供任何面向服务，无论如何，用架构的概念什么也做不了。幸运的是，这个元素的“荒诞的循环”已经打破，SOA领域的许多人已经断开技术政治论的理念。

　　BPM：没人不知道这个术语前两个字母的意思，那么后面呢：BP管理、度量、监控、建模或者头痛。无论如何，IT相信如果能够自动化人工操作活动，并作为一个程序运行，它就是业务流程管理的真相（忽略了另一个因素，即当人工操作活动被程序取代时，业务流程同其管理是非物质化的）。

　　我不认为自己是唯一一个认识到人类智能和技术编程工具之间的桥梁是语义技术的人。最近有一篇文章，Vasudevan Ramanujam发布的《集成和SOA中的语义技术》，给我们的思想提供了很好的积累，并且例举了语义技术的巨大业务价值。

　　虽然该文章列举了数个基于语义方法的技术领域所获得的好处，但我更关注SOA。作者从两个层面概要了如下的“面向服务架构附加值”：

• 服务创造
• 服务定义
• 服务编制
• 服务管理和治理

　　此外，服务接口的语义方面被描述为：

• 知识接口描述
• 接口关系描述
• 数据/参数转移描述
• 转换描述
• 现有数据注释

　　我认为“服务构造”和SOA服务领域的接口应该也是作者所描述的“两个层面”。然而，“接口”群要求一些注释。这些注释基于文中所描述的用户和系统转那个关于语义的接口之间的角色分离，尤其是：

• “管理员/用户最初创建服务描述，这些服务描述将被转化成原来的三倍并存储于存储库中。这些服务的关系也将被创建。”
• 管理员添加上下文/关键字/描述/含义
• 系统发现以最初设置和语境为基础的服务
• 系统也将发现服务关系
• 系统可以推论语境和关系
• 系统将能够添加基于服务使用模式的语境，来语境化服务
• 用户将可以发现和使用服务后端接口，如果频繁使用，将由系统来完成。

　　因此，采取上述的服务的语义方面，我想问一下什么是“接口关系描述”？如果这是关于接口之间的关系，我尚不了解，很有兴趣深入研究。如果这是关于接口和服务之间的关系，我找不到任何与语义相关的内容，现有的服务接口可能重新解释内部服务，但是为何这样的解释应该由预定义本体论来驱动呢？我认为服务的业务性功能足够约束服务接口和本体之间的语义变化。

　　对我而言“数据/参数转移描述”和“转换描述”之间的区别并不明显。我并不认为语义定义数据转换了自身，尽管转换目标对于和语义相关的工作来说是明确的目标。而且“现有数据注释”是不重要的陈述，没有语义注释的数据也没有业务价值。此外，SOA 服务并不是处理数据的，甚至是数据服务，SOA服务只同数据语义、元数据工作。物理数据模型属于实施，不属于服务架构。相同的数据价值对于不同的SOA服务可能有不同的语义。因此，数据语义或者注释在SOA服务中是先天假设的特定数据。

　　至于文章中的角色和智能列表，我想说的更多。

　　首先，服务描述可能仅仅通过管理员描述，而且早SOA环境中绝对不会由“管理员/用户”创建。服务描述文档通常仅由服务提供者创建（根据OASIS SOA标准）。用户只有一个选择，采用湖综合忘记它。尽管用户要求服务使用确定的策略，但这些策略可能包含在服务合同中，而不是服务描述中。然而，服务提供者可以考虑用户的需求，再单独更改服务描述修正服务。

　　如果我们探讨服务注册库和存储库，管理员可添加“上下文/关键字/描述/含义”到记录中。但是“上下文/关键字/描述/含义”仅由服务提供者来定义。

　　我并不理解短语“系统发现以最初设置和语境为基础的服务”。什么叫做“系统发现”？为什么系统需要知道服务？它是服务消费这的一个任务吗？而且，服务语境或者OASIS SOA更准确地定义了这个，服务执行语境必须包括在服务提供商保证的服务描述和有关的服务条款中。因此，我看不到语义在此的作用。

　　“系统也将发现服务关系”这句话也超出了我的理解范围。这对于服务消费者和/或服务提供者到底是什么意思？当很多案例中，这些关系只是服务消费者知识的一部分（用服务的调用的特殊组合来描述），系统如何理解服务关系呢？如果我们探讨预定义使用中的服务的总和，这个只是属于服务，不属于服务运行时环境，也就是系统。因此，我也看不到语义在此的作用。

　　“系统将能够添加基于服务使用模式的语境，来语境化服务”把所有的事情都“头朝下”。系统不可能添加服务执行语境（添加给谁），因为它就是服务执行语境本身，服务是形而上学的，从来不管系统的能力。用户实际上可以按需改变“服务使用模式”，转变“多用”为“重用”模式。然而，本例中语义中的相关改变完全属于用户，不属于系统和服务。

　　“用户将可以发现和使用服务后端接口，如果频繁使用，将由系统来完成”是因为系统可以理解服务的语义吗？就算这是正确的，为什么我们需要使用这个系统的理解力呢？如果服务是OASIS SOA服务，即面向服务应用，我认为它应该能在后端管理自己；如果后端是数据源，也应该有另外的服务在业务数据和数据源使用数据模型之间进行翻译。这个例子中的语义最主要的，毫无疑问，但是它不属于系统。

　　在我的《通向SOE的阶梯》一书中，我探讨了语义SOA 如何协助实现服务消费者和服务功能和服务结果的提供者之间相互的服务消费者，在现实世界中意味着使其达成一致。与以往的这个作用是从技术SOA 到业务SOA 的基石。下面有一个例子：技术SOA 促成服务实施中的改变，与服务消费者不相干，直至服务接口也已由固定的不变的消费者使用为止。实际上这在业务SOA中是不正确的，业务功能由服务提供，即功能由服务实施实现，这要比服务接口有更多的价值。换句话说，服务实施中的改变（后者对于业务服务的消费者仍旧是透明的），影响了服务中业务功能构成的改变。这种变化会通过服务消费者打破服务契约，尽管所有的接口是一样的。这直接关系到服务描述和服务契约的语义，从而影响服务之间的交互。

　　面向服务环境促进企业中数据语义的共享。服务描述的语义对于服务消费者来说必须足够清晰，为了确定是否使用特殊的服务。这并不意味着消费者必须在业务服务交互中使用这个语义：消费者和提供者可以使用业务处理或者服务交互在转换中介离线问题上达成一致。

　　如果要我举一些语义成为SOA 的关键因素的例子，请看下表：

• 服务定义、建模和设计
• 服务描述查看
• 形成服务契约
• “服务管理和治理”
• 服务聚合/编制
• 服务更改控制和维护
• 服务注册库和存储库
• 通过流程和业务对象进行服务实施
• 在业务服务的人工和自动化部分之间集成