CN1232914C - 在分布计算机系统中保持数据完整性的方法与设备 - Google Patents

Abstract

公开了一种维护数据在整个分布计算机系统的完整性的方法和设备。在一个实施例中，本发明的方法包含从服务器应用程序发送一个对象到客户应用程序的步骤。本方法也包含从服务器应用程序发送一个对象的状态到客户应用程序的步骤。本方法进一步包含对象和对象状态在服务器应用程序和客户应用程序间的同步；在同步步骤之后用调用服务器应用程序的方法来改变对象。实施本方法的各个步骤的设备和制造的文章也一起公开。

Description

在分布计算机系统中 保持数据完整性的方法与设备

1、发明名称：在分布计算机系统中保持数据完整性的方法和设备

1A发明者：Anders Vinberg等

1B受让人：计算机合作者思维公司

2、相关申请的相互参考，有则附

本申请是美国临时专利申请，系列号为60/131,019(于1999年4月26日提出)的继续申请，它又是美国系列号为09/408,213(于1999年9月17日提出)的部分的继续申请，它又是美国系列号为08/829,919(于1997年7月15日提出)的继续申请；它又是美国临时专利申请系列号为60/021,480(于1996年7月18日提出)的继续申请。每一个相关申请在这里作为参考的一部分。

3、联邦政府资助的研究与开发的权利说明，有则附

本发明不基于任何联邦政府资助的研究与开发项目。

技术领域

本申请者的系统是属于软件实现方法、系统和制造领域，用于保护贯穿分布计算机系统的数据完整性。

背景技术

在分布环境里的信息处理方面存在着几种不同的技术支持。每一种技术都是设计成满足特殊的目的的。例如远方过程调用系统允许在一个计算机中运行的程序去调用另一个计算机中的函数。对象请求代理程序(ORB)提供类似的服务，但是按照面向对象的习惯作少量的变动。数据库访问系统使程序从另一个计算机中回收数据。报文传送系统使一个程序与在远方计算机中的另一个程序通讯；有时，在需要时存储报文，在通信可以建立时再向前发送。公布和登记系统(Publish and Subscribesystem)允许一个程序广播一个消息，只有那些对此消息已登记的系统可以接收到它。几个其他的技术也存在于这个领域。

在许多情况下，通信技术提供同样的服务给同一计算机中不同程序的通信，或者不同计算机程序的通信，甚至在某些情况下同一程序内部的通信。在另一些情况下，不同的技术，用于不同配置下的通信。

然而，现有的技术引起某些实际问题。没有现存的服务满足现代分布应用的所有要求。不同的服务很少被集成，这意味着，一个需要几个服务组合起来的程序，必须做许多工作去组合它们。在实践上这种作法很难不引入小错误，从而削弱数据的完整性。另外，许多服务的闭合特性常常使开发者组合它们是不可行的。例如，微软公司提供一种ORB服务叫做COM，它是基于通常的以连接为基础的通信。微软也提供一种存储转发报文系统叫做MSMQ。无论如何，COM不支持用MSMQ于通信中来得到非同步的服务调用。

状态传送技术

对象请求代理程序

在现在的技术中有一些系统提供调出在远方服务器的服务。这些通常称作远方过程调用(RPC)服务。当它们是基于对象模型时，就叫作对象请求代理程序。这种系统根本的标志是在服务器中保留对象的状态。当建立分布系统时，希望客户端的程序去访问服务端对象的组成其状态的各个单个属性，开发者一般可在两个可选当中选择，但是没有一个是有吸引力的。

对象服务器可以单独地暴露属性，用这种getCurrent Balance型的属性回收方法和像SetCorrent Balance的属性设置方法。但是这会是效率很低的；为了检索一个对象状态的全部情况，客户程序需要做大量的请求。现代网络系统和数据库管理系统不是设计成能有效地处理大量的小的请求的，在网络和数据两者的额外开销和等待时间，将使它花费很多。

对象服务器可以展示一种getState方法，它回收一个包含整个状态的数据结构。这是比较有效的，因为整个状态在一次对话中就送到客户，但是它破坏对象模型。首先，如果状态是被编码在一个通用的非对象语言的典型的Struct中时，我们由于混合对象与非对象技术而破坏了编程模型。如果状态被编码成一个对象，我们有两个具有非常不同特性的对象：状态是本地的，客户端对象没有方法和没有与服务器的关系；原始服务是一个有方法的对象，但是没有属性。为了改变服务器对象的属性，应用程序必需改变本地对象的状态，然后再调用如setState(the state)的方法来把它送回到服务器。这种技术一定可以工作，但是它不是一个清晰的或者易于维护的编程模型。

另外，在客户端状态已经修改，但还没有写回到服务器期间，我们有两个不一致的状态版本，处理逻辑将得到不同的结果，取决于它是访问哪一个版本。由于在发送期间的这些限制，希望扩展对象请求代理程序，使它具有更加有效地处理状态的服务。

数据库存取系统

有一些系统提供对数据库服务器的远方存取，这些系统中的一部分包含自动高速缓存管理。当一个记录已经从服务器检索出来，应用程序可以再回收此记录的值而不用重新去取；对多个记录的更改可保持在高速缓存中，而当Commit(提交)操作执行时，一次写回服务器。某些这样的系统是基于对象技术，在那里被检索的数据用对象的形式表示在应用程序编程语言中。

该系统有严重的局限性，其在于，它们检素对象给客户，但是不能够调用在服务器上的此对象的方法。一旦对象的状态已经传送到客户，调用一个对象在服务器上的方法将引起困难；此对象是在客户处维护，其状态可在客户处改变，而执行在服务器上的方法可以是没有意义的。

应该注意，这个问题也发生在一般的关系(SQL)数据库中，它们通常提供执行存储过程的支持，例如，假定一个记录被取到客户，然后对此记录的更改是在客户端高速缓存里进行，并且假设这些更改尚未写回到服务器；而现在就调用在服务器端的存储过程，此存储过程将在不正确的数据基础上操作。

由于在支持分布处理时，有这些限制，希望扩展的数据库存取系统具有更加一致的管理分布处理的服务。

具有存储转发技术的高速缓存

高速缓存的管理

高速缓存的管理是一种众所周知的技术；许多系统(从数据库存取工具到Web浏览器)提供本地的信息高速缓存以改善反应时间和减少网络的通信量。

一个可读的高速缓存用于保存已经被检索的信息；如果应用程序再要求同样的信息，就可以从高速缓存中取。这种缓存可以是暂时的，信息仅在一次对话中存活，也可以是长久的，保存的信息在磁盘中，存在于多个对话中或者甚至计算机断电后也继续存在。自然，如果在服务器上的信息更改，高速缓存的信息成为无效的。在某些情况下，如Web浏览器，这种失效性是可以接受的，从服务器修改信息的责任留给用户。在另一些情况下，它是不能接受的。或者是因为信息是更加动态的，或者是因为应用程序是更加重要的。服务器端更改的异步事件通知是一个被证明有用的技术，用于维持分布的应用程序其各元件间的同步性。一个应用程序可以与长久地存储在数据库中的对象一起工作，而用高速缓存来获得众所周知的性能上的好处。如果在网络中某个地方的另一个应用程序改变在数据库中的一个对象的值，系统源发送一个事件通知到这个应用程序，所以此应用程序可以修改这个值在它的计算机过程中或者在屏幕上。

一个可写的高速缓存用于暂时保存数据的改变。当一个客户端应用程序改变其高速缓存里的对象时，这些改变是保存在客户端写的高速缓存中。最终，这些改变要被写到数据库服务器。一旦客户与服务器连接，当应用程序执行一个Commit操作时，这些改变将写回去，依赖于高速缓存管理器和同时控制管理器的策略，改变可以被写回早一些或晚一些，但是至少在Commit执行的时间里完成。

具有传统的高速缓存管理的系统，事件通知(从服务器到客户的同步改变)和高速缓存写回(从客户到服务器的同步改变)两者只有在客户计算机连接到数据库服务器时才能有效地工作。这样的系统不能处理失去连接的情形。如果数据库服务器在Cominit操作时是不可访问的，改变不能写回，并且会失去。类似地，当系统未连接时，任何发生在数据库的改变都将失去，因为没有通知有可能送给客户。

有时一个应用程序能够对故障异常有一定程度的反应，而走入悬挂状态(Pending State)，等待连接重新建立，使Commit操作可以完成；由于有这样一些理由，这种解决办法是没有吸引力的。首先，它把处理这种问题的负担加给应用程序开发者。正确地处理这种中断是困难的，不希望所有的应用程序开发者都需要有正确处理这种问题的技巧和预算。

其次，在这种等待期间，应用程序基本上是停止的；停在一个没有完成的处理中，没有其他的数据库操作能够进行，因为它可以是同一个处理的一部分，而这破坏应用程序的语义学。

