About Nebula

Nebula is intended for use by developers or hobbyists who want to quickly and easily build cross platform applications for remote control, monitoring, security, messaging or countless other uses. Nebula provides the means for others to develop the ends. It contains all the classes and methods required to build, monitor and execute network commands. They can be copied directly into your source code or imported on an as-needed basis.

Nebula leverages the computing power of modern devices to allow you to build and host your own network. It provides security and autonomy for web service applications. It is supplied as Java source code to be used in an Integrated Development Environment (IDE). Nebula development packages include the code for:

  • A muti-threaded HTTP server for receiving and verification of data.
  • An HTTP client for for building encoded HTTP headers and sending payloads.
  • A reciprocal numerical protocol for user supplied commands.
  • A single class command builder for client and server actions.
  • Native commands to add, modify or delete network devices.
  • Native commands to maintain network and device synchronization.
  • End-to-end encryption for public Internet data.
  • Mobile device support via SMS client.
  • Hub action to forward commands and relay responses.
  • Central server action for streaming data.
  • Demonstration commands for popular network operations.

Nebula is supplied as 3 Java development packages and 1 ANSI C package, each operates individually as your application may require. You are free to use any supplied code as-is or modify, add to or delete code as your application requires.

  1. The Java package is named Nebula_JAR. It uses the Intellij IDE and outputs a .jar executable for use on Linux, Windows and MacOS devices.
  2. The Android package is named Nebula_APK. It uses the Android Studio IDE and outputs a .apk executable for Android phones or pads. NOTE: Intellij can build Android code too, it just doesn’t integrate with Google Play as well as Android Studio. The look and feel of both IDEs is identical. Also, the Java code of Nebula_JAR and Nebula_APK is identical in most respects except for making user interfaces.
  3. The Arduino package is named Nebula_BIN. It uses the Arduino IDE and outputs a .bin executable for ESP8266/32 WiFi/BT modules. Nebula_BIN is not true Java but written in the Arduino .ino language which is similar to Java. The Arduino package can be applied to any WiFi capable Arduino board. Arduino devices have limited and typically a specialized capability. Arduino devices are fully supported on a network but cannot establish or maintain the network. Arduino devices must be used in conjunction with a Java or Android device that has established a Nebula VPN.
  4. The ANSI C package is named Andromeda and it’s used for native library development on any device that has a compatible C compiler. Andromeda and Nebula use the same communication protocol and network devices can be mixed and matched as an application requires.

Nebula is a binary-over-HTTP web-service application that builds and maintains a Virtual Private Network(VPN) incorporating multi-platform devices. Nebula includes both an HTTP client and symbiotic muti-threaded HTTP server. Its primary use is assist developers in building private and secure web applications for personal or commercial use. Your web applications can be anything your remote devices are capable of, from simple monitoring and control applications to a fully autonomous network where devices work in conjunction with each other to perform tasks without human intervention. Nebula is also a developers toolbox, the supplied source code can save weeks of development time incorporating features like web client/server, database operations, video streaming and much more into Java, Android and Arduino platform applications.

Nebula uses a unique and patented protocol to describe a command-response web transaction between devices in as little as 20 bytes. Within those 20 bytes Nebula, as supplied, can reference 64K commands and to/from 64K devices. As a numerical reference, the protocol is easily extended or reduced to suit the needs of an application. With Nebula, commands can string together to perform complex tasks between devices that run event-driven without human intervention. User interfaces, while not required, can certainly be employed as needed by an application. The protocol is OS agnostic, it can be used over Bluetooth, LoRa as well as a serial connection allowing software compatibility over a wide range of devices and applications.

Nebula builds on HTTP so a data payload can be sent by the client with a command and returned from the server in its reply. A data payload is not always required because, for simple commands, the protocol itself identifies the command and returns a success or failed response code.

Unlike a traditional web-service that may use XML files or JSON strings, Nebula puts client command prepare, server action and client post action in a single Command class. This way only a single file needs to be maintained. Nebula commands are reciprocal so every device that uses the particular command knows:

  1. What, if any, payload to send with the command.
  2. How to execute the command based on its value and payload.
  3. What to do in response to the returned value and payload.

Any Java or Android device can act as a hub. If it receives a command not intended for it, the device will forward the command to the intended device and relay the response back to the sender. The hub action works for both command and streaming protocols. The primary purpose of the hub is to permit remote or mobile devices to communicate with devices on a private or home network. As supplied, Nebula uses Device 1 as the hub with public ports forwarded to it.

Nebula devices employ and maintain a distributed database similar to a Block Chain, so every device knows the current status and contact details of every other device on the VPN. Additionally, Nebula devices optionally employ end-to-end TLS security. All data sent over the internet is encrypted. The encryption can be turned off for development debug purposes but is highly recommended for release applications.

Nebula vs SOAP or REST

First the acronyms used:
SOAP - Simple Object Access Protocol
REST - Representational State Transfer
XML - Extended Markup Language
JSON - JavaScript Object Notation
CSV - Comma Separated Value
RSS - Really Simple Syndication
HTTP - Hyper-Text Transfer Protocol

SOAP, REST and Nebula are all web service applications. SOAP and REST were both designed to rely on the services provided by the website they want to interact with. They are not especially suited for embedded IoT applications where XML or JSON parsing can be problematic.

SOAP really isn’t as simple as the acronym would suggest. It relies exclusively on XML to provide messaging services. The XML used to make requests and receive responses in SOAP can become extremely complex. In some programming languages, you need to build those requests manually, which becomes problematic because SOAP is intolerant of errors. For example, working with SOAP in JavaScript means writing a lot of code to perform extremely simple tasks because you must create the required XML structure absolutely every time.

REST provides a lighter weight alternative to SOAP. Instead of using XML to make a request, REST relies on a simple URL in many cases. REST can use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks. Unlike SOAP, REST doesn’t have to use XML to provide the response. You can find REST-based Web services that output the data in CSV, JSON and RSS. Its primary use is to interact with a web page that understands its request, so both the website and the REST application files must be matched and maintained for it to work.

Nebula does not use XML as a messaging medium, instead it uses numerical values to describe a command, the sender, and the receiver. The protocol then attaches an optional payload representing any data that needs to accompany the command. On the server side the received HTTP header and data first go through a security check. Then the server passes the data to a parser for command execution. After the command has run the server returns a pass/fail response code to the client with an optional payload describing what has occurred. The client then reads the response and can either send another command or inform the user based on the result. The prepare, run and post command code exist in a single command class so only a single file has to be maintained. The result is easier code to maintain, better security and a faster more efficient web service using substantially less network data than either REST or SOAP.