There are a couple of issues here. If we look at that example, the wsdl provides the interface for the composite service (/switchyard/composite/service[@name=OrderService]). The composite service manages the bindings for the service described by the wsdl (i.e. how you access those operations). The service is implemented by the "Route" component, which exposes an ESB interface. If you examine the component service on the Route component (/switchyard/composite/component[@name=Route]/service, you'll see that its interface is described using an ESB type (as opposed to wsdl or java). The ESB interface type is a little special in that it can only be used to describe a single operation (i.e. the service has one, unnamed operation with the specified input, output and fault types). There is some special logic in SwitchYard that basically ignores the operation name if the target has only one operation (feature or bug, you decide).
Having said all that, the issue here is that the service interface implemented by the Route component is an ESB interface, which means it only has a single operation. Because of this, when you added an operation to the wsdl describing the external service for the binding, the tooling is marking that as an error, because there is no orderTest or orderrr operation on the component.
The bean-service quickstart should be helpful for illustrating this concept, as the component implementing the service uses a java interface, which makes it a little easier to "see" the operation mapping between the composite service and component service.
The camel-soap-proxy quickstart will give you an example using camel, where the component and service interfaces share the same wsdl interface. One thing to note is that the operation name going out is mapped from the input. (SwitchYard adds a header specifying the operation name. This could be used in your route to behave differently based on which operation the caller is invoking. In this example, it simply passes through to the reference service.)
Hope that helps,
Thanks for your helpful message. It makes me understand more switchyad. Then I associate this esb component with the old jboss esb component. I remember it had the same structure, input, out and fault.
I checked both examples and from the java i checked that if i add an operation on the wsdl then i receive an error. Then the names and number of operations in the wsdl and the java service should be the same.
And I think is a good solution. It is like implementing a java interface, but in this case it is implementing in java a wsdl interface.
About the camel soup, yes i checked that both the composite and component service shared the same interface and i realized in the route that the operationname was included.