[转]为何不让SOA变得简单？
key words: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的定义中包含自动定位和发现服务（在大部分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实现上可用服务的组件注册表。
转自 这里
最近，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、生产者/消费者的组件模型。
![[转]为何不让SOA变得简单？_第1张图片](http://img.e-com-net.com/image/product/d699f4e8b6ea4d8aaf4a3efbf85a2b83.jpg)
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
![[转]为何不让SOA变得简单？_第2张图片](http://img.e-com-net.com/image/product/70fdeea7482343cab602461d1886c1f4.jpg)
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实现上可用服务的组件注册表。
![[转]为何不让SOA变得简单？_第3张图片](http://img.e-com-net.com/image/product/38309b235b7d417cabf9f2482c1c7a4d.jpg)
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的设计模式在JEE应用的各层上，告别是网页层。
那么我会为大多数JEE应用推荐哪 一个SOA实现呢？级别2上的SOA实现如带有MDB的JMS队列作为消费者，而POJO或无状态的会话Bean作为消息生产者。当然，如果你确信你需要 集成非Java应用,那么考虑一下Web services实现。还要考虑你现在采用的解决方案在以后要有足够的扩展空间。虽然预测多久通常都有争议的，但我还是建议最远不超过36个月。如果你预 见到那个时间段内有额外的SOA需求，那么现在就来构建吧。
关于作者
Humphrey Sheil是英国服务业企业级应用供应商CedaropenAccounts的首席技术架构师。特别擅长于集成领域。拥有爱尔兰都柏林大学的计算机科学硕士学位。点击这里进入他的博客。
资源
·Jini技术，最早的SOA实现之一:http://www.jini.org
·JEE规范:http://java.sun.com/j2ee/download.html#platformspec
·学习.Net的的入门点：http://msdn2.microsoft.com/en-us/library/ms310245(en-us,MSDN.10).aspx
·http://www.uddi.org UDDI协议
·创建SOA的准备：http://weblog.infoworld.com/techwatch/archives/004644.html
·Java业务集成，用来为Java应用（特别指基于SOA的应用）定义组件模型的规范。这更正规些，因此允许厂商根据标准提供工具和框架以实现最终的 交互性。目前许多失败就是因为缺少这些支持：http://www.jcp.org/en/jsr/detail?id=208
·http://ws.apache.org/axis/ 开源的JEE网页服务实现- Apache Axis
版权声明：任何获得Matrix授权的网站，转载时请务必保留以下作者信息和链接
原文:http://www.javaworld.com/
译文:http://www.matrix.org.cn/