Introducing_SCA，sca入门介绍

SCA 基础

什么是应用程序？我们可以认为它是一组软件构件组合并协作。所有的这些组件可以是用相同或者完全不同的技术。他们可以在同一进程里跑，或者在同一机器上的不同进程，还可能通过了两台或两以上连接的。但是，作为一个应用程序来说必需是有规则的，它必须包括两部分：创造组件的方法和将它们连接在一起的描述机制。

Service Component Architecture(SCA)定义了一种通常情况下做这些事情的方法。SCA归约定义了如何建立组件以及如何将组件组装为应用程序。SCA应用的组件可以由java构成或其它使用SCA编程模型定义的语言，也可以使用其它技术，如Business Process Execution Language(BPEL)或sping框架。不论使用的何种组件技术，SCA定义了通用的装配机制来规约这些组件如何合并为应用。

本文概述的介绍SCA，希望能给大家一个技术功能的蓝图，并描述其如何工作，如何将各个部分组合在一起。

组件和组合

每一个SCA应用都有一个或多个构件组成。在最简单情况下，组件可以是在单一进程里运行的java类以及他们暴露的交互接口。在稍复杂的轻量级例子中，java类可能运行在不同主机中，通过一种通讯机制将它们连接。在更复杂的情况下，应用可能包括了java类，C++以及BPEL定义的实现，并分布在一组不同的主机上。在所有上述的情况中，相同的基础部分是：必需有定义组件的形式以及描述它们如何交互。并且在快速发展的SOA世界里，交互应该为一个服务，将实现技术与他们提供的功能完全的分离开。

为达到这个目标，SCA定义了组件的普遍概念。它同时也规约了组合行为，及这些组件如何合并为一个大的架构。下图展示了一个有三个SCA组件的简单组合。

容器是一个逻辑概念：在其内部的组件可以运行在一台主机上的单一进程或者分布在许多主机上的多个进程。像上例中所示，一个完整的应用可能只有一个组合构成，也可能组合了几个不同的组合。构件组合可以采用同样或不同技术皆可。

       图例显示，非SCA结构的软件可以访问一个SCA应用，如JSP，Webservices客户端或任何其它的。和其它应用一样，SCA应用中的组件可访问数据。Service Data Object(SDO)给了我们一个不错的选择，或者协同其它的标准数据访问技术，如JDBC，Java EE 5’s Java Persistence API （JPA），SCA规范并不强制要求你的选择。

       一个SCA组合通常由关联配置文件所描述，文件的命名结尾为.composite。该文件使用了称为Service Component Definition Language (SCDL, commonly pronounced “skiddle”) 的XML格式来描述组件和组合内部如何归约工作组件工作。对于上面举例的3个组件组合来说，SCDL配置的基本结构如下：

<composite name="ExampleComposite" ...>

<component name="Component1">

... </component>

<component name="Component2">

...

</component>

<component name="Component3">

...

</component> </composite>

       组件及组合是SCA应用的基本元素。这两者都包含与一个大的结构“域”中，因此，我们我们还需要掌握这个域的概念。

域

SCA的创始人可能有这样的设想，我们的运行环境需要安装由一个单一厂商制定的一组软件产品。例如，一个大的电影公司中的部门选择了属于自己的SCA厂商，这个部门愿意在自己的计算机上安装这个厂商的软件。这样做并不反常，很多组织选择安装J2EE的产品就是其很好的例子。SCA运行环境由一组使用统一厂商技术和管理系统的人管理，这就是域的一个最初例子。

域是SCA中的一个重要概念。即使SCA允许创建分布式应用，但它并没有完全定义组件在不同的主机中应如何交互。这导致，组件间的通讯由不同的厂商的不同技术来实现。（然而，在下面章节所讲述的SCA实现部分，一个SCA运行环境允许第三方组织创建一个如BPEL的容器插件以支持特殊的技术）

一个域可以包括一个或多个组合，每个组合可以包括运行在多台机器上的不同进程。如下图所示：

组件间是如何通讯的，不论是进程内，进程间还是主机间，可以被每个不同的SCA厂商所定义。但不论如何选择，组合绝对不能跨越域的界限。

由许多不同的厂商归约来共同定义创建分布式应用的方式然而不定义应用中的组件如何交互，可能感觉不合适。为了理解这一点，需要意识到SCA创建者的主要目标就是允许程序可可插拔性及开发者的技术可以跨越不同的SCA实现。也许有一天，当我们创建的组合跨越了域的界限----及不同的厂商，那已经不在是SCA第一版本所追求的目标了。而且，限制在同一个域中的组合应用也会有很好的性能优化。在同一域中，一个SCA开发者的生活是显然简单轻松的。比如，我们可以避免不同厂商应用内在的复杂配置。

请大家不要迷惑，即便一个SCA组合运行在单一的厂商环境中，它依然是可以域外界的其它域沟通的。为了实现这个目标，一个SCA组件需要能够满足如Webservice的互操作协议，如下图所示：

       这个例子显示了两个SCA域，每个域中有两台计算机。两个域使用了不同的SCA运行环境。每个域中的组件与组合通过单一厂商归约通讯，SCA并不指定具体的交互实现。然而，为了实现域之间或与非SCA应用的沟通，通常将组件暴露并通过WebService等互操作机制访问。事实上不同域之间的SCA应用相互访问是与SCA应用访问其它应用是相同的。its use of SCA isn’t visible outside its domain.

理解组件

组件是SCA应用中的原子元素。就像原子一样，SCA组件有着一致的行为，并且能够通过不同的配置结构来组装。理解SCA需要从这些最基本的构件（building blocks）开始。

         在SCA的解释里，一个组件是一个经过恰当配置的实现的实例。而实现就是提供组件的功能的代码，例如一个java类或是一个BPEL过程。通过SCDL表达的配置，定义了组件如何同外部世界交互。理论上，一个SCA组件可以用任何一种技术实现。然而不论是用何种技术，组件都能有一些共有的抽象，包括服务，引用，属性以及约束（bindings）来归约自己如何同外部交互。下面我们来分别描述这些。

服务，引用以及属性

         从外部观察，一个SCA组件很简单。不论使用何种技术，都包括下图的基础部分：

典型的组件都会实现一些业务逻辑，包括一个或多种服务。服务，在图中通过绿色箭头表示，提供了一些可以被组件外部的客户端所访问的操作。服务如何被描述取决与实现组件的具体技术。例如，一个java类的服务描述通常就是一个java接口，BPEL实现的组件就需要用Web Services Description Language (WSDL)。

         除了对自己的客户提供服务外，一个组件同样需要依赖域中或域外其它组件提供的服务。通过引用来描述这种依赖。在图中以紫色的箭头表示，每个引用定义了需要调用其它接口的操作。

         服务和引用的这些概念非常重要，现在已经越来普遍的使用服务来表示一个组件对外提供的模型，而不是90年左右时利用分布式对象实现，松耦合的方案逐渐流行。显示声明式引用成为主流，它有许多优点。首先，形式化的组件关系描述可以给开发人员在程序块上层清晰的表现。声明式引用可以支持依赖注入（由SCA运行环境来帮助组件定位服务，而不是硬编码在代码中），代码越少越好，这为我们可以不必检查组件代码中的包含就移植或替换组件。

（未完待续，图片传不上去，学习中。。。）