---
schema_version: "1"
id: bbc2ff4f97ae5a44ee6ea6c47084f992dad685bb4bf6df8b6b843d020e5baee3
title: Creating Message Sources with the Mule SDK
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-sdk/latest/sources.md
canonical_url: https://docs.mulesoft.com/mule-sdk/latest/sources
source_site: docs.mulesoft.com
content_type: documentation
content_hash: e4094cf5a94fb0ff35f93abc642a401329029432bd55b01d4ef69b8b77ec89c6
description: MuleSoft Documentation Site
release: "1.13"
latest: true
---
---
product: Mule SDK
version: 1.13
is-latest-version: true
keywords: mule, sdk, sources, listener, triggers
---

# Creating Message Sources with the Mule SDK

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Operations are components that process a message and generate a result. Message sources are
components that receive or generate new messages to be processed by the Mule Runtime.

Examples of message sources:

- An HTTP listener

- A File watcher

- A JMS/AMQP listener that retrieves messages from a queue to which the user previously subscribed

- Salesforce Streaming API

## Similarities Between an Operation and a Message Source

Operations and message sources have:

- Parameters

- A return type

- Name and Description

- Reconnection capabilities

## Differences Between an Operation and a Message Source

<table><colgroup><col> <col></colgroup><thead><tr><th>Operations</th><th>Message Sources</th></tr></thead><tbody><tr><td><p>Operations process messages.</p></td><td><p>Sources create messages and push them to a flow.</p></td></tr><tr><td><p>The lifecycle of operations is tied to the containing flow.</p></td><td><p>Message sources can be started and stopped independently of the containing flow.</p></td></tr><tr><td><p>Parameters of operations have the option of accepting expressions (the default).</p></td><td><p>Sources have a clear definition of which parameters can accept expressions and which cannot. Only parameters that are part of generating a response can accept expressions.</p></td></tr><tr><td><p>An operation can have a lifecycle, but its parameter values are not available or not needed.</p></td><td><p>A Message source must have <code>start()</code> and <code>stop()</code> phases, and they might require access to the parameter values.</p></td></tr><tr><td><p>A connection is obtained each time the operation is executed.</p></td><td><p>A connection is obtained each time the message source is started or when reconnection happens.</p></td></tr></tbody></table>

## Implementing a Message Source through the Mule SDK

The differences listed above make it difficult to define a way to implement a message source in a
way 100% consistent with the model defined for operations.

Sources are required to extend the `Source` class, which takes two generics: one for the type of the
generated event payload, the other for the type of the Attributes:

```java
@Alias("listener")
@EmitsResponse
public class HttpListener extends Source<InputStream, HttpRequestAttributes> {}
```

> [!TIP] You can use the `@Alias` annotation to force a name. Otherwise, the SDK will infer one.

## Next Step

- [Defining Parameters in a Message Source](https://docs.mulesoft.com/mule-sdk/latest/sources-parameters)
