Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (4.8)
  3. Mule 4 for Mule 3 Users
  4. Mule 4

  5. Connectors

Introduction to Mule 4: Connectors

Mule 3 offered two ways of connecting to systems: transports and connectors. Transports used the concept of inbound and outbound endpoints to send data. Connectors used the concept of operations to invoke systems, for example, <http:request> or <db:select>.

In Mule 3, MuleSoft started to replace some of these transports through the new HTTP and Database connectors. Mule 4 completes this change by completely standardizing the approach so that all connectivity is built as connectors. This change improves the consistency and usability of connectors, and it enables more powerful connectors.

Independent Release Cycles for Core Connectors and Modules

Another big difference is how the connectors are shipped and released. In Mule 3, a number of connectors/transports were part of the Mule Runtime distribution (for example, File, Ftp, Sftp, HTTP, Database, JMS, XML, Validations, and so on). To get fixes and enhancements to any of these connectors, it was necessary to wait for the next Mule Runtime release. Meanwhile, other connectors (typically the SaaS connectors) were shipped and released independently (for example, Salesforce, Workday, ServiceNow, SAP, and so on).

Mule 4 standardizes the latest model. The Mule 4 distribution ships with no connectors or modules. Instead, each application includes the modules it needs. This approach has the following advantages:

  • Faster innovation in core modules/connectors because all connectors have their own release cycle. New features and bug fixes can become available without the need to wait for the next Mule Runtime release.

  • Ability for different apps to use different versions of the same module. This allows for easier adoption of new releases without the need to run a full regression on applications that don’t require the upgrade.

  • Consistent approach.