Technology

Microservices

The Microservice architecture drives the design of the software towards small and well defined modules of business functions with high cohesion.

Cloud Native

Strictly following the Twelve-Factor manifesto all services are cloud enabled but do not have to run in the cloud.

Polyglot

OpenWMS.org does not depend on a particular database product nor on storage technology. Different services use different types of datastores. From relational to NoSQL databases.

Workflow

A workflow engine is used to control and change the material flow handling dynamically without interrupts and downtimes.

Microservice Hub

As we've built a couple of microservices, we find it reasonable to create a central website where all microservices are listed and explained in detail. Beside a functional service description each microservice' website contains informtion about how a service consumer can access and use the outer public API. This API documentation explains how to operate with the exposed resources and describes the interaction model, how service calls can be combined to fulfill common use cases.

We differentiate between RTU and BYO services. The former ready-to-use services are already deployed in the public cloud and require valid access tokens for access. The latter build-your-own services are not installed and not online available. For all online services an account registration is required.

Online services may guarantee SLA depending on the non-functional service requirements and based on their runtime environment. Some services (like the service registry and configuration service) run in a geo distributed cluster on different PaaS platforms (e.g. Heroku Cloud and OpenShit Cluster) to achieve a high degree of availability. The SLA are defined by the service itself and documented on the service website.

The Public Microservice Hub.

Private services.

Deployment Scenarios

A typical customer project built with OpenWMS.org is usually a composition of microservices to fulfill the functional requirements. Whereas a service may run in the cloud or on premise customer side. This mainly depends on the quality requirements of the project. For example, a service like the tcp/ip driver must obviously run with low latency close to the automation systems layer whereas and UI services may easily run off-side.

OpenWMS.org is designed to run in four deployment models

  • Cloud

    All microservices run off-site in the cloud and may shared with other customers. Service access is secured but no QoS are defined.

  • Fog

    All microservices run on-side in the private cloud and are solely dedicated to the customer project.

  • Hybrid

    In a combination of Cloud and Fog deployment, some common shared services may reside on the public cloud where other mission critical of time critical services run locally in the private cloud

  • Monolith

    All microservices are packaged into a single monolithic deployment unit that runs on traditional application services. Notice that in this scenario elasticity is only available on infrastructure level (IaaS) not on service level.

Team

Heiko Scherrer

Project founder and actively developing since 2005.

Frank Lauer

One of the first projects contributors when OpenWMS.org was built on EJB technology.

Michael Schmut

Innovation driver. Michael put in ideas and laid out the set of technologies already before the project was initiated.

Tina Russell

In times of Adobe Flex was used for the UI part, Tina implemented the UI application almost on her own.

Florian Gyger

Thinktank

Mischa Farbstein

Best in business analysis and requirements engineering with lots of project experience.