进一步，如果应用程序被关掉，不管是有意的还是无意的，应用程序的悬挂状态要丢失，并且所有的改变同样要丢失。

有一些原因可以使系统断开，这可以是没有计划的中断：由于硬件或者软件的故障，网络暂时失去链接，阻塞或者无线电干扰。这种没有计划的中断，今天比过去更加普遍，因为系统工作在更广泛的分布配置中，通信通过不可靠的拨号线或无线链接。也可以是有计划的中断；例如销售代表用以向预期客户报价用的膝上机，它可以只是断续地连接，只是有时需要连接到总部去下载价格的改变才连接。

总之，存在着高速缓存管理系统是有用的，希望能够改善其面对通信中断的行为。

事件通知

可以出现这样的设想，如果应用程序以锁定数据库的对象来使用通常的不利的并发控制(Pessimistic concurrency control)，那么数据的完整性问题是否存在是值得怀疑的。如果一个应用程序保持对对象的排斥锁定其他应用程序不能够修改它，也就不需要送出通知，也不需要排队。至少有二个实际的理由来反对这种设想。

首先，不利的并发控制在分布很广的分布环境中是不实际的，对于间断连接肯定是不实际的。例如，一个组织不能够允许其到处跑的销售员把总部数据库中的对象锁住，而去阻止总部更改价格。经验建议，在如此广的分布环境里，唯一有实际意义的并发控制模型是优化的，在其中，远方的应用程序不是在数据库里锁住，而代之以依赖事件通知。

其次，不管什么样的锁定机制，在服务器上的改变可以是由同一个应用程序对方法的调用引起的。这样的边效应(side effect)被用事件通知传播到这个在远方的应用程序。在某些长期运行的方法情形里，连接可以在这个方法完成时已被断开，因此，事件通知必需在存储转发系统中排队。

这种情景似乎不会出现在传统的交易处理应用当中，那里服务器侧的方法是短期运行的；但是今天，存在其他的应用程序类型，它们有这种需要。例如，一个应用程序可以跟踪在磁盘上一个文件的文档状态，调用此方法的可以是一个后台作业；在这个后台作业完成以后，应该把修改后的文档状态送到这个应用程序，这可能需要排队，因为没有必要去中断此后台作业，因为一个网络链接是短时间地被中断的。

存储转发报文系统

存储转发是另一个众所周知的技术，在此技术中，被送到一个计算机所在地的报文暂时地存在一个队列中，如果目的地的计算机是不可到达的，而一旦连接可以建立，就送出。

用可到达性技术的长久性

在某些系统中，面向对象的数据运行在这样一种习惯下，当在应用程序中建立一个潜在的长久性类(Persistent Class)的对象时，此对象是暂时性的。此对象只有在当通过执行某些方法或语句而明显地被保存，才变成长久性的。

在这样的系统中，对象也可以访问另一个对象。这种访问可以是直接的，因而对象有包含直接指针、或者地址或者路径至另一个对象的属性。另一种可能是，非直接的访问，因此存在第三个对象，它起着协调或者链接这两个对象的作用。

这样的系统至少有一个潜在的问题：一个长久性的对象可以出现悬空的访问，当一个应用程序试图去重新建立一个对象的结构时，指针指向这个不曾被保留的对象，因而是不存在的对象。

这个问题的通常解决办法是通过可到达性，也被叫做“传送长久性”，来自动地长久化。系统应用这种技术，自动地导航这些访问，寻找出由长久性对象可以到达的所有对象并保存它们。

无论如何，这种系统通过可到达性来实现这样的长久性仅是在一个单个的数据库里。更加复杂的应用系统，它从几个数据库接收对象，并且支持在分开数据库里的对象间的关系，不提供长久性的自动管理。

重复对象解决技术

在任何系统中，从任一个数据库中回收数据，存在着对同一数据回收二次的可能性。这是真实的。对于从一个文件中读数据的最简单的程序和在应用一般的关系表的程序中都存在。重复回收的可能性引起隐藏的程序错误的可能性，被称为“丢失修改”。考虑用伪码写成的这个例子：

基于某个查找判据找一个项         find one item based on some search

                                 criterion

基于某个查找判据找另一个项       find another item based on some

                                 search criterion

加100到第一个项的某个属性上      add 100 to some property of the

                                 first item.

加200到第二个项目的同一个属性上  add 200 to the same property

                                 of the second item.

保存第一项                       save the first item

保存第二项                       save the second item

如果头两个语句一致地寻找同一个项，那么我们可以希望两个改变是对于同一项的属性，那么此属性将增加300，但是这不会发生的。因为程序有同一原始属性的二个拷贝，例如原始值是1000。程序的第三个语句把此属性变成1100。第四个语句把此属性变成1200，第五个语句把1100写到数据库。最后一个语句把1200写到数据库。事实上，加100被丢失了。

必须注意，交易管理或并发控制不能解决这个问题。因为错误甚至会发生在所有的操作是在同一个交易里的上、下文。并发控制阻止分开程序的干扰，但是不能消灭编程逻辑可能的错误。

可以辩解说，这是一个直接的错误，程序员应该测试它并注意到两个原始的读操作实际是对同一个对象的。这是难于做到的，因为对象的回收可以是很间接的，我们可以开始时寻找到二个不同的人，然后我们得到他们工作的不同部门，再后来我们得以这些部门的经理的经理。我们通过二个不同的路径得到同一个人，这是不明显的。类似地，我们可以在程序的一部分回收一个对象，然后在程序完全无关的另一部分(可能由不同的程序员所编写的)，执行一个查询去回收几个对象，其中的一个和已经被取的那个是同一个。

由于丢失修改的复杂性，没有现存的数据库系统提供解决办法，然而，用申请者的系统就有可能解决这个问题或者减少丢失修改的可能性。

对象数据库

当这个潜在的问题发生在所有数据库里，实际上是所有长久的存储中，它会对绑有闭合语言的对象数据库有更多的干扰。因为这样一个对象数据库表现在较高的水平；它表示数据库的对象如同一个大的对象海洋，在其中应用程序可以无接缝地导航，例如丢失修改的错误，由于对象代理复制而更易于出现。简言之，对应用对象数据库的开发者较之比较简单的关系数据库的用户有更多的要求。

动态并发控制技术

在许多情况下，应用程序要求并发控制的标准特性，包括原子性、一致性，完成从数据源回收数据操作的隔离和耐久性。许多应用程序需要访问二者事务处理的和非事务处理的数据源，而所公开的系统被设计成支持所有这些服务的提供者。

数据库系统传统地是依靠锁定来保证并发运行交易的隔离。标准的二相锁定方法要求一个交易锁定一个数据库源并保持这个锁定直到被提交或者被放弃，在应用程序是用于大量的短的交易时，这个办法工作得可以。

二相锁定不大适合于现代的基于Web的应用程序，其特征是较长的交易、较低的交易处理率和中层数据的高速缓存。一个长时间运行的保存在一个普通数据库，源中的锁的交易，例如库存书的数量，可以阻止其他交易的运行，从而使整个Web网站瘫痪。因此，增加了对交替并发控制机制的兴趣。特别是，优化的并发控制机制已经在一些数据库管理系统和应用程序服务器中实现。

优化交易由两个不同的状态组成：一个长运行的该状态，跟着一个短的写状态，也被称作提交状态，在读状态期间，对象不锁定地被回收，并放在交易私有的缓存中，在那里可以对它进行修改，而不影响其他交易。对象是在提交状态期间被写回到共享的存储中。代替锁定，一个优化的交易是依靠于这样的假设，即当它运行时，没有其他交易可以更改此对象。在由交易所作的改变存到数据库中之前，这个假设是有效的。

在具有低的或中等程序竞争中的系统中相信优化的并发控制是优于其他方法。今天，大多数的电子商务应用符合这种类型。

较早的优化并发控制机制的实现是作成较大数据库管理系统的子系统。经常，只有存储在这种系统的数据可以用优化的方式访问而不带有锁定。这种情形与信息的可移植和透明数据访问的趋势相矛盾。而这二者是随着Internet应用的增加而急剧产生，Web网站通常是建立在旧的数据源例如关系的和基于主机的数据库上。

许多现代的应用服务器是传统的“星形”体系结构，如图1所示。Web服务器和应用服务器是在星的中心。它们连到多个Web浏览器和几个信息提供者。应用服务器负责把信息提供者的数据带到Web服务器的客户。数据的高速缓存和优化交易处理也在应用服务器所在的中间层进行。

