Although the .NET Framework makes web service development easier, it is by no means the only way to create them. Just like any other programming task, there are several design and development decisions that must be made. Remember, web services provide a platform-independent way of requesting and receiving data, so the service consumer doesn't need (or in many cases want) information about how it is implemented. Unfortunately, there are some things to be aware of when interoperability is a concern:
Not all platforms support the same data types. For example, many services return an ADO.NET dataset. A system without .NET will be unlikely to understand this data form. Similarly, arrays can be problematic because they can be represented in any number of ways.
Some services are more tolerant of missing or extra headers in the request. This problem is allied to consumers that do not send all the correct headers, which can create problems, especially when it comes to securing a service.
In an effort to overcome these and other related issues, the Web Services Interoperability Organization was formed. You can find its aims, findings, and conformance recommendations at www.ws-i.org/.
When creating a web service, your first decision is which platform to use. If you choose Windows, you'll almost certainly use IIS as your web server. You can use ASP.NET to create your web services, or ASP for older versions of IIS (though this is more difficult). The examples in this chapter use ASP.NET.
If you are using UNIX or Linux, you will likely be using JSP or PHP, both of which have open source web servers available. Using these, you need to program in Java or PHP, respectively, to create web services.
The Axis project (http://ws.apache.org/axis/) has development tools for both Java and C++.
After you've chosen your language, you'll need to decide who will have access to your service. Will your application be the only one calling it, or will your service be accessible publicly? If the latter, you will need to take into account the interoperability issues discussed previously; if the former, you can take advantage of some of the specialized features provided by the client or the server.
With a web service created, the next step is to consume it. Any application that calls a web service is considered a consumer. Typically, consuming a web service follows a distinct pattern: create a request, send the request, and act on the response received. The exact method for taking these steps is up to the functionality that is accessible by the consumer.