Web Services: The New Marketplace

Web Services: The New Marketplace

As we all know, the Internet represents both value and reach for businesses of all sizes by providing opportunities to find new customers, streamline supply chains, provide new services, and secure financial gain. A major impediment has held back the enormous potential of the Internet marketplace to open up trade worldwide. This roadblock is not only in the way of those already conducting business-to-business (B2B) e-commerce but also in the way of businesses that are not yet players in the digital economy. This roadblock is one of design. Most Internet services currently in place take divergent paths to connect buyers, suppliers, marketplaces, and service providers, which means that without large investments in their technology infrastructure, a furniture manufacturer in North Carolina might have a difficult time working with a specialized fittings supplier in Borneo. Also, the furniture manufacturer can only work with global trading partners it knows about, so there has to be a mechanism for the supplier to make its presence widely known. E-commerce participants have not yet agreed on one standard or backbone on which to communicate their services, which makes finding and working with potential trading partners severely limited. This situation, however, is rapidly changing.

What Are Web Services?

In very general terms, ASP.NET pages are for human interaction with a Web server, and Web services are for programmatic interaction with a Web server. Web services are a general model for building applications that can be implemented for any operation that supports communication over the Internet. Web services combine both component-based development models and the Web. Of course, component-based object models such as Distributed Component Object Model (DCOM), Remote Method Invocation (RMI), and Internet Inter-Orb Protocol (IIOP) have been around for some time. The down side of these models is that they depend on a protocol that's particular to the object model. Web services, on the other hand, extend these models a bit further to communicate using SOAP and XML, which essentially eradicates the object model–specific protocol barrier. The nature of a Web service is shown in Figure 13-22.

Figure 13-22

High-level view of the Web service model.

As you can see in the illustration, SOAP calls are remote function calls that invoke code-method executions on Web services components. The output from these methods is rendered as XML and passed back to the user. This magic can be accomplished because Web services basically use text-based HTTP and SOAP to make business data available on the Web. A Web service exposes business objects (such as COM objects, Java Beans, and so on) to SOAP calls over HTTP and then executes remote function calls on their receipt. Consumers of Web services can easily invoke method calls on remote objects using SOAP and HTTP and have their data returned via text-based XML. This is an elegant and compelling scenario.

OK, Now How Do We Communicate?

Let's say that the North Carolina–based furniture manufacturer wants to communicate with the Borneo-based fittings supplier. How does the furniture manufacturer become aware of the semantics required to actually use the fittings supplier's Web service?

This question is easily answered—by conforming to a common standard. A few of these standards are the Service Description Language (SDL), SOAP Contract Language (SCL), and Network Accessible Service Specification Language (NASSL), which are XML-like languages built to facilitate communication between a client and a server. IBM and Microsoft, however, recently agreed on the Web Services Description Language (WSDL) as a Web service standard. Therefore, in order to dynamically communicate, each Web service exposes the structure of its components using WSDL.

WSDL is a general-purpose XML language for describing the interface, protocol bindings, and deployment details of network services. WSDL defines XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and automate the details involved in communications between applications. Like XML, WSDL is extensible to allow the description of endpoints and their messages, regardless of what message formats or network protocols are used to communicate. WSDL can be used to design specifications to invoke and operate Web services on the Internet and to access and invoke remote applications and databases.

Visual Basic .NET makes it easy to create Web services with components that communicate using HTTP GET, HTTP POST, and SOAP. Consumers of a Web service don't need to know anything about the platform, object model, or programming language used to implement the service. Consumers only need to understand how to send and receive SOAP messages (HTTP and XML).

The decentralized nature of Web services enables both the client and the Web service to function as autonomous units. This provides limitless ways to consume a Web service—for example, a call to a Web service that might be included in your Web application, or from a middleware component, or even from another Web service, as in our furniture supplier example.

Finding Out Who Is Offering What in the Global Marketplace

