lingwei.kong/hawkbit
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

Modular hawkBit (#378)

Browse Source 
* Cleaned up component scan
* More flexibility for hawkBit micro services
* Introduce spring boot starters
* Eclipse Jetty as hawkBit default
* Fixed links as prep for wiki removal

Signed-off-by: kaizimmerm <kai.zimmermann@bosch-si.com>
This commit is contained in:
Kai Zimmermann
2016-12-13 12:29:21 +01:00
committed by GitHub
parent 63adbd0298
commit 92dd6a1a0e
178 changed files with 981 additions and 585 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/src/main/resources/documentation/interfaces/ddi-api.md
View File

@@ -12,7 +12,7 @@ The _hawkbit_ [update server](https://github.com/eclipse/hawkbit) provides REST
Note: in DDI the target is identified using a **controllerId**. Controller is used as a term for the actual service/client on the device. That allows users to have in some cases even multiple clients on the same target for different tasks, e.g. Firmware update and App management.
# State Machine Mapping
For historical reasons the DDI has a different state machine and status messages than the [Target State Machine](https://github.com/eclipse/hawkbit/wiki/Target-State-Machine) of the _hawkBit_ update server.
For historical reasons the DDI has a different state machine and status messages than the [Target State Machine](../architecture/targetstate.html) of the _hawkBit_ update server.
This is kept in order to ensure that _DDI_ stays compatible for devices out there in the field. A future version "2" of _DDI_ might change that. _DDI_ also defines more states than the update server, e.g. multiple DDI states are currently mapped by the _DDI_ implementation to _RUNNING_ state. It is possible that in the future _hawkBit_ will fully leverage these additional states.

8
docs/src/main/resources/documentation/interfaces/interfaces.md
View File

@@ -10,20 +10,20 @@ title: Interfaces
# Graphical User Interface
To get started _hawkBit_ offers a [Management UI](https://github.com/eclipse/hawkbit/wiki/Management-UI) that allows operators to manage the repository and trigger provisioning operations.
To get started _hawkBit_ offers a [Management UI](management-ui.html) that allows operators to manage the repository and trigger provisioning operations.
In addition Eclipse _hawkBit_ offers developers multiple options to integrate.
# Application Integration
The _hawkBit_ [Management API](https://github.com/eclipse/hawkbit/wiki/Management-API) allows applications to manage the repository and trigger provisioning operations. It is in general feature compliant with the _Management UI_. However, small differences may occur here and there. The authentication and authorization structure is identical, i.e. a user can login both at Management API and UI with the same credentials and has the same permissions available.
The _hawkBit_ [Management API](management-api.html) allows applications to manage the repository and trigger provisioning operations. It is in general feature compliant with the _Management UI_. However, small differences may occur here and there. The authentication and authorization structure is identical, i.e. a user can login both at Management API and UI with the same credentials and has the same permissions available.
# Device Integration
For device integration two options exist.
The [Direct Device Integration API](https://github.com/eclipse/hawkbit/wiki/Direct-Device-Integration-API) allows direct integration from the device to the _hawkBit_ server. It has been designed with simplicity in mind as its is fully focused on software update. It allows device integrators to separate concerns by means of having distinguished channels for business data and general device management tasks on one side and software update on the other. As a result it is possible to keep the _lifesaving_ provisioning process controller on the device separate from the more complex business functionality. A benefit of such an architecture should not be underestimated.
The [Direct Device Integration API](ddi-api.html) allows direct integration from the device to the _hawkBit_ server. It has been designed with simplicity in mind as its is fully focused on software update. It allows device integrators to separate concerns by means of having distinguished channels for business data and general device management tasks on one side and software update on the other. As a result it is possible to keep the _lifesaving_ provisioning process controller on the device separate from the more complex business functionality. A benefit of such an architecture should not be underestimated.
As result of such a simple HTTP/REST/JSON based API even a major back-end migration or disaster can be covered with simple web server hosting a text file that contains only the command to update one more time to execute a migration on the device. The API was designed on purpose in way to have that last resort even if the plan is that this will never be necessary.
The [Device Management Federation API](https://github.com/eclipse/hawkbit/wiki/Device-Management-Federation-API) however allows to combine the business data and _hawkBit_ connectivity. This is especially usefull if a constrained device cannot handle a TLS/HTTP connection, is supporting a standard device management protocol that covers also the software update part (e.g. TR-069, OMA-DM, LWM2M) or the device is already connected and _hawkBit_ is introduced later on.
The [Device Management Federation API](dmf-api.html) however allows to combine the business data and _hawkBit_ connectivity. This is especially usefull if a constrained device cannot handle a TLS/HTTP connection, is supporting a standard device management protocol that covers also the software update part (e.g. TR-069, OMA-DM, LWM2M) or the device is already connected and _hawkBit_ is introduced later on.
The decision for the right device integration path is up to the integration party.

2
docs/src/main/resources/documentation/interfaces/management-api.md
View File

@@ -46,7 +46,7 @@ For all requests an `Authorization` header has to be set.
* Username: `Tenant\username`
* Password: `password`
Also have a look to the [Security](https://github.com/eclipse/hawkbit/wiki/Security) chapter.
Also have a look to the [Security](../security/security.html) chapter.
In addition, for POST and PUT requests the `Content-Type` header has to be set. Accepted content-types are.