此部分描述SCA组装模型规范V1.0.0–1.7绑定（Binding），主要介绍了引用如何调用服务以及客户端通过什么样的方式来访问服务。  

　　1.7 绑定（Binding）

　　绑定（bindings）被服务（services）和引用（references）使用。引用（reference）使用绑定来描述一个访问机制，此机制用来调用服务（它可以是另一个SCA构件提供的服务）。服务使用绑定也来描述一个访问机制，客户端（可以来自另一个SCA构件的客户端）必须用此机制来调用服务。

　　SCA支持多种不同的绑定类型。示例中包括SCA service、Web service、stateless session EJB、data base stored procedure和EIS service。SCA运行时（runtime）必须支持SCA service和Web service绑定类型。SCA提供了一个扩展机制，通过这个扩展机制，SCA运行时可以增加对其它绑定类型的支持。关于如何定义其它的绑定类型，参见the Extension Model部分。

　　在构件中，绑定通过一个binding元素定义，它可以是service或reference元素的子元素。下面的代码片段展示了有binding元素的构件模式。

　　<?xml version=”1.0″ encoding=”ASCII”?>
　　<!– Bindings schema snippet –>
　　<composite http://www.osoa.org/
        name=”xs:NCName” local=”xs:boolean”? autowire=”xs:boolean”?
        constrainingType=”QName”?
        requires=”list of xs:QName”? policySets=”list of xs:QName”?>
 
　　…
 
      <service name=”xs:NCName” promote=”xs:anyURI”
            requires=”list of xs:QName”? policySets=”list of xs:QName”?>*
           <interface/>?
           <binding uri=”xs:anyURI”? name=”xs:QName”?
                 requires=”list of xs:QName”? policySets=”list of xs:QName”?/>*
           <callback>?
               <binding uri=”xs:anyURI”? name=”xs:QName”?
                     requires=”list of xs:QName”?
                    policySets=”list of xs:QName”?/>+
          </callback>
      </service>
 
…
 
      <reference name=”xs:NCName” target=”list of xs:anyURI”?
            promote=”list of xs:anyURI”? wiredByImpl=”xs:boolean”?
           multiplicity=”0..1 or 1..1 or 0..n or 1..n”?
          requires=”list of xs:QName”? policySets=”list of xs:QName”?>*
          <interface/>?
         <binding uri=”xs:anyURI”? name=”xs:QName”?
              requires=”list of xs:QName”? policySets=”list of xs:QName”?/>*
         <callback>?
            <binding uri=”xs:anyURI”? name=”xs:QName”?
                   requires=”list of xs:QName”?
                  policySets=”list of xs:QName”?/>+
        </callback>
     </reference>
 
…
</composite>

　　binding元素的元素名是被构造出来的（architected）；它本身是一个限定名。第一个限定名总是叫做“binding”，第二个限定名以各自的绑定类型命名（如binding.composite，binding.ejb，binding.eis）。

　　binding元素有下面的属性：

　　uri（可选）：它有下面的语义。

　　对reference元素的binding，此uri属性定义了该引用的目标URI（在SCA域里，此uri为component/service；在SCA域外，此uri是引用终点的可到达的地址）。对作为组件实现的构件来说，定义在其中的引用，使用binding是可选的，但是对于那些对SCA域起作用的构件，它定义的引用的binding是必需的。对作为实现（implementation）的构件来说，其引用的URI属性可以被包含它的构件中的一个组件重新配置。一些绑定类型可以要求目标服务的地址使用一个简单的URI（比如一个WS-Addressing endpoint reference）。在那些情况下，绑定类型可以定义一些附加的属性或子元素，它们对标识服务是必要的。

　　对service元素的binding，URI属性定义了相对于一个组件的URI（即URI的形式为component name/service name），这个组件把服务贡献给SCA域。此URI的默认值是binding的name属性值。

　　name（可选）：binding实例的名字（一个QName）。此name属性允许在service或reference里的多个binding元素之间有差异。name属性的默认值是相应service或reference的名字。当一个service或reference有多个binding的时候，只有一个可以有默认值；其它的必须有一个被指定的值，这些值在service或reference里是不同的。这个名字同样允许绑定实例能在其它地方被引用，尤其对binding的一些类型很有用，这些名字可以在一个定义文档（像模板一样）中声明，被其它绑定实例引用，这就简化了更复杂的绑定实例的定义。

