SCA、SOA与OSGi概念浅析

　基于组件的编程一直是软件业简化编程和提高效率和质量的一个重要方法，但是往往对于不同语言我们有不同的组件模型，从而需要不同的调用方式。SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用。这种方式也使得客户的企业应用具有良好的分层架构，能够很好的分离应用的业务逻辑和IT逻辑，不但易于应用的构建，也易于应用的更改和部署。
　　SCA全称Service Component Architecture，即服务组件框架。服务组件体系结构 (SCA) 是一个规范，它描述用于使用 SOA 构建应用程序和系统的模型。它可简化使用 SOA 进行的应用程序开发和实现工作。它由BEA、IBM、Oracle、以及国内的普元等知名中间件厂商联合制定的一套符合SOA思想的规范。
　　SCA是一个可执行的模型，用于将不同的 服务集成到一个业务解决方案。它简化了实现业务服务的组件编程模型，这些组件可以使用不同编程语言实现,对于企业应用，SCA还提供了关键的一些基础设施，像安全性、事务、可靠调用等，这对于企业应用的开发而言就变得很方便了。SCA确实可以成为企业应用开发的利器SCA确实可以成为企业应用开发的利器。SCA是第一项承诺提供一个组合模型以启用服务网络并支持构建下一代面向服务应用程序的技术。 SCA在2005年11月，发布了0.9版本的规范，其中包括了组装模型规范，Java/C++客户端以及其实现规范。2006年4月，整个SCA规范有了很大的改进，推出了对应的0.95版本。2007年3月，OSOA联盟宣布了SCA和SDO规范中关键部分的完成，发布了SCA 1.0和SDO 2.1，并将其正式提交给OASIS，通过其开放式标准过程进行推动。
　　SCA规范中着重解决了现有企业应用之间的相互调用和企业应用如何以面向服务的思想来建立和部署。但是对于构件容器的实现方面的规定则有些不足，仅仅是站在使用者的角度描述了客户端API的规格。
　　SCA可让你专心于分析业务逻辑，而不需要过多的去担心系统架构。SCA简化了所有开发者的使用体验
　　SCA可以将已有的程序、代码、服务添加上元数据，从而可以被其他的服务引用或调用。独立于程序代码的元数据描述信息，可以方便的描述已有的代码，而不须对已有代码做修改。
　　服务组件框架(SCA)提供了一套可构建基于面向服务的应用系统的编程模型。它的核心概念是服务及其相关实现。服务由接口定义，而接口包含一组操作。服务实现可以引用其他服务，称为引用。服务可以有一个或多个属性，这些属性是可以在外部配置的数据值。
　　SCA与SOA
　　既然SCA是为基于SOA思想的系统而制定的开发、部署规范，它首先必然是具备了SOA的一系列的优点，象跨语言、分布式、以服务的思想构建系统等。SCA对于组件中的服务的调用提供了异步调用的支持，在异步调用的支持上SCA的考虑也较为全面，象JMS方式的、RMI方式的等等。
　　使用SOA构建业务解决方案主要的优势之一就在于其能按照业务需求的变化和革新快速组装新的解决方案。解决方案组装的关键是包含现有的应用和功能的能力，而不是什么都从头开始。的确，只有尽可能地复用现有的功能，才能完成快速开发的目标。
　　SCA一种是使用SOA的业务解决方案的编程模型。SCA提供了这么一个特性，使得将已存在的功能组装成新的解决方案尽可能的简单。该文档检验了这些特性中的一些。
　　SCA提供了实现面向服务的架构(SOA)的一个编程模型。
　　面向服务的架构已经在软件开发领域存在很多年了。但是当一些组织试图去定义最佳的实现和管理技能的时候，为一个特定组织开发一个SOA的细节却是难以捉摸的。
　　SCA规范是为了企业应用集成而制定，OSGI规范的初衷则是为移动设备计算而制定的。由于二者的出发点不一样，导致了两个规范的侧重点不一样。SCA规范现在的版本是0.95，相对OSGI规范的4.0版本还显得多少有些稚嫩。
　　服务组件
　　服务组件是SCA中的基本组成元素和基本构建单位，也是我们具体实现业务逻辑的地方。我们可以把它看成是构建我们应用的积木。我们可以非常容易地把传统的POJO，无状态会话BEAN等包装成SCA中的服务组件。 SCA服务组件的主要接口规范是基于WSDL(Web Service Description Language)的，另外为了给Java编程人员提供一个比较直接的接口，SCA的部分服务组件也提供了Java接口。因此，使用服务组件的客户端可以选择使用WSDL接口或Java接口。
　　服务模块
　　服务模块(简称模块)由一个或多个具有内在业务联系的服务组件构成。把多少服务组件放在一个模块中，或者把哪些服务组件放在一起主要取决于业务需求和部署上灵活性的要求。模块是SCA中的运行单位，因为一个SCA模块背后对应的是一个J2EE的企业应用项目。这里之所以说是"背后"，原因是我们在开发工具WID(WebSphere Integration Developer V6.0)中，通过业务集成透视图看到都是SCA级别的元素。但是当你切换到J2EE透视图你就会发现这些SCA元素与实际J2EE元素之间的对应关系。因此，在WID中构建一个模块就相当于构建一个项目。另外，由于模块是一个独立部署的单元，这给应用的部署带来很大的灵活性。比如，只要保持模块接口不变，我们很容易通过重新部署新的模块而替换原有的业务逻辑，而不影响应用的其它部分。
　　由于一个模块中往往会包含多个服务组件，那我们如何来构建这些服务组件之间的相互调用关系呢?在WID工具中，我们只要简单地通过接口与引用之间的连线，就可以指定它们之间的调用关系而不需要写一行代码。另外，我们可以在这些连线上面设定需要的QoS要求，比如事务，安全等。
　　SCA和SDO/OSGi
　　SCA和SDO规范能帮助企业更便捷地创建新的以及改造现有的IT资产，使之可复用、易整合，以满足不断变化的业务需求。这些规范提供了统一服务的途径，大大降低了在应用开发过程中，因程序设计语言与部署平台的不同而产生的复杂性。SCA和SDO规范都是用于简化业务逻辑和业务数据呈现的新兴技术。早期用户已经开始实行这些规范并从中获得了价值。
　　SCA和SDO的出现，给SOA来了点实际的。SCA(Service Component Architecture)其实就是将过去EJB的成果继续下去，基于Component的复用，同时吸收了IOC的思想，Component之间的组装是通过SCA框架来实现的，但是很重要的一点，他没有走EJB的老路，而是学习spring的轻量级框架，不再为开发者作的面面俱到，其实，特别对于中国的程序员来说，不需要太多的框架去限制他们，只需要给他们一个可以订制的灵活的框架即可，他们的手艺都不错，同时也可以在这个订制的阶段学到很多，这也是为什么开源项目吸引那么多高手的原因，因为参与和创造才能给程序员一种自我实现的快感。SCA的Component和OSGI的Bundle一样其实是对Java封装的一种贯彻，它有需要Import的服务引用，需要Export的服务，很重要一点就是它对于Component，service,reference的实现都没有作限制，这类对象只需要有个接口定义和实现描述即可，当前规范中支持的接口定义可以是java接口也可以是wsdl文件(最终也是转换成为java接口)，实现的话那么更加广泛java,webservice,rmi,jms,脚本语言等等，同时提供了扩展接口，所以只要你想的到，就可以实现的了。然后多个Component组装成为一个Composite(对于业务开发来说，也就是一个业务的Model)。
　　SCA支持远程调用其他组件的服务，而这点正是OSGi的一个巨大的缺点，也是EEG现在正在努力做的;SCA对于远程调用其他组件的服务支持象Webservice、JMS、JCA、RMI、CORBA等等方式的调用。
　　SCA和OSGI之间的优缺点是可以互相弥补的。SCA和OSGI的优劣，但其实作为这两个规范面向的解决问题都是不同的，SCA是SOA的一个实现，SOA是解决分布式服务的互通问题，而OSGI是针对单机服务的动态绑定义及组装，因此两者不存在着可比性，但是在我看来，两者却有着很好的互补性，在平台的现有情况下，用SCA来实现服务框架，同时通过OSGI来实现组件装配，这无疑是很好的一件事情，同样有个开源项目也正在做这件事。
　　SCA 方法的优势包括：
　　简化业务组件开发
　　简化作为服务网络构建的业务解决方案的组装和部署
　　提高可移植性、可重用性和灵活性
　　通过屏蔽底层技术变更来保护业务逻辑资产
　　提高可测试性
　　SCA允许在很宽的implementation types(实现类型)中选择任何一种实现，例如象Java、BPEL或者C++等都是implementation types(实现类型)，每一种类型都描述一个明确的实现技术。这些技术不仅可以是一种语言，象Java，还可以是特殊的框架或者运行环境，象Java技术中的Spring框架和J2EE技术中的EJB环境。
　　目前，SCA提供了Spring、EJB、JavaScript、Groovy、Ruby、BPEL等的实现技术，可以将已有的程序实现加入到SCA系统中，为SCA提供具体的功能实现。也可以根据实际需要，通过SCA提供的扩展机制，将新的技术增加到SCA系统中。