Request-Response messaging via Queues, Web services and SOA technologies

The topic is an old debate in the software industry, we have been listening to SOA experts to use modern technologies like web services, SOA middleware products while from an archaic we would listen terms like queues, reliable messaging etc.

This post will try to differentiate between these concepts, their advantages and disadvantages and probably bridge the generation gap of messaging.

Today web services are widely used due to SOAP, WS Messaging and WSS Security protocol standards. They also tend to provide synchronous mode of messaging communication between the client and the server. Almost of the modern technologies and vendors can call and consume web services easily.

Although web services have an advantage of having synchronous communication and easier way to be consumed they lack asynchronous and one way messaging. I am not sure about other technologies but WCF has a one-way asynchronous communication mechanism.

However in online transactions synchronous request-response messaging is essential and usage of web services is inevitable. Due to asynchronous processing nature of queues they should be avoided. Queues do have a request-response pattern as given below but the latency, client implementation of session management and reliability management (handshakes of messages) is an overhead.

In this post we will briefly look at request-response synchronous messaging via Queues and SOA technologies. I hope the conclusion would be interesting.

Reliability, atomicity and retry submit messages in

Web services

Reliability, retrying mechanism and atomicity is not possible in web services since they tend to be synchronous and stateless in nature. Once the request is processed there is no record of the message. This can be fragile and the messages can get lost. For example if the host process is restarted or got crashed and the messages were in-flight and were being processed by the web services. The transaction in the web services will be inconsistent in this case.


There are a lot of vendors for queues (JBOSS A-MQ, active MQ, RabbitMQ, ZeroMQ etc)  but we’ll focus on MSMQ, IBM MQ Series and JMS queues request-response pattern. All of the queue technologies expose APIs where clients can access the queues and put messages in the queues for processing. This requires clients to handle session states, implement reliability mechanism by checking ACK/NAK messages etc. The advantages and disadvantages of queues are same regardless of different vendors and technologies. The queues can be transactional, allows messages to persist and retrying of message processing can be implemented.

The queues can be of two types.

1- Point-to-point: It means that each queue will be connected to only one subscriber/destination.

2- Publish-subscribe: It means that a queue can be connected to multiple subscribers but the publisher has to publish the message by topic and each subscriber gets the copy of message.

IBM MQ Series

IBM MQ Series is a system/Message Oriented middleware (MOM) in which applications can talk to each other via queues. In the scenario below SOAP messages can also be exchanged between the applications and for application A it is a request-response pattern. In the below the same queue can also be used if the applications and queues use the publish-subscribe model.



MQ Series: Request response pattern

WCF- Reliable messaging via MSMQ

WCF offers the capability of reliable messaging via WS-RM protocol. It uses reliable sessions and MSMQ to queue messages. The disadvantage is latency, session state handling from client application and queues communication which is a different implementation from a client application than just calling a SOAP web service. However it will serve the purpose of reliability (messages are persisted) and retrying. The following figure illustrates the structure of a WCF service and client using MSMQ as a transport.


Queued Application Diagram

WCF service and client using MSMQ as a transport

JMS Request-Response messaging via Queues

I will not go deep into JMS architecture and capabilities you can read here for more information. I am focusing on request/response synchronous pattern implementation via Queues.

In the below diagram you can see that the publisher has to put message in the queue. The advantage is reliability but it comes at the cost of latency.

A publisher sends a message to two subscribers via a
topic destination and receives replies via a queue. Figure is explained in

JMS Request-Response pattern with publish/subscribe model

SOA products:

There are a number of SOA products in the market worth to mention is IBM Message broker, Oracle middleware fusion, TIBCO and Microsoft BizTalk Server. This genes of messaging system has a different set of features than the classical queuing systems like Orchestrations, Business Rules Engines, Business Activity Monitoring, Enterprise Service Bus, Dynamic Routing, Transformation and Error Recovery capabilities. They are far more capable than the classical queues.

In this post we are looking at the request-response message pattern between web services, queues and SOA products. We are concerned about how the message flows between these three set of message processing and their reliability, resilience, error recovery, retrying and atomicity. Lets take a look how message flows between SOA products in request-response pattern then we can compare with Queues and Web services. The message flow is same in all the SOA products we’ll look at the message flow in BizTalk server.


BizTalk Server messaging architecture

SOAP Request-Response Message flow along with an extra File message processing

