WO2016151398A1 - System and method for configuring a platform instance at runtime - Google Patents

Abstract

An improved system and method are disclosed for configuring a platform instance at runtime using predefined configuration information and contexts that contain at least a portion of the predefined configuration information and also contain dynamically generated information that is not available until the platform instance is started. A core server of the platform instance is started and configured, contexts are created, and services and blocks are started and configured using the contexts.

Description

SYSTEM AND METHOD FOR CONFIGURING A PLATFORM INSTANCE AT

RUNTIME

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a Patent Cooperation Treaty Application of U.S. Provisional Application No. 62/137,011, filed March 23, 2015, entitled SYSTEM AND METHOD FOR CONFIGURING A PLATFORM INSTANCE AT RUNTIME (Arty. Dkt. No. SNVS-32552), the specification of which is incorporated by reference herein in its entirety.

BACKGROUND

[0002] The proliferation of devices has resulted in the production of a tremendous amount of data that is continuously increasing. Current processing methods are unsuitable for processing this data. Accordingly, what is needed are systems and methods that address this issue.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] For a more complete understanding, reference is now made to the following description taken in conjunction with the accompanying Drawings in which:

[0011] FIG. 1A illustrates one embodiment of a neutral input/output (NIO) platform with customizable and configurable processing functionality and configurable support functionality;

[0012] FIG. IB illustrates one embodiment of a data path that may exist within a NIO platform instance based on the NIO platform of FIG. 1 A;

[0013] FIGS. 1C and ID illustrate embodiments of the NIO platform of FIG. 1A as part of a stack;

[0014] FIG. IE illustrates one embodiment of a system on which the NIO platform of FIG. 1A may be run;

[0015] FIG. 2 illustrates a more detailed embodiment of the NIO platform of FIG. 1A;

[0016] FIG. 3A illustrates another embodiment of the NIO platform of FIG. 2;

[0017] FIG. 3B illustrates one embodiment of a NIO platform instance based on the NIO platform of FIG. 3 A;

[0018] FIGS. 4A and 4B illustrate another embodiment of the NIO platform of FIG. 2 from a platform perspective and a stack perspective, respectively;

[0019] FIG. 4C illustrates one embodiment of a service that may exist within the NIO platform of FIGS. 4A and 4B; [0020] FIG. 5 illustrates one embodiment of the interaction between various components within the NIO platform of FIGS. 4A and 4B;

[0021] FIG. 6 illustrates one embodiment of a workflow that may be used to create and configure a NIO platform;

[0022] Fig. 7 illustrates one embodiment of the NIO platform of FIG. 6;

[0023] FIG. 8 illustrates one embodiment of a component configuration environment within which a component is configured at runtime using only predefined configuration information;

[0024] FIG. 9 illustrates one embodiment of a component configuration environment within which a component is configured at runtime using a context;

[0025] FIG. 10 illustrates one embodiment of a service that may be used within the NIO platform of FIG. 7; and

[0026] FIGS. 11-13 illustrate embodiments of methods that may be executed by the NIO platform of FIG. 7 to configure components using contexts.

DETAILED DESCRIPTION

[0027] The present disclosure is directed to a system and method for configuring a neutral input/output platform instance at runtime. It is understood that the following disclosure provides many different embodiments or examples. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. In addition, the present disclosure may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed.

[0028] The present disclosure describes various embodiments of a neutral input/output (NIO) platform that includes a core that supports one or more services. While the platform itself may technically be viewed as an executable application in some embodiments, the core may be thought of as an application engine that runs task specific applications called services. The services are constructed using defined templates that are recognized by the core, although the templates can be customized to a certain extent. The core is designed to manage and support the services, and the services in turn manage blocks that provide processing functionality to their respective service. Due to the structure and flexibility of the runtime environment provided by the NIO platform's core, services, and blocks, the platform is able to asynchronously process any input signal from one or more sources in real time. [0029] Referring to FIG. 1A, one embodiment of a NIO platform 100 is illustrated. The NIO platform 100 is configurable to receive any type of signal (including data) as input, process those signals, and produce any type of output. The NIO platform 100 is able to support this process of receiving, processing, and producing in real time or near real time. The input signals can be streaming or any other type of continuous or non-continuous input.

[0030] When referring to the NIO platform 100 as performing processing in real time and near real time, it means that there is no storage other than possible queuing between the NIO platform instance's input and output. In other words, only processing time exists between the NIO platform instance's input and output as there is no storage read and write time, even for streaming data entering the NIO platform 100.

