TITULO XIV DERECHOS DE OFICINA
DERECHOS GENERALES DE OFICINA
This section briefly discusses variations on the normal SLM method of configuration. This particular approach was developed initially with the goal of allowing the SLM configuration to be updated merely by changing a simple XML file rather than requiring the user to update the domain configuration. The technique can be applied in a variety of ways, as will become clear.
The core of the technique is to arrange a set of SLM statements that correspond to particular traffic levels (for example, 1 transaction per second (TPS), 10 TPS, 100 TPS, and so on), then use a stylesheet prior to the SLM action to evaluate each incoming message and associate it with one of the SLM statements.
The easiest way to understand the technique is to look at a working example. Example 3-6 is a sample of the XML that we want to use to control the SLM.
Example 3-6 Sample of XML to use to control SLM
<SLAtoSLMmapping> <sla name="bronze" slm="1TPS"> <wsdl name="parlayx_terminal_location_service_2_3.wsdl" slm="2TPS"> <operation name="getLocation" slm="10TPS"/> </wsdl> </sla> <sla name="silver" slm="3TPS"> </sla> <sla name="gold" slm="5TPS"> </sla> <sla name="platinum" slm="10TPS"> </sla>
<sla name="test" slm="1TENTH-TPS"> </sla>
</SLAtoSLMmapping>
This design maps a service level agreement, such as bronze, gold, or silver, to criteria for determining which level of service should be permitted for each message.
The XML is fairly easy to interpret. First, we know the SLA based on the AAA information. A particular user ID is entitled to one of the defined SLAs. Since this example is for a Web Service Proxy, we also know the WSDL name and the operation. Therefore, the stylesheet simply looks for an <operation> element in the XML, then for a <wsdl> element, then finally for an <sla> element based on the current message. The result, of course, is the number of TPS, which is the “slm” attribute in each of those elements. Example 3-7 is a snippet of the stylesheet.
Example 3-7 Snippet of stylesheet
<xsl:variable name="wsdl" select="dp:variable('var://service/wsm/wsdl')"/> <xsl:variable name="result">
<xsl:variable name="byOperation" select="$mapdoc/SLAtoSLMmapping/sla[@name=$sla]/wsdl[@name=$wsdl]/operation[@name=$operatio nName]"/> <xsl:choose> <xsl:when test="$byOperation"> <root> <slm name="{$byOperation/@slm}"/>
<slm-pool name="{concat($appId, '/', $wsdl, '/', $operationName)}"/> </root> </xsl:when> <xsl:otherwise> <xsl:variable name="byWsdl" select="$mapdoc/SLAtoSLMmapping/sla[@name=$sla]/wsdl[@name=$wsdl]"/> <xsl:choose> <xsl:when test="$byWsdl"> <root> <slm name="{$byWsdl/@slm}"/> <slm-pool name="{concat($appId, '/', $wsdl)}"/> </root> </xsl:when> <xsl:otherwise> <xsl:variable name="bySLA" select="$mapdoc/SLAtoSLMmapping/sla[@name=$sla]"/> <xsl:choose> <xsl:when test="$bySLA"> <root> <slm name="{$bySLA/@slm}"/> <slm-pool name="{$appId}"/> </root> </xsl:when> <xsl:otherwise> </xsl:otherwise> </xsl:choose> </xsl:otherwise> </xsl:choose> </xsl:otherwise> </xsl:choose> </xsl:variable>
The pattern is clear: The result contains a bit of XML, as in Example 3-8.
Example 3-8 Result with a bit of XML
<root>
<slm name="1TPS"/> <slm-pool name="bronze"/> </root>
The <slm name=”1TPS”/> element is passed to the SLM action in this example as an HTTP header, and the <slm-pool name=”bronze”/> element is passed as a SOAP header. Both are removed later by another stylesheet. They could just as easily be stored in context variables. In any event, these values are consumed by the SLM action downstream from the stylesheet. The SLM action is configured as shown in Figure 3-13.
Each statement has a credential class that picks up the SLM level (from the <slm name=”1TPS”/> element) for the message. The resource class is the same for each statement, since it simply picks up the value from the <slm-pool name=”bronze”/> element. Figure 3-14 is an example of one of these SLM statements.
Figure 3-14 Example of SLM statement
Note that the threshold level is the TPS value times the number of seconds, which is 3 in this case. The rest of the statement is unremarkable.
The credential class has to be set up carefully so that it will match the value from the <slm name=”100TPS”/> element (Figure 3-15).
Figure 3-15 Credential class setup
In this example the TPS value, 100TPS, is picked up from the HTTP header and matched against the literal value 100TPS shown in the list box. This literal value must match the value in the <slm name=”100TPS”/> in the XML.
The resource class just returns a string. In this example, it will either be something like “bronze”, “bronze/parlayx_terminal_location_service_2_3.wsdl”, or
“bronze/parlayx_terminal_location_service_2_3.wsdl/getLocation”. Messages with the same string are grouped together for throttling, shaping, or logging.
Three possible variations
This technique is appropriate in several circumstances:
The user must update the SLM policies without actually changing the configuration of objects. This may be due to user unfamiliarity with the Web GUI or the need to repeat test cycles and promotions when making minor changes to the object configuration.
When there is a large mismatch between what SLM can conveniently do out of the box and what the model the user needs to implement. In this case you can devise a simple XML schema to control the SLM configuration and put logic in the stylesheet to evaluate each message according to the XML configuration.
The key design point is that the stylesheet evaluating each message produces two literal values. One value is used to activate a specific SLM statement for the message. The other value is used to group messages that should be throttled, shaped, or logged according to the same limits. You can pretty much do anything that you like in terms of the stylesheet and any XML configuration file as long as you end up with those two strings.
Some sophisticated actions can be taken with care. For example, you could adaptively assign TPS values to messages based on how many of each kind of message have passed through recently. Suppose that you pull the XML configuration (similar to the SLAtoSLMmapping above) from a system variable rather than from a file. Further, you record information in a system variable about each message as it passes through. Finally, you define a rule that periodically executes a stylesheet that copies and clears the historic information, evaluates it, and writes a new XML configuration into the variable mentioned earlier.
You could even drive the