Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "BaSyx / Documentation / Components"
m (Adds registry component) |
(Adds description on how to create new components) |
||
| Line 1: | Line 1: | ||
= Components = | = Components = | ||
| + | == Off-the-Shelf-Components == | ||
BaSyx provides several easy to use off-the-shelf components. They can be used programmatically, as an executable jar or as a [[BaSyx_/_Documentation_/_Components_/_Docker | docker container]]. | BaSyx provides several easy to use off-the-shelf components. They can be used programmatically, as an executable jar or as a [[BaSyx_/_Documentation_/_Components_/_Docker | docker container]]. | ||
* [[BaSyx_/_Documentation_/_Components_/_AAS_Server | AAS Server Component]] | * [[BaSyx_/_Documentation_/_Components_/_AAS_Server | AAS Server Component]] | ||
* [[BaSyx_/_Documentation_/_Components_/_Registry | Registry Component]] | * [[BaSyx_/_Documentation_/_Components_/_Registry | Registry Component]] | ||
| + | |||
| + | == Developing own Components == | ||
| + | There are multiple ways of implementing BaSys 4.0 conforming components. | ||
| + | |||
| + | === Extending Existing Interfaces === | ||
| + | For each component, there exist interfaces that can be implemented to realize e.g. new backends. These interfaces integrate seamless in the REST-API-Provider. Additionally, the already defined test suites for the different component types can easily be reused. | ||
| + | |||
| + | In consequence, this is the easiest and fastest way of introducing new components. | ||
| + | |||
| + | === Conforming to the REST-API === | ||
| + | If the interfaces provided by BaSyx can't be used (e.g. because the component is implemented in a programming language currently not supported by BaSyx), it has to be ensured that the component is conforming to the defined REST-API and behavior. | ||
| + | |||
| + | For this, BaSyx provides a Technology Compatibility Kit (TCK). The TCKs for the components can be found in the repository in ''components/tck''. For each component, there exists a TCK. Each TCK allows to generate a jar file that tests component functionality of arbitrary http endpoints. | ||
| + | Each jar can be called in the following way: | ||
| + | java -jar $JAR $HTTP_ENDPOINT | ||
| + | where ''$JAR'' is the name of the component's TCK jar and ''$HTTP_ENDPOINT'' is the endpoint on which the component's REST API is available. | ||
Revision as of 07:40, 21 October 2020
Contents
Components
Off-the-Shelf-Components
BaSyx provides several easy to use off-the-shelf components. They can be used programmatically, as an executable jar or as a docker container.
Developing own Components
There are multiple ways of implementing BaSys 4.0 conforming components.
Extending Existing Interfaces
For each component, there exist interfaces that can be implemented to realize e.g. new backends. These interfaces integrate seamless in the REST-API-Provider. Additionally, the already defined test suites for the different component types can easily be reused.
In consequence, this is the easiest and fastest way of introducing new components.
Conforming to the REST-API
If the interfaces provided by BaSyx can't be used (e.g. because the component is implemented in a programming language currently not supported by BaSyx), it has to be ensured that the component is conforming to the defined REST-API and behavior.
For this, BaSyx provides a Technology Compatibility Kit (TCK). The TCKs for the components can be found in the repository in components/tck. For each component, there exists a TCK. Each TCK allows to generate a jar file that tests component functionality of arbitrary http endpoints. Each jar can be called in the following way:
java -jar $JAR $HTTP_ENDPOINT
where $JAR is the name of the component's TCK jar and $HTTP_ENDPOINT is the endpoint on which the component's REST API is available.