KR20140036229A - Techniques for adapting an interpretive run time application to multiple clients - Google Patents

Abstract

Techniques for adapting the interpretation runtime engine to a plurality of clients are described. The device may comprise a logic device configured to execute a web client. The web client detects a user event for a client user interface, sends a change of a user event attribute associated with the user event to a server application, and sends a graphical user interface (GUI) independent object and an updated user event attribute to the server. Client adapters that receive from the application and operate to update the rendered image in the client user interface using GUI-independent objects and updated user event attributes received from the server application, and other elements. Other embodiments are described and claimed.

Description

TECHNIQUES FOR ADAPTING AN INTERPRETIVE RUN TIME APPLICATION TO MULTIPLE CLIENTS

The client-server architecture is a distributed application architecture that partitions computing tasks or workloads for application programs between two basic entities, the so-called server and the client. A server is a provider of resources or services. A client is a requester of a resource or service. A server is a physical or logical device that shares its resources with a client and runs one or more server programs. A client is typically a physical or logical device that requests content or service functionality from a server without sharing any of its resources. Typically, clients and servers communicate over a computer network on separate hardware. However, in some cases, both client and server can reside on the same system. Thus, the client initiates a communication session with the server waiting for an incoming request.

Client-server architecture in one form is often n-tier architecture, a (multi-tier architecture)-tier architecture (architecture -tier n) multi-reputed. An n -tier architecture is a client-server architecture in which certain aspects of an application program are separated into multiple tiers. For example, applications that use middleware to service data requests between users and databases employ a multi-tier architecture. The n -tier application architecture provides a model for developers to create flexible and reusable applications. By dividing an application into multiple tiers, developers only need to modify or add specific tiers (or layers), thereby eliminating the need to rewrite the entire application.

The n- tier architecture offers many advantages when developing and modifying application programs. However, it is difficult to implement an n -tier architecture for a web-based environment with a large number of clients. Each client may use different web technologies, such as different web browsers, web services, and web applications. In addition, Web technologies work with a variety of devices with different types of underlying hardware and software architectures, such as different input / output (I / O) components, form factors, power requirements, processing power, communication capabilities, and memory resources. It is designed to. Thus, it may be difficult to implement one or more tiers across many of these heterogeneous devices and architectures. In addition, the web version of the application program may be incompatible with the non-web version of the application program, requiring a separate software architecture for each. With respect to these and other disadvantages, there is a need for improvements herein.

summary

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to assist in determining the scope of the claimed subject matter.

Various embodiments generally relate to a client-server architecture suitable for running different types of application programs, such as commercial line-of-business application programs. In particular, some embodiments relate to an n -tier client-server architecture having a plurality of tiers (or tiers) of application programs, such as at least one presentation tier. In one embodiment, for example, a three-tier client-server architecture decouples graphical user interface (GUI) rendering when applying an interpretive runtime engine application to work with several different types of clients. It can include representation tiers implemented using techniques designed to improve.

In one embodiment, for example, the device may include a logic device configured to execute a web client. The web client detects a user event, sends a changed user event attribute associated with the user event to a server application, receives a graphical user interface (GUI) independent object and an updated user event attribute from the server application, and receives a server application. Client adapters and other elements operable to update the rendered image in the client user interface using GUI independent objects and updated user event attributes received from. Other embodiments are described and claimed.

These and other features and advantages will become apparent by reading the following detailed description and reviewing the associated drawings. It is to be understood that both the foregoing general description and the following detailed description are merely illustrative and are not intended to limit the claimed subject matter.

1A illustrates a conventional desktop application architecture.
1B illustrates a conventional two tier application architecture.
1C illustrates a conventional three tier application architecture.
2 shows a block diagram of an improved n -tier client-server architecture with a plurality of clients and client adapters according to one embodiment.
3 shows a block diagram of an improved n- tier client-server architecture with a single client and client adapter according to one embodiment.
4 shows a block diagram of an improved n -tier client-server architecture with a graphical user interface (GUI) independent object and client adapter for a client according to one embodiment.
5 illustrates a first logical flow diagram of an improved n -tier client-server architecture, according to one embodiment.
1A illustrates a logic diagram of a GUI independent object, according to one embodiment.
1B illustrates a logic diagram of a particular GUI independent object according to one embodiment.
7 illustrates a second logic flow diagram of an improved n- tier client-server architecture, according to one embodiment.
8 illustrates one embodiment of a computing architecture suitable for an improved n- tier client-server architecture according to one embodiment.
9 illustrates one embodiment of a communication architecture suitable for an improved n- tier client-server architecture according to one embodiment.

Various embodiments generally relate to a client-server architecture suitable for running different types of commercial line-of-business application programs. In particular, some embodiments relate to an improved n- tier client-server architecture, where n is a variable representing any integer. The improved n- tier architecture may include a plurality of tiers (or layers) of the application program, such as at least one presentation tier. In one embodiment, for example, the improved n- tier architecture includes a three-tier including a presentation tier, an application processing tier, and a data management tier. It can be implemented as an architecture. In general, the representation tier implements handling user interface logic, such as input / output operations. In general, the application processing tier implements processing data according to an application or business logic, such as a set of application rules. In general, the data management tier implements data storage and access, such as data schema definition, data storage, and data query processing.

