The Gilbane Report: Volume 9, Number 8

Understanding Web Services

Download a PDF version of this article

Read the news for this issue.

Many of the goals of Web Services have been around since long before the Web. Distributed object computing, object-oriented programming, and related efforts were aimed at more efficient ways to share code and content across networks (although "content" was not an "in" term then, the code still had to act on something). It now seems hard to imagine that those early goals could ever be achieved without at least the Internet infrastructure we have today combined with the phenomenal success of XML. Not that we have everything in place that we need, but widespread sharing of code and content is now easily conceivable and in some cases practical.

The easiest way to convince yourself how important web services will be is to think about them in the context of the computing and communication. Web services will eventually be revolutionary because they will do for communication between computing applications what the Web has done for communication between applications and humans.

While the ultimate effect of Web Services will be profound, there will not be an overnight revolution. As you will see in this month's article by Sebastian Holst (now a regular contributor) there are still some barriers to widespread adoption. At the same time, you need to understand the impact Web Services will have, and can have, on your IT strategies. Sebastian's article will help you understand enough about Web Services to start planning.

Understanding Web Services

Web services are most likely going to be the next next big thing, and in some (developer) circles already are. Of course, there are very few things that are less appealing in today's climate of economic and political uncertainty than another next big thing. Databases, object-orientation, the Internet, and their ilk were big because of the technical, organizational, economic and cultural discontinuities they implied. Web services promise to have this kind of impact. Will they? What should you do? And when should you do it?

A basic understanding of the underlying technologies, relevant standards and commercial activity to date can paint a fairly complete picture of what web services should be able to do and when. In this article we provide you with the basic information you need to determine the affect of web services on your IT strategy, including what web services are, how to think about an adoption strategy, what the barriers to adoption are, who is involved, and how web services re-late to content management.

Web Service Basics

Most web use today involves human interaction with some form of browser or front-end application. Web services are intended to connect applications and processes to one another over the web without requiring human intervention. Like object-oriented technology and earlier distributed computing technologies that have preceded web services such as DCE/RPC and CORBA, web services imply a significant shift in development methodology, environments and skill sets. Understanding the basics of web service functionality and the functional hurdles that must be overcome are an important first step in forecasting their rate of adoption and the impact they are likely to have.

Figure 1: Simplified interaction of an application with a single web service.

Figure 1 Scenario: An application has a need to generate a list of properties for sale in a given geography matching a particular set of buyer criteria for further processing and publishing. Rather than write an application that connects to a back office system, the developer includes a call to a web service. "a1" is the application-specific code that builds the buyer criteria and processes the results. "c1" is the stub built and supplied by the developer of the real-estate web ser-vice. It is included into the "application." "S1 stub" is the standard service-side stub that describes and serves as the wrapper enclosing the actual application that generates the real-estate property list. "S1" is the actual application that does the work of the web service.

Essential Characteristics

The very simple real-estate example is intended to highlight the essential characteristics of a web service as a source for either data access and/or processing functionality. These include:

Discoverable and Publishable: A developer and ultimately an application can look to a public directory to search for and select one or more web services. UDDI (Universal Description, Discovery and Integration at www.UDDI.org) is one early web services repository that is emerging as a reference prototype. Web service providers register their services with one or more directory services that would then be published for use.

Self-Describing: In order to automate the publishing of services over the web, a mechanism to describe the interfaces and capabilities of a web service is required. The current specification under consideration by the W3C is WSDL (Web Services Description Language).

Accessible via Internet protocols: This is what puts the "web" in web services. While there are a number of protocols that have been developed, the one that is getting the most attention seems to be SOAP (Simple Object Access Protocol). Its most significant feature is that it solves the problem of communication through firewalls permitting web services to be offered from virtually any location. SOAP provides the definition of an XML document that can be used for exchanging structured and typed information. It operates in a decentralized, distributed environment. SOAP does not care about the semantics of any application-specific data it conveys. However, SOAP provides the framework by which application-specific information may be conveyed in an extensible manner.

Programmable: Web services can be developed in any programming language and will include legacy applications wrapped in web service protocols. Web services can utilize other web services so that there is a notion of compound web services. Compound services that include both new web services and web service interfaces to existing applications will also be developed.

Figure 2: Mix of web service flavors

