Venkat Reddy wrote:
hi Dennis,
Good to know you will focus on data-binding area. I and couple of guys
here have explored JAXB 2.0 for writing an extension for Axis2, and
saw a few issues:
- as you mentioned already, JAXB doesn't provide a "pull-based" API to
iterate over the XML types and generate java binding for each, like we
do in XMLbeans.
This part doesn't look like too much of a problem, since it should be
easy to use an XMLStreamWriter interface instead. For the XMLBeans case,
I haven't looked but I imagine somebody has written a XMLStreamReader to
XMLStreamWriter copy method which can be used to effectively convert it
over to a compatible interface. That way the XMLBeans responses should
be able to stay virtual, rather than having to be converted over to OM
form before they're written.
- The current design of Axis data-binding design requires a type
mapper to be populated. This is easy while using XMLBeans, but turns
out to be quite difficult with JAXB.
I was looking for an example of this, but didn't find anything yet. The
trivial EchoString example doesn't appear to use a type mapper. Is there
a better example for XMLBeans support around somewhere?
I'd think a type mapper is only required when you're implementing
wrapped support. For general doc/lit you should be able to turn the
entire body of the SOAP request over to the data binding framework and
have it return an object. Am I missing something here?
- After running the binding compiler, there is no way to get a map or
collection of all XML types and corresponding java types. It seems we
need to write an vendor-specific plug-in for the JAXB binding compiler
for retaining and storing such information for later use. This is the
case with current Sun's JAXB RI.
I don't know that it'd be possible to provide wrapped support using
JAXB. I had to make a number of enhancements to JiBX to support this.
Here again, I'm assuming you mean this in the wrapped context.
- Lastly, Axis2 relies on data-binding during code-generation time,
and not during run-time. This means that the client programming model
is a bit restricted to using static stubs, rather than DII or dynamic
proxies.
I don't really see this as a limitation. If you truly want to do dynamic
web services I don't see any way you can effectively use data binding,
since the whole point of data binding is converting to and from Java
classes - if you don't know the XML structures in advance, there's no
way to define the Java classes either.
just throwing some of my observations.
Thanks, let me know whether I'm misinterpreting things in my responses.
- Dennis
