[kcbabo]

It's actually the ear-deployment quickstart which shows multiple applications talking use binding.sca - sorry for the confusion.

The order-consumer and order-service applications don't share Java classes via the artifacts module.  In fact, order-consumer doesn't even have Java classes in it.  The Java classes are shared between the web component and the order-service, which is what I was driving at with my comment about demonstrating both approaches.  Putting the classes and WSDLs in a single module was merely a convenience to limit the number of moving parts in the example.

If you have a composite reference with a WSDL interface, use the button bar or right-click on the composite reference and that will give you the option to generate Java from WSDL.

[steve.leach]

Keith Babo wrote:

It's actually the ear-deployment quickstart which shows multiple applications talking use binding.sca - sorry for the confusion.

The order-consumer and order-service applications don't share Java classes via the artifacts module.  In fact, order-consumer doesn't even have Java classes in it.  The Java classes are shared between the web component and the order-service, which is what I was driving at with my comment about demonstrating both approaches.  Putting the classes and WSDLs in a single module was merely a convenience to limit the number of moving parts in the example.

Ahh, that makes sense.

If you have a composite reference with a WSDL interface, use the button bar or right-click on the composite reference and that will give you the option to generate Java from WSDL.

Thank you! That's what I was looking for.

I've pretty much got it now I think; publishing a SOAP service from a Bean component in one composite and referencing it from a Bean component in another composite.

[steve.leach]

Sorry Keith, I'm afraid I'm still struggling with this.

While I didn't make it clear initially, what I'm really interested in is consuming the web service from a Java Bean component, rather than (or as well as) Camel components. Something like the following....

The HelloProvider interface in soap-provider has one method, String greet(String name); and the Consumer interface in soap-consumer has String greet(); so the ConsumerBean just needs to add the name parameter.

I can create this setup, I just can't get it to work. The soap-provider project seems fine, and if I copy/paste the WSDL from soa-provider to soap-consumer then I can create a Reference from it and generate the Java interface from that (in the consumer project).

What I'm needing to do is create the composite reference in soap-consumer (from the copied WSDL) and then click the "generate java interface" button as you mentioned. I then delete the composite reference, and add a component reference to ConsumerBean using the generated Java interface, and then promote that; if I don't delete the composite reference first then it wires the component reference to the composite reference but forgets to add the "promote" attribute which seems to be required.

One specific problem I'm having is that the generated Java interface (HelloProviderPortType in soap-consumer) is dropping the return type for my service operation. The original HelloProvider interface method (in soap-provider) is String greet(String name); and the generated WSDL matches this. However, the Java interface generated in soap-consumer has public void greet(java.lang.String string); instead. No idea why.

I'm sure I'm doing something wrong, but I just can't figure out what. Any ideas?

[kcbabo]

The WSDL->Java and Java->WSDL function uses CXF under the covers, so something is likely going wrong there.  It would help a lot if you could attach your projects so we can try and reproduce the behavior you are seeing.

[steve.leach]

Thanks Keith. I've messed around with the projects over the last few days, trying lots of things to get it working, so I'm going to rebuild from scratch again before I upload.

I figured out that it all uses CXF (JBossWS) under the covers, but the thing is, that part works fine unless it is in a SwitchYard project with a SOAP service reference.

I created a new basic Maven project, and generated a plain JBossWS client stub from my WSDL, which included an auto-generated stand-alone test application (ClientSample) which worked fine.