In BizTalk server the client requests a SOAP message which is accepted by the receive location and then published into the Message Box. The subscribers (orchestrations or send ports) picks up the message. If there are multiple subscribers they will get a copy of the message.

If the subscriber is orchestration it will be the processing unit of the message. Orchestrations has persistence points so the state of the transaction will also be persisted to the store. When the orchestration has finished processing it will again publish the message to the database to be picked up by another subscriber. In SOAP request-response pattern it will be routed back to the receive location.

If the subscriber is a send port then the message is probably meant to be sent to another system outside the middleware server. If there is any transmission failure in the message it will be stored in the message box awaiting for actions to be taken (retry submission or suspend).





In all the SOA technologies a persistence data store is present like an Oracle, SQL database or file. This guarantees reliability of the messages and messages never gets lost within the engine since it is persisted to and from memory to data store.

The data store are used as a single queue while the model is the same publish/subscribe where the publisher publishes the message to the data store and relevant subscribers pick the message for processing. In SOA products publishers are receive locations (SOAP, File) and subscribers can be orchestrations (business processing units) or Send Ports (output from the middleware system). It can be a file a destination system or even another orchestration.

Advantages over queues & web services:

The use of publish/subscribe model in analogous to the publish/subscribe model in queues. The advantage is that the clients can just call SOAP messages and the queue and session handling is abstract.


The SOA technologies implement transactions (Long running/Atomic) which leverages persistence capability by which transactions can recover or resume from their last state in case of a server crash, restart or operating system process failure.

Advantages over queues & web services:

The state of the orchestration is persisted in the store and the transaction state can be retrieved and appropriate actions can be taken. Web services & queues lack this feature.

Retrying/Resubmission of messages

SOA technologies can resume the transactions from the last persisted state or even the message can be retried from beginning since it is persisted in the store.

Advantages over queues & web services:

Queues can retry the message since the message when received is stored however the state of the transaction is not stored since the subscriber will be processing the message which is disjoint from the queue. Web services lack retrying and resubmission of messages.

Using Windows Server AppFabric Caching for Storing SSO & Configuration data

Storing SSO data in cache can be very useful in a low latency scenario. Performance of services can also be improved by caching configuration data such as a Status Codes table (which has business level exception status codes and descriptions).

Using cache in SOA and BPM solutions is not new neither storing SSO data in the cache. You can read Using SSO Efficiently in the Service Oriented Solution and Business Process Management Solution.

Problems with Enterprise Library Caching:

Before AppFabric we could use Enterprise Library caching which had scalability and synchronization problems which means that it was a single server in memory cache which would not be an option with BizTalk running in a Farm and it would cause inconsistency. The other problem is in-process residing of cache in BizTalk Host instances. If the host instances are restarted it means that the cache would load again and causing the cache to populate. The other problem would be if there was a change in the source data the cache would have to be refreshed either by the time interval specified or by enforcement by restarting the host instances. Restarting the host instance can be a heavy operation for the services running and is not an option in production environment. If the cache would be refreshed after a specific time interval it is fine for a single server but in a multi-server environment it can create inconsistency of data for a specific period of time. Consider the refresh interval is 5 minutes on both servers. On Server A the cache will be refreshed after 3 minutes but on Server B it will be after 15 Seconds. In this scenario Server A will be running with the old data for 3 minutes. Windows Server AppFabric has solved this issue and now we can leverage with the features of the technology and incorporate it with BizTalk.

Windows AppFabric Cache features and advantages:

The best would be to go through this article to have an understanding of the architecture and benefits of the caching features. Here is an excerpt of features from this article.

  • Caches any serializable CLR object and provides access through simple cache APIs.
  • Supports enterprise scale: tens to hundreds of computers.
  • Configurable to run as a service accessed over the network
  • Supports dynamic scaling-out by adding new nodes.
  • Backup copy provides high availability.
  • Automatic load balancing.
  • Integration with administration and monitoring tools such as PowerShell, Event Tracing for Windows, System Center, etc.
  • Provides seamless integration with ASP.NET to be able to cache session data in without having to write it to source databases. It can also be used as a cache for application data to be able to cache application data across the entire Web farm.
  • Follows the cache-aside architecture (also known as Explicit Caching) for V1. That is, you must decide explicitly which objects to put/remove in your applications and the cache does not synchronize with any source database automatically.

