为何不让SOA变得简单？ - 军军小站|张军博客

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

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

　　为什么要 SOA ？

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

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

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

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

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

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

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

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

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

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

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

SOA 缺点

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

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

· 并没有像 J2EE 规范那样有自己的正式规范。虽然有一个发布的规范，但那个太复杂了并且没有遵循 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 实现上可用服务的组件注册表。

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

　　小结

　　目前 SOA 是作为一种架构体现，也将会成为与 C/S 或多层架构一样存在。但是，他目前还是不够成熟而且只是作为厂商利用的工具。我对 SOA 的建议是，从简单的做起并保持 SOA 尽可能的简单。不要将 SOA 与 Web services 等同起来，也不要强制使用 SOA 的设计模式在 J2EE 应用的各层上，告别是网页层。

　　那么我会为大多数 J2EE 应用推荐哪一个 SOA 实现呢？级别 2 上的 SOA 实现如带有 MDB 的 JMS 队列作为消费者，而 POJO 或无状态的会话 Bean 作为消息生产者。当然，如果你确信你需要集成非 Java 应用 , 那么考虑一下 Web services 实现。还要考虑你现在采用的解决方案在以后要有足够的扩展空间。虽然预测多久通常都有争议的，但我还是建议最远不超过 36 个月。如果你预见到那个时间段内有额外的 SOA 需求，那么现在就来构建吧。

为何不让SOA变得简单？

更多文章、技术交流、商务合作、联系博主

微信扫码或搜索：z360901061

微信扫一扫加我为好友

QQ号联系： 360901061

您的支持是博主写作最大的动力，如果您喜欢我的文章，感觉我的文章对您有帮助，请用微信扫描下面二维码支持博主2元、5元、10元、20元等您想捐的金额吧，狠狠点击下面给点支持吧，站长非常感激您！手机微信长按不能支付解决办法：请将微信支付二维码保存到相册，切换到微信，然后点击微信右上角扫一扫功能，选择支付二维码完成支付。

【本文对您有帮助就好】元

2元

5元

10元

20元

自定义