开放业务和开放移动体系结构中的迁移支持机制 【技术领域】
本发明涉及开放业务体系结构，更具体地，涉及用于在开放业务体系结构中帮助应用从一个业务启动器迁移到另一个业务启动器的方法。
背景技术
在现今的网络中，应用和业务是网络运营者域的一部分，并且使用智能网络技术构建。这种途径对于简单的销售量大的应用是很好的，但是随着移动性和互联网协议的出现，迅速使用创新的、结合不同特征和关键企业数据的应用成为一种挑战。
许多工业论坛和标准化实体，例如Parlay和3GPP，已经应对这个挑战，并且规定了充当应用和核心网络之间接口地API(应用程序接口)。术语开放业务体系结构是指由Parlay、3GPP和ETSI开发的API组。在开放业务体系结构内部，存在一种OSA内的应用可以预订的基础机制，以便当可以获得新的业务能力特征(SCF)时，应用会被通知。然而，这个机制并没有提供有关新的SCF对应用当前所使用的现有SCF到底向后兼容到什么程度的指示。因此，在开放业务体系结构内部存在对于一种将新SCF与现有SCF的兼容性通知给应用的机制的需要。
【发明内容】
本发明通过用于在开放业务体系结构中第一和第二业务之间迁移的系统和方法，克服了上述以及其他的问题。第二业务向开放业务体系结构框架注册，并且响应于该注册，而在第二业务的性质与第一业务的性质之间进行比较，以确定第二业务是否与第一业务向后兼容。在比较之后，将关于第二业务是否与第一业务向后兼容的信息转发给使用第一业务的至少一个应用。
【附图说明】
通过参考下面的详细说明连同附图，可以获得对本发明的方法和设备的更加完整的理解，其中：
图1说明第三代逻辑网络体系结构；
图2说明开放业务体系结构的概览；
图3说明OSA框架的各种功能性；
图4说明开放业务体系结构内部的应用的业务注册；以及
图5是说明本发明的方法的流程图，用于帮助应用迁移到新的SCF。
【具体实施方式】
现在参看图1，第三代网络的网络体系结构是基于水平分层原理，其中应用40和应用服务器45逻辑上在上层得到，被称为应用或业务网络10。术语业务网络用于将它和位于下层的核心网络15区分开。业务网络10基于开放分布式技术(JAVA，CORBA)，并且应用能够通过开放和标准化应用程序接口(API)20访问核心网络功能性，通过该接口它们可以与一个或多个业务能力服务器(SCS)50进行通信。SCS 50可以与各种网络相连接，例如移动网络5、IP网络6和/或固定网络7。
在图2中所示的分层体系结构中，开放业务体系结构(OSA)包括在业务网络10和核心网络15之间的应用程序接口。虽然本发明是关于由Parlay、3GPP和ETSI规定的开放业务体系结构进行描述的，但本发明也适用于基于web服务的方法，其中具体实现细节可能和OSA中的有点不同。在应用服务器45上使用的应用40利用由业务能力服务器(SCS)50提供的业务能力特征。业务能力服务器50是实现业务能力特征(SCF)35并与核心网络15相互作用的逻辑实体。如前所述，应用40和应用服务器45位于业务网络层10的内部。因此，可以看出，开放业务体系结构30在业务网络层10和核心网络层15之间充当API。
OSA框架55是注册和发现服务器，并且它使能开放系统体系结构的开放，以及当它如下所述的变为开放、发现和集成新的特征时，使其超出IN(智能网络)成为可能。OSA框架55还将开放业务体系结构30内部新业务能力特征的增加通知给应用。0SA框架55提供到SCS 50的受控访问，其与分布式技术相结合来支持商业场景中的应用位置的灵活性。此外，它允许多卖主关系(multi-vendorship)，以及甚至API组的扩展。
如图3所示，OSA框架55实际上是带有核心部分的一族业务能力特征35，其中核心部分包括使能域鉴权的信任和安全管理60；使能发现由运营者提供的新SCF的业务发现65；提供新SCF到框架的注册的业务注册70；以及使能创建新SCF实例的业务工厂75。此外，为例如负载均衡、故障管理和心跳(heart beat)的完整性管理80及提供特殊事件的通知的事件通知85而提供API。
现在参看图4，说明应用能够开始使用由新的业务能力服务器(SCS)50提供的SCF 35的方式。在第一阶段，在步骤90和95，SCS 50将与OSA框架55联系，并请求一个鉴权和注册接口。接着，在步骤100，SCS 50使用该注册接口以公布它的能力，并增加一个引用到它的业务工厂。工厂模式是通用设计模式，并且允许OSA框架55去请求SCS 50创建SCF 35接口。在这个时刻，OSA框架55和SCS 50知道彼此。
在步骤105，应用40与OSA框架55联系并被鉴权。在步骤110，应用40请求一个发现接口。OSA框架55返回一个到该发现接口的引用或指针，之后在步骤115，该应用40使用此接口来请求SCF 35的类型以及应用40所需要的特殊能力。这时，OSA框架55跟踪应用40是否被允许使用SCF 35以及在什么样的条件下使用。这在网络运营者和业务提供者之间的业务级别协定(SLA)中捕获。如果该应用被允许使用SCF35，则OSA框架55返回能够满足该应用需要的SCF 35的所有ID。
接着，在步骤120，应用40选择SCF 35中的一个，并签署所谓的业务协定。在步骤125，OSA框架55与SCS 50的业务工厂联系，并转发允许应用使用SCF 35的条件。在步骤130，SCS 50创建一个SCF 35实例，该实例被这个应用使用，并且也能够检查条件，且在步骤135，框架将该参考或指针返回给应用。根据这个转发的指针，该应用被授权使用SCF 35。虽然这个被描述的注册和发现过程使得框架能够将各种可用的SCF 35通知给应用，并且经由通知接口通知新的SCS 50的潜在可用性，但是不存在用于将新的SCF 35与先前存在的SCF 35的向后兼容性通知给应用的机制。应用可以使用框架55上的事件通知API来预订到各事件。事件的一个例子是何时使SCF成为可用的。
现在参看图5，这里说明用于确定SCF的向后兼容性的方法。当一个新的SCF被变成可用的时，该SCF必须首先在步骤150向OSA框架55注册，如先前关于图4所述的。在这个过程期间，在步骤155，SCF将由该SCF的这个实现支持的性质提供给OSA框架55。OSA框架55具有关于在特殊网络运营者域内的每个可用的现有SCF实现的信息、关于使用它们的应用的信息，以及由业务级别协定施加的使用SCF的限制。使用此信息，OSA框架便能够在步骤160执行有关新的SCF实现的性质相对于先前存在的版本的检查。在这个检查中，获得关于新的SCF实现对网络使用的SCF的其他版本向后兼容到什么程度的指示。在步骤165，这个信息连同对于新SCS的接口的任选的引用，被转发到使用SCF先前版本的应用。为了提供到该接口的引用，将利用当前框架通知机制的扩展。该框架通知机制可以由专用业务性质来指导，这些性质指定该SCF实现去替换或使特定的更旧的SCF实现过时，或指定一个迁移策略。关于向后兼容性级别的信息、该SCF实现替换或使更旧的SCF过时的事实、迁移策略等可以由新的SCS提供，并经由框架发送到应用，或者在当它注册时分析新的SCS的性质之后由框架提供，或者由它们两个的结合提供。
通过这个被描述的扩展的实现，可以使能在更旧的和更新的SCF实现之间的无缝迁移或应用。这将允许运营者几乎是自动地使SCF过时或更新SCF。它还将通过把应用引导到一个备份SCF而允许运营者从业务中取出一个SCF，以用于保持活动性。
先前的说明是实现本发明的一个优选实施例，并且本发明的范围不应一定被这个说明所限制。而是本发明的范围由所附的权利要求书所限定。