此部分描述SCA组装模型规范 V1.0.0—1.5 接口（Interface）。主要描述了本地接口、远程接口、双向接口和回调接口等。  

　　1.5 接口（Interface）

　　Interfaces定义1个或多个业务功能。这些业务功能由服务（services）提供、被references使用。服务提供业务功能（确切的说是接口）给其它组件使用。每一个接口定义了一个或多个服务操作（operations），每一个操作有0或1个请求（输入）消息和0或1个响应（输出）消息。这些请求和响应消息可以是简单的类型如string值，也可以是复杂类型。

　　当前SCA支持下面的接口类型：

　　Java接口

　　WSDL 1.1 portTypes

　　WSDL 2.0 接口

　　（WSDL：Web Services Definition Language[8]）

　　SCA可以根据接口类型进行扩展。通过SCA的扩展机制，可以增加对其它接口类型体系的支持，参见the Extension Model section。

　　下面的代码片段展示了Java接口元素的模式。

　　<interface.java interface=”NCName”/>

　　interface.java元素有下面的属性：

　　interface，Java 接口的限定名。

　　下面的例子展示了Java接口元素实例。

　　<interface.java interface=”services.stockquote.StockQuoteService”/>

　　这里，Java接口定义在Java类文件

　　./services/stockquote/StockQuoteService.class中，根目录由接口所在的基值（contribution）定义。

　　在Java接口类型体系中，使用Java类或简单的Java 类型来描述服务方法的参数和返回值。由于Service Data Objects [2]与XML技术的集成（integration），于是成为Java类的首选形式。

　　关于Java接口与SCA-specific 注解的更多消息，参见the Java Client and Implementation specification [1]。

　　下面的代码片段展示了一个WSDL portType（WSDL 1.1）或WSDL 接口（WSDL 2.0）元素的例子。

　　<interface.wsdl interface=”xs:anyURI” … />

　　interface.wsdl元素有下面的属性：

　　interface，它是具有下面格式的portType/interface 的URI

　　<WSDL-namespace-URI>#wsdl.interface(<portTypeOrInterface-name>)

　　下面的代码片段展示了一个WSDL portType/interface元素的例子

　　<interface.wsdl interface=”http://www.stockquote.org/StockQuoteService#
                            wsdl.interface(StockQuote)”/>

　　对于WSDL 1.1，interface属性指向WSDL的portType。对于WSDL 2.0，interface属性指向WSDL的接口。对于WSDL 1.1和WSDL 2.0接口类型系统，服务操作的参数和返回值使用XML模式描述。

　　1.5.1 本地和远程接口（Local and Remotable Interfaces）

　　一个远程服务是这样的一个服务：它可以被一个运行在操作系统进程（不同于服务运行的进程）上的客户端（client）调用（这也适合于客户端与服务运行在不用的机器上）。一个组件实现的服务是否为远程服务由服务的接口定义。在Java情况下，可以为Java接口增加@Remotable注释来定义远程接口（参见Client and Implementation Model Specification for Java）。WSDL定义的接口一直是远程接口。

　　远程接口的风格是典型的谷粒（coarse grained），用于松散耦合（loosely coupled）交互。远程服务接口不能使用方法或操作重载（method or operation overloading）。

　　不管远程服务在其运行的进程外被远程调用，还是被运行在同一进程里的另一个组件调用，数据交换的语义是by-value。

　　远程服务的实现（implementations）可以在调用过程中或之后修改输入信息（参数），也可以在调用之后修改返回信息（结果）。如果一个远程服务被本地或远程调用，SCA容器会负责确保：调用者会看到输入信息或调用后（post-invocation）的修改对返回信息没有任何修改。

　　下面是一个代码片段，展示了一个远程java接口的例子：

　　package services.hello;
 
　　@Remotable
　　public interface HelloService {
 
　　String hello(String message);
　　}

