If you are already using IIS as your web server and you want to add this security level, all you need to do is to check some check boxes in your web site configuration. In order to accomplish the configuration part you will be asked to provide a certificate.

The certificate (combination of identity and public key) is helping the client to authenticate the server. One of the common examples is your browser, when a user enters a secured web site the browser check its certificate using CA services, and verifies that the server is really who it claims to be.

There are many companies (VeriSign is one of the popular ones) which define the CA (certificate authority) and provide a certification services (it’s my recommendation for public internet applications). If you don’t want to pay money to a third party, you can create a free public certificate using OpenSSL tools, create self-singed certificate using makecert utility (you must remember to protect your private key), or even to build your own CA server (all this three are recommended for intranet applications).

Assume you choose one of the cheap ways, you still need to configure your software to validate the certificate. There are two ways to do it, the first one is using code, and the second by setting the server certificate in the client machine. In order to use a code you need to register to ServicePointManager.ServerCertificateValidationCallback event, this delegate passes the certificate details as a parameter and return whenever the certificate is valid or not. For example:

public void GetData(string url)
{
    using (WebClient webClient = new WebClient())
    using (StreamReader webClientStreamReader =
        new StreamReader(webClient.OpenRead(url), Encoding.UTF8))
    {
        ServicePointManager.ServerCertificateValidationCallback += 
            new RemoteCertificateValidationCallback(customXertificateValidation);
        if (webClientStreamReader != null)
        {
            string returnedStringFromMoma = webClientStreamReader.ReadToEnd();
        }
    }
}
private static bool customXertificateValidation(object sender, X509Certificate cert, X509Chain chain, System.Net.Security.SslPolicyErrors error)
{
    return (cert.Subject == "CN=MyCustomCert, OU=Dev, …");
}

In case you decided to set the server certificate in the client machine, you need to export the certificate from the server, and then to import the certificate into the client machine. You can do the import/export actions from the Windows Certificates manager.

I had another important issue I forget to mention, I know a lot of people which thought the using the request credential is secured, don’t let it to confuse you, the credential is just encoded it’s not encrypted.

I'll explain these two methods for all of those who aren't familiar with them.

Pushing – in this concept, the responsibility to transfer the data is on the server. Each time the server has some new data to publish to the client the server will connect directly to the client and will send it all the relevant data immediately.

Pros:

• Using minimum resources to transfer a message (without extra traffic, network overload and etc)
• The data will be sent and received immediately (without any delay).

Cons:

• Scalability problem: The server needs to be aware for all clients, and which data should be sent for each client.
• Availability problem: The client has high dependency on the server. In a case the server fell down, it'll be very difficult to determining it by the client.
• Reliability and Durability problems: on the other hand, in a case that the client fell down, the server needs to implement a retries mechanism and store the message in some persistence storage, in order to insure the message will be sent successfully and completely to the client.

Pulling – in this method the responsibility for retrieving the data is on the client. The main challenge here is that the client doesn't know when he will need to connect the server in order to retrieve new data from it. In this case the client will need to use some monitoring techniques, every pre-defined interval.

Pros:

• Independency – The client is fully autonomy. Each client only needs to be aware of its server.
• Scalability: this method is fully scalable.

Cons:

• Very "expensive" (using more resources, increase the network traffic, increase the processing time on server and client sides)
• Delay time: the message won't arrived immediately, it'll be sent with a delay.

One of the solutions for this problem is to use publisher-subscriber pattern (aka "pub-sub"). In this pattern we have a third component which call the "pub-sub". Each client will subscribe to the pub-sub to get only messages which is relevant to him. The server will send all the messages to the pub-sub and will publish it to all subscribers' clients. In this pattern the server only need to send one message to one address without to be aware of all client locations.

If we'll return to the question for the beginning, next time you will need to decide which one of them to use, just think about the components architecture, analyze the communication requirements and then do the appropriate choose for your specific design.

1. maxConcurrentCalls [default: 16]:

Refer to the service concurrency mode. In a case we define the service as a multiple concurrency mode, it'll define the number of threads we open in the service to handle requests. But, in a case we define the service as a single concurrency mode the service will ignore this value (because we have only single thread in the service anyway).

Increase this number if your service needs to process large number of requests at the same time

2. maxConcurrentInstances [default: Int32.Max]:

Like the maxConcurrentCalls configuration it depends on other configurations.

If we define the service instance context mode to be Single the service will be ignore this value. In case the instance context mode set to per session, the real sessions number will be the minimum value between the maxConcurrencySessions and maxConcurrancyInstances. In case you define the service instance context mode as per call, it'll limit the number of active service instances. If the maximum number of instances exceeded all, the new requests will be queued.

Increase this number if you are using InstanceConcurrancyMode.PerCall or InstanceConcurrancyMode.PerSession and you have lightweight instances with heavy operations.

3. maxConcurrentSessions [default: 10]:

Refer only to a channel which supports sessions (like TCP) in all combinations of InstanceContextMode and InstanceConcurrencyMode configurations. Limits the number of active sessions in the service. Each time the client creates a new channel to the service it creates a new session in the service side (again, only for supported channels). Only when you close the channel gracefully (or after a timeout in the service side) the session will be released.

Increase this value if you have a lot of open channels to the service (and especially when some of them aren’t been closed gracefully…)

In this case you have three options:

Single – Creates only one service instance in the system.

PerSession (default value) – Create a new service instance per session.

PerCall – Creates a new service instance per call.

