axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject [Axis2] Implementing unwrapped (was Re: [Axis2] Planning for Axis2 next rev - 1.1 (?))
Date Tue, 13 Jun 2006 09:18:53 GMT
I've been doing some more work on the JiBX version of this, mainly 
working on the message receiver side. One approach that would let us 
keep the current method-based code generation for the data binding 
templates is to just have the invokeBusinessLogic() method generated by 
the message receiver template call a method based on the operation name 
to handle the actual business logic call. We could add a per-operation 
flag for the data binding extension to indicate whether it wants to 
handle the operation in this manner, as opposed to the current approach.

So if the flag isn't set, the current approach is used, with toOM and 
fromOM methods generated by the data binding. If the flag is set, the 
data binding would need to instead generate invokeAddOperation, 
invokeSubtraceOperation, etc. The latter methods would take an OMElement 
as a parameter and return another, handling the whole conversion directly.

The flag for using this unwrapped handling would need to be set by the 
data binding extension code for each operation it wanted to handle, and 
it would need to pass information to be included in the XML document 
generated as input to the message receiver template. I've been passing 
information in my code using the pre-existing trick of storing an 
element in the type mapping, rather than a String class name, but this 
is somewhat limited. It'd be better to have a cleaner way of passing 
information for the XML document, including the flags for which 
operations should be unwrapped.

If some of the data binding frameworks want to just simplify the schema 
for code generation, and use custom conversions only for complex 
structures, it'd be easy enough to have common code support code for 
this in a utility class. It'd also be easy to include any common 
transformation templates in the basic MessageReceiverTemplate.xsl, where 
they can be invoked by name from the data binding framework-specific 
template. That way the frameworks that just want the basic handling 
don't have much added complexity.

How does this sound to you, Ajith?

  - Dennis

