WO2016156974A1

WO2016156974A1 - System and method for a development environment for building services for a platform instance

Info

Publication number: WO2016156974A1
Application number: PCT/IB2016/000467
Authority: WO
Inventors: Douglas A. STANDLEY; Matthew R. DODGE; Randall E. BYE
Original assignee: Societal Innovations Ipco Limited
Priority date: 2015-03-31
Filing date: 2016-03-30
Publication date: 2016-10-06

Abstract

An improved system and method are disclosed for creating a configuration for a platform instance using a development environment that has a graphical user interface (GUI). The method includes creating a service to be run by the platform instance and providing a graphical representation of a block library containing available blocks that are available for use by the service. Input is received via the GUI identifying at least some of the available blocks as selected blocks, where the selected blocks are to be run by the service. Input is received via the GUI arranging the selected blocks into an order of execution. The development environment generates and stores at least one configuration file containing the order of execution for use by the platform instance.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a Patent Cooperation Treat Application of U.S. Provisional Application No. 62/141,107, filed March 31, 2015, entitled SYSTEM AND METHOD FOR A DEVELOPMENT ENVIRONMENT FOR BUILDING SERVICES FOR A PLATFORM INSTANCE (Arty. Dkt. No. SNVS-32554), 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

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

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

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

[0006] 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;

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

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

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

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

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

[0012] FIG. 4 illustrates one embodiment of a workflow that may be used to create and configure a NIO platform; [0013] FIG. 5A illustrates one embodiment of a service configuration environment within which a service is configured at runtime;

[0014] FIG. 5B illustrates one embodiment of a block configuration environment within which a block is configured at runtime;

[0015] FIGS. 6A and 6B illustrate embodiments of block classes that may be used within the block configuration environment of FIG. 5B;

[0016] FIG. 7 illustrates one embodiment of an environment within which configuration information is used to configure two blocks based on the same block class in different ways;

[0017] FIG. 8 illustrates one embodiment of an environment within which configuration information is used to configure two services based on the same service class in different ways;

[0018] FIG. 9 illustrates one embodiment of an environment with a base block class and multiple blocks based on the base block class;

[0019] FIG. 10 illustrates one embodiment of a service built using blocks from the environment of FIG. 9;

[0020] FIG. 11 illustrates another embodiment of a service built using blocks from the environment of FIG. 9;

[0021] FIG. 12 illustrates an embodiment of an environment in which a NIO platform running the services of FIGS. 10 and 11 is coupled to external sources and/or destinations;

[0022] FIG. 13A illustrates one embodiment of a method that may be executed by the NIO platform of FIG. 12 to create and configure a block;

[0023] FIG. 13B illustrates one embodiment of a method that may be executed by the NIO platform of FIG. 12 to create and configure a service;

[0024] FIGS. 14A-14C illustrate embodiments of a development environment within which configuration of the NIO platform of FIG. 4 may occur;

[0025] FIGS. 15-26 illustrate embodiments of a graphical user interface (GUI) that may be provided by the development environment of FIGS. 14A-14C; and

[0026] FIGS. 27-31 illustrate embodiments of methods that maybe executed within the development environment of FIGS. 14A-14C.

DETAILED DESCRIPTION

[0027] The present disclosure is directed to a system and method for a development environment for creating services for a neutral input/output platform instance. 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 FIG. 4, a diagram 400 illustrates one embodiment of a workflow that runs from creation to launch of a NIO platform 402 (which may be similar or identical to the NIO platform 100 of FIG. 1A, 200 of FIG. 2 A, 400 of FIG. 4A, and/or 900 of FIGS. 9A and 9B). The workflow begins with a library 404. The library 404 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 406, and block classes 204 that are extended from the base block class 406. 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 404 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 404.

[0056] The configuration environment 408 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 404 in order to define the platform specific behavior of the objects that will be instantiated from the classes within the NIO platform 402. The NIO platform 402 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 402. 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 402.

[0057] In some embodiments, the configuration environment 408 may be a graphical user interface environment that produces configuration files that are loaded into the NIO platform 402. In other embodiments, the configuration environment 408 may use a REST interface (such as the REST interface 908, 964 disclosed in FIGS. 9A and 9B of PCT/IB2015/001288, filed on May 21, 2015, and entitled SYSTEM AND METHOD FOR FULLY CONFIGURABLE REAL TIME PROCESSING, which is incorporated by reference herein in its entirety) of the NIO platform 402 to issue configuration commands to the NIO platform 402. Accordingly, it is understood that there are various ways in which configuration information may be created and produced for use by the NIO platform 402.

[0058] When the NIO platform 402 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 402 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 402 is then configured and begins running to perform the task specific functions provided by the services.

[0059] Referring to FIG. 5A, one embodiment of a service configuration environment 500 within which a service 230 is configured at runtime is illustrated. Within the NIO platform 402, each service 230 is created using a class file 202 and configuration information 502. The configuration information includes predefined information that exists before runtime (e.g., as part of the platform configuration information 210 of FIG. 2 A) and information that is dynamically generated at runtime. The dynamically generated information is not known until the NIO platform 402 is launched and may include information described with respect to the environment 1300 of FIG. 13.

[0060] The class file 202 may be used by multiple services, but the configuration information 502 is unique to the particular service 230 being created. The configuration information 502 may be in a separate file for each service 230 or may be in a larger file from which a particular service's configuration information is extracted. At runtime, the class file 202 is instantiated and then the configuration information 502 is applied to the instantiated service object.

[0061] Referring to FIG. 5B, one embodiment of a block configuration environment 504 within which a block 232 is configured at runtime is illustrated. Within the NIO platform 402, each block 232 is created using a class file 204 and configuration information 506. The configuration information includes predefined information that exists before runtime (e.g., as part of the platform configuration information 210 of FIG. 2A) and information that is dynamically generated at runtime. The dynamically generated information is not known until the NIO platform 402 is launched and may include information described with respect to the environment 1300 of FIG. 13. [0062] The class file 204 may be used by multiple blocks, but the configuration information 506 is unique to the particular block 232 being created. The configuration information 506 may be in a separate file for each block 232 or may be in a larger file from which a particular block's configuration information is extracted. At runtime, the class file 204 is instantiated and then the configuration information 506 is applied to the instantiated block object.

[0063] Referring to FIGS. 6 A and 6B, embodiments of class files 204a and 204b for blocks 232a and 232b (not shown), respectively, are illustrated. Within the NIO platform 402, the service class files 202 and block class files 204 are based on a base service template (for services 230) and a base block template (for blocks 232), respectively. These base templates include NIO platform specific behavior that is inherited by any class that extends them. This means that each service class 202 and block class 204 inherits NIO platform specific behavior that allows the corresponding service 230 or block 232 to work within the NIO platform architecture. Without this NIO platform specific behavior, the class files 202 and 204 would not be recognized within the NIO platform architecture and so the corresponding services 230 and classes 232 could not be created. In addition to the NIO platform specific behavior, each block class 204 contains executable instructions that provide particular task specific functionality.