这种体系结构适用于只基于Web的用户，或称“瘦”用户，并且此用户只访问有限数目的后端信息提供者。同时，对具有“瘦”和“肥”用户混合的应用没有优化。在这样的设置下，“肥”用户需要去访问在远方应用服务器中的高速缓存里的数据，与传统的客户/服务器体系结构相比没有多少改进。另外，把原始数据从大量的信息提供者处带到一个单个的中心位置，当数据对客户可用之前需要被修改时，是对可伸缩性的负作用。

发明内容

如此，需要有一种方法和设备，它能在网络中的分布计算机系统间比较可靠地保持数据的完整性。

本发明的技术方案为：一种用于保持存储在整个分布计算机系统的数据完整性的方法，此方法包含：发送一个对象从服务器应用程序到客户应用程序；发送一个对象的状态，从服务器应用程序到客户应用程序；在服务器应用程序和客户应用程序间同步此对象和对象的状态；并且在同步步骤之后用调用应用程序方法来修改此对象。

采用所公开技术的系统，分布的计算机系统网络能够保持存储在分布计算机系统中的数据的完整性。应用所公开的技术完成这个和其他目的，其特性和优点是使用了几种技术，包括：

·用远方调用功能的状态传送；

·具有存储转发能力的高速缓存；

·用可到达性的长久性；

·重复对象解决办法；

·分布的方法；

·动态并发控制。

附图说明

图1示出了具有星形体系统结构的网络，它与某些以往技术的网络相一致。

图2示出了具有分布体系结构的网络，它与本发明相一致。

具体实施方式

申请者的系统用新的办法组合若干已知技术，并加入新的技术以解决现存系统的这些问题。申请者的系统涉及到几个具体的问题，每一个通过多种技术特别的组合。这个系统也进一步唯一地组合这些服务来提供一个单一的基础设施(infrastructure)支持：服务的提供者(有方法，没有长久的存储)，传统的数据库(有长久的存储，没有方法)和对象数据库(有长久存储和方法)。

不介绍完整性问题而集成不同类型的服务是很困难的。事实上，在任何情况下建造一个分布应用系统是困难的，因为程序逻辑的错误只有当通信的模型组合是一种不幸的方式时才会出现。申请者的系统介绍几种方法涉及到这些问题，因此减少建立分布应用的困难。

建造一个具有良好性能的分布应用系统也是很困难的。整个应用系统在几台计算机系统中的分割方式和通信结构的方式通常要求细心的精确调试。这对应用开发者是一个困难的任务。申请者的系统用对某些性能自动调试的办法来减少开发者的负担，用比较容易地改变分割方式和对应用程序的源代码不用大修改下对通信的调试来减少开发者的负担。申请者的系统移走许多应用系统的这种设定，并使系统管理器能够在一个特定的配置里优化应用系统的行为，在不修改源码和具有最小引入错误的危险下，对可应用技术的改变、商务的要求、分布结构和负载作出反应，修改系统的行为。

术语

为了本规范的目的，某些术语将用下述的定义加到它们公共的意义上。提供者(provider)是一个软件系统，它提供信息或者服务。当此二者的区别有意义时，本规范称一个“信息提供者”其主要作用是提供信息，或者一个“服务提供者”其主要作用是提供某种处理服务。信息提供者包括传统的、关系的和对象的数据库、目录、文件系统、监督代理、Internet和其他提供数据的程序，服务提供者包括商务应用、管理工具、备份代理和其他程序。

无论如何，服务和信息提供者两者的差别是不严格的，例如大多数现代数据库支持调用存于其中的过程，而Internet可用以放置一个命令以及回收目录数据。

一个“消费者(Comsumer)”是一个程序，它回收数据，改变数据，存储数据或者调用服务。一个消费者可以是其种应用程序，或者一个简单的交互工具例如浏览器，它允许人与信息或服务交互。

类似地，提供者和消费者间的区别也是不严格的。一个单个的软件部件可以同时是两者：消费者和提供者。一个提供者可以对请求作出反应，但是为满足这些请求，它可以扮演一个消费者从其他提供者请求其他服务。

另外，在一个消费者和一个提供者之间的信息流不总是传统的请求/反应结构，一个提供者可以送事件通知或其他消息给消费者，或者其他提供者。

系统可提供服务，允许软件和硬件通信，不论它们是在同一个计算机的相同进程、同一个计算机的不同进程、或者不同计算机；不论它们是信息或服务的消费者或提供者，不论它们是对请求的发送或反应，或者是对事件的发送和反应。

状态传送与远方功能调用相组合

申请者的系统把状态传送组合到远方功能调用。当一个对象被访问时，其状态用现行的数据库访问系统传送到客户，并存储在客户侧的高速缓存中。这种组合的完成是在严格的对象模型下，并且这些对象暴露给应用程序的是在应用程序语言中通过语言捆绑的固有对象(nativeobjects)对象的状态可以被直接地访问，而这些访问在本地从高速缓存中得到解答。此状态可以直接地被修改，它们的改变保存在本地的高速缓存中，并在以后再写回服务器通过一个lazy-write(懒惰写)算法。依据使用的并发控制模型和优化决策lagz-write算法可以决定在不同时间写入，但是，至迟要在调用Commit操作时写入。服务器侧的方法是通过捆绑语言的应用程序编程语言的标准方法显露出来的。

方法前和后的同步

因为在服务器或者在某些其他计算机上执行的方法，在分布方法的情况下，其状态应该在客户与服务器或者其他受影响的计算机间是同步的。因此，当一个服务器侧方法被调用时，高速缓存管理器必须在此方法实际被调用之前把客户应用程序里的对象状态所有变化写入到服务器。当然，这种同步在执行客户侧的方法时不需要。

有可能修改申请者的系统的状态同步服务逻辑来优化写入信息的数量。某些状态的改变可以不是正针对这个方法的，因此不需要在这时写入。无论如何，在一般的情况下，状态同步服务不能决定这件事，因为各种方法可以是用多种语言来实现的，并且可以有任意的复杂性；因此，为了安全，应该写入所有属性的变化。当然，这种手动控制，可以是申请者的系统一种可能的变种。

在服务器侧的一个方法已经被调用以后，可能需要客户侧的高速缓存与数据库的同步，此方法可以有边效应(side effect)，当修改它所属的对象的状态或者其他对象的状态时，这些状态也可以是在客户的高速缓存中。因此，在一个方法调用之后，状态同步服务自动地修改所有已经在服务器中被修改的在高速缓存中的对象。

那些纯粹通过现有的基础设施去访问数据库的方法不会有问题。基础设施跟踪所有进行中的活动，决定已给做了什么改变，并能够容易地发送所有这些改变的通知到高速缓存。如果方法通过基础设施无法跟踪的直接技术访问数据库，这个基础设施可能可以依赖于从数据库来的事件通知。大多数数据库系统允许一个程序登记通过触发(Triggers)或者其他技术引起的改变的通知，并且基础设施能够应用这样的通知作为高速缓存同步的基础。

如果基础设施决定没有任何技术是可利用的，它必需采用一种最不利的方法：无效和刷新整个高速缓存。注意，在这种情况下，没有丢失任何在高速缓存中的数据，因为所有悬挂排起来的改变，在此方法被调用之前已被写入。

应用程序事件通知

任何由于方法调用产生的这样的边效应对于对象的改变，不仅用于刷新高速缓存，也作为正常的改变通知送回到客户侧的应用程序，从而允许应用程序用此新数据来计算或者显示在用户接口。由别的程序引起的改变和由方法的边效应引起的改变两者没有根本的差别：两者都需要通知应用程序。

交易管理

在传统的不利的并发控制下，应用程序对它已经读的记录保持锁定。在这种情况下，整个关于方法前和后同步的讨论，完全不包含交易的管理。其在应用程序中的步骤顺序像是这样的：

开始不利的交易            begin pessimistic transaction

修改后在缓存中状态        modify state in cache

...                       ...

自动写入来自缓存的改变    automatic write-through of changes

                          from cache

调用服务器侧方法          invoke server-side method

从服务器刷新缓存          refresh cache from server

其他操作                    other operations

提交交易                    commit transaction

所有这些操作工作在同一个不利的交易里。仅有的不平常效应是应用程序必需处理由于方法的边效应引起的改变通知。在一般的情况下，一个工作在不利并发控制的应用程序操作不关心它所控制下对象的改变通知；在今天复杂的，多线索应用程序里，某些保留在一下窗口或线索的数据，可以被另外的窗口或数据所修改，因此在实际上，必须准备一段代码来接收来自任何与其他实体共享的数据的修改通知。

当运行在优化并发控制机制时，应用程序不保持对数据库中对象的锁定。任何时候，被写入到数据库的改变是有效的和立即提交的。因为任何悬挂的改变，在调用方法之前，被写入到数据库，方法调用自动地提交悬挂的交易。从客户应用程序到服务器方法调用结果是：

开始优化交易                   begin optimistic transaction

修改在缓存中的状态             modify state in cache