Environmentally Agnostic: Last but not least, web services would not be true to the spirit of the web if the design did not guarantee openness and portability.

Multiple Web Services

Now let's look at a slightly more complex example that incorporates multiple web services.

Figure 3: Expanded interaction of an application with 3 web services.

Figure 3 Scenario: The real-estate application developer now needs to include real-time pre-qualification for financing and a meeting planner to coordinate property showings. Different web service providers offer these two significant pieces of functionality as web services. While the basic integration is the same, the resulting application has now become significantly more complex.

Another key web service characteristic surfaces in this slightly extended scenario:

Aggregated, coordinated and loosely coupled: It is expected that applications will include multiple web services offered within and across firewalls, developed internally, by trusted partners and by third parties selected at runtime via trust rankings brokered by reputable service directories that aggregate and rank web service providers.

The Bottom Line

Web services offer developers a distributed and loosely coupled computing environment like none before. Its agnostic architecture, potential to work cleanly across firewalls and reasonably clean fit with the full family of XML recommendations positions it to be the catalyst that connects worldwide computing as today's web has transformed interactive applications.

Web Service Adoption

IT strategies based on web services will be many and varied, and for some time most will include components from legacy and partially web-servicized implementations.

Figure 4: Incremental approach to web service deployment

Figure 4 provides a likely stepwise approach to full web service adoption. The most prudent approach to web service deployment begins with the wrapping or re-implementing of existing services as web services. These would most likely be offered to existing consumers of the pre-web service. Once the basic connections are validated, web services can enable growth in two directions: the deployment of new services and the expansion of the service offering to new customers. The assumption is that the business terms and the connection of the service to the development environment are achieved outside of the directory service. The ultimate scenario (utopia) is a world where both the development environment and the business practices trust web service directories to accurately and reliably offer descriptions, locations and connections to web service providers not previously known to the consumer of those web services. This last scenario is both the most interesting and the furthest away.

Reality Check

There are numerous technical possibilities, scenarios and proposals that could alter the evolutionary path of web services, but a detailed discussion of each of the underlying technological components and the associated candidates for their standardization are beyond the scope of this article. However, it would be misleading to move off of the technical discussion without a short nod to three significant outstanding issues that must be overcome before web services can become truly ubiquitous, dynamic and open.

• Emerging standards are still under development with debate likely to be fierce over whose intellectual property ultimately drives the web service revolution. Therefore, there is a high potential for significant changes in web standards and that there will be technology holdouts that continue to deliver attractive non-standard web services.
• Complete lack of tools or established workflow to support the ultimate vision of dynamic, widely distributed web services. While there are a number of development environments that facilitate the development and use of web services, there is still a long way to go before web services can be dynamically found, evaluated and incorporated into trusted applications.
• Many security and trust issues remain. Standard security functionality such as authentication, authorization, privacy and non-repudiation are mostly incomplete and in some cases nonexistent within web services and the directories that publish and describe them. Fear of bad data, unpredictable behavior or web services that have "side effects" will remain significant obstacles moving mission critical applications to dynamic, web service-based platforms.

Who Is Doing What?

There has been a lot of work done on developing the architecture and standards in support of web services and yet there is still a lot of work to be done. In spite of the relative immaturity of web services, or perhaps because of it, there are numerous competing web service initiatives including every size of technology vendor from the boutique to the world's largest technology corporations. Many are simply working to "web service enable" the software and/or content they currently license. Others are working to offer more comprehensive web service environments that include everything from the tools to build web services, the directories to publish them and a growing collection of web services that are available to embed. A selected list of the latter "comprehensive" category includes:

Bowstreet: Bowstreet is extremely focused on developing a scalable web service platform, web service application development tools and a directory of available web services. As early evangelists that have placed a big personal bet on the value of web services, www.bowstreet.com is an excellent place to begin in inquiry into commercially available web services and the components required to build and to provide them.

Hewlett Packard: HP was an early supplier of non-standard web services under the e-Speak umbrella. Today, they are actively re-implementing their earlier web service product line utilizing the emerging web service standards and marketing this updated web services offering as the hp web services platform. Visit www.hp.com and search the site for web services.

