Generic layer for virtual object resolution

Systems and techniques to derive virtual objects at run-time from persistencely stored objects. In general, in one implementation, the technique includes receiving a request for a target object from a requesting application. It is determined whether a delta link is associated with the target object. The delta link includes a location of the target object and information describing a desired difference between the target object and a derived object to be returned to the requesting application. The target object is located and a derived object is generated from the target object and the information in the delta link. The derived object is then returned to the requesting application. The target object, and derived object, may include a number of elements. The elements may be name-value pairs, or “properties”, or a number of child objects in an object hierarchy.

COPYRIGHT NOTICE

A portion of this disclosure contains material which is subject to copyright protection. Specifically, portions of source code, scripting language and program model and design information appear in the specification. The copyright owner has no objection to the facsimile reproduction of the specification as filed. Otherwise all copyright rights are reserved.

BACKGROUND

The following description relates to software layers in computer systems, for example, a generic layer for virtual object resolution.

Computer systems may include different software layers. Objects may be stored in a persistence layer and utilized in a presentation layer, which represents the run-time environment of the computer system. Objects may be passed between the software layers, e.g., from the persistence layer to the presentation layer for utilization by a requesting software application.

The term “object” may refer to discrete objects, which may hold data in the form of name-value pairs, or “properties”. For example, a web page may be defined by an object including a number of name-value pairs which correspond to, for example, background color, font, layout, and page content.

The term “object” may also refer to object hierarchies, which may include a top-most “parent” object with many depending, or “child”, objects below it on the hierarchy. An object hierarchy may be used to organize data and enable a user to navigate efficiently through data stored in the hierarchy.

An object may be pre-defined and stored in a computer system, e.g., in a database or system memory. The object may be accessed by different applications in different contexts. The context may depend on the device or browser in which the application is running or be specific to the user of the application. It may be desirable to present different versions of the object in different contexts. Multiple versions of the object may be stored in the database, however, this may create inefficiencies relating to addressing the object and storage capacity.

SUMMARY

The present application teaches generating virtual objects for presentation to a requesting application from objects stored in a persistence layer in a computer system. The present inventors recognized that it may be desirable to return different versions of a stored object based on the context of the application requesting the object. Accordingly, the inventors recognized the potential advantages of providing a generic layer that can generate a virtual object from a delta link referencing the requested object.

In one aspect, a computer system includes several software layers. Objects may be stored in a persistence layer. Objects may be presented to requesting applications in a presentation layer at run-time. A generic layer includes delta links pointing to corresponding target objects in the persistence layer. A delta link includes a location of the target object and information describing a desired difference between the target object and a derived object to be presented to the requesting application at run-time. The generic layer may include a module that intercepts a request from the application for the target object, locates the target object in the persistence layer, and generates the derived object from the target object and the information in the delta link. The generic layer then returns the derived object to the requesting application.

The target object may include a number of name-value pairs. The module may replace values in the target object with values in the delta link when generating the derived object. Alternatively, the target object may be an object hierarchy including a parent object and a number of child objects. The module may omit or add objects to the object hierarchy when building the derived object.

Details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages may be apparent from the description and drawings, and from the claims.

DETAILED DESCRIPTION

The systems and techniques described here relate to software layers in computer systems, and more particularly, a generic layer for virtual object resolution.

FIG. 1illustrates functional layers of a software product in a computer system. Objects may be stored in a persistence layer105, which may include, e.g., a database110. A generic layer115may generate objects derived from the stored objects at run-time. The derived objects may be presented to a requesting application125in a presentation layer130. The presentation layer130may represent a run-time environment of the computer system, whereas the persistence layer105may represent the design-time environment developed at or prior to installation of the software product in the computer system.

Objects stored in the persistence layer105may include a number of name-value pairs, or “properties”. The persistence layer may also store hierarchies of objects, e.g., a folder hierarchy. An object in the hierarchy may depend from another object above it in the hierarchy. The depending object may be referred to as a “child” object, and the object from which it depends a “parent” object. A parent object may be a child of another object. An object hierarchy may itself be considered an object, which is identified by the top-most parent object.

Generally, an object contains one or more elements: In the case of discrete objects, the elements may be properties, and in the case of object hierarchies, the elements may be child objects depending from the top-most parent object.

It may be desirable to present the application125with a modified version of an object in the persistence layer based on the user of the application's context. Different version of the underlying object140may be appropriate in different contexts. The context may depend on, for example, the particular device or browser in which the application is running, the user's role or group association, or other information, such as the country or language in which the application is operating.

Since an object in the persistence layer105may be an underlying object for many different user contexts, it may be desirable to generate a derived object for presentation in the presentation layer130without altering the underlying object in the persistence layer105. A object lookup module135may generate a derived object120appropriate for a user context from a target object140at run-time. The newly generated derived object120may then be presented to the application.

The object lookup module130may use delta links to generate derived objects at runtime. A delta link may include an identifier for the target object140. The identifier may be a link or pointer that points to the target object's location in the persistence layer105. The delta link may include definitions that may be used to change or modify the target object. The modification may not affect the target object, but rather be carried out on an internal object that replaces the delta link at run time, i.e., the derived object. The delta link may store only the “delta,” i.e., the differences, between the target object and the derived object.

