Title
MOBILE -APPLICATION SERVICE
Technical Field
This invention concerns a mobile application service. In particular the invention concerns the server and remote client, and their methods of operation, in a system for providing a mobile application as a service, to users.
Summary of the Invention
In a first aspect the invention is a centralised server, or software to program a centralised server, for a mobile application service system, where the server is programmed to create and maintain separate databases for respective mobile clients to hold client knowledge in the form of: free form database objects, known as frame objects, which hold client data in data fields and are replicated in client computers; and component based application modules, known as agent objects, which the server despatches to respective clients, as required, to create or manipulate information in the frame objects: and where the server is programmed such that, after a frame object has been changed a new edition of the frame object, known as a delta frame object, is created which contains only the data fields that have been changed: and synchronisation of the server and the mobile client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity, then transmission of the determined delta frame objects achieves conformity.
In a second aspect the invention is a method of providing a mobile application service system, comprising the steps of: creating and maintaining at a server, separate databases for respective remote clients to hold client knowledge in the form of: free form database objects, known as frame objects, which hold client data in data fields and are replicated in client computers; and
component based application modules, known as agent objects, which the server despatches to respective clients, as required, to create or manipulate information in the frame objects: and where, after a frame object has been changed, creating a new edition of the frame object, known as a delta frame object, which contains only the data fields that have been changed: and synchronising the server and the client by exchanging edition information between them, determining from the exchange which delta frame objects need to be aggregated, aggregating those delta frame objects, and transmitting the aggregated delta frame objects in order to bring them into conformity.
In a third aspect the invention is a client runtime environment, or software to program a runtime environment, where the runtime environment is programmed to hold: free form database objects, known as frame objects, which hold client data in data fields and are replicated in a remote server, and component based application modules, known as agent objects, received from the server despatches, as required, to create or manipulate information in the frame objects; and where the runtime environment is programmed such that, after a frame object has been changed a new edition of the frame object, known as a delta frame object, is created which contains only the data fields that have been changed: and synchronisation of the client with the server or another client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity, then transmission of the determined delta frame objects achieves conformity.
In a fourth aspect the invention is a method of providing a runtime environment, comprising the steps of: programming the runtime environment to hold: free form database objects, known as frame objects, which hold client data in data fields and are replicated in a remote server, and component based application modules, known as agent objects, received from the server despatches, as required, to create or manipulate information in the frame objects; and where, after a frame object has been changed, creating a new edition of the frame object, known as a delta frame object, which contains only the data fields that have been changed: and synchronising the client with the server or another client by exchanging edition information between
them, determining from the exchange which delta frame objects need to be aggregated, aggregating those delta frame objects, and transmitting the aggregated delta frame objects in order to bring them into conformity.
By this arrangement and technique it may be possible to minimise the volume of data transfer required to maintain synchronisation between one or more remote client databases, where each client database holds several frame objects. Alternatively, it may be possible to minimise the volume of data transfer required to maintain synchronisation of a centralised, server, database holding an amalgamation of all frame objects which have been replicated to the server database from client databases.
The server and client databases cooperate in the process of synchronisation to maintain editions of frame objects stored at the server and client databases. An edition represents a complete frame object when taken in isolation. An edition, when taken relative to a predecessor edition represents only the changes ("delta elements") to that predecessor edition. The edition history may be arbitrarily long (i.e. the number of editions kept) although for data storage conservation reasons edition history may be trimmed without loss of integrity of the whole frame object. The tradeoff in this case will be that the whole frame object would need to be sent in any request for an edition which has been trimmed since the change information required to enable extraction of the delta elements will have been removed. Generally. Objects are held at the server and client in persistent storage.
All the objects are advantageously platform independent. Frame objects can have data fields ("slots") arbitrarily added, changed or deleted. Conventional compression schemes may also be employed to further improve the efficiency of data transfer.
The computer supporting the server database and the computers supporting the client databases will be connected via communications networks which are either charged on a time connected basis, or. a quantity of data transferred basis. In either case it is to the commercial benefit of the user to minimise the data traffic such that telecommunications costs are reduced.
Programming and administration tools may be provided for the system. The system may be designed to offer reliable uninterrupted operations. The design may be flexible and broad enough to meet both current and future subscriber requirements. The system may also minimise telecommunications
traffic costs and cater for the typical mobile user who is "occasionally" connected to the service.
The central server infrastructure may support multiple companies operating simultaneously and with concurrent end-user sessions. It may be able to be rapidly and easily customised to meet an individual subscriber company's needs. It may be capable of adding or changing customised applications on the service without compromising the operating stability and reliability for existing subscribers. It may also provide users with an environment closely representing their "legacy" paperwork processes. The system may interface with existing host computing systems to extend the functionality of a company's IT as seamlessly as possible. It may also maximise operational cost efficiency by sharing central server infrastructure over the entire subscriber base. The service may support clients operating in "occasionally connected" mode to provide continuous functionality for mobile users or fixed clients with restricted communications continuity. It may minimise data transfer between clients and the server by only transferring those elements of data structures that have changed at either end. It may support mechanisms to stringently validate the integrity of data transferred between the server and clients. It may be capable of being localised to enable deployment in different international territories
The architecture enables the implementation of a reliable multi- subscriber mobile application service. An innovative use of object technology and an application abstraction layer enables the system to run generalised software at the server (hub) and yet be fully customable to the unique needs of different subscriber companies.
Brief Description of the Drawings
An example of the invention will now be described with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram of the tiers of the architecture of the service example.
Figure 2 is a schematic diagram of the architecture of the central service system.
Figure 3 is a schematic diagram of the client architecture. Figure 4 is a schematic diagram of the communications structure assumed for the service.
Best Modes of the Invention
The system architecture 1 of the service system is implemented as a multi-tiered client-server computing model, as illustrated in Figure 1. There is a central site server system 2, and remote clients 3. There are a number of tiers of the architecture.
A client-server communications layer 4 supports network traffic authenticated access, utility services and programmable (custom) services. The programming model (client-server-service) relies on the concept of software services running in conjunction with the server with which clients interact.
A system-wide object programming model 5 supporting platform independent objects, object manipulation primitives (methods) and mechanisms for remote method invocation between clients and the server. An application "runtime" environment 6 provides support for advanced object operations such as persistence (caching), queries, transfer, synchronisation, etc.
Component-based application modules 7 are dispatched to execute in the client runtime environment 6. The applications 7 are called agents. Agents 7 are objects able to create or manipulate information, which will subsequently be exchanged with the server system 2. deposited in an object store 8. and routed to their next destination (client). To an end user, agents might appear as forms and list items that display on the client device screen. The system also has a number of other important functional blocks. These are: a System Development Kit (SDK) that provides a set of programming tools that enable the rapid development of agents and other data definitions used to define an application. And a set of administrative tools used in the operation and maintenance of the overall system.
The lower layer consists of an object-oriented client-server system that provides data communications, authenticates connections, routes data traffic. logs events, and provides a variety of other utilities (e.g.. Internet mail and paging system interfaces).
The client-server system implements the object model and object primitives used extensively by the upper layers of the architecture. The object model is built around clients interacting with services, which are
exposed to them through the server. Clients create remote objects of defined types in services and send method calls to those objects for the server to execute on their behalf.
In single-purpose application systems, the services consume a large proportion of the application specific code. However, this service system provides services that support object manipulation for the runtime environment executing in the clients. Subscriber-specific application code executes exclusively in the client runtime environment 6.
Applications are abstracted from the basic client-server system by a runtime layer. The client side runtime layer 6 implements a set of interfaces and functionality required for the execution of application agents 7 at a client. Agents 7 are stored centrally 8 on the server and dispatched to a client as required. As far as an agent 7 is concerned, all the resources and data that it requires to operate exist in the client runtime environment 6. Any requests that the client runtime cannot fulfil directly for an agent will be dealt with by having the runtime 6 "contact" the server 2. This can happen invisibly or the agent 7 can be notified of a connection requirement.
The central server system 2, or hub, is the transportation and distribution centre for the entire system. The hub 2 enables agents 7 to travel to clients 3 in order to carry out their intended tasks. Upon connection, clients 3 declare their platform type to the hub 2 which, in turn, dispatches agents 7 that are compatible with that client's computer platform. The hub 2 is solely responsible for transporting and storing objects; it remains independent of any particular subscriber application. The hub 2 is designed to support multiple subscriber companies using the system simultaneously and multiple concurrent client sessions. The services at the hub are available to all users.
Figure 2 shows an overview of the hub architecture.
The hub 2 moves all application data to and from clients. The hub is configured for a new subscriber company by allocating a database 10 to a subscriber company and then depositing agents 7 and their accompanying data into that databaselO. The software "knowledge" for a particular subscriber company is held entirely by the company specific agents and their accompanying data and view definitions. Administration and monitoring of the overall system is carried out by client computer(s) with "administrator" privileges. Administrator clients are
independent of the application system and interact directly with the client- server and runtime systems.
Administrative clients are used to manage functions such as adding or removing subscriber end users, depositing new versions of agents onto the system for use in a particular subscriber application, viewing system logs to trace abnormal events or faults, etc.
Agents 7 characterise the behaviour of a client 3. Agents 7, in conjunction with the data store 10, are the primary means of customising the system. Agents 7 stored at the hub 2 may contain code for execution on a number of different client platforms. The hub 2 will choose the appropriate code version to dispatch in an agent to a client 3. It is able to do this because clients 3 declare their platform type to the hub when they connect in. Neither the server nor client runtime layers 6 have any specific knowledge of the tasks that an agent implements for a particular subscriber company. The runtime environment deals with objects only. Agents are uniquely programmed to implement the "business rules".
Agents are dispatched from the hub to clients automatically and are held in persistent storage in a client until replaced or purged. Therefore, the hub may respond to a client's request for an agent and attached data by sending the data only, since the agent may already reside in memory. Agents may co-exist in clients with more versions of themselves. This enables multiple versions of "agent data" to reside in the system and still be processed by the agent of the correct (or older) version if required. This feature is important where large amounts of historical data may be held on the system. Older versions of data may need to be handled by a matching version of an agent. In this case agents and agent data of older versions must be able to co-exist.
Agents "carry around" the data that they require by referencing data objects. The actual task of transporting the data is a function of the object store and the routing and transfer services. Consequently, agents never need to concern themselves with how they or the data they require travels.
The major elements of the client 3 architecture are shown in Figure 3. The scope of an agent's 7 interaction with the client operating system or connected devices is unrestricted. It is. therefore, possible to implement any required interface at a client. Client computers may interact with human operators using an agent that has a Graphical User Interface (GUI). Client
computers can also act as a gateway to other computers or IT systems simply by creating the appropriate agent interface. Standard agents can be constructed for use via published programmatic interfaces as ODBC and those that are delivered with the Operating systems and database software. Other standard agent interfaces for integrating with customer information systems such as SAP can be readily constructed.
The system is designed to enable clients to operate in off-line (not connected) mode. The runtime environment attempts to satisfy all agent requests without connecting. The object store caching mechanism captures data current to the last connection between the hub and a client. The off-line mode of operation is used heavily for mobile clients; however, the use of the "occasionally connected" mode of operation is not restricted to use by mobile devices.
With the recent emergence of intelligent mobile phone handsets, this class of device is a potential candidate for a mobile client computer. The screen area, memory and processing power of these devices is generally limited to the extent that they are not candidates for a standard client. However, by using a standard client as an intermediate interface for these types of devices, it would be possible to support such simple mobile clients on the system. A single interface client could act as a proxy for multiple simple clients. Simple clients would generally be restricted to receiving schedule (job) data, acknowledging receipt of schedule data, submitting time use information. Simple clients could also perform well in the receiving of management information from the system so that business performance information could be conveyed to field based management.
An agent implements its GUI with the aid of View Definitions. A View Definition is yet another object and defines how a particular GUI operates on a client device. This is important where the same agent may execute on a variety of devices with differing screen sizes and input systems (e.g. handheld vs desktop or keyboard vs pen). Therefore, view definitions provide convenient and consistent ways for agent data to be displayed and input on a system wide basis.
In order to have data formats universally understood across the entire system all data is described by data definitions. Data definitions are objects with a known internal structure which have the sole purpose of describing the format of other free form objects. Data definitions (DataDefs) have
version information contained in them (just like agents). Consequently, multiple versions of the same basic data definition may exist in the system concurrently without causing concern (as you might expect this is actually true of all objects used in the application system). Data definitions may reference other data definitions. Arbitrarily complex data structures can be constructed and moved around the system through this linking and embedding mechanism.
Each customised application will have its own set of data definitions which will be guaranteed to be unique within the system. The object stores (hub and client) hold all subscriber specific data in the system. The hub object store is designed for fast operations on multi- object hierarchical structures. The object store only moves those objects that do not currently exist at the destination site (client or server). The object store further economises on data traffic by moving only those parts of objects that have changed. This process of partial data transfer is termed
"synchronisation". Synchronisation plays an important role in minimising traffic to and from mobile clients where communications bandwidth is at a premium.
In more detail, when a frame object has been changed a new edition of the frame object, known as a delta frame object, is created which contains only the data fields that have been changed. Synchronisation of the server and the client involves the exchange of edition information between them so that a determination can be made of which delta frame objects need to be aggregated and transmitted in order to bring them into conformity. Then the determined delta frame objects are transmitted to achieve conformity.
An object based query system is built into the object store in order to enable content based searching and extraction of objects.
The hub object store caches all client data that passes through it. Clients also cache data but restrict this to items that are of concern to them. Therefore, the hub has a snapshot of information from clients current to their last connection. The caching of data at the hub enables the recovery of a particular client's state should it lose its local copy of data.
All data associated with each subscriber company is held in separate object stores at the hub. Customisation to meet individual subscriber company requirements is carried out with the aid of a System Development Kit (SDK). The SDK
generates agents, view definition and data definition objects. Agents, view definitions and data definitions created by the SDK are loaded into storage on the hub for distribution to client computers. The SDK supports the creation of derivative applications from base (template) applications. This substantially speeds the implementation of applications for specific companies. Derivative applications can co-exist in the system without conflict since all objects are assigned unique IDs.
The basic System requires mobile communications to support roaming connections from handheld clients, landline communications to support connections from office based clients and landline communications to support administration clients.
The communications structure assumed for the service is shown in Figure 4.
GSM is the prime wireless communications medium for handheld devices. This is well supported in Australia, Asia and Europe with the majority of GSM carriers having data capabilities in their networks. In order to increase the customer satisfaction with the GSM mobile connections there is "direct connect" of service servers to the GSM switch. Direct connect eliminates the need to exit the digital part of the GSM network in order to establish a data connection via analog modem to the server(s). This has the effect of reducing the connect time from a mobile handheld by approximately 20 seconds (analogue modem dialling/training time). The resulting connect time is then reduced to the TCP/IP communication setup and server login time. Advances in the GSM system will soon see the introduction of GSM packet based services known as General Packet Radio Services (GPRS). Packet services enable a (virtual) continuous connection between the client and the hub with the subscriber being charged by data traffic rather than connection time. The implementation of GPRS will improve the utility of the Service by enabling mobile clients to dramatically increase their communication "uptime" with the service. While ever a mobile user is in radio coverage GPRS will enable client to server communications to take place and a more continuous exchange of information between the mobile user and the hub. Alternative mobile data networks such as CDPD are supported by the Retriever system. CDPD is a packet based system supporting TCP/IP
communications. It is enjoying increased coverage in the USA and offers similar features to GPRS but operates on an analogue system (operates over legacy -AMPS cellular networks).
Providing Internet based access is a logical extension of the system. By using web access customers could review the status of current activity or review historical information.
Web access would be provided through a secured web site in order to retain security over the information. Web access would be "view only". Customers would require a username and password in order to access the secure web site.
It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.