Logical data model abstraction in a physically distributed environment

A component object binds business driven services to a graphical user interface (GUI). The object includes a data model, view model and controller. The view model graphically presents, and the controller manipulates data used by the object. The controller includes an event handler that respond to events generated within the GUI and binds data used by the object to a data source which can be another component object or a remotely located source. The event handler can call a local script to calculate the value of a data element within the object. The component object can be instantiated on a client, and can be configured to communicate with a corresponding component object on a server. The client and server component objects can exchange only that data that needs to be exchanged to maintain the current state of a user interface in the client computer.

TECHNICAL FIELD

This description relates to client/server based applications, and client based data models for accessing and interfacing with data derived from server based applications.

BACKGROUND

Today, business is often conducted via portable and hand-held computers. Devices such as smart phones, personal digital assistants, tablet based computers and netbooks, to name just a few, have a small physical footprint yet a rich graphical user interface. As such, they are well suited for data presentation and remote business use. While the computing power of such devices is considerable, it nonetheless pales in comparison to the computing power of a server or server farm. The same can be said of desktop and laptop computers. While such computers provide rich graphical user interfaces and posses considerable computing power in their own right, absolute computing power pales in comparison to the computing power of a server or server farm. As a result, many computationally intensive applications are most effectively run on servers or server farms. Still, it is often convenient to remotely access the data that is output by such computationally intensive applications on small footprint, hand-held devices or on simple desktop or laptop computers. For example, a salesperson can benefit from having instant access to all of the sales records of his or her customers, including detailed records of orders placed, shipments made, invoices sent, and payments received over a period of several years. Depending on the number and size of the customers, such records can be voluminous, and maintaining and analyzing them can be a computationally intensive task that is best left to an enterprise server or server farm. Nonetheless, the salesperson may benefit from having instant access to and the ability to mine the sales information to address issues that may arise during a sales call or while working on his or her desktop preparing to make a sales call. Moreover, the enterprise can benefit by allowing the salesperson to have write access to the sales records from any remote computer, thereby allowing the sales person to enter new or useful sales information such as the name and contact information of a customer's new purchasing agent.

Achieving both of these goals, i.e., running data intensive applications on server farms where they are most efficiently run while providing access to the output of these applications on remote devices like laptops, desktops or smart phones where they may most urgently be needed, can be accomplished using a client-server computing paradigm. In this paradigm, a client application running on a remote device can interface with and control a server application running on an enterprise server or server farm. The client based application can send commands and data to the server, while the server can execute the commands and return requested or updated data to the client. Often, the structure of the data that is manipulated and handled by the client application is particularized to the data model that is used in the server application. As a result, different clients or client components are needed to access and manipulate data generated in different server applications. This not only increases the burden placed on the client side devices, which need different clients or client components to interface with different server applications, but also increases the burden on the server, which needs to maintain different interfaces for the different clients or client components.

SUMMARY

This document describes methods and apparatus to declaratively bind business driven services to a user interface and to manipulate the data to fit the UI experience.

In one aspect, a component object that declaratively binds business driver services to a graphical user interface is disclosed. The component object includes a data structure that is stored in a memory element. The data structure includes a data model for representing data used by the component object, a view model for graphically presenting the data used by the component object, and a controller for manipulating the data used by the component object.

Features of the invention include one or more of the following. The controller can include an event handler to respond to events generated within the graphical user interface. The event handler can bind data used by the component object to a data source. The data source can be remotely located on a server computer or can be located in a second component object located on the same computer. The component object's data model can include a flag that indicates when the data binding between the component and the data source is valid. The component object's event handler can respond to an event within the graphical user interface by calling a local script to calculate the value of a data element within the component object. The component object's data model can include a flag that indicates when the value of a component object data element has changed. The component object can be instantiated on a client computer, and can be configured to communicate with a corresponding component object that is instantiated on a server computer. The client instantiated component object and the server instantiated component object can exchange data. The data exchanged between the client instantiated component object and the server instantiated component object can be limited to data that needs to be exchanged to maintain the current state of a user interface in the client computer.

Other features of the invention include one or more of the following. A bound property framework allows the client runtime to receive event notifications of changes that are made to data fields that are not in the current scope, focus, or lead selection of the user interface. As a general rule, component objects are only populated in the client runtime if they are within the current scope or focus of the user interface. As a result, changes made to the values of data fields that are out of the current scope, focus or lead selection of the user interface are generally not visible to the client runtime. The bound property framework allows a proxy object to be created within the client runtime, having a logical path to a data field within the data model, which is alerted to changes in the data field regardless of whether the data field is within the current focus, scope or lead selection of the user interface or client runtime.

