为何不让SOA变得简单？

核心提示： 最近，SOA成为跨技术平台（非凡是J2EE和.Net）软件开发中的热门话题，为何不让SOA变得简单？，然而，假如我们比较一下围绕着SOA的宣传和90年代后期EJB和服务件的宣传，从而支持其他技术如.Net 点击查看大图Figure 2. Schematic illustrating

　　最近，SOA成为跨技术平台（非凡是J2EE和.Net）软件开发中的热门话题。然而，假如我们比较一下围绕着SOA的宣传和90年代后期EJB和服务件的宣传，你会发现这没有什么区别。1998年，EJB带领互联网的潮流并推翻了以CORBA的统治和由PB/Oracle Forms和其他主导的CS架构标准。SOA，作为一种新技术的术语，还不具有那么大的破坏性。SOA只是一种想法/概念和一组构建应用功能的最佳实践。相反地，J2EE是一套完整地开发技术，可以用来设计所有的东西。

　　我对SOA的主要关注在于企业级java应用通用的问题：复杂性。次要关注的是SOA通常作为一种解决方案被用来跨越J2EE应用各层，虽然这似乎没有什么意义。本文提取出SOA的基本元素并介绍他们。一旦我们理解这些，就可以理解SOA系统中的更复杂的组件了。最后，我们可以了解一下SOA给J2EE应用带来的实际价值，同时并不增加无用的复杂性。
本文分为个部分：首先，提出了我对SOA作为一种标准参考点的定义。其次，检查那些主要的软件工种问题通过SOA可以解决而不是用SOA来检查。再次，会给出基于复杂需求的SOA的建议分类。最后，给出三种主要SOA分类的建议实现。

　　SOA是什么？

　　SOA有很多定义。下面是我的定义：
　　SOA是宏级别的应用到应用架构级的设计模式：
　　1、可选地暴露应用的功能作为一组离散的组件。
　　2、使这些组件能被用来构建更复杂的组件和应用。
　　3、仅包含基于消息的组件内部通讯。

　　我还遗漏了什么呢？还有一些方面，包括：
　　1、安全性
　　2、事务
　　3、状态或无状态会话
　　4、消息无数据
　　5、 消息特性
　　6、 消息协议
　　7、 消息内容
　　8、　具体技术实现

　　这些方面也是重要的，但不是主要的。我的定义提取了SOA的核心规则，但没有抛弃概念本身。
注重我在定义中引用了设计模式。我认为这是要害。SOA不是什么新技术，事实上，其最吸引人的一个地方是可以利用现有的技术并使其泛出新的光线。对我来说，SOA更像是一幅蓝图，一组最佳实践，或者说是一个定义下一代的软件应用应该如何设计和实现的规范。

　　基础SOA方法

　　从上面的定义，我们应该可以标识出组成SOA应用的必须提供的软件服务的最小集合。简洁地说，这些服务是：

　　1、消息层，答应消息通过特定的协议传输和接收。用SOA的说法，这一层称为企业服务母线或简写为ESB。
　　2、一个组件模型，如应用必须遵循的发送和接收来消息母线的消息的最小约定。

　　取决于你自己的业务需求，这两种服务可以极度的扩大，但在核心来说，消息层和通用组件模型就代表了SOA。

　　注重，我没有在SOA的定义中包含自动定位和发现服务（在大部分JEE场景中，这是很有杀伤力的）。在UDDI（通用描述/发现/集成协议）后的原始想法是认为企业最终会使用软件服务（通过一个大的基于元数据搜索服务仓库）来购买和销售。这个美梦至少也得十年后，也许永远不会实现，因为人们是需要做的实际的业务而不是软件。

　　JEE应用不需要自动发现服务，例如登录或支付服务，这些服务应该在初始化时设置。不要误导我，假如这些服务的实现不应该硬编码到应用中，那么你也不需要SOA来解决这些问题了。

　　下一节，我们会来考虑一下究竟需要SOA来解决什么，或者他能替代什么。

　　为什么要SOA？

