axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <>
Subject Re: [axis2] simple data binder
Date Thu, 11 Aug 2005 17:59:59 GMT
Hi Dennis,

> I agree with you that this stuff should not be in the Axis2 core, though 
> it's certainly useful to many people. Perhaps the best way of handling 
> this is to have the "Axis2 data binding" framework just use the same 
> interface as the other data binding frameworks (XMLBeans, JiBX, etc.) 
> but be bundled with the distribution as a separate jar. That way users 
> who want to use this basic Axis 1.X-style "automatic" binding can do so, 
> but it won't add to the size of the Axis2 jars required for people using 
> other frameworks.

Definitely +1!

FYI: Why am I against it being in the core? One message receiver I'd
like to write is one that takes the incoming message payload, sets that
as the input stream for Xalan and then fires off an XSLT script which
produces some new XML stream .. which then becomes the payload of the
output message. Another scenario: take the incoming XML stream and feed
it into a Coccoon pipeline.

Doing that does not require any data binding whatsoever, of course.

> I don't know how it's even possible to adopt XML "all the way through" 
> while working with software, at least not unless one of the XML-based 
> languages catches on.

Not necessarily: s/object-relational mapping/xml-relational mapping/ and
you got the same deal. 

Of course if you use an XML-friendly language like E4X this all becomes

Anyway, this is philosophy and not relevant to this discussion much.

>  Ultimately developers need to work with the data 
> in XML documents. They can do so using the actual parser output, using a 
> DOM, or using some sort of data binding or XML serialization to convert 
> to and from Java objects.

+1 .. I guess what I'm surmising is that an XML Infoset model (such as
OM) + a good XPath library can do wonders. 

Oh yeah there's that bit about performance .. it certainly may not be
the fastest way to skin a cat but raw perf is not the only criteria for
selecting technologies. Its absolutely important that Axis2 be *the*
fastest performing stack for the normal perf sensitive scenarios, but
that doesn't mean there aren't other scenarios which are not so perf

> I don't think we're in disagreement on this. :-)  I'm hoping that Axis2 
> will be flexible enough to support all the variations of XML handling 
> that developers may want to use. I think that StAX and (optional, only 
> constructed if needed) OM are a good base to build on, and with an 
> interface that allows developers to plug in data binding support as 
> desired the framework should suit everyone's needs.

Absolutely +1!


View raw message