The improved n- tier client-server architecture can include an expression tier implemented using techniques designed to facilitate GUI rendering and separation and optimization of user events in applications utilizing an interpretive runtime engine. This enables the adoption of interpretation runtime engine applications from a two-tier client-server based architecture into a three-tier environment, while reducing changes in interpretation runtime engine applications.

1A, 1B, and 1C illustrate three conventional architectures for application development as a background to highlight the benefits of various embodiments of an improved n- tier client-server architecture. 1A shows a conventional desktop architecture. 1B shows a conventional two-tier architecture. 1C shows a conventional three-tier (or n -tier) architecture.

1A is an example of a desktop architecture 100 in which all portions (or application layers) of application program 112 are implemented on client computer 110 (eg, desktop computer). The application program 112 may include, for example, various application layers that implement user interface (UI) logic, business logic, and database access logic. The application program 112 may also store and access application data in a database 114 implemented on the client computer 110.

1B is an example of a two-tier architecture 120 in which the current database 114 is located remotely from the client computer 110. In the two-tier architecture 120, the application program 112 and its components, the application layer, still exist on the client computer 110. However, database 114 has been moved from client computer 110 to database server 116. The application program 112 running on the client computer 110 sends a request for data to a database server 116 communicatively coupled to the database 114 via a database application program interface (API). The requested data is then returned to the application program 112 running on the client computer 110.

1C is an example of a three-tier architecture 130. In the three-tier architecture 130, the application program 112 may be separated into distributed application programs 112 and 124, each running on the client computer 110 and the server 122. The application program 112 may implement an application layer having UI logic. The application program 124 may implement an application layer having business and database access logic. The application program 112 running on the client computer 110 transmits data to the server 122 running the application program 124. The application program 124 then executes business logic and sends a request for data to a database server 116 communicatively coupled with the database 114. The result of the requested data and executed business logic is returned to the application program 112 and rendered at the client computer 110. The database server 116 may be located at the same location as the server 122 or may be part of the server 122. That is, the hardware architecture can be configured such that a single server 122 functions as both an application server and a data server. The factor that distinguishes a two-tier architecture from a three-tier (or n -tier) architecture is that some or many of the application layers move out of the client computer 110 and are distributed among one or more other servers 116, 122. It is.

The n- tier architecture, such as the three-tier architecture 130, can provide a number of advantages when developing and modifying application programs over the two-tier architecture 120. For example, a single tier can be modified or added without causing a complete rewrite of the entire application program. However, there is a difficulty in implementing n- tier architecture for a web-based environment with a large number of clients. Each client can use different web techniques, such as different web browsers, web services, and web applications. In addition, Web techniques, along with various devices with different types of underlying hardware and software architectures, different input / output (I / O) components, form factors, power requirements, processing capabilities, communication capabilities, memory resources, etc. It is designed to work. Thus, it may be difficult to uniformly implement a particular application layer, such as the presentation layer across many of these heterogeneous devices and architectures, without extensively customizing the presentation layer to suit the unique configuration of each client. In addition, since the web version of the application program may not be compatible with the non-web version of the application program, a separate software architecture may be required for each.

In various implementations, the improved n- tier architecture enables a two-tier client-server application architecture to migrate to a three-tier application architecture using a thin client to the presentation layer of the application program. Provide a framework to In one embodiment, for example, each client device may implement a thin client in the form of a web client. Generally, a web client refers to a thin client application that is implemented using web techniques, such as a web browser running on a client computer. The web client may also refer to plug-in and helper applications that augment the browser to support custom services from a site or server. The web client referred to herein may refer to the functionality of a web browser.

2 illustrates a client-server system 200. In one embodiment, the client-server system 200 may include an improved n- tier client-server system. The improved n -tier client-server system can separate an application program into multiple tiers, including the presentation tier. The presentation tier may be implemented using a technique designed to facilitate GUI rendering and separation and optimization of user events in an application program using an interpretive runtime engine. This makes it possible to adopt a interpretation runtime engine application from a two-tier client-server based architecture to a hosted three-tier environment while reducing the required changes to the interpretation runtime engine application.

As described above with reference to FIG. 1A, many applications follow a two-tier application architecture in which the application consists of two interrelated components—a database server and a client application. The database server can host system and company data along with extended business logic that allows it to handle some of the heavy computations that would be extremely time consuming to be performed at the client. On the other hand, the client application can perform a function of transmitting a UI, a function of providing data entry validation, and a function of rendering a report.

2, the client-server system 200 may include a server 202 and a plurality of clients 204,206. When implemented on different hardware platforms, server 202 and clients 204, 206 can communicate with each other over network 250. When implemented on the same hardware platform, server 202 and clients 204 and 206 may communicate with each other via appropriate bus techniques and architectures. Although FIG. 2 illustrates only a single server 202 and two clients 204, 206 for the sake of brevity, the client-server system 200 may implement any number of servers and clients as desired in a particular implementation. It can be obvious. Embodiments are not limited in this context.

