News Stay informed about the latest enterprise technology news and product updates.

Web Services (Part 1)

Web services are currently garnering a lot of attention. Some of the attention is good, some of it not so good. In the latter category, Web services are unfortunately being hyped as the next


Web Services
By Steve Vinoski, Chief Architect, IONA Technologies

Web services are currently garnering a lot of attention. Some of the attention is good, some of it not so good. In the latter category, Web services are unfortunately being hyped as the next "Silver Bullet," magically ready to solve all your computing problems, just like all the other Silver Bullets that came before, and just like those that will surely follow. Several supposedly technical articles about Web services essentially ask us to suspend our disbelief and buy into a "new world order" in which the rules of distributed systems, pertaining to performance, latency, coupling, and scalability, no longer matter. Will we ever learn?

If we look past all the hype surrounding Web services, do we find anything worthwhile? I believe we do. Web services represent an evolution and convergence of three very important areas of technology and business:

  • Electronic Data Interchange (EDI), which has been the backbone of business-to-business integration (B2Bi) for more than a decade. EDI has never had a very large following, due mainly to its high cost of implementation. However, despite its high costs, EDI works, which explains its longevity.
  • Traditional middleware, which is used primarily for application-to-application integration (A2Ai). Systems that fall into this category include EJB, CORBA, COM, and Enterprise Application Integration (EAI) middleware including Message-Oriented Middleware (MOM). These types of middleware have been used very broadly and successfully over the past decade as the integration glue for a wide variety of diverse and heterogeneous distributed systems.
  • The World Wide Web, which as we all know has experienced explosive growth over the past decade, thanks to its remarkable capabilities for the presentation and retrieval of an endless variety of information.

By evolving out of each of these three areas simultaneously, Web services are providing a focus for their convergence. It's too early to tell whether Web services will ultimately serve as the vehicle for such convergence, given that similar claims have been made for CORBA-based applets and other technologies. Below, let's explore how the Web services movement relates to each of these three areas.

Evolution from the Web Perspective

The Web today is essentially a large-scale two-tier distributed system. The "business logic" tier is the Web server, and the "presentation" tier is, of course, the browser. As with all two-tier systems, the Web's capabilities are designed for human interaction. Everything you can see or do on the Web is driven through your browser, so naturally its current content is entirely designed to support such interaction.

Given that we've known for years that two-tier systems are somewhat limited, the fact that today's Web is a two-tier system is somewhat surprising. We learned years ago that two-tier systems, such as terminals tied into a mainframe, limit not only usability but also reusability. They limit usability because of their requirements for human-driven screens and GUIs, and they limit reusability because their business logic services are meaningful only in the context of such GUIs.

Web services are the next evolutionary step for the Web because they extend the Web to a three-tier (or more) system. They allow enterprises to expose their business services as applications that can be discovered and invoked programmatically by other applications over the Web. This capability in turn allows enterprises to create Web-based business services composed of other Web services.

Evolution from the Middleware Perspective

Middleware provides two primary approaches for integrating applications:

  • Procedure-oriented middleware, such as DCE, CORBA, COM, and EJB, focuses on integration via procedure or method calls. With this middleware approach, you wrap your business logic with interfaces that define the rules for interacting with that logic. These "rules" are defined in terms of methods or procedures that are normally invoked by other applications in a synchronous fashion.
  • Document-oriented middleware, such as message queuing systems, focuses on integration via document passing. With this middleware approach, you process business documents by posting them to message queues, where another processing entity can retrieve them and act on them. The message queues decouple applications from one another and allow overall processing to proceed asynchronously.

While many words have been wasted arguing over which of these two middleware approaches is superior, the fact is that both approaches have merit under different circumstances. Most enterprises use a mixture of the two approaches to satisfy their application integration needs.

Web services are evolving out of both of these middleware approaches. For example, the Web Services Description Language (WSDL), recently submitted to the W3C for standardization (see, allows you to describe both procedure-oriented and data- or document-oriented Web services. Not surprisingly, many of the same technical issues that we've been battling in the middleware space for years - interface definition, transactions, message queue persistence, recovery, and security, to cite a few examples - are still problematic, perhaps even more so, in the Web services space.

Evolution from the EDI Perspective

With all the hype currently surrounding e-business, you'd think it was brand new. It isn't. It has been around for more than a decade, in the form of EDI. EDI, in fact, provides for fully automated business-to-business transactions. It works, but it's fairly expensive to implement and deploy.

The high costs of EDI are due primarily to the need to establish proprietary communication networks called value-added networks, or VANs, between EDI participants. The need to employ consultants with special skills to implement the actual EDI business document interchange also contributes to its cost.

A key aspect of EDI, and perhaps the main reason it has survived at all, is that it encompasses detailed business process standards, such as the ANSI X12 standards and the Electronic Data Interchange For Administration, Commerce, and Transportation (EDIFACT) standards established by the United Nations. It seems strange to say that, given that the whole reason EDI exists is to enable computer-automated business transactions. However, these types of standards often start out by addressing low-level details such as wire protocols and programming models, and they never move on toward tackling the higher-level business issues.

By taking advantage of XML as the lingua franca for electronic document definition and the existing Web infrastructure, Web services are providing an evolutionary path toward a less expensive, more productive, and more widely available form of EDI. Evolving B2B standards such as RosettaNet ( and ebXML ( are supplying us with XML-based business document standards as well as standard processes for manipulating them.

Go to Page Two


Copyright 2001, IONA Technologies. Reprinted by permission.


.8tVvawOFlrW^1@.ee85eda>Talk back or comment on this article

The Best Web Links for Web Services

The Best Web Links for SOAP

Free Tutorials for Web services, SOAP, UDDI and more

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.