Hi Robert!
IMHO start-from-java is a better match for these cases. (though in the second, it would probably be replaced later by a generative solution.) so, maybe there'd be some reason why people might want to use a start-from-java binder even if it turns out to be better to directly port the old style stuff. opinions?
1) I don't particularly want to call it "old-style" as that feels wrong. It'll simply be the Axis2 Data Binding Framework (unless there's a better name?). And in fact, it'll need to take the old Axis1 stuff and fix a lot of the inherent problems therein (in particular the way we dealt with arrays of various kinds).
2) Our DBF is going to need to go from schema->Java, and also to go from Java->schema. To generate WSDLs for DBF-bound services (whether RPC or not), we'll need to introspect the Java and generate schemas. It doesn't seem XStream does that. And even if it did we'd still need to take the "data-specific" schemas for the RPC argument objects and wrap them in the schema for the actual RPC method element...
3) I'm a little concerned there will be too much Axis-specific stuff we'll need done in the DBF to successfully use a third-party library without major changes. I'm certainly open to having the discussion though.
--Glen