Let’s see now how the problems of previous caching techniques can be solved by Windows AppFabric. For this first we need to understand our requirements because there are a lot of variations of AppFabric caching host and client. You need to analyze which caching hosting options would fit into your scenario and what client you would be writing for your caching. The overview of them is given below.

Windows AppFabric Host Configurations:

On one or more servers the AppFabric Cache service will be running as a Windows service. The servers should be clustered and when using with BizTalk I would install and configure AppFabric on all of my BizTalk Server machines and configure the Cache Cluster. Of course if you have a shortage of servers like us Smile  then you have to use the existing BizTalk servers but if you can make dedicated cache servers for large cache data you can.

In BizTalk as we will not be storing services data but only SSO data and some configuration data which we get from a Sharepoint List then configuring the existing BizTalk Server clusters for AppFabric caching is a good idea.

You have to follow the installation and configuration guide on how to make a cluster and where to store the configuration data of the cluster. The configuration data can be stored in XML file stored on a shared folder or in SQL Server database I have chosen the latter one. Here is the physical architecture diagram of a cache cluster.


1- Partitioned Cache:

I will be assuming that you are familiar with the logical hierarchy of the AppFabric cache. If the caching is configured on a cluster of servers and named cache is defined on each of the servers then the regions can be distributed among the servers and therefore providing availability or scalability.

a) Scalability:

The cache item would reside in one of the regions of the cache and that region can reside on any one of the cache cluster node. The region is guaranteed to reside on one server and the partition cannot be further distributed among the cluster. Therefore all the items residing in one region will reside in one cluster node. Defining region is optional when you add an item to the cache therefore the cache service itself will load balance the region and assign keys to the regions it has created internally on any server. There is a routing layer on the cache level which routes the put and get operations to the relevant cluster node having the key.

b) Availability:

In the availability scenario the cluster nodes can be defined as secondary and one node can be the primary node thus all the nodes having a copy of the cache items. If the primary node fails when a put or get operation is called for the cache one of the secondary nodes becomes the primary node and the applications continue accessing the cache.

It doesn’t matter on which node the get and put operations are called the routing layer of the cache determines the primary node and routes the request to it. The primary node is responsible for the synchronization of data as the data is updated in this node. When the item is accessed or updated it updates itself and then sends the operation to all the secondary nodes to update themselves. It then waits for an acknowledgment from the secondary nodes. When the acknowledgments are received from each node it then sends the acknowledgment of success of operation back to the client.

2- Local Cache:

If there is no need for availability and scalability the local cache host can be configured just as on my development machine I will have a local cache. This will have the cache in one server therefore will be fast as there will be no network hops and deserialization of data. For this when configuring the AppFabric you will have the new AppFabric cluster without having any other nodes joined with them. For making a multi-server cluster you can install AppFabric on another machine and cluster by selecting the Join Existing Cluster option in the configuration wizard and apply the appropriate settings. It still depends upon the client on which server it is accessing cache.

AppFabric Cache Clients:

There are two types of clients that can be configured in AppFabric.

1- Routing Client:

The routing client will have its own mechanism to keep track and management of the cached objects. It should know on which server the region resides and which key is placed in which region. We will not be using this in the middleware since we are just storing the SSO and Configuration data in the cache but it can be used by services or mainly by web applications depending upon the requirements.

2- Simple Client:

The Simple client is not aware about the locations of regions in the cluster. Therefore they just try to access the object in the cache in their respective region (if they are using regions). The cache routing mechanism itself takes care of routing but it depends if the cache cluster is configured for Scalability or Availability. Their routing mechanism is defined above in the host configurations section.


After having some basic concepts about architecture, usage and advantages I am using the AppFabric cache with the Local Cache host configuration and a base client.

For the host you have to install AppFabric and configure the AppFabric caching services. The first configuration would be to store the configuration (which is SQL Database in my case can be a shared XML File). Second configuration would be to add to an existing cluster or to create a new one. I will have another blog post for this but it’s pretty simple and one can follow the AF installation and configuration.

Now it’s time to write the client which would be BizTalk. We have a Common project which is referenced by each service for using common functionality like to read the configuration data/getting status code etc. Therefore in the same common project I will be writing the client code. I have provided the sample for download in the widget which is free from our organization helper functions so it can be used on a BizTalk machine having SSO and Caching configured.

The client can have the configurations in a configuration file or have the configurations programmatically. I will be using a configuration file and will not require recompiling when changing hosting environments. These settings can be stored into machine.config or BTSNTSvc.exe.config. I will not be explaining the configuration file as it is self explanatory with comments. Feel free to copy and modify it according to your needs as it has all the configuration sections with all the parameters.

