Arrowhead (and its continuation, Productive4.0) is an ambitious holistic innovation project, meant to open the doors to the potentials of Digital Industry and to maintain a leadership position of the industries in Europe. All partners involved will work on creating the capability to efficiently design and integrate hardware and software of Internet of Things (IoT) devices. Linking the real with the digital world takes more than just adding software to the hardware.
Placeholder
The project has the following dependencies:
- JRE/JDK 11 Download from here
- Maven 3.5+ Download from here | Install guide
- MySQL server 5.7+ (other SQL databases can work with Hibernate ORM, but the
common module pom.xmlhas to include the appropriate connector dependency to use them)
Verify that you have Java (java -version), Maven (mvn -version), MySQL installed properly!
Pull this code and enter the directory.
git clone https://github.com/arrowhead-f/core-java-spring.git
Run the MySQL script which is in the scripts folder. If you won't run this script first, the project won't build.
cd core-java-spring
Execute mvn install command. Wait until the build succeeds.
This command builds all available projects.
After succeeding enter the scripts folder and execute start_core_systems.sh or start_core_systems.bat depending on your operating system.
- serviceregistry/target directory.
cd serviceregistry/target
and execute:java -jar arrowhead-serviceregistry-4.1.3.jar - authorization/target directory.
cd authorization/target
and execute:java -jar arrowhead-authorization-4.1.3.jar - orchestrator/target directory.
orchestrator/target
and execute:java -jar arrowhead-orchestrator-4.1.3.jar
Wait until servers start...
Service Registry will be available on localhost:8443
Authorization will be available on localhost:8445
Orchestrator will be available on localhost:8441
Event Handler will be available on localhost:8455
Gatekeeper will be available on localhost:8449
Gateway will be available on localhost:8453
Swagger with API documentation is available in the root route.
Enjoy! ;)
4.1.3 is NOT backwards compatible with 4.1.2! The database and the endpoints were redesigned, it is more logical, easier to use.
You can migrate your existing database manually. See the Quick Start Guide, how to deploy the Core Systems.
Major endpoint changes:
- /register - data structure changed
/remove- removed, use /unregister instead
- /mgmt/intracloud - data structure changed
- /mgmt/intercloud - data structure changed
Store based orchestration is available for now.
- /mgmt/store - data structure changed
All work on Arrowhead repositories happens directly on GitHub. Both core team members and external contributors send pull requests which go through the same review process.
The latest version of the core systems are available in the master branch. The code for the next release is merged in the development branch. If you would like to contribute, please check out the development branch. Create a new branch from development. Don't forget do write documentation, unit and integration tests. When finished, create a pull request back into development. If accepted, your contribution will be in the next release. :)
We are using GitHub Issues for our public bugs. We keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn’t already exist.
The best way to get your bug fixed is to provide a reduced test case.
Join our developer team on Slack. Write an email to [email protected] for an invite.
This System provides the database, which stores information related to the currently actively offered Services within the Local Cloud.
The purpose of this System is therefore to allow:
- Application Systems to register what Services they offer at the moment, making this announcement available to other Application Systems on the network.
- They are also allowed to remove or update their entries when it is necessary.
- All Application Systems can utilize the lookup functionality of the Registry to find appropriate Service offerings in the network.
However, it is worth noting, that within this generation the lookup functionality of Services is integrated within the “orchestration process”. Therefore, in the primary scenario, when an Application System is looking for a Service to consume, it shall ask the Orchestrator System via the Orchestration Service to locate one or more suitable Service Providers and help establish the connection based on metadata submitted in the request. Direct lookups from Application Systems within the network is not advised in this generation, due to security reasons.
However, the lookup of other Application Systems and Services directly is not within the primary use, since access will not be given without the Authorization JWT (JSON Web Token). The use of the TokenGeneration is restricted to the Orchestrator for general System accountability reasons.
This System only provides one Core Service the Service Discovery
There are two use case scenarios connected to the Service Registry.
- Service registration, de-registration
- Service Registry querying (lookup)
The register method is used to register services. The services will contain various metadata as well as a physical endpoint. The various parameters are representing the endpoint information that should be registered.
The unregister method is used to unregister service instances that were previously registered in the Registry. The instance parameter is representing the endpoint information that should be removed.
The query method is used to find and translate a symbolic service name into a physical endpoint, for example an IP address and a port. The query parameter is used to request a subset of all the registered services fulfilling the demand of the user of the service. The returned listing contains service endpoints that have been fulfilling the query.
There is another functionality that does not bound to any Services, just an internal part of the Service Registry. There are two optional cleanup tasks within the Service Registry, which can be used to remove old, inactive service offerings. The first task is based on pinging the service provider and if the provider does not respond to the ping, its offered services will be deleted. The second task is based on a feature, called “Time to Live”. Service providers upon registration can provide a timestamp called “end_of_validity” number, which specifies how long the service will be offered by the provider, making the service de-registrations unnecessary, if this task is active. The task is used to remove expired services. The third task is using a feature called "Heartbeat" (Not yet implemented), where the Service provider periodically signals to the Service Registry that it is still alive. When it misses it will be removed. All of these internal tasks can be configured in the application.properties file.
This System can be secured via the HTTPS protocol. If it is started in secure mode, it verifies whether the Application System possesses a proper X.509 identity certificate and whether that certificate is Arrowhead compliant in its making. This certificate structure and creation guidelines ensure:
- Application System is properly bootstrapped into the Local Cloud
- The Application System indeed belongs to this Local Cloud
- The Application System then automatically has the right to register its Services in the Registry.
If these criteria are met, the Application System’s registration or removal message is processed. An Application System can only delete or alter entries that contain the Application System as the Service Provider in the entry.