When you take a look at the examples that come with the latest Mule 3 milestone release, you’ll notice that endpoints have an exchange-pattern attribute now:
This attribute replaces the synchronous attribute we used before. Why did we change the configuration? The old synchronous attribute was purely a two-way state: it was either true or false. With the exchange-pattern attribute on endpoints we’re free to allow additional values in the future. Also, the term exchange pattern is more accurate than the old synchronous flag. When you define the exchange pattern “request-response” on an inbound endpoint, it’s clear that you are expecting a response.
Exchange patterns are a commonly known concept in the integration space so it felt a natrual fit to add this configuration attribute on endpoints. Right now we only support one-way and request-response with one-way being roughly the same as synchronous=false before and request-response being roughly the same as synchronous=true before.
Under the covers, all transports specify their supported exchange patterns for inbound and for outbound and the default exchange pattern that’s used when none is configured on an endpoint. This information is stored in the transport’s service descriptor. This allows stricter checks for invalid configurations now: Some transports support outbound endpoints only (e.g. SMTP) and some transports support inbound endpoints only (e.g. IMAP). Mule will fail fast upon startup now if you configure (global) endpoints with unsupported exchange patterns now.
All transports’ schemas were updated to allow configuring only the supported exchange patterns. If only one exchange pattern is supported by a transport, the exchange-pattern attribute won’t even be available. This approach will help a lot avoiding configuration mistakes.
