Nowadays, creating a webservice can be fairly simple. Axis has finally got to a point where creating a SOAP interface requires the minimum amount of chicken slaughtering and dark incantations, and .NET makes it ridiculously easy (no wonder Java 6 is aping .NET-style ease of use(magpiebrain – Sun on Mustang (J2SE 6.0) – squaring up to .NET?) for webservices). Both Djano and Rails make it easy to create REST-style apps (Django’s URL’s are RESTful out of the box). The problem is creating a webservice shouldn’t simply be a case of placing a language-agnostic HTTP-based interface (be it REST, XMP-RPC or SOAP) in front of your application.
The word ‘service’ in webservice should represent more than the programmatic interface between the server and clients. It should represent a contract between two parties – the maintainer and user of the service – on more levels that what methods can be called, and what types are defined.
As a developer of a service you must be able to commit to (and document if required) a level of service – in terms of uptime, throughput and handling support. You need to have a versioning strategy that allows clients to not only test against new versions of your service, but also gives them time to upgrade once a new version goes live. You need to establish agreed communication channels between yourself and clients. This applies equally if the service is for use inside a team, a department, a company or even between businesses.
As a user you need to give the service some indication of current and future load – giving them a chance to scale if required, throttle your traffic, or look at optimising your current use. You also need to be proactive in testing against new versions of the webservice – not only so you migrate to the latest and greatest version as soon as possible, but also so you can aid the developers and feedback bugs.
As sappy as it sounds it’s about being nice to each other. Webservice developers need to understand that their service doesn’t exist in a vacum – sure your lives would be easier without users, but without them the would be no need for your service. Clients need to understand that the developers need your help to do their job. I’ve seen first hand what can happen when the communication between the two groups of people break down – and that within the same department. Understanding what is involved in creating and maintaining a webservice will make everyone’s lives easier.
magpiebrain 
3 Responses to “The importance of the word ‘service’ in ‘Webservice’”
I’d say that “service” should also mean that web services are there to serve the projects’ needs and the projects are not there to serve the web services. That is, there should be an obligation for a service to prove its worth to projects and projects should not be required to use them.
You’re correct of course Sam but you are also stating the obvious. An enterprise’s decision to move to an SOA based on Web services is a strategic one, not a technical one. While current Web service world is an interesting one to be in (I am now 100% on Web service projects) and the new standards promise much, the real deal for an enterprise is the value the service offers to the business not the technolgy used to implement it. Businesses (SWIFT in particular) have been defining these ‘service parameters’ for years. Currently many are ‘out of band’ although XML namespaces provide the message standard versioning businesses must rely upon. What is new and interesting in the SOA world nowadays is both the promising new standards being proposed for business integration, service quality, business process management and the level to which these new SOA standards are being supported by middleware vendors such as IBM, Microsoft, Oracle, etc. Many currently criticize the Web service world, especially those in the RESTful community (I think) but the value is in the new standards coming forward. WSDL in particular is making a real difference in the back offices of the worlds financial institutions.
You’re correct of course Sam but you are also stating the obvious. An enterprise’s decision to move to an SOA based on Web services is a strategic one, not a technical one. While current Web service world is an interesting one to be in (I am now 100% on Web service projects) and the new standards promise much, the real deal for an enterprise is the value the service offers to the business not the technolgy used to implement it. Businesses (banks in particular) have been defining these ‘service parameters’ for years. Currently many are ‘out of band’ although XML namespaces provide the message standard versioning businesses must rely upon. What is new and interesting in the SOA world nowadays is both the promising new standards being proposed for business integration, service quality, business process management and the level to which these new SOA standards are being supported by middleware vendors such as IBM, Microsoft, Oracle, etc. Many currently criticize the Web service world, especially those in the RESTful community (I think) but the value is in the new standards coming forward. WSDL in particular is making a real difference in the back offices of the worlds financial institutions.