Hi,
I have a customer question, and then some comments for the documentation.

-------------------------------
Every camel implementation and (destination) binding, are defined using java interfaces. The source (to) binding share the same interface as camel.
Which means that every switchyard project is going to have at least two interfaces.
 
An interface definition (in java) looks like this;
 
interface <interface-name> {
    <method-qualifier> <return-type> <method-name>(<parametertype parameterName>)
}
Example;
 
Interface I007 {
  public void getWMSInfo(String contents);
}
 
This means that, when we read a file the payload data type is String.
 
In quite a few of our switchyard implementations, we have omitted the <parametertype parameterName> (e.g.,  public void getWMSInfo();) , and although it works I could not found any documentation that says it is ok to not include this.
Just some sanity check that this is indeed ok to do it like this.
-------------------------------

Strictly speaking, input type is optional, although it should always be used if there is an actual input message.  Our contract requirements were relaxed when the REST binding was introduced to allow for GET operations which produced an output with no actual input body.  Whether this was actually required is debatable, but that ship has sailed and so we need to make the best of it.

- If SwitchYard requires an input parameter for Service contracts we need to enforce somehow this. At deployment time could be good. (I'm basing my assumption in that ESB contracts enforces one input param in the IDE)

It is not required, but is strongly recommended in all cases where input content is actually provided.

- If SwitchYard does not require an input parameter for Service Contracts, we need to align the product so that it behaves the same in runtime, deployment and deign (IDE).

Agree.  Sounds like it’s just a matter of updating the tooling based on what the runtime allows.

- If depends on contract type, we need to document.

Same for all.

It would be good to also cover things like:
- One single operation supported
- If services are IN_ONLY or IN_OUT what is expected for the contract
- Contract combinations (Java component -> java contracts, camel components -> java,esb contracts, soap binding -> wsdl/esb/java contract)