...

送悬挂的改变到服务器           send pending changes to the server

使它们，对数据库现有状态有效   validate them against current state of

                               the database

如果有效失败                   if validation failed

发送一个异常到用户             send an exception to the client

否则                           else

把改变写到数据库               Write changes to database

调用方法                       invoke method

提交交易                       commit transaction

送事件通知到客户               send event notification to client，

从服务器刷新缓存                to refresh cache from server

其他操作                        other operations

提交交易                        commit transaction

申请者的系统提供另一种选择，在关于动态并发控制中详细讨论。当方法被调用时，交易管理服务可以转换到不利的并发控制。执行的可任选可以作为系统配置设定的一部分加以选择。

具有存储转发的缓存

由于通常系统的限制，可以希望有一种基础设施可以接收交易的提交，甚至当连接被中断时，并且能够保持交易在一个长久的存储一转发队列中，当连接重新建立时，把它送出去。

申请者的系统唯一地组合这二种能力：缓存管理和存储转发。在具有存储转发报文返回的缓存管理系统中，所有发生在在停机期间的服务器侧改变的通知存储在一个队排列里，一旦连接被重新建立，这些在缓存和应用程序中的改变就被传播和反射。

类似地，如果需要，客户侧改变的通知也可以存储，而一旦连接重新建立就转发到服务器。因为这样异步写入到服务器可以与并发控制机制有悬而未决的交互，这可以由应用程序或者管理策略把它禁用。

应用程序的透明性

本发明的优点之一是应用程序不需要去警觉断续的同步进程。应用程序可以这样来写，如同它有连续的和可靠的访问数据库的能力，这是用提供立即的对大对象池的访问的联编语言来做到的。缓存改善应用程序的性能，存储转发队列保证所有的改变被传播到应用程序，所有这些都是在不用改变应用程序编程风格下做到的。

非计划停机的恢复

把存储转发队列集成到缓存管理增加了整个系统对短期非计划停机的恢复能力。这种非计划停机可以是非常短的特别是对于拨号或无线连接。例如，一个蜂窝电话连接，当车经过一个桥下时可以丢失，并在几秒钟或几分钟内重新建立。应用程序和缓存管理在此停止连接期间可以连续运行。当然，从服务器来的通知可以丢失。

实际上，大多数网络协议检测这个被失去的连接，并立即发给数据库服务器失败的信号，它将被考虑为整个操作丢失。而用存储转发技术，数据库服务器继续运行，保证报文最终将被发过去，而且不发送报文失败到数据库。

连续运行的应用程序

越来越普遍地，当一个应用程序断续地连接到数据库时，它是连续运行的。汽车、轮船或者飞机可以有连续运行的应用程序来处理连续运行的销售、发货或者把特别轻的可装于口袋的计算装置(包括所谓个人数字助理)连到网络上。在这些情况下，缓存可以保持连续地存在着，而当连接失去时，改变的通知必需排在队列里。

长久的缓存

当缓存是长久的时候，集成缓存和存储转发的价值更进一步增加。没有长久的缓存，上面讨论的好处只有在应用程序或者至少是缓存管理器保持运行时，才可以获得。用通常的非长久的缓存，一旦缓存管理器被关掉，缓存中的值被放弃，当重新开始是，缓存管理器必须从数据库中从很开始时起取出对象，并且因为这些值反映当前的值，不需要把发生在那过程中的改变通知排入队列。

无论如何，在许多情况下，使用长久的缓存是有很多好处的，当应用程序或者缓存管理器关闭时，缓存保存在本地的存储器中，当缓存管理器重新起动时，从本地的存储中重新建立。在某些情况下，保持缓存是缓存管理器的责任。在另一些情况下，例如膝上机运行时，它就是操作系统的责任。

不论由那个部件负责保存缓存，其情形在逻辑上等价于长期运行的缓存和改变通知在存储转发队列中，是用于保持缓存中信息的现时性。

申请者的系统可以与重复的数据库对比，后者能够被配置来提供某些类似的好处。数据库重复方案依赖于数据库的同种性(homogencity)，这意味着在任何节点上是同一的，或者至少需要在结构上和语义上是相似的数据库。在小计算机上，例如膝上机或者掌上机，这是不现实的。在任何情况下，申请者的系统提供这些好处，仅仅在于长久的或者不长久的缓存，这是一种比数据库更少麻烦的技术。

由可到达性得到的长久性

申请者的系统扩展通过跨越几个信息提供者的可到达性做到的长久性概念。任何时候基础设施决定一个对象需要用长久性—通过—可到达性算法来保存时，或者应用程序明显地要求它应该保存时，就要决定这个对象要保存在哪一个数据库提供者那里。通过几种技术中的一种可以做出决定，这些技术包括例如：

·对象所属的类(Class)可以与定义在其个特定数据库中的某个模式相联系，这样，此对象就要存在同一数据库；

·对象所属的类可以是被规定在某个特定的数据库的存储，不管其模式来自何方；

·对象所属的类或者特殊的对象可以动态地与某个特定的存储相联系；

·系统可根据自己的某些判据决定存储。

在这些事例中，二个有可到达性关系的对象可以被保存到不同的数据库。它们间的关系可通过能适应不同存储的引用(reference)来实现。

在这些情况里，由可到达性算法做到的长久性在本质上与相同的方法有关，不管对象存于何处，一旦这些对象被存于缓存或者存在应用程序自己的存储器中，他们间的关系为长久性的基础设施所知道。申请者的系统的可到达性方面的长久性会导航这些引用，并由识别所有长久的对象可到达的对象来决定哪些对象应该用通常的办法保存，并标识它们是将被保存的。然后，应用上面列出的技术中之一来决定此对象应该被保存在哪一个数据库，并达到通常方法的长久性。

复制对象的解决方案

申请者的系统解决复制对象问题，用自动检测一个操作是否是要从数据库回收一个已被从服务器到客户激活和取过的对象来解决。因为系统在其缓存中保有已经被激活的对象，任何时候当要取某个对象时，系统要决定新要取的对象是否可以从在缓存中已存在的对象复制，如果是这样就放弃新拷贝，而代之以使用在缓存中已存在的拷贝。

这种技术决定直接地从数据库中取对象是按照名字，按照对象间的关系，从一个对象到另一个的关联或者指针；按照匹配于某些特定判据的返回一些数据的查询；按照查找最近访问过的对象的列表，或按照任何其他技术。对象如何到达是无关紧要的，当它到达时，系统检测这是一个复制的，就放弃新的拷贝。

性能改善的变种

自然，在许多事例中，系统能够检测出将要被取的对象已经存在于缓存中，并消灭所有对数据库服务器的请求，因而减少网络的通信量和数据库的负担，并改善反应时间。在另一些事例中，像当执行一个查询时，使用数据库是不可避免的。在任何事例中，这些变种只影响到性能，而不改变系统的基本操作。

分布的方法

一个对象数据库存储对象，而这些对象有属性和方法，模式规定对于某个给定对象的类存在着什么方法。

在通常的对象数据库中，方法是在对象同一数据库中实现。方法的定义简单的给出它的名和所属的类。并没有要求进一步的位置规定，因为其位置就隐含在对象的位置中。

存在着一些情况，在那里需要或者希望实现方法在另外的某个地方，例如：

·数据库可以缺少完全的能力。例如，如果对象是存在一个关系数据库中，其执行方法的能力是受限制的。在这样的事例中，方法可以在其他的程序中实现，或者在与数据库同一机器上实现，或者在另一个机器上实现。

·给定的对象数据库具有完全的方法执行能力，可能希望在一个比较少能力的存储处重复数据。重复常常作为改善其可用性，减少网络的通信量和改善反应时间的方法，无论如何，如果一个重复数据所在的数据库，没有提供方法执行的支持，系统就必须回到原始对象的数据库，并在那里实行方法。

·存储在数据库中的对象可以代表在系统某个地方的物理设备或者软件。这样的对象-例如路由器-可以有实现的能力如同程序在对象本身实现；管理服务可以提供在某个地方实现的功能；而应用程序可以有某种包含图形用户接口的功能，因而是运行在用户工作站上。在所有这些事例中，服务可以视为对象的方法，虽然它们可以在整个网络实现。

·类的方法可以在旧的程序中实现，或者在第三者的程序中实现，开发者对它很少能够控制。这些方法可以在不同的编程语言，数据库或操作系统中实现。然而，为了在应用开发中简化这些方法的使用，希望表示这些不同的方法成为一个统一的整体的不同部分。这自然有可能要建立一个软件来把这些分开实现的方法捆绑在一起，但是建立如此的连接服务是一大堆工作，且任何配置的改变都要求改变原码。这就希望通过模式的管理来在外部定义和维护这些关系，不管这些方法的类型和位置。因此，申请者的系统允许模式包括方法的定义、规定方法的位置而不仅仅是它的名字。在执行过程中，系统允许一个应用程序去访问在数据库中的对象，简单地调用对象的方法，如同它是标准的内部的方法；系统将注意传送方法调用请求到相应的位置。

