Building on the blog series for Application Template we got you started couple weeks back with last blog (/blogs/2011/10/05/time-to-get-started-with-existing-application-templates/) and this one focuses on how we logically show you the complete application deployment through single view point.
We have understood so far that it is quite easy to import an Application Template or built a new Template for your custom application from scratch. Once template is deployed most important aspect is the ability to present whole Template on a single screen such that you can view all configuration pieces together. Following is a snapshot of how your Sharepoint Application Template deployment would look like on a single screen.
Here you can see that whole Application is broken down in logical pieces which are called the Application Units (FrontPage Services, SOAP Services …). These AppUnits are logical bucket which caters to specific type of information and content for deployed application. Within same application different content types have got different processing requirements and it is not wise to deploy single set of policies to process whole application traffic. Application template notion drives feature processing using policies at logical AppUnit layer. It provides huge flexibility and improves overall system performance by not spending processing cycle on something less useful. On this screen you see every AppUnit with a column for feature policies and the “+” marks signifies that we can add the policy for respective feature. On other icons we can see what policy has been defined and optimize them as needed.
At this point you would wonder why we cannot put these policies in a consolidated way against the public endpoint and let every AppUnit inherit these policies. We can do that technically but that’s where we lose value offered by Application Template architecture. Defining logical AppUnits and binding policies to these AppUnits is the key because you do not want to take generic action against whole traffic flow for any application. Here are few examples:
– You may not want to cache the SOAP services response because every call results in different content because of dynamic processing
– You may not want to compress images as they would not result in high bandwidth saving
– You may want to use different Application Firewall profiles for “FrontPage Services” versus “Styles and Scripts” given the nature of content and possible attacks
When these templates are exported we maintain same level of association and binding of policies to respective AppUnits. In cases where global configuration of a policy is more meaningful, we do allow that through templates. For example, we break down Application Firewall in positive and negative security model. We recommend using signature based check of negative model globally, bound to public endpoint. While positive security checks can certainly differ based on what kind of content is being processed thus are associated with every AppUnit.
Last but not the least is the ability of doing end to end configuration and changes from this same screen. You can take up any of the following tasks and many more from this single screen:
- Adding new policy
- Modifying existing policy
- Defining new profile or action
- Adding new application unit
- Removing existing application unit
- Defining authentication, authorization and auditing policies
- Getting to visualizer for application deployment
- Looking inside the statistics for application
And many more such logical tasks can be performed from this same screen. Isn’t it a great support? 🙂