Web Services

< BACK  NEXT >
[oR]

The World Wide Web has radically changed the way we access information, buy products, find jobs, and generally live our lives. It has done all of this through applications that interact directly with people through a graphical user interface (GUI).

Web applications today are typically accessed via a GUI

It's no exaggeration to say that GUI-based applications have made the Web what it is today.

But GUI-based applications probably won't be the vehicle for the next phase of the Web. To understand why, think about the kinds of services we get from the Web today. Some of them, such as reading The Economist online, should be delivered through a GUI-based application how else could we get them? Yet an important set of services could be used more easily and more effectively if the applications that provided them were accessible programmatically. Rather than a person sitting at a browser, the client for these services would be software running on a desktop computer, a mobile phone, or some other device. Rather than making requests using only the traditional Hypertext Transfer Protocol (HTTP) that return Hypertext Markup Language (HTML), this client software could invoke remote operations in those applications with some other protocol, returning the information using the Extensible Markup Language (XML). In other words, the applications' functions could be accessed as Web services.

Web services allow programmatic access to Web applications

This technology can be used in many ways. For example, Web services could be used to allow desktop or handheld clients to access applications on the Internet, such as reservations systems. Web services can also be used for business-to-business (B2B) integration, connecting applications run by different organizations over the Internet. Web services can potentially be used even for enterprise application integration (EAI), connecting applications run by a single organization over private networks. In all of these cases, the technologies of Web services provide the standard glue between diverse pieces of software.

Web services can be applied in many ways

Making all of this work requires several technologies. First, there must be some way to define standard Web service interfaces. Each interface contains one or more operations, each with parameters, much like the interfaces defined by the Component Object Model (COM) or the Object Management Group's Common Object Request Broker Architecture (CORBA).[2] In .NET, Web service interfaces are usually specified using the Web Services Description Language (WSDL). Defined using XML, WSDL provides a standardized way to specify the operations in an interface, the input and output parameters of those operations, and more. Although it looks quite different, WSDL is functionally similar to the Interface Definition Languages (IDLs) used by COM and CORBA.

[2] To distinguish them from interfaces defined using these earlier technologies, the convention in this book is to show all Web service interfaces as a diamond.

Interfaces to Web services can be defined using WSDL

Once an interface has been defined, some protocol must be used to invoke the operations in that interface and return any results. WSDL doesn't specify any particular protocol, and so various choices exist. By far the most common protocol for invoking Web services is the Simple Object Access Protocol (SOAP). SOAP, which is itself defined using XML, also relies on XML to define a standard format for the data this protocol conveys. Although SOAP messages are most commonly sent on top of HTTP, this isn't required. In fact, SOAP can be used to invoke operations over a message queuing technology such as Microsoft Message Queue (MSMQ), over e-mail systems, or with other protocols.

Web services are most commonly invoked using SOAP

Given a way to describe Web service interfaces and a protocol with which to invoke the operations in those interfaces, the next problem is to let clients find compatible Web services. Universal Description, Discovery, and Integration (UDDI) allows developers of Web service clients to locate the information they need, such as WSDL interfaces, to build clients that can use appropriate Web services. And rather than invent a new technology to access this information, clients use SOAP to read and write the contents of the UDDI database.

Web service interface definitions can be published and accessed via UDDI

Figure 1-1 shows how the core Web services technologies fit together. As the figure shows, a client might access UDDI, which provides its services through a group of interconnected machines acting as UDDI registries, to learn about the Web services it wishes to use. It can then use SOAP to invoke operations in the interfaces those services provide, interfaces that were specified in WSDL. While other options are also possible the client might invoke a Web service with a protocol other than SOAP, for example, or WSDL might not be used to describe all interfaces this diagram shows the typical way in which these mainstream Web services technologies relate to one another.

Figure 1-1. WSDL, SOAP, and UDDI are the core Web services technologies.
graphics/01fig01.gif

Windows application developers have long relied on Windows DNA

Taken together, WSDL, SOAP, and UDDI allow building many kinds of applications. They can also make existing applications more useful by providing a standard approach to connecting them. Chapter 2 describes in more detail how these technologies work and how they can be used.

< 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