In one embodiment, server 202 may include an electronic device that implements server application 210. The server application 210 may include any type of server application, such as a commercial line-of-business application. Non-limiting examples of commercial line-of-business applications include accounting programs, enterprise resource planning (ERP) applications, customer relationship management (CRM) applications, and supply chain management (SCM). ) May be an application. Because these commercial line-of-business applications are typically executed by a server or server array in a commercial enterprise network, rather than a client device, such as a desktop computer, sometimes they are "middle-tier". It is called an application. A particular example may be Microsoft® Dynamics GP from Microsoft Corporation, Redmond, Washington. The Microsoft® Dynamics GP is a commercial accounting software application. Another particular example of a commercial line-of-business application may include Microsoft Dynamics® AX of Microsoft Corporation, Redmond, Washington. Microsoft Dynamics AX is a commercial ERP software application. However, embodiments are not limited to these examples.

When the server 202 is executing code for the server application 210, the server 202 forms an interpretive runtime engine 212. The interpretation runtime engine 212 is referred to as the application logic 214, the database logic 216 and the server presentation logic 218 in the client-server system 200 for the server application 210 Loss implements multiple application layers. The server application 210 may be controlled and operated via control directives received in the form of signals or messages from the clients 204 and 206 via the network 250.

In one embodiment, each of the clients 204, 206 may include an electronic device that implements its own web client 230, 240. For example, each of the web clients 230, 240 may include an instance of a web browser running on its respective client 204, 206. The web browser may also include plug-ins, web applications and helper applications designed to augment the web browser to support custom services from the server 202. Web clients 230 and 240 referred to herein may also refer to the functionality of a web browser.

The clients 204 and 206 may include their respective client adapters 232 and 242. Each of the client adapters 232, 242 can be configured to be used by a particular client 204, 206. In this manner, the server application 210 and the interpretation run-time engine 212 need not be modified when accessed by different clients using different techniques.

The client adapters 232 and 242 may include respective client presentation logic 238 and 248. The client presentation logic 238, 248 may be designed to present a user interface element or view on an output device, such as a digital display, for the client 204, 206. Depending on the distributed n -tier architecture implemented for server application 210, the client representation logic 238, 248 may be configured to include application logic 214, database logic 216 of server application 210 running on server 202. And server representation logic 218.

Client adapters 232 and 242 and their respective client representation logic 238 and 248 interoperate with server representation logic 218 such that the server application 210 is accessed through different clients 204 and 206. Can be. Each client 204,206 may implement different versions of the server presentation logic 218 as its respective client presentation logic 238,248 to tailor a particular configuration for the client 204,206 have. This can be done without having to rewrite the server representation logic 218, and more importantly, the business logic 214 and database logic 216 need not be rewritten. In addition, the server presentation logic 218 and the client presentation logic 238 and 248 can interact with each other in a manner that reduces communication traffic and overhead to the network 250, thereby reducing latency associated with communication delays, Speed and performance can be increased while reducing.

The server application 210 can communicate separately or simultaneously with the client adapters 232 and 242 or their respective versions. Scenarios for concurrent operation may include when a user needs assistance and an administrator wants to see a second version of the user's web client view.

In various embodiments, the server presentation logic 218 and the client presentation logic 238, 248 may interact in an efficient manner utilizing a graphical user interface (GUI) independent object 260. The GUI independent object 260 allows a GUI element, e.g., a GUI screen (e.g., Microsoft Windows® Forms), to move freely between the desktop environment and the web environment. The GUI independent object 260 allows the server application 210 to receive script events via a traditional OS form or via a web client form and to execute script events regardless of the type of form submitted It can run as a background service while waiting for user events.

The GUI independent object 260 includes, in addition to a user event attribute that may affect an application logic event, a user event that may affect GUI dependent rendering by the client adapter 232, 242, , And other types of information. The GUI independent object 260 is generated from the analysis runtime engine 212 and sent to the client adapters 232 and 242 which are then rendered in the client user interface via their respective client presentation logic 238 and 248.

3 illustrates a particular implementation of an n -tier client-server system 300. The client-server system 300 may include a server 302 and a client 304. The server 302 may represent the server 202 described with reference to FIG. 2, for example. The client 304 may represent one or both of the clients 204, 206 described with reference to FIG. 2, for example.

In the embodiment shown in the client-server system 300, the server 302 may implement a server application 310. In one embodiment, for example, server application 310 may be coded using the Microsoft Dexterity® programming language, or any other suitable type of programming language. When implemented as a Microsoft Dexterity application, server application 310 may generally be divided into two separate elements. The first element is an interpretation runtime engine 312 that solves the technical aspects of the application environment, e.g., communication with the operating system (OS), and establishing and managing connections to the database 320 via the file manager 316. The second element is an application dictionary that hosts application logic 315, such as application rules, business rules, forms, reports, resources, metadata, and application code that enables response to user commands and input. (application dictionary) 313. Examples of application code may include sanScript code, Microsoft Visual Studio® addin, Microsoft Visual Basic® application (VBA), Microsoft Dexterity Continuum, and the like. This architecture isolates application logic 315 from UI style changes and platform advances, such as upgrades of the platform OS.

SanScript code is used to control how the application behaves. Generally, the acid script code is written as an object in the application dictionary 313, e.g., a small segment, or script attached to a field, menu, screen and form. The script is executed when the user interacts with a specific object in the application. For example, a script applied to a push button would run when the user clicks the button.

As shown, the client 304 can include a web client 330. The web client 330 may, for example, represent one or both of the web clients 230 and 240. The web client 330 may deliver a set of components and services adapted to user interface and user interaction, such as user input and lightweight user interface controls for use by the server application 310. have. However, to achieve a smooth migration to the three-tier architecture, various technical challenges created by the introduction of the web client architecture need to be overcome to enable an efficient web client interface.

