The Pros and Cons of Web Services

List of Arguments
Pro: Web Services are standards-based.
Pro: Web Services’ loose coupling leads to increased modularity and flexibility in complex, distributed IT environments.
Pro: Since Web Services are dynamically described, they will lead to systems that can be upgraded automatically.
Pro: Web Services reduces integration costs.
Pro: Web Services simplify Business to Business Integration (B2Bi).
Pro: Web Services enable new business models.
Pro: Web Services leverage existing technology and skill sets.
Pro: Web Services enable less technical business people to “assemble” software solutions without the need for coding.
Pro: The Business Climate is Favorable to Web Services.
Con: Web Services are immature.
Con: Some vendor solutions are single-vendor approaches which conflict with the open standards-based vision of Web Services.
Con: It is unclear where the money will be made in offering Web Services.
Con: The name “Web Services” is vague and misleading.
What are Web Services?
ZapThink believes that in the current chaotic environment, Web Services are both poorly named and vaguely defined. As a result, there is a great deal of confusion in the marketplace about exactly what Web Services are, what their importance is, and where they fit into the overall IT picture. Nevertheless, the phrase “Web Services” has, for better or worse, become the de facto term for a vague set of capabilities. ZapThink has prepared this report to clarify what Web Services are, what they’re for, and just as significantly, what they are not for.A strict definition of Web Services is “encapsulated, loosely coupled, contracted software objects offered via standard protocols.” Essentially, Web Services are application functionality residing on systems that accept requests from other systems locally or across the Internet by means of lightweight, vendor-neutral communications technologies. Breaking down the definition should make it clearer:

  • Encapsulated means that the implementation of each Web Service is invisible from outside the Web Service. Its functionality is known only by the interface it exposes. In essence, Web Services abstract the implementation from the interface, similar to the way that XML separates content from processing. Web Services inherit the property of encapsulation from object-oriented architectures like those based on Java, C++, and COM.
  • Web Services are loosely coupled. Loosely coupled means that Web Services and the programs that invoke them (known as Web Service consumers) can be changed independently of each other, instead of requiring a redesign of the involved components. A Web Service consumer is any piece of software that finds and invokes (or binds to) a Web Service. Consumers may or may not be Web Services themselves.
  • Contracted means that the Web service’s behavior, as well as how to connect, or bind to it, and its input and output parameters, are available to those consumers who are able to access it.
  • In the context of this report, and as increasingly accepted by the software industry as a whole, Web Services are built upon the standard protocols XML (eXtensible Markup Language) and HTTP (Hypertext Transfer Protocol), which are both open and freely available. In addition, Web Services leverage SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery, and Integration), which are all standard protocols based upon XML. As we’ll see later, the definition of Web Services requires standards, but these specific standards (SOAP, HTTP, WSDL) are not required for a solution to be considered to be a “Web Service” if other standards are adopted.

In addition to the above four features that might be considered the core aspects of Web Services, ZapThink also adds the following two characteristics:

  • Web Services are self-defining. Self-definition is a feature of XML that the core Web Services technologies SOAP and WSDL take full advantage of. Since WSDL files describe at runtime, as well as at design time, how to exchange information with Web Services, such descriptions can be changed on the fly, without breaking the Web Service consumers.
  • Web Services support dynamic discovery and invocation. By taking advantage of a UDDI registry, a Web Service consumer can locate and invoke a Web Service at runtime-without the need for a person to program this ability to access a particular Web Service ahead of time. This capability is called Just-in-time (JIT) integration.

This definition of Web Services, however, only tells part of the story. Much more important is the ability to distinguish what aspects of the Web Services model (which is the overall approach to distributed technology enabled by Web Services) will lead to solving real business problems, and what aspects are just hype. In addition, even for those aspects of the Web Services story that are the most promising, it is clear that many facets of the Web Services model are still quite immature.

In fact, this level of immaturity made writing this report a challenge, because for each aspect of Web Services we considered, we encountered the following conundrum:

    • Pros of X (where “X” is some aspect of the Web Services story):

      • X has a lot of promise

Cons of X:

    • X is still quite immature

To make this report useful, therefore, we needed to go beyond the fact that many Web Services-related technologies are still in the emerging or early adoption phases. We decided to provide an analysis of the pros and cons of each aspect of the Web Services model, in the context of the emerging nature of the technologies.