　　对于一个远程服务的实现，需要说明的是，当它被同一进程的一个组件调用的时候，可以使用by-reference数据交换语义来进行调用。这可以提升运行在同一进程里的组件之间服务调用的性能。可以通过使用@AllowsPassByReference注解来完成（参见Java Client and Implementation Specification）。

　　一个标记为local接口的服务只能被运行在同一进程中的客户端调用，它就像实现本地服务的组件一样。本地服务不能通过包含此服务的构件以远程服务的方式发布。在Java情况下，一个本地服务定义为一个没有@Romotable注解的Java 接口。

　　本地接口的风格是细粒的（fine grained） 用于紧密耦合交互（tightly coupled）。本地的服务接口可以使用方法或操作的重载。本地接口调用服务的数据交换语义为by-reference。

　　1.5.2双向接口（Bidirectional Interfaces）

　　一个业务服务到另一个业务服务的关系经常是点对点（peer-to-peer）的，这就需要服务层上的一个双向依赖。换句话说，一个业务服务即是一个服务（由同伴业务服务提供）消费者，也是一个服务提供者。这一点在基于异步消息的交互中（非远程过程调用）尤为明显。在SCA中，双向接口就是直接用来对点对点双向业务服务关系进行建模。

　　一个特殊接口类型系统的interface元素必须允许指定一个可选的回调接口。如果指定了一个回调接口，SCA引用此接口作为一个整体，像双向接口一样。

　　下面的代码片段展示了一个使用Java接口定义的一个interface元素，它有一个可选的callbackInterface属性。

　　<interface.java interface=”services.invoicing.ComputePrice”
                          　　callbackInterface=”services.invoicing.InvoiceCallback”/>

　　如果一个服务的定义中使用了双向接口元素，那么它的实现（implementation）要实现此接口，它的实现使用这个回调接口与调用此服务接口的客户端进行对话。

　　如果一个引用的定义中使用了一个双向接口元素，使用此引用的客户端组件实现通过此接口调用被引用的服务。客户端组件实现必须实现此回调接口。

　　回调可以用在远程和本地服务。一个双向服务的所有接口要么都是远程的，要么都是本地的。双向服务不能混合本地和远程服务。

　　SCA里提供了一些工具（facilities），它们允许不同的组件提供一个回调接口。(Facilities are provided within SCA which allow a different component to provide a callback interface than the component which was the client to an original service invocation. 注：这里的than好像是排版错误，很难翻译？？？)，详见SCA Java Client and Implementation Specification（“Passing Conversational Services as Parameters”部分）。

　　1.5.3会话接口（Conversational Interfaces）

　　有时候服务（services）不能容易地被定义，因此每一个操作都是孤立的，而且和相同服务的其它操作是完全独立的。相反，为了达到一些更高层次的目标，必须要调用一个操作序列（operations sequence）。SCA把这一操作序列称为会话（conversation）。如果服务使用一个双向接口，会话可能包括操作和回调。

　　这样的会话服务使用会话标识符管理，标识符可以是应用数据（消息部分或操作参数）的一部分，或单独在应用数据（可能在报头里）中通信。（Such conversational services are typically managed by using conversation identifiers that are either (1) part of the application data (message parts or operation parameters) or 2) communicated separately from application data (possibly in headers) ，总感觉这个句子有问题，请大家赐教）。SCA引入了conversational interfaces概念来描述上面第二种会话服务的接口契约（contract）。有了这个形式，在部署时适当绑定的帮助下，运行时（runtime）自动管理会话成为可能。SCA不能使任何一个使用应用数据来维持会话服务的样式都符合标准，它们不能得到SCA会话服务支持的帮助，也不受SCA会话服务支持的阻碍。（Such services are neither helped nor hindered by SCA’s conversational service support ）

　　典型地，会话服务包括与正在进行的会话相关的状态数据（state data）。对于会话，状态数据的创建和管理对客户端和会话服务实现的开发都有重要的影响。

　　传统上，编写会话服务的应用开发人员需要写一些管道工程（plumbing）代码，他们需要：

