JBoss.org Community Documentation

- Prev

## Chapter 15. Integration

## 15.1. Overview

OptaPlanner's input and output data (the planning problem and the best solution) are plain old JavaBeans (POJO's), so integration with other Java technologies is straightforward. For example:

- To read a planning problem from the database (and store the best solution in it), annotate the domain POJO's with JPA annotations.

- To read a planning problem from an XML file (and store the best solution in it), annotate the domain POJO's with XStream or JAXB annotations.

- To expose the Solver as a REST Service that reads the planning problem and responds with the best solution, annotate the domain POJO's with XStream or JAXB annotations and hook the `Solver` in Camel or RESTEasy.

## 15.2. Persistent storage

### 15.2.1. Database: JPA and Hibernate

Enrich the domain POJO's (solution, entities and problem facts) with JPA annotations to store them in a database.

## Note

Do not confuse JPA's `@Entity` annotation with OptaPlanner's `@PlanningEntity` annotation. They can appear both on the same class.

### 15.2.2. XML: XStream

Enrich the domain POJO's (solution, entities and problem facts) with XStream annotations to serialize them to/from XML.

### 15.2.3. XML: JAXB

Enrich the domain POJO's (solution, entities and problem facts) with JAXB annotations to serialize them to/from XML.

## 15.3. SOA and ESB

### 15.3.1. Camel and Karaf

Camel is an enterprise integration framework which includes support for OptaPlanner (starting from Camel 2.13). It can expose OptaPlanner as a REST service, a SOAP service, a JMS service, ...

Read the documentation for the camel-optaplanner component. That component works in Karaf too.

## 15.4. Other environments

### 15.4.1. OSGi

OptaPlanner's jars include OSGi metadata to function properly in an OSGi environment too.

## Note

OptaPlanner does not require OSGi. It works perfectly fine in a normal Java environment too.

### 15.4.2. Android

OptaPlanner does not work out-of-the-box on Android yet, because it is not a complete JVM. For more information and workarounds, see this issue.

## 15.5. Integration with human planners (politics)

A good OptaPlanner implementation beats any good human planner for non-trivial datasets. Many human planners fail to accept this, often because they feel threatened by an automated system.

But despite that, OptaPlanner can benefit from a human planner as supervisor:

- The human planner defines and validates the score function of OptaPlanner.

  - Some examples expose a `*Parametrization` object, which defines the weight for each score constraint. The human planner can then tweak those weights at runtime.

  - When the business changes, the score function often needs to change too. The human planner can notify the developers to add, change or remove score constraints.

- The human planner is always in control of OptaPlanner.

  - As shown in the course scheduling example, the human planner can lock 1 or more planning variables to a specific planning value and make those immovable. Because they are immovable, OptaPlanner does not change them: it optimizes the planning around the enforcements made by the human. If the human planner locks all planning variables, he/she sidelines OptaPlanner completely.

  - In a prototype implementation, the human planner might use this occasionally. But as the implementation matures, it must become obsolete. But do keep the feature alive: as a reassurance for the humans. Or in case that one day the business changes dramatically before the score constraints can be adjusted.

Therefore, it's often a good idea to involve the human planner in your project.

- PrevChapter 14. Repeated planning
- Top of page
- Front page