Dynamic attribute values in Policy

Topics: Usage Scenarios, Technical Questions
Jan 12, 2009 at 1:26 PM
Edited Jan 12, 2009 at 1:58 PM
Does MSE supports using dynamic attribute values in a Policy? How can this be implemented in MSE? For example, if the values are sourced from a database or perhaps a config file, and I don't want to use MSE management console to update a Policy attribute value.

Thanks ... comments and sample implementation is much appreciated.

One other question I have is (pardon me if this question sounds silly, I have an answer in mind but just wanted to make sure) -- if I need to apply multiple Policy in a MSE hosted Endpoint, e.g., Throttling, Regex, and Security, how can this be implemented? Only 1 Policy can be associated explicitly in an Endpoint (through the MSE mmc), can this be implemented through 1 Policy and include all necessary namespaces and class mapping in the same PolicyModel?
Jan 14, 2009 at 4:39 PM
I'll tackle the last question first.  You are correct that only one policy can be linked to an endpoint, however that policy can contain as many policy elements as you want.  So as you thought, you can define a policy that contains both the Throttling and RegEx policy elements and apply that aggregated policy to the endpoint.  This can quickly become cumbersome if you need to support several permutations of policies with different policy elements... this is one of the areas we are working on for the next release.

As for dynamic attributes in a policy.  The way to do this would be to define your own policy element (i.e. WCF behavior) that did the appropriate "lookup" for the values.  For example, say you wanted to have values for the ServiceThrottling behavior be dynamically determined when the endpoint was started.  Rather than puting the ServiceThrottling behavior directly in policy you would create your own WCF behavior (call it MyServiceThrottling) that did the lookup for the throttling values perhaps in a database and then used those values to create and apply the ServiceThrottling behavior to the endpoint.  The configuration attributes you'd put in your policy would in this case probably be the location of where the MyServiceThrottling behavior should go to get the values... either a connection string to a database or a path to a file that contains the values.  The Security guide has several examples of custom wcf behaviors applied via policy that you could model your approach after.

Note that in this case that while the policy retrieves values dynamically, the resulting WCF behavior is essentially static since you can't change ServiceThrottling behavior while a service is running.  If you wanted the endpoint to pick-up new values, you'd have to restart the endpoint so the policy can be reapplied.
Jan 14, 2009 at 8:02 PM
In your last paragraph, when you say "... restart the endpoint so the policy can be reapplied", do you actually mean re-start the MSE Runtime Server windows service which essentially hosting the ep? Perhaps this is like "shooting the moon" but could this be included in the Notification implementation?
Jan 14, 2009 at 9:37 PM
Restarting the MSE Runtime Server service is certainly valid, but if it hosts other endpoints then it is a bit much.  You can trigger an individual endpoint to restart by making a change in the Management tool that affects the endpoint. For example, if you have a policy applied to an endpoint, and only that endpoint uses the policy, making any change to the policy will trigger the proper notifications for the runtime to restart only that endpoint.

Another approach is to change the endpoint directly.  You could modify the endpoint description (i.e. add a space to the end) and then remove that space.  This will cause the UI to think the page is dirty and enable the Apply button for you to click.  In reallity there is no actual data change and this will be detected by the runtime when the change notification is delivered.  The runtime will go ahead and restart the endpoint anyway... this is really just a safety net to allow you to force an endpoint restart whenever you want w/o really changing anything... ideally we'd create a menu option to be more explicit about allowing you to force an endpoint to be restarted, but this isn't yet in the works.