Introduce module loaders.

README.md

@@ -1,7 +1,11 @@
 This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments
 
-# Beta Azure IoT Gateway SDK
-Using this SDK, developers write applications that enable gateway-connected devices to communicate with Azure IoT Hub. Such applications use a collection of **modules** to aggregate and transform data, process commands, or perform any number of related tasks. Modules communicate with one another via a message broker. Developers can choose from available modules or write their own to create gateways tailored to any scenario.
+# Azure IoT Gateway SDK
+Using this SDK, developers write applications that enable gateway-connected devices to 
+communicate with Azure IoT Hub. Such applications use a collection of **modules** to aggregate 
+and transform data, process commands, or perform any number of related tasks. Modules 
+communicate with one another via a message broker. Developers can choose from available modules 
+or write their own to create gateways tailored to any scenario.
 
 Visit http://azure.com/iotdev to learn more about developing applications for Azure IoT.
 
@@ -18,51 +22,71 @@ The following modules are available in this repository:
 >| azure_functions  | Sends message content to an Azure Function                              | 
 
 ## Featured Modules
-Other people are creating modules for the gateway SDK too! See the **More information** link for a module to find out how to get it, who supports it, etc.
->| Name   | More information                            | Targets gateway SDK version |
->|--------|---------------------------------------------|-----------------------------|
->| Modbus | https://github.com/Azure/iot-gateway-modbus | 2016-10-06                  |
+Other people are creating modules for the gateway SDK too! See the **More information** link for 
+a module to find out how to get it, who supports it, etc.
+>| Name          | More information                            | Targets gateway SDK version |
+>|---------------|---------------------------------------------|-----------------------------|
+>| Modbus        | https://github.com/Azure/iot-gateway-modbus | 2016-11-02                  |
+>| OPC-UA Client | https://github.com/Azure/iot-gateway-opc-ua | 2016-11-02                  |
 
-We'd love to feature your module here! See our [Contribution guidelines](Contributing.md) for more info.
+We'd love to feature your module here! See our [Contribution guidelines](Contributing.md) for 
+more info.
 
 ## Operating system compatibility
-The SDK is designed to be used with a broad range of operating system platforms. The Beta version of the Azure IoT Gateway SDK has been tested by means of development on the following operating systems:
+The SDK is designed to be used with a broad range of operating system platforms. The version 
+of the Azure IoT Gateway SDK has been tested on the following operating systems:
 
 - Ubuntu 14.04
 - Ubuntu 15.10
 - Yocto Linux 3.0 on Intel Edison
 - Windows 10
+- Wind River 7.0
 
 ## Hardware compatibility
-The SDK is designed to be independent from hardware in addition to the operating system. Developers can power their gateways with hardware as constrained as a microcontroller to systems as powerful as a ruggedized server.
+The SDK is designed to be independent from hardware in addition to the operating system. 
+Developers can power their gateways with hardware as constrained as a microcontroller to 
+systems as powerful as a ruggedized server.
 
 ## Directory structure
 
 ### /doc
-This folder contains general documentation for the SDK as well as step by step instructions for building and running the samples:
+This folder contains general documentation for the SDK as well as step by step instructions 
+for building and running the samples:
 
 General documentation
 
