I am dealing with a question, which is gradually turning in to a religious issue. The key consumers of our Web services are a PB9 application, a .NET application and another J2EE application. The value proposition of using Web services here is that it provides a solution to integrate these diverse set of applications.
We correctly started first with a WSDL (as opposed to starting with components on J2EE which can be converted into Web services by tools). But next the important question is about XML schemas. We can define types inside the WSDL as follows:
<wsdl:types> <xsd:schema> <xsd:complexType> ..... </xsd:schema> </ wsdl:types>
OR alternatively import the schema types in the WSDL. In either cases, when the Web services toolkits (on various platforms) are ran (either to generate shell or to a generate proxy), we get language specific classes for schema types defined within the WSDL.
The toolkits are at various maturity levels and their support for various schema features is limited. Just getting a base minimal WSDL that correctly generates and handles all the XML schema types on all the platforms is a challenge. Additionally, I loose the rich validation aspects offered by the schema because the types generated does not do cool things like pattern checks or check for nulls, etc., and I have to code for those things.
All the platforms support strings, so my solution to this problem was to simplify the WSDL by not having types at all -- have a basic contract using strings. The service consumers pass XML documents (adhering to schemas defined but not part of WSDL) via these strings. The service provider uses the XML schema (agreed upon earlier) to validate the XML passed over.
Now I am losing the language specific types, but I have made the interface simple and loosely coupled. Also, I don't have to worry about any platform specific support for a particular XML schema feature, which may work on one platform but not on other.
What is wrong with this approach versus using (or importing) types within WSDL?
If possible, I recommend using types rather than just sending an XML message. Here are my recommendations for making it work:
- Use Document/Literal
- Follow the "wrapped" programming convention -- most toolkits can simulate the RPC programming invocation model when using Document/Literal with the "wrapped" programming convention. See my blog for more information on the wrapped style.
- Keep your types relatively simple. Use simple types, structures of simple types, and arrays of simple types or structures of simple types. Your structures should be defined as sequences. Avoid using choice groups, unions, etc.
- Define your types in a separate schema and import them into the WSDL. If a toolkit can't process your type definition, then you can develop a custom de/serializer, or that specific application can process the SOAP message by hand (they way you're doing it today).
Dig Deeper on Service-oriented architecture (SOA)
Related Q&A from Anne Thomas Manes
Anne Thomas Manes explains the differences between open source clients and open source implementations. Continue Reading
Anne Thomas Manes discusses the best way to go about creating an enterprise data dictionary and why the systems works well. Continue Reading
Anne Thomas Manes explains the difference between 'hard' real time and 'live' real time systems. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.