Fulfilling the Middleware Promise

Web Services have received al- most as much press coverage as the declining stock market in the last 12 months. This has inevitably led to a lot of hype and confusion about what the technology can and cannot do. Before examining the really useful and valuable attributes of Web Services, it's important to first explain exactly what they are.


Web Services have received al- most as much press coverage as the declining stock market in the last 12 months. This has inevitably led to a lot of hype and confusion about what the technology can and cannot do. Before examining the really useful and valuable attributes of Web Services, it’s important to first explain exactly what they are.

Not many people can precisely define Web Services or the types of problems they will solve. Beyond agreeing that Web Services are defined using the Web Services Definition Language (WSDL), are accessible using SOAP (Simple Object Access Protocol), and are registered using UDDI (Universal Description, Discovery, and Integration), little else is agreed upon. This is the natural state of affairs for two reasons. First, WSDL, SOAP, and UDDI are powerful and flexible technologies that can do many different things. Second, we’re still in the early days of the Web Services era.

The reason Web Services are noteworthy is that they might be able to succeed where previous middleware initiatives and standards have failed. There’s little new in Web Services from a development model perspective. However, developers have learned from the experiences of previous middleware models such as CORBA, DCE, and even COM.

The difference with Web Services is in the standards themselves and in market acceptance. The central role played by XML opens middleware development through Web Services to a wider community than was ever available before. Now everyone using tools and languages like Java, Perl, and Visual Basic has a common means of developing applications that will not only interoperate, but will work across the Internet without needing to develop any new protocols.

Enter: SOAP

I believe the key to Web Services momentum is SOAP. SOAP is making profound changes to the communications and interactions landscapes. In the truest sense of the term, SOAP is a disruptive technology. SOAP is not only being adopted and endorsed by rivals such as Sun and Microsoft, and standards bodies such as the United Nations (ebXML), but is also being actively used to solve real-world problems. As the baseline technology for Web Services, SOAP is leveraging pervasive Internet technologies to deliver two much spoken-about paradigms — the delivery of software as services, and as a corollary, the integration of online businesses.

While SOAP is key, we shouldn’t discount the importance of the industry collaboration around Web Services. I often associate the significance of vendors’ adoption of SOAP with Microsoft’s embrace of TCP/IP in 1995. Prior to Windows 95, getting a TCP/IP stack to work on a DOS-based PC was not a trivial task. You had to open the PC, change the interrupts on the network card, reboot, and hope it worked! Microsoft’s inclusion of TCP/IP in Windows 95 opened the Internet to a much wider consumer audience. With support for SOAP now coming from Sun, Microsoft, IBM, the open source community, and practically every other hardware and software vendor, it becomes the de facto means of communication between software components both inside the corporate firewall and over the Internet.

The ubiquity that SOAP offers opens exciting opportunities for Linux users and developers. We now have a situation where the most efficient way to develop an application is to use the most effective tools and technologies for the job, with the knowledge that, thanks to SOAP and Web Services, those applications will seamlessly link with other applications.

For these reasons, I believe SOAP delivers a tried and trusted paradigm in a new and more accessible packaging. The messaging paradigms behind SOAP, both in terms of Remote Procedure Call (RPC) and store-and-forward messaging, are well understood and widely deployed in technologies such as J2EE, CORBA, and MQ Series. SOAP takes these well-understood concepts and packages them using the ubiquitous protocols of the Web, namely HTTP and e-mail, while also using flexible yet simple XML technology to describe the actions and the data payloads.

With this combination, SOAP finally managed to achieve what J2EE, MQ (Message Queuing), and CORBA never could. Today you can visit http:// www.xmethods.com to see and use real, live, Web-accessible services. In the same way that smaller disk drives changed the storage industry, SOAP is already making fundamental changes to the ways in which many businesses publish their processes on the Web and how these processes integrate with one another.

How Web Services Will Change Business