　　最近的两拨企业级软件开发的主浪潮是C/S架构和多层架构。虽然多层架构提供了C/S架构中布署/平台支持/性能/伸缩性上更好的效果，但两者都没有解决一个要害的企业级计算机领域的软件工程问题：如何重用软件功能。作为软件开发人员和架构师，我们始终没有完全解决软件重用的问题。再往下看，你会看到我也不认为SOA能解决这个问题。然而，我认为软件重用是SOA出现的最重要原因（至少在JEE应用中是这样）。

　　其他SOA使用现有的Jini和风格计算。基于Jini环境的特点如下：
　　1、自动发现组件/服务
　　2、自愈的

　　然而，这些特性并没有与JEE应用等同的重要性。使用JDBC配置数据库的位置只需要一次。我期望数据库来提供容错和除错功能，而且我不需要JEE应用来尝试当产品实例当机时自动发现其他的数据库实例。另一方面，对一个有2000个工作站的办公室来说自动发现一个彩色打印机是一件好事，这也是符合Jini硬件的一个要害好处。

　　平等地主，在一个真实的全球网格计算环境中，自动发现和枚举计算资源来解决问题是基础框架的要害部分，但这不是一个JEE环境，那儿硬件预先计算的以便在定义用户数据和服务性能之间平衡。

　　我的观点是，SOA对不同的需求需要不同对待。在本文中，我只关心JEE架构方面的SOA，而我认为这意味着功能重用。其他从JEE观点来看SOA的优点还有：
　　1、松耦合的组件，这是软件设计中重要的部分
　　2、引入ESB作为消息层意味着强制“面向接口编程，而不是实现”
　　3、异步消息增加了应用的伸缩性

　　让我们通过问三个特定的问题来看一下软件重用中更细节的问题：
　　1、为什么重用软件是重要的？
　　2、SOA是如何提出解决软件重用问题的？
　　3、是否SOA的允诺能够使软件重用应用到现实中？

　　首先，软件重用是重要的原因如下：
　　1、时间和花费上的效率—能够重用已经的组件来满足陈述的业务需求将节省大量的时间和金钱。
　　2、重要的特性包括但不限于如稳定性/性能/可治理性/文档/可配置性。因为一个组件被重用的次数越多，对这个组件的投资也越多，他的优势也越多。
　　3、 良好设计的可重用框架无论在哪里被使用都拥有正面的效果，而且你愿意的话可以封装更好的想法来解决通用问题。

　　因此我们需要重用性。那么最简单的方法是什么呢？就是打包软件作为一组良好定义的组件来满足离散的功能需求。然后，假如其他应用需要相同的组件，他就可以重用了。还有些细节需要考虑，如如何配置，但这些细节已经偏离了主题：重用任何语言编写的代码，那些代码必须被设计成一组离散的组件或重构为集合。

　　可以参考我在JavaWorld上的第一篇文章，“节省时间的框架”（2000.9），有更多细节善于JEE项目的软件重用。

　　其次，SOA是如何解决软件重用的问题呢？是通过基于组件模型来构建和引入一个重要的强制约定：组件间的通讯要通过下发到ESB的消息来进行，而这就确保了松耦合。实际上，最广泛布署的SOA实现—Web services可以通过使消息层技术中性来缝合用不同语言开发的组件。

　　最后，SOA对软件重用的允诺真有实际意义吗？不，我想念假如SOA在1945（大概是和ENIAC同时代吧）被发明的话确实可以解决软件重用的问题。但没有，现存的大量代码是用不同的开发语言编写的，有COBOL/C/C++http://java.chinaitlab.com/C#和其他语言。这些代码没有作为离散的组件来编写，因此也没有SOA魔法来解决。事实上，我认为有大量的SOA项目的工作是花费在重构相同的代码库。

　　现在，让我们来看一下对于JEE应用SOA可以解决的一些问题。

　　SOA缺点

　　SOA缺点包括下面三方面：
　　1、 SOA自身的缺点，主要当前还没有成熟的实现
　　2、 SOA的复杂性
　　3、　厂商对SOA在更广泛的JEE产品和方案中的位置

　　那么我们就心批判的眼光来看一下：

