How to support Complex type and call a compex webservice

[jim.ma]

I know this is a old question I discussed with Stefano before. But I think it is necessary to post here to discuss it widely and get more thoughts before we do 1.0 release since we have this good place to have more feedback.

When use Wise to call a webserivce, we usually write the following code to do it :

1 WSDynamicClientFactory factory = WSDynamicClientFactory.getInstance();
2 WSDynamicClient client = factory.getClient(wsdURL.toString());
3 WSMethod method = client.getWSMethod("HelloService", "HelloWorldBeanPort", "echo");
4 Map<String, Object> args = new java.util.HashMap<String, Object>();
5 args.put("arg0", "from-wise-client");
6 InvocationResult result = method.invoke(args, null);

You can notice WISE needs a parameter map before invoke the WSmethod. The parameter map key "arg0" should be same as the annotation WebParamter name value in the generated JAXWS class on fly . The parameter map value should also be an object and its type (Class) is the parameter type in the generated method on fly. It works for the simple case , for example , the web service method is doc-wrapped style and parameter type is simple java type . Because we can get the parameter name and value information from WSDL.

But if the Webservice method is doc-bare or rpc-literal style, you can not get these information directly and visibly from WSDL. There are complex rules defined in JAXWS spec to map WSDL's element to @WebParameter name value and webservice method signature. So it is difficult to tell what I should put in the parameter map (see above code snippet line 5). To better understanding the problem I described, let's took a look at the real world WSDL:
http://queue.amazonaws.com/doc/2008-01-01/QueueService.wsdl
It is difficult to compose this parameter map to call a web service defined in this wsdl. right ?
So far we use Smooks mapper [2] to transform the java object to the jaxws complex type objects to call the web service. But I believe it is also difficult to write the smooks configuration to do the mapping work, also it is difficult to find out the parameter name .

I know the wise tool we plan to create can help us generate the web service invocation code and give more informatoin we needed to create the paramter map. But before we do 1.0 relase, how do we plan to resolve this issue ?

One of the approach I can think is making WISE support jaxws classes generated beforehand instead of jaxws classes generated on fly. The generated jaxws classes can provide these information to write wise code to call a webservice.

Your thoughts and comments ? Thanks.

Jim Ma

[1] http://jcp.org/aboutJava/communityprocess/pfd/jsr224/index.html

[2]http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/samples/quickstarts/webservice_consumer_wise2

[maeste]

"jim.ma" wrote:
I know this is a old question I discussed with Stefano before. But I think it is necessary to post here to discuss it widely and get more thoughts before we do 1.0 release since we have this good place to have more feedback.

+1 on that

So far we use Smooks mapper [2] to transform the java object to the jaxws complex type objects to call the web service. But I believe it is also difficult to write the smooks configuration to do the mapping work, also it is difficult to find out the parameter name .

I know the wise tool we plan to create can help us generate the web service invocation code and give more informatoin we needed to create the paramter map. But before we do 1.0 relase, how do we plan to resolve this issue ?

IMHO we should not solve it in 1.0. All what we can do is to suggest users to generate JAXB object (maybe Wise could have in 1.0 some good utilities to do that) to have a look to them and/or use them to generate in smooks's JBoss IDE tool (AFAIK it's under development).
But IMHO we SHOULD discourage users to direct use JAXB object directly (see below)

One of the approach I can think is making WISE support jaxws classes generated beforehand instead of jaxws classes generated on fly. The generated jaxws classes can provide these information to write wise code to call a webservice.

