I've explained in a previous post from a high level what a Enterprise Application Fabric is, and what I wanted to do today is dive into some of the architectural concepts and fabric terminology that are helpful to understand as you consider fabric enabling your application.
The concepts you could consider when fabric enabling your application include -
- The first idea, is that your application should be 'partition-able'. Meaning that your application can be run in parallel via the distribution of requests across a number of machines (fabric Workers). If each request to your application is independent from every other request, then this is a simple process. It's like multi-threading your application by distributing and running it across 100's of machines that can each independently process requests.
If your application is more of a straight-line A-Z type of process, you could partition your applications requests into several smaller request A-F, G-K and K-Z that would run in parallel. Or if you had a lots of machines you could partition the application into 26 individual requests that could all be run in parallel across a number of machines, the choice is yours. It's important to note with this type of application partitioning, that you may have to partition or cache your database to achieve scale.
It's also important to note, that your requests do NOT have to be stateless. Your application can use Fabric Accessible Memory or other state caching technologies to maintain state between requests.
- The second idea that I think helps people understand how a fabrics work differently from legacy grid applications, is that we dynamically 'pre-load' your applications into every machine (fabric Worker) in the fabric. You can have hundreds of applications resident in your fabric at any given time and unless they are satisfying some request, they just sit idle.
Fabric Applications are made up from multiple parts.
- Clients include any machine that could make a request to a fabric worker, external to the fabric or recursively from within the fabric.
- Tasks are the entry point to your applications. It's often the middle-tier code that connects to external resources to satisfy requests.
- Process Flows allow you to orchestrate the execution of Tasks and provide a mechanism by which state can be check pointed for each request between multiple machines.
Finally some code! What I wanted to show you here is how we can take a .NET Class and include two libraries, Appistry.Task and FabricHelper and add .NET annotations to expose the relevant parts of the class to the fabric. - which I have posted on how 'How to create a fabric task' link sidebar.
Thanks
Mark
