经过多天的讨论和阅读,我们对SOA有了更深的理解。在这里我想谈一下OO和SOA设计方式的区别。
要更深入的理解SOA,理解它与OO思想的区别非常重要。SOA之所以成为趋势,正是因为它能够解决传统的基于OOAD的现有开发流程和表示法所隐含的一些缺陷。一个完善的SOAD首先需要满足的下面的条件:
l 正如任何其他的项目和方法一样,必须正式(至少半正式)地定义流程和表示法。通过选择和组合 OOAD、BPM 和 EA 原理,就可以在需要时确定额外的原理。
l 必须有结构化的方法来概念化服务: OOAD 为我们提供了应用程序层上的类和对象,而 BPM 具有事件驱动的流程模型。SOAD 需要将它们结合在一起。 方法不再是面向用户的,而是由业务事件和流程驱动的。用户建模是在更低的层次上作为第二步进行的。 方法包括语法、语义和策略。这就需要特别的组合、语义代理和运行时发现。
l SOAD 必须提供定义良好的品质因素和最佳实践(例如回答粒度问题)。必须回答 BPEL 提出的角色问题。例如,谁为哪部分工作负责:是开发人员、架构师,还是分析人员?
l SOAD 活动还必须回答这样的问题:什么不是好的服务?例如:不可重用的任何东西都不可能成为好的一流 SOA 成员(即服务)。另一个例子就是带有挑战性的非功能要求的嵌入式实时系统,它们不能承受任何 XML 处理开销。
l SOAD 必须易于进行端到端建模,并且有全面的工具支持。假如 SOA 给业务带来了灵活性和敏捷性,就应该对从企业到体系结构和应用程序设计领域产生的支持方法有相同的期望。
从上面可以看到,应该说SOAD是涵盖了传统的OOAD,它将OOAD与BPM和EA等技术组合并进行了扩充。我认为理解SOA的关键是理解如何划分服务,划分服务的标准和粒度。从某种意义上来讲,在OOAD中的对象与服务有这很密切的关系,这两个概念很难区分得特别清楚。在传统的设计中,服务的划分依照上面的标准,主要是考虑它的重用性以及划分方式给系统带来的灵活性。SOA中的服务不是一般的对象而是BO,Bussiness Object。在参考文献中说,服务是独立于流程的。于是我理解的服务是一个商业流程中本来就存在的东西。比如一个现有的ERP和CRM系统,即使没有流程,对用户和张单等的管理服务仍然存在于整个系统中,只不过是现有的商业流程没有用到它。这也就是为什么面向服务的架构比较容易扩展的原因,因为在良好的抽象下,服务在商业流程中的重用机会很大,所以当有一个新的流程的时候,也能很轻松的map到服务上,而这时有可能他需要的功能服务已经能够提供了,这样系统就能轻松扩展。所以我觉得服务是个商业概念,在商业流程中比较独立的,可重用性很高的单位。而一般的对象就不具备这种抽象,他们很有可能是只在某个特殊的流程中才会出现。
-magikid