There are a number of issues that must be considered to ensure that efficient Web services are created and a number of decisions that must be made at design time. The major considerations are summarized below:

Design Chunky Interfaces to Reduce Round Trips
Design chunky interfaces by exposing Web methods that allow your clients to perform single logical operations by calling a single Web method. Avoid exposing properties and instead provide methods that accept multiple parameters to reduce roundtrips.

Prefer Primitive Types for Web Service Parameters
There are two broad categories of parameter types that you can pass to Web services:

• Strongly typed: This includes .NET types such as double, int, DataSet and custom objects such as Employee, Person and so on. The advantage of using strongly typed parameters is that .NET automatically generates the schema for these types and validates the incoming values for you. Clients use the schema to construct appropriately formatted XML messages before sending them.
• Loosely typed: These parameters use the string type. Loosely typed parameters are beneficial for interoperability. For example, you can place an XML document containing a business document in the string parameter. The client needs to take care of serializing the data to XML before passing it to the Web service. The Web service implementation must develop custom validation code to validate the incoming message in addition to the de-serialization process. The advantages of loosely typed parameters include good interoperability support, avoiding certain versioning issues because even if the expected schema changes, the message is still wrapped in a single parameter.

Regardless of which encoding style you use, you should prefer simple primitive types like int, double, and string for Web service parameters. Use of primitive types leads to reduced serialization, automatic and efficient validation by the .NET Framework.

Prefer the Message-Style Design for Your Web Service
There are two styles of invocation for a Web service – RPC or messaging. The choice radically impacts the way the Web service interface is designed.

The RPC style model is based on objects and methods. We pass parameters and expect an output. This style relies on a synchronous programming model of making a request and waiting for a response. The SOAP-RPC style encoding for Web services maps to the RPC style invocation. If you are designing for RPC style invocation then use the RPC-literal encoding style for greater efficiency. An example of a Web method which is designed for RPC invocation is shown below:
MyMethod1(Employee e)
MyMethod2(int a, string b)
The message-style model is data-centric in nature. The client prepares and sends XML to the Web service without requiring the data to have an object representation. The XML can be any message payload that is appropriately defined by the schema specified for the request. The client can use asynchronous communication and does not immediately expect the response and can continue executing. The message serves as a data contract between the Web service and its clients. The SOAP-Document style encoding is used for designing messaging-style invocations. An example of a Web method which follows this design is shown below:

// Client
string myString = “<mything>thing</mything>”;
MyMethod(myString);

//server
[WebMethod]
void MyMethod(string myString){ . . . }

The message can be encapsulated in a simple string type or in an XmlElement. Some of the advantages of using message-style invocation include:

• it supports asynchronous invocation.
• The SOAP-Document style encoding involves less XML marshalling of data over the wire in comparison to SOAP-RPC encoding.
• The schema serves as a data-contract between the client and the server and can easily be changed without creating multiple versions of the same method. This is because any XML message can be passed as a single parameter as a string.
• Validation of the complete incoming message at the server is possible by using a schema. This helps you avoid costly redundant processing if the inbound message is invalid.
• Because the message-style model requires sending a prepared XML string to the Web service, you can use your own serialization mechanism for improved efficiency rather than depending upon XmlSerializer.

Approaches to Caching
Web service performance can be enhanced greatly by caching data. With ASP.NET Web services, you can use many of the same caching features that are available to ASP.NET Web applications. These include ASP.NET output caching, HTTP response caching and ASP.NET application caching.

In common with any caching solution, the caching design for a Web service must consider issues such as how frequently the cached data needs to be updated, whether or not the data is user specific or application wide, what mechanism to use to indicate that the cache needs updating and so on.

Caching is a great way to improve Web service performance. By reducing the average request time and easing server load, caching also helps scalability.
Caching can be done for frequently used data applicable to all users or can cache SOAP response output.

Validate Input before Processing It
Validating input early avoids unnecessary server-side processing if the input is invalid for example because it does not adhere to the correct schema. Input data can be validated either by using SoapExtensions or by using separate internal helper methods that Web methods call. The advantage using SoapExtension is that it enables us to separate your validation code from the business logic. If there is any schema change in the future the extension can change independently of the Web method.

Avoid Maintaining State between Calls
Avoid maintaining state between multiple Web service calls from the same client. To maintain state across calls you need to use session state. This might be in-process state, state maintained in a separate state service process or in a database. In each case, additional resources and processing is required. To avoid maintaining state on the server, consider passing any required state to and from the client.

Avoid Calling Local Web Services
Web services located on the same machine as a client ASP.NET application share the same thread pool with the ASP.NET application. Hence the client application and the Web service share the same threads and other related resources such as CPU for request processing.

In addition, the maxConnection attribute Machine.config has no affect on the connection limit for making calls to local Web services. Hence local Web services always tend to give preference to the requests coming from the local machine over and above the requests coming from different machines. This degrades the throughput of the Web service for remote clients.