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 <[EMAIL PROTECTED]> 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
>> http://www.sosnoski.com - http://www.sosnoski.co.nz
>> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
