目录数据库处的数据管理制造技术

提供了一种用于在包括目录中的数据条目在内的目录数据库(302)处的数据管理的方法，所述方法包括以下步骤：将所述数据条目与表示所述数据条目在所述目录数据库处的第一当前存储状态的第一状态信息相关联(330)，从客户端(306)接收(336)修改所述数据条目的请求，与所述请求相关联地从所述客户端(306)接收(342)表示所述数据条目在所述目录数据库(302)处的第二当前存储状态的第二状态信息，所述第二当前存储状态指示所述数据条目对于所述客户端(306)可用的最新可用当前存储状态，以及如果关于所述数据条目在所述目录数据库(302)处的所述第一当前存储状态和从所述客户端(306)接收的所述第二当前存储状态确定所述第一状态信息和所述第二状态信息匹配，则根据所述请求来修改(340)所述数据条目。

【技术实现步骤摘要】
【国外来华专利技术】目录数据库处的数据管理
本专利技术涉及电信，具体地涉及用于在目录数据库处的数据管理的方法，且更具体地涉及在目录服务器侧强制执行的LDAP互斥机制。本专利技术还涉及目录数据库、计算机程序、计算机程序产品、客户端和通信系统。
技术介绍
当前，针对将要到来的3GPP版本9，正在对第3代合作伙伴项目(3GPP)用户数据汇聚(UDC，3GPP术语)进行标准化。提出了核心网(CN)100中的图1所示的新的架构，其中，将不同网络单元的订户服务相关数据和商务逻辑加以分离。这样，将用户数据仓库102(UDR，3GPP术语)用作集中式数据库，使得不同的应用前端106至110可以访问用户数据(通过新的“Ud”参考点112)。需要最小化由于引入UDC而产生的对现有网络的影响。当应用UDC架构时，诸如归属位置寄存器(HLR)/归属订户服务器(HSS)、认证中心(AuC)、应用服务器、供应(provisioning)系统等等之类的功能实体保持应用逻辑，但是他们不持久地本地存储用户数据。在UDC架构中，将这些无数据功能实体统称为应用前端(FE)106至110。现在已同意(阶段3活动正在进行中)轻量级目录访问协议(LDAP，互联网工程任务组(IETF)标准)作为要在针对CRUD(创建、读取、更新、删除)操作的Ud接口中使用的数据访问协议。根据UDC架构原则，每个应用-FE可以在任何时间管理任何订户相关的请求。且对于很多应用，可以并发地(即并行地)针对相同订户管理多于一个应用相关的过程(即，操作)。因此，可以存在以下情况：两个(或更多)不同的应用-FE实例正在管理针对严格相同的数据(即，在UDR中管理的严格相同的订户目录条目/属性)的两个(或更多)不同的应用相关请求。例如，一个3G移动订户正在归属网络上移动(因此，在核心网内部发出“位置更新”过程，以更新订户位置)，且同时相同的订户正在调用“订户过程”以改变针对(之前激活的)“无应答时的呼叫转移”补充服务的重定向号码。在前述示例中，两个不同的HLR-FE实例(管理发出的“移动应用部分(MAP，SS7栈)位置更新”过程的实例和管理调用的订户过程的实例)正在同时/接近同时尝试访问并修改在UDR中的严格相同的数据。存在很多其他的可以发生这种类型情况的网络使用情况。根据第一示例，供应-FE实体可以尝试更新订户简档(作为从客户管理系统(CAS)接收到供应命令的结果)，且同时应用-FE正在尝试更新严格相同的数据(或某些共同的部分)。根据第二示例，来自两个不同应用的两个不同的FE实例可以尝试修改相同订户简档的某些共同(对于两个应用而言)的数据。注意到：在前述示例列表中的第一使用情况(UC)(调用供应-FE实例)可能是发生的最一般的UC(因为其与以下过程无关：应用允许或不允许从两个或更多不同FE实例并行处理两个或更多与严格相同的订户相关的过程)。在所有这些类型的情况下，如果在UDR中不能保障某种互斥机制，则“数据一致性”问题可能发生，如图2的序列图更好地示出(将其作为图形化示例)：具体地，这种有问题的情况可能源于两个客户端(如HLR-FE206和供应-FE208)都请求修改目录数据库(如UDR202)处的数据条目。图2的示例序列图的步骤如下所述：在第一步骤216中，HLR-FE206从订户具体接收MAP位置更新。在另一步骤218中，HLR-FE206请求读取与该订户相关联的订户简档，且HLR-FE206向UDR202发送相应的LDAP搜索请求。因此，UDR202向进行请求的HLR-FE206发送相应的简档数据。于是，在另一步骤220中，HLR-FE206执行应用相关逻辑，并可以具体地处理接收到的该订户的简档数据。在下一步骤222中，供应-FE208从CAS具体接收供应命令。在下一步骤224中，供应-FE208请求读取与订户相关联的订户简档，并向UDR202发送相应的LDAP搜索请求。因此，UDR202向进行请求的供应-FE206发送相应的简档数据。于是，在另一步骤226中，供应-FE206执行应用相关逻辑，并可以具体地处理接收到的该订户的简档数据。在步骤228中，供应-FE208通过发送相应的LDAP修改请求，请求更新在UDR202处存储的订户简档。因此，UDR202更新该订户简档，并向供应-FE208发送与更新过程相关的信息，具体地，已更新的订户简档。在步骤230中，HLR-FE206通过发送相应的LDAP修改请求，也请求更新在UDR202处存储的订户简档。因此，UDR202也更新该订户简档，并向供应-FE208发送与更新过程相关的信息，具体地，已更新的订户简档。从而，在图2的步骤228中，(由供应-FE208)更新订户简档，使得由HLR-FE实例206管理的(在步骤216中读取的)简档从该时刻起变为“老”的简档。由HLR-FE206在步骤230中发出的最终更新操作并未考虑到在步骤228中所引入的改变，因此存在数据一致性风险(例如，在步骤228中引入的某些属性值可能在步骤230中被覆盖；备选地或附加地，在步骤228和230中，可以更新不同的数据(但是依然相关)，使得可以“破坏”应用级别上的数据一致性)。为了避免这些情况，当前已针对LDAP提出了一些解决方案，然而它们都具有同样的问题，因为它们全都要求在LDAP客户端中的用于帮助LDAP目录服务器(即，UDR)来检测更新冲突的特殊行为(以便能够触发与这些解决方案中每个解决方案相关联的互斥算法)。在所有这些解决方案中，LDAP服务器(即，必须确保其正在存储的数据的数据一致性属性的服务器)不是决定何时必须触发互斥机制的实体；最终，应用-FE才是决定何时触发互斥机制的实体(还提供所需数据，以执行相关联的互斥算法)。缺陷可以是：这些解决方案仅对于“带围墙的花园”环境(即LDAP目录服务器和LDAP客户端二者都属于相同运营商域的情况)有效，因为“解决方案所有者”要求对LDAP客户端行为的严格控制。另一缺陷可以是：这些解决方案是容易出错的解决方案，因为它们依赖于每个单体LDAP客户端的正确行为。又一缺陷可以是：在部署的分层架构中集成应用-FE可能是困难的、昂贵的、且消耗时间的，因为这些FE中包括的LDAP客户端必须适于遵守所需的正确行为。此外，这些解决方案可以伴随着未解决的供货商可互操作性问题，以及在尝试将部署的UDR与3PP应用-FE集成时所要解决的其他障碍。
技术实现思路
本专利技术的目标可以是提供用于管理在目录数据库处的数据管理的方法、目录数据库、计算机程序、计算机程序产品、客户端和通信系统，它们可以允许在目录数据库处的数据一致性，特别是在一个客户端或不同客户端对目录数据库进行多个次修改访问的情况下。为了实现上面定义的目标目的，提供了根据独立权利要求的用于管理在包括目录中的数据条目在内的目录数据库处的数据管理的方法、目录数据库、计算机程序、计算机程序产品、客户端和通信系统。根据本专利技术的示例方面，提供一种用于管理在包括目录中的数据条目在内的目录数据库处的数据管理的方法。具体地在目录数据库处执行的所述方法包括以下步骤：在第一步骤中，将所述数据条目与表示所述数据条目在所述目录数据库处的所述数据条目的第一当前存储状态的第一状态信息相关联。在另一步骤中，从客户端接收修改本文档来自技高网...

