专利名称：web服务数据库群集体系结构及其方法
技术领域：
本发明涉及利用数据库群集的web服务，例如使能电子商务。
背景技术：
电子商务日渐成为日常生活的一部分。通过电子网络，最常见的是通过公共互联网，产生对于货物和服务的采购询价和采购订单。大成交量的电子商务应用需要这样的一种基础设施其提供高可用性、有保证的服务质量(QoS)和具有负载平衡的响应时间、容错以及用于高可用性的稳定性。这类系统被部署在群集上，其中，群集节点作为应用服务器(以及应用)与数据库实例(主数据库实例与复制品(replica))的主机(host)，以便分担工作量并提供高可用性和改进的响应时间。
用于实现电子商务应用的一种已知方法是J2EE(Sun Microsystem公司发布的Java 2平台，企业版)。J2EE是一组协调的规范与实践，其共同使用于开发、部署和管理以服务器为中心的多层应用的软件解决方案成为可能。J2EE还是用于创建和使用web服务的平台。
J2EE平台中的主要技术为用于基于XML的PRC(JAX-RPC)的Java API、JavaServer页、Java Servlet、企业JavaBean组件、J2EE连接器体系结构、J2EE管理模型、J2EE部署API、Java管理扩展(JMX)、用于容器的J2EE授权合同、用于XML注册表(JAXR)的Java API、Java消息服务(JMS)、Java命名与目录接口(JNDI)、Java事务API(JTA)、CORBA和JDBC数据访问API。
已知的电子商务体系结构具有用于应用的、分层的开发和部署方法。电子商务应用的不同层为(i)视图或用户接口层，(ii)控制器或应用逻辑层，以及(iii)模型或应用的持久数据模型层。这些层被称作MVC(即模型、视图和控制器)体系结构，它们分别被部署在web、应用和数据库服务器上。
如图1所示，MVC体系结构10具有人类行为者(human actor)12，其与web服务客户端计算机14交互。客户端计算机14运行浏览器应用(其为调用web服务的J2EE程序的客户端)，并使用合适的(即http/https)协议通过例如互联网等公共网络16与应用服务器交互。部署J2EE应用的应用服务器18具有servlet容器20，在该servlet容器20中存在有多个应用Java servlet 22。容器20实现J2EE servlet规范并在运行时执行servlet22。servlet容器20的输出24是被传递到实体/企业Java Bean(EJB)容器26的RMI/IIOP(即IIOP上的RMI)调用。EJB容器26具有多个应用EJB 28。来自EJB容器26的输出30为JDBC API，其在数据库32上进行读取/写入调用。
部署多层体系结构的一种方法是对web、应用和数据库层进行群集，以提高端到端的应用性能。如图2所示，体系结构50包括与网络分派器(dispatcher)程序52通信的web服务客户端14。节点54-58的群集作为多个应用服务器59-62以及数据库实例64-68的主机。分派器程序52将请求平均分配给节点54-58。数据库实例64-68在几个节点上被复制，以便获得性能益处和在数据库故障的情况下更高的可用性。网络分派器52(或虚拟IP)将客户端应用14从群集抽象，并提供与节点54-58的群集交互的单个接口。
接下来转到应用服务器59-62。应用Servlet 22具有与以上所述相同的功能。每一应用逻辑82是一组Java类，其容纳了应用用来满足客户端请求的业务逻辑。业务逻辑可以是任何东西；例如验证由客户端12发送以便持久保存在数据库70中的数据。应用会话Bean 84是如上面所阐释的企业Java Bean(EJB)。会话Bean为容纳需要“ACID”支持的应用逻辑的Java组件。ACID代表原子性、一致性、隔离性与持久性。J2EE容器(例如IBM WebSphere应用服务器和BEA Weblogic应用服务器)向会话Bean 84提供ACID支持。
数据访问层72-76被部署以替换实体Bean，并直接访问数据库。网络分派器78以与上面相对于分派器52所阐释的相同的原理被部署，以便将数据库请求路由传递到复制品群集64-68中数据库节点中的一个。
相应的数据访问层72-76以及网络分派器78将读操作路由传递到复制品数据库实例64-68，且将更新、插入和删除被路由传递到主数据库70。如果应用需要在刚刚写入之后的读取，数据访问层72-76必须在事务之间是有状态的(stateful)以便将这样一种查询路由传递到主数据库，否则，它通过将查询路由传递到复制品来向应用提供过期数据。复制基础结构在后台独立地工作，且不与数据访问层集成在一起以便在它完成复制工作时进行通知。这使得数据访问层72-76智能较低，因为它继续将插入/删除/更新后的所有查询转送到主数据库70，即使数据正被复制到复制品，因此对群集资源利用不足。
另一种方法一其适用于具有非常大的数据库的应用一是将数据库实现为主数据库与分区拓扑结构。如图3所示，体系结构100又一次具有网络分派器52。每个应用服务器102-106具有与图2中的服务器58-62一样的应用servlet、应用逻辑和应用会话bean。然而，应用实体bean层108-112代替了数据访问层72-76。主数据库实例114存在并对来自相应的应用实体bean 108-112的读取/写入请求进行响应。另外，主数据库实例114作为离散的分区116存在。主数据库实例114知道群集中分区的数据库实例，并维护关于数据如何被分区以及分区中的哪一节点承载数据的哪一部分的信息。该信息用于在主数据库上创建索引。一旦查询被提交，主数据库114i)分析该查询，ii)将其划分为不同的部分以便匹配数据分区，iii)将各个部分路由传递到分区的数据库节点116n，iv)收集来自查询执行中所涉及的每个部分的结果，v)在结果汇集上执行数据库操作，由于所述操作需要来自所有分区的结果的完整视图，其不能由底层分区单独执行，vi)构成最终结果集，以及
vii)将查询应答到客户端。
分区的数据库116n为承载数据库114的部分的数据库实例。例如，大的表T可被分区在两个数据库实例中，使得第一数据库承载该表的行(元组)的第一半，第二数据库承载第二半。数据库分区还可通过将不同的表放在不同的数据库服务器上实现。例如，表T1被放在服务器S1上，表T2被放在服务器S2上。
然而，在通过这类解决方案部署分布式系统时存在以下限制1.数据分区的部署是非常特定于数据库厂商和产品的。数据分区部署和查询路由传递逻辑不是行业标准，这使得应用与数据库产品以及厂商紧密耦合。
2.提供数据分区的数据库产品可能需要额外的数据库管理，因为该解决方案是对标准数据库技术的扩展。
3.担任到分区数据集的主接口的单个数据库实例将分区数据库实例抽象；然而，它担任在查询被路由传递到承载与该查询有关的数据的分区节点之前的中间查询停止点。这使得应用首先连接到主数据库实例，接着主数据库实例连接到次级实例，使系统在如本章节后面所讨论的某些情况下效率较低。
4.存在部署主实例和分区实例以便提供容错的智能技术。然而，如果解决方案被设计并被部署为具有作为到数据库系统的单个接口点的单个主实例，则数据库故障的风险由于主实例的单故障点而增加。
主实例对查询进行分析，以检查查询可被包含在哪个数据分区中，且如果存在单个数据分区，主实例将完整的查询路由传递到该分区。如果涉及包括该查询的多个分区，主实例将查询划分成能被路由传递到各个分区的部分，并且，如果需要，在将结果发送回到应用之前，负责处理来自每个分区的结果(例如联结操作)。
如果查询工作负荷和数据被很好地分析以便对数据进行分区，将存在较少的、查询跨多个数据分区的情况。在OLTP应用中，查询复杂性较低，且在大多数情况下，它们由一个分区应答。因此，与将查询路由传递到主实例并接着使之路由传递到分区相比，这种应用能将查询直接路由传递到分区会更有效率。然而，使能这种直接路由传递的企业系统还应支持主数据库实例的其它特征，例如，以对应用透明的方式为不同分区划分查询且联结它们的返回结果，并且能被采用为行业标准，以使得企业系统厂商能将该解决方案合并在框架中。缺少对以上特征的支持使得J2EE应用与数据库厂商紧密耦合，或必须将数据分区逻辑封装在应用层中，这都使应用的可移植性变得复杂。这造成了对于能以透明且松散耦合的方式在分区数据库上进行应用部署的例如J2EE框架等企业系统的需求。
本发明的目的在于克服或至少减弱一个或多个这些问题。
发明内容
本发明的目的在于在数据库群集的部署中、特别是在电子商务应用中改善可伸缩性、性能、可用性和可靠性，并提供服务质量。因此，公开了配置访问共用数据库的群集web服务节点，其包括在每个节点上实现数据虚拟化层以便将数据库的实例从web服务应用抽象。
在一个实施例中，web服务操作在一组访问共用数据库的节点上执行。该数据库被安排为由主实体bean处理的主实例和至少一个复制品实例。在每个节点上执行创建具有主实体bean的全部读取和写入操作的第一数据虚拟实体bean，创建仅承载主实体bean的读取操作并处理所述复制品实例的第二实体bean，在第一实体bean上接收操作请求，取决于被请求操作将请求路由传递到主实体bean或第二实体bean，以访问相应的数据库实例。
在另一实施例中，web服务在访问共用数据库的一组节点上执行。数据库被安排为离散的、不重叠的分区实例。在每一节点上执行实现具有与所述共用数据库匹配的模式的空数据库实例，利用该空数据库识别查询中相关的分区，以及将查询传递到相应的分区数据库实例。
另外，公开了相应的web服务服务器和计算机程序产品。
图1为用于部署web应用多层体系结构的示意框图；图2为用于部署web应用的、具有复制数据库的群集体系结构的示意框图；图3为用于部署web应用的、具有分区数据库的群集体系结构的示意框图；图4为用于部署体现本发明的web应用的、具有复制数据库的群集体系结构的示意框图；图5为用于图4的实施例的序列图；图6为用于部署体现本发明的web应用的、具有分区数据库的群集体系结构的示意框图。
具体实施例方式
概述开发了数据虚拟化层以便将物理数据库实例相对于应用抽象。虚拟化层容纳了数据管理和查询路由传递逻辑，并将数据访问逻辑从应用代码移到作为应用的主机的中间件(例如应用服务器)。
用于web应用开发的优选J2EE技术被扩展以提供数据库层的可伸缩部署。在应用服务器(例如IBM WebSphere以及BEA Weblogic应用服务器)中部署的应用层被群集，以便对web事务进行负载平衡，然而，数据库层不能采用现有的J2EE技术被群集。在J2EE体系结构中部署的数据对象或实体bean在设计上被附属于单个数据库实例，这对通过创建复制品或水平分区的数据库群集来对数据库实例进行群集留下了极小的选择。数据虚拟化层使得这种情况能够发生。
取决于应用的类别，将选择“复制数据库”与“分区数据库”方法来改进数据可用性、可伸缩性以及性能。存在多种电子商务应用类别，例如a)数据读密集的，b)数据读写密集的以及c)数据写密集的。“复制数据库”解决方案以数据读密集的应用为目标，分区数据库解决方案以其余两种即数据读写密集的与数据写密集的为目标。
在下文对实施例的介绍中将使用J2EE的示例。
复制数据库复制数据库解决方案是通过创建实体Bean的两个克隆(clone)实现的。实体Bean是数据(表)的面向对象的视图，典型地表示来自其指向的表的一个元组。然后以这样一种方式部署克隆的实体Bean，使得克隆bean中的一个(RWBean)提供数据虚拟化并将数据的物理位置从应用抽象。另一个克隆bean(ReadBean)针对复制数据库被部署。初始(主)实体bean仍继续指向主数据库。使用主bean的属性(JNDI名)部署数据虚拟器实体bean，因此，应用透明地开始调用数据虚拟器实体bean而不是主实体bean。通过这样做，数据虚拟器实体bean拥有了通过将请求委派到主实体bean或是克隆(Read)实体bean而将查询负载平衡(路由传递)到主数据库或是其复制品的控制。
现在参照图4，注意，对与图2中所示布置具有相同数字的不再进行介绍。在体系结构130中，用基于QoS目标的路由器Servlet(QRS)132代替图2中的网络分派器52。QRS 132是到节点140-144的群集的进入点，它监视每个节点对于给定服务类的性能。QRS 132在后台记录性能，并使用该结果对后续请求进行路由传递，这种路由传递是基于它们的QoS目标以及在前面的运行中观察到的各节点性能。QRS 132还在CEBRW(如下面所介绍的)的帮助下监视数据库状态改变，且如果数据库状态改变，它在将请求传送到SSS(见下文)时设置额外的请求参数，以便将数据库状态改变通知到SSS。SSS在线程名中设置标志，以便同样地使能其下的所有层。
新组件“会话同步器Servlet”(SSS)134-138被部署到容纳web和应用逻辑的各个相应的节点140-144。每一SSS 134-138负责在群集节点140-144间同步用户会话。由于取决于请求QuS目标和群集中的节点所提供的QoS，来自用户的不同请求可在群集的不同节点上得到服务，所以SSS134-138在当请求被路由传递到节点上时在节点上对用户会话进行同步。当请求到达群集中所选择的节点140-144时，SSS 134-138对用户会话进行更新。SSS 134-138是在相应的节点140-144上接收请求的第一个组件，并通过使用应用服务器的servlet链配置属性被配置为第一servlet。在SSS134-138更新用户会话之后，请求被servlet容器转送到相应的应用servlet22。应用服务器在将请求传送到应用servlet 22之前将自动调用SSS134-138。一旦应用servlet 22完成处理，SSS 134-138读回用户会话并将之持久保存在共用(主)数据库152上，该数据库152可由在群集的所有节点140-144上部署的所有SSS 134-138访问。由QRS 132向各个用户会话分配唯一的标识符，且其被用于在共用的数据库152上持久保存用户会话。用户会话标识符被保持在QRS 132的会话中，并作为在QRS 132与SSS134-138之间的请求URI的一部分被传送到SSS 134-138。当请求到达时，SSS 134-138从共用的数据库152读取用户会话，并用来自从共用数据库152读取的会话对象的值设置当前会话属性。
数据对象或实体Bean的部署被再造(re-engineer)。实体Bean承载读取(getXXX())、写入(setXXX())以及删除(remove())操作，以便与数据库进行事务处理并管理持久性数据。实体Bean被部署在作为应用服务器的一部分的J2EE容器中。容器管理器实体bean的部署被再造，以便能够以对应用透明的方式与主数据库以及复制品数据库实例集成。这是通过以下方式实现的(a)克隆具有所有读取和写入操作的实体bean(CEBRW)，并实现主实体bean的主接口(home interface)与远程接口两者。然而，如下面所述的那样，克隆bean的读取和写入操作的逻辑与主实体bean不同。
(b)创建具有其主接口与远程接口的新实体bean，其仅承载主实体bean的读取操作。这种bean叫做CEBR，因为与作为主实体bean的读取与写入操作两者的克隆的CEBRW不同，它是主实体bean的读取操作的克隆。
通过使用Java反射(reflection)API，CEBRW 160-164和CEBR170-174可容易地在编译时(在ejbc或部署阶段)开发。为CEBRW 160-164和CEBR 170-174产生代码的自动工具还可产生用于CEBRW的读和写操作的代码。CEBRW 160-164用“Bean管理持久性”(BMP)选项以及主实体bean的JNDI名进行部署。CEBR 170-174用“容器管理持久性”(CMP)选项并针对数据库复制品进行部署。主实体bean针对主数据库和新JNDI名被部署为CMP。CEBRW 160-164的写入操作(setXXX())将请求委派给主实体bean的写入操作。取决于下面介绍的条件，CEBRW160-164的读取(getXXX())操作将请求委派给CEBR 170-174的读取操作或主实体bean的读取操作。
由于通过使用主实体bean的JNDI名部署CEBRW 160-164，应用会话bean与CEBRW 160-164而不是与主实体bean交互。这允许CEBRW160-164截取源于应用的所有数据库请求，并将它们在主数据库实例152和复制品数据库实例182-184之间路由传递。例如，CEBRW 160-164可通过将读取请求委派给CEBR 170-174来将读取操作路由传递给复制品，并通过将写入请求委派给主实体bean的来将写入操作路由传递给主数据库152。在应用会话bean紧跟在写入后作出读取请求的情况下，CEBRW160-164将请求委派给主实体bean的读取操作(而不是CEBR 170-174的读取操作)，以便向应用提供最新的数据，因为主实体bean是针对主数据库部署的。为了识别读取请求是否在写入请求之后，CEBRW 160-164在其写入操作的执行期间在执行请求的当前线程名中设置标志。该标志在CEBRW 160-164的写入操作中被检查，且如果发现标志值被置位，则将请求委派给主实体bean的读取操作。通过当应用处理完成时读取线程名，数据库状态改变标志也被SSS 134-138读取。SSS 134-138将此标志添加到应用响应中，并将合成的响应传送到QRS 132来将数据库状态改变“通知”给QRS 132。QRS 132总是在来自SSS 134-138的响应中寻找该标志，以便智能地将来自用户的后续请求路由传递到群集中与主数据库实例相关联的主节点，从而允许应用从数据库获取最新的数据。CEBRW 160-164还在线程名中设置与写入操作相关联的时间戳。时间戳也被SSS 134-138传送到QRS 132并在QRS 132的用户会话中被缓存，以便在以后用于与数据复制时间戳进行比较，并识别这样的阶段到该阶段为止，数据被复制在所有复制品上。
通过使用这种方法，将应用与数据持久性细节抽象，因为它继续与实体Bean的初始接口交互。DB复制器180将主数据库152增量地复制到复制品，并将时间戳一直到该时间戳，数据被复制到所有复制品实例182、184上—通知给QRS 132。DB复制器180实现的关键任务之一是提供所有复制品实例的相同状态和直到其为止数据被复制的时间戳。QRS 132将复制时间戳与对于给定用户的最近更新的时间戳进行比较，且如果它发现更新时间戳被包括在复制时间戳中，则它通过将请求路由传递到群集中的任何节点来开始利用复制品，而不是仅将请求路由传递到与主数据库实例绑定的主节点。为了使能数据一致性，QRS 132在数据库(未示出)中存储更新时间戳。
如果在应用中使用有状态的会话bean且对其的引用被缓存在web层用户会话中，则在一个节点(例如140)上部署的应用程序可调用另一节点(例如142)上的有状态会话bean实例，因为同一会话中来自用户的不同请求可取决于QoS目标而切换节点。为了避免这一点，可用启动并利用有状态会话bean的用例(use case)(或URL模式)对QRS 132进行配置。一旦这种用例被用户调用，则QRS 132缓存(在QRS 132的用户会话中)其路由传递请求的节点信息并使用该信息将来自用户的所有后续请求路由传递到同一节点。类似地，还可用终止有状态会话bean的会话的用例(或URL模式)对QRS 132进行配置，使得QRS 132可在终止有状态会话bean的请求后开始将用户请求路由传递到任何群集节点。
取决于应用场景，可用下列选项对QRS 132进行配置，以便将数据库状态改变后的用户请求路由传递到群集中的主节点(a)基于用户的分区数据如果应用承载在用户间被分区的数据且特定用户进行的数据库状态改变仅影响他的记录，则QRS 132仅为来自该用户的、在数据库状态改变之后的请求设置数据库状态改变标志。这使得CEBRW 160能够将来自所有节点的用于该用户的数据库查询路由传递到数据库的主实例。例如，来自该用户的“PayUtilityBill”请求将改变在其账户中的余额，而不会影响其他用户的余额(或任何其他数据)。
(b)不分区数据如果应用数据不是在用户间分区的，且特定用户请求造成的数据库状态改变影响他的记录以及其他用户的记录，则QRS 132为在数据库状态改变之后来自所有用户的所有请求设置数据库状态改变标志。这使得CEBRW 160能够将来自所有节点的用于所有用户的所有数据库查询路由传递到数据库的主实例。例如，从一个用户帐户到第二用户帐户转移资金的“InterAccounTransfer”请求将改变该事务中的两个用户的余额。
可以用用例(或URL模式)以及QRS 132使用上面定义的选项更新数据库状态的方式对QRS 132进行配置。
图5中示出了一完整的序列图，该图示出了相对于图4中的体系结构130的步骤1-29的流程。
体系结构130提供了对以外在于应用的方式将数据库群集部署到应用的透明支持。在不需要在应用空间中构建或嵌入任何逻辑的情况下，应用透明地得以使用最新的数据工作而从不会得到数据的过期副本。
体系结构130提供了基于QoS的请求分派器132，以便最优地利用系统的可用资源。
体系结构130为给定的服务类(service class)监视各节点的性能，并使用性能历史来选择对于给定请求和QoS目标的节点。该体系结构还可将给出不良性能和需要调整的节点通知给系统管理员。
分区数据库分区数据库解决方案是通过在IBM Cloudscape(http://www-306.ibm.com/software/data/cloudscape，其并入此处作为参考)中创建与主数据库匹配的虚拟数据库实现的。Cloudscape是Java中的关系数据库引擎库，其可被嵌入到应用的JVM(中间件服务器)中。Cloudscape中的虚拟数据库包括与物理数据库中的表严格相似的表定义。这里的构思是截取源于应用、到Cloudscape中的数据库的所有查询，并将该查询路由传递到包含应答该查询所需的数据的正确分区。
为了能够将查询路由传递到正确分区，Cloudscape数据库程序库必须被扩展以理解数据分区并使用该信息将查询分解和路由传递到正确的数据源。这种功能不是通过扩展JDBC驱动器实现的，因为很可能查询会需要从一个以上的数据分区中取回数据，并随后可能需要例如Join、Sort等复杂的数据库操作来构建最终结果集。Cloudscape数据库引擎具有将涉及一个以上的表和数据库操作的查询分解为查询图模型(query graph model)并分别执行各个部分以及最终对数据进行集成的能力。引入这一额外的层所涉及的开销不会大，因为Cloudscape是Java程序库并且运行在应用的JVM中。
现在参照图6，应注意，不再重新介绍与图3所示的安排相同的数字。
为了针对分区数据库节点部署J2EE应用，针对框架嵌入RDBMS(FE-RDBMS)202-206(例如IBM Cloudscape)在体系结构200中部署J2EE应用。
典型地针对关系数据库例如IBM的DB2TM和OracleTM部署J2EE应用，以便容纳应用数据并针对其执行查询。J2EE应用的数据对象或实体bean与数据源定义相耦合，所述数据源定义建立与底层数据库的通信通道并作为针对数据库系统执行查询的驱动器。在典型的J2EE应用中，为例如DB2TM和OracleTM的RDBMS定义数据源，以便为应用提供JDBC接口以执行查询。数据库的物理位置被封装在数据源定义中，并从应用抽象，以便于开发和部署可移植性。用数据源JNDI名(在应用部署描述符中)配置应用实体bean；通过使用数据源JNDI名，框架在运行时执行JNDI查找，以便获取数据源实例，并将其用于源于相关联的实体bean的所有数据库查询。
为了针对分区数据库节点102-106的群集部署这类应用，所有源于该应用的数据库查询被截取，并对它们进行分析以得知可应答/执行该查询的分区节点。使用FE-RDBMS 202-206截取查询。使用所介绍的方法，应用可被自动且透明地修改，以便通过在FE-RDBMS 202-206中动态定义其模式与应用数据库的模式相匹配的空数据库实例以及用应用数据库的JNDI名为之定义数据源定义并将应用数据库的JNDI名重新命名为新的唯一名，来针对FE-RDBMS 202-206对它们进行部署。这使得FE-RDBMS 202-206能够在不改变应用代码的情况下“获取”所有应用查询，并对它们进行分析和将其路由传递到可执行和应答该查询的数据库分区节点。作为应用部署的一部分，FE-RDBMS 202-206被配置为具有数据库分区拓扑，并且通过使用该数据库分区拓扑，FE-RDBMS 202-206使用JDBC接口将该查询(或多个查询)分区、重新生成以及路由传递到适当的数据库分区节点。如果查询跨多个数据库分区，则FE-RDBMS 202-206为各个分区产生查询片段，并在各分区的结果上执行联结，以便为应用构成最终的结果集。不需要来自应用提供者的任何代码、查询生成或部署支持来使能针对分区数据库群集的J2EE应用部署。
如果执行查询涉及一个以上的数据库分区节点，则FE-RDBMS202-206分析、产生查询片段并对结果进行联结。
体系结构200对J2EE应用提供了透明的支持，以针对具有分区数据的数据库群集对它们进行部署。该框架透明地将应用查询路由传递到可执行该查询的适当的数据库分区节点。应用不需要承载任何逻辑或代码以便与该分区数据库群集一起工作。
通过使应用能够针对数据库分区被部署，体系结构200改善了应用和数据库性能。
体系结构200使J2EE应用能够与数据库厂商以及产品松散耦合，并自备了对使用数据库分区的支持。
体系结构200适合于应用服务器的群集部署，且没有将查询路由传递到适当的数据库分区节点的单故障点。
查询路由传递逻辑被部署在FE-RDBMS 202-206处，其对应用来说是本地的，并将查询直接路由传递到“正确的”远程数据库分区。在这种体系结构200中避免了分析查询的额外停止，这改善了性能，并使J2EE框架能够针对分区数据库群集透明地部署应用。
组合解决方案有可能将实现包含分区数据源的群集以及每个分区具有复制品的两个方案组合起来。这将提供二级负载平衡、可用性和性能优点。
权利要求
1.一种用于配置访问共用数据库的群集web服务节点的方法，包括在各节点上实现数据虚拟化层，以便将所述数据库的实例从web服务应用抽象。
2.一种在访问共用数据库的一组节点上执行web服务操作的方法，所述数据库被安排为由主实体bean处理的主实例以及至少一个复制品实例，所述方法包括在每一所述节点上执行的以下步骤创建具有所述主实体bean的所有读取与写入操作的第一数据虚拟化实体bean；创建仅承载所述主实体bean的读取操作并处理所述复制品实例的第二实体bean；在所述第一实体bean处接收操作请求；以及取决于所述请求的访问所述相应的数据库实例的操作，将所述请求路由传递到所述主实体bean或是所述第二实体bean。
3.根据权利要求2的方法，其中，如果请求写入操作，则所述请求被路由传递到所述主实体bean。
4.根据权利要求2的方法，其中，如果请求读取操作，则如果(i)不存在涉及写入操作的先前所述请求，或(ii)所述复制品实例与所述主实例同步，所述请求被路由传递到所述第二实体bean，否则，所述请求被路由传递到所述主实体bean。
5.根据权利要求2的方法，包括将操作请求引导到所述节点之一的进一步的初始步骤。
6.一种由访问共用数据库的一组节点形成的web服务服务器，所述数据库被安排为由主实体bean处理的主实例以及至少一个复制品实例，每一节点包含处理器，该处理器用于创建具有所述主实体bean的所有读取与写入操作的第一数据虚拟化实体bean，创建仅承载所述主实体bean的读取操作并处理所述复制品实例的第二实体bean；在所述第一实体bean处接收操作请求；以及取决于所述请求的访问所述相应的数据库实例的操作，将所述请求路由传递到所述主实体bean或是所述第二实体bean。
7.根据权利要求6的服务器，其中，如果请求写入操作，则所述请求被所述处理器路由传递到所述主实体bean。
8.根据权利要求6的服务器，其中，如果请求读取操作，则如果(i)不存在涉及写入操作的先前所述请求，或(ii)所述复制品实例与所述主实例同步，所述请求被所述服务器路由传递到所述第二实体bean，否则，所述请求被路由传递到所述主实体bean。
9.根据权利要求6的服务器，进一步包含分派器，该分派器用于将操作请求引导到所述节点之一。
10.一种在访问共用数据库的一组节点上执行web服务的方法，所述数据库被安排为不离散的、不重叠的分区实例，所述方法包括在每一所述节点上执行的以下步骤实现空数据库实例，其具有与所述共用数据库相匹配的模式；利用所述空数据库在所述查询中识别相关的分区；以及将所述查询路由传递到相应的分区数据库实例。
11.根据权利要求10的方法，包括接收来自所述相应的分区数据库实例的结果集的进一步的步骤。
12.根据权利要求11的方法，其中，如果查询跨一个以上的所述分区数据库实例，则识别所述相关的分区，且将所述结果集形成为相应的结果集的联结。
13.根据权利要求10的方法，包括将查询引导到所述节点之一的进一步的初始步骤。
14.一种由访问共用数据库的一组节点形成的web服务服务器，所述数据库被安排为离散的、不重叠的分区实例，每一所述节点包含处理器，该处理器用于实现空数据库实例，其具有与所述共用数据库相匹配的模式；利用所述空数据库在所述查询中识别相关的分区；以及将所述查询路由传递到相应的分区数据库实例。
15.根据权利要求14的服务器，其中，所述处理器进一步接收来自所述相应的分区数据库实例的结果集。
16.根据权利要求15的服务器，其中，如果查询跨一个以上的所述分区数据库实例，则所述处理器识别所述相关的分区，且所述结果集被形成为相应的结果集的联结。
17.根据权利要求14的服务器，进一步包含分派器，该分派器用于将操作请求引导到所述节点之一。
18.一种系统，其实现根据权利要求2-4中任何一个的方法。
19.一种系统，其实现根据权利要求10-13中任何一个的方法。
全文摘要
公开了对访问共用数据库的群集web服务节点的配置，其包括在每一节点上实现数据库虚拟化层以便将数据库的实例从web服务应用抽象。在一个实施例中，在每一节点上执行以下操作创建具有应用开发的(主)实体bean的所有读取和写入操作的第一数据虚拟化实体bean；创建仅承载主实体bean的读取操作并处理复制品实例的第二实体bean；在第一实体bean上接收操作请求；以及取决于被请求的访问相应的数据库实例的操作，将请求路由传递到主实体bean或是第二实体bean。在另一实施例中，在每一节点上执行实现空数据库实例，其具有与共用数据库相匹配的模式；利用该空数据库在查询中识别相关的分区，以及将查询路由传递到相应的分区数据库实例。
文档编号G06F17/30GK101042767SQ200710084809
公开日2007年9月26日 申请日期2007年2月27日 优先权日2006年2月28日
发明者V·S·巴特拉, W-S·李 申请人:国际商业机器公司