Ajith Ranabahu wrote:
The basic steps are as follows
1. Using a codegen extension, generate an unwrapped schema by looking
at the existing schema. At the time of building this schema we can
determine some type mappings but the complex types still need to be
processed through a databinding framework to generate the necessary
classes. Hence the schema we build here will be only a partial schema
which is needed for the inner complex types only. Note that for this
process it does not really matter whether the schema was an artificial
one !
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.
2. Once this secondary schema passes along the databinding frameworks
the necessary code will be generated. At the end of the codegen run the
correct "unwrapped" type mappings will be fully populated.
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). I suppose this would
work okay for the data binding frameworks that just generate code for an
entire schema.
3. Our codegenerator templates are perfectly capable of handling multiple
parameters in method signatures. However the complication comes when one
needs to construct the outgoing (in the client side) or explode the
incoming (in the server side) message using the unwrapped parameters.
This was not a problem at all in the earlier case since there was always
*one* parameter. Since all these items that need wrapping are data
binding framework dependent, my suggestion is to generate a set of new
_toOM_ methods that knows how to concatenate and generate the proper
"wrapped" xml.
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. 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?
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.
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.
- 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]
