我对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环境，那儿硬件预先计算的以便在定义用户数据和服务性能之间平衡。
文章来源于领测软件测试网 https://www.ltesting.net/
