Soap/Cxf contract with multiple operations y4+09

[virchete]

Hi,

I started working in the Switchyard project and I tried to check a problem that, in my experience had the previous tool jboss esb.

I created the integration layer in my previous company using jboss esb. The main problem we found was the following:

1. They have a team of architects that create an independent WSDL that contains multiple operations.
2. Then the developers implement the Web service using the appropiate technology, in our case Jboss esb.
3. The problem reached was the impossibility to map from Jboss ESB that this operation of the WSDL is map to this binding/jboss esb service.
4. At the end the solution found was to create independent Web services and call jboss esb using http binding.

Now I tried to check if this problem is solved in Switchyard.

1. Went to the camel-cxf quickstart
2. Change the wsdl to have another operation, instead of order i wrote orderTest
3. After executing the example everything was working as before, so I understand the operation name is not relevant.

I did another test. I added another operation to the wsdl, so there are 2 operations. This is the case of my previous job, where there were many operations. I received 2 errors in the switchyard panel:

Unbound operation: can not resolve operation "orderTest" on target.

Unbound operation: can not resolve operation "orderrrr" on target.

I tried to map the operation to the component service, but i did not find the way.

I am not sure if this functionality is covered in switchyard. I am trying to understand better the product and give possible suggestions.

In the case of my previous company, at the end they found that this functionality was covered with Mule and they are switching to it, unfortunately for us.

[rcernich]

Hey David,

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,

Rob

[virchete]

Hi Rob,

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.

Thanks