Abstract:
A method and system for resolving access to a common resource for competing processes. According to one embodiment, a resource manager receives a request from a first process to access a resource, receives a request from a second process to access the resource, the request from the second process arriving after the request from the first process, grants access to the resource to the first process, queues the access request from the second process until the resource is released by the first process, and notifies the second process that its access request has been queued, wherein upon receiving the notification, the second process resumes operation as if the second process had been granted access to and released the resource.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]    This application is related to the subject matter of the following U.S. patent applications filed on even date: attorney docket no. 11884-400801 entitled “System and Method for Incremental Object Generation,” attorney docket no. 11884-403501 entitled “System and Method for Object Navigation Grammar Completion,” attorney docket no. 11884-403601 entitled “System and Method for Rule Based Object Navigation,” and attorney docket no. 11884-403801 entitled “System and Method for Generator State Object Validation.” 
     
    
     
       BACKGROUND OF THE INVENTION  
         [0002]    When two processes attempt to access a common resource at the same time, access is usually granted to the first process that requests the resource, while the second process is forced to block (i.e., wait) until the first process releases the resource. Forcing the second process to block for access to the resource can lead to bad usability, especially when human computer users are left waiting in real-time for their programs to resume operation.  
           [0003]    Accordingly, there is a need in the art for a system and method that allows a process to resume operation before having access granted to a common resource.  
         SUMMARY OF THE INVENTION  
         [0004]    Embodiments of the present invention provide for resolving access to a common resource for competing processes. According to one embodiment, a resource manager receives a request from a first process to access a resource, receives a request from a second process to access the resource, the request from the second process arriving after the request from the first process, grants access to the resource to the first process, queues the access request from the second process until the resource is released by the first process, and notifies the second process that its access request has been queued, wherein upon receiving the notification, the second process resumes operation as if the second process had been granted access to and released the resource. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0005]    [0005]FIG. 1 is a flow chart that depicts a process for asynchronous resource management in accordance with an embodiment of the present invention.  
         [0006]    [0006]FIG. 2 is a block diagram that depicts a user computing device in accordance with an embodiment of the present invention.  
         [0007]    [0007]FIG. 3 is a block diagram that depicts a network architecture for a development environment in accordance with an embodiment of the present invention.  
         [0008]    [0008]FIG. 4 is a block diagram that depicts modeling and generating an application development environment and corresponding applications that are compatible with an existing framework in accordance with an embodiment of the present invention.  
         [0009]    [0009]FIG. 5 is a block diagram that depicts the metalevels of repository based application development using the OMG Meta Object Facility (MOF) architecture in accordance with an embodiment of the present invention.  
         [0010]    [0010]FIG. 6 is a screen shot of an object browser for modeling business objects in accordance with an embodiment of the present invention.  
         [0011]    [0011]FIG. 7 is a screen shot of an object browser for modeling user interface elements in accordance with an embodiment of the present invention.  
         [0012]    [0012]FIG. 8 is a block diagram that depicts changelist management in accordance with an embodiment of the present invention.  
         [0013]    [0013]FIG. 9 is a block diagram that depicts changelist management in accordance with an embodiment of the present invention.  
         [0014]    [0014]FIG. 10 is a screen shot of a changelist browser in accordance with an embodiment of the present invention.  
         [0015]    [0015]FIG. 11 is a screen shot of a particular changelist in accordance with an embodiment of the present invention.  
         [0016]    [0016]FIG. 12 is an abstract object repository model in accordance with an embodiment of the present invention.  
         [0017]    [0017]FIG. 13 is an general framework object model in accordance with an embodiment of the present invention.  
         [0018]    [0018]FIG. 14 is a detailed framework object model in accordance with an embodiment of the present invention.  
         [0019]    [0019]FIG. 15 is a block diagram that depicts the generation of invalidation rules into application repository in accordance with an embodiment of the present invention.  
         [0020]    [0020]FIG. 16 is a flow chart that depicts a process for generating invalidation rule objects in accordance with an embodiment of the present invention.  
         [0021]    [0021]FIG. 17 is a block diagram of a repository based application development environment in accordance with an embodiment of the present invention.  
         [0022]    [0022]FIG. 18 is a block diagram of a data structure representing a runtime object in accordance with an embodiment of the present invention.  
         [0023]    [0023]FIG. 19 is a sequence diagram that depicts the flow of a repository based application development environment during invalidation of a development object in accordance with an embodiment of the present invention.  
         [0024]    [0024]FIG. 20 is a sequence diagram that depicts the flow of a repository based application development environment during generation of a development object in accordance with an embodiment of the present invention.  
         [0025]    [0025]FIG. 21 is a screen shot of a generator settings window in accordance with an embodiment of the present invention.  
         [0026]    [0026]FIG. 22 is a block diagram of a data structure representing a runtime object in accordance with an embodiment of the present invention.  
         [0027]    [0027]FIG. 23 is a diagram that depicts interfering validation/invalidation processes in accordance with an embodiment of the present invention.  
         [0028]    [0028]FIG. 24 is a sequence diagram that depicts the flow of a repository based application development environment during invalidation of a development object in accordance with an embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION  
     Overview  
       [0029]    [0029]FIG. 1 depicts a process for asynchronous resource management in accordance with an embodiment of the present invention. When a process requests a common resource (step  100 ) that is available (“no” branch of step  110 ), the process is able to utilize the resource (step  120 ) and, upon releasing the resource, returns to its normal operation (step  130 ). When an interfering process holds the resource (“yes” branch of step  110 ), a resource manager queues the resource request until the interfering process is complete (step  150 ), allowing the requesting process to resume normal operation even though it had not utilized the resource (step  140 ). Once the interfering process is complete, the resource manager utilizes the resource on behalf of the requesting process (step  160 ).  
         [0030]    Embodiments described below illustrate an application development environment within which the present invention may be implemented.  
       Development Environment  
       [0031]    [0031]FIGS. 2 and 3 illustrate the components of a basic development environment in accordance with an embodiment of the present invention. FIG. 2, depicts client computing device  200 , which may be a workstation, personal computer, handheld personal digital assistant (“PDA”), or any other type of microprocessor-based device. Client computing device  200  may include a processor  210 , input device  220 , output device  230 , storage device  240 , client software  250 , and communication device  260 .  
         [0032]    Input device  220  may include a keyboard, mouse, pen-operated touch screen, voice-recognition device, or any other device that provides input from a user. Output device  230  may include a monitor, printer, disk drive, speakers, or any other device that provides output to user.  
         [0033]    Storage device  240  may include volatile and nonvolatile data storage, including one or more electrical, magnetic or optical memories such as a RAM, cache, hard drive, CD-ROM drive, tape drive or removable storage disk. Communication device  260  may include a modem, network interface card, or any other device capable of transmitting and receiving signals over a network. The components of client computing device  200  may be connected via an electrical bus or wirelessly.  
         [0034]    Client software  250  may be stored in storage device  240  and executed by processor  210 , and may include, for example, the client side of a client/server application such as the SAP Mobile Application Studio component of a mySAP Customer Relationship Management (CRM) installation package that embodies the functionality of the present invention.  
         [0035]    [0035]FIG. 3 illustrates a network architecture for a development environment in accordance with an embodiment of the present invention. According to one particular embodiment, when developer  300   a  invokes an SAP Mobile Application Studio application, client software  250  of client computing device  200   a  communicates with server software  330  (e.g., the server side of the SAP Mobile Application Studio application) of server  320  via network link  315   a , network  310 , and network link  315   d.    
         [0036]    Network link  315  may include telephone lines, DSL, cable networks, T1 or T3 lines, wireless network connections, or any other arrangement that implements the transmission and reception of network signals. Network  310  may include any type of interconnected communication system, and may implement any communications protocol, which may secured by any security protocol.  
         [0037]    Server  320  includes a processor and memory for executing program instructions, as well as a network interface, and may include a collection of servers. In one particular embodiment, server  320  may include a combination of enterprise servers such as an application server and a database server. Database  340  may represent a relational or object database, and may be accessed via a database server.  
         [0038]    Client computing device  200  and server  320  may implement any operating system, such as Windows or UNIX. Client software  250  and server software  330  may be written in any programming language, such as ABAP, C, C++, Java or Visual Basic.  
       Repository Based Application Development  
       [0039]    An embodiment of the present invention may be implemented through the use of a repository based application development environment. In this type of environment, application metadata is modeled (e.g., developed and tested) using an application repository, and then generated into a runtime application to be executed within its corresponding application framework.  
         [0040]    Overview  
         [0041]    An application framework provides core services and functionality common to any application that may run on the framework. An application may take the form of runtime files that extend the basic functionality of the framework in order to achieve individual application behavior. In order to recognize and execute the application, the framework defines a particular format to which the application is expected to conform. By distinguishing an application from its framework in this manner, application development can focus on high-level functionality rather than the low-level, and generally static, services and functionality provided by the framework.  
         [0042]    In order for an application development environment to properly model and generate applications to run on an existing framework, the application development environment needs to have intimate knowledge of the framework architecture. The process of modeling and generating both an application development environment and the corresponding applications in conformance with an existing framework is illustrated in FIG. 4.  
         [0043]    Application framework  400  may represent an existing object-oriented framework with a three-tier architecture: presentation layer  410 , business logic layer  415  and persistence layer  420 . Presentation layer  410  may provide a user interface to user  405 , rendering data to and accepting data from user  405 . Business logic layer  415  may act as a data provider to presentation layer  410 , providing validation of user inputs and business rules, and other standard operations, such as save, delete, revert, etc. Persistence layer  420  may provide an abstraction over user database  425 , providing an object-oriented wrapper over relational data stored in user database  425 .  
         [0044]    Modeler  445  and application generator  455  are part of a repository based application development environment that enables application developers to model and generate applications such as runtime application  460  to run on application framework  400 . Since in this embodiment application framework  400  represents an object-oriented framework, application framework  400  defines a particular object format to which it expects runtime application  460  to conform. This object format is developed into modeler  445  and application generator  455  so that they may correctly model and generate runtime application  460 . Metamodeler  435  provides a modeling (or, more specifically, metamodeling) environment that enables framework developers to specify the object format of application framework  400  to be developed into modeler  445 .  
         [0045]    Thus, framework developers use metamodeler  435  to specify the type of objects (i.e., object type  430 ) defined by application framework  400 . This object type information is used to generate and develop modeler  445 , which is used by application developers to specify instances of these object types (i.e., object instance  440 ) in the development and testing of an application&#39;s metadata (i.e., metadata  450 ). Once the development and testing of metadata  450  is complete, application generator  455  generates metadata  450  into runtime application  460  for execution within application framework  400 .  
         [0046]    Transformation Between Application Metalevels  
         [0047]    This repository based development environment can be described using the OMG Meta Object Facility (MOF) architecture. The MOF is a 4 layer meta data architecture described as follows:  
         [0048]    The user object layer (MO) is comprised of the information that one wishes to describe. This information is typically referred to as data.  
         [0049]    The model layer (M 1 ) is comprised of the metadata that describes information. Metadata is informally aggregated as models.  
         [0050]    The metamodel layer (M 2 ) is comprised of the descriptions (i.e. meta-metadata) that define the structure and semantics of meta-data. Meta-metadata is informally aggregated as metamodels. A metamodel can also be thought of as a modeling language (e.g., UML is defined by a metamodel) for describing different kinds of data.  
         [0051]    The meta-metamodel layer (M 3 ) is comprised of the description of the structure and semantics of meta-metadata. In other words, it is the language for defining different kinds of metadata. The OMG MOF specification contains a standardized meta-metamodel which is designed to support the definition of different kinds of modeling languages like UML, IDL etc.  
         [0052]    [0052]FIG. 5, for example, metamodel  500  (the M 2  layer) represents the object types supported by application framework  400  that are specified by framework developers using metamodeler  435 . Repository generator  510  uses metamodel  500  to generate framework-specific parts of application repository  520  (the M 1  layer), which represent an object repository (i.e., database structure) and corresponding object navigational interface that are accessed by application developers via modeler  445  in the development and testing of metadata  450 . Application generator  455  generates metadata  450  into runtime application  460  (the M 0  layer) for execution within application framework  400 . The M 3  layer is not applicable to the current description of the repository based development environment.  
         [0053]    Modeler  
         [0054]    [0054]FIGS. 6-11 illustrate modeling screens and changelist management employed by modeler  445  in accordance with an embodiment of the present invention.  
         [0055]    Modeling Screens  
         [0056]    As shown in FIGS. 6 and 7, modeler  445  employs an object browser to enable application developers to view a hierarchical display of development objects to be generated into runtime application  460 , and to model development objects for business logic layer  415  (FIG. 6) and presentation layer  410  (FIG. 7) of runtime application  460 . A similar modeling environment may be employed to model development objects for persistence layer  420 .  
         [0057]    As an example, application framework  400  may define a business object type to represent the business logic for business logic layer  415  of runtime application  460 . In the business world, one may wish to model a sales organization that offers products or services to various customers. Since the organization would need to store information on its customers and decide how to offer its products or services in different market segments, a business object could represent customers, contact persons, products, sales opportunities, sales activities and sales promotions.  
         [0058]    A development object in modeler  445  may model each of the above business objects. For purposes of this discussion, although the term “object” may either refer to a class (i.e., object type  430 ) or an instance of a class (i.e., object instance  440 ), the term “object” is generally meant to portray an instance of a class, while the term “object type” is generally meant to portray the class itself.  
         [0059]    Thus, as shown in the “Object Modeler” sub-window in FIG. 6, an application developer has modeled several development objects (e.g., “Address”, “BusinessPartner”, “LOGIN”, “Order”, “OrderItem” and “Product”) representing business objects. Since application framework  400  has also defined attributes for a business object, modeler  445  provides those attributes (e.g., “Properties”, “Methods”, “Event Handlers”, “Relations”, “SaveRules”, “DeleteRules” and “UserExits”) for development as shown under the “Order” object in the “Object Modeler” sub-window in FIG. 6. The application developer develops the attributes for the business object “Order” using the “Business Object-Order” sub-window in FIG. 6.  
         [0060]    For example, the “Properties” attribute may represent the attributes of an entity of a real business world, such as a Sales Order object having properties like order number, order date, quantity. The “Methods” attribute may perform specific operations to manipulate data, such as a Sales Order object having a method to calculate and get the line items total. The “Event Handlers” attribute may describe a specific action that can occur against pre-defined events. The “Relations” attribute may define the interaction between different development objects based on business logic, such as a customer being associated to one or more sales orders. Business rules (e.g., the “SaveRules”, “DeleteRules” and “UserExits” attributes) may validate the object data for consistency, such as allowing the creation of a rule for the Sales Order object to check if the range of the order amount is consistent.  
         [0061]    [0061]FIG. 7 illustrates a similar modeling screen for UI objects, as defined by application framework  400 , to represent the screen elements for presentation layer  410  of runtime application  460 . As shown in the “UI Modeler” sub-window in FIG. 7, an application developer has modeled several development objects (e.g., “CustomerAddress”, “CustomerDetail”, etc.) representing tiles, which are UI objects similar to frames or sub-windows. The application developer develops the UI object “CustomerAddress” using the “Tile-CustomerAddress” sub-window in FIG. 7.  
         [0062]    Changelist Management  
         [0063]    As stated above, modeler  445  uses application repository  520  in the development and testing of metadata  450 . The framework-specific parts of application repository  520  represent an object repository and corresponding object navigational interface that provide for the storage and access of the development objects by modeler  445 . Due to the importance of tracking changes in a parallel and distributed development environment, application developers may operate on a development object via changelists, which allow the developers to maintain different versions of the development object in the object repository. This provides isolation of work in a multi-user development environment, as depicted in FIG. 3.  
         [0064]    A changelist is a collection of open versions of new or existing development objects that are derived from the repository baseline. The repository baseline specifies the current closed version of a development object in the object repository. As illustrated in FIG. 8, the repository baseline includes version  5  of development object  1 , version  3  of development object  2 , version  1  of development objects  3  and  4 , and version  3  of development object  5 . Since a first application developer is working on development objects  1  and  4 , the first developer&#39;s changelist includes version  6  of development object  1  and version  2  of development object  4 . Since a second application developer is working on development objects  2  and  5 , the second developer&#39;s changelist includes version  4  of development object  2  and version  4  of development object  5 . As illustrated in FIG. 9, when the second developer releases her changelist to the baseline, version  4  of development objects  2  and  5  become part of the new repository baseline that is now available for development and testing by other developers.  
         [0065]    An application developer may manage changelists through a changelist browser, as shown in FIG. 10, which keeps track of both open and released changelists of the developer and others. The selection of a particular changelist, such as “Y_NewChangelist 3 ” in the changelist browser in FIG. 10, may bring up an additional window describing the details of the development objects in that changelist, as shown in FIG. 11.  
         [0066]    Modeler  445  may include known configuration management tools to handle version management issues such as branching, collisions, etc. when developers work on the same development objects at the same time.  
       Incremental Generation Based on Invalidation Rules  
       [0067]    Within a repository based application development environment, such as the one described above, an embodiment of the present invention may be implemented to enable application generator  455  to generate only those elements of runtime application  460  that have been invalidated through rule-based navigation. The implementation of invalidation rule based generation depends upon the structure of and relationship between metadata  450  and runtime application  460 .  
         [0068]    Overview  
         [0069]    According to one embodiment of the present invention, the structure of metadata  450  and runtime application  460  may be represented in the object repository of application repository  520  based on the abstractions illustrated in the object repository model of FIG. 12. Development objects (DevelopmentObject  1200 ) represents the class of metadata  450 , which is the pre-generation data representation of the development objects as modeled by application developers in modeler  445 . This data representation, for example, could take the form of database tables wherein in each table represents a development object type, each column represents a particular development object and each row represents the attributes of a particular development object. Runtime objects (RunTimeObject  1220 ) represent the class of runtime files of runtime application  460  that are generated from the development object metadata to be executed by application framework  400 . Examples of runtime files could be binary files, JAVA class files and HTML layout files. In this particular model, development objects are classified as main development objects (RunTimeObjectOwner  1220 ) if they are top level objects associated with runtime objects.  
         [0070]    [0070]FIG. 13 illustrates an general framework object model (object model  1300 ) that may be defined by a framework developer based on the object repository model of FIG. 12. In FIG. 13, the framework designer creates MDO to represent a main development object type, and DO 1  through DO 6  to represent children development objects types associated with MDO. Runtime object types RTO 1  and RTO 2  are associated with MDO, since MDO is the top-level object in accordance with the object repository model of FIG. 12.  
         [0071]    Based on the requirements of application framework  400  and application generator  455  as defined by a framework developer, each runtime object type may only be influenced or affected by changes in a particular set of development object types. For example, during the modeling of specific instances of the framework object types of FIG. 13 in modeler  445 , changes made to development objects of types MDO, DO 1 , DO 2  and DO 5  may influence the associated runtime object of type RTO 1 , while changes made to development objects of types MDO, DO 3 , DO 4  and DO 6  may influence the associated runtime object of type RTO 2 . These relationships may be formalized into a set of invalidation rules in advance of any application development, and can be used during application development to invalidate only the influenced runtime objects of a particular changed development object, so that application generator  455  only has to regenerate the invalidated runtime objects instead of all runtime objects.  
         [0072]    Navigation Grammar Based on Object Semantics  
         [0073]    The invalidation rules may be formalized with an object navigation grammar in accordance with an embodiment of the present invention. For example, an object navigation grammar could define a navigation path through the object repository of application repository  520 , starting from a changed development object and ending at that development object&#39;s main development object, which is associated with the runtime object that is influenced by the changed development object.  
         [0074]    For example, the framework developer who created object model  1300  could formalize the associated invalidation rules as mentioned above using the following grammar:  
       RTO 1  Invalidation Rules  
       [0075]    AnyChange=&gt;D 05 .parent.parent:{RTO 1 } 
         [0076]    AnyChange=&gt;D 02 .parent:{RTO 1 } 
         [0077]    AnyChange=&gt;DO 1 .parent:{RTO 1 } 
       RT 02  Invalidation Rules  
       [0078]    AnyChange=&gt;D 06 .parent.parent:{RT 02 } 
         [0079]    AnyChange=&gt;D 04 .parent:{RT 02 } 
         [0080]    AnyChange=&gt;D 03 .parent.parent:{RT 02 } 
         [0081]    Using the first RTO 1  invalidation rule as an example, the object navigation grammar defines:  
         [0082]    the type of change required to fire the rule (e.g., “AnyChange”),  
         [0083]    the starting object type in the navigation path (e.g., “DO 5 ”),  
         [0084]    the navigation path via role names (e.g., “.parent.parent”), and  
         [0085]    the type of the resultant runtime object that requires invalidation (e.g., “{RTO 1 }”).  
         [0086]    Based on these rules, if a development object of type DO 2  were changed by an application developer in modeler  445 , the following of the above invalidation rules could be applied to determine which runtime objects are influenced by the changed DO 2  development object:  
         [0087]    AnyChange=&gt;DO 2 .parent:{RTO 1 } 
         [0088]    AnyChange=&gt;DO 3 .parent.parent:{RT 02 } 
         [0089]    The first of these rules is applied because the starting object type of the rule (DO 2 ) is that of the changed DO 2  development object. This first rule thus specifies that the RTO 1  runtime object associated with the parent of the changed DO 2  development object should be invalidated. The second of these rules is applied because DO 2  is in the navigation path of DO 3  (i.e., DO 2 =DO 3 .parent), and thus the rule specifies that the RTO 2  runtime object associated with the parent of the changed DO 2  development object (i.e., DO 2 .parent=DO 3 .parent.parent) should be invalidated. This second rule is applied because a corresponding DO 3  development object associated with the changed DO 2  development object could have also been changed due to the change in the DO 2  development object. For instance, the DO 2  development object could have replaced its associated DO 3  development object with a different DO 3  development object, thus requiring invalidation of the changed DO 2  development object&#39;s influenced RTO 2  runtime object. If, in actuality, there is no corresponding DO 3  development object associated with the changed DO 2  development, the rule merely specifies an unnecessary, but rather harmless, invalidation.  
         [0090]    The actions that may be specified by this object navigation grammar can be further illustrated with respect to the more detailed framework object model of FIG. 14, which may represent the types of development objects to be used for modeling presentation layer  410  of runtime application  460 . Each object in FIG. 14 is a development object type, except for the main development object types UITile  1410  (and it&#39;s corresponding runtime object types RR  1411 , Class  1412  and HTML  1413 ), UITileSet  1420  (and it&#39;s corresponding runtime object types RR  1421  and Class  1422 ), UIBusinessComp  1430  (and it&#39;s corresponding runtime object types RR  1431  and Class  1432 ), UIApplication  1440  (and it&#39;s corresponding runtime object type Class  1441 ), and Usages  1480  (and it&#39;s corresponding runtime object type Class  1481 ). The RR runtime objects may refer to binary files. The grammar may specify:  
         [0091]    navigation to associated object or associated collection, specified by “.” 
         [0092]    The cardinality of the relation can be 1 or many. For example:  
         [0093]    a. navigation to associated object with cardinality  1  may be specified as:  
         [0094]    UIObjLibReference.InteractionComp  
         [0095]    b. navigation to associated object with cardinality more than one may be specified as:  
         [0096]    UITileset.UITilesetContainers  
         [0097]    downcasting a pointer of an object to its sub class, specified by enclosing the class to be cast to in “[ ]” 
         [0098]    For example:  
         [0099]    a. InteractionComp [UITile] 
         [0100]    b. InteractionComp [UITileset] 
         [0101]    upcasting a pointer of an object to its super class, specified by enclosing the class to be cast to in “[{circumflex over ( )}]” 
         [0102]    For example:  
         [0103]    a. UIBusinessComp [{circumflex over ( )}InteractionComp] 
         [0104]    repeating any of the above operations or sets of operations zero or more number of times, specified by enclosing them in “( )*” 
         [0105]    For example:  
         [0106]    a. UICustomProperty.(InteractionComp[UIPopupTileset].Usages)*  
         [0107]    the runtime object to be invalidated, specified in “{ }” following “::” 
         [0108]    There could be more than one runtime object to be invalidated. More than one runtime object can be specified in “{ }” separated by comma. For example:  
         [0109]    a. UITile::{class, HTML} 
         [0110]    b. UITileset::{class, RR} 
         [0111]    the change type that will trigger the firing of a particular invalidation rule, specified by prefixing the rule with ‘&lt;change type&gt;=&gt;’ where the&lt;change type&gt;can be one of the following: ‘Create’, ‘Add’, ‘Modify’, ‘Delete’ 
         [0112]    For example:  
                                                   a. modify=&gt;UICustomProperty.(InteractionComp[UIPopupTileset].            Usages)*::{class}                      
 
         [0113]    language dependent rules and runtime objects  
         [0114]    The grammar may handle language dependency at two levels. Firstly, a rule itself may be specified as a language dependent/independent rule and secondly, the runtime object which has language dependency can further define the scope of invalidation with respect to language. The languages on which the rule or the runtime object is dependent may be specified in “&lt; &gt;” separated by commas. For example:  
         [0115]    a. modify=&gt;&lt;EN&gt;Parent[UITile]::{HTML&lt;EN, DE&gt;, class&gt;} 
         [0116]    Here the HTML runtime object needs to be invalidated in EN and DE languages. Class needs to be invalidated but it is language independent. “HTML&lt;LANG*&gt;” would specify all languages.  
         [0117]    predicates to be evaluated to resolve ambiguous object constructions  
         [0118]    In some cases, an invalidation rule should specify information beyond a simple navigation path in order to allow efficient use of the rule. For example, this additional information may be used to evaluate the context of objects that may have ambiguous constructions in the associated object model. For instance, the following two relations may be defined between a tile object and a text object:  
                                                   Object Type (Role)   (Role) Object Type                           Tile (parent)   (caption) Text           Tile (parent)   (status) Text                      
 
         [0119]    Since the tile object type has the same role name for both relations, an invalidation rule for a caption text would be indistinguishable from an invalidation rule for a status text, namely “anychange=&gt;Text.parent . . . ”. Thus, in order to avoid unnecessary invalidations, an additional meta rule may be specified that would allow one to disambiguate an object construction so that a determination can be made as to which rule should be fired. For example:  
                                   a. modify=&gt;&lt;EN&gt;&lt;&lt;LanguageText.Parent[UITile].Caption&gt;&gt;LangText.        Parent[UITile]::{HTML&lt;EN&gt;}                  
 
         [0120]    The part of the rule, such as&lt;&lt;LanguageText.Parent[UITile].Caption&gt;&gt;is known as a meta rule that helps in disambiguation and determining which rule has to be fired. Without this metarule, every rule with a text object type not associated with a caption may have been needlessly fired, possibly causing great inefficiencies.  
         [0121]    several invalidation rules combined together  
         [0122]    For example, modification of UICustomProperty  1450  of InteractionComp  1400  (which could be any of UITile  1410 , UITileset  1420 , UIBusinessComp  1430  and UlApplication  1440 ) may require invalidating the class file of the corresponding interaction component. The rules to specify are:  
                                   modify=&gt;UICustomProperty.InteractionComp[UITile]::{class}”       modify=&gt;UICustomProperty.InteractionComp[UITileset]::{class}”       modify=&gt;UICustomProperty.InteractionComp[UIBusinessComp]::{class}”       modify=&gt;UICustomProperty.InteractionComp[UIApplication]::{class       }”                  
 
         [0123]    The above rules could be clubbed together as:  
                                                   modify=&gt;UICustomProperty.InteractionComp[UITile, UITileset,           UIBusinessComp, UIApplication]-&gt;{class}”                      
 
         [0124]    When UICustomProperty  1450  changes, this rule would be interpreted to invalidate the class file of the corresponding InteractionComponent  1400 , which could be any of UITile  1410 , UITileset  1420 , UIBusinessComp  1430  and UIApplication  1440 .  
         [0125]    Rule Objects  
         [0126]    [0126]FIG. 15 illustrates how navigation grammar based invalidation rules may be generated into the runtime of application repository  520  for runtime execution. Initially, a framework developer defines in metamodeler  435  an invalidation rule for each framework object type in object model  1300  that is relevant with respect to a corresponding runtime object to be generated. This could be implemented in one particular embodiment by adding property pages to the specification of certain UML elements in the Rational Rose modeling software. Repository generator  510  may then extract the object model  1500  information from metamodeler  435  and dump it into an XML file for subsequent processing.  
         [0127]    Grammar Completion  
         [0128]    Before dumping the invalidation rules into an XML file for further processing, repository generator  510  may first create rule parser  1510  so that syntactic correctness of the invalidation rules may be enforced. Repository generator  510  may create rule parser  1510  by first completing a framework-specific grammar file. This can be accomplished by incorporating information such as class names and role names from object model  1500  (e.g., from the Rational Rose mdl file) into a generic grammar file based on the above-described grammar specification.  
         [0129]    In order to illustrate a generic grammar file according to object model  1500 , the following relations are presumed to be defined in object model  1500 :  
                                                   Object Type (Role)   (Role) Object Type                           MDO (parent)   (child1) DO1           MDO (parent)   (child2) DO2           MDO (parent)   (child3) DO4           DO2 (parent)   (child21) DO3           DO4 (parent)   (child31) DO5           DO6 (parent)   (child32) DO6                      
 
         [0130]    Thus, the following represents the contents of a generic grammar file based on object model  15  in accordance with an embodiment of the present invention:  
                                                                             rule_spec!:        change_type        IMPLIES        {lang_spec}        {METARULEBEGIN cls METARULEEND}        invalidation_rule        ;       change_type!:        “modify”        |“add”        |“delete”        |“create”        “AllChanges”        ;       invalidation_rule!:        cls        SCOPEOP        rto_list        ;       lang_spec!:        LANGLEBRACK        (language        |LANG STAR)        RANGLEBRACK        ;       rto_list!:        LCURLY         rto_spec         (COMMA rto_spec)*        RCURLY        ;       rto_spec!:        rto_type {lang_spec}        ;       cls!:        (fw_class_list)        (operation)*        ;       repetition_operator!:        STAR        | PLUS        ;       operation!:        (navigation        |cast)        ;       navigation!:        DOT        (        LPAREN (fw_role_attrib_list) (operation)*       last_recur_nav repetition_operator        |(fw_role_attrib_list)        )        ;       last_recur_nav!:        DOT        (fw_role_attrib_list)        RPAREN        ;       cast!:        (upcast        |downcast        )        ;       upcast!:        LBRACKUP        fw_class_list (COMMA fw_class_list)*        RBRACK        ;       downcast!:        LBRACKDOWN        fw_class_list        (COMMA fw_class_list)*        RBRACK        ;       //==================================================       //the following production rules are to be generated       lang_dep_rto_types!:        (“HTML”        |“Prj”)        lang_spec        ;       lang_indep_rto_types!:        “class”        |“list”        ;       rto_type!:        lang_dep_rto_types        |lang_indep_rto_types        ;       language!:        “EN”        |“DE”        ;       fw_class_list!:        (fw_class)        ;       fw_role_attrib_list!:        (fw_role_attrib)        ;       fw_class!:        “MDO”        |“DO1”        |“DO2”        |“DO3”        |“DO4”        |“DO5”        |“DO6”        ;       fw_role_attrib!:        “parent”        |“child1”        |“child2”        |“child3”        |“child21”        |“child31”        |“child32”        ;       }        #token SEMI  “;”             #token IMPLIES   “=&gt;”        #token LPAREN   “(”        #token RPAREN   “)”             #token LBRACKDOWN  “[”        #token LBRACKUP  “[{circumflex over ( )}”             #token RBRACK   “]”        #token LCURLY   “{”        #token RCURLY   “}”        #token COLON   “:”        #token COMMA   “,”        #token DOT   “.”        #token STAR   “*”        #token SCOPEOP   “::”        #token PLUS   “+”             #token SPACE  “[ tn]+”        &lt;&lt;skip( );&gt;&gt;        #token IDENT “[a-zA-Z_][a-zA-Z0-9_/t*]*”        #token “[ t]+”   &lt;&lt;skip( );&gt;&gt;             #token “n”   &lt;&lt;skip( ); newline( );&gt;&gt;        #token LANGLEBRACK    “&lt;”        #token RANGLEBRACK    “&gt;”        #token METARULEBEGIN    “&lt;&lt;”        #token METARULEEND    “&gt;&gt;”        #token LANG    “LANG”                  
 
         [0131]    As seen from the contents of the above grammar file, the generic framework-independent portion of the grammar file resides above the comment line stating “the following production rules are to be generated.” The framework-dependent portion of the grammar file resides below that comment line, which is where repository generator  510  may insert the relevant model information to complete the grammar. Once the grammar is completed, repository generator  510  may then pass the grammar file to a known parser generator (such as ANTLR/PCCTS) to generate rule parser  1510 , which may then be incorporated into repository generator  510 .  
         [0132]    Rule Object Generation  
         [0133]    As described in FIG. 16, repository generator  510  may then retrieve the invalidation rules from object model  1500  (step  1600 ), and parse and validate the rules (step  1610 ). In parsing the rules, rule parser  1510  may check for syntactic correctness of each rule based on the specified object navigation grammar, and check for correctness of class names and role names based on the specified object model  1500 . Repository generator  510  may validate the rules, for example, by using object model  1500  to ensure that casting operations and navigation paths are supported by the model, as well as making sure that the rule ends with a main development object type (instead of a development object type) and that the runtime object type to be invalidated is properly associated with the ending main development object type. After the rules are parsed and validated, repository generator  510  may dump them into an XML file for subsequent processing.  
         [0134]    Rule Generator  1520  may read the invalidation rules from the XML file and, using XSL transformations, generate for each rule a corresponding rule object (rule objects  1530 ) to be compiled into repository runtime  1540  (step  1620 ) of application repository  520 . According to one embodiment of the present invention, each rule object is generated with a “navigate” function that:  
         [0135]    receives as input a development object (or a reference to the development object) of a type that resides anywhere in the rule&#39;s navigation path,  
         [0136]    navigates using object instances, starting from the received object type&#39;s location in the navigation path and proceeding through the subsequent steps of the navigation path, and  
         [0137]    returns any resultant runtime object (or a reference to the runtime object) of a type required by the rule.  
         [0138]    In this manner, the rule object&#39;s “navigate” function may be invoked to determine the runtime objects, if any, that are influenced by a changed development object that lies anywhere in the rule&#39;s navigation path. The rule object&#39;s “navigate” function is overloaded to allow for the input of a development object of any type that is listed in the rule&#39;s navigation path.  
         [0139]    So that a determination can be made of which development object types are listed in a rule object&#39;s associated navigation path, rule generator  1520  generates each rule object with the functionality to provide this information. In addition, each rule object may also be generated with functionality to additionally provide a listing of any influenced runtime object types specified at the end of the rule. This combined functionality could enable an index to be constructed for fast runtime rule determination. For example, assuming rule objects are generated for the RTO 1  and RTO 2  invalidation rules provided earlier (from the discussion of FIG. 13), the following is a collection of the listings that may be provided by each of the rule objects:  
                                                       Rule Object   DO Types   RTO Types                           Rule Object 1   DO1, MDO   RTO1           Rule Object 2   DO2, MDO   RTO1           Rule Object 3   DO3, DO2, MDO   RTO2           Rule Object 4   DO4, MDO   RTO2           Rule Object 5   DO5, DO4, MDO   RTO1           Rule Object 6   DO6, DO4, MDO   RTO2                      
 
         [0140]    Rule Object  1  corresponds to the rule with starting object type DO 1 , Rule Object  2  corresponds to the rule with starting object type DO 2 , etc.  
         [0141]    Based on these lists, repository runtime  1540  can generate the following index:  
                                                   Changed DO Type   Relevant Rule Objects                           MDO   1, 2, 3, 4, 5, 6           DO1   1           DO2   2, 3           DO3   3           DO4   4, 5, 6           DO5   5           DO6   6                      
 
         [0142]    This index is constructed by matching each development object type with each rule object that lists the development object type in its rule&#39;s navigation path. Repository runtime  1540  may use this index during runtime to immediately determine which rule objects&#39; “navigate” function should be invoked when a development object is changed. In an actual development environment with a large number of rules and associated object types, this index can achieve substantial time savings during runtime because it eliminates the need for repository runtime  1540  to check each rule object for its relevance with respect to a development object every time it changes.  
         [0143]    Incremental Generation  
         [0144]    Within a repository based application development environment as illustrated in FIG. 17, an embodiment of the present invention may be implemented to enable application generator  455  to generate (FIG. 20) only those runtime objects that have been invalidated (FIGS. 19, 24) through rule-based navigation. As illustrated below, this embodiment scales to support many client side developers by centrally storing development objects and runtime objects (either baseline version or changelist version) on the server side in object repository  1700 , while allowing each developer client to maintain cached copies of these objects locally.  
         [0145]    Repository runtime  1540  may include several components, such as development objects  1715 , runtime objects  1720 , rule engine  1730 , rule objects  1530 , change management  1725  and invalidation manager  1735 , that may implement particular client side functionality of application repository  520 . Application generator  455  may similarly include several components, such as local runtime object state  1740  and external validator  1705 , that may implement particular functionality in the generation of runtime objects. Repository server  1750  may include several components, such as invalidation server  1755  and lock server  1760 , that may implement particular server side functionality of application repository  520 .  
         [0146]    According to this embodiment, application generator  455  initially generates all new development objects into corresponding runtime objects, which are persisted to both local file system  1745  and object repository  1700 . These runtime objects may be represented by the RTO  1800  data structure as shown in FIG. 18, which may include MDO  1810 , RTO type  1820 , CL ID  1830 , generation timestamp  1840 , last source change time  1850  and content  1860 . MDO  1810  may represent the main development object (or pointer thereto) from which the runtime object was generated. RTO type  1820  may represent the runtime object&#39;s particular runtime object type. CL ID  1830  may represent an identifier denoting whether the runtime object was generated from a main development object in the baseline or in one of many developer changelists. Generation timestamp  1840  may represent the time that the runtime object was persisted to object repository  1700  after being generated by application generator  455 . Last source change time  1850  may represent the most recent time that the main development object from which the runtime object was generated had been changed. And content  1860  may represent the actual content (or pointer thereto) of the runtime object (e.g., class file, binary file, etc.).  
         [0147]    Invalidation of runtime objects may occur when, as illustrated in FIG. 19, an application developer uses modeler  445  to make changes to development objects that are in the developer&#39;s changelist (step  1900 ). When the developer attempts to persist the changed development objects to local file system  1745  (step  1910 ), invalidation manager  1735  initiates an invalidation process (step  1920 ) that first determines all runtime objects that may be influenced by the changed development objects (step  1930 ). This determination may be quickly made through invocation of the “navigate” function of relevant rule objects that are selected from an index, as described above, of changed development object types and relevant rule objects. Once invalidation server  1755  obtains locks from lock server  1760  for accessing the influenced runtime objects in object repository  1700  (step  1940 ), invalidation manager  1735  invalidates the influenced runtime objects by marking their state as invalid in object repository  1700  (step  1950 ). Their state may be marked as invalid by updating the last source change time  1850  field of their runtime object data structures. (Instead of the last source change time  1850  field, RTO  1800  may utilize a boolean field that indicates whether the runtime object state is valid (e.g., TRUE) or invalid (e.g., FALSE).) Once this is completed, the changed development object is persisted to local file system  1745  (step  1960 ). A similar invalidation process may occur when a developer releases the development objects to the baseline, except that the development objects are stored in object repository  1700 .  
         [0148]    To improve generator efficiency, only invalidated runtime objects are regenerated, as illustrated in FIG. 20. When an application developer wishes to test changed development objects, for example, the developer may explicitly request, through the user interface of modeler  445 , the generation of any corresponding runtime objects. In order to comply with this request, modeler  445  first identifies the development objects that have been changed (step  2000 ) by looking to the current changelist. Modeler  445  then requests the needed runtime objects from application generator  455  (step  2010 ) by providing application generator  455  with a list of the current changelist development objects. Application generator  455  determines from this changelist which runtime objects are needed based on the framework object model information and object navigation. Application generator  455  also retrieves from modeler  445  the current generator state (step  2005 ), which specifies user-selected settings that define how application generator  455  is to generate any runtime objects. FIG. 21 illustrates a generator settings window that a developer may use to define the generator settings.  
         [0149]    Next, for each requested runtime object, application generator  455  retrieves the local state of the runtime object (generation timestamp  1840  of local RTO  1800 ) from the runtime object in local file system  1745  ( 2015 ), and retrieves the server state of the runtime object (generation timestamp  1840  and last source change time  1850  of the server RTO  1800 ) from the runtime object in object repository  1700  (step  2020 ). If the server state is valid (i.e., the last source change time is not more recent than the generation timestamp), and the server generation timestamp is not more recent than the local generation timestamp, then generation is not necessary (step  2025 ) because the local runtime object is valid and current. If the server state is valid but the server generation timestamp is more recent than the local generation timestamp, generation is still not necessary (step  2025 ) but the local runtime object is not current. In this case, application generator  455  retrieves the more recent runtime object from object repository  1700  and updates the local generation timestamp with the server generation timestamp  1840  (step  2030 ). If the server state is invalid (i.e., the last source change time is more recent than the generation timestamp), application generator  455  regenerates the runtime object (step  2025 ), updates the local generation timestamp (step  2030 ), and, upon obtaining a lock for the runtime object in object repository  1700  (step  2040 ), updates the server generation timestamp and the server last source change time (step  2035 ) and persists the regenerated runtime object in object repository  1700  (step  2045 ). The requested runtime object is then stored in local file system  1745  for use by the application developer in modeler  445 , fulfilling the request (step  2050 ).  
         [0150]    Validation Based On Generator State  
         [0151]    The generator state mentioned in step  2005  specifies user-selected settings that define how application generator  455  is to generate any runtime objects. As shown in FIG. 21, two possible settings are listed under the heading “Other Options” and include “Include additional Debug Code” and “Extended Logging”. When the “Include additional Debug Code” option is checked, for example, application generator  455  generates a logging call at the beginning and end of each application method, such as “gServices.Log ‘Entering method’ &amp; MethodName” and “gServices.Log ‘Exiting method’ &amp; MethodName”. When the “Extended Logging” option is checked, application generator  455  report all generation messages, such as warnings and informational messages, instead of only the errors.  
         [0152]    When application generator  455  checks the validity of a runtime object in step  2020  to determine whether it requires regeneration, application generator  455  looks to the runtime object&#39;s last source change time field in order to determine if the runtime object requires regeneration (i.e., is invalid) due to a change in a development object upon which the runtime object depends. According to another embodiment of the present invention, even if the runtime object is valid, application generator  455  (via external validator  1705 ) may also check whether the runtime object was last generated according to the current generator state. If not, application generator  455  may regenerate it according to the current generator state.  
         [0153]    This generator state validation mechanism may be implemented by representing runtime objects by the RTO  2200  data structure as shown in FIG. 22. This data structure is identical to the RTO  1800  data structure discussed above, except that RTO  2200  may additionally include the generator state that was employed during the runtime object&#39;s last generation. For example, content  2260  may represent the content (or pointer thereto) of RTO  2200  that was generated with the “Include additional Debug Code” generation setting enabled (i.e., checked); generator settings  2270  may represent the “Include additional Debug Code” generation setting. Generator settings  2270  may represent the generator state in any form, including a textual description of the generator settings and/or a hash code corresponding to the textual description of the generator settings. Using such a hash code enables external validator  1705  to quickly compare the current generator state with a generator settings  2270  field in steps  2015  and  2020  during runtime.  
         [0154]    Locking  
         [0155]    According to the embodiments illustrated in FIGS. 19 and 20, in order to invalidate (step  1950 ) and validate (step  2045 ) runtime objects, invalidation server  1755  first obtains locks from lock server  1760  (steps  1940  and  2040 , respectively) in order to proceed with the corresponding invalidation/validation. When invalidation and validation requests interfere with each other, as depicted by the request lifetime bars in FIG. 23, the later request fails to obtain a lock from lock server  1760 , causing the request to block (i.e., wait) until the earlier request has completed. For example, validation  2300  is blocked by invalidation  2310  because invalidation  2310  secured the appropriate lock first. Similarly, invalidation  2330 , invalidation  2350  and validation  2360  all have to block based on the embodiments according to FIGS. 19 and 20.  
         [0156]    [0156]FIG. 24 illustrates an embodiment of the present invention that prevents such blocking by queuing invalidation requests for later processing when the invalidation requests intersect validation requests. To illustrate, validation steps  2400 ,  2410 ,  2420  and  2430  of FIG. 24 mirror validation steps  1900 ,  1910 ,  1920  and  1930  of FIG. 19. However, in step  1940  invalidation server  1755  blocks until it obtains locks from lock server  1760  (step  1940 ) to update the runtime object state. In step  2440 , on the other hand, when invalidation server  1755  fails to obtain locks from lock server  1760  due to an interfering request, it queues the invalidation request (step  2440 ) and informs invalidation manager  1735  that the request has been queued. The changed development object then proceeds to be persisted to local file system  1745  (step  2460 ) without the server runtime object state updated. Once the interfering request is complete, invalidation server  1755  obtains a lock for the queued invalidation request and proceeds to update the runtime object state (step  2450 ).  
         [0157]    The queueing of server invalidation requests preserves the integrity of the server runtime object state, since the invalidation requests are not discarded and eventually invalidate all influenced runtime objects on the server. Server validation requests, on the other hand, may be discarded to prevent blocking, since the server runtime object would still correctly reflect that the runtime object is outdated (causing another generation at the next validation request). In each of these situations, the server runtime object state correctly indicates the server runtime object state.  
         [0158]    Several embodiments of the invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.