-- [Dev box setup](doc/devbox_setup.md) contains instructions for configure your machine to build the Azure IoT Gateway SDK.
-- [Getting started](doc/getting_started.md) contains an introduction to the Azure IoT Gateway SDK as well as a detailed walkthrough of the [Hello World sample](doc/sample_hello_world.md).
-
-Samples
-
-- [Hello World sample](doc/sample_hello_world.md) contains step by step instructions for building and running the Hello World sample.
-- [Simulated Device](doc/sample_simulated_device_cloud_upload.md) contains step by step instructions for building and running the Simulated Device sample.
-- [TI Sensor Tag](doc/sample_ble.md) contains step by step instructions for building and running the TI Sensor Tag sample.
-
+- [Dev box setup](doc/devbox_setup.md) contains instructions for configuring your machine to 
+build the Azure IoT Gateway SDK.
 
 API documentation can be found [here](http://azure.github.io/azure-iot-gateway-sdk/api_reference/c/html).
 
 ### /samples
-This folder contains all of the samples for the Azure IoT Gateway SDK. Samples are seperated in their own folders. Step by step instructions for building and running each sample can be found in a sample specific .md file located in azure-iot-gateway-sdk/doc.
+This folder contains all of the samples for the Azure IoT Gateway SDK. Samples are separated 
+in their own folders. Step by step instructions for building and running each sample can be found 
+in the README.md file in the root of each sample's folder.
+
+Samples include:
+- [Hello World](samples/hello_world/README.md) - Learn the basic concepts of the Azure IoT 
+Gateway SDK by creating a simple gateway that logs a hello world message to a file every 5 seconds.
+- [Simulated Device](samples/simulated_device_cloud_upload/README.md) Send data to IoTHub from
+a gateway using a simualted device instead of using a real device. 
+- [Real Device](samples/ble_gateway/README.md) - Send data to IoTHub from a real device that could not
+connect to the cloud unless it connected through a gateway. This sample uses a Blueetooth Low Energy 
+[Texas Instruments SensorTag](http://www.ti.com/ww/en/wireless_connectivity/sensortag2015/index.html) 
+as the end device .
 
 ### /modules
-This folder contains all of the modules included with the Azure IoT Gateway SDK. Each module represents a specific piece of functionality that can be composed into an end to end gateway solution. Details on the implementation of each module can be found in each module's devdoc/ folder. 
+This folder contains all of the modules included with the Azure IoT Gateway SDK. Each module 
+represents a specific piece of functionality that can be composed into an end to end gateway 
+solution. Details on the implementation of each module can be found in each module's devdoc/ folder. 
 
 ### /core
-This folder contains all of the core infrastructure necessary to create a gateway solution. In general, developers only need to use components in the core folder, not modify them. API documentation for core infrastructure can be found [here](http://azure.github.io/azure-iot-gateway-sdk/api_reference/c/html). Details on the implementation of core components can be found in the [core/devdoc](core/devdoc).
+This folder contains all of the core infrastructure necessary to create a gateway solution. 
+In general, developers only need to *use* components in the core folder, not modify them. API 
+documentation for core infrastructure can be found [here](http://azure.github.io/azure-iot-gateway-sdk/api_reference/c/html). 
+Details on the implementation of core components can be found in [core/devdoc](core/devdoc).
 
 ### /build
-This is the default folder that cmake will place the output from our build scripts. The developer always has the final say about the destinaiton of build output by creating a folder, navigating to it, and then running cmake from there. Detailed instructions are contained in each sample doc.
+This is the default folder that cmake will place the output from our build scripts. The developer 
+always has the final say about the destinaiton of build output by creating a folder, navigating to 
+it, and then running cmake from there. Detailed instructions are contained in each sample doc.

bindings/dotnet/devdoc/dotnet_binding_requirements.md

@@ -147,10 +147,10 @@ void DotNet_Destroy(MODULE_HANDLE module);
 
 **SRS_DOTNET_04_020: [** `DotNet_Destroy` shall free all resources associated with the given module.. **]**
 
-Module_GetAPIs
+Module_GetApi
 --------------
 ```c
-MODULE_EXPORT const MODULE_API* Module_GetApi(const MODULE_API_VERSION gateway_api_version);
+MODULE_EXPORT const MODULE_API* Module_GetApi(MODULE_API_VERSION gateway_api_version);
 ```
 
 **SRS_DOTNET_26_001: [** `Module_GetApi` shall return out the provided `MODULES_API` structure with required module's APIs functions. **]**

bindings/dotnet/inc/dotnet.h

@@ -18,7 +18,7 @@ typedef struct DOTNET_HOST_CONFIG_TAG
     const char* module_args;
 }DOTNET_HOST_CONFIG;
 
-MODULE_EXPORT const MODULE_API* Module_GetApi(const MODULE_API_VERSION gateway_api_version);
+MODULE_EXPORT const MODULE_API* Module_GetApi(MODULE_API_VERSION gateway_api_version);
 
 extern __declspec(dllexport) bool Module_DotNetHost_PublishMessage(BROKER_HANDLE broker, MODULE_HANDLE sourceModule, const unsigned char* message, int32_t size);
 

bindings/dotnet/src/dotnet.cpp

@@ -711,9 +711,9 @@ static const MODULE_API_1 DOTNET_APIS_all =
 
 /*Codes_SRS_DOTNET_26_001: [ Module_GetApi shall return out the provided MODULES_API structure with required module's APIs functions. ]*/
 #ifdef BUILD_MODULE_TYPE_STATIC
-MODULE_EXPORT const MODULE_API* MODULE_STATIC_GETAPI(DOTNET_HOST)(const MODULE_API_VERSION gateway_api_version)
+MODULE_EXPORT const MODULE_API* MODULE_STATIC_GETAPI(DOTNET_HOST)(MODULE_API_VERSION gateway_api_version)
 #else
-MODULE_EXPORT const MODULE_API* Module_GetApi(const MODULE_API_VERSION gateway_api_version)
+MODULE_EXPORT const MODULE_API* Module_GetApi(MODULE_API_VERSION gateway_api_version)
 #endif
 {
     (void)gateway_api_version;

bindings/dotnet/tests/dotnet_e2e/dotnet_e2e.cpp

@@ -84,7 +84,7 @@ static const MODULE_API_1 E2E_APIS_all =
     NULL
 };
 
-MODULE_EXPORT const MODULE_API* Module_GetApi(const struct MODULE_LOADER_TAG* loader, const MODULE_API_VERSION gateway_api_version)
+MODULE_EXPORT const MODULE_API* Module_GetApi(const struct MODULE_LOADER_TAG* loader, MODULE_API_VERSION gateway_api_version)
 {
     return reinterpret_cast<const MODULE_API *>(&E2E_APIS_all);
 }

bindings/java/inc/java_module_host.h

@@ -45,7 +45,7 @@ typedef struct JAVA_MODULE_HOST_CONFIG_TAG
     JVM_OPTIONS* options;
 } JAVA_MODULE_HOST_CONFIG;
 
-MODULE_EXPORT const MODULE_API* MODULE_STATIC_GETAPI(JAVA_MODULE_HOST)(const MODULE_API_VERSION gateway_api_version);
+MODULE_EXPORT const MODULE_API* MODULE_STATIC_GETAPI(JAVA_MODULE_HOST)(MODULE_API_VERSION gateway_api_version);
 
 #ifdef __cplusplus
 }

bindings/java/src/java_module_host.c

@@ -949,9 +949,9 @@ static const MODULE_API_1 JavaModuleHost_APIS =
 
 /* Codes_SRS_JAVA_MODULE_HOST_26_001: [ Module_GetApi shall fill out the provided MODULES_API structure with required module's APIs functions. ]*/
 #ifdef BUILD_MODULE_TYPE_STATIC
-MODULE_EXPORT const MODULE_API* MODULE_STATIC_GETAPI(JAVA_MODULE_HOST)(const MODULE_API_VERSION gateway_api_version)
+MODULE_EXPORT const MODULE_API* MODULE_STATIC_GETAPI(JAVA_MODULE_HOST)(MODULE_API_VERSION gateway_api_version)
 #else
-MODULE_EXPORT const MODULE_API* Module_GetApi(const MODULE_API_VERSION gateway_api_version)
+MODULE_EXPORT const MODULE_API* Module_GetApi(MODULE_API_VERSION gateway_api_version)
 #endif
 {
     (void)gateway_api_version;

bindings/nodejs/devdoc/nodejs_binding_requirements.md

@@ -204,10 +204,10 @@ void NodeJS_Destroy(MODULE_HANDLE module);
 
 **SRS_NODEJS_13_025: [** `NodeJS_Destroy` shall free all resources. **]**
 
-Module_GetAPIs
+Module_GetApi
 --------------
 ```c
-MODULE_EXPORT const MODULE_API* Module_GetApi(const MODULE_API_VERSION gateway_api_version);
+MODULE_EXPORT const MODULE_API* Module_GetApi(MODULE_API_VERSION gateway_api_version);
 ```
 
 **SRS_NODEJS_26_001: [** `Module_GetApi` shall return the `MODULES_API` structure with required module's APIs functions. **]**

bindings/nodejs/inc/nodejs.h

@@ -18,7 +18,7 @@ typedef struct NODEJS_MODULE_CONFIG_TAG
     STRING_HANDLE configuration_json;
 }NODEJS_MODULE_CONFIG;
 
-MODULE_EXPORT const MODULE_API* MODULE_STATIC_GETAPI(NODEJS_MODULE)(const MODULE_API_VERSION gateway_api_version);
+MODULE_EXPORT const MODULE_API* MODULE_STATIC_GETAPI(NODEJS_MODULE)(MODULE_API_VERSION gateway_api_version);
 
 #ifdef __cplusplus
 }

bindings/nodejs/src/nodejs.cpp

@@ -1315,9 +1315,9 @@ static const MODULE_API_1 NODEJS_APIS_all =
 };
 
 #ifdef BUILD_MODULE_TYPE_STATIC
-MODULE_EXPORT const MODULE_API* MODULE_STATIC_GETAPI(NODEJS_MODULE)(const MODULE_API_VERSION gateway_api_version)
+MODULE_EXPORT const MODULE_API* MODULE_STATIC_GETAPI(NODEJS_MODULE)(MODULE_API_VERSION gateway_api_version)
 #else
-MODULE_EXPORT const MODULE_API* Module_GetApi(const MODULE_API_VERSION gateway_api_version)
+MODULE_EXPORT const MODULE_API* Module_GetApi(MODULE_API_VERSION gateway_api_version)
 #endif
 {
     (void)gateway_api_version;

core/devdoc/module.md

@@ -52,16 +52,16 @@ typedef struct MODULE_API_1_TAG
     pfModule_Start Module_Start;
 } MODULE_API_1;
 
-typedef const MODULE_API* (*pfModule_GetApi)(const MODULE_API_VERSION gateway_api_version);
+typedef const MODULE_API* (*pfModule_GetApi)(MODULE_API_VERSION gateway_api_version);
 
-MODULE_EXPORT const MODULE_API* Module_GetApi(const MODULE_API_VERSION gateway_api_version);
+MODULE_EXPORT const MODULE_API* Module_GetApi(MODULE_API_VERSION gateway_api_version);
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Module\_GetApi
 --------------
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ c
-typedef MODULE_API* (*pfModule_GetApi)(const MODULE_API_VERSION gateway_api_version);
+typedef MODULE_API* (*pfModule_GetApi)(MODULE_API_VERSION gateway_api_version);
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This function is to be implemented by the module creator. It will return a

core/inc/module.h

@@ -178,7 +178,7 @@ extern "C"
      *
      *  @return NULL in failure, MODULE_API* pointer on success.
      */
-    typedef const MODULE_API* (*pfModule_GetApi)(const MODULE_API_VERSION gateway_api_version);
+    typedef const MODULE_API* (*pfModule_GetApi)(MODULE_API_VERSION gateway_api_version);
 
     /** @brief  Returns the module APIS name.*/
 #define MODULE_GETAPI_NAME ("Module_GetApi")
@@ -198,7 +198,7 @@ extern "C"
  *              convention" name. Using the exported function, the caller learns
  *              the functions for the particular module.
  */
-MODULE_EXPORT const MODULE_API* Module_GetApi(const MODULE_API_VERSION gateway_api_version);
+MODULE_EXPORT const MODULE_API* Module_GetApi(MODULE_API_VERSION gateway_api_version);
 
 #ifdef __cplusplus
 }

core/tests/gateway_e2e/e2e_module/src/e2e_module.c

@@ -163,7 +163,7 @@ static const MODULE_API_1 E2EModule_APIS_all =
 
 };
 
-MODULE_EXPORT const MODULE_API* Module_GetApi(const MODULE_API_VERSION gateway_api_version)
+MODULE_EXPORT const MODULE_API* Module_GetApi(MODULE_API_VERSION gateway_api_version)
 {
     (void)gateway_api_version;
     return (const MODULE_API *)&E2EModule_APIS_all;