　　requires（可选）：策略意图列表。参见Policy Framework specification[10]。

　　policySets（可选）：策略集列表。参见Policy Framework specification[10]。

　　当一个服务存在多个绑定时，它意味着服务可以通过指定绑定中的任何一个得到。SCA运行时（runtime）究竟使用什么技术来选择可用的绑定来得服务，这个工作被留给实现（implementation）去做，它可以包含附加的（或不规范的）配置。不管使用哪一种技术都应该被说明。

　　服务和引用可以在SCA域这个层次上覆盖它们的绑定，除非它们受到应用于自身的Intents的约束。

　　下面的段落细节地描述SCA和Web service绑定类型。

　　1.7.1 包含数据（不在服务接口中定义）的消息

　　一个消息（message）可能包含一些信息（information），这些消息不在用来定义服务的接口中定义，比如，信息可以被包含在SOAP报头里或作为MIME附件。

　　实现类型（implementation type）可以在它们的执行上下文（&#101xecution context）中使得这个信息被组件实现得到。这些实现类型必须表明这个信息如何被访问及以什么形式表示。

　　1.7.2 被部署的绑定的URI形式

　　1.7.2.1 构造分等级的（Hierarchical）URIs绑定使用分等级的URI模式来构造有效的URI，通过下面块的组合：

　　Base Domain URI for a scheme /Component URI/Service Binding URI

　　即：域的基URI/组件URI/服务绑定URI

　　每一个成分都值得额外的说明一下：

　　Base Domain URI for a scheme。一个SCA域应该为每一个等级URI模式定义一个URI基值（base URI），这个URI模式是域将要用来提供服务的。

　　例如：HTTP和HTTPS模式都有自己的为域定义的URI基值。如果一个模式不是分等级的，因此它没有URI基值，比如“jms：”模式。

　　Component URI。对于一个组件，组件URI是部署在SCA域里的。一个组件的URI默认为组件的名字，组件可以有一个指定的URI值。指定的URI值可以是一个绝对URI，在这种情况下，此URI将变成属于此组件的所有服务的URI基值。如果指定的URI值是一个相对的URI，它将被作为Component URI值使用。

　　Service Binding URI。服务绑定 URI是一个相对URI，它是在service的binding元素的“uri”属性里指定的。此属性的默认值是绑定（binding）的name属性值，被当作一个相对URI。如果一个单一服务的多个绑定使用相同的模式（如HTTP），那么只能有一个绑定的uri属性可以依赖于此默认值。服务绑定 URI也可以是绝对URI，在这种情况下，绝对URI完全指定了此服务的URI。一些部署环境可能不支持服务绑定中的绝对URIs。

　　当组件仅仅有一个单一服务时，服务URI是null，所以有效的URI是：

　　Base Domain URI for a scheme/Component URI

　　这种URI的简写形式和连接引用到服务时所使用的连线目标的URI的简写形式是一致的。

　　部署到域里的服务有一个URI，它不包含组件名称，如：

　　Base Domain URI for a scheme/Service Binding URI

　　构件（包含服务）的名字对任何服务的URI都不起作用。

　　比如，一个服务的基URI是“http://acme.com”，组件叫“stocksComponent”，服务绑定的名字为“getQuote”，则URI将像下面那样：

　　http://acme.com/stocksComponent/getQuote

　　允许指定一个不同于服务名字的绑定的相对URI也就允许独立域组织来设计服务的URI层次（等级）。

　　设计独立于域组织的URI等级是一个良好的习惯，但是域有可能最初就使用默认的URI等级被创建。在这种情况下，当维护URI等级的形式时，可以通过对select元素的uri属性赋予合适的值来改变域的组织。下面是一个例子，即在维护已存在的URIs时，对域组织做出一个变化：

　　把一个组件（如“foo”）服务的子集移动到一个新的组件（如“bar”）里，这个新的组件bar应该为移动过来的服务的bindings指定一个URI“../foo/MovedService”。

　　为了给一些ednpoint创建简短的URIs，可以使用URI属性，组件名字可能根本就不在URI里。比如，如果一个绑定的uri属性为“../myService”，组件名字不在URI里。

　　1.7.2.2 无等级的URIs（Non-hierarchical URIs）