[0031] It is noted that this means there is no way to recover an original signal that has entered the NIO platform 100 and been processed unless the original signal is part of the output or the NIO platform 100 has been configured to save the original signal. The original signal is received by the NIO platform 100, processed (which may involve changing and/or destroying the original signal), and output is generated. The receipt, processing, and generation of output occurs without any storage other than possible queuing. The original signal is not stored and deleted, it is simply never stored. The original signal generally becomes irrelevant as it is the output based on the original signal that is important, although the output may contain some or all of the original signal. The original signal may be available elsewhere (e.g., at the original signal's source), but it may not be recoverable from the NIO platform 100.

[0032] It is understood that the NIO platform 100 can be configured to store the original signal at receipt or during processing, but that is separate from the NIO platform's ability to perform real time and near real time processing. For example, although no long term (e.g., longer than any necessary buffering) memory storage is needed by the NIO platform 100 during real time and near real time processing, storage to and retrieval from memory (e.g., a hard drive, a removable memory, and/or a remote memory) is supported if required for particular applications.

[0033] The internal operation of the NIO platform 100 uses a NIO data object (referred to herein as a niogram). Incoming signals 102 are converted into niograms at the edge of the NIO platform 100 and used in intra-platform communications and processing. This allows the NIO platform 100 to handle any type of input signal without needing changes to the platform's core functionality. In embodiments where multiple NIO platforms are deployed, niograms may be used in inter-platform communications. [0034] The use of niograms allows the core functionality of the NIO platform 100 to operate in a standardized manner regardless of the specific type of information contained in the niograms. From a general system perspective, the same core operations are executed in the same way regardless of the input data type. This means that the NIO platform 100 can be optimized for the niogram, which may itself be optimized for a particular type of input for a specific application.

[0035] The NIO platform 100 is designed to process niograms in a customizable and configurable manner using processing functionality 106 and support functionality 108. The processing functionality 106 is generally both customizable and configurable by a user. Customizable means that at least a portion of the source code providing the processing functionality 106 can be modified by a user. In other words, the task specific software instructions that determine how an input signal that has been converted into one or more niograms will be processed can be directly accessed at the code level and modified. Configurable means that the processing functionality 106 can be modified by such actions as selecting or deselecting functionality and/or defining values for configuration parameters. These modifications do not require direct access or changes to the underlying source code and may be performed at different times (e.g., before runtime or at runtime) using configuration files, commands issued through an interface, and/or in other defined ways.

[0036] The support functionality 108 is generally only configurable by a user, with modifications limited to such actions as selecting or deselecting functionality and/or defining values for configuration parameters. In other embodiments, the support functionality 108 may also be customizable. It is understood that the ability to modify the processing functionality 106 and/or the support functionality 108 may be limited or non-existent in some embodiments.

[0037] The support functionality 108 supports the processing functionality 106 by handling general configuration of the NIO platform 100 at runtime and providing management functions for starting and stopping the processing functionality. The resulting niograms can be converted into any signal type(s) for output(s) 104.

[0038] Referring to FIG. IB, one embodiment of a NIO platform instance 101 illustrates a data path that starts when the input signal(s) 102 are received and continues through the generation of the output(s) 104. The NIO platform instance 101 is created when the NIO platform 100 of FIG. 1A is launched. A NIO platform may be referred to herein as a "NIO platform" before being launched and as a "NIO platform instance" after being launched, although the terms may be used interchangeably for the NIO platform after launch. As described above, niograms are used internally by the NIO platform instance 101 along the data path.

[0039] In the present example, the input signal(s) 102 may be filtered in block 110 to remove noise, which can include irrelevant data, undesirable characteristics in a signal (e.g., ambient noise or interference), and/or any other unwanted part of an input signal. Filtered noise may be discarded at the edge of the NIO platform instance 101 (as indicated by arrow 112) and not introduced into the more complex processing functionality of the NIO platform instance 101. The filtering may also be used to discard some of the signal's information while keeping other information from the signal. The filtering saves processing time because core functionality of the NIO platform instance 101 can be focused on relevant data having a known structure for post-filtering processing. In embodiments where the entire input signal is processed, such filtering may not occur. In addition to or as alternative to filtering occurring at the edge, filtering may occur inside the NIO platform instance 101 after the signal is converted to a niogram.

[0040] Non-discarded signals and/or the remaining signal information are converted into niograms for internal use in block 114 and the niograms are processed in block 116. The niograms may be converted into one or more other formats for the output(s) 104 in block 118, including actions (e.g., actuation signals). In embodiments where niograms are the output, the conversion step of block 118 would not occur.

[0041] Referring to FIG. 1C, one embodiment of a stack 120 is illustrated. In the present example, the NIO platform 100 interacts with an operating system (OS) 122 that in turn interacts with a device 124. The interaction may be direct or may be through one or more other layers, such as an interpreter or a virtual machine. The device 124 can be a virtual device or a physical device, and may be standalone or coupled to a network.

[0042] Referring to FIG. ID, another embodiment of a stack 126 is illustrated. In the present example, the NIO platform 100 interacts with a higher layer of software 128a and/or a lower layer of software 128b. In other words, the NIO platform 100 may provide part of the functionality of the stack 126, while the software layers 128a and/or 128b provide other parts of the stack's functionality. Although not shown, it is understood that the OS 122 and device 124 of FIG. 1C may be positioned under the software layer 128b if the software 128b is present or directly under the NIO platform 100 (as in FIG. 1C) if the software layer 128b is not present.

[0043] Referring to FIG. IE, one embodiment of a system 130 is illustrated. The system 130 is one possible example of a portion or all of the device 124 of FIG. 1C. The system 130 may include a controller (e.g., a processor/central processing unit ("CPU")) 132, a memory unit 134, an input/output ("I/O") device 136, and a network interface 138. The components 132, 134, 136, and 138 are interconnected by a data transport system (e.g., a bus) 140. A power supply (PS) 142 may provide power to components of the system 130 via a power transport system 144 (shown with data transport system 140, although the power and data transport systems may be separate).

[0044] It is understood that the system 130 may be differently configured and that each of the listed components may actually represent several different components. For example, the CPU 132 may actually represent a multi-processor or a distributed processing system; the memory unit 134 may include different levels of cache memory, main memory, hard disks, and remote storage locations; the I/O device 136 may include monitors, keyboards, and the like; and the network interface 138 may include one or more network cards providing one or more wired and/or wireless connections to a network 146. Therefore, a wide range of flexibility is anticipated in the configuration of the system 130, which may range from a single physical platform configured primarily for a single user or autonomous operation to a distributed multi-user platform such as a cloud computing system.

[0045] The system 130 may use any operating system (or multiple operating systems), including various versions of operating systems provided by Microsoft (such as WINDOWS), Apple (such as Mac OS X), UNIX, and LINUX, and may include operating systems specifically developed for handheld devices (e.g., iOS, Android, Blackberry, and/or Windows Phone), personal computers, servers, and other computing platforms depending on the use of the system 130. The operating system, as well as other instructions (e.g., for telecommunications and/or other functions provided by the device 124), may be stored in the memory unit 134 and executed by the processor 132. For example, if the system 130 is the device 124, the memory unit 134 may include instructions for providing the NIO platform 100 and for performing some or all of the methods described herein.

[0046] The network 146 may be a single network or may represent multiple networks, including networks of different types, whether wireless or wireline. For example, the device 124 may be coupled to external devices via a network that includes a cellular link coupled to a data packet network, or may be coupled via a data packet link such as a wide local area network (WLAN) coupled to a data packet network or a Public Switched Telephone Network (PSTN). Accordingly, many different network types and configurations may be used to couple the device 124 with external devices. [0047] Referring to FIG. 2, a NIO platform 200 illustrates a more detailed embodiment of the NIO platform 100 of FIG. 1A. In the present example, the NIO platform 200 includes two main components: service classes 202 for one or more services that are to provide the configurable processing functionality 106 and core classes 206 for a core that is to provide the support functionality 108 for the services. Each service corresponds to block classes 204 for one or more blocks that contain defined task specific functionality for processing niograms. The core includes a service manager 208 that will manage the services (e.g., starting and stopping a service) and platform configuration information 210 that defines how the NIO platform 200 is to be configured, such as what services are available when the instance is launched.

[0048] When the NIO platform 200 is launched, a core and the corresponding services form a single instance of the NIO platform 200. It is understood that multiple concurrent instances of the NIO platform 200 can run on a single device (e.g., the device 124 of FIG. 1C). Each NIO platform instance has its own core and services. The most basic NIO platform instance is a core with no services. The functionality provided by the core would exist, but there would be no services on which the functionality could operate. Because the processing functionality of a NIO platform instance is defined by the executable code present in the blocks and the services are configured as collections of one or more blocks, a single service containing a single block is the minimum configuration required for any processing of a niogram to occur.

[0049] It is understood that FIG. 2 illustrates the relationship between the various classes and other components. For example, the block classes are not actually part of the service classes, but the blocks are related to the services. Furthermore, while the service manager is considered to be part of the core for purposes of this example (and so created using the core classes), the core configuration information is not part of the core classes but is used to configure the core and other parts of the NIO platform 200.

[0050] With additional reference to FIGS. 3A and 3B, another embodiment of the NIO platform 200 of FIG. 2 is illustrated as a NIO platform 300 prior to being launched (FIG. 3 A) and as a NIO platform instance 302 after being launched (FIG. 3B). FIG. 3A illustrates the NIO platform 300 with core classes 206, service classes 202, block classes 204, and configuration information 210 that are used to create and configure a core 228, services 230a- 230N, and blocks 232a-232M of the NIO platform instance 302. It is understood that, although not shown in FIG. 3B, the core classes 206, service classes 202, block classes 204, and configuration information 210 generally continue to exist as part of the NIO platform instance 402.

[0051] Referring specifically to FIG. 3B, the NIO platform instance 302 may be viewed as a runtime environment within which the core 228 creates and runs the services 230a, 230b, and 230N. Each service 230a-230N may have a different number of blocks. For example, service 230a includes blocks 232a, 232b, and 232c. Service 230b includes a single block 232d. Service 230N includes blocks 232e, 232f, and 232M.

[0052] One or more of the services 230a-230N may be stopped or started by the core 228. When stopped, the functionality provided by that service will not be available until the service is started by the core 228. Communication may occur between the core 228 and the services 230a-230N, as well as between the services 230a-230N themselves.

[0053] In the present example, the core 228 and each service 230a-230N is a separate process from an operating system/hardware perspective. Accordingly, the NIO platform instance 302 of FIG. 3B would have N+l processes running, and the operating system may distribute those across multi-core devices as with any other processes. It is understood that the configuration of particular services may depend in part on a design decision that takes into account the number of processes that will be created. For example, it may be desirable from a process standpoint to have numerous but smaller services in some embodiments, while it may be desirable to have fewer but larger services in other embodiments. The configurability of the NIO platform 300 enables such decisions to be implemented relatively easily by modifying the functionality of each service 230a-230N.

[0054] In other embodiments, the NIO platform instance 302 may be structured to run the core 228 and/or services 230a-230N as threads rather than processes. For example, the core 228 may be a process and the services 230a-230N may run as threads of the core process.

[0055] Referring to FIGS. 4A and 4B, a NIO platform 400 illustrates a more detailed embodiment of the NIO platform 100 of FIG. 1A, the NIO platform 200 of FIG. 2, or the NIO platform 300 of FIG. 3 A from a platform perspective (FIG. 4A) and a stack perspective (FIG. 4B). For purposes of example, the NIO platform 400 is written in the programming language Python, but it is understood that any suitable programming language can be used, including but not limited to languages such as C++. The NIO platform 400 is built on a core 406. When launched, a core process creates a core server (generally referred to herein as the core), which forms the underlying structure of the NIO platform 400.

[0056] Service components 402 include services 416 and blocks 418 from a functional perspective, even though the services 402 and blocks 418 are illustrated separately in the stack of FIG. 4B. As previously described, the service components 402 are responsible for user defined functionality by enabling block and service functionality to be defined and changed. Much of the functionality in a service component 402 can be user specific, which allows for a high level of customization.

[0057] In the present example, the service components 402 are provided as service classes 417 that define how services 416 are created and executed. The execution of services 416 includes routing signals, executing commands, and defining class structures. Some or all of the service classes 417 that form a service component 402 can be extended to define new functionality. This provides a large amount of flexibility in a neutral manner, as a user can define whatever functionality is desired through the service components 402 and that functionality will be executed by the NIO platform 400.

[0058] Generally, the service components 402 in one platform instance have no dependency or awareness of another platform instance's service components, which allows for each particular platform instance to be configured without having to take into account how the configuration would affect other platform instances. Furthermore, changing functionality in a service component 402 has no effect on the core 406. This ensures that the core 406 does not have to be modified to be compatible with the service components 402.

[0059] In the present example, from a functional perspective, the service components 402 include blocks 418, block classes 417, block instances (also referred to simply as "blocks"), block groups, commands, services 416, and niograms.

[0060] In the NIO platform 400, blocks classes 419 may include classes for both custom blocks 434 and blocks having predefined functionality such as RFID block(s) 424, short message service (SMS) block(s) 426, sensor block(s) 428, programmable logic controller (PLC) block(s) 430, and global positioning satellite (GPS) block(s) 432. Although not shown, it is understood that many other blocks 418 may be defined for use with systems using Electronic Product Codes (EPCs) (a trademark of EPCglobal Inc. of Lawrenceville, New Jersey), Low Level Reader Protocol (LLRP) information, email (e.g., simple mail transfer protocol (SMTP)), hypertext transfer protocol (HTTP) documents, and/or any other protocols.

[0061] Block classes 419 are classes that specify the metadata template and computational functionality of block instances. In the present example, blocks 418 are built from block classes 419 that extend a BaseBlock class and can specify custom behavior by overriding any of the following five basic methods provided by the BaseBlock class: BaseBlock.initialize, BaseBlock. configure, BaseBlock. start, BaseBlock. stop, and BaseBlock.processSignals. These methods are used by the service 416 that corresponds to the blocks 418.

[0062] The BaseBlock.initialize method is called to instantiate the block 418 using the corresponding block class 419. The BaseBlock. configure method is called to configure the block 418 after initialization using a saved block configuration. The BaseBlock. start method is called to start the block 418 after instantiation and configuration. The BaseBlock. stop method is called to stop the block 418 (e.g., when the containing service 416 has been stopped). The BaseBlock.processSignals contains the main processing functionality provided by the block 418. The BaseBlock.processSignals method processes a (possibly empty) list of incoming signals and notifies the service 416 when done (e.g., via a notify Signals method, which is discussed below).

[0063] A block instance is created when a block 418 is instantiated from a block class 419. A block instance may be viewed as the fundamental unit of computation in the NIO platform 400 and may be customized and configured as prescribed by the block class 419 being instantiated. A block instance only exists inside a service 416. Accordingly, when a service 416 is started or stopped, the blocks 418 inside that service 416 are also started or stopped. In the present example of the NIO platform 400, there is no concept of a block 418 running outside a service 416.

[0064] Block configurations, which are used to configure blocks 418, can be reused in different services 416 and may be viewed as saved configurations of blocks 418. When the configuration of a block 418 is changed, it will be changed for all blocks 418 in all services 416 that contain it. However, if a service 416 is running, the configuration of the running block instance may only be updated after the service 416 is restarted.

[0065] In other embodiments, a block instance may be updated without restarting the service 416. For example, if the block instance is not currently in use by the service 416, the block instance may be stopped, reconfigured with the new block configuration, and restarted. Altematively, if not in use, the block instance may be destroyed and a new block instance may be instantiated with the new block configuration. In such embodiments, the service 416 may continue running or may be paused, rather than stopped and restarted.

[0066] Outside agents (e.g., other services and/or external APIs) may modify the behavior of specific blocks 418 via a command API (discussed below). Within the command API, block instances may be referenced by a service level block alias and/or a block group level. For this reason, globally unique block identifiers are not necessary in the present example, although they may be used in some embodiments. [0067] Block instances can directly receive and send signals without going through the service 416. In this respect, a block 418 can serve as an interface through which signals can enter the NIO platform 400 and be sent from the NIO platform 400.

[0068] With additional reference to FIG. 4C, as described previously, services 416 are the main organizational component of the NIO platform's configurable processing functionality. Each service 416 maintains a block router 421, a block controller 422 for each block 418a-418M, its own configuration parameters, a list of block instances for that service, and an associative list of block aliases. In the present embodiment where the service 416 is a process, the service process may handle all communications between the service 416 and the service manager 414. In other embodiments, the block router 421 or another component within the service 416 may handle such communications.

[0069] The block controllers 422a-422M serve as intermediaries between the block router 421 and their respective blocks 418a-418M. In performing this intermediary function, the block controllers 422a-422M mimic both the block router 421 and the blocks 418a-418M. For example, the block router 421 may instantiate the block controller 422a, which in turn instantiates the block instance 418a. In other embodiments, the block router 421 may instantiate the block controller 422a and the block instance 418a. After instantiation, the block router 421 communicates with the block controller 422a as though the block controller 422a is the block 418a. Similarly, the block 418a communicates with the block controller 422 as though the block controller 422 is the block router 421. Accordingly, removal of the block controllers 422a-422M would not prevent communications between the block router 421 and the blocks 418a-418M, but would remove the functionality provided by the block controllers 422a-422M from the service 416 unless that functionality was included elsewhere in the service (e.g., in the block router 421 and/or the blocks 418a-418M).

[0070] The block controllers 422a-422M may be configured to perform error handling and/or other functions for their respective blocks 418a-418c. Generally, only functions that are likely needed by many or all blocks may be provided by the block controllers 422a-422M. This enables a generic block controller to be used for a block 418 regardless of the functionality of that particular block. Accordingly, each block controller 422a-422M is identical in the present example. In other embodiments, block controllers having different configurations may be used for different blocks based on the need of a particular block and/or other criteria.

[0071] The block controllers 422a-422M may be configured to make certain decisions about whether to pass information to the block router 421. For example, when the block 418a throws an error, the error is caught by the block controller 422a. The block controller 422a may then decide how to handle the error, including passing the error up to the block router 421, ignoring the error, and/or taking other action. For example, if the error indicates that the block instance 418a has stopped working, the block controller 422a may proactively notify the block router 421 or may wait to notify the block router 421 until the block router 421 attempts to use the block instance. Removal of the block controller 422a would remove this error handling functionality so that when the block 418a throws the error, the block router 421 would catch it.

[0072] The block router 421 handles data flow among the blocks 418a-418M by defining the flow of niograms between blocks 418a-418M within the service 416. More specifically, communication between block instances within the service 416 is managed by the block router 421 via a Blockrouter.notifySignals() method and a process Signals() method. The Blockrouter.notifySignals() call is issued by a block 418 that has output ready. The Blockrouter.notifySignalsO method identifies the source block and contains the niogram(s) forming the output. For example, the Blockrouter.notifySignalsO may be implemented as Blockrouter.notifySignals(source block identifier, niogram(s)).

[0073] In the current embodiment, this call is made whenever a block 418 within the service 416 has output and the block need not be aware of the service at all. In other words, the block 418 receives input, processes, the input, calls Blockrouter.notifySignalsO, and is done without even knowing that it is part of a service. In other embodiments, the block 418 may know the service 416 of which it is a part, which enables the block 418 to notify the signal to the particular service 416. Although the output itself is passed as a parameter in the method call in the present embodiment, it is understood that other processes may be used to transfer the output. For example, a pointer to the output may be passed rather than the output itself.

[0074] When Blockrouter.notifySignalsO is invoked, the block router 421 looks up the source block 418 in the routing table to determine the destination block(s) 418 to which the output should be directed. The block router 421 then calls processSignals() on each of the next blocks in succession. The processSignals() method identifies the destination block and contains the niogram(s) to be processed (e.g., the niograms that were the output of the source block). For example, the processSignals() method may be implemented as processSignals(destination block identifier, niogram(s)). Although the niogram(s) themselves are passed as a parameter in the method call in the present embodiment, it is understood that other processes may be used to transfer the niogram(s). For example, a pointer to the niogram(s) may be passed rather than the niogram(s) themselves. The block router 421 may, with each call for process Signals(), launch the called block instance in a new thread of the service process.

[0075] In the present example, the blocks 418 operate asynchronously (i.e., each block 418 executes independently of other blocks). When a block 418 publishes a niogram to another block 418, the receiving block executes immediately. This means that there is no buffering of niograms between blocks 418 except as needed (e.g., buffering may occur if a thread pool is used and there is no currently available thread for the receiving block) and data passes through the service 416 as quickly as the blocks 418 can process the data. The processing speed for a given block 418 may depend on the complexity of the block's instructions, as well as on factors outside of a block's control, such as the speed of the device's processor and the amount of processor time allocated to the block's thread.

[0076] Services 416 are started and stopped by commands issued through a service API. When a service 416 receives the start command, it "starts" all blocks 418 contained by the service 416. Similarly, when a service 416 receives the stop command, it stops all blocks 418 contained by the service 416. It is noted that the blocks 418 may not actually be "started," but simply notified that the service 416 encapsulating them has been started. If desired, the blocks 418 can then use the notification hook to execute some functionality (e.g., a block 418 that polls an external API and needs to know when to start polling could use the notification as the polling trigger).

[0077] In some embodiments, stopping a service 416 may result in the loss of any information (e.g., the local state) in any corresponding block instances. For example, in the current example that uses Python objects for block instances, block objects can be wiped out by calling the Blockinstance. destroy () method. In other embodiments, it may be desirable to maintain the local state after a service 416 is stopped. For example, instead of wiping out the local state of instantiated blocks when a service 416 is stopped, the service 416 can instead be paused to stop the service's execution temporarily without losing potentially valuable data. This may be accomplished by issuing the stop command to all the blocks 418 in the service 416 without doing the normally associated cleanup (e.g., without calling Blockinstance.destroyO) and/or in other ways.

[0078] Commands are used to interact with blocks 418 and must be reachable from outside the blocks 418. Accordingly, how a block 418 defines and exposes a command needs to be known. For example, a block 418 may be used to provide SMS functionality. To accomplish this, the block 418 may be configured to expose a command "sendSMS." For the block 418 to function within the NIO platform 400, the method for actually sending an SMS would be written in the block 418 in executable instructions, and then the method would have to be declared as a command to make it reachable through, for example, a REST API. A command to call the method may be formatted in various ways depending on the particular implementation of the block structure, such as a name (e.g., the block's method name), title (e.g., a descriptive name), and arguments. It is noted that this may be the same command structure used to start/stop services.

[0079] As previously described, the niogram is the primary mechanism for intra-service data transmission (e.g., between blocks/block groups). All blocks 418 may accept and emit generic niograms of a base niogram class. The base niogram class generally has no required fields and does not require validation. The base niogram class simply exposes a way to add or remove attributes, and serialize/de-serialize the niogram into different forms (e.g., JavaScript Object Notation (JSON)). In the present example, an instance of the base niogram can add or remove attributes freely.

[0080] With continued reference to FIG. 4B, the modules 404 are modules containing predefined code that the NIO platform 400 may use itself and that blocks 418 may also use. The modules 404 may provide functionality defined with respect to each module, such as a logging module 438, a security module 440, a threading module 442, a communication module 444, a scheduler module 446, a persistence module 448, and/or a web server module 450. Some or all of the modules 404 are designed so that they can be exchanged for different implementations of the same functionality without affecting existing blocks or platform functionality. A role of the modules 404 within the NIO platform 400 is to provide swappable functionality for different platform instances without affecting the blocks 418 and the core 406. The modules 404 provide APIs that can be called by blocks 418 and the core 406. The result of the API call is defined by the functionality of the called module 404.

[0081] The functionality defined in the modules 404 spans an entire platform instance. Accordingly, when the functionality within a module 404 is changed, the entire platform instance will use the new version of the module. For example, if the logging module 438 is changed to log to a remote database instead of a local file, all logging calls (in the core 406 and in the services 416) will start logging accordingly. However, such changes may require a platform instance restart to take effect.

[0082] The modules 404 support the ability of the NIO platform 400 to run within different environments without having to modify the core design of the NIO platform 400. For example, if a particular environment does not support some needed feature, the module 404 responsible for that feature can be reconfigured or replaced with functionality that is supported by the environment. Accordingly, by changing modules 404 as needed, platform instances may be run in varied environments that have different needs.

[0083] Depending on the functionality of the particular module 404, a module 404 may need to initialize its functionality based on variable data. For example, the logging module 438 may need a file name where the information is saved, while the communication module 444 may need a list of current publishers in the platform instance. In order to accomplish this, both the core 406 and the services 416 initialize the modules 404 by calling a setup method and passing context information with this data.

[0084] For services 416, the module's initialization data may come directly or indirectly as part of the service's initialization data. For example, the data may be provided indirectly by providing the name of the configuration file where the data for the module 404 resides. For the core 406, the data may reside in a system wide configuration file that can be read during start up and then used for initializing the module 404.

[0085] The logging module 438 is used to provide logging functionality and, like all of the modules 404, may provide a customized solution or may use an existing solution, such as Python's built-in logging module. The security module 440 enables blocks 418 to interface with internal or external security applications. The threading module 442 provides threading support and may provide one or more threading options. The communication module 444 enables services 416 within a platform to subscribe and publish niograms. The niograms can be transported within the platform instance or between platform instances. The scheduler module 446 facilitates the execution of tasks at scheduled intervals or at a single point in the future. The persistence module 448 enables blocks 418 and core components to "persist" certain information relevant to them that will survive through a platform instance restart.

[0086] The web server module 450 enables services 416 and/or blocks 418 to expose a web server for interacting on an isolated port. In addition, the core 406 may use the web server module 450 to expose a web server that hosts the API 408. Services 416, which operate as different processes in the present example, can ease the load on the core process by receiving data directly through their own web server. Without this, blocks/services use commands to receive data through HTTP, but those commands are regulated and passed through the core 406. By using the web server module 450, the blocks 418 can listen directly to a port for incoming HTTP requests and handle the requests accordingly without loading the core process. [0087] In the present example, the core 406 includes an API 408, a service manager 414, and a configuration manager 410. The configuration manager 410 includes configurations 411, a loader 452, and discovery functionality 454, which may be part of the loader 452 in some embodiments. In other embodiments, the configuration manager 410 may not exist as a component, but the loader/discovery functionality and the configurations may continue to exist within the core 406 (e.g., as part of the service manager 414 or elsewhere). The core 406 may also include core components 412 in some embodiments. The core 406 maintains the services 416 provided by the NIO platform 400. The core 406 is not directly exposed to the service components 402 and can use the modules 404.

[0088] The API 408 represents multiple APIs, but it is understood that blocks 418 and block groups may be able to receive and/or send information without passing through the API 408 in the core 406. For example, a block may be able to send and receive SMS messages without using the API 408. It is understood that many different APIs and API calls may be defined, and that the examples described below are only for the purpose of illustrating how various components of the NIO platform 400 may be accessed and managed. In the present example, the API 408 includes a block API, a block configuration API, a command API, a mechanism for providing custom APIs, and a service API.

[0089] The block API enables a user to alter the state of the blocks 418 loaded in the NIO platform 400. For example, the block API enables a user to add, reload, and/or remove blocks 418 without having to restart the instance in which the blocks 418 are located. For purposes of example, the block API follows the create, read, update, delete (CRUD) model, exposing four methods to interact with blocks 418, as well as an instances endpoint to interact with a block's instances.

[0090] A create method adds a new block 418 to an instance and may be accomplished in multiple ways. For example, a file, module, and/or package may be attached for use as the block 418, a file name where the block code is loaded may be referenced, a remotely hosted block may be referenced, and/or a class may be specified and the NIO platform 400 may be configured to locate and retrieve the class's code.

[0091] A read method returns a list of blocks 418 and therefore exposes the functionality of the NIO platform 400. In addition to the list of blocks 418, the read method may return other block meta information, such as version, dependencies, and install time.

[0092] An update method refreshes a block 418 in the NIO platform 400. This may include reloading the block's code, re-validating, and updating references. The update method may not update the block code for block instances that are currently in running services 416. In such cases, the service 416 may have to be restarted to realize the block code. In other embodiments, a block instance may be updated without having to restart the service 416.

[0093] A delete method enables a block 418 to be deleted from the NIO platform 400. Any block instances of the block 418 will also be deleted. Any blocks 418 that are in running services 416 will continue to run, but when the service 416 is restarted, an error will be thrown and the service 416 will not be able to start unless the service 416 is updated to reflect the deletion.

[0094] An instances method enables interaction with the instances of a block 418. For example, "instances" may be viewed as a custom endpoint that is essentially an alias for /instances?block=BlockName. The instances method allows a user to modify the block instances associated with a given block 418. This will be discussed in greater detail below with respect to the block instance API.

[0095] The block configuration API enables a user to alter the state of the block instances loaded in the NIO platform 400. Because block configurations are configured instances of blocks 418, some API calls can happen through the previously described block API. For purposes of example, the block configuration API follows the CRUD model, but may also define some alternative methods.

[0096] A create method adds a new block configuration. To create a block configuration, a relevant block 418 must exist for the configuration. As a result, configuration creation can go through the specified block's API endpoint within the block API. Configuration creation can also go through the NIO platform's block configuration API as long as a valid block 418 is specified.

[0097] A read method returns a list of block configurations, although there may be multiple ways to see the block configurations that are configured within the NIO platform 400. For example, by hitting the main block configurations endpoint, all configurations in the NIO platform 400 will be returned. Further refinement can be achieved by specifying a block name as a parameter or issuing the GET to the block configuration's endpoint. The GET calls will return the configuration's name as well as the configuration defined within the block 418.

[0098] An update method updates the configuration of a block configuration on the NIO platform 400. Blocks 418 that are part of a currently running service 416 will not have their configuration updates realized until the service 416 is restarted. [0099] A delete method enables a block configuration to be deleted from the NIO platform 400. This removes a block configuration from the NIO platform 400, but not the block 418 itself. If the block 418 is part of a running service 416, the service 416 will continue to run with the original block code. When the service 416 is restarted, an error will be thrown indicating the block 418 cannot be found.

[0100] The command API enables a user to interact with previously described command handlers that have been defined to expose commands for blocks 418. Services 416 and blocks 418 can both be commanded. However, in the present embodiment, because blocks 418 do not stand alone but exist within a service 416, the caller must go through the service 416 to command a block 418. Depending on the particular implementation, a command may be called in many different ways, including hypertext transfer protocol (HTTP) methods such as GET and POST. The block 418 being called should define the proper handling for each type of allowed call.

[0101] A command method can be used to command a block 418 inside a service 416. For example, the method may be structured as

/services/ServiceName/BlockAlias/commandName. The root of this API call is the service 416, since the block 418 inside of that service 416 is what will be commanded. If the specified service 416 does not exist, an error will be thrown. The next component in the method is the BlockAlias. By default, this will be the block configuration name. However, if a service builder wishes to include more than one of the same blocks 418 within a service 416, a block alias can be defined for each configuration of that block 418. The final component is the command name. This command must be a valid command as defined by the block 418 connected to BlockAlias.

[0102] The mechanism for defining custom APIs leverages the ability of blocks 418 to define custom command handlers. Because of this, custom APIs can be written as blocks 418 and implemented as block configurations within a service 416. For example, a service builder can drop an API block 418 into any point in a service 416. The API block 418 does not affect the operation of the service 416, but does provide a new API endpoint that can be used to leverage attributes of the service 416 at the point where the block 418 is inserted.

[0103] The service API enables a user to alter the state of the services 416 in the NIO platform 400. For purposes of example, the service API follows the CRUD model, as well as a command model that allows a user to start/stop a service 416.

[0104] A create method adds a new service 416 to the NIO platform 400. The specification of the service 416 (e.g., blocks and block mappings) may be included in the body of the call. A read method returns a list of services 416 and their configuration. This information may include the blocks 418 within a service 416, the state of the service 416 (e.g., running or stopped), and any other configuration options specified when the service 416 was created. An update method updates a service's configuration. If the service 416 is currently running, the configuration update will be accepted, but the changes will not be realized until the service 416 is restarted. A delete method removes a service 416 from the NIO platform 400. If the service 416 is currently running, this call will return an error. The service 416 should be stopped before being deleted. A command method is used to start or stop a service 416. If a problem exists with the configuration of a service 416 (e.g., there are non-existent blocks 418, block instances with an invalid block 418, and/or other validation issues), the call will return an error.

[0105] In the present embodiment, the configuration manager 410 manages configurations 411 for the current instance of the NIO platform 400, loads services 416 and blocks 418 for inspection if needed, and performs auto-discovery. Ideally, the core 402 has no dependency on its functionality (e.g., the blocks 418) or its configuration (e.g., the block instances and services 416). This lack of dependency enables the use of relocatable instance configurations, such as one or more directories specified by a user. Then, when an instance of the NIO platform 400 is launched, the location of the instance configuration will be identified and the NIO platform 400 will load the instance's blocks 418, services 416, and other needed components from that location. This enables a user to version control their configurations, create multiple configurations on the same machine, and easily share and inspect their configurations.

[0106] Configurations may be represented within the NIO platform 400 in many different ways. For example, block instances and services 416 may use JSON flat files, SQLite databases, and/or zip files, while blocks 418 may use python files or python module directories. It is understood that these are merely examples and that many different formats may be used to represent configuration information.

[0107] The NIO platform 400 may include different types of configurations depending on what part of the NIO platform 400 is being described. Examples include a core configuration, a platform configuration, a core components configuration, a service configuration, and a block configuration. It is understood that these configurations may be stored as separate files or may be combined. Furthermore, any of these configurations may be divided into multiple configurations or combined in many different ways. [0108] The core configuration is directed to settings related to the core 406. These values may be private to the core 406 and visible to the services 402. The platform configuration is directed to settings for the entire NIO platform 400. These include all settings that are visible to the core 406 and to the services 402. The core components configuration is directed to settings related to a specific core component. The service configuration is directed to settings related to a specific service 416. The block configuration is directed to settings related to a specific block 418.

[0109] The NIO platform 400 may use a configuration data file that details what is included in the NIO platform 400. This data file may be different from what is actually inside the configuration directory. For example, if a user copies a block file into a block directory, the block file may not be picked up by an instance until the block file is loaded via the block API. At this point, the instance may load that block 418 into the configuration data file. Similarly, block instance configurations may be copied to the directory, but may not be recognized until the instance is restarted. In other embodiments, an instance restart may not be needed in order for the block instance configurations to be recognized.

[0110] In some embodiments, the data may reside at a remote location (e.g., in a remote database or a data structure server), which allows definitions to be shared among different platform instances. In such embodiments, the handler to use in loading a particular configuration may be specified through a platform setting. The NIO platform 400 would then instantiate the specified handler and use it to fetch the instance configuration. One example of an instance configuration directory for the NIO platform 400 is illustrated below, with comments in parentheses.

[0111] / (The root of the configuration, which can be any directory on a device.)

/blocks/ (A directory containing the blocks in the instance.)

/blocks/"specific block name"/ (An example of a directory block.)

/blocks/blockGroup.py

/instances/ (A directory containing the block instances in the instance.) /instances/"specific block name".db (An example where the blocks are a database.)

/instances/blockGroup/ (An example where the blocks are grouped into a folder.)

/instances/blockGroup/BigBlockGroup.json

/instances/blockGroup/LittleBlockGroup.json

/services/ (A directory containing the services in the instance.) /services/EmailNotificationService.json

/services AVeatherSMSService.db

config.db (A set of data representing what is configured in the instance.)

[0112] The core components 412 are modules containing predefined code that the NIO platform 400 may use. The core components 412 provide functionality to the NIO platform 400 and may include modules such as a monitoring module 456, a messaging module 458, a communication manager module 460, and/or an instance distribution module 462.

[0113] The core components 412 are somewhat different from core functionality provided by the configuration manager 410 and service manager 414. While core functionality is generally hidden from block writers and required for operation of the NIO platform 400, core components 412 are swappable components (similar to the modules 404) that are positioned within the core 406 and provide functions usable by the core 406. Like the core functionality, the core components 412 are hidden from block writers (unlike the modules 404). Unlike the core functionality, the core components 412 are not required for the NIO platform 400 to run. However, it is understood that certain implementations of the NIO platform 400 may rely on the core components 412 due to the platform's configuration, in which case the functionality of one or more of the core components 412 would be needed to provide the desired functionality. In other words, the NIO platform 400 might run without the needed core components 412, but would be unable to accomplish certain tasks. In other embodiments, the NIO platform 400 may not start without the needed core components 412.

[0114] The instance distribution module 462 may be used when more than one platform instance is sharing the services 416. The messaging module 458 provides a way for external systems to send and receive information from the NIO platform 400.

[0115] The service manager 414 handles the interaction of the core 406 with the services 416 running in a platform instance. The service manager 414 handles starting and stopping services 416, and may also manage a service's incoming commands (e.g., commands received via the REST interface 464/ API 408). The service manager 414 may use functionality provided by the modules 404 and core components 412. The service manager 414 may be accessed from outside the NIO platform 400 via the API 408.

[0116] Referring to FIG. 5, one embodiment of an environment 500 that is internal to the NIO platform 400 illustrates a service 416 and the core 406. As previously described, the service process handles communications with the service manager 414, such as commands received through the REST API 408. The block router 421 handles intra-service communications between the blocks 418 via the corresponding block controllers 422 (in embodiments where the block controllers 422 are present). The loader 452 and discovery functionality 454 may be used by the service manager 414 to load service and/or block classes 417, 419 for discovery purposes. External sources/destinations 502 and 504 can communicate via blocks 418 and/or via the REST API 408.

[0117] Referring to FIG. 6, a diagram 600 illustrates one embodiment of a workflow that runs from creation to launch of a NIO platform 602 (which may be similar or identical to the NIO platform 100 of FIG. 1A, 200 of FIG. 2, 300 of FIG. 3A, and/or 400 of FIGS. 4A and 4B). The workflow begins with a library 604. The library 604 includes core classes 206 (that include the classes for any core components and modules in the present example), a base service class 202, a base block class 606, and block classes 204 that are extended from the base block class 606. Each extended block class 204 includes task specific code. A user can modify and/or create code for existing blocks classes 204 in the library 604 and/or create new block classes 204 with desired task specific functionality. Although not shown, the base service class 202 can also be customized and various extended service classes may exist in the library 604.

[0118] The configuration environment 608 enables a user to define configurations for the core classes 206, the service class 202, and the block classes 204 that have been selected from the library 604 in order to define the platform specific behavior of the objects that will be instantiated from the classes within the NIO platform 602. The NIO platform 602 will run the objects as defined by the architecture of the platform itself, but the configuration process enables the user to define various task specific operational aspects of the NIO platform 602. The operational aspects include which core components, modules, services and blocks will be run, what properties the core components, modules, services and blocks will have (as permitted by the architecture), and when the services will be run. This configuration process results in configuration files 210 that are used to configure the objects that will be instantiated from the core classes 206, the service class 202, and the block classes 204 by the NIO platform 602.

[0119] In some embodiments, the configuration environment 608 may be a graphical user interface environment that produces configuration files that are loaded into the NIO platform 602. In other embodiments, the configuration environment 608 may use the REST interface 408, 464 (FIGS. 4A and 4B) of the NIO platform 602 to issue configuration commands to the NIO platform 602. Accordingly, it is understood that there are various ways in which configuration information may be created and produced for use by the NIO platform 602. [0120] When the NIO platform 602 is launched, each of the core classes 206 are identified and corresponding objects are instantiated and configured using the appropriate configuration files 210 for the core, core components, and modules. For each service that is to be run when the NIO platform 602 is started, the service class 202 and corresponding block classes 204 are identified and the services and blocks are instantiated and configured using the appropriate configuration files 210. The NIO platform 602 is then configured and begins running to perform the task specific functions provided by the services.

[0121] Referring to FIG. 7, one embodiment of the NIO platform 602 is illustrated and described with respect to a startup process. The NIO platform's structure is extremely flexible and can be configured to perform many different tasks in many different environments. Therefore, the startup process that is used when a NIO platform is launched should be robust and able to properly configure any NIO platform regardless of the platform's particular configuration. Configuration variations can include different services 230 and service configurations, different blocks 232 and block configurations, the presence/absence of optional core components 412 and their configurations, different implementations and configurations of modules 404, and different locations for resources.

[0122] Furthermore, some configuration information is not available until the startup process is underway. This means that the startup process should accommodate not only predefined configuration information, but also information that is unknown until various points in the startup process are reached.

[0123] Accordingly, the startup process in the present example uses both predefined configuration files and dynamically generated objects called contexts that incorporate information not known before startup. This allows configuration information 210 (FIG. 2A) to make its way from a file on disk, through the core 228, and ultimately to the blocks 232 in a new process, while also incorporating dynamically generated information. When finished, the startup process will have properly initialized the NIO platform's components and created a running NIO platform 602 that can perform the tasks it is configured to perform.

[0124] As illustrated in FIG. 7, the architecture of the NIO platform 602 can be divided into two main parts: (1) the management and support functionality provided by a core server 228 that forms the base of the NIO platform 602, the core components 412, and optional modules 404, and (2) the task specific functionality provided by the service components (services 230 and blocks 232). The core server 228, core components 412, modules 404, services 230, and blocks 232 are generally all initialized when the NIO platform 602 is launched, although some components (e.g., services 230 and blocks 232) may not be initialized until needed. For convenience, the core server 228, core components 412, modules 404, services 230, and blocks 232 are all generally referred to as "components" in the present embodiment and in some later embodiments. When a particular component is being described, its name will be used (i.e., core server 228, core component 412, module 404, service 230, or block 232).

[0125] Each component is initialized by instantiating the component using one or more class files and then configuring the instantiated component. There are two different ways that configuration can occur within the NIO platform 602: (1) using only a configuration file or (2) using a context. The configuration type (i.e., configuration file or context) used with each component is illustrated below in Table 1 along with the part of the NIO platform 602 that is responsible for providing the configuration to the component.

[0126]

Table 1

[0127] In Table 1, it is noted that the core server 228 and block routers 421 may not technically be considered components. The core server 228 is the foundation of the entire NIO platform 602 and a block router 421 is considered to be part of the corresponding service 230 rather than a standalone component. However, the core server 228 and block routers 421 are described as components for purposes of this example because they are both instantiated from their own class files and configured using a configuration file (for the core server 228) or a context (for the block router 421) in the same manner as other components.

[0128] Although each SIC, BRIC, and BIC are described as being unique to their respective service 230, block router 421, and block 232, it is understood that they may be combined in other embodiments. For example, a single SIC may be used for all services 230, with each service 230 extracting the needed configuration information corresponding to itself from the SIC. Similarly, a single BIC may be used for all blocks 232 in a service 230 or all blocks 232 in the NIO platform 602, with each block 232 extracting the needed configuration information corresponding to itself from the BIC. Accordingly, while individual SICs, BRICs, and BICs are used in the present embodiment, other implementations may be used.

[0129] Referring to FIG. 8, one embodiment of a configuration environment 800 within which the core server 228 and modules 404 are configured using only predefined configuration information is illustrated. When the core server 228 and modules 404 are initialized, the component's class file(s) 802 are instantiated to create a non-configured object 804. Configuration information from the component's configuration file 806 is then applied to the non-configured component to form a configured component 808. The configuration information is unique to the component being configured.

[0130] Referring to FIG. 9, one embodiment of a configuration environment 900 within which the core components 412, services 230, block routers 421, and blocks 232 are configured using a context is illustrated. When the core components 412, services 230, block routers 421, and blocks 232 are initialized, the component's class file(s) 902 are instantiated to create a non-configured object 904. Configuration information from the component's configuration file 906 is then combined with dynamically generated configuration information 908 to create a context 910 for the specific component being configured. Accordingly, the context is built from two types of information: (1) the configuration file 906 that contains predefined information for that component known before startup, and (2) the dynamically generated information 908 that is known only after startup. The context 910 then applied to the non-configured component 904 to form a configured component 912.

[0131] Referring again to FIG. 7, in the present embodiment of the startup process for the NIO platform 602, the context needed for the core components 412, services 230, block routers 421, and blocks 232 must be built before those components can be started. Therefore, the NIO platform 602 follows a particular order of operations during startup. This order of operations prioritizes the startup order of the core server 228, modules 404, core components 412, services 230, block routers 421, and blocks 232 so that components that contribute information to the contexts used by other components are started first.

[0132] The startup process of the NIO platform 602 can be separated between the two parts of the NIO platform illustrated in FIG. 7, with the management and support components being started before the service components. The basic order of startup steps for one embodiment of the NIO platform 602 is shown below in Table 2. [0133]

Table 2

[0134] In the present embodiment, it is understood that steps 4-6 of Table 2 occur on a per service basis. For example, step 6 may be executed to initialize the block router 421 for a service #1 at the same time that step 5 is being repeatedly executed to initialize the blocks 232 for a service #2 and step 4 is being executed to initialize the base service process 230 for a service #3. Furthermore, while Table 2 shows that the block router 421 is started before the blocks 232, the block router 421 is created before the blocks 232 are initialized, but is not configured until after the blocks 232 are initialized.

[0135] The initialization processes for the core server 228, core components 412, and modules 404 are interleaved. The core process controls the timing. This is illustrated below in outline form:

1. Core process launched

2. Core configuration information parsed

3. Environment settings and variables created

4. Core server created

5. Core server run

a. Core server configured

Modules discovered

11 Modules initialized

in Component manager created

IV. Core components discovered

1. Each core component initialized and saved in component

manager

v. CIC created - contains references to components and modules VI. CIC passed to each module

VII. Component manager configured with CIC

1. Each core component configured with CIC

b. Core server started

1. Component manager started

1. Each core component started

[0136] In the present embodiment, the service manager 414 (which is a required core component 412) is responsible for starting any services 230 that can be auto-started. This happens in the start method for the service manager 414, so starting services 230 occurs at 5(b)(i)(l), and starting blocks 232 also occurs at that point because the blocks 232 are considered to be part of their respective service 230 from a startup perspective. The following examples describing the initialization of the core server 228, core components 412, and modules 404 should be read in conjunction with the interleaving illustrated in the outline.

[0137] When the core process is launched to start the core server 228, the core process accesses a core configuration file to determine the core server's configuration. An example of a core configuration file is shown below:

[DEFAULT]

[provider]

conf: etc

type: nio. configuration. providers. file.FileConfigurationProvider [modules]

# location of the module configuration files

conf: etc/modules

load: logging, persistence, scheduler, security, threading, web, communication [service]

# location of overall service configuration

conf: etc/service.cfg

block router:

nio.common.block.router.thread_pool_executor.ThreadedPoolExecutorRouter [environment]

# location of custom extensions (blocks, services, etc)

blocks. path: blocks

[ipc]

request_time_to_live: 5.0 [server]

# settings for the web server that will host the core REST API host: [[NIOHOST]]

port: [[NIOPORT]]

[0138] Based on the core configuration file, the core process is able to load needed components and identify the location of needed resources. Once the core server 228 is started and configured, the core 228 creates a Core Initialization Context (CIC).

[0139] The CIC may include information on core components 412, configuration information for modules 404, and a shutdown method that can be called to safely shut down the NIO platform 602. The CIC's information on core components 412 may include a list of core components installed in the node (i.e., the REST API 408/464, service manager 414, component manager (which may be considered to be part of the core server 228, rather than a standalone component), a block manager, the configuration manager 410, and any other components, such as components for messaging 458 and monitoring 456. The configuration information for modules 404 may include a configuration dictionary for each module, specified by a file such as a .cfg file.

[0140] The core server 228 registers all of the modules 404 in the CIC, and then passes the CIC to the component manager. The component manager passes the CIC to each core component 412 and allows the core components 412 to read from and alter the CIC so that later components (e.g., services 230 and blocks 232) can access the core components 412 if needed.

[0141] The core server 228 starts the modules 404. For each module 404, the core server 228 initializes the module 404 and the module 404 configures itself (if needed) using its own configuration file. The core server 228 registers each module 404 and module specific information in the CIC so that other components will have the information needed to use the modules 404.

[0142] After the modules 404 are started and registered in the CIC, the core server 228 starts the component manager. The component manager detects and loads each core component 412, and also passes the CIC to each core component 412. The core components 412 can add their own information to the CIC for use by other components.

[0143] Services 230 are started on a per service basis. Each service configuration file has an "auto-start" field. If the field is set to "true," the core server 228 will automatically start the service 230 during the NIO platform's startup process. If the field is set to "false," the core server 228 will only start the service 230 after receiving a "start" command instructing it to start the service 230. The same startup process is used regardless of when a service 230 is started.

[0144] Services 230 can also be stopped on a per service basis. After being stopped, a service 230 must be restarted to be used. In the present embodiment, the restart process is the same as the original startup process for a service 230. Because the same process is used any time a service 230 is started, all of the contexts for a particular service 230 will be created each time the service 230 is started. This means that previously created contexts are not reused when a service 230 is restarted. In other embodiments, portions or all of the previously used contexts may be reused.

[0145] The service manager 414 of the core server 228 uses the CIC to determine which services 230 and modules 404 are loaded into the NIO platform 602 and is responsible for launching the service processes. The service manager 414 creates a Service Initialization Context (SIC) for a service 230 immediately before that service 230 is launched. The SIC is created from the service's unique configuration file and other information that is dynamically generated during startup.

[0146] With additional reference to FIG. 10, one embodiment of a service 230 called "MyService" is illustrated. The service 230 has a block configuration with a block 1002 named "SimulationBlock," a block 1004 named "ExampleFilter," a block 1006 named "AnotherFilter," and a block 1008 named "ExampleLogger." The block 1002 feeds into the two blocks 1004 and 1006, which in turn both feed into the block 1008. An example of a configuration file for the service "MyService" is shown below:

{

"auto_start": false,

"execution" : [

{

"name": "SimulationBlock",

"receivers" : [

"ExampleFilter",

"AnotherFilter"

]

},

{

"name": "ExampleFilter",

"receivers" : [ "ExampleLogger"

]

},

{

"name": "ExampleLogger",

"receivers": []

},

{

"name": "AnotherFilter",

"receivers" : [

"ExampleLogger"

]

}

],

"log level" : "ERROR",

"mappings": [],

"block_router":

"name" : "My Service",

"status": "stopped",

"type": "Service"

}

[0147] The configuration file identifies which blocks 232 are to receive a block's output, which block router 421 is to be used by the service 230 (e.g., the default block router in this case), the name of the service 230, and the status of the service 230.

[0148] In the present example, the SIC is the only object sent to the new service process when it is spawned and so needs to contain all the information that the service 230 needs to know from the core server 228. The SIC may include information on a service type, service properties, a service pipe, a core pipe, blocks, module configuration, modules, root, block component data, block specific component data, and service component data. The service type information refers to the base class of the service 230 to be created (e.g., service.base). The service properties information refers to properties with which to configure the service 230. The service pipe information refers to an IPC pipe used to listen to data from the core server 228. The core pipe information refers to an IPC pipe used to send data to the core server 228. The blocks information refers to a list of objects containing block classes and block properties for the service 230.

[0149] The module configuration information refers to service specific module configuration information. The modules information refers to a list of modules to initialize, which is needed when the service process is a separate process from the core process and so will have its own module instances. The root information refers to the string path of the root project environment. The block component data information refers to data that the core components 412 can pass to all blocks 232. The block specific component data information refers to data that the core components 412 can pass to specific blocks 232. The service component data information refers to data that the core components 412 can pass to services

230.

[0150] It is understood that not every service 230 may need every module 404. For example, a service 230 that only simulates and logs data (e.g., the service 230 of FIG. 10) will likely have no need for the communication module 444. Accordingly, in some embodiments, the core 228 is able to detect this dependency and can withhold the communication module 444 from the list of modules 404 passed to the service 230 in the SIC.

[0151] However, if a management core component is installed, it may listen to management signals and attempt to publish them along a channel. Since the service 230 is in its own process, this listener would also exist in the service process so it would require communication to be configured in that process. Therefore, the management core component can amend the modules list in the SIC to include the communication module 444, regardless of whether or not the blocks 232 in the service 230 need the communication module 444.

[0152] Block initialization relies on a Block Initialization Context (BIC) created by the service process corresponding to the block 232 being initialized. One BIC is created for each block 232 in the service 230 and is passed to the respective block 232 after the service 230 is configured. The purpose of the BIC is to let the block 232 know pertinent information. The BIC is created from the block's unique configuration file and other information that is dynamically generated during startup. An example of a configuration file for the block "SimulationBlock" of Fig. 10 is shown below:

{

attributes" : [

{

name

value": { "end" : -1,

"start": 0,

"step" : 1

}

}

],

"interval": {

"days": 0,

"microseconds": 0,

"seconds" : 1

},

"logjevel" : "ERROR",

"name" : "SimulationBlock",

"signal_count": 1,

"signal_type": "nio.common.signal.base.Signal",

"type": "Simulator"

}