I then converted the project into a SwitchYard project, created a Bean component with a reference, promoted that reference (selecting the WSDL as the interface) and then ClientSample (which hadn't been modified at all) started failing with a validation error.

[steve.leach]

Keith Babo wrote:

The WSDL->Java and Java->WSDL function uses CXF under the covers, so something is likely going wrong there.  It would help a lot if you could attach your projects so we can try and reproduce the behavior you are seeing.

ZIP file with projects attached. There are two projects, soap-provider2 and soap-consumer2.

Note that this is just one of the configurations I've attempted, but with so many options, the number of permutations is endless. With this one I've gone for unwrapped parameters and results (as each is a simple string), Java transformers and letting the SwitchYard editor UI do the generation of the Java interface from the WSDL. I've also tried various combinations with wrapped parameters, JAXB transformers and generating JBossWS clients directly from the WSDL. Nothing has worked yet.

Note that I can quite happily invoke the soap-provider2 service from SoapUI.

When I run this configuration I get an "UndeclaredThrowableException", whatever that means.

org.switchyard.test.InvocationFaultException

  at org.switchyard.test.Invoker.sendInOut(Invoker.java:313)

  at com.estafet.poc.soap_consumer2.HelloConsumerTest.testTest(HelloConsumerTest.java:24)

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

  at java.lang.reflect.Method.invoke(Method.java:606)

  at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)

  at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)

  at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)

  at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)

  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)

  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)

  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)

  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)

  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)

  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)

  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)

  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)

  at org.junit.runners.ParentRunner.run(ParentRunner.java:300)

  at org.switchyard.test.SwitchYardRunner.run(SwitchYardRunner.java:85)

  at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)

  at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)

  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)

  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)

  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Caused by: org.switchyard.HandlerException: java.lang.reflect.UndeclaredThrowableException

  at org.switchyard.component.bean.ServiceProxyHandler.handle(ServiceProxyHandler.java:197)

  at org.switchyard.component.bean.ServiceProxyHandler.handleMessage(ServiceProxyHandler.java:94)

  at org.switchyard.bus.camel.processors.ProviderProcessor.process(ProviderProcessor.java:29)

  at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)

  at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)

  at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:73)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)

  at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:91)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)

  at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.switchyard.bus.camel.audit.FaultProcessor.process(FaultProcessor.java:46)

  at org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:45)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:303)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)

  at org.apache.camel.processor.Pipeline.process(Pipeline.java:117)

  at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)

  at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:104)

  at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:78)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)

  at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:73)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)

  at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:91)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)

  at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.switchyard.bus.camel.audit.FaultProcessor.process(FaultProcessor.java:46)

  at org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:45)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:303)

  at org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:45)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:122)

  at org.apache.camel.processor.RouteInflightRepositoryProcessor.processNext(RouteInflightRepositoryProcessor.java:48)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)

  at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)

  at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:73)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)

  at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:61)

  at org.apache.camel.processor.UnitOfWorkProcessor.processAsync(UnitOfWorkProcessor.java:150)

  at org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:117)

  at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:99)

  at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:86)

  at org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:63)

  at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:360)

  at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:331)

  at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:227)

  at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:331)

  at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:153)

  at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:106)

  at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:92)

  at org.switchyard.bus.camel.ExchangeDispatcher.dispatch(ExchangeDispatcher.java:87)

  at org.switchyard.bus.camel.CamelExchange.sendInternal(CamelExchange.java:234)

  at org.switchyard.bus.camel.CamelExchange.send(CamelExchange.java:171)

  at org.switchyard.test.Invoker.sendInOut(Invoker.java:308)

  ... 25 more

Caused by: java.lang.reflect.UndeclaredThrowableException

  at com.sun.proxy.$Proxy32.greet(Unknown Source)

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

  at java.lang.reflect.Method.invoke(Method.java:606)

  at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:45)

  at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:105)

  at org.jboss.weld.proxies.HelloProviderPortType$1366014918$Proxy$_$$_WeldClientProxy.greet(HelloProviderPortType$1366014918$Proxy$_$$_WeldClientProxy.java)

  at com.estafet.poc.soap_consumer2.HelloConsumerBean.test(HelloConsumerBean.java:19)

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

  at java.lang.reflect.Method.invoke(Method.java:606)

  at org.switchyard.component.bean.ServiceProxyHandler.handle(ServiceProxyHandler.java:163)

  ... 94 more

Caused by: org.switchyard.component.bean.BeanComponentException: SWITCHYARD030403: Bean Component invocation failure.  Service 'HelloProviderPortType', operation 'greet'.

  at org.switchyard.component.bean.ClientProxyBean$ClientProxyInvocationHandler.invoke(ClientProxyBean.java:315)

  ... 108 more

[kcbabo]

Everything in your project is good except for the transformation logic you added - it's missing the namespace on the <string> operation.  Here's what it should look like:

@Transformer(to = "{urn:com.estafet.poc:soap-provider2:1.0}string")
  public String transformStringToString(String from) {
  return "<string xmlns=\"urn:com.estafet.poc:soap-provider2:1.0\">"
     + from
     + "</string>";
  }

The obscure exception trace is due to the fact that the SOAP binding is returning a SOAP fault (unable to identify operation) and the bean component doesn't know what to do with it.  There are a couple things to keep in mind that are useful when debugging this sort of thing:

1) Enable message tracing (domain tab of editor) when things aren't behaving as expected.  In this case, that would have revealed the SOAP fault coming back from the SOAP endpoint.

2) If an exception is expected which is not defined in the bean reference contract, use ReferenceInvoker in your bean service which provides visibility into the underlying exception.

I think ClientProxyBean could use a tweak to it's logic to attempt conversion of non-Throwable message content into a String and then throw that as an invocation exception.  This would make issues like this (where a SOAP fault is returned) much easier.

[SWITCHYARD-2065] ClientProxyBean obscures fault content - JBoss Issue Tracker

[steve.leach]

Fantastic, that fixed it for me. Thanks Keith.

Now that I've got one configuration working I think I'll create a quick tutorial for it, primarily for internal use by our internal teams. I'd be happy to share that tutorial here if that would be useful. There is enough potential for error in all of this for a step-by-step tutorial to add some real value here I think.

I'm also going to see if I can get other configurations working, including use of JAXB transformers.

Thanks for all your help.

[steve.leach]

I've created an initial version of a tutorial on how to do this at Connecting Java-based SwitchYard Composites with SOAP Web Services (Tutorial)

[kcbabo]

I'm glad this all worked out and thanks very much for taking the time to put together a tutorial on this use case for other users.