什么是OSA
OSA（Open Service Architecture）是3GPP组织提出的用于快速部署业务的开放业务平台。 OSA引入了Internet上的应用开发模式，为IT应用与电信网的融合奠定了技术基础。OSA规范采用面向对象的方法，使用UML(UnifiedModelingLanguage)语言进行描述，而且API的实现基于中间件平台(例如，CORBA等)。这使得OSA的定义与网络技术无关，它只为业务的实现提供统一的抽象接口，由OSA开发的应用能在多种网络上运行。从根本上说，现有网络业务不能实现跨网移植的主要原因在于：业务的开发需要针对具体的网络，业务逻辑一般通过专有协议直接控制网络功能实体。因此，为特定网络开发的业务很难被移植到其他网络上去。另一方面，跨网智能业务的开发要求业务开发人员还需要对不同网络的底层通信网络协议都有深入的了解，这些因素抑制了业务的迅速开发，无法满足用户对业务需求快速增长的需要。由于OSA的定义与具体技术无关，因而具有网络独立性，基于OSA开发的应用能在多种网络上运行。因此，以OSA为基础可实现移动网络业务开放。
OSA的逻辑结构
OSA规定了服务访问的几个实体。如应用(Application)、应用服务器(ApplicationServer),服务使能服务器(ServerCapabilityServer/SCS),OSA框架(Framework)和核心网元(corenetworkelement)。
Applications部署在应用服务器上，可以基于任何标准的IT平台，使用SCS提供的标准接口API来进行核心服务的访问。其中在标准接口API的服务端实现SCS功能，在客户端实现应用(Application)。Application与SCS之间的通信，可以使用标准的、开放性的中间件，如通过CORBA技术来进行。
SCSs实际上是负责API具体实现的功能实体，即实现服务使能特性(ServiceCapabilityFeature,SCF)的接口类。SCS与核心网络元素进行交互，如HLR,MSC,SSP等。这样，一个SCS服务伺服程序就相当于进入核心网络的一个代理或一个网关。
OSAAPI规定了两大类接口：框架接口(frameworkinterface)和业务接口(serviceinterface),并都用CORBAIDL进行了模型的定义。其中：框架接口提供了支持利用服务接口访问网络服务的一些必需的功能，提供业务接口安全，管理性所必需的支持能力。如AAA认证、安全、服务注册、检测等功能。
业务接口，即ServiceCapabilityServer部分，提供应用访问网络能力和信息的接口。业务接口提供途径使应用可访问传统网络能力，如呼叫管理、消息、用户交互等，业务接口也包括减轻通信应用程序的通用应用接口。
在应用和SCS之间的通信是使用标准的IT中间件机制，如CORBA技术来实现的。这样,SCS是实现API的逻辑实体（即业务能力特性的接口类），它可能与核心网元进行交互。这些实体可能包含在归属位置寄存器（HLR）、移动交换中心（MSC）、业务交换点（SSP）中。所以SCS服务器可以看做是核心网络代理或者网关。一个SCS可以同时实现多个SCF。由于SCS是逻辑实体，因此它的实现不必一定是独立的单元。例如，基于内容计费SCF很可能由计费（Charging）和账务（Billing）管理服务器来提供。
OSA框架接口为应用提供了框架的能力。该实体是实现开放性的关键所在，它使得在传统IN范围之外实现开放、发现和集成新的业务特性成为可能。
OSA框架提供了SCF的基本接入能力，它结合分布技术可以支持应用的位置信息和各种业务情景。而且，框架允许多方提供业务，甚至可以包括非标准化的SCF,而这些业务能力是业务创新和区分的关键。框架由三大类不同的特性组成：可信度和安全管理、业务注册和检索功能以及完整性管理。其核心部分包括：信任和安全管理（鉴权）、SCF注册（新的SCF在框架中进行注册）、SCF工厂（创建新的SCF实例）、SCF发现（发现由运营商提供的SCF）o
OSA的工作流程
要理解OSA的工作流程，可以参考SCS的安装过程和应用使用SCS中提供的能力的流程（如图5-8所示）。假定SCS实现了多方呼叫SCF,其过程主要分为以下三步：
（1）注册新的SCF（Registration）
首先，SCF向框架请求注册接口（Registrationinterface）,框架将返回该接口的引用（步骤1~2）;接下来，多方呼叫控制SCS使用得到的该接口发布SCF的类型；而后，SCS将通过注册接口向框架提供自己的引用（称为业务工厂servicefactory）/步骤3）。这时，框架和SCS就互相了解了对方。
（2）建立该业务协定（SetupofServiceAgreement）
该步骤将建立允许应用使用SCS的环境。这里的条件之一是应用只允许使用最多有四方参与的呼叫，这些条件信息在“业务协定”（ServiceAgreement）中进行描述”
（3）建立通信。该步骤建立应用和SCS之间的通信连接
应用接触框架后可以使用发现接口（Discoveryinterface）来查找可用的SCF实现（步骤4~6）。假定这里应用想使用多方呼叫控制SCF,并且想使用最多有四方参与的呼叫。因此，应用将通过发现接口（Discoveryinterface）向框架发送请求，要求返回所有可以满足要求的多方呼叫的SCF实现，然后框架将通过业务协定（ServiceAgreement）确认是否可以使用。如果满足条件，框架将返回这些SCF的列表。例如，现在有两个呼叫控制的SCS,其中一个能够一次处理八方呼叫，一个可以一次处理六方呼叫。这样，应用可以从中选择处理六方呼叫的SCF（步骤7）,因为比较便宜。然后，框架将通过业务工厂接口（ServiceFactoryinterface）要求具体的SCS创建可用的SCF实例；框架同时也将发送SCF使用条件信息，例如，这里要求每次呼叫最多四方参与（步骤8）。这时SCS将创建SCF实例并且向应用返回框架的索引（步骤9~10）。这样，应用就可以开始使用多方呼叫控制SCF。
在应用使用每个SCF的时候都必须重复步骤6~10。要注意的是OSA支持的鉴权步骤（步骤1以及步骤4）在相同的域内可以忽略。例如，运营商为其框架添加新的SCS,或者应用在与框架、SCS相同的域中。 
OSA规范为每一个操作都定义了相应的CORBAIDL描述，并通过序列图、classview等UML建模方式对各操作进行了说明。
osa物理部署
提供OSAAPI功能的物理实体有多种类型，例如，交换机(switches)、IVR(InteractiveVoiceResponsesystem)>HLR(HomeLocationRegistrie)>GSSN(GPRSSupportNode)、计费服务器(billingserver)等。SCS只是逻辑的实体，并且在规范中并没有规定SCS是否是网络中的独立单元。原则上，SCS可以作为网络上一个独立的节点来部署，或者作为核心网络节点来部署。
如果SCS作为一个独立的节点来部署，这种情况下，在核心网络中支持业务的物理的子层可以明显区分。实现的方法有多种，一种是在单个物理节点中提供所有API的实现，通常被称为OSA的物理网关，它具有面向所有核心网实体的协议和接口；另一种是分布式方案，其中OSA网关节点包含了框架以及一些SCS组件，但是其他的SCS运行在不同的节点上。这就意味着OSA网关是一个逻辑概念的网关，其API实现可以运行在分布式的节点上，即不同的网络实体提供它们自己的APL这种方案是SCS作为单独节点以及核心网络提供SCF实现的混合。
原则上，如果在不同节点之间的中间件基础上开发，则所有的开发都是可能的。然而，有时可能不希望直接在核心网节点上开发SCS软件，尤其在最终用户的触发要根据用户位置、信令或者处理负荷来动态存储的情况下。此时，为了能够在用户启动它所感兴趣的事件时能够被触发，则在位于网络 中所有可能的节点应该能够建立和应用的通信。例如，一个移动用户可能根据位置来附着到移动网络中的任何业务交换机上。
由此可见，事实上可能有各种混合的实现情景。最可能的情况是：一个网关节点提供OAS框架，其中包括SCF的注册以及其他一些核心的SCS；其他的SCS分布在不同的节点上，在框架中进行注册。由于框架是关键的实体，因此实现框架的节点能够提供一般电信承载的性 
能，如要求达到99.999%的可用性。而采用CORBA技术，对于应用部署的灵活性都是非常适合的。并且，通过CORBA中间件可以屏蔽低层的异构性和分布性，以一种统一的方式来进行低层的访问及控制，并且可以通过软总线机制构建起服务器之间的集群平台。
应用服务器(ApplicationServer)
基于OSA的体系架构如图5-9所示。
Application部署在应用服务器上，可以基于标准的IT平台。服务使能服务器(ServiceCapabilityServer)向应用提供标准的OSAAPI接口。应用服务器使用SCS提供的标准接口API来进行核心网络的访问，如HLR,MSC,SSP等。其中在标准接口API的服务端实现SCS功能，在客户端实现应用。应用服务器和服务使能服务器(SCS)可以在同一个业务域或不同的业务域内。Application与SCS之间的通信，可以使用标准的、开放性的中间件,如通过CORBA技术来进行。
从图5-9中可以看出，SCS的部署很可能是分布式的。因此，像CORBA这样的技术是非常适合的，在这之上构建应用服务器。通过应用服务器，可以隐藏低层的分布细节，同时向应用开发者提供标准的编程环境，并可以选择熟悉的语言。而CORBA的技术特点，非常适合应用服务器的构建，并可以通过组件封装继承的机制，向应用开发者提供更快速有效的开发方式。
