Service Capability Interaction Manager (SCIM)被作为IMS架构中SIP应用服务器领域中的一项功能引入了3GPP TS 23.002, Figure 6a: Functional architecture for the provision of service in the IMS。虽然3GPP Release 6规范中只用了一小段文字来描述该功能，但是很明显它具有重大意义——下面的常见问题显然需要一个解决方案，但是这类解决方案通常却是由供应商定义的，而该功能就是对这些解决方案的替代：管理大型网络中被表示为SIP应用服务器实例的“功能（部件）”(capability)之间的交互。

　　实际上，功能（部件）就是一个系统组件，用于（可能与其他组件一起）实现一个打包并交付给网络终端用户的“服务”。例如，一个群组列表服务器(group list server)和一个现场服务器都可以被视为用于实现复杂的电话会议服务的“功能（部件）”。

　　但是，要实现一个具有SCIM功能的专门的SIP应用服务器不是一件容易的事情。问题不在于所需的技术或专业知识——实际上这甚至不能预测。真正的问题在于缺乏对必须交互的服务功能的类型的标准定义。实际上，大多数商业网络已经包括了大量根据各种标准、使用各种在IMS出现之前就存在的技术构建的现有系统。有时候，服务提供商期望这些功能可以为新的IMS服务所用。有时候，服务提供商可能已经选择了以IT为中心的技术来实现可以在IMS环境中重用的功能。此时可以很明显地看出，术语SCIM实际是指一类功能而不是对这个范围相当广的问题的单个可执行解决方案。然而，可以推断的是，可能存在一些可被识别的特定SCIM类型。当然了，下面的分类建立在我与服务提供商的联系上，只代表我个人的意见，而且还存在许多灰色区域。

SCIM的可能类型包括：

AS Internal Function——被实现为本地执行环境中服务逻辑的请求调度程序。
这种类型的SCIM只是对SIP应用服务器功能的引用，用于基于SIP请求的属性有选择地调用特定的服务逻辑。例如，对于SIP Servlet API，SIP Servlet容器使用在应用程序的部署描述符中声明的Servlet映射规则来选择特定的Servlet，这些Servlet将被调用以接收给定的SIP请求对象。大多数SIP应用服务器会使用一种类似的机制来有选择地调用组件，但是这通常都是专有并且与所使用的实现技术紧密耦合的。

SIP Broker——用于管理实现SIP代理或用户代理的组件之间的交互性。
对于关注旨在最大限度地利用网络信令系统（控制平面）的全部功能的多供应商服务交付平台问题的网络架构师来说，这种类型的SCIM可能是最为直观的。此类实现通常牵涉到使用Back-to-Back (SIP) User Agent以及复杂的路由选择和排序规则引擎（通常在多个方面类似于Serving Call Session Control Function本身）。

Service Broker——用于管理使用WSDL和IMS网络的基于SOAP的抽象公开了的服务功能之间的交互性。
这种类型的SCIM必定涉及对SIP协议的抽象。SIP是用于核心网络(Serving Call Session Control Function)与相关的服务功能之间的IMS Service Control (ISC)接口。因为SIP通常不会被直接转换为SOAP消息（由于很多原因，这既不现实也不适合），所以，显而易见，对组件服务逻辑的调用基于对更适合于session-ess、消息传递的底层网络的抽象视图。这种类型的SCIM通常将服务之间的交互建模为业务流程。

Legacy/NGN——用于管理SIP特性与传统信令系统组件之间的交互。
这种类型的SCIM可能最不容易被视为一种“通用”解决方案，因为不同的电路交换核心网络实现所需的特定传统接口（从地区到地区、从供应商到供应商）相差甚远。在传统网络中，诸如语音邮件、呼叫显示、呼叫转移之类的特性是在特定于供应商的交换平台上实现的，通常支持INAP或CAMEL接口。这种类型的SCIM通常除了触发和路由选择功能外还包括协议映射功能。通常是与传统特性实现紧密耦合的，而且通常都是嵌入到传统的Feature Server中的。

Service-Type Optimized——针对一种特定的服务类型而不是一组特定的实现技术进行了优化的SCIM。
这种SCIM方法似乎正在引起业内人士尤其是传统的网络设备提供商的注意。为了提升信令效能，SCIM被与一些支持给定的服务类型中的常见信令过程的组件相集成。例如，“电话”SCIM将与一些组件的通用实现相集成，这些组件支持媒体类型协商、对用于电话的媒体服务器的控制、呼叫转移、呼叫等待、呼叫保留、分插(add/drop)媒体等标准过程。然后这些组件就被通过一些非特定于协议的接口向其他组件公开，通过这些接口可以引入附加的服务逻辑或内容，这允许“定制化”服务。这种方法基于一种观察得出的结论：在全双工媒体会话、半双工媒体会话和消息传递会话的工作流之间通常存在着明显的区别，并进一步假设这些类型的会话在系统的日常使用中不会转变为另一种。在这种情况下，电话会话可能包含分插参与者的功能，但是它很可能永远也不会成为功能完备的电话会议。在这种情况下，一群分享一个特别电话的同事可能会一致同意转向一个电话会议系统，从而启动一个全新的会话，这将（在底层）牵涉到一个完全不同的SCIM功能和一组完全不同的应用程序。

　　对于每一种类型的SCIM，以及对于SCIM的广义概念，最大的困难是缺乏一种清晰的IMS组件模型。如前所述，虽然IMS确实以一种个案(case-by-case)方式提供了许多线索和建议，但是对于一个典型的组件应该是什么样的以及它们应该如何交互还是没有确定的说法。SIP确实提供了一种强大的路由选择功能，这允许在一些情况下对应用程序组合使用面向方面方法。该功能在支持IMS的子系统（Home Subscriber Server功能和Call Session Control Function）中得到广泛使用，被当作一种手段来将操作系统方面从与任何给定的应用实现者或用户相关的功能性系统方面分离出来。这个组件“链”非常有用，但是并不真正适合于所有情况。

　　观察这个清单，可以发现很有意思的一点：SCIM功能的类型（除了“Service-Type Optimized”）似乎类似于作为IMS架构一部分而引入的Application Support功能和应用服务器的不同类型（TS 23.002, Figure 6a: Functional architecture for the provision of service in the IMS中阐明了该架构）。这暗示着，在某种程度上，基本3GPP Release 6规范中Serving CSCF与不同的AS类型之间的关系并不十分清楚。这种不确定性，加上几乎每次部署IMS时都存在着的对某种类型的SCIM的明显需求，大大提高了用于服务逻辑（特性或组件）、还可能用于Serving Call Session Control Function的灵活实现技术的价值。实际上，在小型的IMS或类似于IMS的部署中，将SCIM、Serving CSCF和Application Server容器等多个功能组合到单个实现中是一种明智的做法。

　　虽然通信业未来的长期发展方向还存在许多不确定性，但是对组件实现和交互问题的“应用中间件”方法可能会提供成本、灵活性和效能的最佳整体平衡。在很多情况下，特别是从近期和中期来看，应对SCIM挑战的理想解决方案将是使用一个常见编程模型和共享的执行环境实现所有的相关功能(Serving CSCF、SCIM以及服务组件)。

　　不同的通信服务提供商在对所使用的技术和要解决的业务问题的需求上存在着现实差异，这使得通信业无法在近期内达到真正的统一。虽然业内对SCIM问题的实质的争论似乎还将持续一段时间，但是对于以某种方式解决这个问题的产品无疑还是有很大的需求。

原文出处:http://dev2dev.bea.com/blog/mpalmete/archive/2006/02/service_capabil.html