Abstract:
An enterprise locking service coordinates multiple cooperating applications to ensure that one and only one user is modifying a database record at a given time. The database records may be stored in multiple databases having potentially different database record locking protocols. Through monitoring and tracking requests for database locks, the enterprise locking service is also able to determine database usage trends under various metrics.

Description:
PRIORITY CLAIM 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 11/046,390, filed on Jan. 27, 2005, and titled, “Customer Statistics Based on Database Lock Use,” the disclosure of which is hereby incorporated herein by reference in its entirety for all purposes. 
     
    
     BACKGROUND 
       [0002]    The disclosure relates in general to the field of on-demand computer databases, and in particular to database locks for use with the on-demand computer databases. Still more particularly, the disclosure relates to a method and service for monitoring use of database locks to describe and evaluate customer use of the on-demand computer databases. 
         [0003]    In an effort to become more responsive to changing business needs, many companies are incorporating the services of third-party Information Technology (IT) service providers. One example of such a service provider is IBM&#39;s On-Demand Business™ service provided by International Business Machines Corporation of Armonk, N.Y. 
         [0004]    One aspect of IBM&#39;s On-Demand Business™ service is illustrated in  FIG. 1  as an Operating Environment Architecture (OEA)  100 . A user  102  is able to communicate with multiple application services  104  via an interface identified as business services  106 . Application services  104 , via a middleware depicted as Enterprise Service Bus (ESB)  108 , is able to access a variety of infrastructure services  110 . As depicted, infrastructure services  110  include utility business services, service level automation and orchestration, and resource virtualization services. As discussed below, businesses  112  are also able to communicate with user  102  and infrastructure services  110  via enterprise service bus  108 . 
         [0005]    An example of the OEA  100  and its use is as follows. User  102  might be a call center, which can receive a call from a truck driver who is on the road and needing a truck tire to be replaced by the side of the road. The truck driver (not shown) can contact the call center requesting such assistance. The call center (user  102 ) accesses an appropriate application service, such a user access service, user interaction service, business process choreography service, business function service, common service and/or information management service. These application services establish the appropriate protocol to send the request for flat tire assistance to the ESB  108 , which forwards the service request to a business  112 , such as a tire service company. In addition, business  112  may also be the owner of the truck (or fleet) being driven by the driver who requested the road service, thus permitting the fleet owner to access databases in infrastructure services  110 . The fleet owner is thus able to access the database in the infrastructure services  110  to monitor what service has been requested and the charge for that service. The call center (user  102 ) interfaces with the driver who requested the tire service, and a new tire is delivered (or the old tire is repaired). In this scenario, the database record associated with the service call may be locked for tens of minutes while the call center tries to locate a nearby service provide available to provide the service. 
         [0006]    Note again that application services  104  and infrastructure services  110  are accessible to multiple users  102  and businesses  112 , thus making the On-Demand OEA  100 , scalable, flexible, expandable, but also in need of coordination and control. 
         [0007]    One area of control that is required is control of various databases, including those found in infrastructure services  110 . For example, one or more of the databases in infrastructure services  110  may need to be temporarily locked while order information, billing information, etc., is being accessed and/or updated by either a user  102  or a business  112 . This locking procedure is accomplished by a specialized piece of software known as a database lock. In the prior art, each database software vendor for a particular database required a user  102  (or a business  112 ) to be in communication with that database and to use a particularly formatted database lock to lock a database. This has proven cumbersome, and thus there is a need for a universal database locking system that is able to lock any of the databases, no matter which database software vendor is supplying/maintaining the databases. 
         [0008]    In addition to the need for establishing a universal database locking system, there is also a need for a method and service to monitor and evaluate the use of database locks, thus providing information regarding which databases are being used and under what parameters (by whom, where, when, etc.). 
       SUMMARY 
       [0009]    The present invention is directed to an enterprise locking service that is able to coordinate multiple cooperating applications that need to ensure that one and only one user is modifying a database record at a given time. These database records may be stored in multiple databases having potentially different database record locking protocols. Through monitoring and tracking of requests for database locks, the enterprise locking service is also able to determine database usage trends under various metrics. 
         [0010]    The above, as well as additional purposes, features, and advantages of the present invention will become apparent in the following detailed written description. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]    The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further purposes and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, where: 
           [0012]      FIG. 1  depicts a prior art On Demand Operating Environment Architecture (OEA); 
           [0013]      FIG. 2  is a block diagram of an exemplary computer system that may be used by the present invention; 
           [0014]      FIG. 3  is a block diagram of an On Demand service that incorporates the inventive Enterprise Locking Service (ELS); 
           [0015]      FIG. 4  is a block diagram of additional details of the ELS shown in  FIG. 3 ; 
           [0016]      FIG. 5   a  illustrates a first two swim lanes depicting a client application and an enterprise service bus, according to one or more embodiments; 
           [0017]      FIG. 5   b  illustrates a third swim lanes depicting an enterprise locking service, according to one or more embodiments; 
           [0018]      FIG. 5   c  illustrates fourth and fifth swim lanes depicting a lock database and a first business object, according to one or more embodiments; 
           [0019]      FIG. 5   d  illustrates sixth and seventh swim lanes depicting a second business object and an enterprise lock monitoring and reporting service, according to one or more embodiments; 
           [0020]      FIG. 6  is a block diagram of a lock request message; and 
           [0021]      FIG. 7  is an exemplary customer contact “dashboard” based on database lock usage across all customer-related applications using the ELS. 
       
    
    
     DETAILED DESCRIPTION 
       [0022]    With reference now to  FIG. 2 , there is depicted a block diagram of an exemplary data processing system in which a preferred embodiment of the present invention may be implemented. Data processing system  200  may be, for example, one of the models of personal or server computers available from International Business Machines Corporation of Armonk, N.Y. Data processing system  200  includes a central processing unit (CPU)  202 , which is connected to a system bus  208 . In the exemplary embodiment, data processing system  200  includes a graphics adapter  204 , which is also connected to system bus  208 , for providing user interface information to a display  206 . 
         [0023]    Also connected to system bus  208  are a system memory  210  and an input/output (I/O) bus bridge  212 . I/O bus bridge  212  couples an I/O bus  214  to system bus  208 , relaying and/or transforming data transactions from one bus to the other. Peripheral devices such as nonvolatile storage  216 , which may be a hard disk drive, optical drive, or similar mass storage device(s). Also attached to I/O bus  214  is an input device  218 , which may include a conventional mouse, a trackball, or the like, as well as a keyboard or similar device. 
         [0024]    Also coupled to I/O bus  214  is a network interface  220 , which provides network communication via a network  222  to remote devices, including computer logic and/or software described and identified in  FIG. 1  as user  102  and/or business  112 . 
         [0025]    The exemplary embodiment shown in  FIG. 2  is provided solely for the purposes of explaining the invention and those skilled in the art will recognize that numerous variations are possible, both in form and function. For instance, data processing system  200  might also include a sound card and audio speakers, and numerous other optional components. All such variations are believed to be within the spirit and scope of the present invention. 
         [0026]    With reference now to  FIG. 3 , there is illustrated a block diagram of an Operating Environment Architecture (OEA)  300 . OEA  300  includes a service request receiver  302 , which communicates with an Enterprise Locking Service (ELS)  304 , which communicates with a plurality of databases  306 . Databases  306  are maintained by one or more business service providers, which preferably do not maintain/operate ELS  304 . Service request receiver  302  may be a user, such as user  102  or a business  112  described in  FIG. 1 . That is, service request receiver  302  is any entity wishing to utilize ELS  304  to lock/unlock one or more of the plurality of databases  306  in accordance with the present invention. In an exemplary form, databases  306  may be included in infrastructure services  110  described above in  FIG. 1 . 
         [0027]    With reference now to  FIG. 4 , a block diagram showing additional details of ELS  304  is provided. ELS  304  includes, but is not limited to, the following features. A lock list  402  includes a list of database locks identified with a particular client. That is, lock list  402  includes a list of database locks which are able to lock one or more of the plurality of databases  306  shown in  FIG. 3 , and associated with each of these database locks are the entities which are authorized to use the database lock. These entities may be identified as clients, customers, users, business, sessions, etc. Alternatively, lock list  402  may be a list of entities, with database locks associated with each of the entities. 
         [0028]    ELS  304  also includes a map  404  of all databases that need to be simultaneously locked by an entity. For example, when an entity locks a first database, because of relational issues, a second database may also need to be simultaneously locked to maintain data coherency. 
         [0029]    A file table  406  is also located in ELS  304 . File table  406  is a table of all files in all databases. Thus, when an entity requests that only a particular file in a database be locked, file table  406  can identify the particular file in order to transmit the database lock to only lock out that particular file. 
         [0030]    As mentioned above, databases maintained by different vendors may have differently formatted database locks. For example, some database locks may be strings while other database locks are numeric values. Thus, ELS  304  has a translation table  408 , which is able to translate (format) the authorized database lock into a style that is understood by the database that is to be locked. 
         [0031]    ELS  304  also has a list of active locks  410 , which includes information on which client (if any) has currently locked up a database record, the expiration time (or period) of the database lock (if any), etc. Thus, if a first client requests a database lock on a particular database record, and that database record has already been locked by a second client, then list of active locks  410  can provide information to the first client regarding what entity is currently locking up the database. This allows the first client the option of contacting the second client, either through software, automatic dial-up, or voice communication, requesting that the second client to release the lock on the database record. 
         [0032]    With reference now to  FIG. 5   a,  there is depicted a “swim-lane” diagram of enterprise locking service interactions in accordance with a preferred embodiment of the present invention.  FIGS. 5   a - 5   d  depicts seven “swim-lanes.” 
         [0033]    The first swim-lane is a client application  502 , which is preferably a session enterprise Java bean, which is part of a large Java 2 Enterprise Edition (J2EE) application. Client application  502  may operate anywhere within an OEA  100 , as depicted in  FIG. 1 , but is preferably functioning with application services  104 . 
         [0034]    The second swim-lane in  FIG. 5   a  is an enterprise service bus  504 , which is middleware as described above in  FIG. 1  for enterprise service bus  108 . 
         [0035]    The third swim-lane is an enterprise locking service  506 , which is part of ELS  304  (described above in  FIG. 3 ). Besides the functions described below, enterprise locking service  506  determines if a database lock is needed and available, and builds a database lock entry to insert in the lock list  410  if necessary. 
         [0036]    The fourth swim-lane is a lock database  508 , which is also included in ELS  304 , and includes lock list  402 , map  404 , and file table  406 . 
         [0037]    Swim lanes five and six are business objects  510  and  512 , which are preferably entity enterprise Java beans, which can be clustered over a variety of runtime platforms. That is, business objects  510  and  512  are preferably coarse-grained business concepts that are visible to a user in the business world. Attributes found within the entity enterprise Java beans include a high-level identifier and all data whose combination together uniquely identify the object of interest from all others stored. Many other optional or non-unique attributes may also be stored. For example, business object  510  may be a software object used to store all attributes related to a customer order, and can also identify the attributes of the user placing the order. 
         [0038]    Swim lane seven is an enterprise lock monitoring and reporting service  514 , which uses database lock requests to track and map different metrics as described below. 
       Creating and Using a Database Lock 
       [0039]    Steps depicted in  FIGS. 5   a - 5   d  according to the present invention are as follows. A user  516  calls a general application logic (step  518 ), which then determines the need for a database record lock (step  520 ), resulting in a lock request being built using a web service message (step  522 ). Note that while user  516  may be the user  102  of business  112  described above, user  516  may be any entity, either personal or electronic, needing to create, use, monitor and/or track database locks as described below so that only one user ( 102  or  112 ) is allowed to modify a database record of interest at a time. 
         [0040]    Referring now to  FIG. 6 , details of an exemplary lock request message  602 , built in step  522  of  FIG. 5   a,  are shown. Lock request message  602  includes a unique lock request message text string  604  which identifies a lock request from other types of messages on the computer network. A user identifier  606  identifies the user who needs the database lock. In the case of a call center, this would be the user identifier of a customer service representative acting on behalf a customer calling on the phone. In the case of customer self-service, this would be the user identifier of the customer himself. 
         [0041]    An access channel identifier  608  identifies what type of access (customer contact) channel that the user identified by user identifier  606  is using. Such access channels may include web sessions, a call center, a voice response unit, a kiosk, etc. Thus, the access channel may use data, voice, or both. 
         [0042]    An optional user geographic identifier  610  identifies a geographic location of the user. This location may be at any granularity, including a world-wide location, a state-wide location, a local location, or even a location of a desk or office within an enterprise. 
         [0043]    The user type  612  can be used to identify characteristics of the user requesting the lock such as whether the user is an internal user or external user. A call center user, for example, would likely be an internal user. A self-service web user would likely be identified as an “external” or “web user.” Other possibilities include differentiating users who represent themselves (individual customers) vs. users who represent a business (corporate customer). 
         [0044]    The user metric  614  is used to categorize or prioritize users. Examples for internal users might include regular employees vs. managers. Examples for external customers might be some profitability metric based on past transaction history. 
         [0045]    A time identifier  616  identifies the date and time that requests for a database lock was created. With time identifier  616  may also be stored the length of time that the requested database record lock will be valid, if generated. 
         [0046]    Lock Object Name  618  is a high-level alias name representing the type of business object that the user  606  needs to lock with the lock request message  602 . This might also be described as a coarse-grained business object name such as Customer or Purchase Order. This name should be recognized by all cooperating applications using the ELS. 
         [0047]    Object Unique Identifier  620  contains the data required to uniquely identify the single object of type specified by the lock object name  618  from all the other objects of the same type. This is equivalent to all the elements of the primary key if a relational database is used to store the object attributes. 
         [0048]    An optional object profitability metric  622  identifies the financial strength and past profitability of the object to be locked. For example, if the user  606  is trying perform administration on a Customer object, then metrics such as “Regular,” “Silver,” “Gold” or “Platinum” might be provided according to the customer&#39;s average sized purchases and/or financial strength (such as a Dun and Bradstreet rating). This information may be left blank if it does not make sense to apply a profitability metric to the object type. For example, it may make no sense to apply a profitability metric to an object representing an internal user. Alternatively, the profitability metric  622  may be associated with a particular customer order or a line of products, either or both of which are described in an order and/or product database. 
         [0049]    An optional object geography  624  is used to identify any relevant geographic association to the object to be locked. For example, if trying to lock a Customer object, then values such as “USA”, “Canada”, “North”, or “South” might apply. The lock may be associated with either a real-time present location of a user, or may be generally associated with a database associated with such a geographic region. 
         [0050]    A “reply to” identifier  626  provides information for sending a response from the enterprise locking service. Preferably, such a location is URL, an IP address, a telephone number, mailing address, or a physical location. 
         [0051]    With reference again to the steps depicted in  FIGS. 5   a - 5   d,  the lock request message is delivered to enterprise service bus  504  (step  524 ). The enterprise service bus then delivers the lock request to the enterprise locking service  506 . Enterprise locking service  506  then parses the lock request message (step  526 ), and determines if the user  516  already has a lock on the requested database record (step  528 ). To make this determination, a query for the lock applicable to the requested database record (identified by the Object Unique ID  620 ) is made of the lock database  508  (step  530 ). The lock database executes the query and returns the lock database record back to the enterprise locking service  506 , which then inspects the user ID of the record and makes a decision as to whether the lock for the applicable database record (identified by the Object Unique ID  620 ) exists for user  516  (step  532 ). If such a lock does exist, then the timestamp on the lock is updated (step  534 ), the lock timestamp is updated in lock database  508  (step  535 ), and a “lock available” message is built (step  536 ). The lock available message is delivered to enterprise service bus  504  (step  538 ), and the lock available message is used to update potentially multiple business objects on multiple databases (step  540 ). That is, if user  516  needs access to multiple databases, which can be locked with a single database lock, this ability is provided in client application  502 . The multiple business objects together compose a high-level object having the object name  618  and are identified uniquely by object ID  620  are shown as  510  and  512 . 
         [0052]    Business object attributes are updated in all relevant business objects (steps  542  and  544 ), after which the client application determines whether the lock is still needed (step  546 ). If the lock is no longer needed, then the client application builds a “lock release” message (step  548 ). The lock release message is then delivered to the enterprise service bus  504  (step  550 ), resulting in the user&#39;s lock being released (step  552 ) and deleted (step  554 ) in the lock database  508  (indicating that the lock is no longer currently being used). User  516  interacting with client application  502  is then “done” with the lock and other users of other clients using the same enterprise locking service  506  may now attempt to access and update the same business objects and their associated database records. 
         [0053]    Returning to step  532 , if a database lock does not exist for user  516 , then the enterprise locking service inspects the lock database record returned from step  530  to determine whether another user has already locked the requested database (step  556 ). If another user has locked the requested database, then a “lock unavailable” message is built (step  558 ). The “block unavailable” message is then delivered to the enterprise service bus  504  (step  560 ), resulting in the client application  502  displaying an error message to the user (step  562 ). This message may optionally inform the user  516  of the identity of the other user holding the lock on the desired business objects and associated database records. 
         [0054]    Again returning to step  556 , if another user has not locked the requested database record, then a brand new database lock for user  516  is created (step  564 ), and the new lock is inserted into lock database  508  (step  566 ), resulting in a “lock available” message being built (step  536 ), delivered to the enterprise service bus (step  538 ) and sent to the client application  502  where the client can potentially modify multiple business objects in step  540 . The multiple business objects together compose a high-level object having the object name  618  and are identified uniquely by object ID  620  are shown as  510  and  512 . 
       Monitoring and Reporting Database Lock Use 
       [0055]    With reference now to the enterprise lock monitoring and reporting service lane  514 , a systems management user  517  can create a query for currently active locks (step  568 ). The active locks are retrieved from lock database  508  (step  570 ), and business data associated with the active locks is gathered (step  572 ). From all relevant business objects (such as business objects  510  and  512 ), business data associated with the lock is retrieved (steps  574   a - b ), and a real-time customer “dashboard” display is created (step  576 ). Lock usage is compared across all customer access channels (step  578 ), and appropriate steps based on the comparison in step  578  are then taken (step  580 ). Examples of such steps taken include increasing server capacity for customer access channels with higher lock usage, or alternatively, decreasing such server capacity. Additionally, new channels may be opened or closed. Such channels include kiosks, expanded websites, phone centers, etc. The requirement for additional or fewer infrastructure resources are then communicated to the enterprise service bus  504  (step  582 ), above. The enterprise service bus delivers these “need more” or “need less” resources messages to the Infrastructure Services  110  tied to the enterprise service bus  108  in  FIG. 1  above, thus promoting the “on demand” server infrastructure described in  FIG. 1   
         [0056]    With reference now to step  584  in the enterprise locking service  506  swim-lane, a constant loop checks for locks which have been abandoned or should be expired. To make such checks, old locks are retrieved (step  586 ), the old locks are then expired (step  588 ), and deleted (step  590 ). 
         [0057]    Referring again to step  572 , other metrics besides the access channel used may be monitored to create the “dashboard” display described in step  576 . These metrics include, but are not limited to, those identifiers discussed above in  FIG. 6 . 
         [0058]    With reference now to  FIG. 7 , an exemplary real-time dashboard  702  is depicted. Dashboard  700  is the result of steps described above in the enterprise lock monitoring and reporting service  514  swim-lane of  FIG. 5   d.  Dashboard  702  depicts the type of access channel source of customer orders. These access channels include voice response units (VRU), e-mail, call centers, website hits, kiosks, fax and mail channels. If a predetermined (or dynamically determined) level of traffic is exceeded (such as for call centers), then overtime for employees in existing call centers may be authorized, additional telephone lines and operators may be added, or new call centers may be opened. Conversely, if the call center(s) do not justify the traffic levels indicated, then a reduction of resources may be advised. Note that the dashboard  702  is determined by the number of lock requests submitted from the various access channels as identified by the User Access Channel  608  in the lock request message  602 . 
         [0059]    While  FIG. 7  depicts a chart of requests for database locks per type of access channel, similar charts can be generated for individual locations (particular call centers, etc.). Likewise, similar charts can be generated using any of the metrics described above in  FIG. 6 , including user geographical regions, geographies associated with business objects, time of day, user profitability metrics (e.g., “Regular,” “Silver,” “Gold,” “Platinum”), profitability metrics associated with the objects being locked (e.g. size of a customer order), type of user (individual/enterprise), type of client application (whether request for a lock is from a software object that places orders, creates bills, updates client information, etc.), etc. 
         [0060]    It should be understood that at least some aspects of the present invention may alternatively be implemented in a program product. Programs defining functions on the present invention can be delivered to a data storage system or a computer system via a variety of signal-bearing media, which include, without limitation, non-writable storage media (e.g., CD-ROM), writable storage media (e.g., a floppy diskette, hard disk drive, read/write CD ROM, optical media), and communication media, such as computer and telephone networks including Ethernet. It should be understood, therefore in such signal-bearing media when carrying or encoding computer readable instructions that direct method functions in the present invention, represent alternative embodiments of the present invention. Further, it is understood that the present invention may be implemented by a system having means in the form of hardware, software, or a combination of software and hardware as described herein or their equivalent. 
         [0061]    While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.