注意我在定义中引用了设计模式。我认为这是关键。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环境，那儿硬件预先计算的以便在定义用户数据和服务性能之间平衡。
文章来源于领测软件测试网 https://www.ltesting.net/
