面向成功，实现梦想！

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元素的构件模式。

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

binding元素有下面的属性：

l         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属性值。

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

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

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

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

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

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

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

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

    实现类型（implementation type）可以在它们的执行上下文（execution 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

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

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

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

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

l         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元素时，有两种情况：

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

2)       被引用的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的目标没有在这个绑定中定义，它将不得不由使用此构件的构件来提供。

1.7.4 Web Service绑定

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

1.7.5 JMS绑定

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

    此部分结束。。。。。