方法的实现

在方法的定义中应该也规定方法是如何实现的。它可以被例如一个C或C⁺⁺DLL的正常子程序调用。它可以是一个Java的可执行程序或者甚至是一个BAT文件。模式(Schema)识别所使用的技术和方法应该如何被调用。

方法也应该规定对象如何被识别。当一个方法是用例如外部程序实现时，它自然没有原始对象的正文(Context)。方法的模式规定，按照此正文保留的方法调用将如何被进行。

类和实例水平的方法

方法的外部实现处理技术良好地工作，等同于附属于一个对象的实例水平的方法，等同于附属于一个类的类水平的方法。当调用一个配置成实例水平方法的外部方法时，原始对象的识别符是被传送到此方法。如何进行传送的，可以例如在模式中规定此识别符是方法定义的一部分，是调用的变元，是可实行的命令行的参数或者是在具体配置中任何合适的东西。

方法前、后的同步

如前面所讨论的，当一个系统组合远方方法调用和状态传送时，必须注意在客户和服务器之间在方法执行前后状态的同步。在分布方法的事例中，状态的同步应该包括方法将要在其中实行的计算机。

这至少可以用下述方法来进行：

·状态可以被同步到作为这个对象长久存储处的数据库。然后：在执行之前方法可以从此数据库中回收状态。在方法执行期间，系统把任何长久的状态改变写到此数据库。客户侧的缓存管理器被通知以这些状态的改变，并把它们作为方法后状态同步的基础。注意，如果方法运行的那个计算机已经有对象的拷贝在其缓存中时，就不需要从数据库去取对象。

·状态可以被同步到执行此方法服务器的缓存中。

动态并发控制

申请者的系统采用唯一的动态并发控制机制，它是基于组合锁定的(不利的)和非锁定的(最优的)并发控制策略。

每一个运行系统的实例，包含它自己的对象缓存和交易管理器。它可以运行在一个客户机上，在那里它提供非基于Web应用的本地数据访问。运行系统的几个实例可以在中间层组成组。然后，它们可以被Web客户或者其他运行程序的实例所访问。自动的负载平衡保证改善可伸缩性，一个分开的运行实例可以被放在靠近一个旧的数据库，用以完成对象对关系的影射。对象以已装配的形式被发送到中间层，此形式可以减少要求访问这个对象的网络报文数量。

这个体系结构成功地解决许多与分布环境下透明信息访问有关的难题。

分布的有效性

所有现有的应用服务器和透明数据访问框架，在中层(共享对象缓存和私有交易缓存所在地)完成优化交易的有效性检验。有效性检验通常用比较在私有交易缓存中的对象日期印记(date stamp)与同一对象在共享缓存中的日期印记，如果二者不同，有效性检验失败。某些系统完成有效性检验用比较在应用服务器环境下的不同缓存中对象的前后图象来决定。

一个优化的交易可以经由运行系统的多个实例访问数据。例如在图2中的由应用程序“Appl”起动的一个交易，当访问在信息提供者“DB1”中的数据时，通过至少三个运行实例。

在优选实例中，每一个运行实例保持交易的读出和写入组。当交易提交时，其读出组与已经提交的交易写入组相比较，如果在至少一个运行实例中有一个组的非空交叉(non-empty intersection)，此交易就被放弃。

提供者具体的有效性证实

在某些事例中，如何证实交易为有效的，其规则是依赖于具体的应用程序。例如，考虑一个雇员记录的数据库。如果一个应用程序改变某个记录的电话号码，其他应用程序可以被认为是有效的，除非它正好去修改同一个电话号码，但是如果改变的是雇员的姓名，这个交易的标识符，那么试图去修改这个记录的任何部分的交易都是有问题的，任何这样的交易应该是无效的。这种知识是具体针对这个应用程序，一个电话号码是不重要的，而一个姓名是有重要意义的。

申请者的系统允许提供者负责交易有效性的证实，办法是登记它自已有使用标准的提供者和运行系统间接口来干此事的能力。如果提供者宣称负责此事，运行系统要求提供者进行证实。如果提供者不能进行证实，运行系统就依赖于自己的更加保守的技术。在一个具有几个提供者配置的系统中，其他提供者可以作它们自己的具体应用程序的证实，而某些则延迟证实到运行系统。

并行的有效证实

分布交易的读和写组是分开地、通过运行系统的多个实例的。当交易提交时，它的有效性证实是并行地在这些被包含的运行实例中完成的。在理想的情况下，当一个交易通过运行在N个不同CPU的N个不同实例访问N个信息源时，这个有效性证实可以N倍地快于如果仅有一个中央应用服务器时，企业范围数据访问的分布特性，将使这种情况更加普遍。

证实前的提前异常终止

当一个优化的交易是悬挂起来时，其他程序可以修改这个交易所使用的数据，这是优化并发控制的基本原则。这个互相矛盾的修改，在证实阶段用几种技术之一对它进行检测。对于使用申请者的系统的优化系统，这也是普通的。无论如何，事件通知系统能够发一个任何这种矛盾修改的通知给运行系统，允许它提前异常终止这个悬挂的交易。这个提前异常终止的特点可以减少操作者无效的努力，否则他可以花力气输入数据到一个最终是无效的交易中。这个提前异常终止的特点也减少在计算机、网络和数据库中无用的负载。

在分布有效证实期间提前异常终止

一个长时间运行的优化交易，为了发现它已被另一个交易证实是无效的，用不着等到其读出阶段的结束。一旦一个提交交易通过证实阶段，它比较它的写入组和现在还存在着的交易的读出组，并且发出无效事件到所有导致组的交叉是非空的交易。这个无效的事件通过分布事件管理器传播，除了其他特性之外，它是被设计来提供可靠的和有序事件的传送的。

混合的交易

系统支持优化交易管理是基于按交易进行的，一个应用程序当交易开始时，指出交易的方式。一个新的交易可以开始于不利的或者优化的方式。

交易的方式可以不同，不仅基于按交易也基于按提供者。例如一个应用程序可以访问二个数据存储：一个私有的轻便的数据库用做本地长久的对象的缓存，一个远方的部门数据库包含共享的数据。申请者的系统允许应用程序用不利的方式去访问本地的数据库，因此避免了证实有效的不必要的额外开销。这个共享数据库可以一直用非锁定的优化方式进行访问。

这个特点变得特别重要，当本发明是用于访问非交易的提供者例如LDAP、ADSL、MAP1和NT文件系统。优化并发控制可以提供对访问这种有串行性要求的提供者交易的隔离。如果不需要它也可以被禁止使用。

唯一的包裹式应用程序接口

现代数据库系统提供对优化交易管理的可变程度的支持。不同于其他透明数据访问框架，它们坚持用自己的算法来管理优化交易的不同阶段，申请者的系统通过开发用户化的包裹器(wrapper)，而唯一具有操纵不同信息提供者的能力。包裹式API包含优化并发控制的基本功能，它们可以由包裹器开发者重新定义，这不是其他系统所用的ODBC、JDBC和CLE的API(应用程序接口)。

动态的交易

在申请者的系统中，对象的状态(也就是属性的值)传送到对象应用的点。例如，在图2中，应用程序APP1正在访问在本地运行实例缓存中的对象。这是一个明显的改进，相对于其他系统那里，或者把对象留在服务器侧，或者在中间层。当然，当一个服务器侧对象的方法需要调用在客户的此对象状态时，此要求可在服务器中提出，以运行这个方法。

申请者的系统考虑到这种情况，使交易管理器可以把正在运行的交易动态地从优化模式转换成不利模式。这个模式的更换，当它调用服务器侧的方法时，对应用程序是透明的。只有运行此方法的提供者受到影响。所有其他提供者能够继续运行在优化模式。

注意，这个模式的转换，仅在假设提供者本身没有支持某种形式的优化并发控制下是需要的。否则，这个改变可以保存在提供者中作为分布式优化交易的一部分。例如，分布交易的模式，当对象的状态在运行系统的不同实例中传播时，是不改变的。这个特点对支持插入服务器提供者是有价值的。如同这个系统本身的目录管理员。

适应的交易

优化交易不适于具有由客户引起的在数据项上有高竞争的应用程序。在这个的应用程序中，大量的优化交易由于不能接受的高的返回率，将不能通过证实阶段，让所有的交易从不利的模式开始是对这个问题的一个直接的解决办法，并用于其他系统。但它是太受限制了，当竞争水平随时间改变的话，例如在现实世界中，竞争在早8点到晚6点是高的，而在其他时间是低的。