　　·并没有像JEE规范那样有自己的正式规范。虽然有一个发布的规范，但那个太复杂了并且没有遵循80:20法则（80%的应用需要简单的SOA，只有20%的应用需要更强大而复杂的功能）
　　·有状态会话依然存在广泛争议而且现在还没有被SOA的缺省实现（Web services）所解决。而无状态会话已经是完全支持了。
　　·由于缺省正式或推荐的规范，Web services已经成为许多人眼里SOA的代名词了，但Web services通常是过于强大了。
　　·SOA增加了复杂性。可能你更喜欢硬编码和紧耦合，而不需要xml配置文件来运行简单的应用。
　　·SOA兼容的应用对本身来说没有什么意义。其商业价值来自于能够提供离散的功能块通过SOA被用于其他的应用和模块。例如，假如你对订单的较验规则是通过jsp页面中的Java代码来实现的，那么你还需要重构代码将其放到服务端对象中以便于SOA调用—但很多厂商并没有提及这一点。
　　·在某些情况下，厂商将SOA作为网页应用框架的替代者！我认为，WAF是SOA定义功能中的消费者，只是作为一种补充，而不存在竟争关系。
　　· 与厂商提供的相反，一些应用根本不需要SOA而只需要简单使用MVC框架就可以了。这很短视吗？我不这么认为，即使SOA的特性是需要的，在上面的情况下，最重要的部分是用来服务于企业服务总线的良好定义的业务逻辑层，而不是ESB自身。

　　虽然我不认为SOA是一颗解决现有和新建应用中问题的银弹，便我相信SOA在他相应的位置上还是有其内在的价值的。现在让我们来看一下在应用中增加有效的SOA解决方案是如何提供体现其商业价值的。

　　建议的SOA分类

　　现在，你应该对我保持事物的简单性的热忱表示感激吧。但我本质上并不是简单论者，我是一个实用主义者。对软件项目来说，我认为实用主义是一方面要平衡项目的商业和实际价值，另一方面是使用软件设计上的最佳实践。简单的说，就是在我们现有条件下构建我们所能创建的最好的系统。

　　一个实用主义的好例子来自于民间的工程历史。在修铁路时常修木桥，而我们知道用铁桥会更好。当铁路公司的股东想使用铁路尽快开工而且初始投资要有限制时，他就是这是最好的工程方案了。是否听起来耳熟？同样的原则可以应用于软件工程。

　　根据实用主义的精神，我建议将SOA分为三个级别：简单/中等/复杂，衡量标准是需要满足的业务需求。假如你需要简单的SOA，那么不要浪费时间和金钱在复杂的SOA上。

　　级别1：简单的SOA

　　样例实现：
　　1、使用自己的POJO队列实现来发送和接收消息。
　　2、带有MDB（消息驱动Bean）的JMS队列/主题作为消息的消费者。

　　这里涵盖的要害SOA概念有：
　　1、企业服务总线
　　2、生产者/消费者的组件模型。

点击查看大图

　　Figure 1. Schematic illustrating the core components of the simple SOA. Click on thumbnail to view full-sized image.

　　级别2：中等的SOA

　　样例实现：
　　1、带有MDB的JMS队列/主题作为消息的消费者，并附加其他特性如安全性/事务/JMS元数据属性等
　　2、 Web services，例如Apache Axis

　　这里涵盖的要害SOA概念在包含简单SOA外还有：
　　1、用来增加健壮性和可靠性的错误/重试队列。
　　2、引入XML作为消息的有效负载内容来代替序列化Java对象，从而支持其他技术如.Net

点击查看大图

　　Figure 2. Schematic illustrating the core components of the medium-complexity SOA. Click on thumbnail to view full-sized image.

　　级别3：复杂的SOA

　　样例实现：
　　1、带有MDB的JMS队列/主题作为消息的消费者，并附加其他特性如安全性/事务/JMS元数据属性等
　　2、Web services
　　3、厂商/标准相关的SOA兼容工具包（如专门的金融服务）

　　这里涵盖的要害SOA概念在包含中等SOA外还有：
　　1、良好定义而且严格的组件模型（例如Java业务集成/服务组件架构及其他）
　　2、增强的厂商支持，如可插拔的新生产者/消费者组件创建
　　3、 具体枚举特定SOA实现上可用服务的组件注册表。

点击查看大图