[0064] Referring specifically to FIG. 6A, the class file 204a for Block Class 1 includes the standard base block code for the NIO platform and also contains custom code for connecting to an external signal source, which is Twitter for purposes of example. Referring specifically to FIG. 6B, the class file 204b for Block Class 2 includes the standard base block code for the NIO platform and also contains custom code for sending email.

[0065] If there is not an existing block class that contains the code needed to perform a particular task, either a new block class can be created using the base block template or an existing block class 204 can be modified. While service classes 202 can also include custom code, they rarely do so because the base service template generally provides all the functionality needed for a service 230. However, it is understood that service classes 202 can also be customized.

[0066] Referring to FIG. 7, one embodiment of an environment 700 within which configuration information is used to configure two blocks 232 based on the same block class 204 in different ways is illustrated. The configuration information 506 (FIG. 5B) allows configuration of a particular block 232 at runtime by setting the values of configurable parameters defined within the block class 204. This means that the same block 232 can be configured in different ways depending on the values in the configuration information 506 that is used to configure the block 232.

[0067] The block class 204b (as shown in FIG. 6B) contains custom code to send any information received by the block 232 to a destination email address. The code includes a configurable parameter for the destination email address to avoid having to change the underlying block class 204 each time a different email address is used. This allows the email address to be defined in the configuration information 506, which means that the same block class 204 can be used to create multiple blocks that send their emails to different addresses.