Ajith Ranabahu wrote:
> Hi Dennis,
> Please see my answers inline
>> It's not just a matter of unwrapping the schema definitions of the
>> wrapper elements - it's also necessary to relate the types of the
>> unwrapped components to the actual element name *in the context* of the
>> original wrapper. This is important, because the same type can be used
>> with different element names within different wrappers (or even within
>> the same wrapper). I don't really see how this can be handled by a
>> schema transformation, especially not in a way that's compatible with
>> different data binding frameworks.
>> >
> Hmm... I was thinking of the Axis* hierarchy for this. Axis* hierarchy
> is the AxisService,AxisOperation, AxisMessage etc  and this is what is
> used as the object model for the WSDL when generating code. By hanging
> the bits and pieces of the generated schema there we can avoid any
> confusions among the private element names.
>> I don't know how, since the databinding frameworks use the wsdl message
>> references to determine what needs to be handled (at least, JiBX does -
>> I haven't looked at the other frameworks recently).
> We change the logic so that if a particular flag is present in the
> config (say unwrap parameters) we look in the Axis* hierarchy property
> bags instead of the message rererence  ?
>> I suppose this would
>> work okay for the data binding frameworks that just generate code for an
>> entire schema.
>> >
>> It would be possible to handle it in this way, but it creates a number
>> of problems. First off, the component elements of a wrapper may be
>> optional (minOccurs="0") and/or nillable.
> Have to think about this, But if unwrapped, one will have to cater for
> these anyway!
>>> The code generated within the
>> mainline method body would need to be smart enough to handle these
>> cases, which creates a problem on the output side since optional may be
>> defined by the framework (for example, by a default value in the schema
>> definition which needs to be compared with a value supplied at runtime
>> using a specific conversion). Secondly, the same types may be used with
>> different element names in different places. That means that the _toOM_
>> and _fromOM_ methods would need to be based on the type, while the
>> inline code would need to do the element handling. That's basically what
>> I've been doing in the JiBX unwrapped support, except there I just go
>> ahead with the actual conversion, too.
>> But for data binding frameworks you generally need to create some sort
>> of context for the marshalling/unmarshalling, and doing things in this
>> way you'd be creating a separate context for each individual parameter.
>> That seems very inefficient. If you're already handling the element
>> processing inline (pretty much necessary for the reasons given above)
>> you may as well just go ahead and handle the conversions inline rather
>> than using separate _toOM_ and _fromOM_ methods.
>> >
>> > The next question is how should this information be kept in the Axis*
>> > hierarchy.
>> > When we go for WSDL 2.0 we won't have this problem since WSDL 2.0 by
>> > nature does not allow for multipart messages (actually there is no
>> > message concept at all) so changing the
>> > Axis* hierarchy to cater for WSDL 1.1 may not be the most futuristic
>> > design. My guess is extra information needed for WSDL 1.1 is better
>> > attached as properties. Our emitters can search for the specific
>> > properties and do the needful.
>> I don't understand the references here. Can you explain this in more 
>> detail?
> I was actually talking about the Axis *  hierarchy I mentioned earlier..
>> > Also the 3rd step can be slightly improved with the expense of a 
>> few more
>> > classes. We can generate the Original wrapped class by looking at 
>> the un
>> > modified schema and use that wrapper to generate the XML. Since the
>> > classes to represent the fields are already generated we can utilize
>> > them to populate the wrapped object. Still this needs to be 
>> databinding
>> > specific!
>> Minimizing the number of generated classes is the main point of
>> unwrapped handling in the first place, so generating still more classes
>> to handle this is probably not going to be a popular implementation
>> approach. This also wouldn't work for JiBX, which is generally going to
>> be working with existing classes rather than generating new ones from
>> the schema.
> Ok . . So that seems a tricky path to go on :)
>> In the case of JiBX unwrapped handling for the MessageReceiverInOut,
>> I've replaced the calls to _toOM_ and _fromOM_ methods with code
>> generated in-line by the data binding extension template. This code
>> handles the actual conversion of values using predetermined parameter
>> variable names (_1, _2, etc.). The main MessageReceiverTemplate then
>> generates the call to the service method using these parameter names,
>> and invokes the data binding template again for handling the return
>> value (if any). This is somewhat messy in terms of the code generation
>> (especially since it's done using XSLT), but avoids the problems with
>> simpler approaches.
> So basically what you mean is to handle unwrap at the databinding
> level without trying a generic solution ?
>>   - Dennis
>> >
>> > On 6/12/06, Dennis Sosnoski <> wrote:
>> >> Sounds good to me. I've spent a few days working on unwrapping 
>> support
>> >> for JiBX, but found the XSLT code generation approach made it very
>> >> painful. I'll try to get it wrapped up (ha, ha) this week.
>> >>
>> >> What time frame are you thinking of for the release? I'd prefer to 
>> see a
>> >> couple of weeks of testing of at least one beta before the actual
>> >> release, so my hope would be to get all new features in by the end of
>> >> June and then only do bug fixes until a 1.1 release in mid-July.
>> >>
>> >>   - Dennis
>> >>
>> >> Dennis M. Sosnoski
>> >> SOA, Web Services, and XML
>> >> Training and Consulting
>> >> -
>> >> Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
>> >>
>> >>
>> >>
>> >> Davanum Srinivas wrote:
>> >> > Team,
>> >> >
>> >> > There have been some queries on the user list on our next 
>> steps...What
>> >> > do you all think about what should get into the next rev and 
>> when we
>> >> > could possibly cut it?
>> >> >
>> >> > My 2 cents, I'd like to see two hot button issues addressed:
>> >> > #1: unwrapping support in codegen
>> >> > #2: make ADB databinding use OMDataSource, so that there is an 
>> option
>> >> > to write directly to stream (right now we always pull events).
>> >> >
>> >> > Your thoughts please.
>> >> >
>> >> > thanks,
>> >> > dims
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail:
>> >> For additional commands, e-mail:
>> >>
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message