# Deployment & Execution Models

ONEWEB **Microflow Designer** supports multiple execution and deployment approaches, allowing Microflow logic to be consumed and operated in different architectural contexts.\
The choice of deployment model depends on how integration logic is expected to be executed, reused, and scaled within the overall system architecture.

Currently, ONEWEB Microflow supports **two deployment models**:

* **Embedded Microflow**
* **Runtime Microflow Server**

Each model serves distinct integration and operational requirements.

***

### Embedded Microflow

**Embedded Microflow** allows a Microflow to be packaged as a **Java JAR library** and embedded directly into an existing Java application.\
In this model, the Microflow executes **in‑process**, running inside the host application’s JVM, and behaves like a shared internal service or utility component.

#### Execution Concept

With Embedded Microflow:

* The Microflow is designed using **Microflow Designer**
* The Microflow is exported as a **JAR file**
* The JAR is imported into an existing Java application
* The Microflow is executed via **Microflow Java APIs**

No network communication or external service runtime is required. Execution occurs entirely within the hosting application.

#### Suitable Use Cases

Embedded Microflow is appropriate when:

* Integration logic must be **tightly coupled** with an existing Java system
* The deployment environment **does not allow standalone services**
* **Low‑latency, in‑process execution** is required
* REST or service exposure is **not required**

Typical usage scenarios include:

* Extending legacy Java applications
* Custom batch or scheduled jobs
* Embedded integration utilities
* On‑premise systems with strict runtime constraints

***

### Runtime Microflow Server

**Runtime Microflow Server** enables Microflows to be deployed and executed as **standalone runtime services**.\
In this model, Microflows behave as independent service components and are accessible over the network.

#### Execution Concept

With Runtime Microflow Server:

* The Microflow Runtime Server is installed and started independently
* Microflows are deployed to the runtime environment
* Each Microflow is exposed as a **service endpoint**
* External systems or applications invoke Microflows using **REST APIs**

This execution model aligns with **service‑oriented and microservices architectures**.

#### Suitable Use Cases

Runtime Microflow Server is appropriate when:

* Microflow logic must be **shared across multiple applications**
* Integration logic needs to **scale independently**
* REST‑based or API‑driven integration is required
* Loose coupling between systems is a priority

Typical usage scenarios include:

* Backend APIs for web or mobile applications
* System‑to‑system integration services
* Enterprise integration layers
* Cloud‑hosted service architectures

***

### Comparison of Deployment Models

| Aspect            | Embedded Microflow    | Runtime Microflow Server |
| ----------------- | --------------------- | ------------------------ |
| Execution Mode    | In‑process (JVM)      | Remote service           |
| Deployment Form   | Java JAR              | Runtime service          |
| Invocation        | Java API              | REST API                 |
| Coupling          | Tight                 | Loose                    |
| Scalability       | Tied to host app      | Independent              |
| Architectural Fit | Monolithic / embedded | SOA / Microservices      |

***

### Choosing the Appropriate Model

When designing Microflows, consider the following guidelines:

Use **Embedded Microflow** when:

* Logic must execute inside an existing Java system
* Deployment simplicity is critical
* Service exposure is unnecessary
* Performance requires in‑process execution

Use **Runtime Microflow Server** when:

* Logic must be reused across applications
* REST‑based integration is required
* Independent scalability is important
* The architecture emphasizes loose coupling

Selecting the appropriate execution model ensures both **operational efficiency** and **architectural clarity**.

***

### Summary

ONEWEB Microflow Designer supports **two flexible execution models** that allow the same Microflow design to be deployed in different ways depending on system requirements:

* **Embedded Microflow** – optimized for in‑process Java integration
* **Runtime Microflow Server** – optimized for service‑oriented and API‑based integration

By supporting both models, Microflow Designer enables Microflows to function as a **versatile backend logic component**, adaptable to a wide range of enterprise architectures.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.onewebstack.com/oneweb-platform-th/designer-reference/microflow-designer/deployment-and-execution-models.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.