| 开源与商业化软件厂商，在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等各种程序设计模式实作。 |
