InfinityDB Server Java NoSQL Database

InfinityDB Server is a Java NoSQL Database. It organizes a set of InfinityDB Embedded database files into a secure, flexible, dynamic, remotely accessible, shareable database with a PatternQuery language and REST communication mediated exclusively by the queries for no-code access. See the module breakdown, server structure, or management.

Direct Database to API

Connect the database directly and securely to almost any client with PatternQueries via REST APIs. The server-side queries are concise, user-friendly declarative structures in text or graphic forms with no associated complex algorithmic code or configuration. The client side uses simple pre-existing REST access code to send and receive data in simple or intricate custom ways. Security is built-in, unlike hand-crafted algorithmic APIs, and is fine-grained.

Flexible and Dynamic

Online data exploration, schema and REST API evolution, tuning, testing, and experimentation can all be done by making live edits to PatternQueries via the web, without any server downtime. Bypass the the slow software development and deployment cycle and bypass the heavy three-tier architecture of web server, application server, and DBMS. Effortlessly generate and maintain data, schemas, interfaces, queries, indexing, administration and security via the web to enhance productivity without the need for coding. All you need is a PatternQuery to adapt to new or changing data sources and sinks in real-time for sensors, controllers, applications, processes, systems, users, or enterprises.

PatternQueries are Simple

PatternQueries go far beyond SQL; they almost resemble programs but are declarative rather than algorithmic. They are simple, clear, concise, easily readable, and editable as text or graphics. Easy tasks are easy and difficult tasks are simplified. Trade insecure, risky, unmaintainable, opaque, fixed, complex algorithmic code for short expressive descriptions using just a few symbols, literals, and expressions. Performance is accelerated as well with advanced optimization and internal algorithms.

Dynamic REST Interfaces

Each REST access URL corresponds to a single query, serving as a secure interface that conceals the database structure – nothing else is necessary. See the server in action: here is the retrieved JSON of some Aircraft data and a San Francisco Dome image from the infinitydb.com server. The user name is ‘testUser’ and the password is ‘db’.

Graphical or Text Editing of Queries or Any Data

Below is the editable graphical view of a minimal query that receives an image name from the console or REST request and returns the binary of the image. Below that is the syntax colored text view of it. Notice the multiple occurrences of the symbols =image and =name: these are ‘joins’. These graphical and text views work with any rich data structure, not just queries, because queries are stored internally in the same way as any other data: as structures, not plain text.

Here is the editable ‘i-code’ text view. I-code is a trivial but more convenient format somewhat like extended JSON, which you can also use for any purpose. All data can be expressed and edited interchangeably as i-code, JSON, CSV or graphics including blobs like images and embedded files. Blobs may be embedded in any format, even text formats, and are rendered whenever possible.

Applications

The server is very versatile, and is used in these ways:

• Data Science, facilitated by the server’s database browser and PatternQueries.
• Collaborative work, achieved through the manual sharing of local and remote distributed data using the fast binary ‘ItemPacket’ protocol.
• IoT and Microservices networks, powered by REST APIs where PatternQueries define the REST URLs.
• Distributed systems, where Java clients communicate with InfinityDB Servers via the ItemPacket protocol.
• High-performance Java applications, utilizing the bare InfinityDB Embedded or InfinityDB Encrypted low-level ItemSpace Data Model and Map APIs.

Features

Data types include images, other blob types, text, hierarchies, variable tuples, tables, sets, or lists, all nestable, with static or dynamic strongly-typed data components.

The system features a built-in lightweight web server that offers:

1. A data browser and editor with graphical tabular, JSON, CSV, ‘i-code,’ image, and raw data views.
2. Administration via web for managing users, roles, permissions, passwords, grants, and databases.
3. Robust security measures, including universal SSL/TLS encryption, hashed and encrypted passwords and encrypted system data. REST access is finely-controlled via named interfaces and permission types.

‘Pattern Queries’ provide:

• Concise, powerful graphical or text-based definitions without the need for SQL or algorithms. No programming required.
• High-speed execution, powered by the optimized ‘database engine’InfinityDB Embedded.
• A compiler and optimizer that takes just milliseconds for the compilation phase.
• The ability to transform, select, and compute with rich data.
• Reducers for swift data aggregation, covering statistics, hashing, and custom aggregations.
• REST access, functioning as a secure Remote Procedure Call for Python, JavaScript, shell (‘curl’), and more.
• REST APIs defined by PatternQueries for simplicity, flexibility, isolation, security, and extensibility.
• A Python module offering convenient access and utilities.

