SOA Best Practices - Performance and Security

Services should be structured, designed with security in mind. Security includes service security, transport security and message security. However, Security measures introduce some overhead. So, the performance trade-offs need to be measured carefully. 

1. Avoid transmitting large amount of data between your service and service consumers.

• Accelerator technologies, such as compression, may also be able to effectively reduce some of the processing load.
• Send subsets of data if consumer requested large amount of data.

2. For maximum security, consider using transport layer security and message-based security.

• Message-based security such as XML-Encryption and XML-Digital signatures does not encrypt the headers information. You need to use transport layer security (SSL) if you want to encrypt message headers. 
• Many security measures introduce processing overhead, so the performance trade-offs that need to be measured carefully. 

3. If you need to call multiple services consider calling those services parallel. 

• Calling multiple services sequentially reduce the overall performance of your service. Consider using Parallel Activity workflow of Windows Workflow Foundation 4.0 to call multiple services parallel. 

SOA Best Practices - Developing and Deploying a Service

Web services open the door to new integration opportunities and the quality of the interface they expose is very important. For example, changing an interface after it has been deployed can be a costly and messy task. So, it is very important to pay attention to reliability, quality and extensibility of the service. These are some of the points you can consider when designing and developing a service.

1. Operation and data contracts should be designed in such a way that if possible, you can extend them without affecting existing consumers of the service.

• If the existing contracts cannot be extended, consider developing a different service for new business requirements or new service clients. 
• It is very important to make sure that the service consumers are not blocked from using your service after modifying or adding new functionality to your service. This ensures the quality and reliability of your service. 

2. Design against an Interface not vice versa. Design the service interface first rather than building application logics and then expressing that functionality through an appropriate service interface.

• If you design interfaces first and know the purpose of those interfaces, it is easy to start writing business functionalities under it. This also ensures the consistency and reusability of service interface design. 

3. Implement validation logic to check all input based on value, range and type; and reject all invalid data. 

• If your service consumers call your service with invalid requests, your service may fail to respond or throw an exception inside your business logics and it may very difficult to debug the issue. 
• If you do not capture invalid inputs and notify the service consumers for the service failure, your service consumers may not know the reason why they did not get a valid response. 

4. Expose your WCF service both with basicHttpBinding and wsHttpBinding so that wide range of clients can consume it.

• Non .NET/legacy clients only able to consume your service using basicHttpBinding. 

5. Try to use request objects instead of passing multiple parameters.

• Having multiple parameters can make it hard to maintain your service and it is also hard for your service consumers to call your service. 

6. Returns an appropriate sized subset of the data rather than returning large amount of the data in one call.

• It can result in service timeout and also can frustrate the consumers of your service due to latency of the response. 

7. Use a meaningful, business specific name as the service name.

• Consumers of your service should be able to easily recognize your service based on its main business functionality. 
• Consistent naming convention helps service consumers to easily recognize your service. 
• A consistent set of services that cleanly establishes the level of clarity between the services enables easier interoperability and reuse. 

8. If possible, always publish the service to UDDI, so the service consumers can access the service by service name.

• If the consumers of your service are not calling your service using UDDI service name, your consumers may not able to access your service in case the host of your service or the name of your service is changed.

WCF 4.0 new feature - Default Endpoints

WCF 3.x services required at least one endpoint or you'd get an exception.
WCF 4.0 comes with default endpoints. Windows Communication Foundation (WCF) looks at the configured mappings and decides on which binding to use for a particular based address.
If you have defined at least one endpoint, you won't get default endpoints.

WCF defines a default protocol mapping between transport protocol schemes (e.g., http, net.tcp, net.pipe, etc) and the built-in WCF bindings. The default protocol mapping is found in the .NET 4 machine.config.comments file and it looks like this:

<protocolMapping>
    <add scheme="http" binding="basicHttpBinding"/>
    <add scheme="net.tcp" binding="netTcpBinding"/>
    <add scheme="net.pipe" binding="netNamedPipeBinding"/>
    <add scheme="net.msmq" binding="netMsmqBinding"/>
</protocolMapping>

Method Overloading in ASMX and WCF services

Both ASMX and WCF services do not support method overloading by default. However, it is possible to enable method overloading with ASMX or WCF service by decorating a ASMX web method or a WCF method as follows.

In ASMX:

[WebMethod (MessageName="HelloWorld")]
public string HelloWorld()
{
   return "HelloWorld";
}

[WebMethod (MessageName="HelloWorldWithName")]
public string HelloWorld(string name)
{
   return "HelloWorld " + name;
}

In WCF:

[ServiceContract]
public interface IMyCalculator
{
[OperationContract(Name="AddFloats")]
float Add(float operand1, float operand2);

[OperationContract(Name="AddIntegers")]
int Add(int operand1,int operand2);
}

How to enable WCF Tracing?

Tracing is not enabled by default. Trace source should be defined in the assembly level. The System.ServiceModel and System.ServiceModel.MessageLogging are the most important and frequently used WCF trace sources.

For each trace source trace listener should be defined. You can configure tracing by editing the web.config for web-hosted applications, or Appname.exe.config for self-hosted applications.

<configuration>
  <system.diagnostics>
   <sources>
    <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
    <listeners>
   <add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\log\Traces.svclog" />
    </listeners>
   </source>
  </sources>
</system.diagnostics>
</configuration>

You can also configure each trace source to use the same shared listener, as shown below.

<configuration>
  <system.diagnostics>
   <sources>
    <source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
     <listeners>
      <add name="xml" />
       </listeners>
        </source>
         <source name="CardSpace">
       <listeners>
     <add name="xml" />
   </listeners>
</source>
<source name="System.IO.Log">
<listeners>
   <add name="xml" />
     </listeners>
      </source>
       <source name="System.Runtime.Serialization">
     <listeners>
    <add name="xml" />
</listeners>
   </source>
      <source name="System.IdentityModel">
       <listeners>
          <add name="xml" />
       </listeners>
   </source>
</sources>

<sharedListeners>
<add name="xml"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\log\Traces.svclog" />
</sharedListeners>
</system.diagnostics>
</configuration>