<?xml version="1.0" encoding="utf-8" ?> <configuration> <!--configSections must be the FIRST element --> <configSections> <!-- required to read the <dataCacheClient> element --> <!-- Cache Client Setting 1- Client time-out (milliseconds) The requestTimeout attribute in the dataCacheClient element. We do not recommend specifying a value less than 10000 (10 seconds). Default value is 15000. 2- Channel open time-out (milliseconds) The channelOpenTimeout attribute in the dataCacheClient element. This value can be set to 0 in order to immediately handle any network problems. For more information, see Configuring Cache Client Timeouts (Windows Server AppFabric Caching). The default value is 3000. 3- Maximum number of connections to the server The maxConnectionsToServer attribute in the dataCacheClient element. The default value is 1. --> <section name="dataCacheClient" type="Microsoft.ApplicationServer.Caching.DataCacheClientSection, Microsoft.ApplicationServer.Caching.Core, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" allowLocation="true" allowDefinition="Everywhere"/> </configSections> <dataCacheClient> <!-- (optional) specify local cache Remove in a multi-server farm --> <!-- Local Cache Settings 1- Local cache enabled The isEnabled attribute in the localCache element. Values may be true or false. The localCache element may also be missing to indicate that it is disabled. 2- Local cache invalidation method The sync attribute in the localCache element. Use the TimeoutBased value to indicate a time-out value should be used. Use NotificationBased to indicate cache notifications should also be used. 3- Local cache time-out (seconds) The ttlValue attribute in the localCache element. 4- Specific cache notifications poll interval (seconds) (optional) Specified by the pollInterval attribute of the clientNotification element. The clientNotification element is a child of the dataCacheClient element, and not a child of the localCache element. If not specified, a value of 300 seconds will be used. 5- Maximum locally-cached object count (optional) Specified by the objectCount attribute in the localCache element. Triggers when eviction on the local cache should start; it will then attempt to remove 20 percent of the least recently used locally cached objects. If not specified, the default value of 10,000 objects is used. The ObjectCount --> <localCache isEnabled="true" sync="TimeoutBased" objectCount="100000" ttlValue="3000" /> <!--(optional) specify cache notifications poll interval --> <!-- Client Notification Settings 1- Specific cache notifications poll interval (seconds) Specified by the pollInterval attribute of the clientNotification element. If not specified, a value of 300 seconds will be used. 2- Maximum queue length The maxQueueLength attribute of the clientNotification element. If not specified, the default value is 10000. --> <!-- <clientNotification pollInterval="300" /> --> <hosts> <!-- Cache Host Settings 1- Cache server name The name attribute of the host element. 2- Cache port number The cachePort attribute of the host element. --> <host name="D001MWWS3" cachePort="22233"/> <!-- In a Mult-Server Environment add the second Server OR More for caching <host name="CacheServer2" cachePort="22233"/> --> <!-- Security Settings 1- Mode The mode attribute of the securityProperties element. Possible values include Transport and None. The default value is Transport. 2- Protection level The protectionLevel attribute of the securityProperties element. Possible values include None, Sign, and EncryptAndSign. The default value is EncryptAndSign. --> <!-- <securityProperties mode="Transport" protectionLevel="EncryptAndSign" /> --> <!-- Transport Settings Connection buffer size (bytes) The connectionBufferSize attribute of the transportProperties element. The ConnectionBufferSize property of the DataCacheTransportProperties class. This is then assigned to the TransportProperties property of the DataCacheFactoryConfiguration class. Maximum buffer pool size (bytes) The maxBufferPoolSize attribute of the transportProperties element. The MaxBufferPoolSize property of the DataCacheTransportProperties class. Maximum buffer size (bytes) The maxBufferSize attribute of the transportProperties element. The MaxBufferSize property of the DataCacheTransportProperties class. Maximum output delay (milliseconds) The maxOutputDelay attribute of the transportProperties element. The MaxOutputDelay property of the DataCacheTransportProperties class. Channel initialization timeout (milliseconds) The channelInitializationTimeout attribute of the transportProperties element. The ChannelInitializationTimeout property of the DataCacheTransportProperties class. Receive timeout (milliseconds) The receiveTimeout attribute of the transportProperties element. The ReceiveTimeout property of the DataCacheTransportProperties class. --> <!-- <transportProperties connectionBufferSize="131072" maxBufferPoolSize="268435456" maxBufferSize="8388608" maxOutputDelay="2" channelInitializationTimeout="60000" receiveTimeout="600000"/> --> </hosts> </dataCacheClient> </configuration>