[0153] The BIC may include information on a block router, block properties, component data, hooks, a service name, a command URL, and a management signal handler. The block router information refers to an instance of the block router 421 that the service 230 will use. The block properties information refers to a dictionary of configured properties for the given block 230. The component data information refers to any data that the core components 412 wish to pass to the block 232. The hooks information refers to system-wide hooks that are available for the block 232 to subscribe to. The service name information refers to the name of the service 230 (e.g., MyService) containing the block 232. The command URL information refers to an accessible URL for the block 232 that enables the block 232 to let external sources know where the block 232 is located. The management signal handler information refers to a method that can be used by the block 232 to notify management signals.

[0154] In the present example, neither the block's configuration file nor the BIC has any information about the other blocks 232 in the service 230. Instead, the SIC (via the service configuration file) contains the list of which blocks 232 send output to which other blocks 232. [0155] When the block class gets configured, it takes the block properties that were passed and cross references its class metadata properties. It then sets the properties so that instances of the block 232 can use the properties with which it was configured.

[0156] In addition to the general initialization process, a block 232 can be made to perform actions based on start/stop/configure events by overriding methods that are hooked to these events. For example, a user can make a block 232 perform an action when the block 232 is configured by creating an "on_configure" method in the block 232. There are some limitations on actions performed during a specific event.