To address the problems of finding what Web services are out there and how to communicate to them, a group of technology and business leaders have come together to develop the Universal Discovery, Description, and Integration (UDDI) specification. The UDDI service is an industry-wide effort to bring a common standard to B2B integration. It defines a set of standard interfaces for accessing a database of Web services. This initiative creates a platform-independent, open framework to enable businesses to accomplish several goals at once. The UDDI data structure provides a framework for the description of basic business and service information and also architects an extensible mechanism to provide detailed service access information.

• Businesses can discover each other.

• The definition of how businesses interact over the Internet is defined.

• Businesses can easily share information in a global registry.

UDDI is the name of a group of Web-based registries that expose information about a business or other entity and its technical interfaces (APIs). This way, UDDI provides a way for businesses to publish information about their own services as well as find services they need from other businesses.

The UDDI specifications take advantage of World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) standards such as XML, HTTP, and Domain Name System (DNS) protocols. Also, cross-platform programming features are addressed by adopting early versions of the SOAP messaging specifications found at the W3C Web site. There are three steps in how the UDDI works:

1. Software companies, standards bodies, and programmers populate the registry with descriptions of different types of services they support.

2. The UDDI Business Registry assigns a programmatically unique identifier to each service and business registration.

3. Marketplaces, search engines, and business applications query the registry to discover services at other companies.

Conceptually, the information provided in a UDDI business registration consists of three components. There are the "white pages," which include the business address, contact, and known identifiers. Next are the "yellow pages," which include industrial categorizations. And finally there are the "green pages," which contain technical information about services that are exposed by the business.

As you might guess, it's the green pages that allow us to automatically discover how to use the service because they include references to specifications for the Web services as well as support for pointers to various file and URL-based discovery mechanisms—if required.

Once a Web service is found, there must be a mechanism to determine exactly what methods (essentially that service's API) it exposes. For example, a client needs to know that the service has a method named getProductDescription that takes a long and returns a string. The client can accomplish this task using the WSDL, which is conceptually similar to a COM type library. Using WSDL, a C++ or Java client can understand the parameters of the getProductDescription API and build the correct SOAP message to invoke the service. Essentially, WSDL is a specification for using XML schemas to fully describe the service's API.

The third Web service standard is the use of XML schema definition language (XSD). XSD defines a pretty large set of data types that should cover most application's needs. The standard data types ensure that the data passed between service and client, such as integers and dates, are interpreted and laid out in memory the same way on each side. However, if absolutely necessary, XSD permits you to define your own data types when required. Since XSD is used, both the client and the service can agree on what is a string, a long, and so on.

The vocabulary surrounding Web services is that a Web service provides services by exposing its API while a client consumes those services, as shown in Figure 13-23. So a client first finds out about a service from UDDI, then uses WSDL to determine how to communicate with the service, and then contacts the service.

Figure 13-23

How a client discovers and communicates with a Web service.

Where Are Web Services Going?

Web services are quickly becoming the programmatic backbone for electronic commerce. In Chapter 1, "Visual Basic .NET from the Ground Up," I referred to a fictitious Web service that calculates arbitrage rates for cross-currency wire transfers. Another example is where one company calls another's Web service to send a purchase order directly via an Internet connection. Another service might be one that calculates the cost of shipping a package of a certain size or weight over so many miles via a specific carrier.

The future looks bright for Web service technology developed with Visual Basic .NET. However, Microsoft is not alone in the race for Web services technology. Both Sun and IBM are also very interested. In addition, SOAP toolkits are available for Apache and Java Web servers. Although the discovery process is still in the embryonic stages, Web services have the potential to introduce new concepts to the Internet. For example, it would be easy to construct Web sites that generate revenue for each request serviced to a user. This micro-billing would charge by use, not by a flat monthly fee. It's easy to see how searches on sites for periodical publications might charge $1.50 to view any article over 5 years old.

In Chapter 1, I touched on federations of Web services, a situation in which my Web service might call on another Web service to provide value. For example, if my Web service sends foreign denominated wire transfers, behind the scenes I might call on one Web service to validate the user and another to provide the real-time currency exchange rates. By using others' services, my service can concentrate on formatting the instructions correctly and efficiently to send the wire instruction to the Federal Reserve or S.W.I.F.T. When looked at in this light, Web services can be described as the "plug and play" building blocks of B2B Web solutions.