I am into week three of a module on web application design as part of my MSc. This has largely focused on the pros and cons of XML as a way of exchanging data but as part of my research into topics I have read a few articles on the best way to design Web Services - small but extremely powerful software components that live on a web server and allow interaction with data. They can easily be consumed by other applications because of the international language of XML and the concept of the 'mash-up' (websites and portals that amalgamate data from multiple sources) is possible because of Web Services.
There's a really good article written by Close (2005) that discusses contract - first web service design. What this means is that design starts with the schema; the data that the web service will take in and send out is decided upon first before any coding begins. If, like me, you have worked in an organisation where the needs of the business typically have to be bent around how an application has been implemented because the implementation was led by IT then you will understand how important starting with the data is.
Last week I started working on the design for an upgrade of an existing system that allows the online approval of mileage and expense claims. The current system works but it works really badly; maintenance is a nightmare and the user experience would be rated poor (to put it mildly). It's also incredibly slow. The mistake I made there was to treat the 'tinkering' with code as the design phase. I had a few ideas, hashed them together and unleashed it. As more and more people came to rely on the service it ground to a halt.
Fortunately I have learned a few things since then. I made the decision to write a web service that would interact with the database and this would provide the foundation for a web front end to be built upon. Equally I could expect someone to be able to plug an InfoPath form into the web service and build on top of it too. I had been to a couple of meetings with the business owner of the service (in this case the internal audit division) and we had agreed what the weaknesses were and what improvements they wanted making. Based on this two page document I sat with a blank piece of paper in front of me and asked the question "what operations do I need to perform on this data?"
I made the mistake of starting with the methods for the web service, and a couple of days into the design process I realised I needed to design the underlying operations first. What I wanted was two levels; the top level would be the web service methods that could be called by an application and return data based on inputs. The second level would be the components that the web service methods would be constructed from. I figured that if I put this bottom layer in place first it would be easy to put the web service layer together from the component 'blocks'.
It's incredible how liberating this was. I could essentially make my mistakes 'cheaply'; there was no investment in code that I would have to rewrite because I screwed up my thinking. At every point I was able to ask questions like: "what should be the input", "what should be the output", "how should an error be handled".
I studied software engineering at university and I have been developing applications for five years in my current post. But I have never taken this approach before. Part of this is down to immaturity, part is because I never really saw the need. But I understand the need now. Doing this creates a clear audit trail of paperwork and documentation about exactly how the service works and how the technology knits together. It's easy to create clear project tasks from the design documentation and I'm confident that I can hand it to a colleague and get them to do the building work.
Close, S. (2005) 'Contract-First Web Services: 6 Reasons to Start with WSDL and Schema' [Online] SYS-CON MEDIA.
Available from http://soa.sys-con.com/node/143909 (Accessed 23rd January 2009)