申请者的系统提供这个问题的一个解决办法是用神经网络代理技术。此技术的一个例子比较完全地公开于系列号为09/084620的美国专利申请，它是作为参考文献引入这里的。交易总是开始于没有明显地规定其模式。当竞争是低时，它们运行于优化方式，当返回率增长到高于某个限度时，其缺省方式就自动地变成不利的。返回率能够一致地保持于可接受的限度，一旦神经代理收集到足够的知识允许可靠的预测的话。

提交前，会晤范围的事件通知

申请者的系统的基础设施广泛地使用事件通知，通常是从提供者到消费者。例如，一个消费者可以得到通知说保存在客户侧缓存中的对象，按照优化并发管理已经在数据库中被改变了。因此，现行的交易可以是无效的。应用程序和提供者也可以按通常的办法互相发送事件。

另外，构成客户侧应用程序的不同文件之间需要互相通信是普通的。例如图形用户接口(GUI)应用程序，可以由多个窗口组成，某些运行在同一线索，某些运行在同一进程的不同线索，而某些则运行在不同的进程中。

这些不同的应用程序文件可以，例如，表现同一数据项于不同的视图或者不同的上下文间。当然，一旦一个应用程序文件做一个改变并把它提交给提供者，所有对此对象有兴趣的应用程序得到这个改变的通知。无论如何，在一个客户侧应用程序，事件通知必须远在改变提交前就发生。自然，如果所有的应用程序文件是同一进程的一部分，它们将通过公共的会晤和公共的缓存共享数据，这个问题留下来作公开的考虑。

·诸元件当它们是在不同的进程时，是否应该有可能互相合作？用户看不同的窗口是同一应用程序的一部分，并且不觉察到或者不感兴趣于详细的配置情况，如线索和进程。对用户而言，一个应用程序应该表现一个数据组。

·不管数据共享在物理上是怎样做的，不同的应用程序例如GUI(图形用户接口)当数据改变时需要得到通知。这个负担不应该是由开发者负责，因为随着在应用程序中的许多文件改进，许多通知关系也组合地改变，任何时候当一个新的元件加到应用程序，其他那些能够潜在地访问与新元件相同数据的元件必须作相应的改变。这对开发者将是一个昂贵的和实际上无法维护的体系结构。代替它的，基础设施应该提供通知服务，它在某些数据改变时自动地在元件间发送通知，不用等到提交点和不用理会线索和进程的边界。自然，会晤边界受到尊重，因为它是交易管理的基础，会晤间是互相隔离的直到改变被提交。

为了涉及这些问题，申请者的系统提供二个设施：

(1)当一个应用程序部件连到基础设施时，它能够加入到已存在的会晤中；

(2)改变的事件通知在提交点前在会晤中传播，并且不包含提供者。

优先实现的综合提示

对象基础设施是设计成能提供意义重大的好处，对于减少开发的努力，减少编程的错误和改善性能而言；后者是由于把通常留给应用程序员的许多责任转交给基础设施。这个也采用到开发GUI的工作。申请者的系统使能一个通用的用户接口，它的建立是基于对象的状态表示成表格，在它们间联合导航，并把方法表示成菜单或按钮的项。

申请者的系统提供一个方法给数据库设计者或者应用程序开发者；通过提示的定义去指导基础设施的工作。

把应用程序从其实现中隔离

本发明的提示不仅提供直接的好处用于改善基础设施的工作或者减少开发者的努力；它也允许开发者，在不降低应用程序抽象性水平条件下调整其行为。用保持在高水平抽象时的编程习惯，大部分系统的先进功能继续起作用。在低抽象水平下进行明显的调整可以减弱其功能的高水平功能的例子，包括：

·高速缓存管理；

·提前读

·拖后写

·消灭重复的对象

通过使用提示，开发者或者数据库设计者可以调整系统的行为，而不必在应用程序中有任何明显的调整的语句。更有好处的是，当硬件、分布配置，负载模型或其他因素改变时，系统可以重新调整来反映这些改变，而不用要求任何应用程序的改变。

适应外部对象模型

申请者的系统的一般对象管理系统有能力适应不同种类的信息和服务的提供。它的一般对象模型能够适应任何系统，它满足一个对象系统尽可能少的特性。

使用申请者的系统，一个包裹器，一个提供者接口模块是特别地为提供者而写的，并且能够暴露任何数量的描述此提供者特性的特殊的提示。能够觉悟到这些提示的应用程序能够得到提供者的先进特性的全部好处。那些不知道任何关于提供者的应用程序以基于标准对象模型的正常的方法运行。

——说明结束——

提示的例子

性能调整提示：许多提供者可以规定像最佳信息处理的方法，给出信息的语义等的提示；

·一个反射表(Projection list)——一个很可能应用程序要用到的特性的表，

因此建议包含在任何回收中，或者

·用于提前读的框架——一个用于提前读的对象组间的关联关系或者其他关系的表。

GUI提示：一个提供者能够规定一个提示，建议自动GUI发生器应该如何显示信息，例如；

·表格制表键的特性组；

·关联的对象是否需要显示在一般的导航结构中例如树或网络的浏览器，或者是表格上的一个特殊网页或者制表键；

·当对象显示时，应该使用什么缺省特性；

·对于名字、背景名(Caption)、“工具提示”正文、长说明、帮助正文、图标、三维表示、声音或图像对象等应该使用什么样的特性。

·那些项应该出现在一个对象的菜单内容上；

·GUI应该怎样处理导航，例如一个对象的引入；

·在一些特定的关联型下，自动布局技术应该怎样安排对象的内容；

·数字值在显示时应该如何格式化；

·在数据项中什么样的值是被接受的；或者

·一个拖放操作如何说明。

提示源

这样的提示可以由提供者或者消费者提供。如果没有任何提示，系统将以正常的方式工作，从提供者或者消费者来的提示将指导各种系统服务的工作，如果不同的提示是互相矛盾的，它就向上提交给服务来应用这些提示决定怎么做。

开放的和可扩展的

提示直接地由基础设施的各种服务或者由提供者或者由应用程序自已读和解释。因为提示是基础设施数据模型的正式部份，任何部件可以建立提示，任何部件可以使用它们。更进一步，因为整个基础设施是开放的和可扩展的，任何服务可以被另一个所代替，可能是一个用不同的策略来解释提示的服务。

提示不会引起失效

对象的基础设施规定它所提供操作的语义学，提示可以指导基础设施如何去优化操作，但是不应该允许它们做出限制。

从语义学的角度，提示是一种边带通信(Side-band commumication)的形式，不应该把它们与正常的对象特性相混淆，申请者的系统保持提示与正常对象特性的不同。因此，新提示的定义或删除某些提示不象改变模式那样，不用要求程序重新编译。

应用程序处理的提示

因为提示被处理成数据或者元数据(Metadata)的一部分，它们正常地在系统中处理，任何部件可以定义和使用它们。这意味着一个分布应用程序的各个部分能够使用提示来通信关于处理应该怎样做。使用约定的消息惯例，一个提供者能够指导一个GUI元件携带有关的对象和分析其关系结构。

用于现存应用系统中的如此特殊的代码，通常要求边带通信的复杂的特殊的技术，这些特殊的代码需要进行维护。例如，如果系统是从SNA转换到TCP/IP，主要数据库的访问协议必需被移植，边带消息协议也必需被移植。用申请者的系统的应用程序处理提示的设施，特殊的提示逻辑上是在正常的数据库访问通信量之外的边带，但是在技术上，它们是主流协议的一部分，不要求特殊的照顾和维护。

还原

在缓存管理器中的还原支持

在申请者的系统中，系统保留一个所有已从数据库中取出过的对象的缓存。任何时候，对数据库的改变，其新的值要写入此缓存。

一个还原管理设施加到这个缓存的管理器。此服务记录在一个还原队列里的每一个改变，对于典型的属性值的改变，此还原队列简单地记录下前面的值。对于生命有关的改变如建立或消灭一个对象，这个队列记录能够逆反此操作的操作：消灭对建立，建立对消灭。在实践中，逆反一个改变的操作，可以是非常复杂的：例如要消灭一个类，所有这个类的实例、所有子类、所有子类的实例、这些类的所有方法和其他设施都要消灭。还原管理器尽可能存储这些逆反操作，在某些情况下，一个还原操作可以是不可能或者不实际的，在这些情况下相应的记号存在还原队列中。

还原管理器也提供应用程序可直接调用的还原和重作功能，以及支持GUI的服务，例如以人可以读的形式列出在还原队列中操作的顺序。

还原和交易管理

应该注意，有返回能力的数据库交易管理系统不能有效地提供此还原能力，数据库返回对于可能通过鼠标的“点击”(click)进行尝试和错误操作的操作是过于昂贵的。另外，没有数据库交易系统提供重作，并且只有少数提供多重的还原操作。