Get all the data from SSO:

The below code snippet of the function retrieves all the keys from all applications from SSO. I have used it in the CacheManager project where you can find it in the SSOConfigManager class.

/// <summary> /// Returns list of applications in SSO database. /// </summary> /// <returns>Dictionary of application name as key and description as value.</returns> public static IDictionary<string, string> GetApplications() { ISSOMapper ssoMapper = new ISSOMapper(); AffiliateApplicationType appTypes = AffiliateApplicationType.ConfigStore; IPropertyBag propBag = (IPropertyBag)ssoMapper; uint appFilterFlagMask = SSOFlag.SSO_FLAG_APP_FILTER_BY_TYPE; uint appFilterFlags = (uint)appTypes; object appFilterFlagsObj = (object)appFilterFlags; object appFilterFlagMaskObj = (object)appFilterFlagMask; propBag.Write("AppFilterFlags", ref appFilterFlagsObj); propBag.Write("AppFilterFlagMask", ref appFilterFlagMaskObj); string[] apps = null; string[] descs = null; string[] contacts = null; ssoMapper.GetApplications(out apps, out descs, out contacts); Dictionary<string, string> dict1 = new Dictionary<string, string>(apps.Length); for (int i = 0; i < apps.Length; ++i) { if (!apps[i].StartsWith("{")) dict1.Add(apps[i], descs[i]); } return dict1; }

Creating and managing cache:

Before we perform operations on the cache we have to make sure the cache we are going to use is created. There are some power shell command lines for the administration of AppFabric Cache. There is also a useful GUI based tool for cache management. I would recommend downloading it in case the UAT and Production server administrator is not you. I would continue with both power shell command lines and the tools.

1- Create the cache:

There is always a Default cache which you don’t need to create. I am creating a cache named MWConfigurationCache for storing my middleware configuration data by running the New-Cache command. You can then run the Get-CacheClusterHealth command to see its health.


2- Management:

Some commands will be handy during development. For a full list refer to AppFabric Caching Deployment and Management Guide.

1-  First is the Get-CacheStatistics from which you can see how many items, regions and request are being made to the cache. You can also see the cache size in bytes.


2- The Get-CacheConfig command which gives the following output.


Setting Description
CacheName The name of the cache.
TimeToLive The default time that items reside in the cache before expiring.
CacheType The type of cache. This is always Partitioned.
Secondaries A value of 1 indicates that the cache uses the high availability feature.
IsExpirable Indicates whether objects in the cache can expire.
EvictionType Specifies an eviction type of Least-Recently-Used (LRU) or None.
NotificationsEnabled Indicates whether notifications are enabled for this cache.

3- You can see all the cache that exists on the cluster by Get-Cache command.


4- Stop and Start the cluster from Stop-CacheCluster and Start-CacheCluster commands respectively.



Note: Starting and Stopping the cluster clears the cache here is the sequence of commands first we can see from the stats that the cache has 3 items after stopping and starting the cache has no items. This can be useful when your source item has been updated and you want to reflect this in your cache. This would require some down time.


Inserting and retrieving Items:

There are a lot of variations in the API of the AppFabric caching. I would recommend to go through them here. In your middleware if you wish to read/write shared data between services then do consider the concurrency models. You can also have tags with keys and tags can be used to group items with your cache.

I am using the basic cache methods of Put and Get.

You can see the code below where I am getting all the key/value from all applications from SSO and adding them to cache. The Put method updates items if they already exists in cache or adds them. There is also and Add method which gives an exception if the item already exists.

public void PopulateCacheFromSSO() { IDictionary<string, string> apps = SSOConfigManager.GetApplications(); foreach (string appName in apps.Keys) { string appUserAcct, appAdminAcct, description, contactInfo; HybridDictionary properties = SSOConfigManager.GetConfigProperties(appName, out description, out contactInfo, out appUserAcct, out appAdminAcct); System.Diagnostics.EventLog.WriteEntry("SSO Application Name", "Name = " + appName); foreach (DictionaryEntry appProperties in properties) { System.Diagnostics.EventLog.WriteEntry("SSO Application enteries", "Key = " + appProperties.Key.ToString() + " , " + "Value = " + appProperties.Value.ToString()); PutInCache(appName, appProperties.Key.ToString(), appProperties.Value.ToString()); } } } public void PutInCache(string category, string key, string value) { DataCacheItemVersion itemVersion; if ((itemVersion = configCache.Put(category + "_" + key, value)) != null) System.Diagnostics.EventLog.WriteEntry("Cache Item Added", "Key = " + key); else throw new Exception("Cache Item not added"); }

