Marshal-by-value remoting (XML Web services) means that you get XML-serialized data from your remote server. Sometimes, you may need dynamic event behavior or you may not want to move massive amounts of data and need a little more control. In this instance, you peel back the XML Web services layer and start building directly on top of .NET Remoting with marshal-by-reference objects and event sinks. Mostly not, though.

This article looks at the basic technologies that support XML Web services and provides a brief demonstration of how to produce and consume Web services.

First Things First

Before learning the definition of XML Web services, take a look at Web services from a conceptual perspective. What is a Web service? I’m glad you asked.

A Web service is a class, but not a low-level class. For example, a Web service might have a method such as AddItemToOrder, BookFlight, or RetrieveDrivingDirections, but a properly used Web service would not include things like SetCustomerName or CalculateAge. A Web service could include low-level operations, but Web services send XML data across an HTTP connection and serializing data and HTTP is not a comparatively cheap operation. Therefore, using Web services to set the equivalent of property values is a misuse of them.

Conceptually, a Web service is a natural façade. The term façade is an important architectural concept that represents high-level, interface-exposing capabilities. In the context of the UML, think of a façade as a Web service that supports use cases. (If you are not familiar with façades, pick up a copy of Erich Gamma and Company’s book Design Patterns from Addison-Wesley.) In the meantime, think of a Web service as a place to expose high-level capabilities instead of low-level operations.

When you decide to use Web services, consider the Web service a provider of the primary use cases (a.k.a. macro features) of your system.

Consuming and Producing Web Services

A programmer can assume either the Web service producer or Web service consumer role. The skills for producing a Web service are slightly different from those for consuming Web services. When creating a Web service, you are a producer and must play that part. Once you’ve created the Web service, you are a consumer. The capabilities the Web service offers represent a black box, and your tasks as consumer are the same whether you produced the Web service or not.

Producing Web Services

The key to producing a useful Web service is knowing your audience. What are their objectives? What do you need from them to help them meet their goals, and what must you have from them to meet your goals?

It is also important to know that Web service consumers are generally not end users. Web services consumers are often business-to-business (b2b) customers. For example, Dell Computers might use Web services from UPS to offer package tracking. Dell Computers might produce Web services to offer financial information to Dell Financial Services. In the former scenario, Dell might ship your new PC (you’re getting a Dell, dude!) via UPS and enable you to track your PC through its Web site. Dell Financial Services (DFS) might offer you credit, and Dell Computers can request payment through DFS’s Web services.

Hopefully, these analogies help you see what a good level of abstractioin for Web services is. Note that XML Web services do not technically enforce any particular level of abstraction; what I am suggesting is a suitable level of abstraction.

Now, how do you produce a Web service?

Page 2: Producing Web Services in VB.NET