On 8/11/05, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > robert burrell donkin wrote: > > >On 8/10/05, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
<snip> > >>I think JiBX is one of the nicest start-from-Java frameworks around, though > >>it's > >>also being extended to better support start-from-schema. > >> > >> > > > >AIUI JiBX is known primarily as a generative start-from-java binder > >(though now i've dug a little, i've found that it also supports > >dynamic binding). i had in mind a dynamic approach which is why i > >suggested xstream. (JiBX and xstream are - in my mind - third > >generation approaches with better architectures more suitable for axis > >2 than the second generation ones.) > > > > > XStream is an XML serialization framework, while JiBX is XML data > binding. I don't know of any formal definition of the difference between > these two types of frameworks, but the way I'd put it is that XML > serialization generally uses formats that are defined by the > serialization framework itself, while data binding allows the user to > define the XML formats. i know xstream describes itself as a serializer but i've been thinking a lot recently about fusion and commonalities between the various kinds of binders. i really think that xstream is a data binder but pretty much at one end of the expressiveness spectrum. (maybe this is why i also know of no good way to formally definite the difference.) users have some control over the xml formats generated by xstream but this is limited in it's expressiveness. users expect start-from-java to guess well. it's easy to guess well for beans and regular bean-like objects but there a lot of common objects which are just odd. after working for a long time on a binder at the other end of the expressiveness spectrum from xstream, i've come to the conclusion that in some ways, good guessing for many common objects is going to require a lot of reasonably fixed mappings provided by the binder. i think that for start-from-java to really progress, we're going to need to see more fusion combining work from different binders with different strengths rather than working on functionality in parrellel. IMHO the problem's just too big... > SOAP encoding is just a particular serialization format, as is JAX-RPC > 1.X doc/lit. If you want to support these formats using reflection you > could use something like XStream as a good base. The drawbacks are > likely to be somewhat poorer performance and limited flexibility (as > seen with Axis 1.X). JiBX would be more useful for people who want > better doc/lit support with a full range of XML structures supported. i've been wondering recently whether these couldn't be done effectively as configuration sets for expressive binders. (take an expressive binder and do all the work required to process easily a particular set of objects.) > >i'm convinced that start-from-java is a small but vital part of the > >web service ecology and think it's unfortunate the advantages of the > >third generation binders are not more widely know. in some ways, i > >think it's a small but crucial cog in the axis2 machine: delivering > >support for poor schemas and quicker prototyping by java-centric > >developers. > > > > > I actually don't see this as a small part of the problem, but as a large > part. i was trying to avoid being too argumentative (which is a little unlike me, i know ;) > AFAIK the vast majority of .NET work is being done as > start-from-C# (or VB... shudder). That's not going to be everything - > over time, the move is clearly toward standard schemas for data > exchange, including web services - but it's a large part of why > developers find web services today so much more difficult in Java than > in .NET. +1 > There are other problems lurking in the wings from the standard schemas > approach, too. Schema versioning is not well handled by any of the > existing frameworks that I'm aware of, though JAXB 2.0 is moving in this > direction. Right now the schema-centric frameworks require you to > generate a new set of classes for each version of the schema you want to > support. I don't think that's a practical solution, given the trend > toward industry-wide schemas being updated every year or two. In a way > this becomes a variation of start-from-Java, even if the Java you're > starting from was generated from version 1.0 of the schema and you just > want to work with version 1.1. +1 > >do you plan to work on the proposed module here or over sourceforge? > > > > > I'm planning to handle this with a JiBX data binding interface that's > part of the Axis2 code (though presumably optional, so that people who > aren't using JiBX don't need it installed). This will need to include > not only runtime support but also client stub generation (which in the > JiBX case will need to generate the binding definition as well as the > actual data classes). I'd think that's what would need to be done for > other data binding frameworks, too. how's JiBX's schema generation? - robert
