Applying Web Services

< BACK  NEXT >
[oR]

There's no shortage of possible scenarios for using Web services. The most obvious choices fall into three categories:

Web services can be applied in several different ways

  • Allowing programmatic access to applications accessed via the Internet

  • Business-to-business (B2B) integration, allowing applications from different organizations to communicate across the Internet

  • Application-to-application (A2A) integration, allowing applications within a single organization to communicate across an intranet

A technology that addressed any one of these problems would be interesting. Web services, able to address all three, are certain to be important.

Access to Internet Applications

Suppose you'd like to make an appointment with your dentist, book a flight to Mumbai, or check the balance in your bank account. Today, you can do all of these things on the Web using traditional Web applications. Those applications provide their services through a conventional browser, however, and so they require a good bit of human interaction. Also, because they're so graphical, they're less appealing when the client is a handheld device such as a PDA or a mobile phone. All of these functions and many more could likely be done more effectively if they were exposed as Web services. Using an appropriate interface for the client device, you could express your wishes and then have them carried out on your behalf.

Some browser applications would work better as Web services applications

For example, your calendar program might have built-in access to an airline reservations application. You could perhaps enter your travel plans into your calendar and then rely on it to book the flight on your behalf. In fact, you could do many things in this way: schedule an appointment with your dentist, have flowers sent to your mother on Mother's Day, buy tickets to the Metropolitan Opera, and more. A world of interoperable Web services would be a much more convenient place to live, especially given the increasing popularity of handheld devices with wireless connections to the Internet.

Web services could make our lives more convenient

Using Web services in this way raises another possibility, too: Why can't some of those services generate revenue for the firms that provide them? Just as browser-based Web applications allowed new business models that gave rise to the Internet boom, Web services could also provide new ways for their providers to make money. Not all Web services fit this model, of course your dentist is unlikely to charge you for scheduling an appointment but some certainly do. A Web services based airline reservations application will probably charge you something for using its services, as will a SOAP-accessible ticket broker. By increasing ways for customers to access services, today's e-commerce Web sites can also increase their profits.

Web services could make money for companies that provide them

B2B Integration

Another important application of Web services, one that also commonly depends on the Internet, is B2B integration, connecting software running in diverse organizations. To date, connecting applications at two different companies has often been done in specialized, idiosyncratic ways. Why not use a more standard approach? Web services are a straightforward, universally available technology that can be used to address this problem. Most important, they're a technology that has been embraced by every major vendor. Describing data using XML, defining interfaces with WSDL, finding available interfaces with UDDI, and invoking services via SOAP can provide a common glue across all kinds of diverse environments.

B2B integration will be an important application of Web services

Another advantage of this approach is that since SOAP can run over HTTP, Web services can potentially be accessed through firewalls. The obvious security concerns this raises are discussed later in this chapter, but without some way to tunnel through firewalls, B2B integration over the Internet can't happen. SOAP plays an important part in making this solution possible.

A2A Integration

The hardest problem in many organizations is connecting together existing applications. Every company of any size has running on diverse systems a mix of software that was written at different times in different languages. Uniting this plethora of applications into a usable whole is one of the biggest challenges those companies face, especially when adding new applications to the mix. Web services offer a solution to this vexing problem of A2A integration.[2]

[2] This problem is also sometimes referred to as enterprise application integration (EAI).

A2A integration is a major concern in many organizations

To see how, recall that the fundamental notion underlying Web services is to define an interface whose operations can potentially be accessed from any client. While new applications can easily include support for Web services interfaces, it's also possible to retrofit these interfaces onto existing applications. Because the core Web services technologies aren't tied to any particular environment and because they're supported by multiple vendors, they're an excellent choice for connecting diverse applications within an organization.

Web services can provide a common glue between applications

A Web Services Scenario