To clarify this disruptive change, let’s take an example. Take SOAP interfaces to two basic Web services. One is the Barnes & Noble book-pricing engine, which will return the price of a given book in US dollars. The second is a currency converter. With minimal knowledge of XML I can write an application that will find the price of a book in any currency you care to mention. Both of these applications are accessible from the Web. They’re implemented in systems I don’t know about — all I know is the interface to them. However, in a matter of minutes I can create a new application, which combines functionality from two diverse sources. This easy composition of applications is precisely what’s so disruptive about SOAP.

The flexibility offered by Web Services opens a wide variety of uses. One set of users sees Web Services as a very simple Internet technology that can be used to replace some of the existing Internet screen-scraping techniques. Rather than trawling a site and extracting data from pages based on an implicit understanding of how that data is formatted, a SOAP interface can provide an explicit well-formed interface to that data.

These users see SOAP as a convenient protocol that offers little or nothing in the way of guarantees or quality of service, and in fact believe that minimal SOAP implementations can meet all their needs. These users don’t perceive Web Services as a new programming environment, but rather as a useful adjunct to their existing collection of Web tools. For these users, the key to success is a wide variety of tools designed for mainstream developers that makes Web Services as easy to use as FrontPage.

The other end of the spectrum is defined by a set of users who see Web Services as a new distributed computing environment. These users come from a J2EE, CORBA, or COM background and are familiar with all of the usual technologies associated with distributed computing.

This group of users sees Web Services being expanded to include support for stringent security, asynchronous messaging, and message logging and auditing. They would like to introduce a whole new set of APIs and programming paradigms that would elevate Web Services to a new rich and complex development environment. Tools will also be important to this group, although the emphasis will be on productivity rather than simplicity and user-friendliness.

Naturally, neither of these two extremes provide a likely path for the evolution of Web Services. As usual, the truth is somewhere in the middle.

The First Beachhead

Web Services are already being used to solve several real world business problems. However, these initial uses of Web Services are primarily in integration projects. This makes a lot of sense, since Web Services provide an ideal integration solution. It’s inherently suited to integration (and as a mainstream middleware solution) for two key reasons.

Ubiquity: As we discussed earlier, SOAP is a perfect universal protocol. Based on and utilizing both HTTP and SMTP, it does not require an organization to make a costly investment in new network protocols. There isn’t a company around that doesn’t have both HTTP and SMTP installed. Organizations have often looked at a middleware or integration solution that used costly and proprietary protocols, which presented many technical difficulties when required to work in conjunction with standard networking elements such as firewalls and routers. Web Services remove these issues in an elegant and practical manner. Organizations can now easily and inexpensively begin developing Web Services.

Ease of Use: By far, the most compelling aspect of Web Services is the fact that it’s easy for developers to use the technology. Even a cursory glance at the http://www.xmethods.com site shows that there are new Web Services being created daily. Despite the popularity of middleware such as J2EE, MQSeries, CORBA, and others, there is no public Web site where you can see and use components based on those technologies!

If Web Services becomes the integration standard, then we must ask what will become of all the existing EAI (E-Business and Application Integration) and B2Bi (Business to Business Integration) vendors? I believe the integration problem will remain a large and profitable market.

Web Services can solve about 80 percent of IT integration problems. This is because the majority of integration problems are of a tactical and straightforward nature. They don’t require 200 consultants and $4 million worth of software to be solved. However, 20 percent of integration challenges will remain very specialized. This can be attributed to performance or complexity.

Integration projects for stock market data feeds on Wall Street, for example, require quality of service not offered by Web Services. I think the existing EAI vendors are best equipped to tackle that 20 percent enterprise space. I guess that’s what the “E” in EAI stands for!

Fulfilling the Promise

Web Services has been subject to a lot of hype. However, the result is an agreement on a range of standards, which even today offers exciting solutions to the incompatibility problems that have plagued the IT community for over 20 years.

This is great news for the Linux community, which now has complete access to applications and platforms across the enterprise and the Internet. We expect Web Services to drive exciting new possibilities as for the first time people bring together the vast computing resources that are out there.

Web Services are set to fulfill the great promise that was made by their middleware ancestors. This time, the technologies and the support are there to achieve it.

Annrai O’Toole is executive chairman of Cape Clear Software. He can be reached at annrai.otoole@capeclear.com.

Comments are closed.