It wouldn't be hard to do that in Wise, it just need few changes to avoid problems with classloading, but it definitively doable.
But IMHO we SHOULD not do it.
Why? Because I don't want to make Wise the world panacea to call webservice, but I'd like to encourage users to use it for its own real added value that is a zero-code approach in cases you have your own object model and want to keep only it in your codebase. IOW the real added value (mainly in ESB, but not only) of the core is to make possible to don't maintain JAXB object in your code base.
Why a user should use Wise if he have generated and use in its own source code JAXB object? If she is using JAXB object she could use also JAXWS standard client. It's little step more.
As said we will solve this problem (it is a problem, don't misunderstand me) with tools, and we can for the moment suggest users (and maybe support them on this stuff with some command line utility) to generate JAXB object just to have a look to them and generate smooks mappings.
In a real near zero-code approach (mainly but not only in ESB) mapping/transformation are the key added value of Wise which have its place where users would work with their own object model and not JAXB generated ones.
IMHO open source project which loose their focus on their real added value will fail.

Of course Wise have (or will have) some other great added values like WS-* easy support you are working on, or support for scripting language, or (I hope) supporting same APIs to call JAX-WS and JAX-RS (and a lot more we are discussing and we will support in upcoming releases). BTW the support of scripting language like Ruby is another point for which we would push on mapping/transformation centrality, since I'd like to support Wise as pure library, don't asking (J)Ruby users to works with java JAXB objects.

Of course I may be totally wrong. Any comments are welcome.

Thank you very much to have open this discussion with the community!

[asoldano]

"maeste" wrote:
IOW the real added value (mainly in ESB, but not only) of the core is to make possible to don't maintain JAXB object in your code base.
Why a user should use Wise if he have generated and use in its own source code JAXB object? If she is using JAXB object she could use also JAXWS standard client.

I absolutely agree.

"maeste" wrote:
As said we will solve this problem (it is a problem, don't misunderstand me) with tools, and we can for the moment suggest users (and maybe support them on this stuff with some command line utility) to generate JAXB object just to have a look to them and generate smooks mappings.

+1

"maeste" wrote:
Of course Wise have (or will have) some other great added values like WS-* easy support you are working on, or support for scripting language, or (I hope) supporting same APIs to call JAX-WS and JAX-RS (and a lot more we are discussing and we will support in upcoming releases). BTW the support of scripting language like Ruby is another point for which we would push on mapping/transformation centrality, since I'd like to support Wise as pure library, don't asking (J)Ruby users to works with java JAXB objects.

Sure, there're many pretty cool idea... :-)

[jim.ma]

As said we will solve this problem (it is a problem, don't misunderstand me) with tools, and we can for the moment suggest users (and maybe support them on this stuff with some command line utility) to generate JAXB object just to have a look to them and generate smooks mappings.

Well, only generating JAXB objects can not resolve this problem. User also should now that's the parameter name ,then he can know how to name the "beanId" in the smooks configuration file:

<resource-config selector="org.jboss.soa.esb.samples.quickstart.webservice__consumer__wise2.ExternalObject">
 <resource>org.milyn.javabean.BeanPopulator</resource>
 <param name="beanId">complexObject</param>
 <param name="beanClass">it.javalinux.wise.ComplexObject</param>
 <param name="bindings">
 <binding property="integerField" type="Integer" selector="internal number" />
 <binding property="stringField" selector="internal text" />
 <binding property="calendarField" type="XMLGregorianCalendar" selector="date" />
 </param>
 </resource-config>

The parameter name information in above example contains in the generated JAXWS service endpoint interface (SEI) class. User CAN NOT get it just from JAXB object. So until all the JAXWS classes are generated, user still do not know how to write smooks configuration.

Of course Wise have (or will have) some other great added values like WS-* easy support you are working on, or support for scripting language, or (I hope) supporting same APIs to call JAX-WS and JAX-RS (and a lot more we are discussing and we will support in upcoming releases). BTW the support of scripting language like Ruby is another point for which we would push on mapping/transformation centrality, since I'd like to support Wise as pure library, don't asking (J)Ruby users to works with java JAXB objects.

Yes,that's the add value we provided for user. But it would be better if WISE 1.0 can call a complex web service easily.

[maeste]

"jim.ma" wrote:

As said we will solve this problem (it is a problem, don't misunderstand me) with tools, and we can for the moment suggest users (and maybe support them on this stuff with some command line utility) to generate JAXB object just to have a look to them and generate smooks mappings.

Well, only generating JAXB objects can not resolve this problem. User also should now that's the parameter name ,then he can know how to name the "beanId" in the smooks configuration file:
The parameter name information in above example contains in the generated JAXWS service endpoint interface (SEI) class. User CAN NOT get it just from JAXB object. So until all the JAXWS classes are generated, user still do not know how to write smooks configuration.

Yep sure. It's what I meant: users should generate (for complex wsdls) JAXB and SEI objects to help them to compile smooks config. Then they doen't need to maintain these object in their codebase.
Have you in mind some different ideas for 1.0?

BTW the use of current Wise webgui (the one from javalinuxlabs.org) could help a lot to get name and type to use, even if it isn't designed to generate automatically code/config it could help a lot in most cases.