Additionally, a fast and secure ‘ItemPacket’ protocol is provided that connects from a local server or from a Java client to a remote server for tasks such as backup, collaboration, curation, and data transfer.

The Communications Architecture

InfinityDB servers and client programs can communicate in a variety of ways. The ‘ItemPacket’ protocol links allow servers to cooperate by transparently remoting databases that appear to clients to be local to a particular server. Remote servers are for data backup, migration and aggregation. A server can run in a local computer as a sandbox, or in the cloud, for sharing. There are also Remote Procedure Calls via the standard REST type interface:

The Flexible ‘ItemSpace’ Data Model

InfinityDB is a novel DBMS that has an almost trivial, very flexible self-adapting ‘ItemSpace’ data model. It’s different because you don’t define schemas like tables or key/value stores ahead of time, but instead they develop gradually and extend automatically as the need arises, new data sources and sinks come on-line, users work and client apps evolve. Data can be informal but also formalized and curated. Connect users, sensors, controllers, applications, networks, enterprises, and systems with live, responsive, manageable interfaces and data. Use REST access from Java, Python, JavaScript on web pages through AJAX or nodejs, bash through ‘curl’ and more.

 Try the Database Browser Web Access

You can see the backend web app now at https://infinitydb.com:37411. The guest user is ‘testUser’ and password ‘db’. We appreciate your experimentation and exploration of it. To get a flavor of the system, select ‘Access Databases’ on the home page. You will see a table of the available InfinityDB Embedded database files for users in the guest role, which are demo/readonly and demo/writeable. You can select either one to see the main browsing and editing page with a list of the existing ‘EntityClasses’ (which are like nestable tables). Choose any of them, such as Pictures, Samples, Aircraft, Query or Documentation to see the main tabular browsing page with the rich flexible data format. The Documentation EntityClass there describes the system overall, and it looks like a rich document but is actually structured data. You can try various views including the Tabular, i-code Java style, i-code Python style, regular JSON, extended JSON, List of CSV, Set of CSV, List of Strings, Text Blob or Items. There are also example queries there. If you want, you can add and modify your own data in demo/writeable for others to see, and then please comment to us. We will see your changes and help! We will create you a free personal public or private trial database if you contact us at support@boilerbay.com.

The Flexible Data Model Viewed by the Backend Web UI

Here we show various structures you can get with a simple set of ‘Items’ using the built-in web interface.

Below is a set of samples in ‘demo/readonly’ from a simulated IoT, where pressure and temperature are measured very quickly. This could be embedded in another table or document or have additional internal structure. You can add new columns without changing a schema. For example, a new humidity sensor might come online, sending its data to the Samples table but using a new column name, and the old and new sensor data is merged as it arrives, with no changes to the old sensor or database by anyone.

The data is not stored as text, but is ‘strongly typed’  with 10 basic data types plus special ‘EntityClass’ and ‘Attribute’ ‘metadata’ data types that encode the semantics shown here in blue and green. The 10 basic data types are ‘primitive’ and are black. in white boxes. (All data is actually stored invisibly as a sorted set of binary ‘Items’ in a compressed B-Tree, not text, and can therefore be accessed randomly or sequentially as if it were a sorted key/value store for extreme speed at any level of detail.)

Here is a table in ‘demo/readonly’ that contains BLOBs or ‘binary long objects’ which happen to be images in this case.  This is a ‘table’ called ‘Pictures’, with  four ‘columns’ or attributes. At any time, another column could be added simply by using a new attribute name, and these particular columns or other structure are not special or fixed.

Below is some documentation about the system in the flexible format. It’s not a pretty word doc with fonts and so on, but it captures the logic of a rich document that can be concurrently edited. All of it down to individual paragraphs is independently and concurrently editable by multiple users, and the embedded tables, images or other blobs can be added, removed, and edited too, down to one cell at a time, by multiple users. You can use hierarchical numerical or text-titled sections, deeply nested documents or tables and so on. It is real database data, mixed in with any other kind, accessible to remote programs.