DETAILED DESCRIPTION

FIG. 1is a block diagram of a system10for executing an application using a client-server architecture. As shown inFIG. 1, system10includes a client computer100and a server computer150. The client computer100runs a client runtime110that includes one or more controls120. The server computer150runs a server runtime160and a backend application170. The client runtime110generates and renders a graphical user interface (GUI) that allows a user of client computer100to graphically interact with and control the backend application170on server150. The server runtime160communicates with both the client runtime110on client computer100and the backend application170on server150. The server runtime160reads, writes, interprets, and translates data from backend application170into one or more declared UI component objects (see,FIG. 2) using a data model that is common to both the client runtime110and the server runtime160. Preferably, the client runtime110is implemented as a browser plug-in, and executed as part of a browser running on client computer100. Alternatively, a standalone client runtime (not shown) can be separately compiled, installed, and run independently of any browser running on client computer100. Preferably, client runtime110and server runtime160communicate via hyper text transport protocol (HTTP), and exchange data using Java Script Object Notation (JSON). In other embodiments, client runtime110and server runtime160can communicate via secure HTTP (HTTP/s), and can exchange data using XML. Further details of client runtime110and server runtime160are provided below.

FIG. 2is a schematic illustration of a declared UI component object. UI component object201includes a data model202, a view203, and a controller204. The data model202defines a more universal data structure that is abstracted from the particular data and logic of the backend application170. The view203describes the representation of the component object201and data from the data model202in a graphical user interface on the client computer100. Through the UI component's view, event-handlers can be triggered when a user interacts with the component object. The controller204provides various means for handling and manipulating the data that is defined in the data model202of the component object201. In particular, the controller204includes one or more event handlers205and one or more navigation paths206. The event handlers205interpret events that occur within the client runtime110or server runtime160, and bind data fields in the component object201to data sources (e.g., backend application170) per the data model202. The event handlers205can bind data fields to data sources through actions207(e.g., calling a function in application170), scripts208, or queries210(e.g., querying the data source). Finally, the navigation paths206describe the mapping of operations and the flow of data between the component object201and other component objects in the client runtime110, particularly when data in one component object depends on data in another component object. For example, if data in a component object250(not shown) depends on data in component object201, controller204can include a navigation path206that connects component objects201and250. Controller204can use the navigation path206to notify component object250when the data in component object201changes. Component object250can be embedded in component object201, or component object250can be external to component object201.

Each UI component object201is instantiated on both the client computer100and the server computer150. Data in the client and server sides of the component object201are synchronized on an as needed basis. Thus, the client runtime110and server runtime160only exchange data that needs to be exchanged to maintain the current state of the UI and of the component objects201in both the client runtime110and the server runtime160. Data fields in the client side of a component object201are bound to corresponding data fields on the server side of the component object, while data fields in the server side of the component object201are bound to data sources on the server150such as the backend application170.

To improve system performance and preserve bandwidth on the communication channel between the client computer100and the server150, only data that is currently needed or viewable is loaded from the backend application170. For example, when data is retrieved from application170to populate a list object201on the client computer100, the controller204for the list object201sends the current lead selection and other information from the current view203of the list object201to the server runtime160. The server side list object201uses this information to query the application170for only those items in the list object201that are currently viewable in the view203of the client side list object201. Similarly, if the client side list object201is a hierarchical list, the client list object201does not receive data needed to populate a child list object unless the child list object is the current lead selection of the client side list object201. Thus, the child list object appears in a collapsed state when it is not the current lead selection in the client side list object201, and appears in an expanded state when it is the current lead selection in the client side list object201.

Changes made to data fields that are not in the current scope, focus, or lead selection of the user interface can nonetheless be made available to the client runtime110through a bound property framework. This framework allows the client runtime110to receive event notifications of changes that are made to out-of-scope or out-of-focus data fields by creating proxy objects having logical paths to the data fields. The client runtime110can be alerted to changes in the data fields monitored by the proxy objects regardless of whether the data fields are within the current focus, scope or lead selection of the client runtime110. For example, a data model can consist of a sales order containing a list of items being sold, which list can contain one or more sub-lists containing details about each of the items on the sales list. If a user wanted to monitor for changes to the detailed sub-list (e.g., so the only items on the list are items that are made of stainless steel), the user could create a proxy object within the client runtime with a logical path such as “SalesOrder/Items/Details/Composition” that would alert the user to changes made to the composition of items on the list, regardless of whether the items were currently within the focus of the user interface.

