Dennis Sosnoski wrote:
robert burrell donkin wrote:
On 8/10/05, Dennis Sosnoski <[EMAIL PROTECTED]> 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
