axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: [axis2] simple data binder
Date Thu, 11 Aug 2005 16:14:27 GMT
Dennis Sosnoski wrote:

> robert burrell donkin wrote:
>
>> On 8/10/05, Dennis Sosnoski <dms@sosnoski.com> wrote:
>>
[snipped for clarity]

>> 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. 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.
>
> 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.
>
I totally agree on the schema-> is very similar to the start from java 
case. In each case you're still using a DTO pattern. What do you see as 
alternatives to this approach?

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.

Anyone on this list have preferred strategies they use to make schema 
change easier?

- Dan

-- 
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com


Mime
View raw message