FIG. 3is a block diagram of a client computer100, including a client runtime110that is capable of generating a UI for executing an application170running on a server150in a client-server architecture. As shown inFIG. 3, the client runtime110includes a master controller300, a shell340, one or more UI controls370, a UI data container380, and a communications interface capable of establishing communication with a server runtime160on the server150. In one implementation, the communications interface includes a JSON connector390and a browser stack395. The master controller300includes a component manager301, one or more component controllers302or custom component controllers303, and a server synchronization manager306. The master controller300may also include a scripting engine304and a personalization engine305. The component manager301instantiates component objects201(see,FIG. 2) that make up the UI for the client runtime110, and triggers the initialization of component objects201with data that is obtained from a data source such as backend application170running on server150. The component objects201can be constructed from standardized UI controls370, which can be obtained from a standard object repository450(see,FIG. 4) that is located on server150. All component objects201in the client runtime110can be composed from the standard UI controls370or from other component objects201. The top-level component object in the client runtime110can render a shell340, which can consist of various windows341, component object views342(i.e., views203of component objects201), panes343and side cars344for personalization and help.

When the component manager301instantiates a component object, it also instantiates a controller302or303for the component object (i.e., a controller204for each component object201as shown inFIG. 2). The component manager301instantiates a standard component controller302for each UI control370, and a custom component controller303for each composite component object (e.g., each component object that consists of two or more UI controls370or other UI component objects). As explained above in reference toFIG. 2, each component controller302or303binds the data fields of its component object to a data source (e.g., application170) through an event handler205according to a data model202. If data is bound to a component object201through a script, controllers302or303can trigger script engine304to execute that script. Each controller302or303can also trigger a refresh request and roundtrip data exchange with the server runtime160upon detecting a change to the data that is bound to its component object. These refresh requests and data exchanges are managed by a synchronization manager306. The synchronization manager306identifies any data changes in a component object in the client runtime110, and sends a refresh request to the server runtime160to reflect that data change in the corresponding server side component object.

FIG. 4is a block diagram of a server150, including a server runtime160that interfaces a client runtime110running on a client computer100with a data source such as an application170running on the server150. The server runtime160includes a backend controller400, an object repository interface405, and a communications interface that is capable of connecting the server runtime160with a client runtime110on the computer100. In one implementation, the communications interface includes an Internet Communications Framework495and a JSON connector490. The backend controller400includes a master controller401, one or more component controllers402or custom controllers403, and a connector404to the application170running on the server150. The object repository interface405connects the server runtime160with a standard object repository450. The standard object repository450contains standardized UI component objects and controls, including standard data models that bind the data in the component objects and controls to a data source on server150such as application170.

When a client runtime110is initialized on client computer100, the client runtime110requests one or more UI component objects (which may be controls) from the server runtime160, receives and instantiates the one or more UI component objects on the client computer100, and requests initialization of the one or more component objects through the server runtime160. When the server runtime160receives a request for a UI component object from the client runtime110, it directs the request to the master controller401. The master controller401retrieves the component object and its data model from the standard object repository450, sends the component object and its data model to the client runtime110. The master controller401also creates, within the service runtime160, a component controller402or custom controller403and a data container406for the component object. The data container406stores data for the component object in a data structure defined by the component object's data model.

When the server runtime160receives the request to initialize the component object from the client runtime110, it again directs the request to the master controller401. The master controller401sends the request to the controller402or403of the component object. The controller402or403retrieves the initialization data from a data source on server150such as application170, stores the data in the data container406for the component object, and sends the data to the synchronization manager306within the client runtime110. The synchronization manager306in turn sends the data to the controller302or303of the client side component object, which writes the data to the client side data container380in the client runtime110.

Subsequently, whenever the synchronization manager306on the client runtime110requests a refresh or roundtrip data exchange for a client side component object, the server side controller402or403for that component object receives and processes the request. For example, when data in a client side component object201is changed in the client runtime110(e.g., via user interaction), an event handler205in the controller204of the client side component object201sends the changed data to the synchronization manager306in the client runtime110. The synchronization manager306asynchronously collects and sends the changed data to the master controller401in the service runtime160. The master controller401sends the changed data to the controller402or403for the corresponding component object in the server runtime160. The controller402or403receives the changed data, updates its data container406, and performs any other actions indicated by the controller's event handler. Such actions may include sending the data to the application170, calling a function in the application170, or querying the application170. In addition, controller402or403receives data from the application170, updates the data container406for the component object, and sends the updated data to master controller401in the service runtime160. Master controller401sends a message to the synchronization manager306in the client runtime110that includes the updated data. The synchronization manager306in turn sends the updated data to the controller302or303for the client side component object. The controller302or304then writes the updated data to the client side data container380for the component object to complete the roundtrip data exchange for the refresh request.

