此部分描述SCA组装模型规范最后一部分---1.10 打包与部署（Packaging and Deployment）。内容主要描述了组装好的composite如何打包以及部署到应用。
1.10 打包和部署（Packaging and Deployment）
1.10.1 域（Domains）
一个SCA域代表一个完整的运行时配置，潜在地发布在一系列互连的运行时节点上。
一个单一的SCA域为所有SCA结构（mechanisms）定义了可见性的界。比如，SCA连线通常仅仅用来连接单一的SCA域里的组件。连接域外部的服务必须使用绑定机制来寻找服务（如WSDL endpoint URIs）。同样，SCA结构如intents和policySets仅仅能被用在一个单一域的上下文中。一般来讲，对一个使用SCA开发和部署的服务来说，它外部的客户机应该不能断定（tell）SCA被用来实现这个服务，因为那是实现细节做的事情。
SCA域的大小和配置不受SCA组装规范的约束，它被期望是高度可变的。SCA域典型地代表了一个业务功能的区域，业务功能由一个单一的组织控制。比如，一个SCA域可以是一个业务的整体，或者是一个业务的部分。
举个例子，对于某个业务的账目部门，SCA域可能覆盖所有与财政相关的功能，它可能包含一系列构件来处理账目的特定区域，如其中的一个处理顾客账目，另一个处理应付款。
一个SCA域有下列各项：
l 一个虚拟的域层次（domain-level）的构件，它的组件被部署并运行。
l 一个installed contributions集，包含实现、接口和其它对执行组件必需的部件。
l 一个合理的服务集，它操纵发布（contributions）的集合和虚拟的域层次的构件。
与SCA域相关的信息可以通过多种方式被储存，包括但不限于一个特定的文件系统结构或一个仓库（repository）。
1.10.2 发布（Contributions）
一个SCA域可能需要很多不同的部件（artifacts）来工作。这些部件包括由SCA定义的，也包括其它的部件如对象代码文件（object code files）和接口定义文件（interface definition files）。SCA定义的部件类型都是XML文档。不同的SCA定义文档的根元素为：composite、componentType、constrainingType和definitions。不是由SCA定义的但可能被SCA域需要的XML部件包括XML Schema 文档、WSDL 文档和BPEL 文档。像其它的XML定义的结构，SCA结构使用XML限定名（如命名空间+本地名）来标识它们。
在SCA域里，非XML的部件也是需要的。这种部件最明显的例子是Java、C++和其它编程语言文件，这些文件对组件实现是必要的。因为SCA是可扩展的，其它XML和非XML部件可能也是必需的。
SCA为发布（ZIP）定义了一个能共同使用的打包格式，像下面详细说明的那样。这种格式不是仅有的SCA运行时可以使用的打包格式。SCA允许多种不同的打包格式，但是需要它们支持ZIP格式。当部署一个发布使用ZIP格式时，这个规范没有指定在部署后那个格式是否被保留。比如，基于SCA运行时的Java EE可以将ZIP包转换为一个EAR包。SCA期望任何一个打包（packaging）有如下特征：
l 把打包到SCA里的部件表示为一个单一的根节点的资源（resources）的一个等级结构是可能的。
l 目录资源（directory resource）应该在META-INF等级的根节点上存在。
l 一个名字为sca-contribution.xml的文档直接存在于META-INF/目录下，它列出了发布里的SCA构件，其中发布是可追捕的（runnable）。
上面的文档列出了结构（constructs）的命名空间，这里的结构在发布中定义且可以被其它发布使用。可选地，附加的元素可以存在，它们列出了发布所需的结构的命名空间，它们应该可以在别处找到，比如在其它的发布里。这些元素可以不是在打包中物理上存在的，但是可以被产生，基于存在的定义和引用，或者如果没有未解析的引用（unresolved references），它们可能根本不存在。
关于这个文件格式的细节，参见“SCA Contribution Metadata Document”。
为了说明SCA使用的打包格式的多样性，下面是格式的例子，这些格式通常用来打包SCA部件和元数据（还有其它部件）作为一个发布：
l 一个文件系统目录
l 一个OSGi包（an OSGi bundle）
l 一个压缩目录（zip、gzip等）
l 一个JAR文件（或它的变化，如WAR、EAR等）
发布不包含其它的发布。如果打包格式是一个包含其它JAR文件的JAR文件（或任何一个类似的其它技术的嵌套），内部的文件不被当成分离的（separate）SCA发布对待。一直等到实现再决定内部的JAR文件是否应该被表示为一个发布等级里的单一的部件，或是否所有的内容应该被表示为分离的部件。
SCA中部署方法的目标是：为了在一个域中安装和使用发布的内容，不必去修改发布的内容。
1.10.2.1 SCA 部件解析（Artifact Resolution）
发布可以是自包含（self-contained）的，它里面的所有部件对运行发布（在发布自身的里面被发现）的内容都是必要的。然而也有可能是这种情况，发布的内容引用了此发布外面的部件。这些引用可能引用SCA部件，或其它的部件如WSDL文件、XSD文件，或代码部件如Java类文件、BPEL脚本。
发布可以使用一些与部件相关的或与打包相关的方法去解决部件引用。这种机制的例子包括：
l wsdlLocation与schema Location属性，在引用WSDL和XSD schema的构件时。
l OSGi包机制，解决Java类和相关的资源依赖。
当前（where present），这些机制通常用来解决部件依赖。
SCA也提供了一个部件解析机制。这种机制在两种情况下被使用，一种情况是在没有其它机制可用时，一种是在同一个SCA Domain里不同的发布使用的机制不同时。第二种情况的一个例子是，一个发布使用了OSGi Bundle，第二个发布被第一个发布使用，但是没有使用OSGi实现。比如，第二个发布是一个主机的（mainframe）COBOL服务，它的接口使用WSDL声明且必须被第一个发布访问。
SCA部件解析可能对包含多种发布的SCA域最有用，部件相关（artifact-related）或打包相关（packaging-related）机制不太可能运转在不同种类的发布中。
SCA部件运转在一个原则上，即一个发布如果需要使用在别处定义的部件，那么在发布的元数据（metadata）中需要使用import声明来表达这些依赖。一个发布通过在元数据中使用export声明来控制哪些部件可以被其它发布使用。
1.10.2.2 SCA发布元数据文档
发布可以包含一个文档，它声明runnable composites、exported definitions和imported definitions。文档存放的路径是/META-INF/sca-contribution.xml（相对于发布的根目录）。一些SCA元数据经常需要手工指定，而其它元数据可以由工具产生（如下面描述的<import>元素）。为了适应这种情况，可能需要在目录/META-INF下建立一个相同结构的文档sca-contribution-generated.xml。如果这个文档存在，它将被合并到sca-contribution.xml的内容里，如果在这个整体中存在不一致的声明，sca-contribution.xml占有优先权。
sca-contribution.xml的格式如下：
deployable元素：标识一个发布里的构件，此构件潜在地被包含到虚拟的域层次的构件里。发布里的其它构件不用于包含（inclusion），而是仅仅被其它构件使用。新的构件可以在发布安装后被创建，通过使用add Deployment Composite和add To Domain Level Composite。
l composite（必需）：发布里的构件的限定名（QName）。
Export 元素：一个声明：属于一个特殊命名空间的部件被导出（export）并可在其它发布里使用。一个发布里的export声明指定一个命名空间，它里面的所有定义（definitions）都认为是被导出。默认地，定义不被导出。
SCA artifact export对于包含多种发布打包和技术的SCA域是有用的，部件相关或打包相关机制不太可能运转在不同种类的发布中。
l namespace（必需）： 对于由限定名标识的XML定义来说，namespace应该是被导出定义（exported definitions）的命名空间URI。对于在一个命名空间里定义多种记号空间（symbol spaces）的XML技术来说（如WSDL port types是不同的记号空间），所有记号空间的所有定义都被导出。
对于使用naming schema而不是QNames的技术，必须使用一个不同于SCA<export>元素的export元素。这个被使用的元素标识着技术，且对适合此技术的命名空间来说，这个元素可以使用任何值。比如，<export.java>通常用来导出Java定义，在这种情况下，命名空间应该是一个完整的限定的包名。
Import元素：import声明指定了定义的命名空间，这里的定义是被发布里的定义和实现所需要的，但它们是不在发布里的。大多是情况下，import声明将基于发布的内容的反射被产生。在这种情况下，import声明应该出现在文档/META-INF /sca-contribution-generated.xml中。
l namespace（必需）：对于由限定名标识的XML定义来说，namespace应该是被引入定义（imported definitions）的命名空间URI。对于在一个命名空间里定义多种记号空间（symbol spaces）的XML技术来说（如WSDL port types是不同的记号空间），所有记号空间的所有定义都被引入。
对于使用naming schema而不是QNames的技术，必须使用一个不同于SCA<import>元素的import元素。这个被使用的元素标识着技术，且对适合此技术的命名空间来说，这个元素可以使用任何值。比如，<import.java>通常用来引入Java定义，在这种情况下，命名空间应该是一个完整的限定的包名。
l location（可选）：一个URI，为import解析定义。SCA对此URI的格式以及解析途径都没有特定的要求。它可以指向另一个发布（通过URI）或者指向一些SCA域外的位置。
有一件事情被期待，即SCA运行时可以为发布之间的artifact resolution来定义解析位置信息的实现细节方式。然而这个机制常常被局限于一个运行时技术和一个主机环境的发布的集合。
为了适应在不同运行时技术的发布之间引入部件，强烈建议SCA运行时把SCA发布URI作为位置规范。
对于SCA部件的cross-contribution 解析，支持发布URIs的SCA运行时也应该类似这样做，当它使用@schimaLocation、@wsdlLocation和其它部件位置规范时。
被指定的import声明的次序在这个机制中可能扮演着角色。因为一个命名空间的定义可以在几个部件上发布，所以一个命名空间可以有多个import声明。
location的值是一个默认值，依赖的分布（installContribution的调用中列出的分布）应该覆盖这个值，如果有冲突的话。然而解决发布（这些发布定义了不一致的定义）之间冲突的具体机制是实现细节。
如果location属性的值是一个SCA发布URI，那么发布打包可能依赖于部署环境。为了避免这种依赖，依赖的发布应该仅在部署或更新发布（像Operations for Contributions部分描述的一样）时被指定。
1.10.2.3 使用ZIP打包发布
SCA允许多个不同的SCA运行时可以支持的打包格式，但是SCA要求所有的运行时支持ZIP打包格式。这个格式允许存在元数据，这里的元数据由‘SCA Contribution Metadata Document’部分指定。具体说来，这个格式可以包含一个顶层的“META-INF”目录和一个“META-INF/sca-contribution.xml”文件，还可以有一个可选的“META-INF/sca- contribution-generated.xml”。由SCA定义以及非SCA定义的部件，如object files、WSDL definition、Java classes，可以在ZIP存档文件中的任何地方存在。
最新的ZIP文件格式的定义由PKWARE发布，参见an Application Note on the .ZIP file format [12]。
1.10.3 已安装的发布（Installed contribution）
像在上面的部分提到的那样，为了在一个域里安装和使用发布，发布的内容应该不必被修改。一个installed contribution是一个发布，它拥有执行发布里的deployable composites时所必需的所有相关信息。
一个installed contribution由下面的部分组成：
l Contribution Packaging：用于解析所有引用的起点的发布。
l Contribution 基URI。
l Dependent contributions：其它发布的集合，用于从根节点composite和其它依赖的发布解析import声明。
² 依赖的发布可以或不可以与其它已安装发布（installed contributions）被共享
l Deployment-time composites。
这些构件在部署后被添加进一个已安装的发布里。这就使得在不修改发布的情况下提供最终的配置和访问发布里的实现成为可能。这些是可选的，就像发布里已经存在的构件也可以用于部署一样。
已安装的发布提供了一个上下文去解析限定名（如：XML中的QNames、Java里的完全限定类名（fully qualified class names））。
如果多个依赖发布导出了带有冲突的限定名的定义（definitions），用来决定使用限定名的算法依赖于实现。SCA的实现也可以产生一个错误，如果有冲突的名字。
1.10.3.1 已安装的部件URIs（Installed Artifact URIs）
当一个发布被安装后，发布里的所有部件都分配了URIs，这些URIs以发布的基URI为开始，后面添加每一个部件的相对URI（回顾一下，SCA要求任何一个打包格式都能把它的部件表示为一个单一的层次结构）。
1.10.4 发布的操作（Operations for Contributions）
SCA域提供下面的与发布相联系的概念上的功能（意味着这些功能可能不被表示成可寻址的服务，也意味着可以以其它方式提供等价的功能）。这些功能是可选的，意味着SCA运行时可以选择以任何方式不去提供这些功能。
未完待续......
| 
