Here is how it will look like. create a task setting `

1. How many times we want to retry`
2. How long should we wait between a retry and another.
3. A function to filter errors. so in my case, server errors are ok to retry against but authentication errors are not. for filtering errors in JS refer to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch
4. A function to call if we failed (after trying the given number of times).
5. A function to call if we succeed (example: in my case this is where I will start listening to events).
6. The function I want to try executing.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

var rtmodule = require('./RetryableTask.js');

var totalRetry = 3;
var retryIntervalSec = 1;

var rt = new rtmodule.retrybleTask(totalRetry, retryIntervalSec);
// or
//var rt = rtmodule.retrybleTask(3, 1);


rt.on("failif", function (err) {
    console.log("failif failed with err: " + err);
    return false;
}).on("finalfail" , function (err, trycount) {
    console.log("final fail: " + err + " " + trycount);
}).on("done", function (TriedCound) {
    console.log("sucess! try cound is:" + TriedCound);
}).on("execute", function () {
    var d = new Date();

    if (d.getSeconds() % 2 == 0)
        throw "RANDOM ERROR";
});

console.log("about to run");
rt.run(); // let there be light!

the module code is below, enjoy!

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104

(
function () {
    function _retrybleTask(retryCount, delaySeconds) {
        
        if (!(this instanceof _retrybleTask)) { 
            return new _retrybleTask(retryCount, delaySeconds);
        }

        this._retryCount = retryCount | 1;
        this._currentRetry = 1;
        this._delaySeconds = delaySeconds | 1;
        
        // this is what the task will execute
        this._execute = function () { 
            throw "this retryable is empty! with nothing to execute";
        };
        
        // our fail filter
        this._failIf = function (err) {
            return true // default we fail with every error
        };
        
        // if we successed, ultimatly
        this._done = function (tryCount) { 
           // this what we will execute if we managed to successfully execute 
        };
        
        // if we failed, ultimatly
        this._finalfail = function ( err, tryCount) {
            console.log("Retryable Task Failed: trycount{" + tryCount + "}" + " err was {" + err + "}"); 
        };
        return this;
    }

    _retrybleTask.prototype.on = function(action, callback)
    {
        
        var events = ["failif", "done", "execute", "finalfail"];
        

        if (typeof callback != "function")
            throw "callback is not a function";
        
        if (-1 == events.indexOf(action))
            throw "unsupported action";

        if ("failif" === action) { 
            this._failIf = callback;
            return this;
        }

        if ("done" === action) { 
            this._done = callback;
            return this;
        }

        if ("execute" === action) {
            this._execute = callback;
            return this;
        }
        if ("finalfail" === action) {
            this._finalfail = callback;
            return this;
        }
        
    }
    _retrybleTask.prototype.run = function () {
        var self = this;
        var bSucess = false;
        try {
            
            this._execute();
            bSucess = true;
        }
        catch (err) {
            if (this._failIf(err)) {
                this._finalfail(this._currentRetry, err);
                return;
            }
            if (this._currentRetry === this._retryCount) { 

                this._finalfail( err, this._currentRetry);
                return;
            }
            // set next execute cycle
            this._currentRetry++;
            setTimeout(function () { self.run() }, this._delaySeconds * 1000)    
        }
        finally {
            if (bSucess) {
                this._done(this._currentRetry );
            }
            
        }

       
    }
    


    module.exports.retrybleTask = _retrybleTask; 
    
}
)();

“

Try N number of times to do X, if at any point you encountered exception A or B or C fail and don’t retry

“

On a side note: I needed the below as a JS function for a something I am doing based on nodejs but turned out to be harder than expected due to the way lexical scope is transferred from one call back to another.

Ultimately speaking you need it to look like that:

     RetryableTask<int> rt = new RetryableTask<int>(); // this task will return an int when it finally successed
            rt.RertyCount = 1000; // try for a 1000 time
            rt.FailIF = (exp) => // Stop if you encounter one of these exceptions
            {
                // handle and filter error here
                return false;

            };
            rt.FuncToExecute = async (cts) => // this is what we will execute 
            {
                Debug.WriteLine("FuncToExecute - Thread:" + System.Threading.Thread.CurrentThread.ManagedThreadId);
                return 0;
            };

    Then we are ready to execute our task

