Patent Application
20060069704
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates to systems and method for organizing applications. More specifically, it relates to techniques for providing disconnectible applications that can be run on clients without a constant connection to a server.
Since its inception in 1995, the Java™ programming language has become increasingly popular. (Java™ is a trademark of Sun Microsystems, Inc.) Java, which is an interpreted language, enabled the creation of applications which could be run on a wide variety of platforms. This ability to function across a variety of different client platforms, i.e., platform independence, and Java's relatively easy implementation of network applications has resulted in the use of Java, as well as other programming languages that provide platform independence, in endeavors as basic as personal web pages to endeavors as complex as large business-to-business enterprise systems.
However, since applications that are designed to provide functionality over networked systems are necessarily designed to rely upon frequent connectivity in order for the applications to function, such applications are often rendered useless when connectivity is unreliable. For example, many applications require frequent interactive transmission with a remote server. Such applications often wait for replies and confirmations for any transmissions before proceeding to a next step. Additionally, since such conventional applications cannot function without server/client connectivity, servers are often forced to devote resources to relatively unimportant responses to remote clients, without which the remote applications would be held up.
What is needed is an improved mechanism for managing server/client interaction.
In embodiments there are provided mechanisms and methods for providing disconnectible applications capable of executing at least semi-autonomously, i.e., without needing constant contact with a server, on a client substantially independent of server connectivity. A “disconnectible application” (DA) can be any type of application, including without limitation a Portal or a Portlet, or an application completely separate from portal constructs. The ability of a disconnectible application to execute on a client substantially independent of server connectivity can enable enhanced flexibility in organizing applications to build data processing systems.
In an embodiment, disconnectible application can comprise one or more “smart pages” that provide dynamic access to data stored locally on a client. Through messages exchanged with a server, the disconnectible application is able to update a local data store and trigger actions on the server. Messages can be sent and received asynchronously with respect to the disconnectible application, so that the disconnectible application is not forced to wait for a server response. Because user interface pages are generated dynamically on the client, embodiments of disconnectible applications can be used even when network connectivity is poor or unavailable.
A disconnectible application can appear to ‘contain’ other disconnectible applications. In the case of a disconmectible Portal, this means the disconnectible Portal could contain disconnectible Portlets. The Portal and any disconnectible Portlets it contains can then be run in either in a connected or a disconnected mode.
In an embodiment, disconnectible applications reside in a runtime environment on the client, which provides the applications with a high-level abstraction of the services available on the client and asynchronous communications services. A web browser may be used to interact with the runtime environment to access the application on the client. When connected, a disconnectible application Portal can be enabled to access traditional (non-disconnectible) Portlets.
In an embodiment, disconnectible applications comprise one or more “screens” that contain user interface information and “message handlers” that process messages received from the server or other entities. Each screen includes a definition comprising information on how data should be bound from the local data store and what actions should be taken for user actions. The message handlers contain information on how to process messages arriving from the server or other entities, such as adding data from the message to the local data store or responding with another message.
The local data store is accessed by the disconnectible application as a hierarchical, ordered object database abstracted in the form of an XML document. The data store is not necessarily physically stored as an XML document, but treating it as such provides a familiar, powerful and flexible mechanism for storing data while maintai ing a relatively lightweight footprint. The disconnectible application runtime environment provides this abstraction on top of the actual data storage mechanism available on a client.
Disconnectible application embodiments can comprise a messaging interface for communicating with one or more servers, for example, and data access/persistence functionality on the client. In an embodiment, disconnectible applications communicate with one or more servers through an asynchronous message system. In an embodiment, disconnectible applications may reside within the runtime environment that abstracts messaging and data access functions from the applications thereby providing the applications with the flexibility to execute without constant connections to messaging and data access functions. The disconnectible applications may return or modify data stored on the client in response to messages received from the server responsive to communications with the server becoming active.
In an embodiment, communication to and from the disconnectible application is conducted through a “message” abstraction. Each message comprises of an “action”, which serves as a label to indicate the message type or intent, and optionally some “action data”, which may contain arbitrary data. Action data may be a hierarchical, ordered object database fragment and is accessible to the disconnectible application through an XML document fragment abstraction, although the data is not necessarily physically transmitted as XML. Data arriving from a server or other entities (such as other disconnectible applications or connected applications) can be presented to the appropriate message handler as an XML fragment. When the disconnectible application sends a message to the server or another entity, the disconnectible application can construct or derive an XML fragment representing the message and specify that the message be sent. The runtime environment is responsible for handling the underlying processing involved in receiving and sending messages, such as data formatting, network or inter-application protocols and error handling.
Disconnectible application creation can be performed by building on the supporting runtime framework, which provides mechanisms for accomplishing tasks to the disconnectible application.
The databases 105 are information resources that are accessed and utilized by the server 115. In one embodiment, the databases 105 are Structured Query Language (SQL) compliant databases. The server 115 receives requests for data from the client 140, translates the data requests to SQL requests to be applied to the databases 105, and then passes the requested data back to the client 140.
The client 140 provides client functionality to include receiving input and data from users, transmitting the input and data to server 115, receiving responses and output from the server 115, displaying responses and output to a user and other client operations. As used herein, the term “user” is intended to include human users, as well as proxies and other computational entities. As with the server 115, the client 140 can be implemented by various combinations of hardware and software in various embodiments. The client 140 includes one or more disconnectible applications 150 deployed thereon. The disconnectible applications 150 are applications configured to run semi-autonomously without constant contact with the server 115. Embodiments of disconnectible applications 150 can employ an asynchronous message system to communicate with the server 115. In an embodiment, disconnectible applications 150 function within a runtime environment on the client 140 that abstracts messaging and data access functions from the various disconnected applications. The disconnectible applications 150 return or modify data stored on the client 140 in response to messages received from the server and interpreted through the runtime environment. In some embodiments, the disconnectible applications 150 are downloaded from the server 115 when the client 140 first interacts with the server 115, and/or at convenient times thereafter. In alternate embodiments, the disconnectible applications 150 are configured directly on the client 140, or may be obtained through a third party.
The disconnectible application runtime environment 230 supports one or more disconnectible applications and provides messaging and data access support for the disconnectible applications. The disconnectible application runtime environment 230 maintains a messaging layer that receives messages from message handlers within the disconnectible applications, queues the messages until the server 115 is accessible, and transmits the messages to the server 115. The runtime environment 230 similarly receives messages from the server 115 and transmits them to the disconnectible applications. The disconnectible application runtime environment 230 additionally provides an interface to data store 215 in order to manage features such as data formatting, error handling, and management of data storage on behalf of the disconnectible applications.
The communication component 245 interfaces with the disconnectible application runtime environment 230 to manage the interaction between the client 140, and the server 115 and any other clients or servers with which the client 140 might interact. The communication component 245 additionally handles message management features such as data formatting, error handling, and management of network or inter-application protocols.
The client 140 additionally includes an interface component 225. The interface component is configured to receive input from a user of the client and to display output to the user. In some embodiments, the interface component 225 interacts with a web browser (not shown for brevity). In these embodiments, the interface component 225 collects input from the user through forms or other input mechanisms managed through the web browser. In these embodiments, the interface component 225 displays output to the user through content displayed on web pages viewed through the browser. In alternate embodiments, the interface component 225 generates a custom interface through which a user interacts with the client 140.
The client 140 additionally includes a data store 215. The data store 215 stores data to be accessed by the client services 250 and the disconnectible application runtime environment 230. The client services 250 are client data access and management services that are made accessible for the disconnectible applications.
The disconnectible applications 320, 325 include interface data that is handled by a web browser or other interface component to generate a user interface that is used to collect input from users and display output. The interface data includes information indicating how data should be bound from the data store 215 and what information should be taken in response to user actions received through the generated interfaces. The disconnectible applications 320, 325 additionally include message handlers that process messages received from the server 115 or other entities. The message handlers indicate what actions should be taken by the disconnectible application 320, 325 in response to a message from the server 115. The actions can include displaying output to a user, modifying data stored in the data store 215, providing a response message, or performing other functions.
The communications services 310 receive outgoing messages from the disconnectible applications 320, 325 as well as incoming messages from the server 115, and transmit the messages to the intended destination. In some embodiments, the messages are configured as an extensible Markup Language message. In alternate embodiments, other formats are used. In some embodiments, the messages include an action field indicating the message type or intent. The message can also include an action data fragment containing arbitrary data.
The disconnectible application runtime environment 230 additionally includes a client interaction module 340. The client interaction module 340 governs the interaction between the disconnectible applications 320, 325, the client services 250, and the data stores 215. The client interaction module 340 abstracts data stored in the data stores 215 so that the data appears to disconnectible applications 320, 325 as a hierarchical ordered database in the form of an XML file. Thus, all data extraction and modification requests submitted by the disconnectible applications 320, 325 are formatted for such a database.
The pages 405, 410 include information indicating how user actions should be processed for each page's associated interface. These actions can include displaying or modifying data in the data store 215, or displaying a response to the user. While in the present embodiment only two pages 405, 410 are illustrated the disconnectible application 320 can have any number of pages.
The message handlers 415, 420 process messages received from the server 115 and respond accordingly. Potential responses include without limitation displaying output to a user, modifying data stored in the data store 215, providing a response message, or performing other functions. In some embodiments, a single message handler is configured to process all messages received from the server 215. In alternate embodiments, the disconnected application includes a different message handler for each message type or group of message types.
Other features, aspects and objects of the invention can be obtained from a review of the figures and the claims. It is to be understood that other embodiments of the invention can be developed and fall within the spirit and scope of the invention and claims.
The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to the practitioner skilled in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence.
In addition to an embodiment consisting of specifically designed integrated circuits or other electronics, the present invention may be conveniently implemented using a conventional general purpose or a specialized digital computer or microprocessor programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art.
Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of application specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
The present invention includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present invention. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, and user applications.
Included in the programming (software) of the general/specialized computer or microprocessor are software modules for implementing the teachings of the present invention.
The present application claims the benefit of: U.S. Provisional Patent Application No. 60/573,776 entitled SYSTEMS AND METHODS FOR PORTAL 9.0, by Skip Sauls et al., filed on May 21, 2004. (Attorney Docket No: BEAS-1707US0), the entire contents of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60573776 | May 2004 | US |
