Anne Thomas Manes wrote:
>The impedance mismatch is between the XSD types (hierarchies) and OO
>language types (rich object graphs), regardless of the abilities of
>the current toolkits -- the type systems are fundamentally different.
>I actually think that the major interoperability issues are caused
>from the other direction -- current toolkits aren't very good at
>mapping rich object graphs to hierarchical structures. Many toolkits
>attempt to treat SOAP/WSDL as just another distributed object system
>(similar to CORBA, RMI, and DCOM). The toolkits focus on generating
>XSD definitions from code -- and lots of developers try to expose
>language-specific object types (Java hashmaps, .NET Datasets, etc)
>through their SOAP interfaces. This approach often results in
>If developers start with WSDL descriptions and XSD types and generate
>code from them, the interop issues are definitely lessened. And if the
>toolkit doesn't support a specific XSD construct, the toolkit can
>always resort to DOM.
You are absolutely correct. I call them R3AWs (Retarded 3GL API
Wrappers). The tight binding between WSDL and 3GL API makes some
toolkits very easy to make a POJO into a Web service, but you pay as
soon as the POJO changes.
There needs to be an abstraction, aka service contract (called service
signature in webMethods Integration Server) which keeps the generated
WSDL from actually caring about the implementation. This is more work up
front, but forces one to focus on the question "What should my public
API be?" and "What API do I want to commit to providing SLAs for?",
which is exactly what will happen as we evolve to "WSDL First"
This all does not excuse R3AWs for not having reasonable 3GL mappings
for all the primitive types of XSD. This was to be verified by the
Round5BaseTypes interop test of SoapBuilders.org, which were created
just as WS-I 'replaced' SoapBuilders as the hub of all interop