The classic approach here is to use abstract and concrete WSDLs for each service, where the abstract WSDL defines the types, messages, and portTypes; and the concrete WSDL defines the binding and service elements. Each concrete WSDL will import the appropriate abstract WSDL. (Blog on this: http://blogs.sun.com/gopalan/entry/wsdl_the_wsdl_model). This would allow you to change the abstract model without having to edit multiple WSDL files each time, as well as having multiple bindings for a given interface (HTTP, JMS, etc.).
Brennan Spies Sr. Programmer Analyst Shared Application Services -----Original Message----- From: Ramesh Gurunathan [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 09, 2007 8:32 PM To: [email protected] Subject: WSDL Design Hi Everyone, I'm looking for a WSDL design article. We are providing web service interface for existing APIs, which consist of nearly 50 business logic interface classes, in total it's going to have about 300 business methods. Obviously, writing a single WSDL which (flat) include all the methods of 50 business classes is not a good. Maintenance of such a mega WSDL will be disastrous. If the API, for which web services layer is provided, gets changed, then it will be impossible to ensure that the WSDL is up-to-date with the API changes. What is the right approach and design in this case? My goal is to come up with WSDL that 1) Separates business logic (types, messages, port types) from implementation details (SOAP binding and service end point definitions). 2) Easier maintenance. i.e. When there is a change detected in a business logic class, lets say BusinessLogic1.java, I want to directly edit the WSDL fragment file and not disturb the other WSDL fragments. 3) Of the total 50 business classes, some of the classes can be grouped as module. i.e. A BusinessLogicModule1 contains BusinessLogic1.java, BusinessLogic2.java, etc., I'm thinking of designing WSDL like this: Master.wsdl | |--> Module1.wsdl |---> BusinessLogic1.wsdl |-----> BusinessLogic1.xsd |---> BusinessLogic2.wsdl |----> BusinessLogic2.xsd |-> Module2.wsdl |-> Module3.wsdl Basically, the master.wsdl imports all the module level wsdl fragments. Each module.wsdl imports BusinessLogicN.wsdl. Each business logic wsdl declares messages and a port type. The Module.wsdl not only imports all the business logic wsdls but it creates bindings for each of the port types. The Master.wsdl not only imports all the module wsdls but declares service end points for each of the port types. I may be wrong in my understanding. Please point me to a WSDL design article, if you know any. What do you think on the design above? Appreciate if you could share your thoughts and experience. Thanks in advance Ramesh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