FIG. 2is a flowchart depicting a delta link resolution operation200that may be performed by the object lookup module135. The application125may request an object in the persistence layer105, e.g., by sending a name or address of the object (block205). The object lookup module135may intercept the request (block210) and determine whether the requested object is associated with a delta link (block215). If not, the object lookup module135may return the object (block220). If the object is associated with a delta link, the object lookup module135may locate the target object (block225). The object lookup module135may then read the internal data in the delta link (block230) and generate a derived object based on the delta link information and the elements in the target object (block235). The object lookup module135may then return the derived object to the application (block240).

In an alternative embodiment, all delta links may be resolved at run-time. The resultant delta links may then be stored temporarily in the generic or persistence layer for access by the object lookup module135.

When resolving a delta link pointing to a discrete object, the object lookup module135may “merge” the properties in the delta link and the properties in the target object140.FIGS. 3 and 4illustrate a target object300and a delta link400, respectively. The target object300has four properties302-305, i.e., the name value pairs A:1, B:1, C:3, and D:1, respectively. Each property may be bound to a set of attributes, which control the algorithm for merging the properties of the target object and the delta link to generate the derived object. In this example, the properties have the associated attributes “inheritance” and “scope”. The inheritance attribute may indicate which properties can and cannot be modified by a delta link, e.g., the “non-final” and “final” values, respectively. The scope attribute may identify which properties can be personalized by a user and which apply to all user, e.g., the “user specific” and “cross-user” values, respectively. The delta link400may include a link405to the target object and modified properties410and415, i.e., the name value pairs A:2 and B:2, respectively.

The object lookup module may merge the properties in the delta-link400with the properties in the target object300to generate a derived object500, shown inFIG. 5. Like the target object300, the derived object has four properties502-505, i.e., A:1, B:2, C:3, and D:1, respectively. The value for A is in the derived object is unchanged from the target object because A has a “final” inheritance value. The value for B in the derived object is that defined in the delta link since B has a “non-final” inheritance value. The values for C and D are unchanged since the delta link did not include these properties.

Delta links may be used with a variety of different discrete objects. For example, the target object described above may define a web page for a company's portal. The properties in the object may define, e.g., the layout of the page (background color, fonts, etc.), hyperlinks, and content, such as a telephone number for a reception desk at the main office. The delta link may be defined by a branch office of the company to generate a similar web page, but modified to reflect the specific context of the subsidiary, e.g., a the telephone number for a reception desk at the branch office.

When resolving a delta link pointing to a object hierarchy, the object lookup module135may build a virtual tree from the target object hierarchy and the information in the delta link. A delta link for an object hierarchy may have the structure shown inFIG. 6. The target attribute value605in the <DELTA_LINK . . . > tag defines the target object hierarchy. The object_id is a unique identifier for the derived object hierarchy.

The delta link may include a list of entries that define subtractive (MINUS_ENTRIES610) and additive (PLUS_ENTRIES615) alterations to the target object hierarchy. For the <MINUS_ENTRY>-tag and <PLUS_ENTRY>-tag, the target attribute has the value (relative_object_id), which is a relative URL using object_id as its root.

The definition of an entry to be removed from the hierarchy is sufficient for the <MINUS-ENTRY>-tag. The <PLUS-ENTRY>-tag may require positional information identifying where the new entry should be included in the derived structure. The position attribute625defines where the additional entries should be located. Possible values include:BEFORE, indicating that the new entry should be placed directly before the target entry;AFTER, indicating that the new entry should be placed directly behind the target entry;FIRST_CHILD, indicating that the additional entry is to be included in this folder as the first (top most) item; andLAST_CHILD, indicating that the additional entry is to be included in this folder as the last (bottom) element.

The delta link technique may be used to adapt an object that has been pre-defined in a generic system to the needs of companies in a given industry. For example, a user may be assigned a role in a company, e.g., “manager”, “engineer”, or “human resources administrator”. An object hierarchy may be created for the role.FIG. 7shows the structure of an exemplary role object. The role object may be a hierarchy of objects, e.g., folders705, worksets710, pages,715and services720, which may be useful to users assigned that role. The object hierarchy may be structured to provide easy, intuitive navigation through the role.

In an example, a role “employee”800(shown inFIG. 8) is tailored to the requirements of organizations in the public sector by deriving a role named “employee public sector” from the “employee” role. Referring to 2, when the application requests the employee role (block205), the object lookup module135may intercept the request (block210) and determine that the employee role is associated with a delta link1000(block215). The object lookup module135may then locate the target object in the persistence layer105(block225). The object lookup module135may read the internal data in the delta link (block230) and use this information to build a virtual tree corresponding to the derived object “employee public sector” (block235).

FIG. 9illustrates the structure of the delta link900for the “employee public sector” role. The minus entries905and910identify the targets “root/b” and “root/c/d”. Accordingly, entry “b”915is removed from the “root” folder920and entry “d”925is removed from the “c” folder930when building the virtual tree for the derived object. The plus entries935and940identify a new entry “g”945and a new folder “h”950in the “c” folder. The new folder “h” includes the new entries “i”955and “j”960. The definition of the “employee public sector” role1000is resolved as shown inFIG. 10. The derived role “employee public sector” differs from the target role, “employee”800, in that entry “b” in the top level content object and entry “d” in folder “c” are removed from the “employee” object hierarchy. Also, a single entry “g” and a folder “h” with two new entries, “i” and “j”, are added to folder “c” of the “employee” role.

After the delta link is resolved, the object lookup module135may return the derived object, i.e., the “employee public sector” role1000, to the application125(block240).

Although only a few embodiments have been described in detail above, other modifications are possible. The logic flows depicted in the accompanying figures do not require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be preferable.

Other embodiments may be within the scope of the following claims.