Advertisment

Everything you wanted to know about web services

author-image
CIOL Bureau
Updated On
New Update

Holt Adams



Customers, and not evangelists, are driving the rapid adoption of web service technologies, within and beyond the enterprise. A key challenge for many developers and application architects who are seeking to apply these technologies, however, is the fact that amidst all the hype, there is currently very little direction available on how to best apply new technologies such as SOAP, WSDL, and UDDI within real business scenarios.



Recognizing this deficiency, a number of developers and architects from across IBM's Global Services, jStart, and Emerging Technologies Groups have sought to identify and document a collection of best practices for the real-world application of web service technologies on a scenario-by-scenario basis.





What is a web service?



It is probably fair to say that the initial hype surrounding web services has reached astronomical proportions, so much so that the language used to describe what web services are, and how to go about implementing them, is becoming entirely too overloaded and muddled. In fact, one of the most difficult tasks the recently formed W3C Web Services Architecture Working Group has faced so far has been to determine the answer to what seems like an easy question.



What is the generic definition of a web service?


Given all the hype, one might think that such a definition wouldn't be hard to come by. The challenge, however, is to overcome the abundance of definitions, most of which are contradictory and only reveal a fragment of what web services can be or may become.



The working definition of a web service that the W3C web Services Architecture group managed to agree on is as follows:



A web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described, and discovered by XML artifacts, and supports direct interactions with other software applications using XML-based messages via Internet-based protocols.



For those who think that web services are limited to SOAP messages used to invoke the methods of an application over an HTTP connection (as the traditional SOAP stock-quote service does), this definition may be a bit surprising. However, it tells us a couple of interesting things pertinent to our goal of a common vernacular:

Advertisment



  • Web services do not require SOAP.


  • Web services do not require HTTP.

However, a web service (as defined by the W3C) does require an XML-based description mechanism of some kind (such as WSDL) that can be used to describe the service's form and function. Remember, the backdrop framework for this industry-wide initiative around web service technologies is a service-oriented architecture.



As such, a non-XML based description mechanism (like IDL) would make an SOAP implementation more complex and less open. Note also that the W3C's definition, while mentioning service discovery, does not mention UDDI or any other specific discovery mechanism. This fact will become important as we walk through the various business scenarios and explore how and why certain service discovery mechanisms are used.



Specifically, while early literature on the web services architecture asserted that UDDI had a core, essential role to play, real-life implementation of business solutions with web services have demonstrated that UDDI's most significant role is actually quite specialized at this time; in fact, many web services solution are built that do not use UDDI in any way.



In the vast majority of current business cases, it would be safe to say that these discovery mechanisms are not yet a core component for integrating processes between business partners. Web services in our vernacular, as it is already associated with the domain of technologies relevant to our conversation.



What we discovered as we began to analyze customer scenarios is that we needed to come up with new perspectives and a vernacular to differentiate the various subtypes of web services that emerge through the use of the different available description, message, and transport protocols.

Figure 1. Service-oriented application protocols



Advertisment

From Figure 1, we derived the first two definitions in our new vernacular:



  • Web services
  • are software components that are developed using specific technologies from three primary technology categories:

  • An XML-based description format (for example, WSDL)


  • An application messaging protocol (for example, SOAP)


  • A collection or transport protocol (for example, HTTP)

Advertisment

In each of these categories, there are proprietary (vendor- or platform-specific) technologies as well as open (vendor- or platform-independent) technologies available.



  • Service-oriented applications
  • include applications that MAY make use of web service technologies such as SOAP but may not include a WSDL or other XML-based description. Such applications are considered web-service-like but are not technically web services.

After considering the W3C's definition and the Venn diagram in Figure 1, we can say that any piece of software that is described using some XML-based description mechanism qualifies as a web service. It does not matter if such an application makes use of any other web service technologies. It is quite possible for an application that uses a programming language-dependent messaging protocol (for example, JMS) and a proprietary transport protocol (for example, MQSeries) to qualify as a fully compliant web service by simply providing a WSDL description of the application's interface. Conversely, an application that sends SOAP messages over HTTP but does not provide a WSDL description does not qualify as a web service, though it would be considered web-service-like and deemed a service-oriented application.



So, given our new definition for a web service, let us now focus on the circle in Figure 1 that represents open XML-based descriptions. Furthermore, let's focus on the pain-points at which web service technologies were originally targeted: integration and interoperability. These two pain-points are pertinent to application development both internal and external to the enterprise.



In Figure 2, we illustrate a subset of web services and derive three new additions to our vernacular.



Figure 2. Domain of web service protocols

Advertisment



  • Enterprise web services are web services that do provide a WSDL description but may make use of proprietary application messaging or transport protocols. An example of such a service would be one that sends SOAP messages over


IBM MQSeries using JMS.

Advertisment



  • Internet web services
  • are enterprise web services that MUST only use open application messaging or transport protocols. An example of such a service would be one that sends OTA XML messages over HTTP.

  • XML web services
  • represent the very small subset of Internet web services that MUST use the W3C's adopted XML-based messaging protocol over a narrow range of transport protocols. Specifically, XML web services will only send SOAP messages, and only send them over HTTP, SMTP, or raw TCP/IP connections.

These new definitions capture the concepts conveyed by many in the industry over the last few years whilst providing a semantic framework to categorize the subsets of components that the original (overloaded) term web services intended to capture but failed to articulate.



For instance, Microsoft's .Net strategy focuses on XML web services, while CommerceQuest's CICS Process Integrator (CPI) focuses on enterprise web services. This new vernacular provides a framework for understanding the intentions of both companies with respect to web service technologies.



Resources

With inputs from Dan Gisolfi, James Snell , and Raghu Varadan

tech-news