The above can be considered a table that just looks like a rich document. The ‘keys’ at the left are the section titles, and the contents of the ‘description’ column is the text. The text has multiple embedded tables – the visible one is called ‘Browser’, where the key is the name of a screen widget, and the single ‘purpose’ column it has is the description of the widget. The display format is determined solely by the set of ‘Items’ in the database and looks like a document in this case, but it is not ‘known’ by the graphics display to be a rich document. Below is the same data in the ‘i-code’ Java Style format. You can see it is more like a traditional document, and it is editable as i-code text, regular JSON, or ‘extended’ JSON, with optional embedded blobs anywhere such as images or plain text.

Below is a nested structure, the definition of a ‘Pattern Query’ found in the public database ‘demo/readonly’. First of all, there is an outer table called ‘Query’. The keys are the query names, so you can re-use queries. Inside that are the ‘description’ and ‘query’ columns, where the second is the query’s specification, and the first is an explanation, a little documentation about what it is for. The description or query parts are not limited in size, and can be rich, so there can be nested tables, images, text blobs and so on, and there can be more columns besides description and the definition. The definition has nested columns called ‘pattern’ and ‘result’, plus a nested table called ‘Where’ to describe symbols like =aircraft and their attributes Furthermore, the Aircraft, Results and AircraftCopied tables are nested within those, where you define the data sources, sinks, and computations. You can execute this query and others yourself at https://infinitydb.com:37411, (user testUser password db) or experiment, creating anything you want in the public ‘demo/writeable’ database.

This is just more structure represented by the almost trivial data model called the ‘ItemSpace’, with normal data types plus the two special flexible data types ‘EntityClass’ and ‘Attribute’ mixed in to some of the Items. The GUI formats it with certain simple fixed rules into a graphical display based on patterns in the data. The displays above follow these fixed rules, without any special ‘formatting’ instructions or external data structure. That means every structure above is nestable and can be combined with any other structure at any time. The ‘document’ shown above is not a file, but a data structure of Items. It can be read from and written to at any level of hierarchical detail. The ‘Samples’ table is not a file but a set of Items, as are the ‘Picture’ and ‘Pattern Query’ displays.

Database Browser User Interface

Here is the full backend browser page looking at a ‘Trees’ table in the flexible format. The functions of the display components are described in the table ‘Documentation’ in database ‘demo/readonly’ using the flexible format itself.

The ‘Current Prefix’ here is like your ‘current working directory’ in the shell. This prefix contains an ‘Item’ which is composed of strings, longs, doubles, floats, Booleans, dates, indexes, short byte arrays, short byte strings, and short char arrays, but in the flexible format it also can have any combination of two optional additional special ‘EntityClass’ and ‘Attribute’ type components that describe the schema of the Item internally. There are 12 data types in total. To the left are the prefix navigation buttons for moving around.

There is no schema structure defined anywhere but inside the flexible-format ‘Items’ themselves. The database is nothing more than an ordered set of these Items. When an Item is inserted, say with the insert button or by a Python or Java client, or by a curl command in the shell, the database schema is effectively extended at that moment. Deleting the Item reverses it, leaving behind the exact original structure. Any kind of structure can be created instantly and painlessly: more JSON trees, raw or flexible tables, rows, new attributes, values, nested structures, whatever.

This self-extending system allows us, for example, to add a brand new EntityClass – think of an EntityClass like a ‘table name’ for now. All raw or flexible data begins with an ‘EntityClass’. An EntityClass or Attribute contains a string to name it, with an EntityClass beginning with an upper case character, an Attribute beginning with a lower case letter, and thereafter zero or more letters, digits, dot, dash, or underscore.  (The .-_ can be used for Morse code when necessary.) Here is an Item with an EntityClass called ‘Trees’ and then an ‘entity’ data component for the tree type, “red fir” – which is like a key – then a new Attribute we are creating at the same time called “type” and then “conifer” at the end for the value of the Attribute:

You can read this Item like a sentence: “There is a Tree called a red fir whose type is conifer”. Now just insert it with the Insert button, and there is a new table:

If you delete that Item, the table vanishes, leaving nothing at all behind. Now you can edit the Item in the current prefix line it to put in a new tree – “oak” as “deciduous”.

When it is inserted, there are now two rows. You can get back the Items by clicking on the table display – so the original Items re-appear in the current prefix. You can delete the entire table with the ‘delete suffixes’ button after clicking the ‘Trees’ EntityClass to set the current prefix. Click ‘commit’ from time to time when you like the current state, so you can click rollback to go back there. (This is the ‘global’ transaction feature, not the fine-grained ‘Optimistic’ ACID feature obtained by checking ‘Transactional’ explained elsewhere).

