Chapter 7. SwitchYard Contracts
7.1. SwitchYard Contracts
- Component Service
- Component Reference
- Composite Service
- Composite Reference
- Service Binding
- Reference Binding
7.2. Component Contracts
- Java: Using a Java interface.
- WSDL: Using a port type in a WSDL file.
- ESB: Using a virtual interface definition. (No real file is used).
- argument: If used, this is the message content. It is optional as there can be operations that don’t expect a message (for example, REST GET, Scheduled operations). Used in Exchanges of type IN_ONLY and IN_OUT.
- return type: If used, this is the message content for the response. Used only in Exchanges of type IN_OUT.
- exceptions: If used, this is the message content for the response in case of an Exception. Used in Exchanges of type IN_ONLY and IN_OUT.
A Java contract is defined by a Java Interface.
A WSDL contract is defined by a port type in a WSDL file.
An ESB contract is a virtual contract (no file required) that declares the types of the input, output and exception types.
7.3. Transformations between Contracts
Contract differences are handled in the ServiceHandlers when composing and decomposing the SwitchYard message. Any difference in contracts is handled in the Message composer.
Contract differences are handled by transformers defined in the composite application, which are applied by the ExchangeHandler chain during the execution of the Exchange. The transformers usually map from an origin type to a destination type.
- In the IN phase, from is the argument’s type of the composite service and the to is the type in the component service.
- In the OUT phase, from is the return/exception type of the component service and the to is the return/exception type of the composite service.
- In the IN phase, from is the argument’s type of the component reference and the to is the type in the composite reference.
- In the OUT phase, from is the return/exception type of the composite reference and the to is the return/exception type of the component reference.
Contract differences are handled in the component implementation, and has to be explicitly transformed.
- If a Composite Service does not declare a contract, it uses the contract defined by the promoted Component Service.
- Every Component can have one Service.
- Binding name can be null. In this case, a binding name is automatically generated with "ServiceName+BindingType+i".
- When the input parameter of a service contract is empty, the message does not change, it is in its original form (e.g. java.io.Reader for streaming bindings like http, File,…)