Skip to content

openwms/org.openwms

Repository files navigation

OpenWMS.org

Is a free to use and extensible Warehouse Management System (WMS) with a Material Flow Control (MFC) system for automatic and manual warehouses.

Find further documentation in the Wiki

Architecture

Instead of applying a technical layered architecture (like with previous technologies), the current architecture focuses on business components. Business functions with a high cohesion are kept together as small deployable software components. Each component has its own development lifecycle with its own roadmap of the API evolution and a separate data store. The following sketch shows all currently existing components of the OpenWMS.org system together with all potential surrounding systems.

Architecture

Beside the user interface, several other systems interact with the OpenWMS.org system. ERP systems on top are sending high-level tasks to OpenWMS.org, e.g. a customer orders with order lines that refer to products managed by the Inventory Service. OpenWMS.org fulfills these tasks by orchestrating the underlying subsystems. The communication between OpenWMS.org and an ERP system might be in both directions, OpenWMS.org although sends status messages back to the ERP or might request product catalog updates, depending on the project needs. On the bottom of the above graphic the system if connected to devices that are close to actors and sensors in automatic warehouses. Those devices are almost limited in hardware resources and protocol stacks. Typical PLC (Programmable Logic Controllers) are used to interact with field sensors and to control actors. OpenWMS.org is an open source software and therefore promotes the usage of open source hardware components over commercial PLC products. The first choice of supported devices are boards, like Raspberry Pi or industrial Revolution Pi, with an open microcontroller architecture. But nevertheless also closed proprietary systems are supported as well. All this kind of subsystems have one thing in common: They are close to the hardware and expect response times in the range of milliseconds to control motors and switch gates very quickly. They have the power to bring down a serving component down just by repeating requests all the time. Typical web application clients are different in that the infrastructure takes care of DoS attacks, and the application server pools incoming traffic.

Read more about each components architecture and design on the components corresponding GitHub page.

Technologies

In addition to a bunch of Spring Framework subprojects, OpenWMS.org supports popular BPMN workflow engines like Activiti, Flowable and Camunda to take routing decisions on the transport layer. RDBMS access is most often realised with the Jakarta Persistence API. Some components might also use NoSQL databases, like MongoDB. RabbitMQ in combination with the Spring Integration project is used as an event broker for asynchronous event and command propagation. Currently, all microservices are realised as Spring Boot applications designed to run on any modern PaaS cloud platforms, like the Azure Kubernetes Service, AWS EKS or Redhat OpenShift.

Microservices

Due to OpenWMS.org is built on a modern distributed microservice architecture that follows the Twelve-Factor methodology, all functional business components are managed within their own SDLC (Software Development Life Cycle) and own source code repositories.

Service Name Repository Accessibility License
Service Registry org.openwms.services Public Apache-2.0
Configuration Service org.openwms.configuration Public Apache-2.0
Gateway Service org.openwms.gateway Public Apache-2.0
Gateway Service ENTERPRISE org.openwms.gateway Private GPLv3
Auth Service org.openwms.auth Private GPLv3
UAA Service org.openwms.core.uaa Public Apache-2.0
Preference Service org.openwms.core.preferences Public Apache-2.0
Printing Service org.openwms.core.printing Private GPLv3
Translation Service org.openwms.core.lang Private Preview Apache-2.0
Common Service org.openwms.common.service Public Apache-2.0
OSIP/TCP Driver org.openwms.common.comm Public Apache-2.0
OPCUA Driver org.openwms.common.opcua Private Preview Apache-2.0
Transaction Service org.openwms.common.transactions Private Preview Apache-2.0
Common Tasks Service org.openwms.common.tasks Public Apache-2.0
Transportation Service org.openwms.tms.transportation Public Apache-2.0
TMS Routing org.openwms.tms.routing Public Apache-2.0
Receiving Service org.openwms.wms.receiving Public Apache-2.0
Inventory Service org.openwms.wms.inventory Private Preview Apache-2.0
Picking Library org.openwms.wms.picking Private GPLv3
Movements Service org.openwms.wms.movements Public Apache-2.0
WMS Tasks Service org.openwms.wms.tasks Private Preview Apache-2.0
Partner Service org.openwms.wms.partners Private Preview Apache-2.0
Trucks Service org.openwms.wms.trucks Private Preview Apache-2.0
Shipping Service org.openwms.wms.shipping Private Preview Apache-2.0
Putaway Library org.openwms.wms.putaway Private GPLv3
SAP Adapter org.openwms.wms.sap Private GPLv3
Dynamics Adapter org.openwms.wms.msdynamics Private GPLv3
NetSuite Adapter org.openwms.wms.netsuite Private GPLv3
WMS Orchestrator org.openwms.wms.orchestrator Private Preview Apache-2.0

Current state of development

Most components are under active development. In 2016 the whole product has been migrated from the technical structured OSGi architecture towards a business oriented architecture with Spring Boot microservices and Netflix OSS components. Documentation of previously released versions does still exist on SourceForge.net and Atlassian Confluence. All current documentation is maintained in OpenWMS Cloud Wiki.

Previous Architectures

The project started in 2005 with an J2EE server approach based on EJB2.1 with XDoclets, Hibernate and JavaServer Faces (JSF). In more than 15 years we've seen a bunch of technologies addressing all the same problems.

A PoC has been implemented with EJB2.1, but the project actually started with EJB3.0. Since around 2007 OpenWMS.org is based on the Spring Framework and this is still fine, and the right choice. Spring in combination with OSGi seemed to be the perfect match to build a modular and extensible base project. Unfortunately Spring stopped their efforts on OSGi, in particular on Spring dmServer and Spring Dynamic Modules . In a transition step to the current microservice architecture, we put all the OSGi bundles into a fat JavaEE WAR deployment unit to run the application on a servlet container like Apache Tomcat. After that we redesigned all services and business functions and applied a microservice architecture. The standalone WAR deployment is not supported anymore because it was not demanded by the community. Only the microservice architecture is supported right now.