Adding a column happens when an Item with a brand new Attribute is inserted. Let’s add “hardwood” as an attribute with the value ‘false’. (Oak is not a hardwood actually.) Insert caused the table to widen by the new column. The cell for ‘red fir’ under hardwood is gray because it has no Item. Here insert false and it goes white. Each white cell has an Item in the database.

You can edit the data cells – here is the edit box containing “deciduous” now you can update it and hit checkmark, or hit plus after changing the text in the box to get a new entry, or hit minus to delete the entry in the edit box. The edit box appears when you click on the already selected cell.  You can’t add structure with the edit box, only ‘data’. For structure changes, you use the Current Prefix. Structure change basically means using a different class or attribute. The table GUI finds the attributes to display by looking forwards a bit in the database from the Current Prefix.

The tables we get this way are more flexible than regular tables. You can put structure inside the cells as well as data. Suppose we add ‘larch’, and then discover that ‘conifer’ and ‘deciduous’ are not mutually exclusive! We can put in multiple values to fix it. This is not possible in standard tabular or relational DBMS. Hence standard relational tables require an initial analysis ‘pass’ by the developers in which they figure out the desired capabilities of an application once and for all, and then create the schema and write apps that assume that schema. InfinityDB does not do that, but is more ‘agile’.

Now suppose we find that we want to store facts about red as well as white oak. We can edit the “oak” cell to add “red” and hit ‘+’.

And now we have:

Now there is a row starting with “oak” “red”, and we can put in the hardwood and type attributes for it. The original “oak” row can be changed to “oak” “white” by clicking and editing and clicking the checkmark. The result is a table with ‘composite keys’. The fact that there are multiple components in some keys is OK. Any white cell can have any combination of any number of components of the 10 ‘primitive’ data types, including string, number, Boolean, date and so on.

We call the white-cell components under ‘Trees’ ‘entities’ and those under ‘hardwood’ or ‘type’ we say are ‘values’. A sequence of zero or more primitive components in a white cell is a ‘tuple’. Each of the multiple values of an attribute can be a different tuple. So the “conifer” and “deciduous” of the “larch” form two values, not a tuple. If you move the pointer over a tuple, it goes yellow, including all of the primitive values in it, so you can distinguish multi-component tuples from multi-value attributes if they wrap. Each value can be a tuple, with no limit on the number of values, and in fact can be any nested structure. Tuples should stay relatively short, though.

Relational systems cannot have keys of varying numbers of columns with mixed data types – this is baked in, and impossible to change later. This is good and bad, because the limitation keeps the data ‘clean’, but it precludes extension. However we can force the data types to follow rules by defining queries to manipulate the data in consistent ways, and we can also transform existing data to formalize the structure. Using varying-length tuples, we can do things like create hierarchies, where the entity tuples represent the paths to the substructure. Using varying data types, we can still expand when the data type assumptions turn out later to be too limiting. We can combine numbers and text, to form hierarchically numbered sections that can have titles too.

We’ll extend this even further below, but as an aside, here is a bit about the non-tabular modes.

The JSON and Item formats

If you need the JSON data format, here is our Trees table (click on ‘Trees’ and select ‘Show as Extended JSON’). You can edit, cut and paste and save it or email it. The initial ‘Trees’ EntityClass component is implied. Note that the keys are Attributes in some places – we can actually use any of the 12 data types for keys or values or list elements. To get rid of that behavior, see ‘Underscore quoted JSON’, in which the 12 data types are encoded as strings with an initial underscore to identify them for compatibility with standard JSON.  Plain strings that happen to have an initial underscore have one more ‘stuffed in’ at the front to avoid being interpreted as non-string data types. There are data types for raw hex-displayed short byte arrays or byte ‘strings’ or short char arrays with which we can store blobs or clobs, even in JSON. An i-code or JSON list uses the ‘Index’ primitive data type.

{
    "larch" : {
        type : {
            "conifer" : null,
            "deciduous" : null
        }
    },
    "oak" : {
        hardwood : false,
        type : "deciduous",
        "red" : null
    },
    "red fir" : {
        hardwood : false,
        type : "conifer"
    }
}

Here are the underlying Items for the Trees (Click on ‘Trees’ and Select Show as Items). The initial ‘Trees’ EntityClass component is implied. The text is in the standard InfinityDB ‘tokenized’ representation for components.

