Dan Diephouse wrote:
Dennis Sosnoski wrote:
...
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?
The only alternative I know of is some form of mapped binding, where you
use a binding definition to establish the relationships between your
Java classes and XML. In the case of JiBX you can use multiple binding
definitions with the same Java classes, so you're able to reuse your
existing classes for different schema versions. That doesn't mean the
classes don't have to change at all - you'd still need to add fields or
new classes for new components from the schema - but you should be able
to continue using the modified classes with different versions of the
schema, selecting at runtime which binding to use for a particular input
document.
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 actually teaching a web services class for some Amazon personnel
right now - I'll have to ask if they can tell me what they're actually
doing on the backend web service implementation. I haven't followed
their schema evolution in detail, but I think they're trying to minimize
update problems for developers between versions of the schema. The
downside of this is that they're stuck with a horribly cluttered and
ugly schema for their web service support, but cleaning it up would
thoroughly break every piece of code that uses their web service. The
current class assignment is using Axis to build a client for their own
web service, so maybe that'll add some impetus for change within the
company. ;-)
- Dennis