[0157] On creation, a block 232 can be instructed to initialize any variables. This can be used to set the variables to a default value.

[0158] On configure, the block 232 can be instructed to prepare for handling signals. After a block 232 is configured, it should be assumed that the block 232 can process signals from another block 232. This means that a block 232 that is to log signals to a database should create its database connection in the configure call. No blocks 232 should notify signals or do anything that will cause notification of signals in the configure method.

[0159] On start, the block 232 can be instructed to perform any actions that could result in notifying signals. For a simulator, this means starting the simulator job that will notify signals here. A block 232 should not send/notify any signals until it is started. Note that no block 232 will be started until all blocks 232 are configured. This is important because once a block 232 is started, it should be assumed that the block 232 will notify signals and a block 232 must be configured to handle signals.

[0160] The initialization processes for the block router 421 and blocks 232 are interleaved. The block router 421 is instantiated before the blocks 232 are initialized, but is not configured until after the blocks 232 are initialized. This is because the blocks 232 need to know information about the block router 421 when the blocks 232 are initialized, and the block router initialization relies on a Block Router Initialization Context (BRIC) that is created by the service process for the main service 230 using information from the blocks 232.

[0161] Accordingly, after all of the blocks 232 for the service 230 have been created and configured with their respective BICs, the BRIC is created and the instances of those blocks 232 are passed to it. The BRIC gets passed to the block router 421 of the service 230 so that the block router 421 knows how to route signals between the blocks 232. Without receiving this information from the service 230, the block router 421 will not know where to pass signals when a particular block 232 in the service 230 notifies the service that it has output. [0162] Information contained within the BRIC includes execution and blocks. The execution information refers to a list of block execution routings (e.g., similar to what is in the service's .cfg file). The blocks information refers to a dictionary mapping of block names to instances of blocks.

[0163] Referring to FIG. 11, a method 1100 illustrates one embodiment of a process that may be executed by the NIO platform of FIG. 7 to create and configure various components during startup. In step 1102, a core server 228 of the NIO platform 602 is configured. In step 1104, a CIC is created using information from modules 404 and core components 412. In step 1106, an SIC is created for a service 230 using information from the CIC and the service's configuration information. In step 1108, the service 230 is configured using the SIC. In step 1110, a BIC is created for each block 232 in the service 230 using the SIC and the block's configuration information. In step 1112, each block 232 is configured using its respective BIC.

[0164] Referring to FIG. 12, a method 1200 illustrates one embodiment of a process that may be executed by the NIO platform of FIG. 7 to create and configure various components. In step 1202, a core server 228 of the NIO platform 602 receives a command to start a service 230. In step 1204, an SIC is created for the service 230 using information from a CIC and the service's configuration information. In step 1206, the service 230 is configured using the SIC. In step 1208, a BIC is created for each block 232 in the service 230 using the SIC and the block's configuration information. In step 1210, each block 232 is configured using its respective BIC.

[0165] Referring to FIG. 13, a method 1300 illustrates one embodiment of a process that may be executed by the NIO platform of FIG. 7 to create and configure various components. In step 1302, a service 230 is configured using an SIC and the service's configuration information. In step 1304, a block router 421 is started for the service 230. In step 1306, a BIC is created for each block 232 in the service 230 using the SIC and the block's configuration information. In step 1308, each block 232 is configured using its respective BIC. In step 1310, a BRIC is created using information from the blocks 232. In step 1312, the block router 421 is configured using the BRIC.

[0166] While the preceding description shows and describes one or more embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the present disclosure. For example, various steps illustrated within a particular flow chart may be combined or further divided. In addition, steps described in one diagram or flow chart may be incorporated into another diagram or flow chart. Furthermore, the described functionality may be provided by hardware and/or software, and may be distributed or combined into a single platform. Additionally, functionality described in a particular example may be achieved in a manner different than that illustrated, but is still encompassed within the present disclosure. Therefore, the claims should be interpreted in a broad manner, consistent with the present disclosure.

[0167] For example, in one embodiment, a method for configuring a platform instance at runtime includes configuring, by a core process of a platform instance running on a digital device and interacting with an operating system of the digital device, a core server for the platform instance using a predefined core configuration file; creating, by the core server, a core initialization context (CIC) that contains dynamically generated information about the platform instance, wherein the dynamically generated information only becomes available during configuration of the core server; creating, by the core server, a service initialization context (SIC) for a service that is to be run as part of the platform instance, wherein the SIC includes service configuration information from a predefined service configuration file and the CIC; configuring the service for operation within the platform instance using the service configuration information in the SIC; creating a block initialization context (BIC) for a block that is to be used to provide task specific functionality for the service, wherein the BIC includes block configuration information from a predefined block configuration file and the SIC; and configuring the block for operation within the service using the block configuration information in the BIC.

[0168] In some embodiments, the method further includes creating a block router initialization context (BRIC); and configuring a block router for the service using the BRIC so that the block router can route data between the block and at least one other block that is part of the service.

[0169] In some embodiments, the method further includes starting, by the core server, at least one module that is capable of providing functionality to the service; configuring the module using a predefined module configuration file, wherein the configuring generates module-specific information; and updating the CIC with at least a portion of the module- specific information.

[0170] In some embodiments, the method further includes detecting, by the core server, whether the service needs the functionality provided by the module; and adding at least a portion of the module-specific information in the CIC to the SIC only if the service needs the functionality provided by the module. [0171] In some embodiments, the method further includes starting, by the core server, at least one core component of the core server; configuring the core component using information from the CIC, wherein the configuring generates core component-specific information; and updating the CIC with at least a portion of the core component-specific information.

[0172] In some embodiments, the core component is configured after the CIC is updated with the module-specific information.

[0173] In some embodiments, the platform instance is configured to run a plurality of services, and wherein a unique SIC is created for each of the plurality of services.

[0174] In some embodiments, each of the plurality of services corresponds to a service configuration file that is unique to that service.

[0175] In some embodiments, the service is configured to run a plurality of blocks, and wherein a unique BIC is created for each of the plurality of blocks.

[0176] In some embodiments, each of the plurality of blocks corresponds to a block configuration file that is unique to that block.

[0177] In some embodiments, the SIC contains all the information sent to the service by the core server and contains all information about the platform instance needed by the service to operate.

[0178] In some embodiments, the method further includes shutting down the service by the core server, wherein the core server continues running after shutting down the service; and re-launching the service by the core server, wherein re-launching the service includes creating a new SIC for the service; configuring the service using the new SIC; creating a new BIC for the block; andconfiguring the block using the new BIC.

[0179] In some embodiments, the method further includes pausing the service by the core server, wherein the service is paused with a first configuration; and restarting the service by the core server after the service has been paused, wherein the service maintains the first configuration after being restarted.

[0180] In some embodiments, the method further includes generating, within a configuration environment that is separate from the platform instance, the core configuration file, the service configuration file, and the block configuration file; and making the core configuration file, the service configuration file, and the block configuration file accessible to the core process prior to configuring the core server.

[0181] In some embodiments, the method further includes passing the SIC to the service, wherein the step of configuring the service for operation is performed by the service. [0182] In some embodiments, the method further includes passing the BIC to the block, wherein the step of configuring the block for operation is performed by the block.

[0183] In some embodiments, the method further includes running the service to process input signals using the block.

[0184] In some embodiments, the method further includes launching the core process on the digital device to start the platform instance, wherein the platform instance is run as a first application by the operating system.

[0185] In some embodiments, the method further includes starting a second platform instance on the digital device, wherein the second platform instance is run by the operating system as a second application that is separate from the first application.

[0186] In some embodiments, the method further includes updating, via the core server, the service configuration file to create an updated service configuration file; stopping, by the core server, the service after the updated service configuration file is created; and restarting, by the core server, the service using the updated service configuration file.

[0187] In another embodiment, a method for configuring a service within a platform instance at runtime includes instantiating the service from a base service class that is usable to instantiate a plurality of different services within the platform instance; configuring the service for operation within the platform instance using information contained in a service initialization context (SIC), wherein the SIC includes configuration information from a predefined service configuration file and dynamically generated configuration information that was not defined until a core process of the platform instance was launched; instantiating a plurality of blocks from a plurality of block classes; and configuring each of the plurality of blocks for operation within the service using information contained in a block initialization context (BIC), wherein the BIC includes configuration information from a predefined block configuration file and the SIC.

[0188] In some embodiments, the method further includes configuring a block router that is part of the service using information that is contained in a block router initialization context (BRIC), wherein the BRIC contains source/destination information needed by the block router for routing messages among the plurality of blocks.

[0189] In some embodiments, each block corresponds to a unique BIC and a unique predefined block configuration file.

[0190] In some embodiments, the method further includes passing the SIC to the service, wherein the step of configuring the service is performed by the service. [0191] In some embodiments, the method further includes passing the BIC to each of the plurality of blocks, wherein the step of configuring each of the plurality of blocks includes each block configuring itself using the BIC.

[0192] In some embodiments, the method further includes discovering the service and the plurality of blocks using an auto-discovery process, wherein the auto-discovery process determines which services the platform instance is configured to run.

[0193] In some embodiments, the method further includes shutting down the service without shutting down the platform instance; and re-launching the service, wherein relaunching the service includes creating a new SIC for the service; configuring the service using the new SIC; creating a new BIC for the plurality of blocks; and configuring the plurality of blocks using the new BIC.

[0194] In some embodiments, the method further includes pausing the service, wherein the service is paused while being configured with a first configuration; and restarting the service after the service has been paused, wherein the service maintains the first configuration after being restarted.

[0195] In some embodiments, the method further includes pausing the service, wherein the service is paused while being configured with a first configuration; and restarting the service after the service has been paused, wherein the service is restarted with a second configuration.

[0196] In some embodiments, the BIC contains no information linking any of the plurality of blocks to any other block and wherein each block is unaware of the other blocks when the service is running.

[0197] In some embodiments, the method further includes running the service to process input signals using the plurality of blocks.

[0198] In another embodiment, a method for configuring a plurality of services for use within a platform instance includes launching a core process of the platform instance on a digital device, wherein the core process interacts with an operating system of the digital device; configuring a plurality of services to be run simultaneously by the platform instance, wherein each service provides task specific functionality to the platform instance, and wherein each service is configured using both predefined service configuration information unique to that service and dynamically generated configuration information that is not available until the core process is launched; and instantiating and configuring a plurality of blocks, wherein each block corresponds to one of the plurality of services and provides task specific functionality to the corresponding service, and wherein each block is configured using predefined block configuration information unique to that block and at least a portion of the dynamically generated configuration information.

[0199] In another embodiment, a method for configuring a platform instance at runtime includes configuring a core process of a platform instance using a core configuration file, wherein the core process is run on a digital device and interacts with an operating system of the digital device; creating, by the core process, a module context for at least one module; creating, by the core process, a service initialization context (SIC) for a service to be started by the core process, wherein the SIC includes information from the module context and a service configuration file corresponding to the service; launching, by the core process, the service; passing, by the core process, the SIC to the service; configuring, by the service, the service using the SIC; creating, by the service, a block initialization context (BIC) for each of a plurality of blocks to be used by the service, wherein each BIC includes information from the SIC and a block configuration file corresponding to the block for which the BIC is being created; launching, by the service, the plurality of blocks; passing, by the service, to each block the BIC corresponding to the block; configuring, by each block, the block using the BIC; creating, by the service process, a block router initialization context (BRIC); passing the BRIC to a block router of the service; and configuring, by the block router, the block router using the BRIC so that the block router can transfer information between the blocks.

[0200] In another embodiment, a system includes a processor; and a memory coupled to the processor and containing instructions for execution by the processor, the instructions for: launching a core process of a platform instance, wherein the core process is launched by the processer using an operating system stored in the memory; configuring, by the core process, a core server for the platform instance using a predefined core configuration file; creating, by the core server, a core initialization context (CIC) that contains dynamically generated information about the platform instance, wherein the dynamically generated information only becomes available during configuration of the core server; creating, by the core server, a service initialization context (SIC) for a service that is to be run as part of the platform instance, wherein the SIC includes service configuration information from a predefined service configuration file and the CIC; configuring the service for operation within the platform instance using the service configuration information in the SIC; creating a block initialization context (BIC) for a block that is to be used to provide task specific functionality for the service, wherein the BIC includes block configuration information from a predefined block configuration file and the SIC; and configuring the block for operation within the service using the block configuration information in the BIC. [0201] In some embodiments, the instructions further include instructions for creating a block router initialization context (BRIC); and configuring a block router for the service using the BRIC so that the block router can route data between the block and at least one other block that is part of the service.

[0202] In some embodiments, the instructions further include instructions for: starting, by the core server, at least one module that is capable of providing functionality to the service; configuring the module using a predefined module configuration file, wherein the configuring generates module-specific information; and updating the CIC with at least a portion of the module-specific information.

[0203] In some embodiments, the instructions further include instructions for: detecting, by the core server, whether the service needs the functionality provided by the module; and adding at least a portion of the module-specific information in the CIC to the SIC only if the service needs the functionality provided by the module.

[0204] In some embodiments, the instructions further include instructions for: starting, by the core server, at least one core component of the core server; configuring the core component using information from the CIC, wherein the configuring generates core component-specific information; and updating the CIC with at least a portion of the core component-specific information.

[0205] In some embodiments, the core component is configured after the CIC is updated with the module-specific information.

[0206] In some embodiments, the platform instance is configured to run a plurality of services, and wherein a unique SIC is created for each of the plurality of services.

[0207] In some embodiments, each of the plurality of services corresponds to a service configuration file that is unique to that service.

[0208] In some embodiments, the service is configured to run a plurality of blocks, and wherein a unique BIC is created for each of the plurality of blocks.

[0209] In some embodiments, each of the plurality of blocks corresponds to a block configuration file that is unique to that block.

[0210] In some embodiments, the SIC contains all the information sent to the service by the core server and contains all information about the platform instance needed by the service to operate.

[0211] In some embodiments, the instructions further include instructions for: shutting down the service by the core server, wherein the core server continues running after shutting down the service; and re-launching the service by the core server, wherein re-launching the service includes creating a new SIC for the service; configuring the service using the new SIC; creating a new BIC for the block; and configuring the block using the new BIC.

[0212] In some embodiments, the instructions further include instructions for: pausing the service by the core server, wherein the service is paused with a first configuration; and restarting the service by the core server after the service has been paused, wherein the service maintains the first configuration after being restarted.

[0213] In some embodiments, the instructions further include instructions for: generating, within a configuration environment that is separate from the platform instance, the core configuration file, the service configuration file, and the block configuration file; and making the core configuration file, the service configuration file, and the block configuration file accessible to the core process prior to configuring the core server.

[0214] In some embodiments, the instructions further include instructions for passing the SIC to the service, wherein the step of configuring the service for operation is performed by the service.

[0215] In some embodiments, the instructions further include instructions for passing the BIC to the block, wherein the step of configuring the block for operation is performed by the block.

[0216] In some embodiments, the instructions further include instructions for running the service to process input signals using the block.

[0217] In some embodiments, launching the core process to start the platform instance includes running the platform instance as a first application on the operating system.

[0218] In some embodiments, the instructions further include instructions for starting a second platform instance, wherein the second platform instance is run by the operating system as a second application that is separate from the first application.

[0219] In some embodiments, the instructions further include instructions for updating, via the core server, the service configuration file to create an updated service configuration file; stopping, by the core server, the service after the updated service configuration file is created; and restarting, by the core server, the service using the updated service configuration file.

[0220] In another embodiment, a system includes a processor; and a memory coupled to the processor and containing instructions for execution by the processor, the instructions for: launching a platform instance, wherein the platform instance interacts with an operating system stored in the memory; instantiating a service of the platform instance from a base service class that is usable to instantiate a plurality of different services within the platform instance; configuring the service for operation within the platform instance using information contained in a service initialization context (SIC), wherein the SIC includes configuration information from a predefined service configuration file and dynamically generated configuration information that was not defined until a core process of the platform instance was launched; instantiating a plurality of blocks from a plurality of block classes; and configuring each of the plurality of blocks for operation within the service using information contained in a block initialization context (BIC), wherein the BIC includes configuration information from a predefined block configuration file and the SIC.

[0221] In some embodiments, the instructions further include instructions for configuring a block router that is part of the service using information that is contained in a block router initialization context (BRIC), wherein the BRIC contains source/destination information needed by the block router for routing messages among the plurality of blocks.

[0222] In some embodiments, each block corresponds to a unique BIC and a unique predefined block configuration file.

[0223] In some embodiments, the instructions further include instructions for passing the SIC to the service, wherein the step of configuring the service is performed by the service.

[0224] In some embodiments, the instructions further include instructions for passing the BIC to each of the plurality of blocks, wherein the step of configuring each of the plurality of blocks includes each block configuring itself using the BIC.

[0225] In some embodiments, the instructions further include instructions for discovering the service and the plurality of blocks using an auto-discovery process, wherein the auto- discovery process determines which services the platform instance is configured to run.

[0226] In some embodiments, the instructions further include instructions for: shutting down the service without shutting down the platform instance; and re-launching the service, wherein re-launching the service includes creating a new SIC for the service; configuring the service using the new SIC; creating a new BIC for the plurality of blocks; and configuring the plurality of blocks using the new BIC.

[0227] In some embodiments, the instructions further include instructions for: pausing the service, wherein the service is paused while being configured with a first configuration; and restarting the service after the service has been paused, wherein the service maintains the first configuration after being restarted.

[0228] In some embodiments, the instructions further include instructions for pausing the service, wherein the service is paused while being configured with a first configuration; and restarting the service after the service has been paused, wherein the service is restarted with a second configuration.

[0229] In some embodiments, the BIC contains no information linking any of the plurality of blocks to any other block and wherein each block is unaware of the other blocks when the service is running.

[0230] In some embodiments, the instructions further include instructions for running the service to process input signals using the plurality of blocks.

[0231] In another embodiment, a system includes a processor; and a memory coupled to the processor and containing instructions for execution by the processor, the instructions for: launching a core process of a platform instance, wherein the core process interacts with an operating system stored in the memory; configuring a plurality of services to be run simultaneously by the platform instance, wherein each service provides task specific functionality to the platform instance, and wherein each service is configured using both predefined service configuration information unique to that service and dynamically generated configuration information that is not available until the core process is launched; and instantiating and configuring a plurality of blocks, wherein each block corresponds to one of the plurality of services and provides task specific functionality to the corresponding service, and wherein each block is configured using predefined block configuration information unique to that block and at least a portion of the dynamically generated configuration information.

[0232] In another embodiment, a system includes a processor; and a memory coupled to the processor and containing instructions for execution by the processor, the instructions for: configuring a core process of a platform instance using a core configuration file, wherein the core process interacts with an operating system stored in the memory; creating, by the core process, a module context for at least one module; creating, by the core process, a service initialization context (SIC) for a service to be started by the core process, wherein the SIC includes information from the module context and a service configuration file corresponding to the service; launching, by the core process, the service; passing, by the core process, the SIC to the service; configuring, by the service, the service using the SIC; creating, by the service, a block initialization context (BIC) for each of a plurality of blocks to be used by the service, wherein each BIC includes information from the SIC and a block configuration file corresponding to the block for which the BIC is being created; launching, by the service, the plurality of blocks; passing, by the service, to each block the BIC corresponding to the block; configuring, by each block, the block using the BIC; creating, by the service process, a block router initialization context (BRIC); passing the BRIC to a block router of the service; and configuring, by the block router, the block router using the BRIC so that the block router can transfer information between the blocks.

Claims

WHAT IS CLAIMED IS:

1. A method for configuring a platform instance at runtime, the method characterized by:

configuring, by a core process of a platform instance running on a digital device and interacting with an operating system of the digital device, a core server for the platform instance using a predefined core configuration file;

creating, by the core server, a core initialization context (CIC) that contains dynamically generated information about the platform instance, wherein the dynamically generated information only becomes available during configuration of the core server;

creating, by the core server, a service initialization context (SIC) for a service that is to be run as part of the platform instance, wherein the SIC includes service configuration information from a predefined service configuration file and the CIC; configuring the service for operation within the platform instance using the service configuration information in the SIC;

creating a block initialization context (BIC) for a block that is to be used to provide task specific functionality for the service, wherein the BIC includes block configuration information from a predefined block configuration file and the SIC; and configuring the block for operation within the service using the block configuration information in the BIC.

2. The method of claim 1 characterized by:

creating a block router initialization context (BRIC); and

configuring a block router for the service using the BRIC so that the block router can route data between the block and at least one other block that is part of the service.

The method of any one of claims 1 or 2 characterized by:

starting, by the core server, at least one module that is capable of providing functionality to the service;

configuring the module using a predefined module configuration file, wherein the configuring generates module-specific information; and

updating the CIC with at least a portion of the module-specific information.

4. The method of claim 3 characterized by:

detecting, by the core server, whether the service needs the functionality provided by the module; and

adding at least a portion of the module-specific information in the CIC to the SIC only if the service needs the functionality provided by the module.

5. The method of claim 3 characterized by:

starting, by the core server, at least one core component of the core server; configuring the core component using information from the CIC, wherein the configuring generates core component-specific information; and

updating the CIC with at least a portion of the core component-specific information.

6. The method of claim 5 wherein the core component is configured after the CIC is updated with the module-specific information.

7. The method of any one of claims 1 through 6 wherein the platform instance is configured to run a plurality of services, and wherein a unique SIC is created for each of the plurality of services.

8. The method of claim 7 wherein each of the plurality of services corresponds to a service configuration file that is unique to that service.

9. The method of any one of claims 1 through 8 wherein the service is configured to run a plurality of blocks, and wherein a unique BIC is created for each of the plurality of blocks.

10. The method of claim 9 wherein each of the plurality of blocks corresponds to a block configuration file that is unique to that block.

11. The method of any one of claims 1 through 10 wherein the SIC contains all the information sent to the service by the core server and contains all information about the platform instance needed by the service to operate.

12. The method of any one of claims 1 through 11 characterized by:

shutting down the service by the core server, wherein the core server continues running after shutting down the service; and

re-launching the service by the core server, wherein re-launching the service includes

creating a new SIC for the service;

configuring the service using the new SIC;

creating a new BIC for the block; and

configuring the block using the new BIC.

13. The method of claim 12 characterized by:

pausing the service by the core server, wherein the service is paused with a first configuration; and

restarting the service by the core server after the service has been paused, wherein the service maintains the first configuration after being restarted.

14. The method of any one of claims 1 through 13 characterized by:

generating, within a configuration environment that is separate from the platform instance, the core configuration file, the service configuration file, and the block configuration file; and

making the core configuration file, the service configuration file, and the block configuration file accessible to the core process prior to configuring the core server.

15. The method of any one of claims 1 through 14 characterized by passing the SIC to the service, wherein the step of configuring the service for operation is performed by the service.

16. The method of any one of claims 1 through 15 characterized by passing the BIC to the block, wherein the step of configuring the block for operation is performed by the block.

17. The method of any one of claims 1 through 16 characterized by running the service to process input signals using the block.

18. The method of any one of claims 1 through 17 characterized by launching the core process on the digital device to start the platform instance, wherein the platform instance is run as a first application by the operating system.

19. The method of claim 18 characterized by starting a second platform instance on the digital device, wherein the second platform instance is run by the operating system as a second application that is separate from the first application.

20. The method of any one of claims 1 through 19 characterized by:

updating, via the core server, the service configuration file to create an updated service configuration file;

stopping, by the core server, the service after the updated service configuration file is created; and

restarting, by the core server, the service using the updated service configuration file.

21. A system characterized by :

a processor; and

a memory coupled to the processor and containing instructions for execution by the processor, the instructions for:

launching a core process of a platform instance, wherein the core process is launched by the processer using an operating system stored in the memory;

configuring, by the core process, a core server for the platform instance using a predefined core configuration file;

creating, by the core server, a core initialization context (CIC) that contains dynamically generated information about the platform instance, wherein the dynamically generated information only becomes available during configuration of the core server;

creating, by the core server, a service initialization context (SIC) for a service that is to be run as part of the platform instance, wherein the SIC includes service configuration information from a predefined service configuration file and the CIC; configuring the service for operation within the platform instance using the service configuration information in the SIC;

creating a block initialization context (BIC) for a block that is to be used to provide task specific functionality for the service, wherein the BIC includes block configuration information from a predefined block configuration file and the SIC; and

configuring the block for operation within the service using the block configuration information in the BIC.

22. The system of claim 21 wherein the instructions further include instructions for:

creating a block router initialization context (BRIC); and

configuring a block router for the service using the BRIC so that the block router can route data between the block and at least one other block that is part of the service.

23. The system of any one of claims 21 or 22 wherein the instructions further include instructions for:

starting, by the core server, at least one module that is capable of providing functionality to the service;

configuring the module using a predefined module configuration file, wherein the configuring generates module-specific information; and

updating the CIC with at least a portion of the module-specific information.

24. The system of claim 23 wherein the instructions further include instructions for:

detecting, by the core server, whether the service needs the functionality provided by the module; and

adding at least a portion of the module-specific information in the CIC to the SIC only if the service needs the functionality provided by the module.

25. The system of claim 23 wherein the instructions further include instructions for:

starting, by the core server, at least one core component of the core server; configuring the core component using information from the CIC, wherein the configuring generates core component-specific information; and updating the CIC with at least a portion of the core component-specific information.

26. The system of claim 25 wherein the core component is configured after the CIC is updated with the module-specific information.

27. The system of any one of claims 21 through 26 wherein the platform instance is configured to run a plurality of services, and wherein a unique SIC is created for each of the plurality of services.

28. The system of claim 27 wherein each of the plurality of services corresponds to a service configuration file that is unique to that service.

29. The system of any one of claims 21 through 28 wherein the service is configured to run a plurality of blocks, and wherein a unique BIC is created for each of the plurality of blocks.

30. The system of claim 29 wherein each of the plurality of blocks corresponds to a block configuration file that is unique to that block.

31. The system of any one of claims 21 through 30 wherein the SIC contains all the information sent to the service by the core server and contains all information about the platform instance needed by the service to operate.

32. The system of any one of claims 21 through 31 wherein the instructions further include instructions for:

shutting down the service by the core server, wherein the core server continues running after shutting down the service; and

re-launching the service by the core server, wherein re-launching the service includes

creating a new SIC for the service;

configuring the service using the new SIC;

creating a new BIC for the block; and

configuring the block using the new BIC.

33. The system of claim 32 wherein the instructions further include instructions for:

pausing the service by the core server, wherein the service is paused with a first configuration; and

restarting the service by the core server after the service has been paused, wherein the service maintains the first configuration after being restarted.

34. The system of any one of claims 21 through 33 wherein the instructions further include instructions for:

generating, within a configuration environment that is separate from the platform instance, the core configuration file, the service configuration file, and the block configuration file; and

making the core configuration file, the service configuration file, and the block configuration file accessible to the core process prior to configuring the core server.

35. The system of any one of claims 21 through 34 wherein the instructions further include instructions for passing the SIC to the service, wherein the step of configuring the service for operation is performed by the service.

36. The system of any one of claims 21 through 35 wherein the instructions further include instructions for passing the BIC to the block, wherein the step of configuring the block for operation is performed by the block.

37. The system of any one of claims 21 through 36 wherein the instructions further include instructions for running the service to process input signals using the block.

38. The system of any one of claims 21 through 37 wherein launching the core process to start the platform instance includes running the platform instance as a first application on the operating system.

39. The system of claim 38 wherein the instructions further include instructions for starting a second platform instance, wherein the second platform instance is run by the operating system as a second application that is separate from the first application.

40. The system of any one of claims 21 through 39 wherein the instructions further include instructions for:

updating, via the core server, the service configuration file to create an updated service configuration file;

stopping, by the core server, the service after the updated service configuration file is created; and

restarting, by the core server, the service using the updated service configuration file.