"larch" type "conifer"
"larch" type "deciduous"
"oak" hardwood false
"oak" type "deciduous"
"oak" "red"
"red fir" hardwood false
"red fir" type "conifer"

The secure Python and other RESTful access uses JSON on the wire, while the secure Java ‘ItemPacket’ protocol uses discrete Items or batches in their underlying binary form for extreme speed. The browser can also display, edit and store any data in ‘i code Java Style’ ‘i code Python Style’, Lists of CSV, Sets of CSV, Lists of Strings, or blobs. The i code formats make editing PatternQueries and other data more concise, clearer and more convenient. Note that the JSON form always comes out sorted, so two JSON documents that are intended to contain the same data show up and are operated on ‘canonicalized’ so they can be compared Item-by-Item for example.

Nested Tables

Now back to tabular view. We will add more info to the flexible Trees table because we realized we have nurseries that stock them for sale. (In a relational system, we would create a new Nurseries table and have a connection table with a fixed composite key of nursery id and species id including quantities, then set up relational integrity maintenance mechanisms.) We can transform and query our Trees table easily with the pattern query feature into a different form at any time, but we want other people and fixed data sources like IoTs and older databases like backups or distributed databases to remain compatible with the existing structure.  (And, we don’t need three tables and annoying joins every time we access it as in relational systems.) So let’s add a subtable to each tree that lists the nurseries and on-hand stock. We click on the “oak” “red” to get back the Trees “oak” “red” Item, then add to it:

This can be read “There is a tree called ‘oak’ and it is a ‘red’ subtype, which is in a nursery in the location aptos in quantity 2”. We start ‘nursery’ with lower case to make it an Attribute, and ‘Location’ with upper case so it is an ‘EntityClass’. Now we have a nested table:

This kind of extension is almost limitless. Any attribute can have any number of values, distinct nested tables, distinct nested attributes, lists, pictures or BLOBs all at once. The structure grows as data flows in. It is determined entirely by the placement of components in the Items that flow in and out. Any possible set of Items has a unique corresponding representation, either in the table display, JSON, or a text Item list. A particular sensor or script producing data will often keep sending in Items of the same structure, but new data sources come along all the time, with new structure to merge in. If the structure becomes limiting in some way, it can be transformed almost limitlessly using the ‘Pattern Query’ feature.

The semantics of the Items containing EntityClasses and Attributes depends only on how pairs of them occur in the Item. There are four ways to pair them at any position in the Item:

The data parts are any adjacent sequence of zero or more of the 10 primitive data types. The adjacent primitives are a ‘tuple’ but a single primitive component can also be considered a tuple, called a ‘singleton’. The tuple after an EntityClass is an ‘entity’, and the tuple after an Attribute is a ‘value’.

Examples of the rich GUI displays you will see for different simple and complex Item patterns are shown in the database ‘demo/readonly’ and the EntityClass ‘Documentation’ at https://infinitydb.com:37411 user name ‘testUser’ password ‘db’.

 The Index Data Type

There is also an ‘index’ primitive data type that allows lists of Items to be described, as shown in the ‘Documentation’ EntityClass above, where the paragraphs are numbered by ‘[n]’ components. These can be appended to easily, and they form lists in the i-code and JSON forms, which are easily editable to handle renumbering if you insert new paragraphs in the middle.

Dialing it Back with Access Permissions

Of course this is so flexible that it can get out of hand if everyone is just adding data any time they want. So in an enterprise, there will be various means of coordinating the changes. This is done by having multiple databases with different access permissions for each role, and users can be given multiple roles. Then, a user can own a database and use it for loosely organized things, or a more formal database’s structure can be maintained by agreement at routine meetings in various groups, or a single person or two might be the controllers of the structure of a ‘curated’ database, which can be made read-only to many other users and data sinks via role permissions. There is a single ‘admin’ user who creates databases, users, passwords, roles, permissions, and grants. There are READ, WRITE,and QUERY permissions.

For very tight database control, access can be restricted to queries. The QUERY permission can be very focused – see Permissions in Managing a Server . This allows tightly controlling access by encapsulating a database behind named interfaces. Queries are grouped by interface names which can be used to control access by name or by name prefixes, as well as ‘setter’ and ‘getter’ query types. For example, without changing the externally visible semantics, a user could modify a query transparently to ‘log’ accesses or to adapt to a restructured database or to maintain replicated data. Or, the semantics of the interface can be extended in an externally compatible way without breaking clients. A combination of READ and QUERY without WRITE can ensure data consistency by preventing arbitrary updating.

