The Management and Governance of the distributed applications is a challenging task. The On-demand business requirements mean that new services have to be frequently added to existing business processes. The administrator needs to ensure that the service components being added are tested thoroughly and do not compromise the stability and performance of the system. To satisfy this requirement, the administrator needs to implement reliable configuration management and governance policies to prevent unstable components from being added to the system.
Deployment Manager is a powerful rule engine that simplifies configuration management and governance in the Fiorano network. The Deployment Manager uses the concept of Labels and Rules to achieve the above mentioned goals.
The Fiorano Platform enables users to label the various components of their distributed architecture. All the Service Components, Event Processes, and nodes (peer servers) can be labeled.
The labels currently supported by the tool are:
You can use a combination of labels and other identifiers (GUIDs, version numbers, and node names) to create comprehensive and powerful rules to control the deployment of processes. For example, when a new process has been developed, then it can be marked with a Development label. After appropriate levels of testing, it can then be upgraded to Staging. The labeling support at the service component level provides similar functionality at a much more fine-grained level.
A rule in the Fiorano Platform context is a conditional statement that controls the launch of Business Components. The rules have two important aspects; identifiers and precedence.
The identifiers are values assigned to the various configurable elements of the Fiorano Network. The configurable elements are the fixed elements of the Fiorano Network, such as Event Processes, Business Components, and Peer Servers. The rules are constructed by combining identifiers of the various Fiorano Platform elements. The Deployment Manager has been configured with the following identifiers:
The identifiers allow you to control the ambit and complexity of a rule. The fewer the identifiers, the simpler the rule and the greater its ambit. For example, a simple rule can be created to disallow all instances of a particular Business Component from being launched. This rule will typically contain one identifier, the GUID of the Business Component. Despite being a simple rule, it applies to all Business Components in the Fiorano Network. A complex rule, on the other hand, can be created to prevent a particular Business Component from being launched on a Peer Server when it is part of a particular Event Process. This rule will contain at least three identifiers, the GUIDs of the Event Process, the Business Component, and the label of the Peer Server. The Version identifier is present only for components and event processes and not for the Peer Server.
Precedence: All rules are processed in the order in which they are stored by the Deployment Manager. By default, rules are stored in the order in which they were created. As a result, you will have to ensure that one rule does not interfere with the other. You can alter the precedence of the rules by using the controls provided in the tool.
The syntax of a rule is illustrated in the figure below.
Figure 1: Rule syntax
The figure below illustrates a sample rule that disallows deployment of any non-production event process on a peer with the Production Label.
Figure 2: Sample Rule
The complex business rules can be tested and verified before implementing them in your environment. The Deployment Manager provides the ability to test the rules at design time.
Figure 3: Verifying Rule