Dennis Sosnoski wrote:
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.
I knew JiBX had some of that capability. This may be a bit off topic,
but take this example: at first I'm receiving an xsd:double representing
a price, then I create a complex type which holds both the amount and
the currency units. Can JiBX take my xsd:double, create a new price
class with the default currency unit instead of just passing me a double?
TIBCO did a cool thing which allowed you to map arbitrary classes to
arbitrary schema elements that I saw here (watch the screencast, ~5
minutes in):
http://weblog.infoworld.com/udell/2005/05/25.html
I don't know if others are, but I'd be interested in putting together
some sort of object/schema relationship designer that allowed you to
specify these relationships easily.
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. ;-)
Nice :-). Let me know how that goes.
Cheers,
- Dan
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
