开源与商业化软件厂商，在SOA领域各有强项，何者是适当的选择，得视企业应用的层面决定。笔者将SOA的应用分成三个面向来看：企业应用系统整合、IT架构与商业运作校准、与产品开发。

　　SOA整合应用系统，保障既有投资

　　这是运用SOA架构思维最简易的方式。通常企业会导入中介软件ESB，作为协议异质系统讯息的媒介。更进一步，ESB可汇集各服务端点，透过流程汇编的功能，将基础服务汇编为功能更复杂的业务服务。

　　将SOA解决方案应用于整合企业应用系统，最有利于保障既有投资。透过引入开源ESB，系统的整体架构可采用渐进的更新手法：逐步将既有应用系统内部的功能转为服务揭露出来，再一步步透过ESB加以整合。

　　在整合的过程中若发现缺少某个配方，再到开源社群采药。例如缺少传输层，就加入Axis或XFire作为系结组件;若想善用POJO提供服务，就加入Spring Framework作为服务引擎;要是效能不佳，那么就再加入一些实体节点，而这些完全没有商业软件授权费的问题。

　　而开源项目在企业应用整合仍有不足之处。由于各系统在设计之初并没有经过统一的考虑，可能各系统中存在着重复的功能(例如客户关系管理、企业资源规划或项目管理系统中，均可能具备连络人名单管理的功能)，因此，仅靠ESB整合后的IT系统，并非最佳化的系统，而且散落于各系统的信息也难以同步。

　　因此长远来看，导入ESB之后，仍要朝下一个目标「IT 架构与商业运作校准」前进，将整个企业的IT架构转换为SOA模式。

　　IT架构与商业运作校准

　　这是导入SOA架构的终极目标。要将SOA的应用提升到此一层级，通常会依照厂商所提供的方法论规画与导入。例如建立商业能力模型与IT服务能力模型，由上而下地找出支持企业核心流程所需的服务，作为未来调整与修正的蓝图，然后依此蓝图逐步完成建模与建置。

　　“IT架构与商业运作校准”是商业化软件厂商SOA整体解决方案的强项。就许多开源SOA解决方案来说，相对的比较无法找到相关教育训练或顾问单位。笔者认为，以当前的情势要在企业内透过开源项目SOA项目达到此一层级，将面临较大的挑战。

　　以SOA架构产品，建置松散耦合的模块

　　对软件开发厂商而言，在授权条件许可下，我们可将SOA架构概念用于开发自有产品，促使系统更加模块化、产品模块间的耦合更为松散。产品内部松散耦合的好处，在于开发厂商可以提供客户更多样的部署选项。当客户挑选好需要的模块后，厂商才开始封装产品。

　　另外，还必须提供一些机制，让系统内的功能可以动态开放，以服务的方式呈现，使其它系统能更易于与此产品互动。

　　应用SOA在产品开发有两派观点：画分组件实作层次与服务流程组装层次

　　透过这种方式，组件的实作与服务的开放便成为两个层次。我们可以依照过去习惯的开发方式，以 POJO+Spring Framework或是EJB实作服务组件，然后将流程汇编的工作交给ESB的BPEL或Script引擎处理。

　　对于既有程序代码，只需想办法开放它的服务接口，就可以纳入ESB统一管理，如此便可以有效保障既有开发成品及技术投资。此时你可采用Mule ESB或ServiceMix作为主架构，组件化过去的产品，立即得到所有系统整合上的便利性。

　　将SOA概念作为服务组件的模型

　　将SOA概念作为服务组件的模型，也就是说，不论是组件的实作与服务的组装，均采一致的架构。当前支持此套思想最彻底的组件模型，当属IBM与 BEA等几家大厂共推的服务组件架构(Service Component Architecture，SCA)，而开源的实作则为Apache Tuscany及Fabric3专案。

　　透过SCA服务组件架构，开发者可以很容易地设定服务与组件之间的对应，以及服务与服务间参引关系。

　　透过SCA服务组件架构，我们可以很容易地设定服务与组件之间的对应，以及服务与服务间之参引关系。将SCA的概念与模块设定文件比较，当更容易了解意涵

　　至于服务组件实作的部分，则采用POJO的作法，相当容易撰写。值得一提的是，除了Java语言外，SCA还支持了不同的程序语言及程序设计模式。SCA的服务组件及客户端可用Java、Groovy、BPEL、C++、PHP、Python和Ruby等各种语言，以及POJO、EJB和Spring等各种程序设计模式实作。

　　选择适用的开源 SOA 项目

　　开放源码SOA项目的适用性，除了考虑质量参差不齐的因素外，更多时候是取决于你的用途。提供几条评估开放源码SOA项目时需要考虑的要点：

　　● 起源：项目的起源可作为决选的参考。了解项目的历史，有助于判别它是否符合企业的需求。

　　● 成熟性：还在Alpha或Beta阶段的项目，与发行次数多的项目相较，通常功能性较少，或臭虫较多。

　　● 对标准的支持：从头开始的项目，较能确保支持一些标准。Mule因出道早，现在得要回过头来调整架构。

　　● 弹性的部署选择：有些ESB支持多样化的部署模式，可以快速入门，然后需要时，再转移到进阶的部署模式。

　　● 平台支援：考虑项目是否支持目前已使用的平台，包括应用程序服务器、网站服务器、讯息中介软件，以及应用程序框架等。

　　● 社群成长性及动能：积极活跃的社群，除了能帮助初学者入门以外，更有助于项目的未来发展。

　　● 商业支持：在国内，采用开放源码产品最大的困扰，是难以找到合适的导入厂商。此时可以找一些对开放源码有研究的社群高手，读者可以在JavaWorld@TW这类的社群网站找到他们，并询问他们任职的公司是否提供此类服务。

　　● 工具及文件：与商业化产品相较，开放源码通常在工具及文件上较不完备。随着Eclipse及NetBeans此类整合性开发平台的成熟，加上开放源码的商业化走势，此类状况逐渐改善中。总之，采用开放源码需具备实验精神。