On 8/12/05, Venkat Reddy <[EMAIL PROTECTED]> wrote: > On 8/11/05, Dan Diephouse <[EMAIL PROTECTED]> wrote: > > Personally, I like to be able to change and extend my schemas more than > > once every year or two. Creating a seperate set of DTOs each time poses > > a lot of maintenance costs. As does simply parsing the XML by hand. As > > does transforming inputs and outputs to a new version. Companies like > > EBay and Amazon manage to change their schemas like every month. I > > wonder if they have any unique strategies they've worked out. > > > > I'm not here to comment on the main discussion, but it appears to me > that part of the problem here is the difficulty to work with or > maintain schemas and update the associated java code. With better > graphical tooling support for managing schemas and update the linked > java code, maybe this problem might go away? Would start-from-java > still be attractive then?
if you're writing a pure web service with no interaction with existing code then start-from-schema works very nicely. the sweet spot for start-from-java is for use cases where there the web service is integrated into a large system with extensive reuse. the heart of these systems are typical a load of objects (typically POJOs). it can be difficult to reuse objecs generated from schema. it's therefore usual to employ a translation phase between the generated object model and the object model used by the core system when using start-from-schema. this code needs to be recoded when the schema changes. i'm not sure whether this translation phase could be effectively automated. IMHO one of the missing links in start-from-java is the absence of good graphic tools sets. given a good graphical tool, it would be possible just to alter the mapping between the schema and the object model when using start-from-java when the schema changes. much easier and quicker than start-from-schema. - robert