FIG. 5is a schematic illustration of a class diagram showing the abstracted data model of a component object in the client runtime. The data model202defines the attributes for a data element501within a UI component object201. For example, the data model202defines the binding510between the data element501and a data source520. The data source520can be a backend application or business object521running on a remote server (e.g. application170), an object or function within such an application522, or another component object523in the client runtime110. The binding510between the data element501and the data source520expresses a particular path to the data source520. The path can be a call to particular function511within the data source520, a query512of the data source520, or a particular data object513or data element within the data source520. Two-way data exchange can occur between the data element501and the data source520through these paths or data bindings510.

As further shown inFIG. 5, each data element501can be part of an overall data structure540in the data model202of the component object201. The client runtime110and server runtime160can access this data model202and data structure540through their respective data containers550. For example, client runtime110can access the data model202of a component object201through its data container380as shown inFIG. 3, while server runtime160can access the data model202through its server side data container406shown inFIG. 4. The overall data structure540of the component object201allows individual data elements501to be organized as data records541, lists542or list rows543.

As also shown inFIG. 5, each data element501includes a data field502that can hold the value of the data element. The value of the data field502can depend on or be bound to additional information or sources of data as indicated in a bound property field531. For example, the value of the data field502can depend on the value of data in another data element as indicated in a dependent property field530. In addition, the value of the data field502can depend on one or more calculations that are indicated in a calculated property field532. The calculated property field532defines the calculations that are needed to compute the value of the data field502from the information available from the bound data sources520and/or from any other data elements on which the value depends (e.g., as indicated in the dependent property field530). When the value of the data field502in a component object201is bound through a calculation532or depends on data from another data element in another component object, one or more event triggers533can alert the client runtime110or service runtime160when the value of the data field502needs to be recomputed. For example, if the value of the data field502is the sum of the values from two or more independent data fields, a trigger533can alert the client runtime110or service runtime160to recompute the value of the data field502when the value of at least one of the independent data fields changes.

The calculated property field can be used to perform trivial calculations on the client computer100rather than on the server computer150to preserve bandwidth between the client and server computers. For example, the value of the data field502can be the age of a customer, and can depend on both the current date and the birthday of the customer. Whenever information regarding the customer's birthday or the current date is changed, the customer's age can be recalculated in the client runtime110by executing a script. The recalculated age and the changed birthday or current date information can then be sent to the corresponding component object in the server runtime160. In this way, only a single data exchange between the client and server component objects is required. By contrast, were the age calculated in the server runtime160, the updated customer birthday or current date would have to be sent from the client runtime110to the server runtime160, the customer age calculated in the server runtime160, and the updated customer age sent back to the client runtime110, thus requiring two data exchanges between the client and server computers.

Finally, the data field502can also included a plurality of indicators551-555that contain information regarding the status of the data in data field502. In particular, a round-trip pending indicator551can be set to indicate when the value stored in data field502in a component object201in the client runtime110has changed, and that change is being propagated to the data field of a corresponding component object201in the server runtime160. A value change indicator552can be set to signal a change in the value stored in data field502to the synchronization manger306in the client runtime110shown inFIG. 3or to the master controller401in the server runtime160shown inFIG. 4. A state changed indicator553can be set to signal when the state of the data value in the data field502has changed (e.g., from valid to invalid or from fresh to stale). A binding invalidated indicator554can be set to indicate when the abstract binding510of the data element501to the data source520is valid. For example, the binding invalidated indicator554can be set to invalid when the data source520(e.g., application170) crashes. This indicator can be checked to insure that only valid data connected to a valid and up-to-date data source is displayed and used in the client side110UI. Finally, a field validated indicator555can be set to indicate when the value in the data field502is valid.

The methods and apparatus described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. They may be implemented as a computer program product, i.e., as a computer program tangibly embodied in a non-transitory machine-readable storage device for execution by, or to control the operation of, a processor, a computer, or multiple computers. Method steps may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The method steps may be performed in the order shown or in alternative orders.

A computer program, such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, plug-in or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communications network. Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer, including digital signal processors. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both.

Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer may also include, or be operatively coupled to receive data from and/or transfer data to one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Machine readable media suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in special purpose logic circuitry.

To provide for interaction with a user, the methods and apparatus may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse, trackball or touch pad, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.