[Axis2] Extending databinding code generation

[Dennis Sosnoski <dm...@sosnoski.com>]

I've been looking into implementing unwrapping of method call parameters 
for JiBX. The current code generation approach uses several different 
XSLT templates, with some templates just generating generic code for 
handling the service operations while the details of conversions to and 
from XML are handled by toOm()/toEnvelope() and fromOm() that are 
specific to the data binding approach being used. For unwrapped handling 
I think we need to change the code generation to use an in-line 
approach, where the data binding framework is invoked to generate code 
that gets embedded directly within the operation method on the client 
stub, or within the invokeBusinessLogic method of the message receiver 
on the server. The reason I'm suggesting this is because the current 
approach of calling other methods gets very messy when you're passing or 
returning a list of objects, rather than just a single object.

I don't know how well this will fit with the current 
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter. 
At a minimum, it's going to need to pass additional information in the 
XML documents used to drive the code generation (since each data binding 
framework will have it's own approach to handle unwrapping, and will 
need to pass the appropriate information to its code generation 
template). I can just start extending the current code to support 
unwrapped with JiBX, but figured I'd bring it up for discussion first to 
see if anyone else is working in this area.

To enable unwrapping I assume we'll want a WSDL2Java flag, as in Axis1. 
Each framework would be able to check this flag and then set 
per-operation flags to control the code generation, selecting between 
the current form (toOm()/toEnvelope() and fromOm()) and an unwrapped 
approach. The AxisServiceBasedMultiLanguageEmitter would then use this 
per-operation flag to control how that operation is generated.

  - Dennis

-- 
Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117

Re: [Axis2] Extending databinding code generation

[Dennis Sosnoski <dm...@sosnoski.com>]

After looking at this in more detail my inclination is to extend the 
existing TypeMapping schema used by the code generation so that it can 
carry information for the data binding frameworks. Right now the type 
mapping goes from an element qname (which I believe is always the 
element referenced by a message part) to a Java class name. That's fine 
for plain doc/lit, but for wrapped we need better granularity. Just as 
one example, the same element name can be used for different purposes 
and even different types of values within different wrapped operations. 
That means context information is needed, so that the data binding 
framework knows when it's generating code for a foo(user, password) call 
as opposed to a bar(user, amount, items) call.

My thought is to allow the value of a type mapping to be either the Java 
class name String, as now, or an org.w3c.dom.Element. If the Element 
value is seen, the code generation will know that the data binding 
framework wants to handle this message part directly, and will include 
the Element in the XML document passed to the XSLT, which in turn will 
invoke the data binding XSLT for the details of the handling. It'll be 
the responsibility of the data binding framework to generate code that 
constructs the argument list for the service method call in the message 
receiver, and that constructs the document from the arguments in the 
client stub.

Any comments?

  - Dennis

Dennis Sosnoski wrote:

> I've been looking into implementing unwrapping of method call 
> parameters for JiBX. The current code generation approach uses several 
> different XSLT templates, with some templates just generating generic 
> code for handling the service operations while the details of 
> conversions to and from XML are handled by toOm()/toEnvelope() and 
> fromOm() that are specific to the data binding approach being used. 
> For unwrapped handling I think we need to change the code generation 
> to use an in-line approach, where the data binding framework is 
> invoked to generate code that gets embedded directly within the 
> operation method on the client stub, or within the invokeBusinessLogic 
> method of the message receiver on the server. The reason I'm 
> suggesting this is because the current approach of calling other 
> methods gets very messy when you're passing or returning a list of 
> objects, rather than just a single object.
>
> I don't know how well this will fit with the current 
> org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter. 
> At a minimum, it's going to need to pass additional information in the 
> XML documents used to drive the code generation (since each data 
> binding framework will have it's own approach to handle unwrapping, 
> and will need to pass the appropriate information to its code 
> generation template). I can just start extending the current code to 
> support unwrapped with JiBX, but figured I'd bring it up for 
> discussion first to see if anyone else is working in this area.
>
> To enable unwrapping I assume we'll want a WSDL2Java flag, as in 
> Axis1. Each framework would be able to check this flag and then set 
> per-operation flags to control the code generation, selecting between 
> the current form (toOm()/toEnvelope() and fromOm()) and an unwrapped 
> approach. The AxisServiceBasedMultiLanguageEmitter would then use this 
> per-operation flag to control how that operation is generated.
>
>  - Dennis
>