Posted by jdcmember
on April 7, 2005 at 4:15 PM PDT
XML Schema is THE type system of web services. Learn it, use it, live it; and stop hiding behind Java->WSDL tools.
XML Schema is THE type system of web services. Learn it, use it, live it; don't hide behind Java->WSDL tools. More to the point: JAX-RPC Java->WSDL mechanical translation tools should never be used.
Java-to-WSDL is a stunningly poor choice when you want to exchange data with another organization through web services. Think about it: you're going to translate a Java interface in to the XML Schema type system, and then hand the resultant WSDL to someone else to translate back in to some other language. Think that's really a good idea? Take a look at the next paragraph, which is the text of this paragraph run through a mechanical translator in to, oh, Portugeuse and then back in to English:
The Java-> WSDL is a choice stun poor man when want to change facts with another organization. Think about him: will translate an interface of Java in the the system of kind of Schema of XML, and then passes the WSDL resultant to another one person translate back in the some another one language. Think that that is really a good idea? Of a look in the near paragraph, that is the text of this run of paragraph by a mechanical translating in the, oh, Portugeuse and then back in the English one:
Java->WSDL->Some other language translation will do the same number on your interface's parameter and return types. DON'T DO IT.
Here's some pathologies you will experience if you insist on designing web service definitions in Java first:
1) Strange translations of maps and other collection types. JAX-RPC does not define a standard mapping for Collection types.
2) Surprising translations of your custom atomic data types, like MyDate or MyEntityIDNumber.
2) Domain object artifacts in your WSDL, such as representations of Bean properties that encode non-persistent state of your domain objects.
3) Unexpected translations of your class hierarchies.
4) Modifications to your Java service classes' public interfaces ripple through the WSDL like a bad smell in a closed elevator. Give up all hope of backwards compatibility -- you have no idea how the change in the source Java will translate in to WSDL.
When you start feeling the pain of these first-tier problems, you will be tempted to either:
a) Write custom XML (de-)serializers; or
b) Actually modify your domain classes so that their XML translation will look more palatable
You are like an alcoholic alleviating your cravings by smoking crack now. Wasn't Java->WSDL translation supposed to be saving you time and effort? Don't you think learning some custom serialization and configuration mechanism is just burning good brain cells after bad?
The Design by Contract principle has an unwritten correlary, which I'm going to write down here: In Design by Contract, the contract must be expressed in a language devoid of either client or service implementation artifacts.
When both the client and the service implementation are in the same language then you can use that common language, no problem. Java RMI uses Java interfaces, for example. (RMI/JRMP that is.)
But once the client and service implementation are to be implemented in different languages, you must use a neutral interface definition language. COM has (had) IDL, CORBA has its own IDL, and SNMP uses its own definition language. Adopters of each of these technologies learned, though expensive failure, that you've got to speak the interlingua to be heard clearly. Double translation won't do.
Maybe you've never seen a VB programmer designing a COM component in VB. Trust me, that programmer is either a genius on a solo mission, or (much more likely) a naive soul lulled in to a poor choice.
I'll admit it; that programmer was once, long ago, me. Please listen to the bitter, cracked voice of experience. Let me be your Onceler. Don't be that VB programmer. Don't trust gee-whiz wizards and magical tools. Learn XML Schema. Learn to use it to define web service interfaces. Learn JAXB. Be your company's web service implementation hero. Be that guy/gal who knows something way before everyone else does, and does the right thing.