Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent Application
20020095399
Kind Code
A1
Devine, Robert L.S. ; et al.
July 18, 2002
System and methods providing automatic distributed data retrieval, analysis and reporting services
Abstract
A data processing system includes a network containing of a set of connected devices, where individual ones of the connected devices include a data processor that executes a program for connecting to and disconnecting from the network and for maintaining a first list descriptive of other connected devices and a second list descriptive of at least some user-defined services published by individual ones of publisher connected devices that form a first sub-set of the connected devices. Individual ones of the publisher connected devices maintain a third list descriptive of an individual one or individual ones of registered service subscriber connected devices that form a second sub-set of connected devices. The publisher connected devices provide a service output to registered service subscriber connected devices upon an occurrence of at least one predetermined triggering event, which may be a push trigger, a pull trigger, or a combination of push and pull triggers. A given one of the connected devices may be a member of only the first sub-set of connected devices, or may be a member of only the second sub-set of connected devices, or may be a member of both the first sub-set of connected devices and the second sub-set of connected devices. The set of connected devices are logically organized into a plurality of clusters each having a top level connected device (TLCD), where the plurality of TLCDs are coupled together in a ring for propagating system administration information between the plurality of clusters. Services remain operative even after the connected device on which they initially reside becomes inoperative. This is accomplished by migrating the publication function to at least one other connected device when a current publisher's connected device becomes inoperative for any reason. A backup of last resort is referred to as a persistent connected device.
Inventors:
Devine; Robert L.S.
(Falkirk, GB)
, Stoner; Robert J.
(Duxbury, MA
)
Correspondence Name and Address:
1809 BLACK ROCK TURNPIKE
HARRINGTON & SMITH, LLP
FAIRFIELD
CT
06432
US
Series Code:
849061
Filed:
May 4, 2001
U.S. Current Class:
707/1
U.S. Class at Publication:
707/1
Intern'l Class:
G06F 007/00
Claims
What is claimed is:
1. A data processing system that includes a network comprised of a set of connected devices, individual ones of said connected devices of said set of connected devices comprising a data processor that executes a program for connecting to and disconnecting from said network and for maintaining a first list descriptive of other connected devices and a second list descriptive of at least some user-defined services published by individual ones of publisher connected devices that are members of a first sub-set of the connected devices, individual ones of said publisher connected devices maintaining a third list descriptive of an individual one or individual ones of registered service subscriber connected devices that are members of a second sub-set of connected devices, said publisher connected devices providing a service output to registered service subscriber connected devices upon an occurrence of at least one predetermined triggering event, wherein a given one of said connected devices may be a member of only said first sub-set of connected devices, or may be a member of only said second sub-set of connected devices, or may be a member of both said first sub-set of connected devices and said second sub-set of connected devices.
2. A data processing system as in claim 1, wherein individual ones of said publisher connected devices of said first sub-set of connected devices have at least one back-up connected device to publish the service upon the unavailability of said publisher connected device, said at least one back-up connected device storing data and procedures required to publish the service should the publisher connected device become unavailable.
3. A data processing system as in claim 1, wherein said triggering event is comprised of an occurrence of a push trigger defined by said publisher connected device.
4. A data processing system as in claim 1, wherein said triggering event is comprised of an occurrence of a pull trigger defined by said subscriber connected device.
5. A data processing system as in claim 1, wherein said triggering event is comprised of an occurrence of a push trigger defined by said publisher connected device and by an occurrence of a pull trigger defined by said subscriber connected device.
6. A data processing system as in claim 1, wherein a content of said first list is changed automatically as connected devices connect to and disconnect from said network.
7. A data processing system as in claim 1, wherein at least one of said published services is based on the operation of a spreadsheet engine operated by one of said publisher connected devices.
8. A data processing system as in claim 1, wherein said network is comprised of a Local Area Network (LAN), and wherein said connected devices self-register on the LAN when connecting to the LAN using Mailslots.
9. A data processing system as in claim 1, wherein said network is comprised of a Wide Area Network (WAN), and wherein said connected devices self-register on the WAN when connecting to the WAN using Named Pipes.
10. A data processing system as in claim 1, wherein at least one of said published services retrieves data in response to a database query originated by a subscriber connected device, wherein the data is retrieved from a database where the publisher connected device has access rights.
11. A data processing system as in claim 1, wherein at least one of said published services is offered by a first publisher connected device that subscribes to at least one second publisher connected device, wherein a report generated by said first publisher connected device comprises a portion of a report received from the second publisher connected device.
12. A data processing system as in claim 1, wherein at least one of said published services is offered by a first publisher connected device that subscribes to at least one second publisher connected device, wherein a report generated by said first publisher connected device comprises a processed portion of a report received from the second publisher connected device.
13. A data processing system as in claim 1, wherein set of connected devices communication over said network using TCP/IP.
14. A data processing system as in claim 1, wherein at one of said set of connected devices is coupled to said network through a wireless link.
15. A data processing system as in claim 1, wherein at least one of said connected devices comprises a measuring machine that generates data and publishes the data in a report service to which at least one publisher connected device subscribes, said subscribing publisher connected device offering a service that reports all or a portion of the data generated by said measuring machine.
16. A data processing system as in claim 1, wherein at least one of said connected devices comprises a measuring machine that generates data and publishes the data in a report service comprising a spreadsheet to which at least one publisher connected device subscribes, said subscribing publisher connected device executing a spreadsheet engine that treats at least some of said data as spreadsheet variables and offers a service that reports a result of a processing of said spreadsheet variables by said spreadsheet engine.
17. A data processing system as in claim 16, wherein a triggering event comprises a change in state in at least one of said spreadsheet variables.
18. A data processing system as in claim 1, wherein a database is stored in a distributed manner by a plurality of said connected devices, and wherein subscribers to said database issue queries that are responded to in a distributed manner by said plurality of connected devices.
19. A data processing system as in claim 1, wherein a publisher connected device maintains a data warehouse by subscribing to at least one publisher connected device that is coupled to a database, and responds to a query from a connected device for data stored in said data warehouse.
20. A data processing system as in claim 1, wherein at least one database is accessible to a publisher connected device to which a subscriber connected device issues queries, said publisher connected device issuing a database query on behalf of the subscriber connected device and returns a result of the query to the subscriber connected device.
21. A data processing system as in claim 1, wherein a database is maintained by at least one publisher connected device, said database storing data related to a project, and wherein a subscriber connected device has access to at least a portion of said project-related data regardless of its storage location, so long as said publisher connected device has access to the project-related data.
22. A data processing system as in claim 1, wherein a service offered by a publisher connected device migrates to at least one backup connected device that forms a part of a hierarchy of backup connected devices.
23. A data processing system as in claim 1, wherein one of said connected devices of said hierarchy of backup connected devices is designated as a persistent backup connected device.
24. A data processing system as in claim 22, wherein a connected device's location within the hierarchy of backup connected devices is determined based on a plurality of criteria, including the availability and available processing power of each connected device being considered for placement into the hierarchy of backup connected devices.
25. A data processing system as in claim 24, wherein both long term and short term scores are derived using said criteria.
26. A data processing system as in claim 23, wherein said persistent backup connected device is comprised of a mainframe computer.
27. A data processing system as in claim 1, wherein a database is maintained by at least one publisher connected device, said database storing data related to a project, and wherein a subscriber connected device has access to at least a portion of said project-related data, including project-related data stored in private folders, so long as said publisher connected device has access to the project-related data.
28. A data processing system as in claim 1, wherein a publisher defines a service through the use of a scripting engine.
29. A data processing system as in claim 1, wherein a reporting of services to subscriber connected devices is conducted through a user interface that comprises a browser in the subscriber connected device that views web pages provided by a server of the publisher connected device.
30. A data processing system as in claim 1, wherein said system is COM-compliant.
31. A data processing system as in claim 1, wherein at least one service is provisioned, at least in part, by interoperability with a COM-compliant application program.
32. A data processing system as in claim 1, wherein individual ones of said connected devices comprise middleware software and function as middleware servers.
33. A data processing system as in claim 1, wherein said set of connected devices are logically organized into a plurality of clusters each having a top level connected device (TLCD), and wherein said plurality of TLCDs are coupled together in a ring for propagating system administration information between said plurality of clusters.
34. A data processing system as in claim 33, wherein said system administration information is used at least in part for changing a content of said first list as connected devices connect to and disconnect from said network.
35. A data processing system as in claim 1, wherein at least one of said published services is a data retrieval service wherein a connected device having privileges to access a database employs a query tool to compose a query, wherein and said query is placed at the disposal of a subscriber connected device who does not have privileges to access the database.
36. A data processing system as in claim 1, wherein at least one of said published services is a data retrieval service wherein a connected device having privileges to access a database is responsive to a query composed by a subscriber connected device, who does not have privileges to access the database, to access the database using the query and to return the results of the query to the subscriber connected device.
37. A data processing system as in claim 1, wherein a service offered by a publisher connected device migrates to at least one backup connected device that forms a part of a hierarchy of backup connected devices, wherein a determination of the hierarchy of appropriate backup connected devices is based at least in part on a score derived from long term loads, and wherein balancing of the load on backup connected devices is accomplished at least in part by limiting the number of services that may become active based on a score derived from short term loads.
38. A data processing system as in claim 33, wherein a service offered by a publisher connected device migrates to at least one backup connected device, wherein the backup connected device is constrained to reside within the cluster of the publisher connected device.
39. A data processing system as in claim 1, wherein a reporting service is implemented by a fanout mechanism so as to reduce the load on a publisher connected device.
40. A data processing system as in claim 1, wherein said set of connected devices are logically organized into a plurality of clusters each having a top level connected device (TLCD), and wherein a connected device is enabled to locate a service with certain attributes by a drill down procedure through information about a service provided by a publisher connected device.
41. A data processing system as in claim 1, wherein said set of connected devices are logically organized into a plurality of clusters each having a top level connected device (TLCD), and wherein a connected device is enabled to locate a service with certain attributes by issuing a query that is passed all TLCDs, and TLCDs pass the query to all cluster members connected devices, and those cluster member connected devices that return an output do so to the querier connected device in a manner that is umnediated by said TLCDs.
42. A data processing system as in claim 1, wherein in response to a connected device applying to a publisher connected device for a subscription, said publisher connected device one of selectively grants the subscription or grants the subscription automatically.
43. A data processing system as in claim 1, wherein at least one publisher connected device provides a service that is responsive to commands native to at least one of an Enterprise Resource Planning (ERP) system, a Material Requirements Planning (MRP) system, or a Manufacturing Execution System (MES).
44. A data processing system as in claim 33, wherein said clusters are constructed in parallel as connected devices request connection to the system so as to add connected devices in turn to individual ones of N clusters.
45. A data processing system as in claim 33, wherein said clusters are constructed sequentially so as to add connected devices to one cluster until the cluster reaches a predetermined size, and to then add the next connected device to a next cluster.
46. A data processing system as in claim 23, wherein said persistent backup connected device is comprised of a central server.
47. A data processing system as in claim 1, wherein a reporting of services to subscriber connected devices is conducted by a web server of the publisher connected device that hosts a report in the form of a web page.
48. A data processing system that includes a network comprised of a set of connected devices, individual ones of said connected devices of said set of connected devices comprising a data processor that executes a program for connecting to and disconnecting from said network and for maintaining a first list descriptive of other connected devices and a second list descriptive of at least some user-defined services published by individual ones of publisher connected devices that are members of a first sub-set of the connected devices, individual ones of said publisher connected devices maintaining a third list descriptive of an individual one or individual ones of registered service subscriber connected devices that are members of a second sub-set of connected devices, wherein at least one publisher connected device offers a data retrieval service from at least one database, and wherein at least one service subscriber connected device is registered to receive said data retrieval service.
49. A data processing system as in claim 48, wherein said at least one publisher connected device provides retrieved data to a registered service subscriber connected device upon an occurrence of at least one predetermined triggering event.
50. A data processing system as in claim 48, wherein said data retrieval service automatically moves to at least one backup connected device at least upon an occurrence of the publisher connected device becoming unable to provide the data retrieval service.
51. A data processing system as in claim 50, said at least one backup connected device is one of a hierarchy of backup connected devices, one of which is designated as a persistent backup connected device.
52. A data processing system as in claim 48, wherein said publisher connected device makes a database query on behalf of the subscriber connected device who does not have privileges to access the database.
53. A data processing system as in claim 48, wherein said set of connected devices are logically organized into a plurality of clusters each having a top level connected device (TLCD), and wherein said plurality of TLCDs are coupled together in a ring for propagating system administration information between said plurality of clusters.
54. A data processing system as in claim 48, wherein said publisher connected device makes a database query on behalf of the subscriber connected device, where the subscriber connected device is coupled to said network through a wireless link.
55. A data processing system as in claim 48, wherein said database stores data related to a project, and wherein said subscriber connected device has access to at least a portion of said project-related data regardless of its storage location, so long as said publisher connected device has access to the project-related data.
56. A data processing system that includes a network comprised of a set of connected devices, individual ones of said connected devices of said set of connected devices comprising a data processor that executes a program for connecting to and disconnecting from said network and for maintaining a first list descriptive of other connected devices and a second list descriptive of at least some user-defined services published by individual ones of publisher connected devices that are members of a first sub-set of the connected devices, individual ones of said publisher connected devices maintaining a third list descriptive of an individual one or individual ones of registered service subscriber connected devices that are members of a second sub-set of connected devices, wherein at least one publisher connected device offers a project data management retrieval service providing access to project management data that comprises project-related files and communications, and wherein at least one service subscriber connected device is registered to use said project management data retrieval service and to have access to at least a portion of said project management data regardless of its storage location, so long as said at least one publisher connected device has access to the project-related data.
57. A data processing system as in claim 56, wherein said at least one publisher connected device provides the project management data to a registered service subscriber connected device upon an occurrence of at least one predetermined triggering event.
58. A data processing system as in claim 56, wherein said project data management retrieval service automatically moves to at least one backup connected device at least upon an occurrence of the publisher connected device becoming unable to provide the project data management retrieval service.
59. A data processing system as in claim 58, wherein said at least one backup connected device is one of a hierarchy of backup connected devices, one of which is designated as a persistent backup connected device.
60. A data processing system as in claim 56, wherein said set of connected devices are logically organized into a plurality of clusters each having a top level connected device (TLCD), and wherein said plurality of TLCDs are coupled together in a ring for propagating system administration information between said plurality of clusters.
61. A data processing system as in claim 56, wherein said publisher connected device retrieves project management data for the subscriber connected device, and sends the retrieved project management data to the subscriber connected device through a wireless link.
62. A method for operating a network comprised of a plurality of connected devices, comprising: in each connected device, maintaining a first list descriptive of other connected devices and a second list descriptive of at least some user-defined services published by individual ones of publisher connected devices; in each publisher connected device, maintaining a third list descriptive of an individual one or individual ones of service subscriber connected devices that are registered to receive the service published by said publisher connected device upon an occurrence of at least one predetermined triggering event; logically organizing the plurality of connected devices into a plurality of clusters each having a top level connected device, wherein said plurality of top level connected devices are coupled together in a ring structure for propagating system administration information between said plurality of clusters; and automatically moving the service published by said publisher connected device to at least one backup connected device at least upon an occurrence of the publisher connected device becoming unable to provide the service.
63. A method as in claim 62, wherein said at least one backup connected device is one of a hierarchy of backup connected devices, and further comprising designating one of said hierarchy of backup connected devices to be a persistent backup connected device.
64. A method as in claim 62, wherein said publisher connected device offers a project data management retrieval service providing access to project management data that comprises project-related files and communications, and wherein at least one service subscriber connected device is registered to use said project management data retrieval service and to have access to at least a portion of said project management data regardless of its storage location, so long as said at least one publisher connected device has access to the project-related data.
65. A method as in claim 64, wherein said publisher connected device retrieves project management data for the subscriber connected device, and further comprising sending the retrieved project management data to the subscriber connected device through a wireless link.
66. A method as in claim 62, wherein said publisher connected device offers a data retrieval service from at least one database, and wherein at least one service subscriber connected device is registered to receive said data retrieval service.
67. A method as in claim 66, wherein said publisher connected device makes a database query on behalf of the subscriber connected device who does not have privileges to access the database.
68. A method as in claim 66, wherein said publisher connected device makes a database query on behalf of the subscriber connected device, and further comprising sending a result of query to the subscriber connected device through a wireless link.
69. A method as in claim 66, wherein said database stores data related to a project, and wherein said subscriber connected device has access to at least a portion of said project-related data regardless of its storage location, so long as said publisher connected device has access to the project-related data.
70. A method as in claim 62, wherein said publisher connected device offers a data mining service for data stored in at least one database, and wherein at least one service subscriber connected device is registered to use said data mining service.
71. A method as in claim 62, wherein said publisher connected device offers a data warehouse service for data obtained from at least one database, and wherein at least one service subscriber connected device is registered to use said data warehouse service.
72. A method as in claim 62, wherein said publisher connected device offers a service based on a spreadsheet engine, and wherein at least one service subscriber connected device receives a report upon an occurrence of a change of state of at least one spreadsheet variable.
73. A method as in claim 62, wherein said publisher connected device provides a data retrieval service from at least one database, wherein at least one service subscriber connected device is registered for generating queries to said data retrieval service, and wherein said publisher connected device functions as a proxy to make a database query on behalf of the subscriber connected device.
74. A method as in claim 62, and further comprising accounting for use of a service provided by said publisher connected device.
Description
CLAIM OF PRIORITY FROM COPENDING PROVISIONAL PATENT APPLICATIONS
[0001] This patent application claims priority under 35 U.S.C. 119(e) and 120 from the following Provisional Pat. application No. 60/222,979, filed Aug. 4, 2000; Ser. No. 60/243,154, filed Oct. 25, 2000; Ser. No. 60/256,028, filed Dec. 15, 2000 and Ser. No. 60/267,245, filed Feb. 8, 2001, the contents of which are incorporated by reference herein in their entireties.
FIELD OF THE INVENTION
[0002] These teachings pertain to a system and methods for providing automatic data retrieval, analysis and reporting (RAR) services to interconnected desktop and mobile computer users, wherein the provision and receipt of the RAR services does not depend on central administration or processing.
BACKGROUND
[0003] A number of companies in numerous industries obtain, generate and store large amounts of information (data) which relates to the current and past performance of their operations. For example, in manufacturing industries it is common to characterize work pieces at various stages of production by manual or automatic means, and then store any characterization data in a database. Based on an analysis of this data it may be possible for workers to discover, for example, that corrective actions are required at a certain manufacturing step. By taking such corrective actions, these workers are often able to prevent the loss of valuable finished parts. Such data analysis, and or provision of status indicators, warning messages, or other forms of reporting may be carried out manually or automatically depending, among other things, on factors such as (a) the complexity of the analysis, (b) the ease of delivering the report to the intended worker, as well as (c) the number and complexity of steps which must be taken to retrieve and organize the input data prior to carrying out any analysis. Under very favorable conditions it may be possible to perform all aspects of the data retrieval, analysis and reporting sequence entirely automatically under computer control, and thus to effect any corrective changes automatically by using the report information within a feedback loop whose function is to adjust the operating conditions of one or more manufacturing systems. Under unfavorable conditions, all steps must be performed manually. The labor costs for a company associated with the latter may be considerable.
[0004] As a general problem, sequences which may be characterized as data retrieval, analysis and reporting (RAR) operations are not limited to manufacturing. Examples may be found in numerous service industries (for instance, financial services, health care, and legal services), government administration, and the military. Most RAR operations are carried out in large measure by manual means. As a means to control labor costs, and improve the efficiency of their operations, there is currently a great need among employers in all of these industries for computerized systems and methods for automating their RAR operations. A requirement for any such system is that it must be implemented in a manner which has low inherent operational risk, low cost, high scalability, and a minimal requirement for training of system users.
[0005] It is very common for companies and other organizations to use a combination of large scale, highly integrated computer systems in their daily operations. One common system is an Enterprise Resource Planning (ERP) system. ERP systems are used to provide a means of entering, manipulating and viewing records relating to many aspects of a complex organization B for example financial records, payroll records, inventory records, purchasing records, etc. The records may be stored in one or several databases to which the ERP system has access, and among other things, it is an inherent and critical function of the ERP system to coordinate the movement and updating of database information in order to minimize duplication of effort, and to provide accurate record keeping. For example, a change to an inventory record may require changes to be made to certain financial records, or a change to an inventory record may require a change to be made to an ordering record.
[0006] A further commonly used system is known as MES, or Manufacturing Execution System. The MES is used to track and control the movement of work pieces in a factory. In addition to transmitting instructions and characterization data between users and databases, the MES also generally controls one or more databases used to store historical records relating to (among other things) work piece characterization, machine maintenance, and manufacturing history, and is operative to use these records so as to provide a high standard of manufacturing history, and to ensure that work pieces are manufactured in a repeatable manner, and that they exhibit measured characteristics and performance falling within predetermined acceptable limits.
[0007] Both the MES and ERP systems typically provide a variety of data query and retrieval, analysis and reporting services. Specifically, it is common for many MES systems to feature an analytical subsystem for statistical process control (SPC) whose function is to automatically apply certain statistical tests to characterization and other test data, and make a statistical determination of the condition of a work piece under test, and the machines used to manufacture it. Based on such a determination the SPC subsystem may effect a warning message, or may otherwise alert a worker connected to theMES computer system to an occurrence of a production discrepancy. However, the analytical and messaging functionality found in ERP, MES and other so-called enterprise scale computer systems is generally limited in scope to what the vendor of such a system anticipates his intended typical customer may require.
[0008] To the extent that all organizations are unique to some extent, and may therefore have different methods and requirements, it has become apparent that many enterprise class software systems do not provide adequate functionality to meet the particular needs of many of their users. in other words, the lack of customizability inherent in these systems forces their users to carry out many RAR operations manually.
[0009] An important characteristic of enterprise software systems, such as the ERP system and the MES, is that they are based upon the so-called client-server architecture. Important characteristics of client-server systems include centralized administration, and the use of specialized server computers running specialized software, that is typically not found on machines such as desktop computers, to analyze and store data, and that functions to perform operations on behalf of connected system users (or clients). It is common for a large organization to have numerous servers dedicated to performing certain types of procedures or transactions having similar data access needs, or a similar group of clients. It is also common for servers to be required to exchange data, results and signals amongst one another automatically, and to have access to various databases.
[0010] Numerous integration techniques and protocols exist for creating the necessary linkages between such systems (including, for example, CORBA and DCOM). Adding software, communication linkages and storage capacity, as well as additional server capacity to such a complex system requires expert knowledge, and careful planning and administration. This makes the cost of installing and maintaining client-server based enterprise systems very high, and acts as a disincentive for many organizations to modernize and extend the RAR aspects of their computing systems.
[0011] Further, although enterprise software systems typically manage the exchange of data between databases, and provide users (clients) with access to that data by means of embedded reporting and query tools, they do not provide the clients with general access to those databases. Such access is usually available only to a small number of individuals with special permissions (for example, the vendor, or information technology (IT) professionals with special maintenance responsibilities). This is a significant characteristic and limitation of such client-server enterprise systems, the effect of which is to place data in locations where is it cannot be accessed by ordinary users with unforeseen interests. These and other disadvantages thus greatly diminish the potential value of critical stored data to organizations of all types.
[0012] Recently there has been considerable interest in so-called peer-to-peer file sharing systems. These systems purport to allow users to share information with each other that is stored locally in files on their systems. The principle behind all such systems is that two users may communicate with one another (i.e., exchange digital data) in an unmediated fashion. That is, they need not each connect, as in a client-server system, to a common central server whose role is to effect the exchange. Rather, they connect "directly" to each other. In fact, the connection may be indirect in the sense that the data passes through any number of routers and servers along its way, but these may be considered to be network nodes, and the specific path is not predetermined or fixed. The manner of establishing such connections and transmitting data across them is well known in the art of internet protocol (IP) technology.
[0013] A number of peer-to-peer methodologies and systems have received much publicity. In one system offered by Groove Networks Inc., peer users may create collections of files on their workstations, and then invite or allow others to view those files via a peer-to-peer connection. In certain business environments, especially those in which data are stored on desktop work stations in file form, this offers the potential benefit of allowing users to share selected files with each other. For example, the users may share files relating to a particular work project, without a requirement for a common server connection, or access to a common file server. In another system, known as Napster, users access a common server containing the names of songs indexed by the name and IP address of one or more individuals who may currently have digital copies of the songs stored on their workstations that may be accessed via peer-to-peer connections. An individual seeking a song file therefore carries out a search using the central server to process a query, and then downloads the song file via a peer-to-peer connection from one of the peers identified by the Napster server. This system provides a means for large numbers of users to exchange data files from among a very large collection of files. In yet another system, known as Gnutella, users agree to store files containing text or other content in a common, predetermined folder available to other users via a peer-to-peer connection. Each user then has an identical copy of the Gnutella system running on his workstation, and may issue search commands which are relayed from user-to-user via peer-to-peer connections. The result is a search on each peer contacted for content matching the search string, and the results of the search are presented to the searcher in the form of a list. The searcher may then download the content of interest via a peer-to-peer connection. In yet another class of peer-to-peer systems, known as distributing processing systems (an example of which is SETI@(home), users agree to install certain predefined analysis software on their workstations, and to permit their workstations to download data via a peer-to-peer connection, and subsequently process the data using the analysis software at certain times of the day, or when the software determines that the workstation is not in use. After completing the analysis of the data, the system transmits the result to a central collection point via an IP connection. In yet another system, known as Engenia, users (usually within a single company, and therefore isolated from unauthorized users) agree to expose some or all of the files on their computers to each other via peer-to-peer connections. The purported benefit of this system is that it enables users to search for "knowledge" among company experts on a subject related to a user's work. The method of operation of the system is comparable to the Gnutella system in that the searching process may involve the transmission from one peer to another of the original query string.
[0014] None of the above peer-to-peer systems effectively address the need among corporate users for RAR services, and do not provide access to information (records) stored in databases, nor do they allow users to automate the exchange of information between their workstations and such databases. The Groove system permits the grouping of files, and also permits many groups to be created and shared among many individuals. However, it does not enable users to establish database connections, nor automatically analyze and distribute reports to other users based on such analysis, and as such it has little value for enhancing corporate RAR functionality. Distributed computing solutions such as SETI@home and United Devices provide for users to automatically receive data, locally analyze, and then report the results of their analysis to a central computer; however, such systems are directed at dividing up the processing of large amounts of data using the distributed computing capacity of many users. As such, the users receive data from a central originating point (the fact that it is via an IP connection does not make this a peer-to-peer exchange), they agree only to receive the data, and they do not specify what data is to be received. Indeed, the data they receive has no significance for them, and may have no value to them in isolation from the input and output of the other processors. The local processing is carried out using an analysis program which is provided to them in toto and which they cannot modify locally in any substantial way, and the results are returned in a way they cannot change to a central server (again via an IP connection, but to a central server, not a peer) largely outside of their control and to a predefined location which they cannot change. This again has no value as a means for providing RAR services within a corporate environment. Engenia and Gnutella offer no local data processing capabilities, and they assume that all data are stored locally and in files exposed generally to the peer-to-peer network.
[0015] A number of systems also presently exist whose purpose is to provide executive and expert reporting services within corporate computing environments. Two providers of such systems are Cognos Inc., and SAS Institute Inc. These systems are based on client-server architectures, i.e., all query, analysis and report formation and distribution is carried out on one or more large servers, which would not be considered as "peers" in a network using peer-to-peer exchange. These systems are expensive to install and maintain, they are limited in processing capacity to a large degree, and the result is that they are made available only to a small number of workers. This greatly limits their value as RAR systems because they do not help companies to automate RAR operations and thereby reduce labor costs. Moreover, they also suffer from the problems generally associated with client-server enterprise systems, including poor scalability and low flexibility.
[0016] Another problem inherent in all such conventional data processing systems and techniques is that they are not readily amenable to the inclusion of "non-standard" devices within their respective networks. Such "non-standard" devices can include measuring, sensing and process control systems found in a manufacturing environment, point-of-sale (POS) devices, portable data processors such as personal data assistants (PDAs) having rather more limited memory and processing capabilities, as well as mobile devices that connect to and disconnect from the network using wireless links, such as radio frequency (RF) and infrared (IR) links.
[0017] As such, it can be realized that a long-felt need exists to provide a system and methods that give organizations a capability to realize an efficient and cost-effective implementation of RAR services.
SUMMARY OF THE INVENTION
[0018] These teachings provide a system for providing automated data retrieval, analysis and reporting (RAR) services utilizing an exchange of data in which mediation and processing are accomplished by one connected device (CD) per service who acts as a service publisher, and in which an arbitrary number of connected devices may act as service subscribers. The service publisher controls which users may subscribe to publisher's service. A publisher may create compound services which may themselves subscribe to other services. The number of connected devices is substantially unconstrained by eliminating a consideration of the processing or storage capacity of a central mediating server. The number of publishers, subscribers, services and subscriptions may thus be very large. In response to a connected device applying to a publisher connected device for a subscription, the publisher connected device may selectively grant the subscription based on some criteria, or it may grant the subscription automatically.
[0019] The analysis of data is carried out automatically using procedures specified by the publisher of a service and then reported to subscribers upon trigger events specified by the publisher and/or by the subscriber(s).
[0020] A feature of these teachings is that services remain operative even after the CD on which they initially reside becomes inoperative. This is accomplished by migrating the publication function to at least one other CD when a current publisher's CD becomes inoperative for any reason. A backup of last resort is referred to as a persistent CD.
[0021] Services may be created by the publisher by obtaining data automatically from databases, files, input devices or sensors, which may or may not reside on the publisher's system.
[0022] Subscription methods for RAR services are defined which may be operated from fixed or from mobile devices. Any number of mobile devices may be operated solely as subscribers to RAR services. Preferably the RAR services are provided to subscribers via IP protocols which may involve transmission over a private or a public network. Data retrieval may involve the use of commands native to Enterprise Resource Planning (ERP), MRP (Material Requirements Planning) and MES (Manufacturing Execution System), or other server-based software programs, or the use of commands native to desktop applications present on the publisher's Connected Device (CD).
[0023] A RAR publishing and subscription service is described in which an administrator controls who may belong to the network and what services each system user may access, or not access as the case may be.
[0024] In the preferred embodiment of these teachings the CDs use middleware which has both client (subscriber) and server (publisher) aspects, although a given CD may function only as a publisher, or only as a subscriber.
[0025] The data analysis may include a scripted use of executables and commands from other programs, and the RAR system may make use of desktop COM objects, including COM-compliant spreadsheet programs and models. The output format of a service is specified by the publisher, and the delivered data may be altered by the subscriber at the point of delivery, such as by discarding unwanted data. The subscribers and publisher interact directly through apply/accept-reject procedures, and the exchange of data between users, machines and databases is automated. The triggering of a RAR service is specified by the service owner (push trigger) and/or by the subscriber (pull trigger). For some services both the push and pull trigger conditions must be satisfied before the subscriber receives the service output. All reporting is preferably provided via substantially unmediated or direct connections.
[0026] The system provides a distributed searching capability, a distributed data processing capability, and a distributed administration capability.
[0027] Reports may be used to provide feedback for manual or automatic control systems, and custom database retrieval and reporting services may be created. The system further provides for the creation of scripted database retrieval services using legacy enterprise functions (i.e., use ofERP, MES, MRP reports may form an input to the RAR services.) Also provided is an ability to create scripted analysis services using legacy desktop executables, an ability to create scripted analysis services using a built-in scripting engine, and the creation of non-scripted analysis services using a spreadsheet engine and its associated functionality.
[0028] An aspect of these teachings is an ability to provide data warehouse creation methods using database services and secondary storage, analysis services using warehoused or database service data, and reporting services using warehoused or database service data for use as, by example, feedback for control systems. Distributed database searching is another aspect of these teachings, as is distributed query result processing.
[0029] A feature of the system is an ability to provide connected device (CD) cluster formation and migration of services amongst cluster members and persistent backups.
[0030] Over-subscribed services may be reported using a fan-out technique, wherein the responsibility for reporting the output(s) of a service falls on the subscribers to the service.
[0031] A data warehouse may be created from database retrieval services, and subscribers to the data warehouse service may receive pre-processed query results, of the processing may be performed by the subscriber, or by another CD in accordance with load-balancing considerations.
[0032] Mapped storage (i.e, file servers) may be employed as well by the CDs.
[0033] Project services are definable that provide subscription access to files, and which can themselves subscribe to reporting services.
[0034] These teachings beneficially provide a system in which the constituent connected devices are able to register their presence on the network with other connected devices without intervention from users or administrators, and in which the self-registration can be achieved on a LAN or WAN without prior knowledge of any IP Addresses. The connection status may be updated through a series of permanent connections between connected devices, and in which backup connected devices can be managed through a series of permanent connections between the connected devices.
[0035] In the preferred embodiments of the system services can be delivered without requiring permanent connection between the publisher and the subscriber, and publish-subscribe services can be based on a spreadsheet engine. Database services may be based on the operation of a connected device as a database middleware server.
[0036] It is a feature of the system that the users themselves can customize and extend the functionality of the system by developing their own publish-subscribe services, rather than requiring the skills of a professional software developer.
[0037] The present teachings provide a system and methods for creating and operating a computer network capable of providing data management and computing services such as, but not limited to, file sharing (e.g., static files and executables), data retrieval, data analysis, data reporting, and project management. Services provided by the system include application functionality and event-driven services. The system may be used alone, that is, separate from existing computer hardware, database, and software. The system may also be used in conjunction, though not dependant on, one or more databases and/or non-network devices (either data storage or processing device such as, for example, a database or an enterprise server). An aspect of the system is to provide the above services, some in the context of existing client-server based Enterprise Resource Planning (ERP), MRP (Material Requirements Planning) and MES (Manufacturing Execution System) systems without substantially increasing the computational or storage burden for existing client-server devices. Accordingly, the system provides users, including users of existing client-server based processing systems, additional processing capabilities reliably, at low cost, and without taxing or substantially degrading the performance of existing systems.
[0038] A data processing system includes a network containing of a set of connected devices, where individual ones of the connected devices include a data processor that executes a program for connecting to and disconnecting from the network and for maintaining a first list descriptive of other connected devices and a second list descriptive of user-defined services published by individual ones of publisher connected devices that form a first sub-set of the connected devices. Individual ones of the publisher connected devices maintain a third list descriptive of an individual one or individual ones of registered service subscriber connected devices that form a second sub-set of connected devices. The publisher connected devices provide a service output to registered service subscriber connected devices upon an occurrence of at least one predetermined triggering event, which may be a push trigger, a pull trigger, or a combination of push and pull triggers. A given one of the connected devices may be a member of only the first sub-set of connected devices, or may be a member of only the second sub-set of connected devices, or may be a member of both the first sub-set of connected devices and the second sub-set of connected devices. The set of connected devices are logically organized into a plurality of clusters each having a top level connected device (TLCD), where the plurality of TLCDs are coupled together in a ring for propagating system administration information between the plurality of clusters.
BRIEF DESCRIPTION OF THE DRAWINGS
[0039] The above and other features of these teachings will be understood by reference to following description and drawings, wherein:
[0040] FIG. 1 is a simplified schematic diagram of a data processing network containing a plurality of connected devices in accordance with the teachings herein;
[0041] FIG. 2A depicts a steady-state configuration of the system for an example network of connected device clusters through top level connected devices (TLCDs), the network having a total of 12 connected devices (CDs);
[0042] FIG. 2B illustrates a case where a client CD goes off-line;
[0043] FIG. 2C illustrates a case where a TLCD goes off-line;
[0044] FIG. 3 is an example of a data entry service showing an overlap of output and trigger ranges;
[0045] FIG. 4 shows a connected device having an embedded web server and an associated browser;
[0046] FIGS. 5A-5D show various data warehouse service embodiments;
[0047] FIG. 6 is a block diagram of a connected device of the system of FIG. 1;
[0048] FIG. 7 is a flow diagram showing a method for creating a query-based service;
[0049] FIG. 8 illustrates a technique for providing a composite service in accordance with the teachings herein;
[0050] FIG. 9 illustrates a technique for performing a distributed query in accordance with the teachings herein;
[0051] FIG. 10 depicts a spreadsheet service delivery triggered by a data service;
[0052] FIG. 11 is a flow diagram showing a method for creating a spreadsheet-based service;
[0053] FIG. 12 is an example of a spreadsheet-based hierarchical data format; and
[0054] FIG. 13 is an example of a user interface screen of a connected device in the system of FIG. 1.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0055] By way of introduction, and referring to FIG. 1, these teachings provide a system and methods for providing data retrieval, analysis and reporting (RAR) services within a distributed computer network or system 1 containing servers, databases and connected devices (CDs). The CDs 10
may include any suitable type of data processors including, but not limited to, mainframe computers, supercomputers, workstations, personal computers, portable computers and hand-held computers, as well as measuring systems, sensors and various types of mobile devices having some type of embedded data processor and memory. Connected devices 10 may act as servers, capable of creating and providing (i.e., hosting) data RAR services for other connected devices 10. To avoid confusion with conventional central servers, in the ensuing description the term "publisher" will be henceforth used to refer to any connected device 10
that functions as a server. Other connected devices 10 may act as clients, capable of receiving and optionally modifying reports that they receive from publishers. Further to avoid confusion between (a) connected devices 10 acting as clients with respect to services hosted by publishers and (b) devices connected to central servers, the term "subscriber" will henceforth be used to refer to the former, i.e., those connected devices 10 acting as clients with respect to services hosted by publishers. Connected devices 10 may also function both as servers (publishers) and as clients (subscribers). The system uses direct connections to allow connected devices 10 to exchange data with each other, and client-server connections to allow data exchange between workstations, central file servers and databases. These teachings further provide methods which users of individual workstations may use to deploy data Retrieval, Analysis and Report distribution applications (or services). The functionality of these services resides substantially on the workstation of a service provider who initially creates and publishes a service, except that some aspects of the retrieval, analysis or reporting may be carried out on other computers (by example, on other workstations or central servers) under the control of the service residing on the publisher's workstation.
[0056] The Retrieve, Analyze and Report services are separately provided in the system 1 by one or several publishers, and they may be grouped to form Compound services. For example, an Analysis service may use the output of one or more Retrieval services for input, and likewise a Reporting Service may incorporate the output of one or more Analysis services in its output. It is also contemplated that a Reporting service may use the output of one or more Retrieval services in combination with, or in the absence of, output from one or more Analysis services. All such combinations may be referred to hereafter as RAR services, where it should be appreciated that a multiplicity of services may be present of any one type, or that one or more types of service may be absent or of a trivial nature.
[0057] The methods and system 1 in accordance with these teachings may be deployed on a network in which workstations and servers are connected together via an Internet Protocol (IP), such as TCP/IP, and where some number of workstations are substantially alike in computing power, storage capacity and speed. The system 1 is operative to identify at least one such computer in the network, and to designate this, and possibly other workstations, to serve as "primary backups", such that in the event of failure or loss of power to a workstation functioning as the publisher of a service, control and ongoing provision of the service is automatically transferred to the primary backup workstation, which then assumes the role of publisher for e the service or services provided by the workstation that is no longer available. In certain cases a suitable workstation maybe provided, referred to for convenience as a persistent CD, and this workstation is so equipped as to have the capacity to act as the primary backup for one or more workstations and services.
[0058] The system 1 is preferably administered by a distributed administrator, rather than a central administrator. The role of the distributed administrator is to maintain a special service operative to perform special functions such as, for example, system software upgrades and the maintenance of permitted user lists, access permissions, allowed users and connected devices 10. In the event that the distributed administrator's workstation becomes inoperative, then the administration service (including any associated data and authorities) is transmitted to a primary backup, which may be the persistent CD 10.
[0059] It is also within the scope of these teachings for the administrative service to reside on a central server, although in most cases this is a more expensive, and therefore less desirable, mode of operation.
[0060] In a simplest instance the system 1 may run on a plurality of substantially alike (i.e., in processor speed, memory, and non-volatile storage) connected workstation devices. To install the system 1 on such a network (it being assumed that all workstations are previously connected via a network protocol, such as TCP/IP), the workstations or other computing devices (i.e., the connected devices) are first loaded with identical system-level software, or with a sub-set of the system-level software. The software executes automatically upon installation and registers each connected device 10 by adding it to a list of valid connected devices on the network, which list is preferably stored on each connected device 10, along with information describing the processing characteristics of each connected device 10. Those devices so connected, having substantially similar processing power, may be considered to be "peers"; however, there is no requirement that all connected devices 10
should fall into this category. For example, their processing power may be greater (as in the case of a super computer), or less than (as in the case of a mobile device) that of the typical connected device 10. Therefore, not all connected devices 10 may be suitable primary backup devices. Moreover, not all connected devices 10 may have the capability to operate as service publishers, but rather only as subscribers. An important characteristic of the system 1 is that the automatic assignment of primary backup machines by the publisher systems takes into account the known computing power, and loading (i.e., the number of services published, and subscription rate) of other connected devices 10 which may be candidate backup machines.
[0061] In the simplest installation of the system 1 there need be no external sources of data, i.e., all data in the system 1 originates from files or keyboard input sourced from publishing devices in the network of connected devices 10. To create a simple instance of a RAR service in this case a publisher uses system 1 commands to specify that a service S1
is operative to accept keyboard input and store it in a memory location with an assigned name M1. The publisher may optionally specify a "push trigger" for the service, such that when M1 changes, its contents are transmitted via a connection to any subscribers to the service S1. Other types of trigger events can include, by example, timing events, "buffer full" events, "specified value" events and many other possible events, as well as combination of logical combinations of events. In this simple case, Retrieval means "obtained from a keyboard buffer", there is no Analysis, and Report means transmit the buffer contents. Similarly, Retrieval may include obtaining some or all of the data contained in a text or other file, Analysis may mean "load into a spreadsheet and prepare a chart", and Report may mean "transmit the chart each time it is updated to all subscribers". As another example of a simple RAR service, Retrieve may mean "obtain a named file from the local disk drive", Analyze may mean "no processing", and Report may mean "transmit a copy of the file to any subscriber requesting the file", the latter being an example of a file sharing service. A variety of such services may thus be created and published by suitable connected devices 10. The "no processing" events may be specified for any Retrieve, Analyze or Report step, so that a service may only Retrieve, or only Analyze, or only Report, or specify any other combination (e.g., RA, RR, AR) meaningfully.
[0062] In the system 1 there are two classes of triggers which may be applied to any service type, including compound services. A "push" trigger is specified by a publisher, and is any event (such as, by example, a time, a change in the contents of a file, or a change in the status of a variable) which the publisher can sense and specify, which initiates the RAR service, and that causes the publisher's service to execute. A "pull" trigger is specified by a subscriber, and is any event which the subscriber can sense to initiate the RAR service and cause the service to be executed. Combined triggers may also be used, such that both a push and pull trigger must be TRUE in order for a transfer of data to be effected. One important class of triggers uses COM events generated by COM compliant desktop software applications (by example, Microsoft Excel, Word, or PowerPoint), or COM compliant enterprise software applications running on a server.
[0063] Other techniques for introducing data to the connected devices 10
from an external source may involve the use of at least three types of Data Retrieval Services. The three presently preferred Data Retrieval Service modes are (a) direct database query services, (b) indirect query services, (c) sensor data services. To effect mode (a), a connected device 10, such as a workstation connected to an existing database, creates a suitable database query. Such queries may be simple or complex. An example of a simple query is "download a specified data record"; another example is "download any newly created record of a certain type". Many other such queries are possible. In such cases, the specified data records are downloaded to the publisher's device and stored in a file or memory buffer. To effect mode (b) a publisher with a suitable connected device 10, which is also connected to a second computer network running an enterprise system such as a MES or an ERP system, creates a service which executes one or a sequence of commands using the native instruction set of the MES or ERP system. This causes the system 1 to retrieve and download certain records (e.g., a report) generated by the MES or ERP system to the publisher (acting as a client with respect to the ERP or MES). The Indirect Query Service may then optionally extract certain parts of the downloaded report, and subsequently store these locally for later transmission to subscribers to the Retrieval service. To effect mode (c), the sensor is registered as a valid connected device 10, and is the publisher of a "sensor service" that continuously or periodically updates a simple report containing a digitized measurement result (e.g., the temperature of an oven or the speed of a conveyor belt). A Sensor Data Service then subscribes to this sensor service, providing a pull trigger which causes the output of the Sensor Service to be transferred to local storage on the connected device 10 publishing the Sensor Data Service, where it may be further processed and combined with Sensor Service data from other sensors, and which may then form part of a complex Sensor Data Service report to which other connected devices 10
may subscribe. This mode of operation thus provides, by example, the basis for a large scale environmental monitoring system.
[0064] The foregoing relates to actions taken by the publisher of a data Retrieval service. As explained, the publisher may or may not elect to specify a trigger event which causes the service to execute (i.e., download and store data). The subscriber to a data Retrieval service generally has the option to choose to use some, or all of the data made available by the publisher. It is noted that in the preferred implementation all data specified in the service output is delivered to the subscriber. The subscriber then decides what data to use and what to ignore. The service metadata describes the data provided by the service, and the subscriber uses an interface to this metadata to specify what should be used.
[0065] The subscriber may also specify a trigger event (for example, a time of day), the occurrence of which causes the data to be transferred to the subscriber. If the service was specified by the publisher to be a "push" service, then the transfer is effected only when the subscriber trigger is TRUE and the publisher trigger is TRUE. Otherwise (in the absence of a push trigger), the transfer is effected when the subscriber's trigger is TRUE. This logic governing such compound trigger events applies also to Analysis and Report services.
[0066] In any of the services considered herein, the term "local storage" of data may include storage on local media (e.g., a disk drive), or on "mapped remote storage devices" such as a file server.
[0067] Data transferred to a Retrieval service subscriber is preferably analyzed using one or more analysis programs resident on the connected device 10of the publisher or the subscriber, and processing preferably takes place substantially on the publisher's, or the subscriber's connected device 10 in order to avoid taxing the processing capability of a central server or processor. Thus, for example, the publisher may create an Analysis service which effects processing of certain data on the publisher's connected device, with the output of the service (e.g., a text or spreadsheet file) being stored locally or on a mapped storage device. Alternatively, the publisher may specify that the processing is to take place on some other connected device, for example, that of the subscriber.
[0068] All nontrivial data Analysis services include steps of obtaining input data (the output of a data Retrieval service to which the Analysis service publisher is a subscriber), processing the data, and creating an output object (e.g., a text or graphic file, or a spreadsheet) stored on the connected device 10 of the publisher (or on a mapped file server to which the publisher has read and write access).
[0069] Analysis Services may be effected preferably in one of two ways, as governed by the manner of processing. In one mode the service uses a COM compliant software program for processing, and in one preferred implementation the system 1 is made to be COM compliant. It is in the nature of COM compliant software programs that one COM compliant program may exchange data with another COM compliant program in a flexible manner that is well-known in the art of application programming. It is further in the nature of COM compliant programs that one COM compliant program may cause another to execute certain of its native functions. Using these features of COM compliant programs, a publisher may automatically transfer data from an output of a data Retrieval service (or other data source) directly into a COM compliant application, such as a spread sheet (by example, a spreadsheet created by means of MS-Excel). By transferring some or all of the subject data into specified cells of the spreadsheet, the Analysis service (via the processing specified in the spreadsheet) causes a result (such as a value, chart, or message) to be generated. This generated result may then be stored and viewed in the spreadsheet, and may subsequently be used by a Reporting service for output. Note that this is not equivalent to outputting the entire spreadsheet, but rather provides a means to selectively output certain values (such as cell values) or embedded objects (such as charts), or some combination thereof.
[0070] In a second mode of operation, the publisher of the Analysis service may use an executable application that is not necessarily COM compliant. In this mode the publisher takes certain steps using a "recorder" feature of the system 1 to create a sequence of steps, preferably in the form of a "script". Execution of the script then generally operates by: (a) Starting the executable analysis application (for example, a program written in Fortran, and stored in executable form, or a Windows application featuring a Graphical User Interface GUI)); (b) Loading the subject data into the application; and (c) Operating on the data in some way in order to produce an analysis result. The manner of data input and result output employs files which may be transferred in toto. Although this manner of transfer of data and output is less flexible than in the COM compliant mode described previously, it may be preferable in cases where it is desired to use an existing analytical procedure which is not COM compliant, thereby realizing one of the cost saving benefits that accrue from the use of these teachings. The Analysis service may be triggered to run automatically using one or a combination of push and pull triggers as discussed previously.
[0071] The system 1 features several presently preferred modes for providing data Reporting services. The function of all such services is to effect an automatic transfer of information between a connected device 10 controlled by a publisher and a connected device 10 controlled by at least one subscriber subject to a trigger event. The information is assumed to be in the form of digital data prepared by a data Retrieval or Analysis service. Trigger events may be specified by the publisher (push trigger) or subscriber (pull trigger), or both (AND or OR). For example, a trigger event may be specified to be one of the following: (a) a change in a computer file on either the publisher or subscriber device, (b) the occurrence of a date, or time of day, (c) a request made by a subscriber to a publisher, (d) a change in a database record, (e) a change in the state of a sensor, (f) and the prior execution of a Retrieval or Analysis service on either the publisher or subscriber's connected device.
[0072] One aspect of the system 1 is that a subscriber to a Reporting service may select all, or only a part of the report information exposed by the publisher of the service to transfer to subscriber's connected device. Thus, by example, if the publisher prepares a Reporting service exposing a spreadsheet file for output, then the subscriber may specify that the entire spreadsheet, or that only certain spreadsheet cells, are to be transferred to the subscriber's device upon execution of the service.
[0073] These teachings also provide methods for automatically creating data warehouses. For the purposes of these teachings a data warehouse is a collection of data automatically culled or compiled from one or more data sources, such as, by example, databases, or a collection of computer files, or from one or more sensors. The data warehouse then provides a convenient and secure source of data for certain specialized analysis and reporting applications. The culling (i.e., selection based on specified criteria) and compilation (i.e., the joining, or reorganization of culled data) may be best effected by means of one or a multiplicity of data Retrieval services to obtain data meeting specified criteria, and then directing the data thereby retrieved to a database. The organization of the database is controlled by the data Retrieval service subscriber (who may also be the service publisher), hereinafter referred to as a "warehouse publisher". The system 1 provides methods well known in the art of database technology whereby the warehouse publisher may specify the organization ("schema") of the warehouse. The warehouse publisher has permission to write data to, and optionally to read data from the warehouse database. Either the publisher, or the distributed network administrator, controls a list of permissions whereby third parties have read and write access to the warehouse database. It is not required that those with such access subscribe to, or operate within the system 1.
[0074] The system 1 may be used to effect automatic Statistical Process Control (SPC) by combining data Retrieval, Analysis and Reporting services. The implementation of such an SPC system may be in such a manner that all required RAR services reside on a single connected device 10, or on many connected devices 10. In some situations, the amount of data generated over time by one or more sources may be very large. In such cases it may be advantageous to distribute the RAR service among several connected devices 10 in order to effect timely processing.
[0075] The system 1 further features Project Management service methods whereby groups of individuals may work collaboratively on one or more common tasks involving the ongoing analysis and reporting of data and results in a particularly effective manner. To create such a service using the system 1 the user of a suitable connected device 10 prepares a compound data Reporting service which, like any Reporting service, specifies certain files, records and other information that the user wishes to publish. The user may also specify one or more other RAR services. Subscribers to the Project Management service may receive both the specified files, as well as the information associated with any of the specified other services. In this way, a group of individuals may be automatically provided with a common information concerning a project in which they are participants. Further, the system 1 features methods whereby the Project Management service subscribers may exchange email, tasks, schedule events and instant messages with their co-subscribers which are automatically added to a Project database residing on the publisher's connected device, or another connected device 10 acting as a primary backup for the Project Management service.
[0076] A feature of the system 1 is the ability to ensure that all CDs 10
have up-to-date information regarding the status of all other CDs 10. This is achieved through the use of fixed connections within and between clusters 11 of CDs 10 (see FIG. 2A). These connections are based on Client and Server Sockets (e.g., using AstaClientSocket and AstaServerSocket components), i.e. they use sockets and TCP/IP. Client and Server Sockets and the details of their use are well known in the art of network connection technology.
[0077] The creation of the clusters 11 is based on the concept of a group of Top-Level CDs (TLCD). Each CD 10 can operate as both a client and a server and the clusters 11 operate on the basis of configuring the TLCDs as servers with all other CDs 10 operating as clients. This partitioning of CD 10 operation is for the purpose of system management, and does not imply that the "client" CDs 10 are restricted in functionality.
[0078] If one has a network of N computers, then the number of TLCDs is dependent on a parameter D that can be changed by the system administrator, where D is the number of CDs 10 per cluster 11. If Nc is the number of clusters 11 then:
[0079] Nc=Round(N/D).
[0080] A default value for D may be specified at startup as a feature of the system 1 design.
[0081] Another parameter that is pre-defined in the system 1, but that can be altered by the administrator, is the default number of TLCDs, NT.
[0082] After the system 1 has been established the number of TLCDs is equal to Nc.
[0083] An extreme example has D=N, giving one large cluster 11. Multiple clusters 11 provide a greater level of redundancy, minimizing the amount of re-connection activity if a cluster server goes off-line. It also provides a possible starting point for organizing backups for services, that is, for the migration of services within the system 1, as described in further detail below, and for re-connection strategies that minimize network activity.
[0084] The preferred steady-state configuration of the system 1 is shown in FIG. 2A, for an example network with 12 CDs. In this case a ClientSocket (CS) on CD#10 connects to a ServerSocket (SS) on CD#1. The key functionality of the Client and Server Sockets that is used to maintain the connection status is:
[0085] ServerSocket: Client Connect and Disconnect events
[0086] ClientSocket: Disconnect event (i.e. when the Server forces a disconnect)
[0087] The detailed use of these Sockets in maintaining the global status is described in the following sections.
[0088] It should be noted that there is no requirement for an equal number of CDs 10 in each cluster 11. Assuming that all CDs 10 are on-line, typically there will be one cluster 11 with a CD count not equal to D. For example, if there are 100 connected devices 10 on the network, and a specified cluster 11 size of 7, then there will be 14 clusters, 13 of which will have 7 members with the 14th having 9 members.
[0089] The cluster 11 configuration based on system 1 status monitoring provides a possible means of organizing backups for published services, although it is not a requirement.
[0090] There are a number of ways to organize the assignment of the client CDs 10 to each cluster 11. The example depicted in FIG. 2A shows the lowest CDs in the hierarchy being assigned to the highest-ranking TLCD.
[0091] This section describes (i) the actions taken on connection and disconnection of individual CDs 10 and (ii) the actions taken to organize the CDs 10 into the previously described cluster 11 architecture.
[0092] An important aspect of the system 1 is that a newly-connected CD 10
should, without user intervention, be able to (i) detect the presence of other CDs 10 and (ii) to register its own presence with those other CDs. Two distinct network scenarios exist (i) a network composed of computers connected together without the presence of a mediating central server and (ii) a network composed of computers connected together through a central server.
[0093] The preferred transport protocol of the system 1 is TCP/IP and, in order for the CDs 10 to communicate, this requires that each CD have access to the IP addresses of all other CDs. A complication is that the IP address of a workstation on a Local Area Network (LAN) is normally dynamically allocated when the workstation logs onto the LAN server.
[0094] On a Windows network there exists functionality to allow computers to gain information on other computers on the network without having pre-existing knowledge of any IP addresses. Specifically, on a Windows network, the system 1 uses Mailslots and Named Pipes (well known in the art of network technology) to allow CDs 10 to locate each other on the network.
[0095] Another important aspect of the system 1 is that the CDs 10 can locate each other, and the system 1 can auto-configure, without requiring any IP address information to be supplied by a user or administrator. Similar functionality exists for networks based on Unix-type servers (i.e., UDP and Named Pipes).
[0096] A Mailslot is created within each CD 10 as it starts up. An ALMailslot Delphi component is an example of a component that can be used for this purpose. ALMailslot includes a Broadcast function that takes a simple string of characters as an argument, and an OnNewMessage event which fires when a new Mailslot message is received.
[0097] The string of characters, i.e. the text, which is broadcast in the startup Mailslot message contains the following key items:
[0098] (i) an identifier (message-type identifier) indicating that the message is a request for status information;
[0099] (ii) the local IP Address;
[0100] (iii) the operating system of the sending computer (9x or NT);
[0101] (iv) the number of records in the local CDT; and
[0102] (v) the install Date and Time.
[0103] The text message is built by converting any non-string-type parameters to strings and concatenating them into a single larger string that forms the message to be sent, with each sub-string being separated by a colon (":") or similar character. For example, the string "1:195.10.1.2:9x:0:2001-4-4 14:30:00" contains information that this is a request for status information (i.e. the "1") from a CD 10 that is online at IP Address 195.10.1.2, that the operating system is Windows 9x (i.e. 95/98/ME), that there are no entries in the local CDT and that the install date and time is Apr. 4, 2001 at 14:30.
[0104] The OnNewMessage event procedure in the Mailslot passes the following parameters:
[0105] (i) the ComputerName of the computer that sent the message;
[0106] (ii) the UserName of the logged on user on that computer; and
[0107] (iii) the message text itself.
[0108] This information is sufficient to identify the remote computer on the network.
[0109] A feature of Mailslot messages is that the sending CD 10 receives its own message. The CD 10 includes the ability to distinguish these from messages sent by remote CDs, as described below.
[0110] When a CD 10 is first installed and started it has no records in its local CDT of any other CDs 10 on the network. The following pseudo-code describes the steps taken during initial startup:
1
Procedure Startup Create Mailslot If Operating System = Windows NT or Windows 2000 then Create Named Pipe Server Start CD Timer (see next section) Retrieve record count from CDT If recordcount = then do the following Determine the local IP Address Build Mailslot message (see section A above) Broadcast the Mailslot message End of recordcount conditional section End of Startup procedure
[0111] A description of the use of Named Pipes within the system 1 is described below.
[0112] When a Mailslot message is received by a CD 10, it is handled in the OnNewMessage event procedure as follows:
2
Procedure OnNewMessage Read message text Extract the message-type identifier (MTI) Extract the IP Address If extracted IP Address = local IP Address then exit (i.e. message origin = local) If MTI = request for online status information then do the following Create new Mailslot message with MTI = "Reply from online CD" Add local IP address, operating system etc to the new Mailslot message Extract Computer and User Name from received message Check local CDT for the Computer Name If Computer Name not present then Add a new record to the local CDT and update the IP Address, ComputerName etc Else if Computer Name present then Update the IP Address End of Computer Name conditional End of new CD online conditional
[0113]
3
If MTI = Reply from online CD then do the following Extract Computer and User Names from message Add a new record to the local CDT and update the IP Address, ComputerName etc End of online CD reply conditional End of OnNewMessage procedure
[0114] Using the above procedures, each new CD 10 provides information on its IP Address and Computer Name to all other online CDs 10, thereby allowing them to register the new CD 10 in their local CDT. Each of the online CDs 10 in turn sends a reply Mailslot message to the new CD 10
with the equivalent parameter settings. In this way local CDTs with a record of all CDs 10 on the network are created without there being a need for any initial knowledge of IP Addresses.
[0115] At least two startup management sequences may be employed by the system 1:
[0116] (i) the above steps are carried out during the launch of the CD 10
application; or
[0117] (ii) a timer-based approach is used, where the CD 10 is launched and a timer is created within the CD 10. This timer controls the broadcast event, launching a broadcast at regular pre-defined intervals. The presently preferred embodiment is that where the broadcast is carried out as the CD 10 is started up.
[0118] Each CD 10 has an associated timer that starts when the CD 10 is launched, hereafter referred to as the StartupTimer. A suitable timer component is the TTimer component that is supplied with Delphi. The function of a timer in general is to carry out a specified action at regular, pre-specified intervals. The StartupTimer is configured to trigger X milliseconds after startup, and every Y milliseconds thereafter, where Y>X.
[0119] The use of the StartupTimer for start-up management when a CD 10 is first installed is described in further detail below with regard to initial startup when there are no replies from other CDs 10.
[0120] When a CD 10 is first installed and started it has no knowledge of any other CDs 10 on the network, and other CDs 10 have no knowledge of it. After the initial Mailslot broadcast there is the possibility that there will be no reply from another CD 10. This can occur due to the following two scenarios:
[0121] (i) the CD 10 is the first to be installed on the network; or
[0122] (ii) there are other CDs 10 on the network, but they are all off-line.
[0123] The number of replies is checked within a StartupTimer OnTimer procedure. This triggers X milliseconds after the CD 10 has started up. The sequence of actions is described in the following pseudocode:
4
Procedure OnStartupTimer for Time = X Count number of records in CDT If count = 0 then do the following Set local Rank = 1
Enumerate the domains on the network Add domain names to the Domains Table (DT) Enumerate the computers on the network Add the computer names to the CDT with Active = false Reset the StartupTimer interval to Y End of count = 0 conditional End of OnStartupTimer procedure
[0124] The new timer interval Y is preferably configurable by the system administrator.
[0125] The aim of the above sequence of actions is to provide a basis for the new CD 10 to continue querying the network using individual Mailslot messages, rather than using global broadcasts at regular intervals, and thus beneficially minimizes the amount of network traffic.
[0126] The functions used to enumerate the domains and computers are described below. The enumerated computers, which are computers that are on the network but which do not have the software installed or running, are added to the CDT with Active=false, i.e. they are initially configured for the case where there is no CD 10 installed on them (in other words, these computers are not yet "connected devices").
[0127] The system 1 therefore configures the new CD 10 to continue querying the network to establish its registration, rather than have existing CDs search for new CDs.
[0128] Mailslot messages can be transmitted using a number of different formats. As well as the broadcast format used in the new CD 10 startup procedure, a format exists to transmit to a specific computer name on a specific domain name. The following pseudocode describes the actions associated with the ongoing network queries:
[0129] Procedure OnStartupTimer for Time=Y
[0130] Retrieve B (the cycle size)
[0131] Cycle through B computers in the list of enumerated computers
[0132] For each of the B computers transmit the Mailslot message requesting status update
[0133] End of OnStartupTimer procedure
[0134] The cycle size B is the number of computers the new CD 10 will transmit the Mailslot message to every time the timer triggers. For example, if there are 100 computers listed in the CDT and B=10, then the CD 10 will start with the first 10 computers and transmit the Mailslot message to each in turn. When the timer next triggers the Mailslot message is sent to the next 10 computers in the CDT, and so forth until completed.
[0135] The parameters B and Y can be set to cover a wide range of querying strategies, with the two extremes being:
[0136] (i) B=N (where N=Number of computers) and Y is relatively long; or
[0137] (ii) B=1 and Y is relatively short.
[0138] The first of these cases is similar to the broadcast case, where the timer triggers relatively infrequently and all computers on the network have the Mailslot message transmitted to them. The preferred implementation is the second case, where single Mailslot messages are transmitted relatively frequently.
[0139] The sequential Mailslot transmissions are continued until (i) a reply message is received from an established CD 10 or (ii) a status request Mailslot message is received from another CD 10.
[0140] The presence of a licencing sub-system provides a convenient way of establishing the maximum possible size of the system 1 on a network, i.e., the maximum number of CDs 10. A set of Delphi components providing suitable licence control functionality is OnGuard from Turbopower software.
[0141] A typical implementation of licencing technology such as OnGuardJ involves a hidden key within the compiled software application, together with a serial number and an associated modifier, such as the company name. For the licencing condition to be met, the combination of key, serial number and modifier must match. Restrictions can be included in the software application that come into force if the licencing condition is not met. Examples include preventing the software from running, or restricting the functionality.
[0142] Within the context of the system 1, an additional modifier can be added--the maximum allowed number of CDs 10. As additional CDs 10 beyond the permitted number are detected, they are added to the CDT, but are marked as Active=False. This prevents connections between unlicenced CDs and any other CD 10, but ensures that if the licence count is increased then the re-configuration of the system 1 will be achieved more rapidly.
[0143] With regard to establishing the CD 10 configuration, consider first the situation where the system 1 is being installed on a network for the first time. The steps described assume that a CD 10 remains on-line after start-up and as the other CDs 10 are installed and started up.
[0144] The cluster 11 configuration shown in FIG. 2A contains a ring of TLCDs, with each TLCD forming the primary server in a series of client-server clusters 11. Each CD in the system can be viewed as having a "parent" CD, and this parent is recorded in the CDT. The establishment of this topology is presently preferred, as it provides an efficient connection strategy for immediate notification of any connect/disconnect events.
[0145] The first task during startup of the system 1 is the establishment of the TLCD ring. The following steps describe the establishment of connections between CDs 10 as they start up (NT is the pre-specified number of TLCDs):
[0146] CD1 Starts up--no reply to Mailslot broadcast, set CD1 Rank=1
[0147] Update CDT (Cluster ID=Rank, Rank)
[0148] CD2 Starts up--reply from CD1, CD1 receives CD2 Mailslot message. Set CD2 Rank=2.
[0149] CD2 Client Socket (CS) connects to CD1 Server Socket (SS)
[0150] Update CDT (ParentIdentifier field, Cluster ID=Rank, Rank)
[0151] CD3 Starts up--replies from 1 and 2. Set CD3 Rank=3.
[0152] If NT>=3 then CD3 Client Socket connects to CD2 Server Socket
[0153] CD1 Client Socket connects to CD3 Server Socket
[0154] As each TLCD is incorporated into the system 1 a new record is added to a Clusters Table 12.
[0155] At this stage the system 1 has formed into the first closed ring of CDs 10, i.e., 3 CDs, and any further TLCDs will be incorporated into this ring. The disconnect/connect sequence is as follows:
5
CD4 Starts up - replies from 1, 2 and 3. Set CD4 Rank = 4. If NT >= 4 then do the following CD4 Client Socket connects to CD3 Server Socket CD1 Client Socket disconnects from CD3 Server Socket CD1 Client Socket connects to CD4 Server Socket End of NT conditional
[0156] When the Nth CD starts up and N>NT then the sequence to attach CDs to the TLCDs begins:
[0157] CDN Starts up
[0158] If N>NT then CDN connects to TLCDn.
[0159] CDN+1 Starts up
[0160] If N+1>NT then CDN+1 connects to TLCDn+1.
[0161] This sequence demonstrates that the CDs 10 are attached to each TLCD in turn, i.e. the clusters 11 are constructed in parallel, thereby ensuring that the CD clusters 11 are formed in a balanced manner.
[0162] The construction of the system 1 is controlled by two parameters (i) the default number of TLCDs, NT and (ii) the cluster size D. As the system 1 is constructed the details of the connections are determined by NT. At some point the number of CDs in each cluster 11 will equal D and the number of clusters 11 will equal NT.
[0163] If a new CD 10 is added at this point two choices are available:
[0164] (i) add the CD 10 to an existing cluster 11; or
[0165] (ii) increase the number of TLCDs, i.e. insert the new CD 10 into the TLCD ring. The preferred implementation is the latter procedure.
[0166] An alternative method of building the system does not require the number of TLCDs to be specified, only the cluster size D. In this case CD1 is the first TLCD as before. Unlike the previous approach, CD2 is not the second TLCD, but the first cluster client attached to CD1. Sub sequent CDs are added to the cluster until D is reached. The following CD is then the second TLCD, and so on. Therefore, each cluster is completed up to the maximum specified cluster size D before the next cluster is started.
[0167] The previous implementation is the preferred one. For the simple assignment of seniority based on installation time it automatically ensures that all TLCDs are in the central ring without having to disconnect and reconnect CDs 10.
[0168] As CDs 10 are installed on the system 1 it is possible for "orphan" groups of CDs to be established, unless a mechanism exists to prevent this. Orphan groups would be established if new CDs 10 are added to the network while all member CDs of the existing installed group are off-line.
[0169] To protect against this, the system 1 provides a low-network-load polling mechanism that uses either (i) Mailslot messages or (ii) Named Pipes (refer to the description on the Startup in a WAN for further details on Named Pipes).
[0170] The polling mechanism is based on:
[0171] (i) the list of enumerated domains and computers that is obtained by any CD 10 that starts up on a network, where no other CDs are on-line; and
[0172] (ii) the Startup timer that initializes when the CD 10 starts up.
[0173] The enumeration of the computers includes the retrieval of the operating system information. Only those computers currently marked as Active=False are polled, since this setting indicates that application has not been detected at that location.
[0174] The timer runs continuously while a CD 10 is on-line. Each time the timer event triggers the CD 10 sends a request for status information to at least one of the Active=False computers. Each time the timer fires the next computer on the list is used as the recipient. Two situations apply:
[0175] (i) if the computer is on the current broadcast domain then send a Mailslot message; or
[0176] (ii) if the computer is on a different broadcast domain, and its operating system is NT or 2000, then use the system Named Pipe to attempt a connection.
[0177] The system 1 also provides a feature whereby a user can browse for computers on the network and select one or more as message recipients. Such user intervention can be used as a last resort for situations where orphan groups have failed to be linked automatically.
[0178] In practice, the existence of such orphan groups is unlikely, since the start-up of a new CD 10, while at least one CD 10 from each group is on-line, triggers a synchronisation of the CDTs.
[0179] On a Windows network the operating system provides functions for enumerating domains and computers on the network. These functions include the WNetOpenEnum and WnetEnumResource functions.
[0180] The system 1 provides a means for an administrator to specify computers on the network which have the system software installed. This is provided during the installation in the form of a network browse dialog.
[0181] When a CD 10 re-starts, the event is registered as being a re-start by counting the number of records in the CDT (which should be greater than zero).
[0182] There are two possibilities that would lead to the re-start of a CD 10:
[0183] (i) the computer has been powered-down or the CD closed during the current 24 hr period; or
[0184] (Ii) the computer has been powered-down overnight (or longer).
[0185] With respect to fixed IP addresses, if each CD 10 has a permanently assigned IP Address then the re-connection steps are relatively simple, as the IP addresses stored in the CDT will still be valid. In this case the startup is described by the following pseudocode:
[0186] Retrieve ParentID from CDT
[0187] Retrieve IP Address of parent from CDT
[0188] Establish Connection
[0189] With respect to Dynamic IP addresses, if the IP address of the CD 10 is allocated dynamically on startup then the re-start procedure is more complex, since the current IP addresses in the CDT might not be valid.
[0190] During start-up, the CD 10 retrieves the LastLogoffDateTime from the CDT. The connection actions initiated by the CD 10 during start-up are conditional on whether the LastLogoffDateTime is within the current day. This is described by the following pseudocode:
6
IfLastLogoffDateTime is within the current 24 hr period Then Attempt to re-start using connections Else if LastLogoffDateTime is before the current 24 hr period Then Attempt to re-start using Mailslot messages End of LastLogoffDateTime Conditional
[0191] If the CD's last logoff was within the current 24 hr period, then there will be a high probability that the IP Addresses currently in the CDT will still be valid. Therefore connection attempts are made on the basis of the existing IP addresses.
[0192] The pseudocode for re-starts using connections and Mailslots is given below.
[0193] As for the Initial Startup case, the Startup timer is initialized with a timer delay=X. A high-level view of the re-start sequence is as follows:
[0194] (i) Start the CD 10
[0195] (ii) Start the Timer
[0196] (iii) Attempt connections and/or mailslot messages
[0197] (v) During the Timer event check connection status
[0198] (vi) If no connection is made, then increment ClusterlD and start again
[0199] The details of this procedure are given in the following pseudocode examples:
7
Procedure ReStart with Connection Retrieve the local ClusterID Filter the CDT where ClusterID = local ClusterID and order by Rank Store the highest Rank value in MaxRankTable variable Start Loop Retrieve last known IP Address of first CD in list (i.e. highest rank) Attempt to connect using ClientSocket If Connection Error then Move to next ranking CD on list and repeat cycle End Connection Error Conditional End Loop when a connection is successful or all CDs have been attempted End of Procedure ReStart with Connection
[0200] A failure to connect may be caused by either: (i) all other members of the cluster 11 are currently off-line, or (ii) all other members of the cluster 11 have new IP Addresses. If there is no successful connection during the above cycle, then the next step involves sequential Mailslot messages (within the cluster 11) as follows:
8
Procedure ReStart with Mailslot Messages Start Loop Retrieve ComputerName and DomainName of first CD in cluster list Send Mailslot to CD Move to next CD on list and repeat End Loop End of Procedure ReStart with Mailslot Messages
[0201] The time delay X of the StartupTimer is selected to allow time for any Mailslot replies to be received. The Mailslot messages contain the Rank of the sending CD 10. The re-start CD 10 has a variable that holds the highest rank value obtained from Mailslot replies: this is initialized to MaxRank=0. In the Mailslot OnNewMessage event the following pseudocode applies:
9
Procedure OnNewMessage Check connection status If connected then exit Extract Rank value from message If Rank = MaxRankTable then connect to Rank using ClientSocket If Rank > MaxRank then MaxRank = Rank Wait for next Mailslot message End Procedure OnNewMessage
[0202] As each message is received the CD 10 checks its current connection status. If an earlier Mailslot message has resulted in a successful connection then all other messages are ignored.
[0203] An alternative implementation omits the attempts to re-connect to each CD 10 using the Client and Server sockets and instead directly loops through the Mailslot messages.
[0204] After the time period X has elapsed, the timer OnTimer event triggers and the CD 10 checks its current connection status. If there is still no connection then the actions described in the following Cluster Re-Start are carried out.
[0205] With respect to CDT update, the following are fields that are updated when a CD 10 re-starts:
[0206] LastLogonDateTime
[0207] ParentID (i.e., the CD 10 that is acting as a server to the re-starting CD)
[0208] When a CD 10 re-starts, there exists the possibility that all other member CDs 10 of the cluster 11 are off-line. This will be detected when the timer event fires, as described in CD Re-Start section. In this case one strategy would be to re-start the re-connect actions, but targeted at the next cluster 11 in the Clusters table (CT). The preferred implementation is to have the re-connecting CD 10 act as the nucleus for re-establishing the original cluster 11.
[0209] Each cluster 11 can be viewed as both a "server cluster" and a "client cluster" within the main TLCD ring shown in FIG. 2A. The re-connecting CD 10 first retrieves the list of currently-connected TLCDs before determining where it should be inserted into the TLCD ring. The re-establishment of the cluster 11 is carried out within the timer OnTimer event, and the following pseudocode describes the actions which occur:
10
Procedure OnStartupTimer for Time = X Check connection status If connected = false then do the following Enumerate the TLCDs in the CDT Start Mailslot message Loop Send Mailslot message for status update to each TLCD End Mailslot message Loop End of connected = false conditional End of OnStartupTimer procedure
[0210] The next stage of the process is handled within the Mailslot OnNewMessage event, and the following pseudocode applies:
[0211] Procedure OnNewMessage
[0212] Check connection status
[0213] If connected then exit
[0214] Extract Rank value from message
[0215] If Rank=MaxRankTable then connect to Rank using ClientSocket
[0216] If Rank>MaxRank then MaxRank=Rank
[0217] Wait for next Mailslot message
[0218] End Procedure OnNewMessage
[0219] If none of the primary TLSDs are currently on-line then the following sequence of actions is carried out:
[0220] (i) obtain the next cluster ID;
[0221] (ii) enumerate Computer Names in the cluster 11;
[0222] (iii) send status request Mailslot message to each computer name in the cluster 11; and
[0223] (iv) from the reply messages determine the current main server for the cluster 11.
[0224] The above procedures are repeated until the current configuration of the TLCD ring is established. The details are similar to those outlined in the preceding pseudocode segments for the OnTimer event and the OnNewMessage event.
[0225] A situation commonly encountered is where all CDs 10 are powered-down, usually in the evening, and CD IP Addresses are provided dynamically by a Dynamic Host Configuration Protocol (DHCP) server (i.e., by a centralized method of managing IP Addresses that is well known in the art of network management). When the system is re-started, e.g., when users arrive in the morning and switch their computers on, the IP Address allocated to each CD 10 will differ from that stored in the CDT.
[0226] This situation differs from the initial start-up scenario in that each CD can obtain computer name information from the local CDT. Therefore, global Mailslot broadcasts are not necessary, and targeted Mailslots can be used instead. This is significant, as a global broadcast from every CD 10 as it started up in the morning could lead to a significant network load.
[0227] As with the other start-up scenarios described, there are two distinct stages in which the setup process is controlled:
[0228] (i) during the start-up phase of the CD; and
[0229] (ii) in the OnTimer event procedure that fires X milliseconds after startup.
[0230] In a system re-start the assumption is made that there are no valid IP addresses for the first CD 10 started. Mailslot messages are therefore used to obtain connection information from each cluster 11 in turn.
[0231] The details of how this is done for individual CDs is described in the section that discusses CD Re-Start, described previously.
[0232] The permanent connection architecture based on the clusters 11
provides immediate notification of any changes in the status of any CD 10.
[0233] With respect to the case where a client CD 10 within a cluster 11
disconnects, consider the case illustrated in FIG. 2B, where CD6, i.e. a Client CD, has gone off-line. Each Server Socket holds a list of currently connected Client Sockets. When CD6 disconnects the Client Disconnect event is triggered on the Server Socket on CD1. CD1 constructs a message with the following information:
[0234] Message Type (i.e. Disconnect Notification)
[0235] Disconnected CD Name
[0236] Source TLCD.<