[0068] Accordingly, in the present example, the block class 204b is to be used to instantiate two blocks 232a (also referred to as Block #1) and 232b (also referred to as Block #2). The blocks 232a and 232b are to be configured to send email to two different addresses using configuration information 506a (also referred to as Block #1 configuration information) and 506b (also referred to as Block configuration information #2), respectively. When the blocks 232a and 232b are instantiated and configured, the two blocks will have the same email sending functionality, but will send their emails to different email addresses.

[0069] Referring to FIG. 8, one embodiment of an environment 800 within which configuration information is used to configure two services 230 based on the same service class 202 in different ways is illustrated. The configuration information 502 (FIG. 5A) allows limited configuration of a particular service 230 at runtime by defining which blocks 232 are to be executed by the service and the order of execution of the blocks 232. The configuration information 502 may also be used to set the values of configurable parameters defined within the service class 202. This means that the same service 230 can be configured in different ways depending on the blocks 232, the order of execution, and the values in the configuration information 502 that is used to configure the service 230.

[0070] In the present example, the configuration information 502 for a service 230 includes source blocks and destination blocks needed to build a routing table when the service 230 is instantiated. Because the blocks 232 do not have any connection to each other except through the service 230, the service 230 uses the routing table to direct information from one block (a source block) to the next block (a destination block). The service 230 receives the source and destination blocks as configuration information after the service 230 is instantiated, so the same underlying service class 202 can be used for different services 230. This means that the services 230 can have different functionality based on the particular blocks 232 and block execution order defined in their configuration information 502. [0071] Accordingly, in the present example, a service class 202 is to be used to instantiate two services 230a (also referred to as Service #1) and 230b (also referred to as Service #2). The services 230a and 230b are to be configured using different blocks and different orders of execution using configuration information 502a (also referred to as Service #1 configuration information) and 502b (also referred to as Service configuration information #2), respectively. When the services 230a and 230b are instantiated and configured, the two services will have different functionality.

[0072] In the present example, the fact that a service 230 is made up of a service class 202 and configuration information 502 means that, prior to instantiation, there is no service class 202 that can be examined to determine the execution order of blocks 232, or even the blocks 232 that are to be used, within the service 230. To determine the behavior of the service 230, the configuration information 502 would have to be examined.

[0073] Referring to FIG. 9, one embodiment of an environment 900 is illustrated with a base block class 406 that is extended to create various customized block classes (not shown), such as those in the library 404 of FIG. 4. The customized block classes can then be instantiated as described previously to form various blocks 232a-232j . As described above, a NIO platform operates by using a service 230 to organize the appropriate blocks 232 to perform a particular task. In the present example, the blocks 232 do not have any connection to each other except through the service 230. This organizational structure provides benefits such as asynchronicity in block execution, dynamic expansion and retraction of block resources in response to input changes, and the ability to modify services 230 and blocks 232 without having to restart the NIO platform 402.

[0074] For example, as shown in FIG. 9, the environment 900 includes a block library that contains the ten blocks 232a-232j . Each of the blocks 232a-232j is built from the base block template, so each block is compatible with the NIO platform architecture. The blocks 232a-232j have no connection to each other except that all of them can operate within the NIO platform architecture. Each block 232a-232j contains task specific code that allows that block to perform a particular function. For example, the block 232a connects to Twitter, the block 232b sends an email containing any information received from another block, the block 232c connects to a machine in an assembly line, the block 232d filters any input received from another block for one or more defined text strings, the block 232e sends a signal to turn off the machine on the assembly line, and so on.

[0075] Assume that a user wants to create two different services 230a and 230b using the ten blocks 232a-232j. Service 230a is to monitor an external source (e.g., Twitter) Twitter for the words "company name" and send an email to userl@companyname.com if such a tweet is detected. Service 230b will monitor an assembly line machine for the occurrence of certain error codes and send an email to user2@companyname.com if an error is detected. Service 230b will also shut the machine down if an error is detected. Services 230a and 230b are to run simultaneously on a single NIO platform and perform their tasks asynchronously and in real time without any data storage.

[0076] With additional reference to FIG. 10, one embodiment of the service 230a is illustrated using blocks from the environment 900 of FIG. 9. Service 230a is created by identifying the needed block classes and defining their order of execution. For example, the block 232a (connecting to Twitter) will be followed by the block 232d (filtering for "company name"), and then the block 232b will send an email to userl@companyname if block 232d identifies any tweets with "company name." The block classes include configurable parameters that allow them to be customized without needing to open the block classes and change their code. FIG. 10 illustrates the configured appearance of the service 230a from a functional perspective.

[0077] The routing table for the service 230a defines the destination block for any output from a source block. If a block does not send output to another block (i.e., the block 232b), there is no entry in the routing table. There is no source block for block 232a because block 232a is connecting directly to Twitter. Table 1 illustrates an example of a routing table for the service 230a.

[0078]

Table 1

[0079] The decoupled nature of the blocks and the flexibility provided by the routing table allow the service 230a to be modified or blocks swapped for other blocks relatively easily. It is understood that any configuration changes and any new blocks must be loaded into the NIO platform (assuming the new blocks are not already there) and then the service 230a must be restarted for changes to take effect. For example, if a user wants to swap the email block 232b for a text message block, block 232b can be replaced with a suitably configured block for sending texts. If the block's name remains the same, the routing table may not even change in some embodiments. If the block's name is different, the routing table needs to be updated, but no other change may be needed. Table 2 illustrates an example of the routing table for the service 230a with the block 232b replaced by a text message block 232g.

[0080]

Table 2

[0081] If the user wants to send both the text message and the email, then the text message block 232g can be added so that it exists within the service 230a alongside the email block 232b. In this case, the routing table can be updated to include the new block 232g as another destination for source block 232d. Table 3 illustrates an example of the routing table for the service 230a with both block 232a and block 232g.

[0082]

Table 3

[0083] With additional reference to FIG. 11, one embodiment of the service 230b is illustrated using blocks from the environment 900 of FIG. 9. Service 230b is created by identifying the needed block classes and defining their order of execution. For example, the block 232c (connecting to the machine) will be followed by the block 232d (filtering against an error list). If an error is detected, the block 232b will send an email to user2@companyname and the block 232e will shut down the machine. The block classes include configurable parameters that allow them to be customized without needing to open the block classes and change their code. FIG. 11 illustrates the configured appearance of the service 230b from a functional perspective. Table 4 illustrates an example of a routing table for the service 230b. [0084]

Table 4

[0085] Referring to FIG. 12, one embodiment of the NIO platform 402 is shown within an environment 1200. The environment 1200 includes access to Twitter 1202 and a machine 1204. As shown, the NIO platform 402 includes a core 228 and is running the two services 230a and 230b simultaneously. Each service 230a and 230b performs its configured functions independently of the other service.

[0086] Referring to FIG. 13A, a method 1300 illustrates one embodiment of a process that may be executed by the NIO platform of FIG. 12 to create and configure a block 232. In step 1302, a block class 204 is identified along with the block's corresponding configuration information and dynamically generated information needed for the block 232. In step 1304, the block 232 is instantiated from the block class 204. In step 1306, the block 232 is configured using the corresponding configuration information and dynamically generated information.

[0087] Referring to FIG. 13B, a method 1310 illustrates one embodiment of a process that may be executed by the NIO platform of FIG. 12 to create and configure a service 230. In step 1312, a service class 202 is identified along with the service's corresponding configuration information and dynamically generated information needed for the service 230. In step 1314, the service 230 is instantiated from the service class 202. In step 1316, the service 230 is configured using the corresponding configuration information and dynamically generated information.

[0088] Referring to FIGS. 14A-14C, various embodiments of development environments 1400, 1410, and 1420 are illustrated. Each development environment 1400, 1410, and 1420 includes the configuration environment 408 of FIG. 4. The configuration environment 408 enables users to configure the NIO platform 402 on a device 124. Accordingly, the configuration environment 408 provides one or more command line and/or GUI interfaces that may be used to configure the NIO platform 402 with services and blocks.

[0089] The configuration environment 408 may interact with the NIO platform 402 using an API such as the REST API. As described in PCT/IB2015/001288, the REST API includes a block API, a block configuration API, and a service API. These APIs can be used to create, read, update and delete blocks and services. Accordingly, the configuration environment 408 may be used to configure the NIO platform 402 via the REST API while the NIO platform is running.

[0090] In other embodiments, the configuration environment 408 may enable a user to define a configuration of blocks and services for the NIO platform 402 without accessing the NIO platform 402 while the configuration is being defined. The configuration can then be loaded into the NIO platform 402 at a later time, either through the API when the NIO platform 402 is running or directly into a memory for later use by the NIO platform 402 (e.g., when the NIO platform is started or restarted). The memory may be a memory of the device 124, or may be a memory that is remote from the device 124 (e.g., a server or the cloud) but accessible to the NIO platform 402 for later use.

[0091] Referring specifically to FIG. 14A, one embodiment of the development environment 1400 is illustrated. The development environment 1400 includes the configuration environment 408 of FIG. 4 that can be used to configure the NIO platform 402 on the device 124. In the present example, the configuration environment 408 is provided as an API client 1402 that is running within a browser or other application 1404. The API client 1402 is able to interact directly with the NIO platform 402 and can either configure the NIO platform 402 while the instance is running (e.g., via the REST interface) or before the instance is launched (e.g., by saving the configuration into a memory accessible to the NIO platform 402). The direct interaction via the API client 1402 enables the NIO platform 402 to be directly configured any time the NIO platform can be accessed.

[0092] Referring specifically to FIG. 14B, one embodiment of the development environment 1410 is illustrated. The development environment 1410 includes the configuration environment 408 of FIG. 4 that can be used to configure the NIO platform 402 on the device 124. In the present example, the configuration environment 408 is part of the NIO platform 402 and enables a user to configure the NIO platform 402 any time the NIO platform can be accessed.

[0093] Referring specifically to FIG. 14C, one embodiment of the development environment 1420 is illustrated. The development environment 1420 includes the configuration environment 408 of FIG. 4 that can be used to configure the NIO platform 402 on the device 124. In the present example, the configuration environment 408 is provided as a server/cloud application or service. The configuration environment 408 may be configured to interact directly with the NIO platform 402 or may be configured to enable a platform configuration to be created/modified and then later transferred to the NIO platform 402.

[0094] Referring to FIG. 15, one embodiment of the configuration environment 408 is illustrated. The configuration environment 408 includes a GUI 1500 that enables a user to create and/or edit services 230 and blocks 232 (not shown). The configuration environment 408 produces configuration files that are used by services 230 and blocks 232 as previously described. For purposes of example, the configuration environment 408 is accessing the NIO platform 402 as illustrated in FIG. 14A and the NIO platform 402 is running. However, similar or identical steps may be used when creating a configuration for a NIO platform that is not running or is not currently accessible by the configuration environment 408. In such embodiments, the output of the configuration environment 408 may be saved and later transferred to or otherwise accessed by the NIO platform 402.

[0095] The GUI 1500 includes block buttons 1502a-1502M that correspond to various blocks in a library (e.g., the library 404 of FIG. 4). For purposes of example, the block buttons 1502a-1502j correspond to blocks 232a-232j of FIG. 9. Additional blocks are represented by block button 1502M. Some or all of the block buttons 1502a-1502M correspond to toggles 1504, which will be described later in greater detail.

[0096] An "Add Block" button 1506 enables a user to add a block to the NIO platform 402 without restarting the platform instance. A "Reload Block" button 1508 enables a user to reload a block in the platform instance without restarting the platform instance. An "Add Service" button 1510 enables a user to add a service to a platform configuration. A "Save Block" button 1512 enables a user to save a block configuration. A "Save Block As" button 1514 enables a user to save a block configuration under a different name. A "Delete Block" button 1516 enables a user to delete a block from a service.

[0097] A "Save Service" button 1512 enables a user to save a service configuration. A "Save Service As" button 1514 enables a user to save a service configuration under a different name. A "Delete Service" button 1516 enables a user to delete a service from a platform configuration. A "Start Service" button 1524 enables a user to start a service on the NIO platform 402. In embodiments where the configuration environment 408 is not interacting directly with a running NIO platform instance, the "Start Service" button 1524 may not be present, may be deactivated so that a user cannot interact with it, or may be used to set a configuration value that is later used to start the service when the NIO platform 402 is accessible. [0098] A block configuration pane 1526 provides a display area within which configuration values can be assigned to block parameters, as will be described later in greater detail. A "Service List" button 1528 provides a "home" button that can be used to return to a list of services that the platform instance is configured to run.

[0099] Referring to FIG. 16, one embodiment of the GUI 1500 is illustrated after the "Add Service" button 1510 has been selected to create a new service. A service pane 1602 represents the new service that has been created. As indicated by the service pane 1602, the new service is named "Service 1" (denoted by reference number 1600) and for purposes of example is the service 230a of FIG 8. The service pane 1602 includes multiple buttons that can be used to affect the service 230a. A "Stop" button 1604 enables a user to stop the service 230a when the service is running. A "Clone" button 1606 enables a user to create a duplicate of the service 230a. A "Modify" button 1608 enables a user to edit the service 230a. A "Delete" button 1610 enables a user to remove the service 230a from the NIO platform 402.

[0100] An indicator 1612 may be used visually indicate a current status (e.g., running or stopped) of the service 230a. For example, in FIG. 16, the indicator 1612 may be red in color to indicate that the service 230a is currently stopped. If the service 230a is started, the indicator 1612 may change color (e.g., to green) to indicate that the service 230a is currently running. The service pane 1602 may also indicate via text or in another manner whether the service 230a is set to auto start. In the current example, the text (denoted by reference number 1614) indicates that the service 230a is set to auto start.

[0101] Referring to FIG. 17, one embodiment of the GUI 1500 is illustrated after the "Modify" button 1608 has been selected to edit the service 230a. A service builder pane 1702 is now visible. In addition, a selectable tab 1704 for "Service 1" may be added to indicate the current service for which the service builder pane 1702 is being viewed and/or to enable a user to return to the service builder pane 1702 for the service 230a if at another location in the configuration environment 408.

[0102] Also illustrated in FIG. 17 is the function of the toggles 1504 that correspond to the block buttons 1502a-1502M. Each block button 1502a-1502M represents a block that is based on a particular block class. For example, the block button 1502d corresponds to a Block 4 (as described with respect to the service 230a in FIGS. 9 and 10). However, there may be different configurations saved for that Block 4. Continuing the example of FIGS. 9 and 10, the filter block 232d is configured to filter for the term "companyname," which is defined as a value for a configurable parameter. Other filter configurations for Block 4 may contain other values for the same configurable parameter. [0103] Accordingly, actuating the toggle 1504 next to the Block 4 reveals the various configurations that are available for Block 4. The present example includes three configurations for Block 4: Block 4a, Block 4b, and Block 4c. For purposes of illustration, Block 4b is the configuration that corresponds to the desired functionality for block 232d. In other words, Block 4b is already configured to filter for "companyname." It is understood that a block button 1502a-1502M corresponding to a block that has no configuration or only a single configuration may not have a corresponding toggle 1504 or, if there is a corresponding toggle 1504, actuating the toggle 1504 may have no affect (e.g., no configurations would be displayed).

[0104] Referring to FIG. 18, one embodiment of the GUI 1500 is illustrated after Block 1 , Block 4b, and Block 2 have been selected for the service 230a. Block 1, Block 4b, and Block 2 correspond to blocks 232a, 232d, and 232b of FIG. 10, respectively. As a result of being selected, Block 1, Block 4b, and Block 2 are now visible in the service builder pane 1702.

[0105] In the GUI 1500, each Block 1, Block 4b, and Block 2 is illustrated with at least one entry point and at least one exit point. For example, Block 1 includes an entry point 1802 and an exit point 1804. Block 4b includes an entry point 1806 and an exit point 1808. Block 2 includes an entry point 1810 and an exit point 1812. Although not shown, a block with multiple entry and/or exit points may display the multiple points and, in some embodiments, mark them so that a user can distinguish between the points if needed.

[0106] Referring to FIG. 19, one embodiment of the GUI 1500 is illustrated after Block 1, Block 4b, and Block 2 have been connected. More specifically, the exit point 1804 of Block 1 is connected to the entry point 1806 of Block 4b by a line 1902, with an arrow indicating the direction of flow. Accordingly, any niograms output by Block 1 are to flow to Block 4b. Similarly, the exit point 1808 of Block 4b is connected to the entry point 1810 of Block 2 by a line 1904, with an arrow indicating the direction of flow. Accordingly, any niograms output by Block 4b are to flow to Block 2.

[0107] To create these connections, a user may interact with the service builder pane 1702, dragging a line from an exit point to an entry point or using other processes to create a flow between various blocks. The configuration environment 408 then creates the needed logic for the service 230a. This logic defines the source and destination blocks for the service 230a, such as are illustrated in the routing table of Table 1.

[0108] Referring to FIG. 20, one embodiment of the GUI 1500 is illustrated after Block 1 has been selected. As shown in the block configuration pane 1526, Block 1 (which corresponds to block 232a of FIG. 10), has a configuration parameter 2002 for access credentials needed to access Twitter. Any needed access credential values are entered, which enables the block 232a to access Twitter. The "Save Block" button 1512 may then be selected to save the configuration for Block 1. In the present example, this will save a configuration file for Block 1 that includes the configuration information and the name of the service 230a to which the block belongs.

[0109] Referring to FIG. 21, one embodiment of the GUI 1500 is illustrated after Block 4b has been selected. As shown in the block configuration pane 1526, Block 4b (which corresponds to block 232d of FIG. 10), has a configuration parameter 2102 that is set with the configuration value of "companyname." Other filter conditions may be set if desired as illustrated by configuration parameter fields 2104 and 2106, but these fields are empty as default values in the present example. The "Save Block" button 1512 may then be selected to save the configuration for Block 4b. In the present example, this will save a configuration file for Block 4b that includes the configuration information and the name of the service 230a to which the block belongs.

[0110] Referring to FIG. 22, one embodiment of the GUI 1500 is illustrated after Block 2 has been selected. As shown in the block configuration pane 1526, Block 2 (which corresponds to block 232b of FIG. 10), has a configuration parameter 2202 for a recipient email address. The value "usernamel@company.com" has been entered into this field. Other configurable parameters available as indicated by a field 2204 for a subject of the email and a field 2206 for a body of the email. These additional fields are empty as default values in the present example. The "Save Block" button 1512 may then be selected to save the configuration for Block 2. In the present example, this will save a configuration file for Block 2 that includes the configuration information and the name of the service 230a to which the block belongs.

[0111] After the configuration of the Blocks 1, 4b, and 2 or at any time during the configuration, the service 230a may be saved by selecting the "Save Service" button 1518. This will save the configuration of the service 230a, including the blocks used by the service and their order of execution. In the present example, a configuration file containing this information will be saved for the service 230a. The service 230a may also be started at this time by selecting the "Start Service" button 1524.

[0112] Referring to FIG. 23, one embodiment of the GUI 1500 is illustrated with the service pane 1602 and a new service pane 2302 for a Service 2. For purposes of example, Service 2 corresponds to the service 230b of FIG. 11. It is noted that the service 230a is now running and the indicator 1612 has changed color to green. The service pane 2302 includes an indicator 2304 that is currently red because the service 230b is not running. A tab 2306 has been added for Service 2.

[0113] Referring to FIG. 24, one embodiment of the GUI 1500 is illustrated after the service 230b has been configured. More specifically, after being created, the service 230b can be configured using a similar process to that described previously for the service 230a. Accordingly, following this configuration process, the service builder pane 1702 illustrates that Block 3 (corresponding to block 232c), Block 4b (corresponding to block 232d), Block 5 (corresponding to block 232e), and Block 2 (corresponding to block 232b) have been selected and connected.

[0114] Block 3 is connected to Block 4b by a line 2402, with an arrow indicating the direction of flow. Block 4b is connected to Block 5 by a line 2404, with an arrow indicating the direction of flow. Block 4b is also connected to Block 2 by a line 2406, with an arrow indicating the direction of flow.

[0115] Referring to FIG. 25, one embodiment of the GUI 1500 is illustrated after Block 2 has been selected for service 230b. As described with respect to FIGS. 10 and 11, block 232b is to send an email to the address for which it is configured. In the service 230a, the destination address is usemamel@companyname.com. However, in the service 230b, the destination address is username2@companyname.com. Accordingly, for the service 230b, the value "username2@company.com" has been entered into the field for the configuration parameter 2202. In addition, the text "Machine Error" has been entered into the subject field 2204, so that any email sent by the service 230b to the address username2@companyname.com will contain the words "Machine Error" in the email's subject line.

[0116] Referring to FIG. 26, one embodiment of the GUI 1500 is illustrated after the service 230b has been configured and saved. The service 230b can now be started, which will change the indicator 2304 to green as shown. This will result in both services 232a and 232b running as shown in FIG. 12.

[0117] If the GUI 1500 is closed and reopened for the NIO platform 402, any services loaded onto the NIO platform may be displayed. For example, in FIG. 15, no services are initially displayed when the GUI 1500 is opened because the NIO platform 402 has not yet been configured to run any services. However, after the services 232a and 232b have been configured as described, opening the GUI 1500 will display the services 232a and 232b as illustrated in FIG. 26, along with the current status of each service as running or stopped. In embodiments where the configuration environment 408 is not connected directly to a running NIO platform, an existing configuration may need to be selected and opened before any services will be shown.

[0118] Referring to FIG. 27, a method 2700 illustrates one embodiment of a process that may be executed within a development environment, such as one of the development environments 1400 of FIG. 14A, 1410 of FIG. 14B, and 1420 of FIG. 14C. The method 2700 may be used to create and configure a new service on the NIO platform 402 using a GUI, such as the GUI 1500 of FIG. 15, that is part of the configuration environment 408 of FIG. 4.

[0119] In step 2702, input is received via the GUI 1500 to create a new service. In step 2704, the configuration environment 408 creates the new service and displays the new service in the service builder. In step 2706, input is received via the GUI 1500 selecting blocks to be used in the service. In step 2708, the configuration environment 408 displays the blocks in the service builder. In step 2710, input is received defining connections between the blocks to define one or more data flow paths through the service. In step 2712, the configuration environment 408 displays the connections in the service builder.

[0120] In step 2714, input may be received for configuration values to be assigned to the configuration parameters for one or more of the blocks. In step 2716, input is received to save the service and block configurations. In step 2718, the configuration environment 408 saves the service and block configurations. In step 2720, the configuration environment 408 saves the service and/or block classes if needed. For example, the configuration environment 408 may load the service and/or block classes into the NIO platform 402 using the REST API, or may save the service and/or block classes to a defined memory location for later use by the NIO platform 402.

[0121] In step 2722, input may be received to start the service. For example, if the NIO platform 402 is running and the configuration environment 408 is communicating via the REST API, the GUI 1500 may be used to start the service. Accordingly, in step 2724, the configuration environment 408 may start the service on the NIO platform 402.

[0122] It is understood that, although not shown, steps may be repeated during the execution of the method 2700 and/or steps may be performed in an order different from that shown. For example, a single block may be added, configured, and saved (steps 2706, 2708, 2714, 2716, and 2718), and then another block may be added, configured, and saved (repeating steps 2706, 2708, 2714, 2716, and 2718). The blocks may then be connected (steps 2710 and 2712). Accordingly, it is understood that many variations of the illustrated steps of the method 2700 may be used. [0123] Referring to FIG. 28, a method 2800 illustrates one embodiment of a process that may be executed within a development environment, such as one of the development environments 1400 of FIG. 14A, 1410 of FIG. 14B, and 1420 of FIG. 14C. The method 2800 may be used to modify an existing service on the NIO platform 402 using a GUI, such as the GUI 1500 of FIG. 15, that is part of the configuration environment 408 of FIG. 4.

[0124] In step 2802, input is received via the GUI 1500 to open an existing service. The existing service may be opened via the REST API of the NIO platform 402, or may be opened from a saved configuration that is accessed at a defined memory location (e.g., a hard drive on which the existing service configuration is stored). In step 2804, the configuration environment 408 opens the service and displays the service in the service builder. In step 2806, input is received via the GUI 1500 selecting one or more existing blocks to be modified, deleted, or moved. The input may also be for adding one or more new blocks. In step 2808, a determination is made as to the input received in step 2806.

[0125] If the determination of step 2808 indicates that a new block was added or an existing block was deleted or moved, the method 2800 moves to step 2810. In step 2810, the configuration environment 408 displays the current arrangement of blocks in the service builder. In step 2812, input is received defining connections between the blocks to define one or more data flow paths through the service. In step 2814, the configuration environment 408 displays the updated connections in the service builder. The method 2800 then moves to step 2816, where the blocks can be configured if desired.

[0126] If the determination of step 2808 indicates that an existing block was modified, the method 2800 moves to step 2816. In step 2816, input is received for configuration values to be assigned to the configuration parameters for one or more of the blocks. In step 2818, input is received to save the service and/or block configurations. In step 2820, the configuration environment 408 saves the service and/or block configurations. In step 2822, the configuration environment 408 save the service and/or block classes if needed. For example, the configuration environment 408 may load the service and/or block classes into the NIO platform 402 using the REST API, or may save the service and/or block classes to a defined memory location for later use by the NIO platform 402.

[0127] In step 2824, a determination is made as to whether additional changes are to be made to the service. For example, input may be received indicating another block is to be modified, added, deleted, or moved. If the determination of step 2824 indicates that an additional change is to be made, the method 2800 returns to step 2806 to handle the change. If the determination of step 2824 indicates that no additional changes are to be made, the method 2800 moves to step 2826.

[0128] In step 2826, input may be received to stop and/or start the service. For example, if the NIO platform 402 is running and the configuration environment 408 is communicating via the REST API, the GUI 1500 may be used to stop the service (if the service is running) or start the service (if the service is stopped). As described previously, changes to the service may not take effect until the service is stopped and restarted. Accordingly, if the method 2800 was executed while the service was still running on the NIO platform 402, the service needs to be stopped and restarted. If the service is already stopped, the service can be started. Although not shown, it is understood that the service can be stopped at any time before or during the method 2800. Accordingly, in step 2828, the configuration environment 408 may stop and/or start the service on the NIO platform 402.

[0129] As with the method 2700 of FIG. 27, it is understood that, although not shown, steps may be repeated during the execution of the method 2800 and/or steps may be performed in an order different from that shown. Accordingly, it is understood that many variations of the illustrated steps of the method 2800 may be used.

[0130] Referring to FIG. 29, a method 2900 illustrates one embodiment of a process that may be executed within a development environment, such as one of the development environments 1400 of FIG. 14A, 1410 of FIG. 14B, and 1420 of FIG. 14C. The method 2900 may be used to save service and/or block configurations to the NIO platform 402 using a GUI, such as the GUI 1500 of FIG. 15, that is part of the configuration environment 408 of FIG. 4.

[0131] In step 2902, input is received to save the service and/or block configurations. In the present example, the NIO platform 402 is running and the configuration environment 408 is communicating with the NIO platform 402 via the REST API. Accordingly, in step 2904, the configuration environment 408 saves the service and/or block configurations to the NIO platform 402 via the REST API. In step 2906, the configuration environment 408 saves the service and/or block classes if needed. In the present example, the configuration environment 408 would load the service and/or block classes into the NIO platform 402 using the REST API.

[0132] Referring to FIG. 30, a method 3000 illustrates one embodiment of a process that may be executed within a development environment, such as one of the development environments 1400 of FIG. 14A, 1410 of FIG. 14B, and 1420 of FIG. 14C. The method 3000 may be used to save service and/or block configurations to the NIO platform 402 using a GUI, such as the GUI 1500 of FIG. 15, that is part of the configuration environment 408 of FIG. 4. [0133] In step 3002, input is received to save the service and/or block configurations. In the present example, the configuration environment 408 is not communicating with the NIO platform 402. Accordingly, in step 3004, the configuration environment 408 saves the service and/or block configurations to a defined memory location. In step 3006, the configuration environment 408 saves the service and/or block classes if needed. In the present example, the configuration environment 408 would save the service and/or block classes to a defined memory location for later use by the NIO platform 402.

[0134] Referring to FIG. 45, a method 4500 illustrates one embodiment of a process that may be executed within a development environment, such as one of the development environments 1400 of FIG. 14A, 1410 of FIG. 14B, and 1420 of FIG. 14C. The method 4500 may be used to configure the NIO platform 402 using a GUI, such as the GUI 1500 of FIG. 15, that is part of the configuration environment 408 of FIG. 4.

[0135] In step 4502, the configuration environment 408 is provided with the GUI 1500 and library 404 of FIG. 4. In step 4504, input is received via the GUI 1500 for configuration information for the NIO platform 402. In step 4506, the configuration environment 408 converts the configuration information into service and/or block configurations usable by the NIO platform 402. In step 4508, the configuration environment 408 saves the service and/or block configurations. For example, the configuration environment 408 may load the service and/or block classes into the NIO platform 402 using the REST API, or may save the service and/or block classes to a defined memory location for later use by the NIO platform 402.

[0136] 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.

[0137] For example, in one embodiment, a method for creating a configuration for a platform instance that is to be used on a digital device includes creating, within a development environment having a graphical user interface (GUI), a service to be run by the platform instance; providing, via the GUI, a graphical representation of a block library containing a plurality of available blocks that are available for use by the service, wherein each available block contains first executable code that provides task specific functionality and second executable code that enables the block to function within the platform instance; receiving, via the GUI, input identifying at least some of the available blocks as selected blocks, wherein the selected blocks are to be run by the service; receiving, via the GUI, input arranging the selected blocks into an order of execution that defines which of the selected blocks are to receive output produced by others of the selected blocks when run by the service; generating, by the development environment, at least one configuration file for use by the platform instance, wherein the configuration file includes information that represents the order of execution so that output produced by the selected blocks can be correctly directed to others of the selected blocks when the platform instance runs the service; and storing the configuration file for use by the platform instance.

[0138] In some embodiments, the platform instance is configured to run the selected blocks in a decoupled manner within the service with each selected block having no awareness of the other selected blocks, and the configuration file is generated as a service configuration file for configuring the service to direct the output of the selected blocks according to the order of execution.

[0139] In some embodiments, generating the service configuration file further includes identifying a service class in the service configuration file, wherein the service class is to be used by the platform instance to instantiate the service.

[0140] In some embodiments, the method further includes generating, by the development environment, a block configuration file for the plurality of selected blocks.

[0141] In some embodiments, the method further includes generating, by the development environment, a unique block configuration file for each of the selected blocks.

[0142] In some embodiments, generating the unique block configuration file for each of the selected blocks further includes identifying one of a plurality of available block classes in each of the unique block configuration files, wherein the identified block class is to be used by the platform instance to instantiate the selected block corresponding to the unique block configuration file.

[0143] In some embodiments, the configuration file is generated as a service configuration file for configuring the service to configure each selected block that produces output for another selected block to direct the output to the other selected block. [0144] In some embodiments, the configuration file is generated as a block configuration file for configuring each selected block that produces output for another selected block to direct the output to the other selected block.

[0145] In some embodiments, the method further includes receiving, via the GUI, input selecting a first block of the selected blocks, wherein the first block includes a plurality of configurable parameters; receiving, via the GUI, at least one configuration value to assign to at least one of the configurable parameters, wherein the configuration value will be used when the first block is run within the platform instance; generating, by the development environment, a block configuration file for the first block, wherein the block configuration file contains the configuration value; and storing the block configuration file for use by the platform instance.

[0146] In some embodiments, generating the block configuration file further includes identifying a name of the service within the block configuration file.

[0147] In some embodiments, the configuration value defines a destination outside of the service for output produced by the first block.

[0148] In some embodiments, generating the at least one configuration file includes generating a platform instance configuration file that identifies the service and any other services that are to be run by the platform instance, a service configuration file for the service and for each of the other services, and a block configuration file for the selected blocks and for any other blocks used by the other services.

[0149] In some embodiments, storing the configuration file for use by the platform instance includes storing the configuration file in a memory of a device containing the platform instance.

[0150] In some embodiments, storing the configuration file for use by the platform instance includes storing the configuration file in a memory for download by a device containing the platform instance.

[0151] In some embodiments, the method further includes loading the selected blocks into a memory accessible to the platform instance, wherein the available blocks that were not selected are not loaded into the memory.

[0152] In some embodiments, the method further includes providing, by the GUI, a user selectable actuator for deleting the service from the platform instance.

[0153] In some embodiments, the method further includes providing, by the GUI, a user selectable actuator for starting and stopping the service on the platform instance. [0154] In another embodiment, a system for creating a configuration for a platform instance that is to be used on a digital device includes a processor and a memory coupled to the processor, the memory including instructions executable by the processor for creating, within a development environment having a graphical user interface (GUI), a service to be run by the platform instance; providing, via the GUI, a graphical representation of a block library containing a plurality of available blocks that are available for use by the service, wherein each available block contains first executable code that provides task specific functionality and second executable code that enables the block to function within the platform instance; receiving, via the GUI, input identifying at least some of the available blocks as selected blocks, wherein the selected blocks are to be run by the service; receiving, via the GUI, input arranging the selected blocks into an order of execution that defines which of the selected blocks are to receive output produced by others of the selected blocks when run by the service; generating, by the development environment, at least one configuration file for use by the platform instance, wherein the configuration file includes information that represents the order of execution so that output produced by the selected blocks can be correctly directed to others of the selected blocks when the platform instance runs the service; and storing the configuration file for use by the platform instance.

[0155] In some embodiments, the platform instance is configured to run the selected blocks in a decoupled manner within the service with each selected block having no awareness of the other selected blocks, and the configuration file is generated as a service configuration file for configuring the service to direct the output of the selected blocks according to the order of execution.

[0156] In some embodiments, the instructions for generating the service configuration file further include identifying a service class in the service configuration file, wherein the service class is to be used by the platform instance to instantiate the service.

[0157] In some embodiments, the instructions further include generating, by the development environment, a block configuration file for the plurality of selected blocks.

[0158] In some embodiments, the instructions further include generating, by the development environment, a unique block configuration file for each of the selected blocks.

[0159] In some embodiments, the instructions for generating the unique block configuration file for each of the selected blocks further include identifying one of a plurality of available block classes in each of the unique block configuration files, wherein the identified block class is to be used by the platform instance to instantiate the selected block corresponding to the unique block configuration file. [0160] In some embodiments, the configuration file is generated as a service configuration file for configuring the service to configure each selected block that produces output for another selected block to direct the output to the other selected block.

[0161] In some embodiments, the configuration file is generated as a block configuration file for configuring each selected block that produces output for another selected block to direct the output to the other selected block.

[0162] In some embodiments, the instructions further include receiving, via the GUI, input selecting a first block of the selected blocks, wherein the first block includes a plurality of configurable parameters; receiving, via the GUI, at least one configuration value to assign to at least one of the configurable parameters, wherein the configuration value will be used when the first block is run within the platform instance; generating, by the development environment, a block configuration file for the first block, wherein the block configuration file contains the configuration value; and storing the block configuration file for use by the platform instance.

[0163] In some embodiments, the instructions for generating the block configuration file further include identifying a name of the service within the block configuration file.

[0164] In some embodiments, the configuration value defines a destination outside of the service for output produced by the first block.

[0165] In some embodiments, the instructions for generating the at least one configuration file include generating a platform instance configuration file that identifies the service and any other services that are to be run by the platform instance, a service configuration file for the service and for each of the other services, and a block configuration file for the selected blocks and for any other blocks used by the other services.

[0166] In some embodiments, storing the configuration file for use by the platform instance includes storing the configuration file in a memory of a device containing the platform instance.

[0167] In some embodiments, storing the configuration file for use by the platform instance includes storing the configuration file in a memory for download by a device containing the platform instance.

[0168] In some embodiments, the instructions further include loading the selected blocks into a memory accessible to the platform instance, wherein the available blocks that were not selected are not loaded into the memory.

[0169] In some embodiments, the instructions further include providing, by the GUI, a user selectable actuator for deleting the service from the platform instance. [0170] In some embodiments, the instructions further include providing, by the GUI, a user selectable actuator for starting and stopping the service on the platform instance.

[0171] In another embodiment, a method for creating a configuration for a platform instance that is to be used on a digital device includes creating, within a development environment having a graphical user interface (GUI), a first service and a second service to be run simultaneously by the platform instance, wherein the platform instance is configured to run on the digital device; providing, via the GUI, a graphical representation of a block library containing a plurality of available blocks that are available for use by the first service and the second service, wherein each available block contains executable code that provides task specific functionality; receiving, via the GUI, input arranging a first set of the available blocks into a first order of execution for the first service, wherein the first order of execution defines which of the available blocks in the first set are to receive output produced by others of the available blocks in the first set when run by the first service; receiving, via the GUI, input arranging a second set of the available blocks into a second order of execution for the second service, wherein the second order of execution defines which of the available blocks in the second set are to receive output produced by others of the available blocks in the second set when run by the second service; and generating, by the development environment, at least a first configuration file for use with the first service and a second configuration file for use by the second service, wherein the first configuration file and the second configuration files include source/destination information that represents the order of execution for the first and second services, respectively, when the platform instance runs the first service and the second service.

[0172] In some embodiments, the first configuration file contains communication information defining that at least a first block of the available blocks in the first set is configured to send information to a second block of the available blocks in the second set.

[0173] In some embodiments, the communication information defines a publication channel of the platform instance to be used by the first block and the second block.

[0174] In some embodiments, the first configuration file contains a first configuration value indicating that the first service is to be autostarted when the platform instance is launched.

[0175] In some embodiments, the first and second configuration files are a single configuration file.

[0176] In another embodiment, a system for creating a configuration for a platform instance that is to be used on a digital device includes a processor and a memory coupled to the processor, the memory including instructions executable by the processor for creating, within a development environment having a graphical user interface (GUI), a first service and a second service to be run simultaneously by the platform instance, wherein the platform instance is configured to run on the digital device; providing, via the GUI, a graphical representation of a block library containing a plurality of available blocks that are available for use by the first service and the second service, wherein each available block contains executable code that provides task specific functionality; receiving, via the GUI, input arranging a first set of the available blocks into a first order of execution for the first service, wherein the first order of execution defines which of the available blocks in the first set are to receive output produced by others of the available blocks in the first set when run by the first service; receiving, via the GUI, input arranging a second set of the available blocks into a second order of execution for the second service, wherein the second order of execution defines which of the available blocks in the second set are to receive output produced by others of the available blocks in the second set when run by the second service; and generating, by the development environment, at least a first configuration file for use with the first service and a second configuration file for use by the second service, wherein the first configuration file and the second configuration files include source/destination information that represents the order of execution for the first and second services, respectively, when the platform instance runs the first service and the second service.

[0177] In some embodiments, the first configuration file contains communication information defining that at least a first block of the available blocks in the first set is configured to send information to a second block of the available blocks in the second set.

[0178] In some embodiments, the communication information defines a publication channel of the platform instance to be used by the first block and the second block.

[0179] In some embodiments, the first configuration file contains a first configuration value indicating that the first service is to be autostarted when the platform instance is launched.

[0180] In some embodiments, the first and second configuration files are a single configuration file.

[0181] In another embodiment, a development environment includes a processor and a memory coupled to the processor, the memory including instructions executable by the processor for providing a graphical user interface (GUI); providing a block library containing a plurality of available blocks that are available for use by a service that is to be run by a platform instance, wherein each available block contains first executable code that provides task specific functionality and second executable code that enables the block to function within the platform instance; receiving first user input via the GUI selecting at least a first block and a second block from the available blocks; receiving second user input linking the first block to the second block to define an order of execution between the first and second blocks; and generating at least one configuration file for the platform instance, wherein the configuration file includes the order of execution.

[0182] In some embodiments, the development environment further includes a block editor that enables a user to edit the first executable code of one of the available blocks.

[0183] In some embodiments, the development environment further includes a configuration file editor that enables a user to edit configurable parameters used by a core of the platform instance.

[0184] In some embodiments, the development environment further includes instructions for receiving third user input creating a service that is to run the first block and the second block.

[0185] In some embodiments, the development environment is located on a device having access to the platform instance via an application programming interface (API).

[0186] In some embodiments, the development environment is part of the platform instance.

[0187] In some embodiments, the development environment is located on a server that is separate from a device on which the platform instance is located.

[0188] In some embodiments, the development environment interacts with the platform instance via a Representational State Transfer (REST) application programming interface (API) of the platform instance.

[0189] In some embodiments, the development environment is an application programming interface (API) client.

[0190] In some embodiments, the API client is based on a hypertext transfer protocol (HTTP) and javascript code.

[0191] In some embodiments, the API client is accessible using a browser.

Claims

WHAT IS CLAIMED IS:

1. A method for creating a configuration for a platform instance that is to be used on a digital device, the method comprising:

creating, within a development environment having a graphical user interface (GUI), a service to be run by the platform instance;

providing, via the GUI, a graphical representation of a block library containing a plurality of available blocks that are available for use by the service, wherein each available block contains first executable code that provides task specific functionality and second executable code that enables the block to function within the platform instance;

receiving, via the GUI, input identifying at least some of the available blocks as selected blocks, wherein the selected blocks are to be run by the service;

receiving, via the GUI, input arranging the selected blocks into an order of execution that defines which of the selected blocks are to receive output produced by others of the selected blocks when run by the service;

generating, by the development environment, at least one configuration file for use by the platform instance, wherein the configuration file includes information that represents the order of execution so that output produced by the selected blocks can be correctly directed to others of the selected blocks when the platform instance runs the service; and

storing the configuration file for use by the platform instance.

2. The method of claim 1 wherein the platform instance is configured to run the selected blocks in a decoupled manner within the service with each selected block having no awareness of the other selected blocks, and wherein the configuration file is generated as a service configuration file for configuring the service to direct the output of the selected blocks according to the order of execution.

3. The method of claim 2 wherein generating the service configuration file further includes identifying a service class in the service configuration file, wherein the service class is to be used by the platform instance to instantiate the service.

4. The method of claim 2 further comprising generating, by the development environment, a block configuration file for the plurality of selected blocks.

5. The method of claim 2 further comprising generating, by the development environment, a unique block configuration file for each of the selected blocks.

6. The method of claim 5 wherein generating the unique block configuration file for each of the selected blocks further includes identifying one of a plurality of available block classes in each of the unique block configuration files, wherein the identified block class is to be used by the platform instance to instantiate the selected block corresponding to the unique block configuration file.

7. The method of claim 1 wherein the configuration file is generated as a service configuration file for configuring the service to configure each selected block that produces output for another selected block to direct the output to the other selected block.

8. The method of claim 1 wherein the configuration file is generated as a block configuration file for configuring each selected block that produces output for another selected block to direct the output to the other selected block.

9. The method of claim 1 further comprising:

receiving, via the GUI, input selecting a first block of the selected blocks, wherein the first block includes a plurality of configurable parameters;

receiving, via the GUI, at least one configuration value to assign to at least one of the configurable parameters, wherein the configuration value will be used when the first block is run within the platform instance;

generating, by the development environment, a block configuration file for the first block, wherein the block configuration file contains the configuration value; and storing the block configuration file for use by the platform instance.

10. The method of claim 9 wherein generating the block configuration file further includes identifying a name of the service within the block configuration file.

11. The method of claim 9 wherein the configuration value defines a destination outside of the service for output produced by the first block.

12. The method of claim 1 wherein generating the at least one configuration file includes generating a platform instance configuration file that identifies the service and any other services that are to be run by the platform instance, a service configuration file for the service and for each of the other services, and a block configuration file for the selected blocks and for any other blocks used by the other services.

13. The method of claim 1 wherein storing the configuration file for use by the platform instance includes storing the configuration file in a memory of a device containing the platform instance.

14. The method of claim 1 wherein storing the configuration file for use by the platform instance includes storing the configuration file in a memory for download by a device containing the platform instance.

15. The method of claim 1 further comprising loading the selected blocks into a memory accessible to the platform instance, wherein the available blocks that were not selected are not loaded into the memory.

16. The method of claim 1 further comprising providing, by the GUI, a user selectable actuator for deleting the service from the platform instance.

17. The method of claim 1 further comprising providing, by the GUI, a user selectable actuator for starting and stopping the service on the platform instance.

18. A development environment comprising:

a processor; and

a memory coupled to the processor, the memory including instructions executable by the processor for

providing a graphical user interface (GUI);

providing a block library containing a plurality of available blocks that are available for use by a service that is to be run by a platform instance, wherein each available block contains first executable code that provides task specific functionality and second executable code that enables the block to function within the platform instance; receiving first user input via the GUI selecting at least a first block and a second block from the available blocks;

receiving second user input linking the first block to the second block to define an order of execution between the first and second blocks; and

generating at least one configuration file for the platform instance, wherein the configuration file includes the order of execution.

19. The development environment of claim 18 further comprising a block editor that enables a user to edit the first executable code of one of the available blocks.

20. The development environment of claim 18 further comprising a configuration file editor that enables a user to edit configurable parameters used by a core of the platform instance.

21. The development environment of claim 18 further comprising instructions for receiving third user input creating a service that is to run the first block and the second block.

22. The development environment of claim 18 wherein the development environment is located on a device having access to the platform instance via an application programming interface (API).

23. The development environment of claim 18 wherein the development environment is part of the platform instance.

24. The development environment of claim 18 wherein the development environment is located on a server that is separate from a device on which the platform instance is located.

25. The development environment of claim 18 wherein the development environment interacts with the platform instance via a Representational State Transfer (REST) application programming interface (API) of the platform instance.

26. The development environment of claim 18 wherein the development environment is an application programming interface (API) client.