最近，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环境，那儿硬件预先计算的以便在定义用户数据和服务性能之间平衡。

[1]  [2]  [3]  [4]