The cost one can associate with Web services depends on whether one s interest in Web services lies in being a Web-service consumer or a Web-service provider. There is an underlying (and often overlooked) commonality in relation to cost between these two different sides of Web-services, which is that Web services are an enabling technology for software development.
Thus, those who wish to acquire Web services (i.e., the Web-services consumers) will have that interest because they are in the process of developing new applications or adding new functionality to existing applications. (At this juncture one could ignore the potential small market of Webservice resellers and bundle these in as a specialized instance of Web-service providers.) In this respect, Web services cannot be treated as just another facet of the computer application industry. The consumers of Web services are not application end users. Web-service consumers are application developers. Web services set out to simplify and expedite their task.
Web-service providers are also, by the same token, software developers. In some cases they also may be application developers. But this does not have to be the case. The Google and amazon.com Web-service offerings mentioned at the start of this chapter, in conjunction with Microsoft s MapPoint Web Service, illustrate this case in point. Microsoft is a recognized application provider ”which in this instance is offering a Web service in parallel to its other application initiatives (keeping in mind that there is also a boxed MapPoint application available as a standard, Windows mapping application for end users).
Amazon.com and even Google are not conventional computer application purveyors. However, in this instance they are offering Web services. Yes, there would have been a tangible cost to create these Web services ” though they are obviously culled from existing mission-critical software that was developed totally independent of any desire to offer a Web service. These are examples of business logic contained in existing mission-critical applications being repacked and marketed as potential revenue-generating Web services.
The cost of developing such culled Web services is in general relatively small, particularly given the studio-oriented tools available on the market to facilitate such endeavors. Typically a company should be able to get a positive ROI on such culled Web services relatively quickly ”even if in some cases, as with amazon.com, the return, rather than being in terms of explicit dollars for the Web service, would be in terms of overall increased e-commerce and added competitiveness . In other words, when amazon.com s Web service is embedded in another application, users of that application will be directed to amazon ”at the expense of the likes of Barnes & Noble, or Best Buy in the case of electronics.
What should be apparent by now is that with Web services what you are really dealing with is lost opportunity costs as opposed to explicit costs!
Not exploiting Web services when developing applications, or not offering culled Web services from existing applications, could result in higher overall development costs in the case of the former and lost business and diminished competitiveness in the case of the latter. So when it comes to Web services, one really should look at them in terms of obviating lost opportunity costs ”rather than as something that has an intrinsic cost associated with it. The bottom line here is that not exploiting Web services, whether as a consumer or provider, is likely to cost you much more than any cost associated with using or creating Web services. It really is as simple as that.