IBM: IBM's Websphere is an early mover in delivering infrastructure and tools to develop and deploy web services. Like most other players at this high-end, IBM is struggling to grab mind share away from Microsoft. For a discussion of IBM's web service offerings, visit www-4.ibm.com/software/solutions/webservices/. For IBM's view on how Websphere compares to Microsoft's .NET, visit http://www-4.ibm.com/software/webservers/studio/msnetreview.html.

Microsoft: Microsoft has taken a very aggressive position on web services offer-ing technology, directory services and development tools. For Microsoft's own view of web services and how they form the basis of .NET, visit www.microsoft.com/net/xmlservices.asp. .NET My Services (originally code named Hailstorm) is the first complete offering from Microsoft with a focus on individual users rather than enterprise services. Microsoft would be quick to point out that many of the individual services have an application to a user's work environment, but they are nevertheless focused on personal productivity.

Oracle Corporation: Oracle has also aggressively moved into the web service platform market with Oracle9i. While touting support for all of the emerging web service standards, much of the key functionality such as the registry and the processing of web and fulfilling of web service requests remain embedded within the Oracle9i platform. This is not a necessarily bad thing given the relative immaturity of web service standards, it is just important to appreciate that Oracle9i has not yet achieved the (utopian) open, dynamic, loosely coupled web service environment outlined earlier. Oracle offers a fairly thorough description of 9i's web service functionality at http://otn.oracle.com/products/dynamic_services/htdocs/ds_wp_deploy_and_manage/ds_wp_deploy_and_manage_1.html

Sun Microsystems: Surprisingly, Sun has come a little late to the party giving others (most notably, Microsoft) a head start in defining the web services landscape. Regardless of the timing, Sun's Sun One initiative certainly qualifies as a comprehensive web service platform that is likely to scale as well or better than any other offering and to be supported by numerous middleware suppliers. For more information on Sun One, visit www.sun.com/software/sunone. For Sun's perspective on the differences in technology and approach between Sun One and .NET, visit www.sun.com/software/sunone/whitepapers.html and select "J2EE vs. Microsoft.NET."

It is evident that there is little debate among the vendor community that web services are going to be very big indeed and that becoming a preferred supplier of web service infrastructure will be as significant a battle as the operating system, DBMS, and browser wars of the past.

Content Management Implications

In the real estate use case outlined here, the first service that was suggested was a service that provided property listings. This is a simple content service where the technology required was a simple DBMS query; the value of the web service was in the content it offered. The second web services was a meeting scheduler - an application that relies less on a data warehouse and whose value is found in its processing capabilities. The final web service offered pre-qualification on a mortgage - depending on how sophisticated the pre-qualification, this hybrid service might have combined content (credit history) with processing power (loan acceptance criteria mapping prospective buyers to specific properties). The first point to be made is that virtually all envisioned web services include some measure of both content and processing power. The second point is that there may be a difference in level of effort and the value proposition depending on the degree to which a web service is valued because of the content it provides or the results of its processing engine.

Will content providers have an easier path to web service enabling their businesses? Most likely, yes. Providing content via a web service versus a portal or a pre-web service connection is not that great a paradigm shift. As such, moving to a web service distribution channel will be a lower hurdle to clear, but will also be far less interesting as business paradigm shift.

Conclusions

Web services are going to have a significant impact on software vendors, individual developers, IT management, and CIOs before they ultimately transform web-based computing or application-to-application supply chains. Until enterprises trust web services, engineers know how to be productive utilizing web ser-vices, and there is a large enough body of competitive web service offerings, today's programming and deployment infrastructure will not be left behind. Security, stability and availability are simply too important to risk for the promise of incremental improvements in flexibility, productivity and openness.

Having said that, do not become too complacent, for as significant as the remaining issues may appear, the resources that are being thrown at the problem are even more impressive. The web has transformed the user's experience and it would be foolish to think that it will not ultimately do the same for applications. Figure 4 provided incremental steps that balance business and technological enhancements that should serve as an odometer for how far a particular web ser-vice initiative will take you. One thing is almost certainly true; web services will find their way into customers', suppliers' and your own infrastructure. The only questions that you will have to answer are to what degree, what the anticipated benefits will be, and what the risk is to your operations and business models. If you do not currently have a strategy for what you will do (or not do) with regards to web services, you should.

-- Sebastian Holst