Pattern Queries

Pattern Queries transform an ItemSpace in a wide variety of ways based on only an input ‘pattern’ and an output ‘result’ plus a ‘Where’ table. These query definition elements are stored as normal Items, so they can be viewed in tabular form in the web-based data browser and editor or used in any other way as data themselves. They are named and individually documented for re-use. The definition pattern and result are very flexible and represent the structures over which the query operates, while the Where table declares the individual characteristics of symbols.

The queries can do these things with simple sets of a few definition Items and no SQL or other language:

• Match patterns of input Items with ‘symbols’ literals, and expressions.
  • Match multiple correlated input Items – these ‘join’
• Output results creating new Items from symbols, literals, and expressions:
• Follow rules based on attributes of the symbols
• Execute ‘reducers’ such as counters, sums, statistics, secure hashing, timers, randomizers, custom and more

These capabilities are much more powerful than the relational ‘select’, ‘project’, ‘join’, and ‘order by’, but far simpler.

The results can be easily moved, copied, trimmed, annotated, filtered, simplified, canonicalized, sorted, restructured, re-nested, and more, with no complex syntax like SQL. See PatternQuery Examples, the PatternQuery Reference for details, PatternQuery Perspective and PatternQuery Implementation.

Transfer Suffixes

Another valuable back-end feature is the ability to quickly relocate data based on a pair of prefixes. Any Item can serve as either the source or destination prefix, enabling data movement within or between databases. This feature proves useful for tasks such as backup, database replication, or structural reorganization. The operands for this operation are the two sets of suffixes. The operation itself can involve copying, merging, intersecting, or taking the difference between the two sets of suffixes, with the option to delete the source for corresponding ‘move’ variations.

This feature gracefully handles data ‘aliasing.’ For example, it prevents errors akin to those encountered in Unix when attempting to move a directory ‘inside itself’ or ‘outside itself.’ Importantly, the operation is not contingent on the pattern of components within the Items.

.

Custom Structures

The types of structures mentioned earlier do not impose limitations on their applications. In some cases, applications create custom organizational structures, such as text indexes, genome DNA encodings, or time-series databases. Creativity can lead to achieving exceptional performance or crafting convenient, tailored models that match specific needs.

Data can be intentionally replicated in controlled ways to enhance speed. This can involve permuting the variable aspects of replicated items and then incorporating specific classes and attributes as descriptive metadata. These replications serve multiple purposes, including acting as ‘inversions,’ ‘indexes,’ or alternative perspectives, forming the foundation for further structural enhancements.

Differences with the Embedded Version

Many applications are light-weight, using only one or a few database files, and they use only InfinityDB Embedded or InfinityDB Encrypted. No back-end server is necessary for many applications, but the database is then used in a single JVM process. Security and administration of an InfinityDB Embedded file is much simpler; in fact they are non-issues.

On the other hand, InfinityDB Server requires a directory structure to store web pages, data files, SSL https certificates, CA certificates, and encrypted metadata. InfinityDB Server requires an ‘admin’ user – at least at first – to manage users, passwords, roles, permissions, and databases. The need for all of this arises as soon as data is exposed on a port, and a simplistic hand-crafted REST interface cannot easily add security and other vital features later on.

Fortunately, once an InfinityDB Server instance is running, little administration is required, because schema changes and extension are so easy in the ItemSpace data model. There are no SQL scripts for upgrade/downgrade or for the countless maintenance issues that arise in other systems.

Licensing

We provide our clients with free online trials and limited personal trial data storage at https://infinitydb.com:37411, and we license the InfinityDB Server software for private on-premises use, such as behind a firewall or on client’s secure public servers. We license it for inclusion in client’s products as well. We are working on providing servers within IoT’s, so that an IoT can collect data on its own, and then provide it to applications or users on demand.

Amazon Cloud Servers

Finally, we are working on providing client-operated cloud servers on Amazon Elastic Compute Cloud EC2. This will be done through the AWS Marketplace, where the client launches an AMI provided by us, and then pays the usage fees for it plus our small fee on top while it is running. Such an arrangement provides highly secure private storage.

Contact us at support@boilerbay.com.