To understand the DevKit, you need only understand that Mule applications are made up of flows, and that the components of flows are message processors strung together between endpoints according to the Pipes and Filters design pattern. The message processors all implement the same simple Java interface, and the endpoints implement a similar, but slightly different interface. (For a detailed description of the Mule application architecture, see Mule Application Architecture).
In addition to message processors and endpoints, Mule recognizes another kind of building block called a module. These provide pluggable functionality for specific packages or standards, such as RSS feeds, PGP security, or XML.
Internally, all these building blocks consist of business logic wrapped in Java classes that implement the external interface. In order for this to work, the business logic must have a certain structure and supply certain internal resources.
The DevKit is designed to enable you to provide business logic as a plain old Java object (POJO) with annotations that identify the required internal resources for the type of message processor or endpoint you wish to create. How the DevKit Works provides detailed information about this. The DevKit generates code that complies with certain Mule interfaces, but you do not have to understand those interfaces or the generated code to use the DevKit. You need only understand how to use the annotations that pertain to the kinds of building blocks you create.
Because they interact with entities outside the Mule application, building blocks using the
@Connector annotation (called Cloud Connectors, though they can connect to any entity outside the Mule application) tend to be more complex than other building blocks. Writing Custom Cloud Connectors describes how to use the