　　使用无等级的URI模式（如jms：or mailto：）的绑定，可以选择地使用“uri”属性，此属性是相应服务绑定的URI的完整表示。在绑定不使用“uri”属性的地方，绑定必须提供一个不同的机制来指定服务地址。

　　1.7.2.3 决定被部署的绑定的URI模式

　　当构造一个被部署的绑定（如endpoint）的有效URI时，需要决定的事情之一就是URI模式。决定endpoint URI模式的过程是明确绑定类型。

　　如果绑定类型支持一个单一的协议，那么和它相关的仅有一个URI模式。在这种情况下，那个URI模式被使用。

　　如果绑定类型支持多个协议，通过对绑定配置的反射，绑定类型的实现确定了URI模式，这个模式可以包含与绑定相关的策略集。

　　支持多协议绑定类型的一个很好的例子是binding.ws，它可以通过引用一个“抽象的”WSDL元素（如portType或interface）或“具体的”WSDL元素（如binding、port或endpoint）被配置。当绑定引用一个PortType或Interface时，协议和URI模式来自于绑定附带的intents/policy。当绑定引用“具体的”WSDL元素时，有两种情况：

　　被引用的WSDL binding元素唯一地标识一个URI模式。这是大多数情况。在这种情况下，URI模式由WSDL binding元素指定的protocol/transport给出。

　　被引用的WSDL binding元素不能唯一地标识一个URI模式。例如，当HTTP被SOAP binding元素的@transport属性指定时，“http”和“https”都可以作为有效的URI模式使用。在这种情况下，URI模式由binding的策略集（policy sets）决定。

　　1.7.3 SCA绑定

　　SCA 绑定元素定义为下面的模式：

　　<binding.sca />

　　SCA绑定用于包含在SCA域里的引用和服务之间的服务交互。绑定类型以哪种方式被实现没有在SCA规范中定义，它可以被不同的SCA运行时（runtimes）通过不用的方式实现。唯一的要求是：SCA绑定类型中必需的服务必须被实现。SCA绑定类型并不打算成为一个互用的（interoperable）绑定类型。对于互用性（interoperability）来说，应该使用一个可互用的（interoperable）绑定类型，如Web service绑定。

　　如果服务或引用的定义（definition）中没有指定binding元素，默认使用SCA绑定。<binding.sca/>仅仅在覆盖的情况下必须指定，或当你在服务或引用的定义中指定了一个bindings集时，SCA绑定应该是它们（绑定集）中的一个。

　　如果服务或引用的接口是本地的，则要使用SCA绑定的local变量。如果服务或引用的接口是远程的，那么SCA绑定的local或remote变量的使用将依赖于源和目标是否是相互定位的（co-located）。

　　如果一个引用通过uri属性指定了一个URI，那么它提供了到服务的默认连线，这里的服务是由另一个域层次的组件提供的。URI的值是这样的：

               <domain-component-name>/<service-name>

　　1.7.3.1 SCA绑定实例

　　下面的代码片段展示了MyValueComposite的MyValueComposite.composite文件，MyValueComposite包含名为“MyValueService”的service元素和引用StockQuoteService的reference元素。service和reference都使用了SCA绑定。reference的目标没有在这个绑定中定义，它将不得不由使用此构件的构件来提供。

　　<?xml version=”1.0″ encoding=”ASCII”?>
　　<!– Binding SCA example –>
　　<composite http://www.osoa.org/http://foo.com”>http://foo.com”
         name=”MyValueComposite” >
 
       <service name=”MyValueService” promote=”MyValueComponent”>
            <interface.java 　　interface=”services.myvalue.MyValueService”/>
            <binding.sca/>
             …
      </service>
 
…
 
    <reference name=”StockQuoteService”
          promote=”MyValueComponent/StockQuoteReference”>
         <interface.java 　　interface=”services.stockquote.StockQuoteService”/>
        <binding.sca/>
    </reference>
 
　　</composite>

　　1.7.4 Web Service绑定

　　SCA定义了一个Web service绑定。详见a separate specification document[9]。

　　1.7.5 JMS绑定

　　SCA定义了一个JMS绑定。详见a separate specification document[9]。

　　此部分结束。。。。。

　　原文出处：http://gocom.primeton.com/blog9681_35328.htm