Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Mule Sub-Flows, Processing Strategy, and One-Way Endpoints

DZone's Guide to

Mule Sub-Flows, Processing Strategy, and One-Way Endpoints

Interested in learning more about Mule? Read on to get an overview of sub-flows, processing strategy, and one-way endpoints.

· Integration Zone ·
Free Resource

WSO2 is the only open source vendor to be named a leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report. Download the report now or try out our product for free.

Benefits of breaking up flows into separate flows and subflows:

  • Makes the graphical view more intuitive, you don’t want long flows that go off the screen.

  • Makes XML code easier to read.

  • Enables code reuse.

  • Provides separation between an interface and implementation.

  • Makes them easier to test.

Subflows:

  • Subflows are executed exactly as if the processors were still in the calling flow.

  • Always run synchronously in the same thread.

  • Inherit the processing and exception strategies of the flow that triggered its execution.

Image title

Flows:

  • Flows, on the other hand, have much more flexibility in how they are used.

    • They cn have their own processing and exception strategies.

    • They can be synchronous or asynchronous.

  • Flows without message sources are sometimes called private flows.

Image title

Processing Strategy:

  • A flow processing strategy determines how Mule implements message processing for a given flow.

    • Should the message be processed synchronously (on the same thread) or asynchronously (on a different thread)?

      • If asynchronously, what are the properties of the pool of threads used to process the messages?

      • If asynchronously, how will messages wait for their turn to be processed in the second thread?

Flows contain 3 thread pools:

  • Receiving - Message source's threads.

  • Flow processing - Message processor's threads.

  • Dispatching - Outbound endpoint's threads.

Image title

Use of pools depends on a flow's behavior :

Image title

Staged Event Driven Architecture (SEDA):

  • The architecture upon which Mule was built.

  • Decouples receiving, processing, and dispatching phases.

  • Supports higher levels of parallelism in specific stages of processing.

  • Allows for more-specific tuning of areas within a flow's architecture.

What determines a flow’s processing strategy?

  • Mule automatically sets a flow to be Synchronous or queued-asynchronous.

  • A flow is set to synchronous if the message source is request-response.

  • The flow partakes in a transaction.

  • Otherwise, a flow is set to queued-asynchronous. The message source is not expecting a response.

Synchronous flows:

  • When a flow receives a message, all processing, including the processing of the response, is done in the same thread.

  • Uses only the message source's thread pool.

  • The flow's thread pool is elastic and will have one idle thread that is never used.

  • Tuning for higher-throughput happens on the connector receiver's level.

Image title

Queued-asynchronous flows:

  • Decouples and uses all 3 thread pools.

  • Uses queues, whose threads drop messages off for the subsequent pool's thread to pick up.

  • Pools, queues, and behaviors of this strategy are configurable.

  • By default, the flow thread pool has 16 threads.

Image title

Creating flows and subflows:

  • Use flow scope to create a new flow or drag any message processor to the canvas.

  • Use subflow scope to create subflows.

  • Use Flow Reference component to pass messages to other flows or subflows.

  • Flow variables persist through all flows unless the message crosses a transport boundary.

Image title

Setting the flow processing strategy:

  • The flow processing strategy is automatically set.

  • It can be changed in the flow’s properties view.

  • This is usually done when a custom queued-asynchronous profile has been created for tuning application performance.

Image title

Using VM endpoints in flows - The Java Virtual Machine (VM) transport:

  • The Java Virtual Machine (VM) transport can be used for intra-JVM communication between Mule flows.

  • Each app in a Mule instance has its own, unique set of VM endpoints.

  • The VM transport can only handle communications within an app or between apps in the same domain.

  • This transport by default uses in-memory queues but can optionally be configured to use persistent queues.

  • Before Mule 3, the VM transport was needed to pass a message from one flow to another.

  • In Mule 3, Flow Reference was added to let flows directly reference one another without a transport in the middle.

  • VM transport is now mostly used to:

         - Achieve higher levels of parallelism in specific stages of processing.

         - Allow for more-specific tuning of areas within a flow's architecture.

         - Call flows in other applications that are in the same domain.

Image title

IAM is now more than a security project. It’s an enabler for an integration agile enterprise. If you’re currently evaluating an identity solution or exploring IAM, join this webinar.

Topics:
mule 3.8 ,flow ,jvm ,web dev

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}