　　选择或定义一个client与provider之间会话（相关）信息的通信协议

　　provider发送会话信息到一个能处理此会话的机器上，当处理并发数据访问时

　　在客户端编写代码使用或编码会话信息

　　在实现和客户端维持会话中特殊的状态，比如持久性（persistently）和事务处理（transactionally）

　　SCA把与会话服务相关的工作（effort）划分到一些角色中：

　　应用开发人员（Application Developer）：声明服务接口是会话的（协议的细节放到绑定（binding）去做）。使用生命周期（lifecycle）语义、APIs或其它的编程机制（像implementation-type定义的）来管理会话状态

　　应用集成人员（Application Assembler）：选择一个支持会话的绑定（binding）

　　绑定提供人员（Binding Provider）：实现一个协议，它能够通过每一个操作请求或响应传递会话信息

　　Implementation-Type提供人员：为应用开发人员访问会话信息定义APIs与（或）其它编程（programmatic）机制。可选地，基于binding的会话信息，实现生命周期语义自动管理implementation状态

　　此规范要求会话接口通过记号“conversational”标记。这种标记形式依赖于接口类型。注意，当使用一个没有标记为“conversational”意图的接口时，服务或引用将它设定为“conversational”意图是可能的。当重用一个已存在的接口定义（定义中不包含SCA信息）时，这一点是很有用的。

　　Conversational意图的含义是：客户端和接口提供者都可以假定消息（messages）将作为正在进行的会话的一部分被处理，而不依赖于消息体（如操作参数）里的识别信息。实际上，会话接口指定了一个高层次抽象协议，服务使用的任何实际binding/policy组合都要满足它。

　　支持会话接口的binding/policy组合的例子如下：

　　Web service binding with a WS-RM policy

　　Web service binding with a WS-Addressing policy

　　Web service binding with a WS-Context policy

　　JMS binding with a conversation policy that uses the JMS correlationID header

　　会话发生在一个客户端（client）和一个目标服务（service）之间。所以，一个客户端到多个目标会话服务的请求将会导致多个会话。例如，如果client A调用服务B和C，B和C都实现了会话接口，将会有两个会话结果，一个是A和B之间的，另一个是A和C之间的。同样，多个实现实例（implementation instances）上的流动请求也会导致多个会话。例如，一个请求先从A到B，然后从B到C，这将导致两个会话（A和B的，B和C的）。在前面的例子中，如果有一个从C到A的请求，则第三个会话就产生了（对于A来说，实现实例将会不用于原始请求的instance）。

　　一个会话接口的任何一个操作的调用都可能开始一个会话。一个操作能否开始一个会话依赖于组件的实现（implementation）和它的实现类型（type）。实现类型可能支持带有会话服务的组件。如果一个实现类型提供这种支持，那么它必须提供一个机制来决定一个操作什么时候可以使用一个新的会话（例如，在Java中，一个注入引用的第一次使用时，新的会话将开始；在BPEL中，当client的partnerLink进入到范围中）。

　　在一个会话接口中，1或多个操作使用一个endsConversation注解来注释（注释接口的机制依赖于接口类型）。在接口是双向接口的地方，操作也可以通过回调接口中操作被注释的方式被注释。当一个会话结束操作被调用的时候，它会对客户端和服务提供者表明这个会话完成了。在这之后，任何试图调用与此会话相关的操作或回调操作都会产生一个sca：
ConversationViolation错误。

　　sca：ConversationViolation错误在下列错误之一发生的时候被抛出：

　　在会话结束后，为了一个特殊的会话，接收了一个消息

　　会话标识符是无效的（不唯一，出界等）

　　会话标识符不在结束此会话的操作的输入信息里

　　在会话结束之后，客户端或服务试图在会话里发送信息

　　在SCA命名空间里，这个错误以一个标准的前缀“sca”命名，对应着URI http://gocom.primeton.com/blog9404_35328.htm