XML & Web services: which approach? - wsdl first or implementation first
When designing and developing web services, which is better approach: wsdl first or implementation first?
- Posted by: Taku Sugimoto
- Posted on: November 05 2005 01:57 EST
I've thought wsdl first approach was to be taken, but it seems many tool providers such as ibm, bea or axis push implementation first approach.
Any idea will be appreciated.
- depends on intention.. by Ole Matzura on November 06 2005 13:33 EST
- depends on intention.. by Taku Sugimoto on November 07 2005 22:36 EST
- if want tight control of the 'contract' - top down by Craig Salter on November 22 2005 23:02 EST
- Top-down is the professional approach by Ernst de Haan on November 28 2005 15:28 EST
From a strictly "OOP" point-of-view, I would argue that creating the interface (ie the WSDL) before its implementation is the (only) way to go. On the other hand, I think the best way depends a little on your "intentions" with using soap/wsdl..
- If you are using soap as a "plumbing" technology in a totally internal architecture on a single technology platform that you have full control over (for example j2ee or .net), generating wsdl from ejb's (for example) is probably easier and faster
- If you are using soap as an integration technology in a distributed architecture with external integrations where many platforms may be integrated, starting with the wsdl is probably a better option as it will give you full control over service contracts and their interoperability.
Tool-providers (especially commercial ones) will push the former since the later would (probably) make you less dependant on their technology (even though they will claim otherwise), both from a technical and development-process point of view.
If you are stuck somewhere in the middle of the above 2 "extremes", I suggest starting with the wsdl as it will give you better control over your service contracts/lifecycle and will "prepare" you for interoperability with other platforms. With the current wsdl/soap tool offering, this option may take some more time though, so if you are in a hurry, generating wsdls from implementations is probably easier..
well.. I hope this helps you out!
Thanks very much for your insight. Do you know any recommended wsdl editors?
We have used eclipse and their WTP which works pretty well for WSDL editing. Once you start implementing I obviously have to recommend my own tool soapui (http://www.soapui.org) for testing and debugging ;-)
There was an interesting article on the "WSDL first" approach in the october issue of WebServices Journal, maybe that can help you further..
Hi Taku and Ole!
I don't quite agree... It all has to do with WHY you build WebServices. Web Services are built to be used. A major part (maybe the most important factor) of WebService quality is HOW close the service consumer uses it is to the way he WANTS to use it.
Therefore i say; always, always start with on designing the service, then the create the wsdl, and then the implementetation.
Of course it can be used "just" for internal plumbing and the quality of the service (how well thought out the interface is) is not a factor. In that case I don't think WebServies are needed at all.
Thanks for your comment.
Humm, "web services or not" is a different question, but if it's supposed to be exposed as a web service, the "wsdl first" approach seems a right one.
I tried eclipse and WTP, which looks pretty nice!
I'll also your soapui.
Thanks so much!
Bottom up is often fine for quick and dirty web services where no one is particularly choosey about the interface. Top down is the way to go if you're developing web services and you want to carefully design the contract. Especially if your web service will be using industry standard XML Schemas to describe the data structures.
BTW, good to see some of you using and enjoying the WSDL editor in WTP. My team (here at IBM) is responsible for the XML Web Services content in WTP (which includes WSDL, XML Schema and XML related bits). So it's always good to hear feedback. And it you're interested in contributing bug fixes or implementing new features we're always eager accept contributions.
Oh and bug reports are welcome too ;-)
When designing Web Services for typical applications (i.e. where the services need to be reliable, need to function for a relatively long time and change in specifications is relatively costly) you should always design first and then build. That's a very basic rule in IT.
However, for research or for a pet project, building bottom up can be a way to gain knowledge so you will become a better designer.
The problem with WSDL is that it is quite a complex format. The learning curve is relatively steep, especially if one is not familiar with XML Namespaces. It becomes worse if you take related technologies, such as Basic Profile into the picture.
However, there are tools that simplify Web Services greatly, without "generating specs from code", such as SoapUI ( http://www.soapui.org/ ) and XINS ( http://xins.sourceforge.net/primer.html )