To get a sense of how Web services might be applied, imagine that you wished to book an airplane reservation from your PDA via a wireless Internet connection. Once you've entered the destination and dates you're interested in, Figure 2-1 illustrates how the system you use to book your trip might look. As shown in step 1, the process begins when the PDA contacts on the Internet a reservations application that provides a Web services interface. This application might be provided by an Internet travel service, and so it offers a common access point to the actual reservation systems provided by various airlines. Given this, step 2 in the diagram shows this application contacting a specific reservation system provided by a particular airline. Once again, this happens over the Internet, which means that this airline must have chosen to expose its reservation system to the Internet travel service (although not necessarily to anyone else) as a Web service. Finally, as shown in step 3, the airline reservation system interacts with a seat availability application and a pricing application to make the actual reservation. These applications are available only on this airline's intranet, yet they may well run on different kinds of systems using different implementation technologies. Here, Web services provide the glue that unites diverse software.

Figure 2-1. Web services can be applied in many different ways.
graphics/02fig01.gif

A single application might use Web services in several different ways

The Role of ebXML

Effective B2B integration requires a higher level of agreement than WSDL, SOAP, and UDDI alone can provide. If one company wishes to send a purchase order to another, for example, what should that purchase order look like? Most kinds of business interactions depend on documents like this, and carrying out those interactions electronically requires agreement on what these documents look like. Standards for electronic data interchange (EDI) have long defined common formats for these kinds of business exchanges. Yet many people working in this area have come to believe that EDI is no longer sufficient. Instead, the rise of XML allows defining standard business documents in a more flexible and useful way.

As its name suggests, the goal of the ebXML initiative is to define XML-based standards for e-business. The group defines standard business documents, rules for exchanging those documents, and even entire business processes, all described using XML. A large number of vendors and users is involved in ebXML, and they've produced many documents so far.

The ebXML effort originally appeared to be competitive with SOAP-based Web services. The group defined its own protocol for conveying ebXML documents, for example, which competed with SOAP. Eventually, however, the ebXML group endorsed SOAP as an approved option for conveying their standard documents and UDDI as a way to locate Web services. What could have been a painful split in the Web services world was avoided.

Still, perhaps because of this initial conflict, Microsoft hasn't been much of an ebXML backer. Today, .NET doesn't offer direct support for this family of specifications. ebXML is likely to be important, though, at least in some areas, so it's probable that Microsoft will support it if and when its customers insist. If effective Web services based B2B integration requires ebXML, as it very well might, Microsoft won't have much choice.

Creating Common Connections: Why COM and CORBA Couldn't

Wouldn't it be nice if all kinds of software on all kinds of systems could snap together like LEGO blocks? The technical problems that stand in the way of this goal aren't hard, especially if we're willing to accept a fairly basic level of connectivity. What has stopped us in the past is will: Users have had it, but vendors haven't. And in this case, vendors rule.

Microsoft, for example, has been quite successful in creating snap-together software for Windows platforms. COM makes this possible even when that software is running on remote systems. But other major vendors haven't seriously supported COM, and one could debate whether Microsoft ever really wanted them to. Similarly, the Object Management Group's CORBA was intended to connect all kinds of applications on all kinds of systems. Two problems doomed the OMG's efforts, though. First, their standards weren't complete enough, so organizations were all but forced to stick with a single CORBA vendor to make their systems communicate. And second, Microsoft didn't support it.

At long last, however, something has appeared with both the right technical merits and, more important, vendor agreement. That something, of course, is Web services. After more than one false start with other technologies, we're likely to see SOAP and its fellow travelers emerge as the standard mechanism that all applications use to expose their services to the outside world. Given that every vendor has endorsed these technologies, users should expect (and, if necessary, demand) that software providers make their products more interoperable by providing Web services interfaces. While some problems remain, as discussed later in this chapter, Web services look like the best chance we've seen yet to create true standards for application interoperability.

Step 1 in Figure 2-1 is an example of a client directly accessing services across the Internet, the first use of Web services described earlier. Step 2 shows Internet-based B2B integration using Web services, while step 3 illustrates an A2A scenario that uses Web services to integrate in-house applications across an intranet. In every case, these useful technologies provide common interfaces and common ways to communicate among diverse applications on diverse systems over diverse networks.

< BACK  NEXT >


Understanding. NET. A Tutorial and Analysis
Understanding .NET: A Tutorial and Analysis (Independent Technology Guides)
ISBN: 0201741628
EAN: 2147483647
Year: 2002
Pages: 60

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net