【技术保护点】

【技术特征摘要】
【国外来华专利技术】2010.02.11 US 61/303,4701.一种用于在包括目录中的数据条目在内的目录数据库(302、402、602、DB11)处的数据管理的方法，所述方法包括以下步骤：-将所述数据条目与表示所述数据条目在所述目录数据库(302、402、602、DB11)处的第一当前存储状态的第一状态信息相关联(330、430)，所述第一状态信息是存储表示数据条目的当前内容的值的数据，-向客户端(306、406、606、CL12)发送(332、334、348、350、432、434)所述第一状态信息，-与所述第一状态信息相关联地从客户端(306、406、606、CL12)接收(336、436、554、694)修改所述数据条目的请求，-与所述请求相关联地从所述客户端(306、406、606、CL12)接收(336、436、694)表示所述数据条目在所述目录数据库(302、402、602、DB11)处的第二当前存储状态的第二状态信息，所述第二当前存储状态指示所述数据条目对于所述客户端(306、406、606、CL12)可用的最新可用当前存储状态，以及-如果关于所述数据条目在所述目录数据库(302、402、602、DB11)处的所述第一当前存储状态和从所述客户端(306、406、606、CL12)接收的所述第二当前存储状态确定所述第一状态信息和所述第二状态信息匹配，则根据所述请求来修改(340、440、564、696)所述数据条目。2.根据权利要求1所述的方法，还包括以下步骤：-获得(340、440、658、696)表示修改后的数据条目在所述目录数据库(302、402、602、DB11)处的修改后的当前存储状态的第三状态信息，以及-将所述修改后的数据条目与所述第三状态信息相关联(340、440、568、696)。3.根据权利要求2所述的方法，还包括以下步骤：-向所述客户端(306、406、606、CL12)或另一客户端(308、408、608、CL12)发送(332、334、348、350、432、434)所述第三状态信息，-与所述第三状态信息相关联地从所述客户端(306、406、606、CL12)或所述另一客户端(308、408、608、CL12)接收(342、442、698)用于修改所述目录数据库(302、402、602、DB11)处的所述数据条目的另一请求，-与所述另一请求相关联地从所述客户端(306、406、606、CL12)或所述另一客户端(308、408、608、CL12)接收(342、442、698)表示所述数据条目在所述目录数据库(302、402、602、DB11)处的第四当前存储状态的第四状态信息，所述第四当前存储状态指示所述数据条目可用于所述客户端(306、406、606、CL12)或所述另一客户端(308、408、608、CL12)的最新可用当前存储状态，-关于所述数据条目在所述目录数据库(302、402、602、DB11)处的修改后的当前存储状态和从所述客户端(306、406、606、CL12)接收的所述第四当前存储状态确定(344、444、699)所述修改后的状态信息与所述第四状态信息不匹配，以及-通过不修改修改后的数据条目来拒绝(346、446、699)所述另一请求。4.根据权利要求3所述的方法，还包括以下步骤：-验证(556)所述客户端(306、406、606、CL12)和/或所述另一客户端(308、408、608、CL12)是否在所述目录数据库(302、402、602、DB11)处针对应用以下一项或多项进行了注册：匹配确定步骤、修改步骤和拒绝步骤。5.根据...

【专利技术属性】
技术研发人员：安东尼奥·阿隆索阿拉尔孔，埃米利亚诺·美利奴巴斯克斯，
申请(专利权)人：瑞典爱立信有限公司，
类型：
国别省市：