After running the code you can run the Get-CacheStatistics command to see if the items are added to the cache. Now it’s time to retrieve and item from the cache which you added. The code below gets the items from the cache.

public string GetFromCache(string category, string key) { string item; if ((item = (string)configCache.Get(category + "_" + key)) != null) System.Diagnostics.EventLog.WriteEntry("Cache Item Retrieved", "Key = " + key); else throw new Exception("Cache item could not be found"); return item; }

Try to retrieve the values from the cache after the TTL time configured in the configuration file. You will find that the cache has expired. Also run the Get-CacheStatistics from power shell, see what you find.

Some troubles which I had and would be common to any developer are below.

ErrorCode<ERRCA0017>:SubStatus<ES0007>:There is a temporary failure. Please retry later. (The request failed because the server is in throttled state.)

If you get the error above it means nothing I couldn’t figure it out neither the guys on MSDN I just reset the IIS and this will go away. You will notice in the Task Manager that the w3wp process is taking too much memory.

The type or namespace name ‘ApplicationServer’ does not exist in the namespace ‘Microsoft’ (are you missing an assembly reference?)

If you are getting the error above may be you have not set the target framework 3.5/4. The second thing which I had is that I was adding references to Microsoft.ApplicationServer.Caching.Client and Microsoft.ApplicationServer.Caching.Core assemblies from C:\Windows\SysNative\AppFabric path. It simply didn’t work and the error persisted. I then added the reference from the GAC (I have no explanation for this). You can find the references in the sample.

Did the above solve my middleware problems?

I had to find a solution to the problems which I had from the enterprise library.

1- Availability and Scalability is solved by architecture of the AppFabric cache.

2- If you want to reflect changes immediately in the cache as a result of the update in the source restart the cluster services without restarting the BizTalk host instances. I mentioned that there would be a downtime it means that you don’t need to stop the host instances just stop the receive locations so that no request is entertained by BizTalk.

3- If you don’t need the downtime there can be another trick. Create a new cache of same configuration but with a different name. In the BTSNTSvc.exe.config or machine.config file I assume that you have kept the name of the cache in the appSettings section. This means that you will be retrieving it at runtime. Change it to the new cache which you created.

4- If you can wait till the cache gets expired it’s the best thing the cache will get the fresh data from the source and in the multi-server environment of BizTalk each BizTalk node will have a consistent identical copy of the cache. Great!

Security Considerations:

Without security considerations this article is incomplete and a BizTalk guy reading this cannot compromise the security over the SSO data. Of course if security is not considered with caching the SSO data can be overridden by any client who has access to the cache. As the cache will be clustered, clear text data in the network can also be sniffed.

In AppFabric cache cluster the communication between the client and the server supports Encryption and Signing.

A windows account must be added which has access to the cache cluster. This account must be used by the client application to access the cache cluster. In the BizTalk scenario we would add users such as BizTalk application Users (under which host instances run) and SSO Administrator/Affiliated administrator. This is done by Grant-CacheAllowedClientAccount command from power shell.

Cluster Security options :

After allowing access to the users you have to configure the server and client for security.

For enabling security option to the server you have to use Set-CacheClusterSecurity command from power shell.


Client Security options:

For client you can do it programmatically and in the configuration file locate the security properties tag.

<securityProperties mode=”Transport” protectionLevel=”EncryptAndSign” />

There is a table from Security Model (Windows Server AppFabric Caching) where the matrix of the combination of the cluster and client security options is given. The combination of client and cluster security options will work or not is explained in the following table. 

Client Settings Mode=None, ProtectionLevel=Any Mode=Transport, ProtectionLevel=None Mode=Transport, ProtectionLevel=Sign Mode=Transport, ProtectionLevel=EncryptAndSign
None, Any Pass Fail Fail Fail
Transport, None Fail Pass Fail Fail
Transport, Sign Fail Pass Pass Fail
Transport, EncryptAndSign Fail Pass Pass Pass
%d bloggers like this: