In some ways the developers have to take responsibility here as well.
Why is it that when one is learning C# or Java that it is expected that
you will take the time to come up to speed on the language and the base
class libraries associated with the platform, but when learning about
web services have the expectation you don't have to pick up the skills
to work with angle brackets (XML, XQuery, XPath, XSLT etc.) but can
continue to live in the language world?
The impedance mismatch between Objects and XSD is real, just as the
issue of vendors implementing the support of XSD on an inconsistent
basis. As someone who spent a significant amount of my time trying to
document what XSD structures caused problems and how best to design
schemas such that the Object to XSD mapping would have a hope of
interoperating across vendor stacks, it is not fun at all.
I've also learned that it is a losing battle that I am no longer
interested in participating in. The lesson for me was that if I wish to
truly play in the web services world, I have to to come up to speed on
XML technologies so that I can directly interact with the messages on
the wire as XML with all the rather powerful XML based tech like XPath
and XQuery rather than expecting an O/X framework to do the job for me.
What I would like to see is more vendor toolkits supporting the ability
to work in this manner. But support does not mean that I need it
abstracted away or "Objectified", but that I simply would like more
visibility into and the ability to work with the messages on the wire as
XML. And that in turn requires that developers make that a requirement
and hold vendor's feet to the fire on this, but with the exception of a
minority, I don't see that happening. I don't remember who said this (I
believe it was either Paul Fremantle or Sanjiva) about how when they
were architecting Axis2 they were originally looking only at this
approach, but the existing Axis community basically was firmly
entrenched in the OO world, so they had to add that support back in (I
am paraphrasing heavily here.. But Paul and/or Sanjiva can correct if I
got that wrong).
Regards,
- Anil
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Anne Thomas Manes
Sent: Saturday, June 09, 2007 9:46 AM
To: [email protected]
Subject: Re: [service-orientated-architecture] Is the problem
simply WSDL and XSD?
I think the major issue at hand is that organizations expect
developers to write schemas. Schemas should be developed by data experts
who understand data modeling, and understand XSD and namespaces.
Organizations should define standard corporate schemas, and developers
should be advised to use the corporate standards. They should also be
advised not to generate schemas from their application code.
Think about it -- how many developers are responsible for
defining database schemas? If you left it to developers, they would
generate database schemas from their code using O/R mapping tools.
If you expect people to share services -- or to enable composite
service development-- you have to start at the data type level. You must
have standard corporate data types that represent, e.g., "customer" in
customer service applications.
Most WS-* frameworks provide tools that generate code from WSDL
(e.g., wsdl.exe and wsdl2java). There are also plenty of O/X binding
frameworks in the Java world ( e.g., JAXB, XMLBeans, JiBX, Castor).
These tools can isolate the developer from having to deal directly with
XML. There is an impedance mismatch between XSD and objects, but as long
as you recognize it and deal with it, it's no worse than the impedance
mismatch between object and relational. The problem is that developers
don't want to deal with the impedance mismatch -- they assume that SOAP
is just like RMI, and they get annoyed when it doesn't work seamlessly.
They just need a little education.
The bigger challenge is mapping method-oriented objects to
RESTful resources. Todd suggested a tool that maps a collection to a set
of resources, but I don't think it's quite that simple. Most objects
expose object-specific interfaces. If they only expose getters and
setters, then it's fairly trivial to do automatic mappings. But how do
you automatically map object-specific methods to GET, PUT, POST, and
DELETE?
Anne
