• Get/Set Caching Strategy
• Get/Set Maximum Entries to Cache
• Get Keys
• Edit value
• Time to Live value

Throttling (a.k.a. Choking) Aspect

This aspect reduces the load on services based on policies which determine:

• When to delay access
• When to refuse access

Composite Apps requiring use of this aspect will have to employ the Filter Request/Reply or the Filter One-Way exchange pattern.

The Request Throttling policy should be applied based on:

• Service Endpoints
• Key Expressions in the message payload.
• Remote User if the user principle is available in the Normalized message header

Throttle Management Configuration

• Get/Set the Number of connections allowed
• Get/Set the Delay by x milliseconds
• Get/Set the Allow/Disable access based on policies

<?xml version="1.0" encoding="UTF-8"?>
<throttling>
    <config>
        <!-- Messages per second -->  
        <property name="rate" value="10" />
        <!-- Maximum number of queue entries -->  
        <property name="queue-length" value="1000" />        
    </config>    
    <ruleset name="mythrottling">
        <rule name="myfirstrule">
            <xpath keyExpression="/Employee/FirstName"/>            
        </rule>
    </ruleset>
</throttling>

Retry (a.k.a. Auto-Reconnect) Aspect

In a request/reply scenario, if the service provider is unavailable, one has to block the client until the service is up again and a response is received. The Auto-Reconnect Aspect would keep trying to make the call to the destination every configurable seconds for another configurable amount of time until the service provider becomes available again or the maximum number of retries is reached based on the configuration.

This pattern ensures the Retry policy acts between the client and the service that is being invoked. Therefore, if this aspect is configured, all messages flowing between the client and the service provider flows through the Retry engine core.

Composite Apps requiring use of this aspect will have to employ the Filter Request/Reply exchange pattern.

The Retry Aspect works on idempotent operations that do not need to go back to the client for conflict resolution.

Retry Management Configuration

• Get/Set the Seconds to Retry
• Get/Set the Maximum retries allowed

<?xml version="1.0" encoding="UTF-8"?>
<retry>
    <config>
        <!-- retry rate in msg / sec -->
        <property name="rate" value="10" />
        <!-- timeout in millisecond -->
        <property name="timeout" value="1000" />
    </config>
</retry>

Logging Aspect

The levels in descending order are:

• SEVERE (highest value)
• WARNING
• INFO
• CONFIG
• FINE
• FINER
• FINEST (lowest value)

This pattern ensures the Logging policy acts between the client and the service. Therefore, if this aspect is configured, all messages flowing between the client and the service providers flow through the Logging engine core.

Composite Apps requiring use of this pattern will have to employ either the Filter Request/Reply or the Filter One-Way exchange pattern. Logging Management Configuration

• Get/Set the Logging Level
• Get/Set Rotation Policy
• Get/Set Log file location

<?xml version="1.0" encoding="UTF-8"?>
<logging>              
    <config>
        <property name="level" value="INFO"/>
        <property name="rotation-policy" value="DAILY" />
        <property name="log-file" value="C:\\temp\\loggingse.log" />
    </config>
</logging>

Lease Management Aspect

For lease management we need to keep a list of users. And for each user we have the start time and end time for when that user can request that service. For example we have a list like:

jwaldorf 3/20/2007 12:23 AM 4/20/2007 12:23 AM
sbiswas 4/5/2007 2:33 PM 5/17/2007 4:55 AM

Then when the web service is invoked that has the jwaldorf credentials today it allows the call. But if the call was made with sbiswas today then it returns a fault because sbiswas cannot access the service until April 5th.

Let's say in May jwaldorf tried the call again, it fails because his lease expires. The aspect will need to look at the message exchange property that contains the security context that has the name of the principle (aka user) that is invoking this service).

Message Filter Aspect

Content Filter Aspect

Queuing Aspect

In a one-way web service request scenario, if the service provider is unavailable, one can use a Queuing Aspect to queue the requests until the service provider becomes available again. The Queuing Aspect would keep trying to make the call to the destination every configurable seconds for another configurable amount of time until the service provider becomes available again or the maximum number of retries is reached based on the configuration.

This pattern ensures the Queuing policy acts between the client and the service that is being invoked. Therefore, if this aspect is configured, all messages flowing between the client and the service provider flows through the Queuing engine core.

Composite Apps requiring use of this pattern will have to employ the Filter One-Way exchange pattern.

The Queuing Aspect works on idempotent operations that do not need to go back to the client for conflict resolution.

Queuing Management Configuration

• Get/Set the Seconds to Retry
• Get/Set the Maximum retries allowed

<?xml version="1.0" encoding="UTF-8"?>
<queuing>
    <config>
        <!-- Maximum number of queue entries -->  
        <property name="queue-length" value="1000" />
        <!-- time specified in sec/ millisec-->
        <property name="timeout" value="1000" />
        <property name="queue-type" value="normal / priority">
    </config>
</queuing>

Validator Aspect

Splitter Aspect

The splitter will only work on operations that have one part. And that part is a repeating element. What the splitter will do is make 1 message with n repeating elements into n messages each with 1 element. For example, if the operation's message has a part called foo that is a min=0, max=unlimited element called bar. And the input message has 10 "bar" elements. The the splitter would create 10 output messages each with one "bar" element.

The splitter would also put in a message exchange property that would identify each messages group id, it's message number, and a flag if it is the last one.