一旦在一个交易中的一组操作已被提交，要还原此交易的一个单个步骤会是有问题的。例如，如果用户要传送钱从一个用户到另一个用户，它是由一个减和一个加组成的一个交易来完成，此操作的单个步骤的还原是有问题的。因此，典型的提交操作凝固此还原队列，把现行交易的所有操作压缩成一个可还原的操作。在某些情况下，一个具体的计数操作可以为一个特殊的操作所知道：对一个特殊的方法可以在数据库的模式中规定对应的计数方法，在另一些情况下，交易可以是根本不可能还原的。总之，详细的一个交易如何处理，可以在系统任何具体实现中加以修改。

无堆栈还原模型

通常的还原操作是一个堆栈模型，返回动作是以它们做时相反的次序进行的，而重做是以它们做时的次序进行的。原理上，没有任何东西可以阻止单个的动作按任意的顺序重作操作。随机的返回操作不仅在原理上是可能的，在某些情况下还是很有用的。

这样的随机还原在现行的技术中往往是被拒绝的，因为在许多情况下是不可能的。例如，如果在队列中的操作6是建立一个对象，而操作11修改此对象的某个属性；这时，单独还原(不进行)操作正是不可能的，因为它将使操作11无效。这个简化的说明并不是唯一的可能，如果动作保持内部互相依赖，则可能允许随机还原，在这个例子中，还原动作6可自动地还原动作11，但是如果在队列中动作7没有与动作11或者其他操作有关系，则它可自己还原。

这样的随机还原在许多日益增加的复杂操作中是很有用的。在传统的在线交易处理中，操作顺序常常是很简单的，随机还原的好处是有限的，但是在更加复杂的、知识密集的应用就是非常有用的。

模式的偏差

在理论上，理想的情形，所有有关的对象假设都存在一个单个数据库里，由一个单个的模式(Schema)管理。现存的系统，在采用几个分布的数据库的情况下，假设它们模式是一致的，但是在实际上模式的一致性是难于达到的。为了技术的、经济的、实际的和行政的原因，信息可以存储在模式不一致的数据库中。例如，在获得一个买卖以后，它的大部分信息需要保存在与获得者的模式不一致的现存数据库中。例如，一个美国的公司获得一个玻利维亚或者俄罗斯组织的买卖，它将必需处理不同的名字定义：在玻利维亚是名字、家庭名、母亲家庭名；而在俄罗斯是名字、父名、家庭名。

申请者的系统适应这种模式不一致的情形，并且允许应用程序在不同数据库之间无缝隙地导航。考虑这个例子：

Object boss＝Employee.find(...)

Collection staff＝boss.getAssociatedItems(“reports”)

For each emp in staff

...

next emp

如果起始的对象，经理(boss)可保存在特殊模式的数据库A中，而组成职工的雇员则可放有不同模式的另一个数据库B中。事实上，某些雇员可以存在A中，而另一些可存在B中，系统隐藏这种差别，允许应用程序去回收对象和访问它们的属性和方法，不管它们存在哪里：

Object boss＝Employee.find(...)

Collection staff＝boss.getAssociated Items(“reports”)

For each emp in staff

Name＝emp.Family Name

next emp

如果两个数据库间的差别是比较大的，应用程序可以调查此对象，找出它们的位置，并把自己适应于此特殊的模式，例如回收一个人存在的父名。

实体间的关联

抽象关联

申请者的系统把实体间的关系抽象为关联，这样的关联是模式的一部分，一个应用程序可以是本发明的一个服务去导航关联。因为定义是从物理实现移出的抽象的东西，一个提供者可以使用维护这种关系所需要的任一种技术；例如，在关系数据库中的外部钥匙(foreign key)在对象数据库中的对象引用，执行查询的方法，以及出现在与关联的词义相一致的某个方法。

一旦关系被表示成一个关联，应用程序就可以容易地导航此关系。互相关联的对象简单地以互相有关系的对象在应用程序中出现。应用程序代码可以像是这样的伪码；

Object boss＝Employee.find(...)

Collection stapb＝boss.getAssciatedltems(“reports”)

For each emp in staff

...

next emp

一个关联是一个抽象的概念，它提供二个实体间的双向引用(reference)。

在大多数情况下，被关联的实体是对象，但是这个概念不限于对象。关联能够存在于任何一对有唯一整体名的实体之间，例如带有路径名的文件，带有URL的网页，和带有UUID的对象。例如，从一个类的一个属性的关联可以赋值给一个证实的方法或者这个属性的可视化服务。

一个关联也能够有它自己的附加属性，例如开始日期。一个程序，可能是数据库由人使用的管理工具，可以规定关联的型，和建立命名实体间的个别的关联。这个程序也能够用这些关联导航，回收互相关联的实体，或者是关联本身。

关联的实体可以自动地被取，如果需要这样做的话，当应用程序在一组互相关联实体中导航，关联可以自动地间接引用(de-reference)。

通过自动优化和自调整技术，自动地间接引用可以是有效率的，例如：

·系统不是在getAssociated Items语句立即取所有的对象。而是使用一个懒惰取(lazy fetch)它只是在需要时，才从数据库中取对象。

·懒惰取并不取单个的对象。懒惰取管理器成批取对象。

·系统是自调整的，成批取的大小适应于所处环境的可观察到的性能，快速的周转(trunaround)引起批的大小增加，而低的周转引起批的大小减少，更复杂的算法自然也可以插入于此。

·性能调整子系统，也允许开发者提供提示，指导系统的调整。

关联注册

各种实现可用于关联，例如带有引用的对象，具有外部键的表，方法和查询，可直接用于导航，不用任何进一步的规定或元数据。例如，考虑一个类叫做Containment用于实现关联。它保持两个引用到容器对象(container object)和被包容的项(contained item)。

class Containment{

Object container

Object containeditem

}

这样的类可以直接地由编程语言用于导航，像这样：

Object cont＝

Collection contents＝Cont.getAssociatedItems(

“Containment”，“Container”，“Containeditem”)

最后的语句告诉系统寻找类Containment的对象，用名叫Container的属性去寻找到达现行对象(被cont引用)的引用，然后用containitem属性的引用找到所有的对象。

