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系统中。