We have our Axis/SOAP app prototype running fine, but before we ramp up in functionality, I have a high-level WSDL design question:
Imagine we have some biz functionality:
( ) Employee ( ) Payroll ( ) Customer ( ) Order
Assume that the functionality is loosely related, as is the above.
We are using an .xsd schema file for each of our functional units (i.e Employee.xsd, Payroll.xsd, etc.) with, say, a Common.xsd for elements which cross functional boundaries. This effectively avoids redundant element code maintenance in the various .xsd's.
We then create a .wsdl for each functional unit (i.e. an Employee.wsdl, Payroll.wsdl, etc.), and use the <xsd:include> statement to pull in the associated .xsd file. Example:
This is working ok for us, but I'm worried about the possible coding redundancies (and other potential downsides) of having one .wsdl for each functional unit.
Would it be better to have a single .wsdl and a single .xsd for ALL our functionality? How far do you carry this out? What if we ramp up to several dozen functional units? Is that still a better approach? What are the potential downsides of having a single .wsdl?
Should we even create .wsdl's based on functional units? Is there some better accepted organizational approach?
Bottom line question is: What are some of the best practices for industrial-strength wsdl design? I can't yet find much on this in the books and samples.
Usually all the endpoints provided by single Web service are described in the same WSDL. Richard Monson-Haefel has a short discussion in his book J2EE Web Services on the pros and cons of various WSDL and Schema management approaches � in the end versioning is the thorniest issue. Whatever strategy is employed it usually involves some use of WSDL imports and/or XML Schema imports rather than strictly separating everything. WSDL file imports.