var nRes = rt.Execute();
		// do a lot of things here 
		
		await nRes // this will return if when we get results 
 
// if the task failed (i.e. encountered an irrecoverable failure we will get one of the following exceptions 
// TaskExecutionException as in we tried 1000s times and no results
// any other exception as thrown (one that FailIf returned true on).

the class also supports cancelation by calling rt.Cancel() and support chain-ing the task by setting the cancelation token source field before calling execute.

The complete code is below

    public class RetryableTask<T>
    {
        public Func<CancellationTokenSource, Task<T>> FuncToExecute = null;
        public Func<Exception, bool> FailIF = new Func<Exception, bool>((e) => { return false; }); // basically always retry
        public CancellationTokenSource cts = new CancellationTokenSource();
        public int RertyCount = 1;
        public int DelayMiliSec = 0;
     


        protected void Validate()
        {
           if (null == this.FuncToExecute)
                throw new ArgumentNullException("FuncToExecute");

            if (null == this.cts)
                throw new ArgumentNullException("cts");

            if (null == this.FailIF)
                throw new ArgumentNullException("FailIF");
        }

        
        public async Task<T> Execute()
        {

            Validate();
            Debug.WriteLine("Do/While - Thread:" + System.Threading.Thread.CurrentThread.ManagedThreadId);


            int nCurrent = 1;
            do
            {

                if (cts.IsCancellationRequested)
                {
                    Debug.WriteLine("Task canceled.. breaking");
                    break;
                }

                try
                {
                    return await FuncToExecute(cts);
                }
                catch (Exception e)
                {
                    if (true == this.FailIF(e)) // fail if delegate should handle and log the error as needed
                        throw;
                }

                nCurrent++;


                // you don't want to wait unncessary
                if (cts.IsCancellationRequested)
                {
                    Debug.WriteLine("Task canceled.. breaking");
                    break;
                }

                if (this.DelayMiliSec > 0)
                    await Task.Delay(this.DelayMiliSec, cts.Token);

            } while (nCurrent <= RertyCount);

           // if we are here then task failed to execute given the # of retries
            throw new TaskExecutionFailedException(nCurrent);


        }
        public async Task Cancel()
        {
              if (null == this.cts)
                throw new ArgumentNullException("cts");

              this.cts.Cancel();
              await Task.FromResult(0);
             
        }
    }

The complete code to run the above in a console app is below:

RetryableTask<int> rt = new RetryableTask<int>(); // this task will return an int when it finally successed
            rt.RertyCount = 1000; // try for a 1000 time
            rt.FailIF = (exp) => // Stop if you incounter these specic exceptions
            {
                // handle and filter error here
                return false;

            };
            rt.FuncToExecute = async (cts) => // this is what we will execute 
            {
                Debug.WriteLine("FuncToExecute - Thread:" + System.Threading.Thread.CurrentThread.ManagedThreadId);
                return 0;
            };

            int nResults;
            Task t = Task.Run(async () => { nResults = await rt.Execute(); });

            Task tCancel = Task.Run(async () =>
            {
                await Task.Delay(10000);
                Debug.WriteLine("About to Cancel");
                await rt.Cancel();
            });

            Console.WriteLine("running");
            t.Wait();




            Console.WriteLine("Done!");

            Console.Read();

Have a good weekend!

Continuing on Building SaaS solution journey. The past articles are here:

1. Part 1: https://blogs.msdn.com/b/bursts_of_random_architecture_thoughts/archive/2015/02/19/saas-bits-01.aspx

We have layered the foundation architecture where we decided