So in the example above the 10 messages would have the following properties

(gid=1, mn=1, last=false)
(gid=1, mn=2, last=false)
(gid=1, mn=3, last=false)
(gid=1, mn=4, last=false)
(gid=1, mn=5, last=false)
(gid=1, mn=6, last=false)
(gid=1, mn=7, last=false)
(gid=1, mn=8, last=false)
(gid=1, mn=9, last=false)
(gid=1, mn=10, last=true)

Aggregator Aspect

The aggregator would then simply wait for all the messages and put them back into the array in the right order. It would be the responsibility of each se and aspect to preserve these message properties.

Scatter-Gather Aspect

The splitter and aggregator work on one-way messages only. The Scatter-Gather works on request reply. For now we will make it only work on WSDLs that has it's input message have only one part that has a repeating element, and the output message that has only one part that is a repeating element. What the aspect will do is break the input message's many elements into a lot of single element messages. And then take the resulting responses and put them back into a single repeating array. For example if the input message has 3 repeating elements on the input message, then 3 seperate messages each with one element will be sent out of the aspect. When the 3 messages come back then will be put together into the repeating element and send back to the requester as one single message.

Resequencer Aspect

Chargeback Aspect

Monitoring Aspect

Time to Recover Aspect

Prioritization Aspect

Regulatory Compliance Aspect

Record/Replay Aspect

Simulator Aspect

Message Tracking Aspect

The Message Tracking aspect can be used to track messages flow through the system. Message Tracking will happen based on a configurable Rule Set which can be configured from the Web Console.

This pattern ensures the Message Tracking policy acts between the client and the multiple services that are involved to service the operation. Therefore, if this aspect is configured, all messages flowing between the client and the service providers flow through the Message Tracking engine core.

Composite Apps requiring use of this pattern will have to employ either the Filter Request/Reply or the Filter One-Way exchange pattern.

Message Tracking Management Configuration

• Get/Set/Add s
• Get/Set/Add/Edit s to
• Specification based
• Pre-condition based
• Get messages based on ID - Each normalized message has a unique message identifier that lets you select all the recorded events for a specific message.

<?xml version="1.0" encoding="UTF-8"?>
<message-tracking>
    <config>
        <property name="mode" value="database / file" />
        <!--
        config can have more params defining the database/file locations.
        -->
    </config>
    <ruleset name="myMessageTracking">
        <rule name="myfirstrule">
            <xpath keyExpression="/Employee/FirstName"/>            
        </rule>
    </ruleset>
</message-tracking>

Catch-Edit-Retry (a.k.a. Manual Recovery) Aspect

Audit Trail Aspect

Tee Aspect

It acts very much like the tee command in Unix where, for example, you may want to save the output of a command in a file, while at the same time see the results on the terminal as it is being produced. Then if you see that the output is in error, you can stop the command.

The tee command in Unix acts like a T-junction. For e.g., the UNIX command

ls -al | tee folderdetails

shows all the details of the current folder on the terminal screen and also redirects the details to a file named folderdetails.

This pattern ensures that the Tee policy acts between the client and the service that is involved to service the operation. Therefore, if this aspect is configured, all messages flowing between the client and the service providers flow through the Tee engine core. The routing will happen based on a configurable Rule Set which can be configured from the Web Console.

Composite Apps requiring use of this pattern will have to employ the Filter One-Way exchange pattern.

Tee Management Configuration

• Get/Set/Add s
• Get/Set/Add/Edit s to

<?xml version="1.0" encoding="UTF-8"?>
<tee>
    <config />
    <ruleset name="mytee" >
        <rule name="myfirstrule">
            <xpath keyExpression="/Employee/FirstName"/>            
            <destination id="1" />
            <destination id="2" />
        </rule>
    </ruleset>
</tee>

Content-Based Routing Aspect

This pattern ensures the Content-Based Routing policy acts between the client and the multiple services that are involved to service the operation. Therefore, if this aspect is configured, all messages flowing between the client and the service providers flow through the Content-Based Routing engine core.

Composite Apps requiring use of this pattern will have to employ either the Filter Request/Reply or the Filter One-Way exchange pattern.

Content-Based Routing Management Configuration

• Get/Set/Add s
• Get/Set/Add/Edit s to

For example,

<?xml version="1.0" encoding="UTF-8"?>
<contentBasedRouting>
    <config />
    <ruleset name="myrouting_1">
        <rule name="myfirstrule">
            <xpath keyExpression="/Employee/FirstName"/>            
            <destination id="1" />
        </rule>
        <rule name="mysecondrule">
            <xpath keyExpression="/Employee/FirstName"/>            
            <destination id="2" />
        </rule>
        <rule name="mythirdrule">
            <xpath keyExpression="/Employee/FirstName"/>            
            <destination id="3" />
        </rule>
    </ruleset>
</contentBasedRouting>

Priority-Based Queuing Aspect

For request/reply type interactions, it could work similarly. It would allow x un-responsed requests to be outstanding.

This would work for some course grain priority of messages. This could control creation of new processes based on priority. But once the business process is created it would not be able to control putting one business process ahead of the other.

The configuration for such a priority-based queuing advice would be based on the message content where the XPath expression evaluates to a certain value or a range of values.

Messages that pass through such a priority-based queuing aspect engine would be resequenced and queued based on the XPath rules defined.

Security Aspect