目录数据库处的数据管理的制作方法

专利名称：目录数据库处的数据管理的制作方法
技术领域：
本发明涉及电信，具体地涉及用于在目录数据库处的数据管理的方法，且更具体地涉及在目录服务器侧强制执行的LDAP互斥机制。本发明还涉及目录数据库、计算机程序、计算机程序产品、客户端和通信系统。
背景技术：
当前，针对将要到来的3GPP版本9，正在对第3代合作伙伴项目(3GPP)用户数据汇聚(UDC，3GPP术语)进行标准化。提出了核心网(CN)IOO中的图I所示的新的架构，其中，将不同网络单元的订户服务相关数据和商务逻辑加以分离。这样，将用户数据仓库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-FE 206和供应-FE 208)都请求修改目录数据库(如UDR 202)处的数据条目。图2的示例序列图的步骤如下所述在第一步骤216中，HLR-FE 206从订户具体接收MAP位置更新。在另ー步骤218中，HLR-FE 206请求读取与该订户相关联的订户简档，且HLR-FE 206向UDR 202发送相应的LDAP搜索请求。因此，UDR 202向进行请求的HLR-FE 206发送相应的简档数据。于是，在另ー步骤220中，HLR-FE 206执行应用相关逻辑，并可以具体地处理接收到的该订户的简档数据。在下ー步骤222中，供应-FE 208从CAS具体接收供应命令。在下ー步骤224中，供应-FE 208请求读取与订户相关联的订户简档，井向UDR 202发送相应的LDAP搜索请 求。因此，UDR 202向进行请求的供应-FE 206发送相应的简档数据。于是，在另ー步骤226中，供应-FE 206执行应用相关逻辑，并可以具体地处理接收到的该订户的简档数据。在步骤228中，供应-FE 208通过发送相应的LDAP修改请求，请求更新在UDR 202处存储的订户简档。因此，M)R 202更新该订户简档，井向供应-FE 208发送与更新过程相关的信息，具体地，已更新的订户简档。在步骤230中，HLR-FE 206通过发送相应的LDAP修改请求，也请求更新在UDR202处存储的订户简档。因此，UDR 202也更新该订户简档，井向供应-FE 208发送与更新过程相关的信息，具体地，已更新的订户简档。从而，在图2的步骤228中，(由供应-FE 208)更新订户简档，使得由HLR-FE实例206管理的(在步骤216中读取的)简档从该时刻起变为“老”的简档。由HLR-FE 206在步骤230中发出的最終更新操作并未考虑到在步骤228中所引入的改变，因此存在数据一致性风险(例如，在步骤228中引入的某些属性值可能在步骤230中被覆盖；备选地或附加地，在步骤228和230中，可以更新不同的数据(但是依然相关)，使得可以“破坏”应用级别上的数据一致性)。为了避免这些情况，当前已针对LDAP提出了一些解决方案，然而它们都具有同样的问题，因为它们全都要求在LDAP客户端中的用于帮助LDAP目录服务器(即，UDR)来检测更新冲突的特殊行为(以便能够触发与这些解决方案中每个解决方案相关联的互斥算法)。在所有这些解决方案中，LDAP服务器(即，必须确保其正在存储的数据的数据一致性属性的服务器)不是决定何时必须触发互斥机制的实体；最終，应用-FE才是决定何时触发互斥机制的实体(还提供所需数据，以执行相关联的互斥算法)。缺陷可以是这些解决方案仅对干“带围墙的花园”环境(即LDAP目录服务器和LDAP客户端二者都属于相同运营商域的情況)有效，因为“解决方案所有者”要求对LDAP客户端行为的严格控制。另ー缺陷可以是这些解决方案是容易出错的解决方案，因为它们依赖于每个单体LDAP客户端的正确行为。又ー缺陷可以是在部署的分层架构中集成应用-FE可能是困难的、昂贵的、且消耗时间的，因为这些FE中包括的LDAP客户端必须适于遵守所需的正确行为。此外，这些解决方案可以伴随着未解決的供货商可互操作性问题，以及在尝试将部署的UDR与3PP应用-FE集成时所要解决的其他障碍。

发明内容
本发明的目标可以是提供用于管理在目录数据库处的数据管理的方法、目录数据库、计算机程序、计算机程序产品、客户端和通信系统，它们可以允许在目录数据库处的数据一致性，特别是在一个客户端或不同客户端对目录数据库进行多个次修改访问的情况下。为了实现上面定义的目标目的，提供了根据独立权利要求的用于管理在包括目录中的数据条目在内的目录数据库处的数据管理的方法、目录数据库、计算机程序、计算机程序产品、客户端和通信系统。根据本发明的示例方面，提供一种用于管理在包括目录中的数据条目在内的目录数据库处的数据管理的方法。具体地在目录数据库处执行的所述方法包括以下步骤在第ー步骤中，将所述数据条目与表示所述数据条目在所述目录数据库处的所述数据条目的第一当前存储状态的第一状态信息相关联。在另ー步骤中，从客户端接收修改所述数据条目的请求。在又ー步骤中，与所述请求相关联地从所述客户端接收表示所述数据条目在所述 目录数据库处的第二当前存储状态的第二状态信息。所述第二当前存储状态指示所述数据条目对于所述客户端可用的最新可用当前存储状态。在又ー步骤中，如果关于所述数据条目在所述目录数据库处的所述第一当前存储状态和从所述客户端接收的所述第二当前存储状态确定所述第一状态信息和所述第二状态信息匹配，则根据所述请求来修改所述数据条目。根据本发明的另ー示例方面，一种目录数据库适于执行上述用于在包括目录中的数据条目在内的目录数据库处的数据管理的方法的步骤。根据本发明的另ー示例方面，一种要由目录数据库的处理单元执行的计算机程序包括适于执行上述用于在包括目录中的数据条目在内的目录数据库处的数据管理的方法的步骤的代码。根据本发明的另一方面，提供ー种用于在包括目录中的数据条目在内的目录数据库处的数据管理的方法。具体地在客户端处执行的所述方法包括以下步骤。接收表示所述数据条目在所述目录数据库处的第一当前存储状态的第一状态信息。基于所述第一状态信息，将表示所述数据条目在所述目录数据库处的第二当前存储状态的第二状态信息与修改所述数据条目的请求相关联。所述第二当前存储状态指示所述数据条目对于所述客户端可用的最新可用当前存储状态。此外，发送与所述第二状态信息相关联地修改所述数据条目的请求。根据本发明的另ー示例方法，一种客户端适于执行上段中描述的用于在包括目录中的数据条目在内的目录数据库处的数据管理的方法的步骤。根据本发明的另ー示例方面，ー种通信系统包括均如前所述的目录数据库和至少一个客户端。在从属权利要求中定义了以下各项的其他实施例用于在目录数据库处的数据管理的方法、目录数据库、计算机程序、计算机程序产品、客户端以及通信系统。