1. All requests will be directed to a gateway (reverse proxy, based on IIS ARR). Previous code (https://github.com/khenidak/SaaSBits  check 2015-2-19 directory) redirect to one of 2 URLs statically defined as didn’t build the scale part yet.

2. Based on user information (and dynamic information managed by the capacity and scale component CSC) the request will be routed.

3. The gateway/router routs to a “pod”. The number and the addresses of pods is managed by the CSC.

Based on our requirements request is redirected to a certain pod based on:

1. Tenant (request belongs to a premium tenant which is served by a dedicated pod)

2. If not, then the tenant decided by the CSC which can be scaling or compacting (un-provisioning pods) the system.

A bit of side info on the need for scale/compacting approach:

If you keep the cost of building/upgrading your SaaS software aside you will notice that the majority of cost is running/operating cost (i.e the number of active VMs, roles and other resources). Hence the need to keep those as minimum as possible (less - paid for - compute + storage resources serving the same amount of users means more financial yields of the system).

So where should the gateway look for user’s tenant (per request? The obvious answer is authentication claim (from the AuthN system). As in the Gateway will have to broker the AuthN for each request before it routes it to a pod. The rest of authentication requirements (aside from the obvious ones) are:

1. Federate: allow SaaS customers to use their identity providers.

2. Standardize: no funky AuthN or proprietary mechanisms that doesn’t work with your customers.

3. Transparency: you don’t want to change the actual authentication tokens. This to allow SaaS application developers to make use – AS IS without the need to change - of the fun stuff like ADAL, WIF or OWIN AuthN middleware. With scenarios like impersonation/on-behalf-of enabled.

In context:

• A windows Azure A/D WAAD tenant (core tenant) will be created where

  • SaaS apps (i.e hr.cloudapp.net> or erp.cloudapp.net) will be published as a multi-tenant application (follow these instructions for how, you will need a verified domain on WAAD for multitenant applications). With its redirect URL points to the gateway (more on this later).

  • SaaS gateway/router will be also published to this tenant but not as a multi-tenant. It will carry the URLs (via cname records) the URLs which you will share with your customers (ie hr.<yourcompany>.com erp.<your company>.com).

• Each of our customers will have a WAAD tenant as the following:

  • Option1: customer’s self-operated tenant is federated with ADFS (or similar) which authenticates based on an on-prem A/D.

  • Option 2: customer’s self-operated tenant is federated with ADFS which authenticates using a custom user store.

  • Option 3: customer’s self-operated tenanted is synchronized with an on-prem A/D.

  • Option 4: for customers who don’t have a WAAD we can create and operate a tenant for each (this option is also good if we already have an on-prem software and we are converting it to cloud based SaaS).  

WAAD will be providing a single token format for our SaaS applications as the following:

1. oAuth2 JWT for web API apps

2. OpenID-Connect for Web Applications

The above pretty much covers most of the authentication and token formats currently available in the industry.

The authentication for the entire system code will work as the following

The gateway is an IIS application that has the following:

1. Custom HTTP module:

   1. Identify if the target request is for a web app or web API

      1. For Web App: Checks the OpenID-Connect authentication token (manaually as a multitenant app) extracting the TenantID and UPN into HTTP header.

      2. For Web API: checks oAuth bearer token (this code is not implemented yet).

   2. Appends a custom oAuth token to a custom header (it authenticates itself as a daemon check: https://msdn.microsoft.com/en-us/library/azure/dn646737.aspx#BKMK_Daemon).

2. The IIS ARR components uses the tenant Id and user principal to decide on routing (currently static routing, dynamic routing is not implemented yet).

3.  The backend application will be configured as usual in addition to a preceding component (executes before regular AuthN code) to validate the custom gateway oAuth (from the custom header). This ensure that these applications will only be called from the gateway.

What is in the Code:

1. The entire code is abstracting IIS functionality. The code is future ready for ASP.NET 6 where System.Web will not be used. Also the abstraction allows you to run the code away from IIS if needed.

2. Note HTTPs not implement yet. So all tokens used in testing is shared on unencrypted channel.

3. An azure web site sample application configured with default OWIN OpenID-Connect and a custom empty OWIN component that will be used as gateway authenticator.

4. A web API application (as azure web site).

5. A custom deployment replicator PowerShell script that deploys the azure web sites multiple times to simulate pods.

Setup:

1. Deploy the gateway as Web Role (already configured, just update with your key). The package already performs all the installation needed via startup tasks.

2. Create WAAD tenant (core tenant) with a verified domain ie saasdomain.com

3. Publish gateway application to your tenant as a regular web app/web API.

4. Publish gateway application as a client in your core tenant. (the oAuth bearer token is based on the gateway as an application and a client).  

5. Publish a sample SAAS backend app ie hr.saasdomain.com as a multitenant web app/web api.

6. On your DNS (or RDP into the gateway web role and modify hosts file). Create a CNAME of hr.saasdomain.com pointing to the gateway ur lie gateway.cloudapp.net.

7. Create another WAAD tenant (as a customer tanant) add a test user to it.

8. Open your favorite browser browse to hr.saasdomain.com sign in to WAAD you will be redirected to the gateway (where the above process executes).

9. Review the entities statically loaded in GatewayApp class in SaaS.Gateway.Common assembly

10. Publish sample backend applications (not currently needed).

Code has been published here:

https://github.com/khenidak/SaaSBits/tree/master/2015-3-1

How can we build that? if you strip out all the fatty details what we need is the following

A pipeline that processes the request with the following stages (in order)

1-HTTP Listener

2- Few components that perform AuthN and AuthZ

3- A component that looks at the incoming request and decides where this request goes say request coming in are for https://domainA.com and it should go https://domainB.com (similar to IIS URL rewrite).

4- A component that takes the request and executes.

OWIN comes natural to this as it has the pipeline (and an HTTPlistener based on .NET frx HTTP Listener).

The below code is hosted in a console app:

Program Main

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

    static void Main(string[] args)
        {
            string baseUrl = "https://localhost:5001/";

            using (var server = WebApp.Start<Startup>(new StartOptions(baseUrl)))
            {
                Console.WriteLine("Server Started... Press Enter to quit.");
                Console.ReadKey();
            }


        }

the above just runs the server

the Startup class sets up 2 components (the URL re-writer and the other is Request Router)

1
2
3
4
5
6
7
8

 public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.UseURLRewrite();
            app.UseRR();
        }
    }

Because this is fun project. I wanted to do more. Let us assume we want to implement 2 very simple pattern Broadcast (request goes to multiple servers) or First Responder (request goes to multiple servers returns when any responds).

so my URL rewrite does the following (OWIN invoke method). it randomly selects (based on current time second odd/even) modes (either broadcast or first responder) setting list of URLs and current mode in OWIN environment dictionary

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

   public async Task Invoke(IDictionary<string, object> env)
        {
            var response = env["owin.ResponseBody"] as Stream;

   
            List<string> TargetUrls = new List<string>();


            //current code does't handle GZIP 
            // BBC is not using it. other site will give octet/stream response time out of the proxy.

            if(DateTime.Now.Second %2 > 0 )
            {

                // scatter and gather approach
                TargetUrls .Add("https://www.bbc.com");
                TargetUrls.Add("https://www.bbc.com");
                TargetUrls.Add("https://www.bbc.com");
                TargetUrls.Add("https://www.bbc.com");
                TargetUrls.Add("https://www.bbc.com");
                TargetUrls.Add("https://www.bbc.com");
                TargetUrls.Add("https://www.bbc.com");
                TargetUrls.Add("https://www.bbc.com");

                env.Add("rr.Mode", "ALL");
                Debug.WriteLine("routed first case");


            }
            else
            {
                env.Add("rr.Mode", "ANY");
                Debug.WriteLine("routed second case");
                TargetUrls.Add("https://www.bbc.com");
            }

            env.Add("rr.targetURLs", TargetUrls);
            await _next.Invoke(env);
        }

My Request router performs the following:

1- copies original request stream

2- prepares an HTTPRequest/HTTPClient instance for each URL.

3- copies original request headers

4- execute the request

5- waits for the results (either All or Any).

6- copies response headers back to the down steam header.

7- copies the response body back into the down stream body.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136

 public async Task Invoke(IDictionary<string, object> env)
    {
        
        var Tasks = new List<Task<HttpResponseMessage>>();
        var outStream = new MemoryStream();
        Task tCopy = null;
        var inStream = env["owin.RequestBody"] as Stream;
        string rrmode = env["rr.Mode"] as string;
        var Clients = new List<HttpClient>();
        List<string> sTargetURs = env["rr.targetURLs"] as List<string>; 




        if(null != inStream)
            tCopy =  inStream.CopyToAsync(outStream);
        else
            tCopy = Task.FromResult(0);






        foreach (var s in sTargetURs)
        {
            var client = new System.Net.Http.HttpClient();

            
               // copy headers
                foreach (var header in env["owin.RequestHeaders"] as IDictionary<string, string[]>)
                  client.DefaultRequestHeaders.Add(header.Key, header.Value);

                // copy body
                   HttpRequestMessage request = new HttpRequestMessage();
                   await tCopy; // finish copy

                   var sMethod = env["owin.RequestMethod"] as string;

                    
                 // set body - not all types take a body
                if("get" != sMethod.ToLower())
                   request.Content  = new StreamContent(outStream);
   
                
                 //set method
                 request.Method = new HttpMethod( sMethod);

                var sPath = (env["owin.RequestPath"] as string)  ?? string.Empty;
                var sQueryString =   (env["owin.RequestQueryString"] as string)  ?? string.Empty;
            
                if (string.Empty != sQueryString)
                    sQueryString = "?" + sQueryString ;

                request.RequestUri = new Uri(s + sPath + sQueryString);
                
                // add it to our bag // you should track cancellation tokens as well. 
         
                Tasks.Add(client.SendAsync(request));
                Clients.Add(client);
        }

          HttpResponseMessage selectedResponse = null;// :-(
          HttpStatusCode _responseCode = HttpStatusCode.InternalServerError;
          HttpResponseHeaders _responseHeaders = null;
          HttpContent _responseContent = null;
          string _responseStatusMessage = "Proxy!"; // obviously w are not using RFC - review spec: RFC 2616 section 6.1.1


        // wait for response
          try
          {


              if (rrmode == "ALL")
              {
                  Debug.WriteLine(string.Format("waiting for - ALL - {0} requests", sTargetURs.Count));
                  var completedTasks = await Task.WhenAll<HttpResponseMessage>(Tasks);
                  Debug.WriteLine(string.Format("{0} requests completed..", sTargetURs.Count));
                  // you can do fun stuff here like compsing a response, concating it etc..
                  
                  selectedResponse = completedTasks[0];


              }
              else
              {
                  Debug.WriteLine(string.Format("waiting for - ANY - {0} requests", sTargetURs.Count));
                  
                  // this could be "any" or "Single" mode
                  var completedTask = await Task.WhenAny<HttpResponseMessage>(Tasks);
                  
                  // you should keep a list of cancelation tokens. and cancel all once one returned. 
                  // in this example all tasks will keep in running and return to nothing 
                  
                  
                  string.Format("1 request completed..");
                  selectedResponse = await completedTask;
              }
              selectedResponse.EnsureSuccessStatusCode();

              _responseCode = selectedResponse.StatusCode;
              _responseHeaders = selectedResponse.Headers;
              _responseContent = selectedResponse.Content;

          }
          catch (AggregateException ae)
          {
                // log ae
              _responseStatusMessage = "error executing the request: " + ae.Flatten().Message;
             
          }
          catch (Exception e) // we are assuming since we are here we actually executed a request and we got a response
          {
              //log e
              _responseStatusMessage = "general internal error" + e.Message;
          
          }
        finally
          {
              // release all clients
              Clients.ForEach(c => c.Dispose());
          }
          


          await setResponse(env,
                       _responseCode,
                        _responseHeaders,
                        _responseContent,
                        _responseStatusMessage);

          await _next.Invoke(env);

         
        }

While this is FUN project there is a lot of applications to it. Typically with high-scale write operations are based on eventual consistency using platforms such as Event Hubs/Service Bus/CQRS or databases (name your favorite eventual consistency DB here).  Read operations however specially those across multiple shards/systems are harder to implement. My favorite implementation for this a command broker. where the client (imagine SPA page) sends one request that this pipeline intercepts and expand into multiple sub commands each is targeting a WebAPI/System.

The code is attached to this past. hope you had a fun week end

Fun.ARR.zip

So you want to build a SaaS/SaaS like solution? Yes!. But what is a SaaS solution?

You can look up the definition at Wikipedia, spend hours discussing it at Reddit or discuss the architecture philosophies behind at your favorite tech group(s). For the purpose of this blog entry (and those to follow) we will define it as “A hosted software that scale and descale according to demand or configurable parameters”.

While there is a lot of literature around SaaS challenges, components that fits within SaaS architecture or general how-to architecture; there is a limited literature that ties everything together and allow you to actually link all these learned lessons together. This is exactly the focus of this blog series. The focus is to provide a detailed – as much as we can - descriptive guidance on building SaaS infrastructure. And to provide – as much as we can – of the SaaS infrastructure actual building blocks. It will not focus on building the actual SaaS (your CRM, billing, tax etc.).

Few words before we begin, I follow sketch, detail then repeat approach similar to this. That means broad strokes first and it also means that we will make mistakes (intentionally and unintentionally) and we will fix them as go.

As we go I will be adapting code (there is plenty already written that we can refactor for our purposes), referencing external materials for you to learn more and build a wider understanding of an architecture like this.

Let us begin

General Requirements:

1. SaaS Clients types: Browsers, desktop apps, mobile or others backend solutions (for B2B scenarios).

2. SaaS solution components: The solution can run anything that is based on HTTP/HTTPs (this means Web, Web API, Web Sockets). It will not include lower level protocols such as AMQP, MQTT etc. (at least for this stage)

3. Offerings Types – for whatever the SaaS:

   1. Private Jet/Platinum: Those who are premium customers served at the highest performance and availability SLA.  Those might include customers with higher level of isolation (government/public sector and so forth).

   2. First Class/ Gold: lower performance and so on.

   3. Business Class: …

   4. Econ Class:….

4. The system must allow scaling response to the demand or scheduling scaling.

5. The system must be flexible to allow seasonal customer type changes (customer Xyz is an econ customer but wants to use private jets during the last 5 days of the month).  

6. The system must allow different versions of the SaaS software running side by side (to allow early adapters, A/B testing and so on).

7. The system must allow private/public cloud deployment.

8. The system must allow deployment of different SaaS software on the same platform (for example crm.contoso.com, taxes.contoso.com, hr.contoso.com).

9. The system must have the lowest footprint/ties possible on/with the underlying platform (azure, private cloud etc.). You will need that to:

   1. Make use of different features from the underlying platform as they get released (without ripping your solution apart).

   2. Shift different parts of the solution to different clouds private/public(s) as needed.

10. Billing/subscription schemes? (Check: https://msdn.microsoft.com/en-us/library/ff966499.aspx MSFT P&P Developing Multi-tenant Applications for the Cloud, 3rd Edition). As we add more to our SaaS infrastructure we will be seeing the impact on different billing/subscription types.

11. For different types SLAs and impact on architecture also check “Developing Multi-tenant Applications for the Cloud, 3rd Edition”

The above defines broad strokes, let us begin to define our SaaS infrastructure conceptual architecture.

The easiest way to describe the above conceptual architecture is to walkthrough it. As the following

1. A user or a system (client) will authenticate (as a result of redirection) against the AuthN component.

2. The AuthN component will generate a token for the client.

3. The client will use the token to connect to SaaS infrastructure (via the gateway).

4. The gateway will unpack the token to acquire enough information about the user (example tenant ID, group id etc).

5. Using this info the gateway will connect to the capacity and scale component CSC asking “where should I send this request to”.

6. The CSC will decide which “pod” should respond to this user request. It can also decide to create more Pod as needed.  

7. Gateway routes the request to the pod load balancer based on the CSC answer.

Few Extra Notes:

1. The above happens for each request (to allow temporal subscriptions i.e. give me the highest performance last 5 days of the fiscal month).

2. The details of how CSC is making decisions is not relevant now, and will be discussed later.

3. A Pod is a collection of same instances serving the software itself, the instances are behind a load balancer (something we should not write ourselves, details later).

4. A Pod scales within (number of instances can increase up to the highest limits).

5. The AuthN engine is expected to normalize tokens, authentication protocols into one gateway specific protocol.  

6. The gateway must not retain any shared state to allow multiple instances of the gateway (load balancing) to run without the need to write a shared state component.  

Implementation

I have selected to start with gateway/router. The gateway is based on the James Baker’s Service Gateway published here (https://sg.codeplex.com/) for more information visit (https://channel9.msdn.com/Shows/Web+Camps+TV/Decoupling-Large-Applications-with-the-Service-Gateway):

The gateway is based on

1. IIS ARR Reverse Proxy + Custom URL Rewrite Provider.

2. Hosted as a Azure Web Role

For more info:

• IIS URL rewrite module: https://www.iis.net/downloads/microsoft/url-rewrite

• IIS URL rewrite custom provider https://www.iis.net/learn/extensions/url-rewrite-module/developing-a-custom-rewrite-provider-for-url-rewrite-module

• IIS ARR https://www.iis.net/downloads/microsoft/application-request-routing

• IIS Reverse Proxy https://www.iis.net/learn/extensions/configuring-application-request-routing-%28arr%29/creating-a-forward-proxy-using-application-request-routing

My applicationhost.config looks like (under system.webserver section):

<rewrite>

 <allowedServerVariables>

          <add name="x_custom_header" />

        </allowedServerVariables>

            <globalRules>

                <rule name="ARR_server_proxy" enabled="true" patternSyntax="ECMAScript" stopProcessing="true">

                    <match url="^(.*)$" />

                    <action type="Rewrite" url="{SaaSUrlExec:{C:0}[***]{R:0}}" appendQueryString="true" />

                    <conditions logicalGrouping="MatchAny" trackAllCaptures="true">

                        <add input="{HTTP_xHEADER}" pattern="(.*)" />

                    </conditions>

                    <serverVariables />

                </rule>

            </globalRules>

            <providers>

                <provider name="SaaSUrlExec" type="Saas.Gateway.UrlRouter.RouterExec, Saas.Gateway.UrlRouter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f94e44481a93f173">

                    <settings />

                </provider>

            </providers>

        </rewrite>                                                                     

        <proxy enabled="true" reverseRewriteHostInResponseHeaders="true">

            <cache />

        </proxy>

Basically it is a server wide rule that captures a custom header called xHeader and the Request Path then passes them as to our custom URL rewrite provider as <<xHeader>>[***]<<path>> which currently as a POC routes based on the xHeader content to one of two hard coded URLs (which for me was an empty page that spits “server 1 “ (as deployed on server 1) and “server 2“ (as deployed on server 2).

The rest of the code written at this stage is packaging and deployment code to Azure Web roles (ARR/IIS installation and configuration).

Note: in the code there is a console application that performs tests to confirm that the request has been routed successfully.

Code is published on https://github.com/khenidak/SaaSBits (with Feb 19th date). Once we have something stable enough we will move it to the root folder.

Notes:

1. We are currently installing ARR 2.5 (we will need to reconfigure for ARR 3.0 as it supports web sockets).

Till next time..

SharePoint Application Services provides web service endpoints for WFEs (and other
components) for connection. These end point in high available configuration require
load balancing which is available OOTB in SharePoint 2010.

This is a great reading for more information on this topic: https://blogs.msdn.com/b/dtaylor/archive/2011/02/23/sharepoint-2010-service-application-load-balancer.aspx