The second (ConcurrencyMode) controls how many threads can be run in the service at the same time.

For this configuration we have several options:

Single – Single thread, only one thread in the entire service. You are in thread safe situation; don't worry about protecting your data, synchronization and etc. But in case your service is processing a request, all other request will wait (or failed on request timeout).

Reentrant – This is a tricky one, its means that only one thread can be executed in the service but in case you call to another service the WCF infrastructure will release the lock from it (and then you should protect your service state like in the Multiple mode). You should use it to avoid cases of deadlock when two services with a single concurrency mode are calling each other.

Multiple – Multi-thread, multiple threads can be run on the same time. In most cases you will reduce yours client's timeouts. But remember, this is not a magic solution, high number of thread will cost you in a context switch time (I'll cover the "how to control the number of service active threads" issue in one of my next posts).

Everything sounds simple by now, but the combination between the InstanceContextMode and the ConcurrencyMode is the fascinating part. To clarify this issue I summarized all possible combination in the next table:

– InstanceContextMode and ConcurrencyMode

– Wcf configuration – Throttling settings

In my next posts I decided to focus on some of interesting issues from the architecture design world, like:

– Communication.

– Configuration.

– Performance

– State sharing

and more…

<services>
  <service
      behaviorConfiguration="WcfService.Service1Behavior"
      name="WcfService.ServiceHandler">
    <endpoint
      address="http://localhost:2010/ServiceHandler.svc"
      binding="wsHttpBinding"
      contract="WcfService.ICustomerService">
    </endpoint>
    <endpoint
      address="net.tcp://localhost:2020/ServiceHandler.svc"
      binding="netTcpBinding"
      contract="WcfService.ICustomerService">
    </endpoint>
  </service>
</services>

But our question was: Can we associate more than one contract to a single service?

So we created something like this:

<services>
  <service
      behaviorConfiguration="WcfService.Service1Behavior"
      name="WcfService.ServiceHandler">
    <endpoint
        address="http://localhost:1056/ServiceHandler.svc"
        binding="wsHttpBinding"
        contract="WcfService.IOrderService">
    </endpoint>
    <endpoint
        address="http://localhost:1056/ServiceHandler.svc"
        binding="wsHttpBinding"
        contract="WcfService.ICustomerService">
    </endpoint>
  </service>
</services>

After few tests it worked. Now our service handler class looks like this:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
public class ServiceHandler : IOrderService, ICustomerService
{
    …
}

We added the InstanceServiceMode service behavior attribute with the “Single” value to define only one service handler class instance for the entire service requests. Now we have one service handler class which implements more than one service contract.

According to this idea you can work with inheritance interfaces too, for example assume you have this interface:

[ServiceContract]
public interface ICRM : ICustomerService, IOrderService
{
}

You can easily define only one service and get two in the same price.

I attached a code sample of it.

In the beginning of this month I was in a business trip to Asia to train our technical team members on a new software component we developed in our R&D team. The main goal of this component is to monitor net events and map it to actions. The business user has the ability to creates flows in a web interface and to defines the relevant actions for each event. In our solution we used WCF to communicate between our services, in addition, we used FTP to transfer batch files to our backend server.

You can look on some of my pictures here.

It's very useful to take an enum and bind it into bind-able controls (like drop down list, check box, grid view and etc). For example, if we have an enum which represents bug statuses and you want to bind it into a drop down list.

public enum Bug

{

    Opened = 1,

    Closed = 2,

    Rejected = 3,

    Resolved = 4,

    InProgress = 5

}

In addition, usually in a UI we want to separate between the enum words (for example to change the "InProgress" to "In Progress").

I search over the net and I found some solution but in all of them I needed to extend my current enum (like using attribute in this solution), so I decided to implement one of myself:

public static class EnumHelper

{

    public static IDictionary<string, int> GetList<TEnum>()

    {

        return GetList<TEnum>(false);

    }

    public static IDictionary<string, int> GetList<TEnum>(bool splitString)

    {

        Type type = typeof(TEnum);

        Dictionary<string, int> list = new Dictionary<string, int>();

        Array enumValues = Enum.GetValues(type);

        foreach (Enum value in enumValues)

        {

            int enumValue = Convert.ToInt32(((TEnum)Enum.Parse(type, value.ToString())));

            string sb = (splitString) ? SplitString(value) : value.ToString();

            list.Add(sb, enumValue);

        }

        return list;

    }
    private static string SplitString(Enum value)

    {

        StringBuilder sb = new StringBuilder();

        char[] chars = value.ToString().ToCharArray();
        sb.Append(chars[0]);

        for (int i = 1; i < chars.Length – 1; i++)

        {

            if ((chars[i].ToString() == chars[i].ToString().ToUpper())

                && (chars[i – 1].ToString() != chars[i – 1].ToString().ToUpper()))

            {

                sb.Append(" ");

            }

            sb.Append(chars[i]);

        }

        sb.Append(chars[chars.Length – 1]);

        return sb.ToString();

    }

}

How do we use this code?

In case we just want to bind it without separate between the enum words, it will be like this:

var bugs = EnumHelper.GetList<Bug>();

And in case we want to separate between the words will have something like that:

var bugs = EnumHelper.GetList<Bug>(true);

Challenge:

How do you synchronies between enum (which execute in web/service context) and a table/database context?

For example you have this bug statuses enum and in addition you have a bug table with numeric status column. The status column values are the same enum numeric values. After deployment, in order to understand this column value you must look at the enum that represent it. But in order to do so, you must open your code…