The goal of the embodiments described herein is to reduce the necessary changes to existing code and GUI metadata. Various embodiments relate to techniques for decoupling user interface manager 318 and OS rendering engine 322 from interpretation runtime engine 312 to solve some of the aforementioned problems. User interface manager 318 is system software that controls the placement and appearance of various interface elements, such as GUI screens, within a particular GUI system. The OS rendering engine 322 is system software for displaying content. The interpretation runtime engine 312 is an executed version of the server application 310.

The use of forms (or screens) is a key component of any Microsoft Dexterity application. The form is the mechanism that the user will use when interacting with the server application 310. The server application 310 is implemented as a Microsoft Dexterity application screen, typically a Microsoft Dexterity application screen that includes the acid script code associated with the control for the screen. The san script code is executed in response to a user event when given the intended function of the screen and control under the direction of a script interpreter 314. [

In a non-web version of the server application 310, the UI is managed by the user interface manager 318 and is then communicated to the OS rendering engine 322 to provide the actual Microsoft Dexterity screen to the developer It can be displayed on the display screen together with the control elements previously arranged.

However, the user interface manager 318 and the OS rendering engine 322 may be configured to perform the functions of the analysis runtime engine 312 to facilitate the transition of the client-server system 300 to the web client 3-tier architecture. It can be disconnected. This allows web client 332 to implement client versions of user interface manager 336 and rendering engine 338 on client 304. This also allows the interpretation runtime engine 312 running on the server 302 to create a GUI independent object 360 for use by the web client 332. Using the GUI independent object 360, the web client 330 of the client 304 provides a web-based representation of the same screen, without having to change any of the underlying application client logic 315 of the server application 310 In doing so, traditional clients can continue to provide conventional GUI screens (eg, Microsoft Win32® screens).

By disconnecting the user interface manager 318 and the OS rendering engine 322 from the analysis runtime engine 312, the screen can move freely between the non-web (e.g., desktop or Win32) environment and the web environment . Using the disconnected user interface manager 318 and the OS rendering engine 322, the server application 310 can receive script events, regardless of the type of form submitted, via a traditional Win32 form or web client form It can be executed as a background service while waiting for a user event that can be executed.

To facilitate disconnection, the GUI dependent processing layer and the GUI independent processing layer of the server application 310 are first separated from each other. Instead of direct communication between these two layers, rendering and event metadata are exposed using the GUI independent object 360. The GUI independent object 360 may include any user event attributes that may affect GUI dependent rendering by the client adapter 332, in addition to user event attributes that may affect application logic events. have. The GUI independent object 360 is then transferred to the (GUI dependent) client adapter 332 rendered on the client user interface screen on the display for the client 304. Non-limiting examples of some client adapters 332 may include Microsoft Silverlight®, HTML, Win32 GDI, .Net Forms, and the like.

4 illustrates a particular implementation of an n -tier client-server system 400. The client-server system 400 may include a server 402 and a client 404. The server 402 may represent, for example, the servers 202 and 302 described with reference to FIGS. 2 and 3. The client 404 may represent one or both of the clients 204, 206, 304 described with reference to FIGS. 2, 3, for example.

On server 402, there may be a server application 410 that includes an interpretation runtime engine 412 that is responsible for executing one or more application layers or is coupled to other components that execute one or more application layers. The interpretation runtime engine 412 may further include a script interpreter 414, a file manager 416, and a user interface manager 418. The script interpreter 414 can communicate with a file manager 416 and a server user interface manager 418. File manager 416 may also be in communication with database 420.

On the client 404, there is a web client 430 running a client adapter 432. The client adapter 432 uses the user interface manager 436 and the rendering engine 438 to display content in a client user interface, such as the client user interface, in accordance with the client presentation logic 238, 248 shown in FIG. 2. It may include.

4 may represent a three-tier application architecture, where a particular application layer may be distributed between server 402 and client 40. For example, client representation logic 238 and / or 248 may reside on client 404, while application logic 214 and database logic 216, as shown in FIG. 2, 402 may be dispersed. 4 has disconnected the functionality of the user interface manager 436 and the rendering engine 438 from the interpretation runtime engine 412 on the server 402 and sends it to the client adapter 432 on the client 404. [ Located with.

In one embodiment, the interpretation runtime engine 412 may include a script interpreter 414. Generally, the script interpreter 414 may be configured to execute the scripted code in response to a user event, a non-limiting example, a transaction storage or posting of a batch. Examples of scripted code may include pre-script, change script, post-script, and other types of script.

In one embodiment, the interpretation runtime engine 412 may include a file manager 416. In general, the file manager 416 may be configured to perform file management operations on files stored in the database 420. Examples of file management operations may include creating files, opening files, copying files, moving files, deleting files, and the like.

In one embodiment, the interpretation runtime engine 412 may include a user interface manager 436. In general, the user interface manager 436 may be configured to control the placement and appearance of various user interface elements, such as screen elements, within a user interface implementing a particular GUI system.

In operation, the user may interact with the client user interface via the web client 430. The web client 430 may include a web browser having user interface code for rendering web-based content. The web client 430 may be implemented using various web technologies, such as HTML, XHTML, XML, and the like. Non-limiting examples of the web client 430 may be Internet Explorer (R) from Microsoft Corporation of Redmond, Washington, and other types of web browser software.

According to one embodiment, during operation, the user may interact with the client user interface via the web client 430 and input user events that may be received and processed by the client adapter 432. Non-limiting examples of user events may include moving a pointer to a field, hovering over a field, selecting a field, clicking a button with a mouse, populating a text field, and the like . User events can be defined using a set of user event attributes. In one embodiment, instead of a complete set of user event attributes, only changes to user event attributes need to be sent from the web client 430 to the server application 410. These different techniques can conserve communication bandwidth and reduce latency.

The user event attribute may be any user interface element displayed on the user interface layout, e.g., an attribute that can be assigned to a field, screen, or graphic object. A user event attribute describes an attribute of a presentation style or presentation format for a corresponding user interface element. User event attributes may include user interface element identifiers (ID), attributes (e.g., borders, fonts, font sizes, font colors, backgrounds, background colors, styles, , Double space, etc.), attribute values (e.g., false, true, 0, 1, etc.), and other types of information. For example, a GUI screen has an identifier "Window 001" with a Resizeable property set to False, meaning that the GUI screen cannot be resized by the user at runtime. This is just a few examples, and any user interface element and user interface attribute may be implemented as desired, depending on the particular implementation. In this context, embodiments are not limited.

The web client 430 can send the changed set of user event attributes 451 to the server application 410 in a message 450. The user interface manager 418 operating on the server 402 forwards the changed user event attribute 451 to the script interpreter 41 as a message 450 for processing. The server application 410 may ensure that application input and application state are appropriate before executing any application logic for the server application 410. The script interpreter 414 then accesses the database 420 as needed to execute any application rules derived from the changed user event attribute 451 in the message 450 received from the client 404. Communicate with 416. After execution of the appropriate application logic, the interpretation runtime engine 412 may create a GUI independent object 452. The GUI independent object 452 may include an updated user event attribute 454 and other information. The user interface manager 418 implemented by the server 402 may again send the GUI independent object 452 back to the client 404 with any updated user event attributes 454. [ The client adapter 432 then sends the rendered image using the GUI independent object 452 previously through the client user interface manager 436 and the rendering engine 438 to the server application 410, It can be updated with the updated user event attribute 454.

Operation for the above-described embodiments may be further described with reference to one or more logic flows. The logic flows that appear do not need to be executed in the order presented, or in any particular order, unless stated otherwise. In addition, the various activities described in connection with the logic flow can be executed sequentially or in parallel. The logic flow may be implemented using one or more hardware elements and / or software elements or alternative elements of the described embodiments, as desired for a particular set of design and performance constraints. For example, the logic flow may be implemented as logic (eg, computer program instructions) for execution by a logic device (eg, a general purpose or special computer).

5 illustrates one embodiment of a logic flow 500. The logic flow 500 may illustrate operations performed in accordance with one or more embodiments. For example, the logic flow 500 may illustrate the operations performed by the web client 430 and / or server application 410.

Of the logic flow 500, at block 502, the user interacts with a web client running in a client-side user interface. For example, the web client 430 may be in the form of one or more control directives received from an input device that affect one or more user interface elements of the user interface when presented by the rendering engine 438. [ User input can be received. The user input may interact with a user interface element that causes a user event. For example, the user can select one field on the form that is displayed on the GUI screen and modify the value for that field.

In logic flow 500, at block 504, the client adapter running there may interpret control instructions representing a user event in a manner compatible with the server application running on the server. For example, the client adapter 432 executed by the web client 430 may interpret the user event in a manner similar to the server application 410. The user event may include one or more user interaction with the user interface running on the web client 430, e.g., non-limiting such as button clicking, text field populating, and the like.

In logic flow 500, the analysis operation at block 504 examines the newly entered user event attribute to determine whether the user event attribute has changed in the diamond 506 to the extent that the server application needs to know Can be. For example, the client adapter 432 may examine any user input and the corresponding change in the attribute of the affected user interface element to determine whether the user event attribute has changed greater than some threshold. For example, hovering over the field to sharpen the field may be insufficient to trigger any change in user event attributes, while selecting the field will be sufficient to notify the server application 410.

If, during logic flow 500, a notification is required, at block 508, the client adapter may send any pending changed user event attributes to the server application. For example, the client adapter 432 may send a user event attribute 451 to the server application 410 over the network 250 with a message 450. In some embodiments, the client adapter 432 may send a plurality of sets of modified user event attributes 451 for a plurality of user events to the server application 410 executing on the server 402 with the message 450 . This "batch" transmission may be useful in many ways, such as assisting the server application 410 in setting user event timing. For example, the script interpreter 414 can timing execution of various scripts (eg, pre-scripts, change scripts, post-scripts, etc.) to ensure the correct sequence of updates to the server application 410. . Batch transmission can also reduce communication overhead by sending fewer messages 450 over the network 250. Other advantages also exist, and embodiments are not limited in this context.

Of the logic flow 500, before a business logic event can be executed at block 512, a runtime engine running on the server at block 510 can ensure proper input / state to the server application. For example, the interpretation runtime engine 412 running on the server 402 can ensure appropriate application input and application state for the server application 410 before executing any application or business logic.

Of the logic flow 500, at block 514, the updated user event attribute resulting from the execution of the business logic may be sent back to the client adapter along with the GUI independent object. For example, an updated user event attribute 454 resulting from the execution of an application or business logic is sent from the server application 410 to the web client 430 along with the GUI independent object 452 to the client adapter 432 Can be sent back.

During logic flow 500, the client adapter may then update the previously rendered image in the client user interface at block 516 using the updated user event attributes and the GUI independent object. For example, the client adapter 432 receives the GUI independent object 452 and the rendering engine 438 uses the updated event attribute 454 and the GUI independent object 452 to render the image previously rendered to the client user interface. Can be updated.

1A illustrates one embodiment of how a GUI independent object 452 can be created for a client adapter 432 using data from the server application 410. As described above, the client adapter 432 may receive a GUI independent object 452 having an updated user event attribute 454. The updated user event attribute 454 can include GUI independent object metadata 602 and other information. In one embodiment, the GUI independent object metadata 602 may include fixed or static metadata. The updated user event attribute 454 may further include a property / value collection 604. The static / static GUI independent object metadata 602 is combined with the GUI independent attribute / value set 604 to yield a GUI independent object 606 that can be rendered to the web client 430 by the client adapter 432. can do.

FIG. 1B illustrates one embodiment of how a particular GUI independent object 452 can be created using the configuration provided in FIG. 1A. The updated user event attribute 454 may include object metadata 612, an attribute / value set 614, and other information.

The updated user event attribute 454 can include object metadata 612 with one or more interface elements. In this example, the object metadata 612 is in the form of a field and comprises three user interface elements labeled as field A, field B, and field C. Each of the fields A, B, and C generally appears as a text box with a border surrounding the default font text, which is composed of the phrases 'field A', 'field B', and 'field C'.

The updated user event attribute 454 may further include an attribute / value set 614. In one embodiment, attribute / value set 614 may be implemented as a data structure, such as a table having one or more tuples (or rows), where each tuple is an identifier for a user interface element, An attribute for the user interface element, and an attribute (or column) containing a value for the attribute. The table of identifiers, attributes, and values may correspond to fields in object metadata 612.

When combined together, the result may be a GUI independent object 616. As shown in the GUI independent object 616, the field A does not change from the generic metadata version, because none of its attributes or values have been changed in the attribute / value set 614. In attribute / value set 614, field B appears without its border because the attribute 'border' is set to the value 'false'. Since the attribute 'italic' in the attribute / value set 614 is set to the value 'true', the text in field C appears in italic. The object 616 may now be rendered on the client 404 in the web client 430 by the rendering engine 438 of the client adapter 432. [

7 illustrates one embodiment of a logic flow 700. The logic flow 700 may illustrate operations performed in accordance with one or more embodiments. For example, logic flow 700 may illustrate operations performed by web client 430 and / or server application 410 for purposes of restoring a client adapter 432 that has been destroyed.

Another advantage of the embodiments described herein is that the image rendered to a particular client 404 can be restored when the client adapter 432 is destroyed. When the client adapter 432 is destroyed, the rendered image composed of the various GUI dependent objects 452 is also destroyed. However, server application 410 may still maintain state in the form of GUI independent object 452. As shown in FIG. 7, at block 702 a user may interact with web client 430 running in a client-side user interface to create a new instance of client adapter 432. The new instance of the client adapter 432 can then be re-connected to the server application 410 at block 704. After re-connection, server application 410 may still maintain the last known state for all GUI independent objects 452. At block 706, the last known state for all GUI independent objects 452 is sent back to the client 404 and received by the client 404. The last known state for all GUI independent objects 452 may then be synchronized with the web client 430 of the client 404 at block 708. As a result, the current state for client adapter 432 can be effectively restored using the information stored by server application 410.

8 illustrates one embodiment of an example computing architecture 800 suitable for implementing various embodiments as previously described. The computing architecture 800 may include various common computing elements, such as one or more processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices ( timing device), video card, audio card, and multimedia input / output (I / O) components. However, embodiments are not limited to implementations by the computing architecture 800.

As shown in FIG. 8, the computing architecture 800 includes a processing unit 804, a system memory 806, and a system bus 808. The processing unit 804 may be any of a variety of commercially available processors. Dual microprocessors and other multi-processor architectures may also be employed as the processing unit 804. The system bus 808 provides the processing unit 804 with an interface to system components, non-limiting, for example, system memory 806. The system bus 808 may be any type of bus structure that can be further interconnected to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. May be any of

The system memory 806 may include various types of memory units such as read only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), and double data rate DRAM ( DDRAM: Double-Data-Rate DRAM), static RAM (SRAM), programmable ROM (PROM: programmable ROM), erasable and programmable ROM (EPROM: erasable programmable ROM), electrically erasable and programmable Electrical erasable programmable ROM (EEPROM), flash memory, polymer memory, such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide- A silicon (SONOS) memory, magnetic or optical card, or any other type of media suitable for storing information In the embodiment shown in FIG. The memory 806 may include a nonvolatile memory 810 and / or a volatile memory 812. A basic input / output system (BIOS) may be stored in the nonvolatile memory 810. have.

The computer 802 may be a magnetic floppy disk drive (FDD) for reading or writing from various types of computer readable storage media, such as an internal hard disk drive (HDD) 814, a removable magnetic disk 818. disk drive 816, and optical disk drive 820 for reading from or writing to removable optical disk 822 (eg, CD-ROM, or DVD). The HDD 814, the FDD 816, and the optical disk drive 820 may be connected to the system bus 808 through the HDD interface 824, the FDD interface 826, and the optical drive interface 828, respectively. The HDD interface 824 for implementing an external drive may include at least one or both of a universal serial bus (USB) and an IEEE 1394 interface technique.

Drives and their associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, and the like. For example, the plurality of program modules may include drive and memory units 810, 812, such as operating system 830, one or more application programs 832, other program modules 834, and program data 836. Can be stored in. One or more application programs 832, other program modules 834, and program data 836 may include software components for client-server systems 200, 300, and 400, for example. .

A user may enter commands and information into the computer 802 through one or more wired / wireless input devices, such as a keyboard 838 and a pointing device, such as a mouse 840. Still other input devices may include a microphone, infrared (IR) remote control, joystick, game pad, stylus pen, touch screen, and the like. These and other input devices are often connected to the processing unit 804 via an input device interface 842 connected to the system bus 808, but other interfaces such as parallel ports, IEEE 1394 serial ports, gaming It can be connected by a port, a USB port, an IR interface, or the like.

One or more monitors 844 or other type of display device are also connected to the system bus 808 via an interface, such as a video adapter 846. In addition to the monitor 844, a computer generally includes other peripheral output devices such as speakers, printers, and the like. One or more monitors 845 may also be connected to the system bus 808 via an input device interface 842 and / or a hub, such as a USB hub 843. The monitor 845 may include various components, such as a video camera, array microphone, touch sensor, motion sensor, speaker, and the like. The component may be connected to the input device interface 842 via a USB hub 843.

Computer 802 may operate in a networked environment using logical connections to one or more remote computers, such as remote computer 848, via wired and / or wireless communications. The remote computer 848 may be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device or other common network node, and generally the computer 802 Although many or all of the elements described in connection with the description are included, for simplicity, only memory / storage device 850 is shown. The logical connections shown include wired / wireless connectivity to a local area network (LAN) 852 and / or a larger network, such as a wide area network (WAN) 854. These LAN and WAN network connection environments are commonplace in offices and corporations, facilitating intra-enterprise computer networks, such as intranets, all of which can be connected to a global communications network, such as the Internet.

When used in a LAN networking environment, the computer 802 is connected to the LAN 852 through a wired and / or wireless communication network interface or adapter 856. The adapter 856 may facilitate wired and / or wireless communication to the LAN 852, which may further include a wireless access point disposed to communicate with the wireless function of the adapter 856.

When used in a WAN networking environment, the computer 802 may include a modem 858 or may be connected to a communication server on the WAN 854 or other for establishing communications over the WAN 854, such as using the Internet. Have other means. Modem 858, which may be an internal or external wired and / or wireless device, is connected to system bus 808 via input device interface 842. In a networked environment, program modules depicted for the computer 802 or portions thereof may be stored in the remote memory / storage device 850. It will be appreciated that the network connections shown are exemplary and that other means for establishing a communications link between the computers may be used.

The computer 802 is operably deployed in wired and wireless devices or entities, such as wireless communications (e.g., IEEE 802.11 over-the-air modulation scheme) using the IEEE 802 standard family. Any facility or location associated with a wireless device such as, for example, a printer, scanner, desktop and / or portable computer, personal digital assistant (PDA), communication satellite, wirelessly detectable tag (eg, Kiosk, news stand, restroom), and telephone. This includes at least Wi-Fi (i.e., Wireless Fidelity), WiMax, and Bluetooth (TM) wireless techniques. Thus, the communication may be a designated structure as in the case of a conventional network or simply an ad hoc communication between at least two devices. To provide secure, reliable, and high-speed wireless connectivity, a Wi-Fi network uses a radio technique called IEEE 802.11x (a, b, g, etc.). Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wireless networks (using IEEE 802.3-related media and functions).

9 illustrates a block diagram of an example communications architecture 900 suitable for implementing various embodiments as previously described. The communication architecture 900 includes various general communication elements, such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, and the like. However, the embodiment is not limited to implementation by the communication architecture 900.

As shown in FIG. 9, communication architecture 900 includes one or more clients 902 and a server 904. The client 902 may implement a web client 330. The server 904 may implement a runtime engine 312. The client 902 and server 904 may each be used to store local information of each client 902 and server 904, such as cookies and / or contextual information associated therewith. Are operatively connected to the client data store 908 and the server data store 910.

Client 902 and server 904 may communicate information between each other using communication framework 906. The communication framework 906 may be any well-known communication technique, such as a packet-switched network (eg, public network, such as the Internet, a private network, such as a corporate intranet, etc.), a circuit-switched network. suitable techniques for use with circuit-switched networks (e.g., public switched telephone networks) or combinations of packet-switched and circuit-switched networks (including suitable gateways and translators) Can be implemented. The client 902 and server 904 are various types of standard communication elements designed to interoperate with the communication framework 906, such as one or more communication interfaces, network interfaces, network interface cards (NICs). , Radio, wireless transmitter / receiver (transceiver), wired and / or wireless communication media, physical connector, and the like. By way of non-limiting example, communication media includes wired and wireless communication media. Examples of wired communication media include wire, cable, metal lead, printed circuit board (PCB), backplane, switch fabric, semiconductor material, twisted-pair wire, co-axial cable, optical fiber, propagated signal, and the like. Examples of wireless communication media may include acoustic, radio frequency (RF) spectra, infrared, and other wireless media. One possible communication between the client 902 and the server 904 may be in the form of a data packet configured to be transmitted between two or more computer processes. The data packet may comprise a cookie and / or contextual information associated with it, for example.

Various embodiments may be implemented using hardware elements, software elements, or a combination thereof. Examples of hardware components include, but are not limited to, devices, logic devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits A programmable logic device (PLD), a digital signal processor (DSP), a field programmable gate array (FPGA), a memory unit, a logic gate, a register, Microchips, chipsets, and the like. Examples of software components are software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, An application program interface (API), an instruction set, a computing code, a computer code, a code segment, a computer code segment, a word, a value, a symbol, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and / or software elements may include any number of factors, such as desired computational rate, power level, thermal tolerance, processing cycle budget, input data rate, Depending on the output data rate, memory resources, data bus speed, and other design or performance constraints, it may vary as desired for a given implementation.

Some embodiments may include articles of manufacture. The article of manufacture may comprise a computer-readable storage medium configured to store logic. Examples of computer-readable storage media include any storage medium capable of storing electronic data, such as volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or rewritable Re-writeable memory and the like. Examples of logic include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, Procedures, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. In one embodiment, for example, an article of manufacture may store executable computer program instructions that, when executed by a computer, cause the computer to perform a method and / or operation in accordance with the described embodiment. Executable computer program instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The executable computer program instructions may be implemented in accordance with a computer language, method, or syntax that is intended to instruct a computer to perform a particular function. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

Some embodiments may be described using the expression “one embodiment” or “an embodiment” and derivatives thereof. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.

Some embodiments may be described using the expression “coupled” and “connected” and derivatives thereof. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms "connected" and / or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but that they cooperate or interact with each other.

The abstract herein is provided to enable a reader to quickly find out the nature of the technical disclosure. It should be understood that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped into one embodiment for the purpose of streamlining the disclosure. This disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims indicate, the invention consists in less than all features of one single disclosed embodiment. Accordingly, the following claims are in the detailed description, and each claim is itself a separate embodiment. In the following claims, the terms "including" and "in which" are used as synonyms for the respective terms "comprising" and "wherein". In addition, the terms "first", "second", "third", and the like are merely used as labels, and are not intended to impose any numerical requirements on these objects.

While the invention has been described in language specific to the operation of features and / or methods of construction, it is to be understood that the invention as defined in the following claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.

Claims (10)

15. A method implemented by a computer,
Receiving a control directive indicating a user event in the client user interface,
Determining whether a user event attribute associated with the user event has changed;
Sending the changed user event attribute to a server application running on the server,
Receiving a graphical user interface (GUI) independent object having updated user event attributes from the server application, and
Updating the image rendered in the client user interface based on the GUI independent object and the updated user event attribute received from the server application.
A method implemented by a computer.
The method of claim 1,
Receiving a GUI independent object having an updated user event attribute, wherein the updated user event attribute is one in which object metadata having one or more user interface elements or each tuple includes an identifier for a user interface element At least one of at least a tuple, an attribute for the user interface element, and an attribute / value set having a value for the attribute;
A method implemented by a computer comprising a.
The method of claim 1,
Sending a plurality of changed user event attributes for a plurality of user events as a message to the server application running on the server.
≪ / RTI >
The method of claim 1,
Updating one or more user interface elements of an image rendered in a client user interface based on the GUI independent object and updated user event attributes received from the server application.
≪ / RTI >
The method of claim 1,
Creating a new instance of the client adapter when the rendered image composed of the previous instance of the client adapter and its associated GUI dependent objects is destroyed,
Reconnecting the new instance of the client adapter to the server application,
Receiving a last known state for all GUI independent objects from the server application, and
Synchronizing the last known state for all GUI independent objects received from the server application in the new instance of the client adapter
≪ / RTI >
When executed, a storage medium comprising instructions for causing a system to perform a method according to any one of claims 1, 2, 3, 4 and 5.
An article of manufacture comprising a.
Logic devices, and
A web client operating on the logic device, the web client detecting a user event for a client user interface, sending a change in a user event attribute associated with the user event to a server application, a graphical user interface (GUI) independent object, and A client adapter operative to receive an updated user event attribute from the server application and to update an image rendered in the client user interface using the updated GUI event and the updated user event attribute received from the server application.
/ RTI >
8. The method of claim 7,
The GUI independent object has an updated user event attribute, the updated user event attribute includes object metadata and a set of attributes / values, the object metadata includes one or more user interface elements, and the attribute / value The set includes one or more tuples where each tuple includes an identifier for a user interface element, an attribute for the user interface element, and a value for the attribute.
Device.
8. The method of claim 7,
The client adapter may be configured to include at least one of a user interface manager for controlling the client user interface, or a rendering engine for updating the rendered image based on the GUI independent object and an updated user event attribute received from the server application. Containing
Device.
8. The method of claim 7,
The web client
Create a new instance of the client adapter when a rendered image that includes a previous instance of the client adapter and one or more GUI dependent objects associated therewith is destroyed, such that the new instance of the client adapter reconnects to the server application; Operative to receive the last known state for all GUI independent objects from the server application and to synchronize the last known state for all GUI independent objects received from the server application in the new instance of the client adapter. Working
Device.

Images