下面将參考示例来更详细地描述本发明的实施例，但是本发明的范围不局限于这些示例。图I是示出了采用3GPP用户数据汇聚的通信架构的框图。图2是示出了在HLR前端实体、供应前端实体和用户数据仓库之间的通信的流程图。图3是示出了根据本发明的示例实施例的用于在目录数据库处的数据管理的方法的流程图。图4是示出了根据本发明的另ー示例实施例的用于在目录数据库处的数据管理的方法的流程图。图5是示出了根据本发明的另ー示例实施例的用于在目录数据库处的数据管理的方法的流程图。 图6是示出了根据本发明的另ー示例实施例的用于在目录数据库处的数据管理的方法的流程图。图7示出了框图，该框图示出了根据本发明的示例实施例的目录数据库的构成。图8示出了框图，该框图示出了根据本发明的示例实施例的客户端的构成。
具体实施例方式附图中的说明是示意性的。在不同附图中，相似或相同的単元具有相同的附图标记。下面，将描述根据本发明的示例实施例的用于在目录数据库处的数据管理的方法。ー种用于管理在包括目录中的数据条目在内的目录数据库处的数据的方法可以包括具体地在目录数据库处执行的以下步骤将所述数据条目与表示所述数据条目在所述目录数据库处的第一当前存储状态的第一状态信息相关联，从客户端接收修改所述数据条目的请求，与所述请求相关联地从所述客户端接收表示所述数据条目在所述目录数据库处的第二当前存储状态的第二状态信息，所述第二当前存储状态指示所述数据条目对于所述客户端可用的最新可用当前存储状态，以及如果关于所述数据条目在所述目录数据库处的所述第一当前存储状态和从所述客户端接收的所述第二当前存储状态确定所述第一状态信息和所述第二状态信息匹配，则根据所述请求来修改所述数据条目。该方法可以帮助目录数据库针对并发数据访问场景来强制执行数据完整性。为了更好的说明，下面描述示例和解释-目录数据库的示例可以是UDR或LDAP服务器。-可以将“目录数据库”理解为特殊仓库技术，其以逻辑和分级的方式对管理的数据对象(包括其自身的(关联的)属性实例)进行组织。3GPP UDC版本9将UDR功能单元定义为对于所有应用前端(FE)实例都共同的“目录数据库”。-数据条目的示例可以是订户简档。-注意到在ー些示例目录数据库中，可以将数据条目表示为目录条目。-注意到可以将单一订户简档定义和管理(在目录DB中)为单一“目录条目”或目录条目的集合(由于目录DB不对“目录条目”是什么强加任何语义限制)。
-表示在目录数据库处的数据条目(例如，特定的“目录条目”)的当前存储状态的信息的示例是entryDigest(条目摘要)值。-EntryDigest可以是以单一意思方式来表示在该目录条目中包含的属性实例中存储的当前值的值(或值的集合)。例如，可以从在涉及的目录条目中所有包含的属性值中获得(与每个目录条目相关联的)摘要值。-修改请求的示例可以是LDAP修改请求。-匹配的示例可以是如果确定第一和第二当前状态信息相同(这是典型情况)，其他条件可以用于匹配。例如，第一当前状态信息可以表示与第二当前状态信息相匹配的间隔，即，第二当前状态信息被确定落入所述间隔中。然而，由于实现的容易性以及安全性原因，“相等匹配”可以是优选的，因为检查从执行的上一次读操作开始是否已由任何其他客户端更新了目录条目是非常合适的条件。具体地在图5的检查框(checkbox) 562中示出了匹配检查的示例，即，“在(条目“,的)属性“ entryDigest”中存储的当前值是否等于在断言过滤器中接收到的〈值〉”。如果将其评估为“是”，即确定匹配，则修改数据条目，即， “处理接收到的LDAP修改请求操作”，具体地如图5中框564所示。如果将其评估为“否”，确定不匹配，则拒绝接收到的修改请求操作，具体地如图5中框576所示(还參见下面呈现的权利要求3以及具体地參见图5的描述)。具体地，作为表示数据条目的当前存储状态的信息的示例的“entryDigest”可以是与数据条目(具体地，数据条目的对象)相关联的參数(具体地，操作属性)。具体地，可以由目录数据库内部管理entryDigest。例如，目录数据库可以确定要与数据条目关联存储的entryDigest的值。具体地,可以在数据条目的创建时将entryDigest分配给数据条目，或在数据条目的配置时(例如在修改数据条目的值时)可以分配entryDigest。具体地，可以使用基于数据条目的内容(具体地基干与数据条目相关联的另ー參数(具体地，属性))向EntryDigest (參数)分配单ー意思值的函数,来产生entryDigest值。具体地,可以在entryDigest的产生过程中排除或不考虑entryDigest的值。具体地，这种函数可以是散列函数，且entryDigest的值可以是数(具体地，整数)。接下来，将描述用于在目录数据库处的数据管理的方法的示例实施例。然而，这些实施例也适用于如在“发明内容”部分和“具体实施方式
”部分中描述的相应目录数据库、相应通信系统、相应计算机程序、相应计算机程序产品、相应客户端方法、以及相应客户端。该方法还可以包括以下步骤获得表示在所述目录数据库处的修改后的数据条目的修改后的当前存储状态的第三状态信息，以及将所述修改后的数据条目与所述第三状态信息相关联。示例可以如下所述在根据修改请求修改了数据条目之后，第三状态信息取代第一状态信息。该“修改后的当前存储状态”表示在应用所请求的更新之后的数据条目的当前存储状态。该方法还可以包括以下步骤从所述客户端或另ー客户端接收修改在所述目录数据库处的所述数据条目的另ー请求，与所述另ー请求相关联地从所述客户端或所述另ー客户端接收表示所述数据条目的在所述目录数据库处的第四当前存储状态的第四状态信息，所述第四当前存储状态指示所述数据条目可用于所述客户端或所述另ー客户端的最新可用当前存储状态，关于所述数据条目在所述目录数据库处的修改后的当前存储状态和从所述客户端接收的所述第四当前存储状态确定所述修改后的状态信息与所述第四状态信息不匹配，以及通过不修改修改后的数据条目来拒绝另一修改请求。该方法还可以包括以下步骤验证所述客户端和/或所述另ー客户端是否在所述目录数据库处针对应用以下一项或多项进行了注册匹配确定步骤、修改步骤和拒绝步骤。示例可以是类似干“要在LDAP客户端“c”上应用互斥(mutex)机制？ ”的检查，具体地如图5中检查框556所示。目录数据库可以接收客户端和/或另ー客户端的客户端识别数据，以执行验证步骤，例如，以确定客户端“c”是否真的是“c”或客户端“c”是否属于被授权进行这些操作的客户端的组。具体地，还可以将该互斥机制表示为互斥控制(Ctrl)机制。该方法还可以包括以下步骤验证所述数据条目是否在所述目录数据库处针对应用以下一项或多项进行了注册匹配确定步骤、修改步骤和拒绝步骤。
该数据条目可以与标识符相关联，该标识符指示必须在实际处理或进行至确定匹配的步骤之前执行该验证，以及取决于该验证检查的結果，目录数据库进行对数据条目的修改或对请求的拒绝。这种标识符的示例可以仅仅是表示与数据条目相关联的任何当前存储状态的任何状态信息的存在性，备选地，其可以是具有指示需要验证的预定义值(例如，永久性)的额外标识符，例如，标志(flag)。示例可以是类似干“在条目“e”上应用互斥机制？ ”的检查，具体地如图5中检查框558所示。可以在数据条目创建时创建标识符，并将其与数据条目相关联。还可以在任何时刻(只要数据条目已经存在)配置该标识符，以指示是否应用所述操作。该方法还可以包括以下步骤管理所述第一状态信息和/或所述第三状态信息，使得所述客户端和所述另ー客户端中的任何客户端不能修改所述第一状态信息和/或所述第二状态信息。具体地，所述目录数据库可以确定是否“在条目“e”中执行某种改变”，且可以相应地更新条目“e”中的entryDigest值，并可以存储更新后的值，如图5的检查框566和框568所示。该方法还可以包括以下步骤向所述客户端和所述另ー客户端分别发送在包括所述第一状态信息、所述第二状态信息、所述第三状态信息和所述第四状态信息在内的组中的至少ー个状态信息，所述客户端和所述另ー客户端分别被配置为处理接收到的至少ー个状态信息，以与请求修改的所述请求和所述另ー请求分别相关联地向所述目录数据库发送。例如，在图6中的步骤684或690中，向作为另ー客户端和客户端的示例的HLR-FE和供应-FE分别发送作为状态信息的示例的条目摘要信息。在该方法中，可以根据LDAP来执行涉及在所述目录数据库和所述客户端和/或所述另ー客户端之间的接收和/或发送的至少ー个步骤。在该方法中，所述修改请求和/或所述另一修改请求可以包括LDAP断言控制，所述LDAP断言控制分别包括所述第二状态信息和所述第四状态信息。在本申请的上下文中，术语“LDAP断言控制”可以与术语“LDAP断言扩展控制”作为同义词来使用。下面，将描述根据本发明的示例实施例的目录数据库。所述目录数据库可以适于执行上述用于在目录数据库处的数据管理的方法。具体地，所述目录数据库可以适于将所述数据条目与表示所述数据条目在所述目录数据库处的第一当前存储状态的第一状态信息相关联。另外，所述目录数据库可以适于从客户端接收修改所述数据条目的请求，以及与所述请求相关联地从所述客户端接收表示所述数据条目在所述目录数据库处的第二当前存储状态的第二状态信息。所述第二当前存储状态指示所述数据条目对于所述客户端可用的最新可用当前存储状态。另外，所述目录数据库可以适于如果关于所述数据条目在所述目录数据库处的所述第一当前存储状态和从所述客户端接收的所述第二当前存储状态可以确定所述第一状态信息和所述第二状态信息匹配，则根据所述请求来修改所述数据条目。本发明还涉及包括软件代码的部分在内的计算机程序，以在目录数据库处操作时实现上述方法。可以将所述计算机程序存储在计算机可读介质上。计算机可读介质可以是目录数据库中的或位于外部的永久性或可重写存储器。还可以经由例如电缆或无线链路将所述计算机程序作为信号序列传输至目录数据库。要由目录数据库的处理单元执行的计算机程序可以包括适于执行上述用于在目 录数据库处的数据管理的方法的步骤的代码。计算机程序产品可以包括如上所述的计算机程序。 下面，将用于在包括目录中的数据条目在内的目录数据库处的数据管理的方法描述为具体地由客户端来执行。所述方法可以包括以下步骤接收表示所述数据条目在所述目录数据库处的第一当前存储状态的第一状态信息，基于所述第一状态信息，将表示所述数据条目在所述目录数据库处的第二当前存储状态的第二状态信息与修改所述数据条目的请求相关联，所述第二当前存储状态指示所述数据条目对于所述客户端可用的最新可用当前存储状态，以及发送与所述第二状态信息相关联地修改所述数据条目的请求。接下来，将解释在之前段落中描述的方法的示例实施例。然而，这些实施例也适用于如在“发明内容”部分和“具体实施方式
”部分中描述的用于在目录数据库处的数据管理 的相应方法、相应目录数据库、相应计算机程序、相应计算机程序产品、相应客户端、以及相应通信系统。该方法可以包括其他步骤在所述客户端的存储单元中存储所述第一状态信息，以及从所述存储単元中检索所述第一状态信息，以及将所述第二状态信息基于所述第一状态ィ目息。可以根据轻量级目录访问协议来执行涉及在所述目录数据库和所述客户端之间的接收和/或发送的至少ー个步骤。因此，修改请求可以包括轻量级目录访问协议断言控制，所述轻量级目录访问协议断言控制包括所述第二状态信息。下面，将描述根据本发明的示例实施例的客户端。所述客户端可以适于执行如上面针对客户端所述的用于在目录数据库处的数据管理的方法。具体地，所述客户端可以适于接收表示数据条目在目录数据库处的第一当前存储状态的第一状态信息，基于所述第一状态信息，将表示所述数据条目在所述目录数据库处的第二当前存储状态的第二状态信息与修改所述数据条目的请求相关联，所述第二当前存储状态指示所述数据条目对于所述客户端可用的最新可用当前存储状态，以及发送与所述第二状态信息相关联地修改所述数据条目的请求。下面，将描述根据本发明的示例实施例的通信系统。通信系统可以包括根据如上所述的本发明的示例实施例的目录数据库和也如上所述的至少ー个客户端。此外，所述通信系统可以包括请求修改在所述目录数据库处的所述数据条目的另ー客户端。具体地，所述客户端和/或所述另ー客户端可以与修改所述数据条目的(另一)请求相关联地发送相应的状态信息。具体地，所述通信系统中的通信可以基于LDAP。可以在用户数据合并(UDC)解决方案中的中央用户数据库(CUDB)中实现本发明，存储针对应用(例如，HLR、AuC、HSS等等)的与用户应用相关的数据。CUDB可以扮演商务UDC解决方案中的(3GPP标准)UDR角色。參见图3和4，将分别描述根据本发明的第一和第二示例实施例的用于在目录数据库处的数据管理的方法。图3示出了在目录数据库302、客户端306、以及另一客户端308之间传输消息以及在相应设备处执行操作的第一实施例。目录数据库302、客户端306和另ー客户端308形成了通信系统314。
在目录数据库302处的第一当前存储状态的第一状态信息相关联。具体地，之前已由目录数据库302产生第一状态信息。在其他步骤332和334中，目录数据库302向客户端306和另ー客户端308分别发送数据条目的第一状态信息。客户端306和另ー客户端308可以在客户端306和另ー客户端308各自的存储单元中分别存储接收到的第一状态信息。接下来，在步骤336中，客户端306发送包括第二状态信息在内的修改数据条目的请求。第二状态信息是如下基于第一状态信息的客户端308从存储単元中检索第一状态信息，并基于检索到的第一状态信息来获得第二状态信息。第二状态信息表示数据条目在目录数据库302处的第二当前存储状态，其中，第二当前存储状态指示数据条目对于客户端306可用的最新可用当前存储状态。在该实施例中，第一和第二状态信息可以相同。在下ー步骤338中，目录数据库302执行对在目录数据库302处的第一状态信息和来自(具体地为接收)客户端306的接收到的第二状态信息的匹配的确定。根据该实施例，第二状态信息等于第一状态信息，匹配确定是肯定的。具体地，可以将该确定评估为“是”。然后目录数据库302执行对在目录数据库302处的数据条目的修改，且具体地更新在数据条目中存储的相应数据，例如值。这导致在目录数据库302处的修改后的数据条目。此外，目录数据库302执行对与数据条目相关联的第一状态信息的修改，导致与修改后的数据条目相关联的第三状态信息。接下来，在步骤342中，另ー客户端308向目录数据库302发送修改数据条目的另ー请求。另ー请求包括第四状态信息。第四状态信息是如下基于第一状态信息的另ー客户端308从其存储单元中检索第一状态信息，并基于检索到的第一状态信息获得第四状态信息。第四状态信息表示数据条目在目录数据库302处的第四当前存储状态，其中，第四当前存储装置指示数据条目对于另一客户端308可用的最新可用当前存储状态。在本实施例中，第一和第四状态信息也可以相同。在下ー步骤344中，目录数据库302执行对在目录数据库302处的第三状态信息和来自(具体地为接收)另ー客户端308的接收到的第四状态信息的不匹配的确定。根据该实施例，第四状态信息等于已经过期的、且同时已被第三状态信息所替换的第一状态信息，匹配确定不是肯定的。具体地，可以将该确定评估为“否”。在下ー步骤346中，则目录数据库302拒绝从另一客户端308接收的另一修改请求。在步骤348和350中，目录数据库302向客户端306和另ー客户端308分别发送修改后的数据条目的第三状态信息。然后客户端306和另ー客户端308可以在其存储单元中存储接收到的第三状态信息。图4示出了在目录数据库402、客户端406、以及另一客户端408之间传输消息以及在相应设备处执行操作的第二实施例。目录数据库402、客户端406和另ー客户端408形成了通信系统414。在第一步骤430中，目录数据库402将目录数据库402处的数据条目与表示数据条目在目录数据库402处的第一当前存储状态的第一状态信息相关联。具体地，之前已由 目录数据库402产生第一状态信息。在下ー步骤431中，客户端406向目录数据库402发送读取数据条目的请求。在步骤432中，目录数据库402向客户端406发送包括与数据条目相关联的第一状态信息和具体地数据条目的数据在内的读取响应消息。客户端406可以在客户端406的存储单元中存储接收到的第一状态信息。在下ー步骤433中，另ー客户端408向目录数据库402发送读取数据条目的请求。在步骤434中，目录数据库402向另ー客户端406发送包括数据条目的第一状态信息和具体地数据条目的数据在内的读取响应消息。另ー客户端406也可以在另一客户端406的存储单元中存储接收到的第一状态信息。接下来，在步骤436中，客户端306发送包括第二状态信息在内的修改数据条目的请求。如上面參考图3所述的，第二状态信息基于第一状态信息，并标识数据条目在目录数据库402处的第二当前存储状态，其中，第二当前存储状态指示数据条目对于客户端406可用的最新可用当前存储状态。在该实施例中，第一和第二状态信息可以包括不同的格式，这可以是由于将第二状态信息基于第一状态信息的过程所产生的。在下ー步骤438中，目录数据库402执行对在目录数据库402处的第一状态信息和来自(具体地为接收)客户端406的接收到的第二状态信息的匹配的确定。根据该实施例，第二状态信息等于第一状态信息，匹配确定是肯定的。具体地，如以參考图3所声明的，这对应于导致“是”的确定。在下ー步骤440中，则目录数据库402执行对在目录数据库402处的数据条目的修改，且具体地更新在数据条目中存储的相应数据，例如值。这导致在目录数据库402处的修改后的数据条目。此外，目录数据库402执行对与数据条目相关联的第一状态信息的修改，导致与修改后的数据条目相关联的第三状态信息。在另ー步骤441中，则目录数据库402向客户端302发送修改响应，且具体地使用序列“结果0K”来肯定应答对数据条目的已执行的修改。接下来，在步骤442中，另ー客户端408发送包括第四状态信息在内的修改数据条目的另ー请求。如參考图3的步骤342所解释的，第四状态信息是基于第一状态信息的，且表示数据条目在目录数据库402处的第四当前存储状态，其中，第四当前存储状态指示数据条目对于另一客户端408可用的最新可用当前存储状态。在本实施例中，第一和第四状态信息可以包括不同的格式，这可以是由于将第二状态信息基于第一状态信息的过程所产生的。在下ー步骤444中，目录数据库402执行对在目录数据库402处的第三状态信息和来自(具体地为接收)另ー客户端408的接收到的第四状态信息的不匹配的确定。根据该实施例，第四状态信息等于已经过期的、且同时已被第三状态信息所替换的第一状态信息，匹配确定不是肯定的。具体地，评估确定结果为“否”。在步骤446中，目录数据库402相应地拒绝另一修改请求。因此，在步骤452中，目录数据库402向另ー客户端408发送包括内容“拒绝結果”在内的修改响应，以向另ー客户端408指示匹配确定的结果不是肯定的，且具体地拒绝对另ー修改请求的处理。在第二实施例中(图4)，如客户端406、408所请求的，目录服务器402仅向客户端406,408发送数据(这是来自“客户端” 406和“另ー客户端” 408的第一读取请求的原因， 因此他们可以获得当前的“第I存储状态”，具体地如图4的步骤431至434所说明的)。在图3中，在第一实施例中(取代实施例2(图4)的具有请求-响应的拉回机制)，使用推送机制，例如目录数据库302向客户端306、308推送数据条目的第I状态信息，类似于第3状态信息，具体地如步骤332、334、348、350所说明的。要注意，数据条目的状态信息优选地可与客户端306、308、406、408处的数据条目相关，以使得客户端306、308、406、408能够将状态信息与以下信息相关联与在包括状态信息在内的修改数据条目的请求中请求修改所针对的数据条目相关的信息。由于是目录302、402(DB)将该值与和条目相关联的当前存储状态进行比较(在“客户端” 306、406的情况下是第I存储状态信息，以及在“另ー客户端” 308、408的情况下是第3存储状态信息，具体地如图3和4的步骤338、344、438、444所说明的)，客户端/另一客户端306、308、406、408发送之前读取的第一存储状态(附加到修改请求，作为第2/第4存储状态信息，具体地如图3和4的步骤336、342、436、442所说明的)。客户端306、308、406、408接收数据条目的第I状态信息，并在存储单元中存储该信息。当需要修改数据条目吋，客户端306、308、406、408检索所存储的状态信息，并将其与修改数据条目的请求相关联(例如，将其附加或包括到请求中)，以及将其发送至目录数据库302、402，以请求修改数据条目(具体地，如图3和4的步骤336、342、436、442所说明的)。通常，第I和第2以及第4状态信息是相同的，例如具有相同的值。然而，可以存在第I和第2以及第I和第4状态信息不相同的实现，例如，相应信息具有不同的格式，以例如将第I状态信息在相应客户端306、308、406、408处分别存储为第2状态信息和第4状态信息。在下ー步骤中，根据存储的格式来检索它们(具体地，分别是第一、第二和第四状态信息)，并将它们关联(例如，附加或包括)到相应的修改请求消息，并发送至被配置为不管不同格式而分别确定匹配和不匹配的目录数据库302、402 (具体地，如图3和4中步骤336、338、342、344、436、438、442、444所说明的)。客户端306、308、406、408可以具有与图7所示的目录数据库DBll类似的结构特征。在第二实施例中(图4)，从客户端406、408要求修改响应(指示成功或错误)，所以可以完成“修改过程”(具体地，如图4的步骤441、452中所说明)。在第一实施例中，可以通过发送第3状态信息来暗示修改响应(指示成功和错误)(具体地，如图3的步骤348、350所说明的)，使得客户端306、308具有根据针对该数据条目的稍后修改请求的修改而可用的最当前的状态信息(未示出)。从目录数据库302向客户端306和另ー客户端308发送的第一实施例中的消息可以包括与第二实施例中一样的信息，以分别显式地指示成功和失败。下面，将參考图5、6和7来描述·根据本发明的其他示例实施例的用于在目录数据库处的数据管理的方法。在根据本发明的示例实施例的方法中，主要的目标是定义LDAP可用互斥机制，其在LDAP目录服务器侧(即，UDR)中管理、执行以及强制执行，并且不依赖于所有完全的LDAP客户端遵守正确的行为(因为从LDAP目录服务器侧也识别和拒绝“错误的”客户端行为)。具体地，当接收修改在目录数据库处的数据条目的请求时，可能存在用于在目录数据库处进行数据管理的需要，具体地，与是否根据目录数据库提出的约束向目录数据库发出接收到的修改请求无关。具体地，在该上下文中，术语“客户端的正确行为”可以表示客户端发送根据目录数据库提出的约束的相应修改请求，且术语“客户端的错误行为”可以表示客户端发送未根据目录数据库所提出的约束的相应修改请求。本发明不限于符合3GPP UDC版本9的环境。其对于目录数据库的任何实现都有效，大体是基于LDAP的环境，其中，必须控制客户端的并发性(为了说明，本发明完全基于LDAP概念，但不限于此)。在呈现的解决方案中，是LDAP目录服务器侧对可能出现数据一致性风险的这些条目强制执行互斥(mutex)机制，且(仅)针对所选LDAP客户端。并且这是在与来自向这些目录条目发出“LDAP修改请求”操作的LDAP客户端的正确或错误行为无关地情况下完成的。具体地，目录数据库(比如LDAP服务器)可以确保根据目录数据库的配置从客户端(如LDAP客户端)接收的修改请求可以导致对修改请求的正确处理。因此，为了满足目录数据库的具体配置的要求，可以将发出修改请求的客户端修改为能够发送正确的修改请求(根据目录数据库配置)。具体地，在该上下文中，术语“客户端的正确行为”可以表示客户端发送根据与对接收到的修改请求的处理或不处理相关联的目录数据库的配置的相应修改请求，以及术语“客户端的错误行为”可以表示客户端发送未根据与对接收到的修改请求的处理或不处理相关联的目录数据库的配置的相应修改请求。具体地，目录数据库的配置可以具体地表示如上定义的用于应用互斥机制的客户端的注册、根据如上定义的互斥机制的可修改的数据条目的配置、以及在从客户端发送修改请求时将修改请求与状态信息(如“ entryDigest”值)相关联。具体地，客户端的正确和错误行为可以分别表示客户端发送与状态信息相关联和不与状态信息相关联的修改请求。下面，描述用于正确实现该机制的在(i)配置阶段[步骤I]、(ii)供应阶段[步骤2]和(iii)业务阶段[步骤3]处的所需步骤。在[步骤I]配置阶段中，执行LDAP目录服务器侧中的LDAP客户端“互斥配置”。为了建立针对标准LDAP目录服务器的LDAP会话，始終需要某些客户端配置存储在LDAP目录服务器侧(例如，要由LDAP客户端在LDAP会话建立时使用的至少“用户名”和加密或摘要“密码”)。提出了包括一些新的配置数据(例如，在存储客户证书的目录条目中)，其中，指定针对从这些客户端中的每个客户端发出的“LDAP修改请求”是否必须应用(或必须不应用)互斥机制。建议的实现可以包括在要添加到客户端-证书目录条目中的新的辅助对象类(objectclass)中包含的新LDAP属性类型(attributeType)(语法布尔型)。如果该属性不存在，或如果其被设为值“伪”，则对于从该LDAP客户端发出的更新操作，将不应用互斥。在[步骤2]供应阶段中，执行在目录条目创建时的LDAP条目“互斥启用”。对于创建的每个新的目录条目(通过“LDAP添加请求”操作)，规定是否要求(或不要求)对向该条目发出的“LDAP修改请求”操作执行互斥。在条目中要求互斥机制的情况下，仅在从一被配置为“针对其进行检查”的“LDAP”客户端发出的针对该条目的修改操作时才应用(參见上面[步骤I]和下面[步骤3]中的一般算法)。此外，对于这些目录条目中的每ー个目录条目，目录服务器必须管理(内部)某些数据(此处称为“entryDigest”数据)，该数据存储以下值 -不能被任何LDAP客户端修改(但是始終可以被读取-当不被从任何访问控制指令(ACI)所限制时-如果是，通过“LDAP搜索请求”操作，通过LDAP客户端)。注意到将始終有可能定义(通过配置过程)某个特权用户(其被允许请求“更新/设置”该内部数据(例如，供应实体、目录根用户等等))，然而对干“普通”(即不是这种特权)客户端，修改是不可能的。-每次对相关联的条目正确应用“LDAP修改请求”操作时被内部更新(因此在内部“ entryDigest”元素中存储的值将表示当前的目录条目内容，一旦改变了在相同条目中包含的其他属性类型中的至少ー个中的某些存储值，就改变其值)。建议的实现可以包括被定义(和管理)为由目录服务器内部维护的、且LDAP客户端不能修改的操作属性的“entryDigest” (參见在http://tools. ietf. org/html/rfc4512#section-3. 4上可找到的LDAP目录信息模型(IETF RFC 4512)中的第3. 4节)。将要添加(或不添加)到每个创建的目录条目中的新的辅助对象类中可以包含它。当该新的对象类将出现在目录条目中时，其将意味着针对向该条目发出的更新操作必须强制执行互斥机制。可以用语法“整数，存储根据整个当前条目内容计算出的散列值”来定义“entryDigest” 属性类型。在[步骤3]业务阶段中，执行在LDAP服务器侧处的“互斥”强制执行。当在LDAP目录服务器中接收到“LDAP修改请求”操作时，如果(当且仅当)以下两个条件匹配，则应用互斥机制I、从已被配置为必须针对从其发出的操作应用互斥检查的LDAP客户端接收到它(參见[步骤I])。2、针对该互斥检查，已配置了目标目录条目(在创建时)(參见[步骤2])。在该情况下(但是仅在该情况下)，要求在目录服务器中接收到的每个“LDAP修改请求”操作包括“LDAP断言控制”。在http://tools. ietf. org/html/rfc4528上可以找到LDAP断言控制(IETF RFC4528)，其内容以引用的方式并入本文中，其描述到由LDAP客户端发出的“LDAP修改请求”操作可以包括断言控制以及在LDAP服务器侧要检查的条件；如果不满足该条件，可以拒绝整个“LDAP修改请求”操作。因此，新的“LDAP断言扩展控制”包含以下断言条件
“entryDigest = <last-entryDigest-read-value-for-target_entry>，，如果在接收到的“LDAP修改请求”操作中不包括该等式过滤器，则拒绝整个修改请求。如果在LDAP断言中包括的等式过滤器评估为“伪”，则拒绝整个修改操作(根据RFC 4528)。如果LDAP断言中包括的等式过滤器评估为“真”，则正常处理接收到的“LDAP修改请求”操作(根据 LDAP :在 http://tools. ietf. org/html/rfc4511 上可找到的协议(IETF RFC 4511))，其内容以引用的方式并入本文中，且如果(在目标条目中)最終添加/刪除/替换了ー些值，则产生新的值(由目录服务器内部产生)，并将其存储为该目录条目的新的计算出的“entryDigest”数据。參见图5，示出了整个流程图，其描述了针对正在接收到的每个“LDAP修改请求”操作在LDAP目录服务器侧处所需的额外处理步骤。具体地，图5示出了根据本发明的另ー示例实施例的用于数据管理的方法的过程。由目录数据库来执行这些过程步骤。在由框554指示的第一步骤中，从名为“c”的LDAP客户端接收针对名为“e”的目录条目的LDAP修改请求操作。在由检查框556指示的下ー步骤中，确定是否对LDAP客户端“c”应用互斥机制。如果该确定是肯定的且导致“是”，则在由检查框558指示的下一歩骤中，确定是否对条目“e”应用互斥机制。如果该确定是肯定的且导致“是”，则在由检查框560指示的下ー步骤中,确定接收到的操作是否包括携带过滤器“entryDigest =值”的LDAP断言控制。如果检查框560的确定是肯定的且导致“是”，则在由检查框562指示的下ー步骤中，确定在与条目“ e”相关联的属性“ entryDigest”中存储的当前值是否等于(作为匹配的示例)在断言过滤器中接收到的具体〈値〉。如果该确定是肯定的且因此导致“是”，则在由框564指示的下ー步骤中，相应地处理接收到的LDAP修改请求操作。接下来，在由检查框566指示的步骤中，进ー步确定在条目“e”中是否已执行了某个(些)改变。如果该确定是肯定的且导致“是”，则在由框568指示的下ー步骤中，产生条目“e”中的“entryDigest”属性的新值，并将其与改变后的条目“e”相关联地存储。之后，过程如圆570所指示地结束。取决于检查框556、558、560、562、566的确定结果，还可以执行以下步骤，其中，关于检查框556和558，在由“否(备选I)”和“否(备选2)”表示的2个实施例之间加以区分。在根据检查框556和558的确定之ー不是肯定的且导致“否(备选I) ”的情况下，过程可以进行至框564，且可以相应处理接收到的LDAP修改请求操作。之后，过程可以如所述ー样的进行。备选地，在根据检查框556和558的确定之ー不是肯定的且导致“否(备选2) ”的情况下，方法进行至由框572指示的步骤，其中，处理接收到的LDAP修改请求操作。之后，方法可以如圆574所指示地结束。对于两个备选，根据检查框556和558的确定可以帮助区分与客户端类型(注册客户端对非注册客户端)和被请求修改的数据条目的类型(配置用于根据互斥方法来修改的数据条目和未配置用于根据互斥方法来修改的数据条目)相关的目录数据库的预配置。备选I和备选2都导致对接收到的LDAP修改请求操作的处理。然而，对于备选1，根据556额外检查是否已改变了条目“e”,且如果是,则如框568所指示的,修改entryDigest属性并将其与改变后的条目“ e”相关联地存储。尽管备选2可能对于传统实现是令人感兴趣的，但备选I更安全且提供了更好的数据一致性。因此备选I符合任何接收到的LDAP断言所需的一般过程，然而此处缺少检查框562的步骤，因为在“否(备选I) ”的情况下，不需要针对未启用互斥的客户端和目录条目来检查在检查框562中规定的条件。此外，在根据检查框560的确定不是肯定的情况下，该方法可以进行至由框576指示的步骤，其中，拒绝接收到的LDAP修改请求操作。之后，该方法可以如圆578所指示的结束。从而，根据检查框560的确定可以帮助区分具有“正确行为”和“错误行为”的客户端，例如，以在发送了具有过滤器和不具有过滤器的修改请求的客户端之间进行区分。此外，在根据检查框562的确定不是肯定的且导致“否”的情况下，该方法可以进行至由框576和圆578所指示的步骤，即，拒绝接收到的LDAP修改请求操作且方法停止。 此外，在根据检查框566的确定不是肯定的且导致“否”的情况下，该方法可以直接进行至圆570，并可以相应结束。注意到根据检查框562、框564、576和圆578的步骤的集合可以表示任何接收到的LDAP断言所需的一般过程。这些步骤可以具体地对应于对接收到的断言过滤器的检查。此处，该集合由580来表示且由虚线来指示。注意到，可以针对目录条目的属性而不是目录条目本身来执行上述确定。參见图6,所示序列图示出了參考图5所具体描述的机制如何能够检测到冲突。具体地，在目录数据库602、客户端606和另ー客户端608之间传输相应消息，以及在相应设备处执行操作。此处，仅为了说明的目的，将客户端606体现为HLR-FE实体，且将另ー客户端608体现为供应-FE实体。目录数据库602、客户端606、以及另一客户端608形成了通信系统614。在第一步骤682中，HLR-FE 606从订户具体地接收MAP位置更新。接下来，在步骤684中，从HLR-FE 606向UDR 602发送用于读取订户简档的LDAP搜索请求。注意到已从UDR 602请求了当前的“ entryDigest”值,使得UDR 602可以仅向HLR-FE 606发送与所请求的订户简档相关的信息。接下来，在步骤686中，HLR-FE 606具体地基于接收到的订户简档信息，执行与应用相关的逻辑。在下ー步骤688中，供应-FE 608从CAS具体地接收供应命令。在下ー步骤690中，供应-FE 608向UDR 602发送用于读取具体地存储在UDR602中的订户简档的LDAP搜索请求。此处，已向UDR602请求了当前的“entryDigest”值，使得UDR 602可以相应地向供应-FE 608发送与订户简档相关的数据以及之前请求的entryDigest 值。在下ー步骤692中，供应-FE 608执行与应用相关的逻辑。在下ー步骤694中，供应-FE 608向TOR 602发送用于更新订户简档的LDAP修改请求消息。在所发送的请求消息中，还包括断言控制过滤器“entryDigest =在步骤690中读取的值”。
在下ー步骤696中，UDR 602执行断言检查(例如，使用图5的检查框562所说明的步骤)。所执行的断言检查是肯定的，以相应处理所请求的修改操作(例如，如图5的框564所指示的)。此外，在更新在UDR 602处的数据条目中存储的订户简档时，还更新该数据条目的“entryDigest”值的值(类似于图5的检查框566和框568)。在下ー步骤中，可以从UDR 602向供应-FE 608发送更新后的订户简档的信息和更新后的“entryDigest”值。在下ー步骤698中，HLR-FE 606向TOR 602发送用于更新订户简档的LDAP修改请求。在该请求消息中包括断言控制过滤器“entryDigest =在步骤684中读取的值”。接下来，在步骤699中，UDR 602执行断言检查(例如，使用在图5的检查框562中说明的步骤)，并评估接收到的“entryDigest”值与UDR 602中可用的“entryDigest”值不匹配。因此，拒绝所请求的修改操作，例如根据框576和圆578。此外，不更新数据条目的“entryDigest” 值。 在下ー步骤中，UDR 602相应地向HLR-FE 606通知拒绝的修改请求。此外，注意到执行步骤686，同时执行步骤690至696。注意到在图6中，已假定⑴针对目标条目，已启用了互斥机制以及(ii)已配置了 2个LDAP客户端606、608 (HLR-FE 606和供应-FE 608)，使得必须对它们应用互斥。一旦已解释了本互斥机制，依然可以包括某些扩展/改进。这些扩展和改进不改变所述互斥方法，但是可以被视为该互斥方法的其他实施例。在修改中，(每个目录条目-在条目创建吋-或可以在目录服务器级别上-在配置吋)，可以将属性类型的集合(来自可以在目录条目中包含的那些属性类型)定义为在改变包含的值时，不触发任何“entryDigest ”更新。具体地，目录条目可以与多个属性或属性类型相关联。ー个属性类型(例如，目录条目的属性类型“e”)或多个属性类型可以与entryDigest相关联。然而，多个属性类型的集合可以不与entryDigest相关联。因此,对ー个或多个属性类型的修改可以强制对entryDigest值的更新,但是对属性类型的定义集合的修改可以不强制对entryDigest的更新操作。从而，可以在互斥机制中实现如果在基于上述属性类型的定义所具体获得的列表中不包括某些属性类型，则互斥机制将不“分析”仅请求更新这些属性类型(中的ー些)的任何“LDAP修改请求”操作。具体地，当接收修改请求吋，目录数据库可以仅对于那些被配置为应用与entryDigest相关联的互斥机制的属性类型才应用互斥机制。在互斥机制中，可以忽略那些未被配置为应用互斥机制的属性类型(且从而不与entryDigest相关联)。此外，可以针对每个目录条目定义多于ー个“entryDigest”元素，其中，每个“entryDigest”元素可以与该条目中包含的属性类型的子集相关联。具体地，目录条目与多于ー个属性或属性类型相关联。这些属性类型的组与entryDigest相关联,且剩余的属性类型可以与另一 entryDigest相关联。在修改属性类型的组中的ー个属性类型的情况下，可以更新与属性类型的组相关联的entryDigest的值，而不更新另ー个entryDigest的值。因此,在修改剩余属性类型(之一)的情况下，可以更新与剩余属性类型相关联的另ー entryDigest的值,而不更新entryDigest的值。
从而，定义的属性类型的每个组被针对其关联的“ entryDigest”元素所“支配”，其可以允许在每个目录条目中的某种更细颗粒的互斥机制。这可以允许增加并行的水平，且不将在该上下文中定义的互斥机制与目录条目的范围绑定。下面，将描述根据本发明的示例实施例的目录数据库的构成。在第一示例实施例中，目录数据库可以包括接收单元、存储单元、处理单元以及可选地发送単元。參见图7，将解释根据本发明的另ー示例实施例的目录数据库DBll的构成。在图7中示出了包括接收单元RUlI、处理单元PUlI、存储单元SUlI和发送单元TUlI在内的目录数据库DBll的实施例。接收单元RUll可以适于接收消息和信息，如修改请求和状态信息，存储单元SUll可以适于(永久性或临时性)在目录中存储数据条目以及状态信息和标识符等等，以及发送単元TUll可以适于发送消息和信息，如向客户端发送信息，以及处理单元PUll可以适于处理接收信息和消息以及发送信息和消息，并在目录数据库DBll处的存储单元SUll的目录中存储或检索或修改数据条目。 处理单元PUl I可以适于将数据条目与表示数据条目在目录数据库处的第一当前存储状态的第一状态信息相关联。接收单元RUll可以适于从客户端接收修改该数据条目的请求。接收单元RUll还可以适于与该请求相关联地从客户端接收表示数据条目在目录数据库处的第二当前存储状态的第二状态信息，第二当前存储状态指示数据条目对于客户端可用的最新可用当前存储状态。处理单元PUl I可以适于如果处理単元PUl I关于数据条目在目录数据库处的第一当前存储状态和从客户端接收的第二当前存储状态确定第一状态信息和第二状态信息匹配，则根据该请求来修改数据条目。根据实施例，处理单元TOll可以适于获得表示修改后的数据条目在目录数据库处的修改后的当前存储状态的第三状态信息，并将修改后的数据条目与第三状态信息相关联。根据另ー实施例，接收单元RUll可以适于从客户端或另ー客户端接收修改数据条目在目录数据库处的另ー请求，以及与另ー请求相关联地从客户端或另ー客户端接收表示数据条目在目录数据库处的第四当前存储状态的第四状态信息，第四当前存储状态指示数据条目可用于客户端或另ー客户端的最新可用当前存储状态。处理单元PUll可以适于关于数据条目在目录数据库处的修改后的当前存储状态和从客户端接收到的第四当前存储状态确定修改后的状态信息与第四状态信息不匹配，以及通过不修改修改后的数据条目来拒绝另一修改请求。根据另ー实施例，处理单元TOll可以适于验证客户端和/或另ー客户端是否在目录数据库中针对应用匹配确定步骤、修改步骤和拒绝步骤中的一个或多个进行了注册。根据另ー实施例，处理单元TOll可以适于验证数据条目是否在目录数据库中针对应用匹配确定步骤、修改步骤和拒绝步骤中的一个或多个进行了注册。根据另ー实施例，处理单元TOll可以适于管理第一状态信息和/或第三状态信息，使得客户端和另ー客户端中的任何客户端都不能修改第一状态信息和/或第三状态信
O根据另ー实施例，发送单元TUll可以适于向客户端和另ー客户端分别发送在包括第一状态信息、第二状态信息、第三状态信息和第四状态信息在内的组中的至少ー个状态信息，客户端和另ー客户端分别被配置为处理接收到的至少ー个状态信息，以与针对请求修改的请求和另ー请求分别相关联地向目录数据库发送。根据另ー实施例，处理单元TOll可以适于根据轻量级目录访问协议来执行涉及在目录数据库和客户端和/或另ー客户端之间的接收和/或发送的至少ー个步骤。因此，修改请求和/或另一修改请求可以包括轻量级目录访问协议断言控制，轻量级目录访问协议断言控制分别包括第二状态信息和第四状态信息。下面，将描述根据本发明的示例实施例的客户端的构成。在第一示例实施例中，客户端可以包括接收单元、处理单元和发送单元，以及可能的存储单元。參见图8，将解释根据本发明的另ー示例实施例的客户端CL12的构成。客户端CL12可以具有与图7所示的目录数据库DBll和上述相似的结构特征。 客户端CL12的实施例包括与图7中针对目录数据库DBll所述相类似的接收单元RU12、处理单元PU12、存储单元SU12以及发送单元TU12。接收单元RU12可以适于接收消息和信息，存储单元SU12可以适于(永久性或临时性)存储信息(如数据条目的状态信息)，以及发送単元TU12可以适于发送消息和信息，以及处理单元TO12可以适于处理接收信息和消息以及发送信息和消息，并存储或检索存储单元SU12中的信息。具体地，接收单元RU12可以适于接收表示数据条目在目录数据库处的第一当前存储状态的第一状态信息。处理单元PU12可以适于基于第一状态信息，将表示数据条目在目录数据库处的第二当前存储状态的第二状态信息与修改数据条目的请求相关联，第ニ当前存储状态指示数据条目对于客户端可用的最新可用当前存储状态。此外，发送单元TU12可以适于向目录数据库发送与第二状态信息相关联的修改数据条目的请求。根据实施例，处理单元TO12可以适于在客户端的存储单元SU12中存储第一状态信息，以及从存储单元SU12中检索第一状态信息，以及将第二状态信息基于第一状态信息，即，可以用以下方式来处理检索到的第一状态信息其形成了第二状态信息的基础，例如，可以将第一状态信息格式化为第二状态信息。如上面已经详细解释的，第一和第二状态信息可以相同，即从存储单元SU12检索到的信息形成了第二状态信息的相同基础。根据实施例，处理单元PU12可以适于根据轻量级目录访问协议来执行涉及在目录数据库和客户端之间的接收和/或发送的至少ー个步骤。因此，修改请求包括轻量级目录访问协议断言控制，轻量级目录访问协议断言控制包括第二状态信息。下面，将描述本发明的一些优点。在目录数据库侧的目录服务器侧上控制互斥机制，且与正确/错误的LDAP客户端行为无关。从而，由目录数据库而不是客户端来具体地触发或发起互斥机制，因为目录服务器可以设置与互斥机制结合使用的数据条目和客户端相关的目录数据库的预配置。不需要对LDAP协议进行改变，因为可以使用与在LDAP相关的RFC中定义的LDAP消息、操作和序列严格相同的LDAP消息、操作和序列。因此，从协议的角度来说，可以确保后向兼容性。新的互斥方法还允许基于访问目录服务的应用的性质(即，来自“应用侧”的并发要求)和/或正在被访问的目录服务器中存储的数据的性质(即，来自“数据侧”的并发要求)，来管理不同的并发水平，例如，它们都来自相同的目录服务器以及在相同的时间上。此夕卜，在与3GPP UDC版本9中当今管理的基于“LDAP交易”的解决方案进行比较时，可以增加 并发性/并行性。
权利要求
1.一种用于在包括目录中的数据条目在内的目录数据库(302、402、602、DB11)处的数据管理的方法，所述方法包括以下步骤 -将所述数据条目与表示所述数据条目在所述目录数据库(302、402、602、DB11)处的第一当前存储状态的第一状态信息相关联(330、430)，-从客户端(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.根据权利要求I所述的方法，还包括以下步骤 -获得(340、440、658、696)表示修改后的数据条目在所述目录数据库(302、402、602、DB11)处的修改后的当前存储状态的第三状态信息，以及 -将所述修改后的数据条目与所述第三状态信息相关联(340、440、568、696)。
3.根据权利要求2所述的方法，还包括以下步骤 -从所述客户端(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.根据前述权利要求中任一项所述的方法，还包括以下步骤 -验证(556)所述客户端(306、406、606、CL12)和/或所述另ー客户端(308、408、608、CL12)是否在所述目录数据库(302、402、602、DB11)处针对应用以下一项或多项进行了注册匹配确定步骤、修改步骤和拒绝步骤。
5.根据前述权利要求中任一项所述的方法，还包括以下步骤 -验证(558)所述数据条目是否在所述目录数据库(302、402、602、DB11)处针对应用以下一项或多项进行了注册匹配确定步骤、修改步骤和拒绝步骤。
6.根据前述权利要求中任一项所述的方法，还包括以下步骤 -管理所述第一状态信息和/或所述第三状态信息，使得所述客户端(306、406、606、CL12)和所述另ー客户端(308、408、608、CL12)中的任何客户端不能修改所述第一状态信息和/或所述第二状态息。
7.根据前述权利要求中任一项所述的方法，还包括以下步骤 -向所述客户端(306、406、606、CL12)和所述另ー客户端(308、408、608、CL12)分别发送(332、334、348、350、432、434)在包括所述第一状态信息、所述第二状态信息、所述第三状态信息和所述第四状态信息在内的组中的至少ー个状态信息，所述客户端(306、406、606、CL12)和所述另ー客户端(308、408、608、CL12)分别被配置为处理接收到的至少ー个状态信息，以与请求修改的所述请求和所述另ー请求分别相关联地向所述目录数据库(302、402、602、DB11)发送。
8.根据前述权利要求中任一项所述的方法，其中，根据轻量级目录访问协议来执行涉及在所述目录数据库(302、402、602、DB11)和所述客户端(306、406、606、CL12)和/或所述另ー客户端(308、408、608、CL12)之间的接收和/或发送的至少ー个步骤。
9.根据权利要求8所述的方法，其中，所述修改请求和/或所述另一修改请求包括轻量级目录访问协议断言控制，所述轻量级目录访问协议断言控制分别包括所述第二状态信息和所述第四状态信息。
10.一种目录数据库(302、402、602、DB11)，适于执行根据前述权利要求中任一项所述的步骤。
11.根据权利要求10所述的目录数据库(302、402、602、DB11)，所述目录数据库(DBll)包括接收单元(RUll)、存储单元(SUll)、处理单元(PUll)和可选的发送単元(TUll)。
12.—种要由目录数据库(302、402、602、DB11)的处理单元(PUll)执行的计算机程序，所述计算机程序包括适于执行根据权利要求I至9中任一项所述的方法的步骤的代码。
13.一种计算机程序产品，包括根据权利要求12所述的计算机程序。
14.一种用于在包括目录中的数据条目在内的目录数据库(302、402、602、DB11)处的数据管理的方法，所述方法包括以下步骤 -接收表示所述数据条目在所述目录数据库(302、402、602、DB11)处的第一当前存储状态的第一状态信息， -基于所述第一状态信息，将表示所述数据条目在所述目录数据库(302、402、602、DB11)处的第二当前存储状态的第二状态信息与修改所述数据条目的请求相关联，所述第ニ当前存储状态指示所述数据条目对于所述客户端(306、308、406、408、606、608、CL12)可用的最新可用当前存储状态，以及 -发送与所述第二状态信息相关联地修改所述数据条目的请求。
15.根据权利要求14所述的方法，所述方法还包括以下步骤 -在所述客户端(306、308、406、408、606、608、CL12)的存储单元(SU12)中存储所述第一状态信息，以及 -从所述存储单元(SU12)中检索所述第一状态信息，以及将所述第二状态信息基于所述第一状态信息。
16.根据权利要求14或15所述的方法，其中，根据轻量级目录访问协议来执行涉及在所述目录数据库(302、402、602、DB11)和所述客户端(306、406、606、CL12)之间的接收和/或发送的至少ー个步骤。
17.根据权利要求16所述的方法，其中，所述修改请求包括轻量级目录访问协议断言控制，所述轻量级目录访问协议断言控制包括所述第二状态信息。
18.一种客户端(306、308、406、408、606、608、CL12)，适于执行根据权利要求14至17中任一项所述的步骤。
19.根据权利要求18所述的客户端(306、308、406、408、606、608、CL12)，所述客户端(CL12)包括接收单元(RU12)、发送单元(TU12)、处理单元(PU12)和存储单元(SU12)。
20.ー种通信系统(314、414、614)，包括根据权利要求10或11所述的目录数据库(302、402、602、DB11)和根据权利要求18或19所述的至少ー个客户端(306、308、406、408、.606,608)。
全文摘要
提供了一种用于在包括目录中的数据条目在内的目录数据库(302)处的数据管理的方法，所述方法包括以下步骤将所述数据条目与表示所述数据条目在所述目录数据库处的第一当前存储状态的第一状态信息相关联(330)，从客户端(306)接收(336)修改所述数据条目的请求，与所述请求相关联地从所述客户端(306)接收(342)表示所述数据条目在所述目录数据库(302)处的第二当前存储状态的第二状态信息，所述第二当前存储状态指示所述数据条目对于所述客户端(306)可用的最新可用当前存储状态，以及如果关于所述数据条目在所述目录数据库(302)处的所述第一当前存储状态和从所述客户端(306)接收的所述第二当前存储状态确定所述第一状态信息和所述第二状态信息匹配，则根据所述请求来修改(340)所述数据条目。
文档编号G06F17/30GK102834823SQ201080066122
公开日2012年12月19日 申请日期2010年12月8日 优先权日2010年2月11日
发明者安东尼奥·阿隆索阿拉尔孔, 埃米利亚诺·美利奴巴斯克斯 申请人:瑞典爱立信有限公司