Learning the Module Model | MuleSoft Documentation
# Learning the Module Model
The entry point for building a Mule module is the `@Extension` annotated class. This class is used to export all the module functionality and all the elements associated with it.
This class **must** be a public, non-abstract class. The `@Extension` annotation cannot be used on interfaces, abstract classes, private/protected classes, or typed classes (with generics).   
---  
```
@Extension(name = "basic")
public class BasicModule {
}
```

When using the `@Extension` annotation, you need to provide a descriptive and concise name for your module. You should not use `extension`, `module`, or `connector` in the module name. If you do, the SDK will trim them. Optionally, you can specify the attribute `vendor` and the attribute `category` (See Licensing).
Once you have created an empty module, you can start adding elements to it.
Figure 1. Basic Module Structure
At a high level, the elements are:
  *     *   * Connection Providers
  *   * 

## Components
Components are the key to the functionality of a module. Given a set of parameters, they can be executed to produce or alter messages in a flow.
Sources and Operations are the most common components in a module:
  * Operations are components that process an incoming message and generate a result.
  * Sources are components that receive or generate new messages to be processed by the Mule Runtime.


## Configuration
Configurations are a set of configurable parameters that affect the behavior of the Module. Sources and Operations typically depend on a Configuration for parameters that determine their behavior. However, some can work on their own without a Configuration.
There is no requirement to declare a Configuration for a Module, but you can declare as many as you need. Different configurations might provide a different set of parameters and specify a set of Operations and Sources that are only available when using that configuration.
## Connection Providers
A Connection Provider is the Module element in charge of handling connections, which are created from a Configuration. They centralize the logic and parameterization to provision and release connections of some specific type.
Like the Configurations, Sources, and Operations, Connection Providers typically depend on a connection in order to be executed. A connection is not required but is common. Connections used by Operations and Sources are provided by the Connection Provider.
Connection Providers are bound to Configurations. Configurations can have none, one, or many Connection Providers that create different types of connections, for example, one `ConnectionProvider` for HTTPS and another for (non-secured) HTTP connections.
## Parameters
`Parameters` are the most granular elements on the module model, and they are used in all these elements: Operations, Sources, Configurations, and Connection Providers.
They represent configurable elements that accept the values for elements to execute, or they hold the configured values.
## Other Elements
A module can have other element types, for example, Routers, Scopes, Functions, or Errors. The ones described here are the core elements that most modules are likely going to have.