类Containment并没有任何特殊之处，它正是正常的类(这类似于你在SQL中对正常的、不具有任何特别特性的表做连接(Join)。

无论如何，本发明用允许类Containment被登记在关联注册中，而使此概念更普遍一些。这告诉基础设施，此类正常是用于一个关联，但并没有限制它用于其他方面。

类似的登记，也可用于其他关联，包括但不限于：一对直接的对象-对-对象的引用(对于1对1的关联)；对象-对-对象引用的集(Collection)(用于1对N和N对N关联)和回收逻辑上关联对象的搜查方法。

关联注册提供大量的好处，包括例如：

·消费者应用程序不需要知道一个具体提供者的实现模型，它们简单地引用关联的抽象概念，而基础设施者翻译此引用成为关联具体实现的相应操作。

·分开应用程序与关联的实现，使它具有更大的弹性去改变提供者的数据模型，和更能够去做不同类型的数据库提供者互相间的合适的替代。

·通用的工具，不用知道任何关于提供者应用水平的模式，检查当中使用关联注册能够找出存在的关联类型，这对图形浏览器是特别有用的。

·当产生层2模型时，层2模型发生器能够建立基于被登记的关联类型的虚属性；在上述例中，我们能够在名字内容下通过Containment类登记关联，而这允许层2代码发生器建立用于Container类的虚属性的内容，使应用程序有一比较容易的方法导航关联。

参考到外部的对象

对象间的关联可以引用存储在外部提供者中的信息。例如，在上例中老板(boss)可以存在数据库A，而职员(staff)可以存在数据库B。

关联的自动导航和对象的自动间接引用，其差别对应用程序是完全地隐藏的。应用程序能够在这些对象间导航，从一个到另外一个而不用管对象是在哪儿。

事实上，因为系统的体系结构对应用程序隐藏了提供者的特性，这就可能使这种对外部的引用指向任何类型的数据源，包括但不限于在非对象数据库中的数据，人名录中的人，一个文件或者在Internet上的一个页面。

存在于外部的关联

在许多情况下，应用程序可以使用其模式不能改变的现存的数据库提供者。一个实际的例子，信息可以存在商业财务管理系统中，它参考人和部门，而可能希望联系这些参考到人名录的相应的项。这个联系可以允许一个应用程序建立对数据的反映在数据库中，而作决定则基于在人名录中的组织机构的数据，可能是发送电子邮件。

然而，如果数据库或人名录均不能改变，就没有可能存储联系，和用直接的连接于数据库之间。

申请者的系统允许储存这样的关联在另外的数据库中。因此，二个不能互相参考的数据库，也不能互相引用的数据库，能链接。

在申请者的系统中，应用程序用标准的方法导航关联，必须做的仅有的一件事是当命名的关联要为导航所使用时，规定关联存在何处。甚至这个最小的不方便也能够用登记关联在注册中来加以消灭。这样，在标准方法中关联可以用名字来描述，而系统在注册中查找它实际上存于何处，到这个外部关联的存储中去得到联系，然后跟随此联系到另一个对象。

外部绕回的关联

同样的技术可用于存储关联，它引用在同一数据库中的诸对象，但这时模式不能改变成为能直接地适应存储关联。

语言的联编

申请者的系统通过在通用编程语言中可以得到的应用程序接口(API)来显露它的服务；这些编程语言包括Java、C⁺⁺和任何支持COM的语言包括Visual Basic。

层1的语言联编

每一个系统为了访问信息提供者或者服务提供者使用一个核心数据模型。在基于SQL的系统，例如在ODBC和JDBC，数据模型是具有在每一格内是原子元件的表，并扩展成具有存储的过程。在ORB，数据模型是接口，基本上是过程调用的规范。数据模型的选择是每一个设计的基本部分，因为它包含着某些折衷：

·如果数据模型是原语的(Primitive)，它限制了系统的能力(如SQL)

·如果数据模型是丰富的(rich)，它要求提供者有一大堆的能够与原语提供一起工作的能力，并使它困难地连接到原语提供者(例如JavaRMI)

·如果数据模型是很特别的，它不能适应不同的设计(如Microsoft的WMI)

·如果数据模型是很一般的，它提供低水平的服务而留下所有语义智能给应用程序(例如LISP)

本发明的对象模型开始于某种叫做项(item)，然后进到规定项的集合(collection)，介绍项名的记号，并最后命令的集合和项的所有者。用这种方法，对于一个可用于存储、移动和引用数据的自说明数据格式建立了一个紧凑的和精巧的基础。这个数据模型叫做层0。

这个格式的建立是为了定义更高水平的概念如类和对象、属性和方法(层1)，然后在其上建立具体的类，例如计算机和雇员(层2)。

这种设计的独特的优点是：

·这个基本的数据模型(层0)，它是足够简单的，它可以适合任何已经存在的系统，不用注入任何要求到对象模型。

·因为较高水平的模型(层1)是基于简单的层0模型，它能提供一个比较现代的对象模型和给这样一些提供者的比较丰富的语义，这些提供者表现出不用要求它是简单提供者的能力。

·层1联编的实现是基于动态处理，而因此有不一致的和改变的容差。如果提供者改变它的数据模型，例如，如果改变数据库的模式，层0模型自动地适应这种改变，并且层1也是这样。使用这个提供者的应用程序不要求改变或重新编译，而不会失败，如果他们自己不要求必须这样做。特别地，如果应用程序没有兴趣，被加上的能力可以简单地加以忽略；但是如果应用程序使用申请者的系统的服务去做内部观察，它可以发现新的能力并采用它们。应用程序没有用的那些能力的移去，不会对应用程序有影响。甚至假如一个应用程序试图去使用一个已经移去的能力，它只是简单地得到一个例外的信息并能够试图加以恢复。

层2代理联编

问题：弹性对确定性

当建造和维护一个大的应用系统时，特别是那种包含以前存在的元件，或者来自其他应用系统的元件时，维护整个系统的一致性是一种挑战。词配置管理(Configuration Management)，或者简单地称为版本的管理(Version Management)是保证系统的各个元件是兼容的，因而能合作；是一致的，因而工作在相同的假设下。在已存在的系统，配置管理普遍地被视为是建立时的活动。

在申请者的系统中，配置管理是一个运行时的活动；系统的元件应该是互相通信，互相谈判并同意在一个共同的版本上；每个元件应该是有弹性的和甚至在对应者是不一致时应该能继续运行。

在现存的系统中，这样的弹性有时通过动态接口来达到，通常叫作晚联编(late binding)。一个晚联编的系统，例如COM的IDispatch-based接口，能够自适应于一个元件显露出来的不论什么样的接口。

然而，使一个软件系统完全是晚联编通常是没有吸引力的，因为它消灭了通过早联编在编译时对配置一致性证实的可能性。编译时的证实允许有一个这样的确定水平，这是晚联编系统不可能达到的，因为运行试验不能够完全地把各方面问题都显示出来。

申请者的系统把晚联编的弹性和早联编的确定性组合起来。

问题：弹性与方便性

动态接口允许一个消费者通过内部观察和反射服务与提供者对话来适应它自己于提供者的规范。这样的服务通常地提供在部件的体系结构中如COM，和数据库访问服务中如ODBC和嵌入式的SQL。

这些系统的好处是花高价得来的。对这些接口的编程是非常繁重而又困难的，并且容易出错。为减轻应用程序开发者的负担，我们希望有一个暴露事务应用的数据模型的接口，直接地集成到编程环境中。这对于现代的面向对象的语言，例如C++、Java和Visual Basic是特别有吸引力的，它们直接支持相对丰富的词义和模型。

解决办法

在现存的系统中，二种方法的好处是不可能同时得到的。早联编的系统例如COM是不提供晚联编系统的弹性或者适应性。具有适应性的系统如动态SQL不提供早联编系统的确定性和方便性。

申请者的系统通过高级语音的联编来组合这些好处。层2代理联编用特定编程语言的固有类(native class)的形式来暴露在信息提供者处可以得到的对象。一个开发者在数据库中规定其模式，然后应用此模式于应用程序语言：代理联编是数据提供者的中枢。

这种联编型式提供对层1联编的几个好处，而不牺牲其核心优点：

·层1联编的适应性和通过内部观察得到的动态适应任何提供者能力隐含着对于开发者是重的负担。层2联编表现给开发者的是应用程序范围的语义结构，减少了开发和维护所需的努力。

·层1的动态自适应性，被称作适合提供者模式改变的能力，使它难于在编译时证实消费者和提供者间的一致性。在层2联编，在目标编程语言或基础设施中产生类，而这些类能够用于编译时的证实。

·同时，因为层2联编应在层1上实现，它有动态适应的能力，正像任何层1的应用。因此，一个现存的应用程序，开发者不能控制它，因为远方的采用，行政的阻碍或者费用的考虑，可以具有层1的弹性继续运行。那些珍惜编译时证实的应用程序可以通过运行层2的证实进程。

联合代理的和长久的联编

问题；长久联编的局限性

联合联编

在申请者的系统中，层2的长久的和代理的联编被联合成一个集成的整体，因此减少不一致性的危险。

一个开发者能够规定起始的模式，或者在应用程序或者在数据库工具中加以规定。一个公用程序(Utility)迁移模式定义从一个环境到另一个。如果原始的定义是应用程序，一个数据库的模式是建立和安装在数据库。如果原始定义是数据库，则产生用于应用程序的原码。然后，开发者能够改善定义在二个位置中的某一个：例如增加索引和簇的定义，修改属性和它们的型和特性，增加或修改服务器侧或客户侧的方法。申请者的系统的公用程序保持两个环境的同步，并把定义从一种语言翻译到另一种语言。

本发明的观点

联合是通过本发明的这样一些特点达到的：

·应用程序的语法对于二种联编语言(代理模型和永久性模型)是同一的；

·数据库模式对二种联编模型是同一的；

·两个模型的应用程序使用同一个运行支持程序库；

·两个模型的应用程序有同一语义；

·用在代理模型中的代码发生器产生的代码与永久模型预处理器是兼容的；

·用在永久性模型中的模式发生器和代码发生器产生的模式和代码与代理系统兼容，并且

·两者代码预处理器和代码发生器接收和保留用户的扩展。

此联合至少提供二个非常重要的好处：

首先，被联合的联编支持重覆开发(iterative development)。自然地，一个开发者可以重复地使用这二种模型，在两种工作方法中来回移动，其次，联合联编提供教学的一致性，限制一个应用程序是对单个的源代码模型，使系统易于学习。

完成本发明的最好实施方式已经详细地叙述了，那些熟悉与本发明有关技术的人将得知各种各样的可供选择的设计和本发明的实施例。这些可选择的实施例仍是在本发明的范围之内。

Claims (2)

1、一种用于保持存储在整个分布计算机系统的数据完整性的方法，此方法包含：

发送一个对象从服务器应用程序到客户应用程序；

发送一个对象的状态，从服务器应用程序到客户应用程序；

在服务器应用程序和客户应用程序间同步此对象和对象的状态；并且

在同步步骤之后用调用应用程序方法来修改此对象。

2、如权利要求1的方法，进一步包含这个步骤：

在修改步骤之后在服务器应用程序和客户应用程序之间重新同步对象和对象的状态。