Index Changes
This is version 61. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Aspect-Orientation for Mashups


Modularity and Encapsulation have always been cornerstones of good software engineering. Modularizing concerns is an important way to ensure that there is very little overlap in functionality between software services. Concerns that defy encapsulation are termed Cross-cutting concerns. Cross-cutting concerns make a clear separation of concerns difficult to achieve since they may cut across many modules within a software application. Some examples of such cross-cutting concerns are logging which cross-cuts all logged classes and operations, or caching which cross-cuts all cached objects, or alerting, or message tracking, or auto-reconnect, or queuing, et aliae.

Aspects help to encapsulate cross-cutting expressions in one place. By applying an Advice, at various points in an application called Join-Points, Aspects can alter the behavior of the non-aspect parts of a software application.

The Java Business Integration (JBI) specification, JSR-208, provides a loosely coupled integration model for distributed services within a Service-Oriented Architecture (SOA). The architecture allows dynamic deployment of JBI components and JBI service assemblies that can be used as Aspect and Advice mechanisms to alter the behavior of other services. Once these Aspect and Advice mechanisms are "plugged" in on-the-fly between a Consuming Service and a Provisioning Service through a Service Facade, the architecture provides a mechanism to dynamically define, verify, audit, track, enable, and enforce these cross-cutting concerns.

Also see:

Table of Contents

Aspect Patterns


There are two types of aspect patterns that are addressed:
  1. Facade Pattern
  2. Aspect-Weaving Pattern

Facade pattern

The Facade aspect pattern allows the user to apply a chain of aspects that serve as a service façade to a deployed provisioning service. This pattern solves the Network Composition problem. The only artifacts that will be required to create such a fronting service would be the client-facing WSDLs and XSDs of the Provisioning service. The user will be allowed to specify the order in which the aspect chain is applied. The figure below depicts a typical aspect chain that forms the gateway that now sits between the client and the Provisioning Service.

Multiple such configurations can be deployed so based on the façade URL that the client uses, different sets of advices are applied based on the aspect group configuration dynamically at runtime.

Aspect weaving pattern

The Aspect weaving pattern allows the user to apply weave an existing application with chains of aspects between services within a Composite Application. This pattern addresses the code-composition problem. To inject aspect-weaving into a composite application, the original composite application artifact will be required. The user will be allowed to specify the order in which the aspect chain is applied. The figure below depicts a typical aspect chain created using the aspect-weaving pattern.

Multiple such configurations can be deployed so based on the façade URL that the client uses, different sets of advices are applied based on the aspect group configuration dynamically at runtime.

Aspect Weaving Message Exchange Patterns


To facilitate injection of aspect advices to a composite application, we will extend the JBI JSR-208 Message Exchange patterns and add a couple of new message exchange patterns based on the pre-existing request/reply and one-way patterns. They are:

The Filter Request/Reply Message Exchange Pattern

The Filter One-Way Message Exchange Pattern

Aspect Map Connection Weaving


The aspect map determines how service connections are generated for the aspect unit. Specifically the <consumes/> and <provides/> endpoint information is generated from the aspect map that is created as part of the aspect service unit.

The aspect map schema is as detailed below:

&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            targetNamespace="http://xml.sun.jbi.aspects/schema/AspectMap"
            xmlns:tns="http://xml.sun.jbi.aspects/schema/AspectMap"
            elementFormDefault="qualified"&gt;
    
    &lt;!-- Aspect Map Element --&gt;
    &lt;xsd:element name="aspectmap" type="tns:aspectmapType"/&gt;
    
    &lt;!-- Aspect Map Type --&gt;
    &lt;xsd:complexType name="aspectmapType"&gt;
        &lt;xsd:sequence&gt;
            &lt;xsd:element type="tns:aspectType" name="aspect" minOccurs="0" maxOccurs="unbounded"&gt;
                &lt;xsd:annotation&gt;
                    &lt;xsd:documentation&gt;The aspect map&lt;/xsd:documentation&gt;
                &lt;/xsd:annotation&gt;
            &lt;/xsd:element&gt;
        &lt;/xsd:sequence&gt;
    &lt;/xsd:complexType&gt;
    
    &lt;!-- Aspect Type --&gt;
    &lt;xsd:complexType name="aspectType" mixed="true"&gt;
        &lt;xsd:sequence&gt;
            &lt;xsd:element type="tns:inputType" name="input"/&gt;
            &lt;xsd:element type="tns:outputType" name="output" minOccurs="0" maxOccurs="unbounded"/&gt;
            &lt;xsd:element type="tns:adviceType" name="advice" minOccurs="0" maxOccurs="unbounded"/&gt;
        &lt;/xsd:sequence&gt;
        &lt;xsd:attribute type="tns:ExchangeSimpleType" name="exchangeType" use="required"/&gt;
        &lt;xsd:attribute type="xsd:string" name="ID" use="required"/&gt;
    &lt;/xsd:complexType&gt;
    
    &lt;!-- Exchange Simple Type --&gt;
    &lt;xsd:simpleType name="ExchangeSimpleType"&gt;
        &lt;xsd:restriction base="xsd:string"&gt;
            &lt;xsd:enumeration value="filterRequestReply"/&gt;
            &lt;xsd:enumeration value="filterOneWay"/&gt;
            &lt;xsd:enumeration value="requestReply"/&gt;
        &lt;/xsd:restriction&gt;
    &lt;/xsd:simpleType&gt;  
    
    &lt;!-- Input Type --&gt;
    &lt;xsd:complexType name="inputType"&gt;
        &lt;xsd:simpleContent&gt;
            &lt;xsd:extension base="xsd:string"&gt;
                &lt;xsd:attribute type="xsd:string" name="partnerLink" use="optional"/&gt;
                &lt;xsd:attribute type="xsd:string" name="roleName" use="optional"/&gt;
                &lt;xsd:attribute type="xsd:string" name="portType" use="required"/&gt;
                &lt;xsd:attribute type="xsd:string" name="operation" use="required"/&gt;
                &lt;xsd:attribute type="xsd:string" name="messageType" use="required"/&gt;
                &lt;xsd:attribute type="xsd:string" name="file" use="required"/&gt;
                &lt;xsd:attribute type="xsd:string" name="transformJBI" use="optional"/&gt;
            &lt;/xsd:extension&gt;
        &lt;/xsd:simpleContent&gt;
    &lt;/xsd:complexType&gt;
    
    &lt;!-- Output Type --&gt;
    &lt;xsd:complexType name="outputType"&gt;
        &lt;xsd:simpleContent&gt;
            &lt;xsd:extension base="xsd:string"&gt;
                &lt;xsd:attribute type="xsd:string" name="ID" use="required"/&gt;
                &lt;xsd:attribute type="xsd:string" name="serviceName" use="optional"/&gt;
                &lt;xsd:attribute type="xsd:string" name="portName" use="optional"/&gt;
                &lt;xsd:attribute type="xsd:string" name="portType" use="required"/&gt;
                &lt;xsd:attribute type="xsd:string" name="operation" use="required"/&gt;
                &lt;xsd:attribute type="xsd:string" name="messageType" use="optional"/&gt;
                &lt;xsd:attribute type="xsd:string" name="file" use="optional"/&gt;
                &lt;xsd:attribute type="xsd:string" name="transformJBI" use="optional"/&gt;
                &lt;xsd:attribute type="xsd:string" name="partnerLink" use="optional"/&gt;
                &lt;xsd:attribute type="xsd:string" name="roleName" use="optional"/&gt;
            &lt;/xsd:extension&gt;
        &lt;/xsd:simpleContent&gt;
    &lt;/xsd:complexType&gt;
    
    &lt;!-- Advice Type --&gt;
    &lt;xsd:complexType name="adviceType"&gt;
        &lt;xsd:simpleContent&gt;
            &lt;xsd:extension base="xsd:string"&gt;
                &lt;xsd:attribute type="xsd:string" name="type" use="optional"/&gt;
                &lt;xsd:attribute type="xsd:string" name="configurationFile" use="optional"/&gt;
                &lt;xsd:attribute type="xsd:string" name="order" use="optional"/&gt;
            &lt;/xsd:extension&gt;
        &lt;/xsd:simpleContent&gt;
    &lt;/xsd:complexType&gt;
    
&lt;/xsd:schema&gt;


The <provides/> section of the jbi.xml for the service unit is derived from the <input/> node contents. The <partnerLinkName/> and <roleName/> are used to determine the provisioning endpoints for the Aspect Service unit. So for each <input/> node available in the aspectmap.xml, a <provides/> service endpoint will be registered with the NMR.

The <consumes/> section of the jbi.xml for the service unit is derived from the <output/> node contents of the aspectmap. The {<partnerLinkName/>, <roleName/>} combination, or the {<serviceName/>,{portName/ combination is used to determine the consuming endpoints for the Aspect Service unit. So for each <output/> node available in the aspectmap.xml, a <consumes/> service endpoint will be registered with the NMR.

A typical aspectmap contains one or more <aspect/> nodes. Based on the exchangeType attribute of each of those <aspect/> nodes, each aspectType contains an <input/> node, zero or more <output/> nodes, and zero or more <advice/> nodes.

The exchangeType represents the type of message exchange that is taking place, and can have three enumerated values. They are:

  • filterRequestReply
  • filterOneWay
  • requestReply

filterRequestReply

The filterRequestReply, represents a Filter Request/Reply message exchange pattern where the request/reply messages passing through the system are forced to go through the aspect filter. This allows the aspect engine to work on the request message before sending it to the provisioning service and then work on the reply before it reaches the intended consumer of the message. So if the exchangeType is of this type, the <aspect/> node will contain an <input/> node representing the provisioning service endpoint that the aspect unit exposes, one or more <output/> nodes representing the service endpoints that the aspect unit consumes, and one or more <advice/> nodes representing the advices that have to be applied to the request/response message.

filterOneWay

The filterOneWay, represents the Filter One-Way message exchange pattern where the one-way messages passing through the system are forced to go through the aspect filter. This allows the aspect engine to work on the one-way message before it reaches the intended provisioning service. So if the exchangeType is of this type, the <aspect/> node will contain an <input/> node representing the provisioning service endpoint that the aspect unit exposes, one or more <output/> nodes representing the service endpoints that the aspect unit consumes, and one or more <advice/> nodes representing the advices that have to be applied to the one-way message.

requestReply

The requestReply, represents the regular Request/Reply pattern where an external service is invoking the aspect unit to perform some work directly instead of it acting as a filter to any other provisioning service. So if the exchangeType is of this type, the <aspect/> node will contain an <input/> node representing the provisioning service endpoint that the aspect unit exposes, zero <output/> nodes and zero <advice/> nodes.

The <input/> node

The <input/> node determines the <provides/> endpoints that are exposed by the aspect service unit to the external client through the Service Façade. There can be only one input node inside each <aspect/> node and it is required node. The attributes that are part of this node are:
  • partnerLink: This comes from the partnerLink associated with the WSDL exposed by this service unit
  • roleName: This comes from the roleName associated with the WSDL exposed by this servce unit.
  • portType: This comes from the WSDL portType
  • operation: This denotes the operation from the WSDL that is being exposed by this service endpoint.
  • messageType: The messageType associated with the operation that is exposed.
  • file: Points to the XML StyleSheet that contains the transformations if any that have to be applied to the input message before sending it off to the remote provisioning service, probably transform namespaces, etc.
  • tranformJBI: It is a Boolean field with either a true or false value, determining if the transformation specified in the file attribute earlier has to be applied to the whole JBI Normalized Message or to its parts thereof.

The <output/> node

The <output/> node determines the <consumes/> endpoints that are exposed by this aspect service unit which consumes services provided by other provisioning services. There can be zero or more output nodes inside each <aspect/> node. The output node is only required in the case if the value of the exchangeType attribute on the <aspect/> node is either a filterRequestReply or a filterOneWay message exchange pattern. It is not required if the exchangeType is a requestReply exchange pattern. Moreover, if the pattern is a Facade Pattern, the serviceName and portName attributes replace the partnerLink and roleName attributes. The attributes that are part of this node are:
  • ID: Uniquely identifies this service endpoint within an <aspect/> node.
  • partnerLink: This comes from the partnerLink associated with the WSDL exposed by the provisioning service. This attribute only appears in the output node if it is an aspect-weaving pattern. For the Facade Pattern, this attribute is replaced by the serviceName attribute.
  • roleName: This comes from the roleName associated with the WSDL exposed by the provisioning service. This attribute only appears in the output node if it is an aspect-weaving pattern. For the Facade Pattern, this attribute is replaced by the portName attribute.
  • serviceName: This comes from the <service/> name attribute associated with the WSDL exposed by the provisioning service. This attribute only appears in the output node if it is a Facade Pattern. For the aspect-weaving pattern, this attribute is replaced by the partnerLink attribute.
  • portName: This comes from the <port/> name attribute associated with the WSDL exposed by the provisioning service. This attribute only appears in the output node if it is a Facade Pattern. For the aspect-weaving pattern, this attribute is replaced by the roleName attribute.
  • portType: This comes from the WSDL portType of the provisioning service
  • operation: This denotes the operation from the WSDL that is being exposed by the provisioning service
  • messageType: The messageType associated with the operation that is exposed by the provisioning service
  • file: Points to the XML StyleSheet that contains the transformations if any that have to be applied to the output message before sending it off to the client from the aspect service unit, probably transform namespaces, etc.
  • tranformJBI: It is a Boolean field with either a true or false value, determining if the transformation specified in the file attribute earlier has to be applied to the whole JBI Normalized Message or to its parts thereof.

The <advice/> node

The <advice/> node is used to list the different advices that have to be applied to messages that are received through that service endpoint. There may be one or more <advice/> nodes present in the <aspect/> node each specifying an advice. The attributes of the advice node are:
  • type: The type attribute determines the type of advice that is being applied. The values can be caching, logging, throttling, etc.
  • configurationFile: The configurationFile attribute specifies the file in the service unit that contains the unit configuration for the advice.
  • order: The order attribute specifies the order in which the advice has to be applied to the message as it flows through the aspect engine.

&lt;aspactmap&gt;
    &lt;aspect exchangeType = "filterRequestReply" ID=”1”&gt;
            &lt;input  partnerLink="{foo}pl1"       
                    roleName="server"            
                    portType="portType"          
                    operation="operation"
                    messageType="replyMessageType"
                    file="input.xsl"               
                    transformJBI="false" /&gt;      
            &lt;output ID=”1”
                    serviceName="{bar}pl2"       
                    portName="client"            
                    portType="outPortType"       
                    operation="outOp"
                    messageType="replyMessageType"
                    file="output.xsl"              
                    transformJBI="false" /&gt;*
            &lt;advice type="queuing" 
                    configurationFile="cache.xml" 
                    order="1"/&gt;
    &lt;/aspect&gt;

    &lt;aspect exchangeType = "filterOneWay" ID=”2”&gt;
            &lt;input  partnerLink="{foo}pl1"       
                    roleName="server"            
                    portType="portType"          
                    operation="operation"
                    messageType="replyMessageType"
                    file="input.xsl"               
                    transformJBI="false" /&gt;      
            &lt;output ID=”1”
                    partnerLink="{bar}pl2"       
                    roleName="client"            
                    portType="outPortType"       
                    operation="outOp" /&gt;*
            &lt;advice type="queuing" 
                    configurationFile="cache.xml" 
                    order="1"/&gt;
            &lt;advice type="throttling" 
                    configurationFile="throttling.xml" 
                    order="2"/&gt;
            &lt;advice type="logging" 
                    configurationFile="logging.xml" 
                    order="3"/&gt;
            &lt;advice type="cache" 
                    configurationFile="cache.xml" 
                    order="4"/&gt;
    &lt;/aspect&gt;

    &lt;aspect exchangeType = "requestReplyService" ID=”3”&gt;
            &lt;input  partnerLink="{foo}pl0"       
                    roleName="server"            
                    portType="portType"          
                    operation="operation"
                    messageType="replyMessageType"
                    file="input.xsl"               
                    transformJBI="false" /&gt;
            &lt;advice type="tracking" 
                    configurationFile="tracking.xml" 
                    order="1"/&gt;
    &lt;/aspect&gt;
&lt;/aspactmap&gt;

Bindings

Right now you can configure the service and facade to be http. We should be able to support all the BCs. For example, a jms service could be facaded by an http service address. Or a file service could be facaded by a jms service address. The AspectsUI should allow setting the service. One-Way and Request-Reply.

Aspects


Some of the aspects are:
  1. Cache Aspect
  2. Throttling (a.k.a. Choking) Aspect
  3. Retry (a.k.a. Auto-Reconnect) Aspect
  4. Logging Aspect
  5. Lease Management Aspect
  6. Message Filter Aspect
  7. Content Filter Aspect
  8. Queuing Aspect
  9. Validator Aspect
  10. Splitter Aspect
  11. Aggregator Aspect
  12. Scatter-Gather Aspect
  13. Resequencer Aspect
  14. Chargeback Aspect
  15. Monitoring Aspect
  16. Time to Recover Aspect
  17. Prioritization Aspect
  18. Regulatory Compliance Aspect
  19. Record/Replay Aspect
  20. Simulator Aspect
  21. Message Tracking Aspect
  22. Catch-Edit-Retry (a.k.a. Manual Recovery) Aspect
  23. Audit Trail Aspect
  24. Tee Aspect
  25. Content-Based Routing Aspect
  26. Priority-Based Queuing Aspect
  27. Security Aspect

Cache Aspect

This would save the request and response and then resend if seen again. We need a way to select which element is the key. Also need a Time To Live configuration property. request/reply only.

There are a couple of patterns that the Cache aspect should support for starters:

  1. Write-Through Cache (a.k.a. Transparent Cache) pattern
  2. Cache-Aside pattern

Write-Through Cache (a.k.a. Transparent Cache) pattern

This pattern ensures the Cache is placed between the client and the service that is being invoked. This makes sure all messages flowing between the client and the service provider flows through the cache.

This is the default Cache pattern that we will use. Composite Apps requiring use of this aspect will have to employ the Filter Request/Reply exchange pattern.

In a request/reply message exchange, the request message from the client is sent to the service with the Cache in the middle. The reply message to the client is cached. Subsequently, when the same request message is sent out by the client, the reply message is provided from the Cache instead of having to invoke the actual service.

Cache-Aside pattern

This pattern allows the Composite App developer to manage caching of certain key elements and their values contained within the messages that flow through the write-through cache and use it in building features into his composite app. Composite Apps requiring use of this aspect will have to employ the regular Request/Reply exchange pattern on the cache and make use of its get/put operations.

One scenario the user can use the Cache Aside pattern in his composite app is as follows:

  1. Check the cache before invoking a service by providing a list of XPath keyExpression(s).
  2. Get the value(s) directly from the cache and use them in the composite app.
  3. Optionally, if the values are not cached, invoke the actual service, and optionally, put the key/values into the cache.
  4. Optionally, evict or optionally, update the cache with new values.

Cache Aside Management configuration

The above mentioned scenarios would require that the user provide a list of XPath keyExpression(s) (present in the message) to cache. This can be provided through the Web Console which would have the ability to manage the key expressions. Typical operations include:
  • Get all Key Expressions to Cache
  • Edit Key Expression
  • Remove Key Expression
  • Edit value.
For example,

Cache Management Configuration

The Cache implementation uses a Linked HashMap. By over-riding the boolean removeEldestEntry(Map.Entry eldest) method, a First-In-First-Out cache can be created. This will ensure that if the ‘number of entries’ exceed the set limit; the oldest entry will be removed, which gives us automatic cache management. However, the cache can also be configured to be a Generic Cache in which case, Cache management will have to be provided by the Web Console. Typical management operations include:
  • Get/Set Caching Strategy
  • Get/Set Maximum Entries to Cache
  • Get Keys
  • Edit value
  • Time to Live value

Throttling (a.k.a. Choking) Aspect

Can be defined on a user by user bases. Can also for example, jwaldorf can process 100 msgs/sec. GRaj can process 1000 msgs/sec. One-Way and Request-Reply.

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

  • When to delay access
  • When to refuse access
This pattern ensures the Throttling 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 Throttling engine core.

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
For example,
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;throttling&gt;
    &lt;config&gt;
        &lt;!-- Messages per second --&gt;  
        &lt;property name="rate" value="10" /&gt;
        &lt;!-- Maximum number of queue entries --&gt;  
        &lt;property name="queue-length" value="1000" /&gt;        
    &lt;/config&gt;    
    &lt;ruleset name="mythrottling"&gt;
        &lt;rule name="myfirstrule"&gt;
            &lt;xpath keyExpression="/Employee/FirstName"/&gt;            
        &lt;/rule&gt;
    &lt;/ruleset&gt;
&lt;/throttling&gt;

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

This would try and reconnect to a service/endpoint for some number of tries before giving up and returning a fault. Request-Reply.

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
For example,
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;retry&gt;
    &lt;config&gt;
        &lt;!-- retry rate in msg / sec --&gt;
        &lt;property name="rate" value="10" /&gt;
        &lt;!-- timeout in millisecond --&gt;
        &lt;property name="timeout" value="1000" /&gt;
    &lt;/config&gt;
&lt;/retry&gt;

Logging Aspect

The Logging aspect can be used to control logging output. The logging Level objects are ordered and are specified by ordered integers. Enabling logging at a given level also enables logging at all higher levels.

The levels in descending order are:

  • SEVERE (highest value)
  • WARNING
  • INFO
  • CONFIG
  • FINE
  • FINER
  • FINEST (lowest value)
In addition there is a level OFF that can be used to turn off logging, and a level ALL that can be used to enable logging of all messages.

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
For example,
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;logging&gt;              
    &lt;config&gt;
        &lt;property name="level" value="INFO"/&gt;
        &lt;property name="rotation-policy" value="DAILY" /&gt;
        &lt;property name="log-file" value="C:\\temp\\loggingse.log" /&gt;
    &lt;/config&gt;
&lt;/logging&gt;

Lease Management Aspect

Can define length of time a particular user can access a resource. Should use user names and not explicit tokens. .One-Way and Request-Reply.

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

User can specify an xpath expression or set of them, that if true don't forward on the message. . One-Way and Request-Reply. If one-way drop message. If req/reply return fault.

Content Filter Aspect

This would go inside the message and strip off selected elements in the message. The gui could work by showing a list of all optional elements and attributes with a check box next to each. If the user selects the check box, then that element won't be propagated on. It will be removed from the message. . One-Way and Request-Reply.

Queuing Aspect

Works for one-way only. This would get the message and send it on to the destination. If within x seconds a done is not received the message would be saved to disk and after that a done would be sent back to the originator. When the done is finally received on the outbound side, we can then delete the message.

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
For example,
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;queuing&gt;
    &lt;config&gt;
        &lt;!-- Maximum number of queue entries --&gt;  
        &lt;property name="queue-length" value="1000" /&gt;
        &lt;!-- time specified in sec/ millisec--&gt;
        &lt;property name="timeout" value="1000" /&gt;
        &lt;property name="queue-type" value="normal / priority"&gt;
    &lt;/config&gt;
&lt;/queuing&gt;

Validator Aspect

This would allow the user to specify that hard validation rules would be used to make sure the message is valid. This could include XML Schema, and XML Schematron rules. Works for both One-Way and Request-Reply.

Splitter Aspect

This would only work for messages that have one part and that part repeats. If the inbound message had 150 elements at this level that repeated, then it would create 150 individual messages on the output side. One-Way only.

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

This would take and collect the above 150 messages and put them back into a single message. Would need some special message exchange property that splitter would populate and aggregator would read. The special property would indicate the group message id, the message sequence number, and the last message.

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

This would be used to take a request in, split that request into multiple requests. Then gather all responses and send back single response to original requestor. This would only work with request/reply operations.

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

This would be used to order messages. One-Way only. Security Aspect Add ability to configure the HTTP BC security settings from the AspectsUI. This would allow someone to indicate that a service is secure by http basic auth or http digest or add ssl or WS-Security Basic Profile or ... In addition you would be able to configure the users that can access this. Would require integration with Access Manager. One-Way and Request-Reply.

Chargeback Aspect

Keep track in a database that is user configurable each request and the user that made the request. . One-Way and Request-Reply.

Monitoring Aspect

Keep track of number of messages, number of errors, response time, message throughput, ... for all services. This would be a basic fact table for all requests and responses that could be analytically processed as a cube. . One-Way and Request-Reply.

Time to Recover Aspect

The user would be able to specify that a service endpoint is out and what the response message should be. For example, the user would log into a simple web gui and set the mbean for this aspect for this service endpoint to respond with "service foo is unavailable. it is undergoing maintenance and will be back on line at 3:30 pm pst 3/30/2007". . One-Way and Request-Reply.

Prioritization Aspect

Based on users or message content decide what messages get processed before others. For example, prioritize messages based on purchase price. IE the largest orders get process first. The user would configure this by selecting the element in the message with an xpath expression. Could also be based on users. . One-Way and Request-Reply.

Regulatory Compliance Aspect

??

Record/Replay Aspect

This would allow messages that pass through it to be recorded and then later played back. Would allow someone to capture the traffic and then replay that without the external applications being involved. Help for problem reproduction. . One-Way and Request-Reply.

Simulator Aspect

This would emulate a service by providing random response generation based on the xml schema for the response message. request/reply only.

Message Tracking Aspect

Keep track of messages and their corresponding messages. This would allow the user to specify which message element represents the correlation key. Then the message and key would be saved to a database table and someone could then track all messages associated with that key.

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.
For example,
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;message-tracking&gt;
    &lt;config&gt;
        &lt;property name="mode" value="database / file" /&gt;
        &lt;!--
        config can have more params defining the database/file locations.
        --&gt;
    &lt;/config&gt;
    &lt;ruleset name="myMessageTracking"&gt;
        &lt;rule name="myfirstrule"&gt;
            &lt;xpath keyExpression="/Employee/FirstName"/&gt;            
        &lt;/rule&gt;
    &lt;/ruleset&gt;
&lt;/message-tracking&gt;

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

When a failure occurs, this aspect stores the request in a database for future review. At a later point in time, an administrator can come in, inspect the message, and retry sending the message.

Audit Trail Aspect

Keeps a track of users that accessed the system. The username is obtained from the Normalized Message Header property and the information is tracked in a database.

Tee Aspect

In some scenarios, you want to redirect the same message to two different components. The Tee Aspect Service Engine core introduces a T-junction that facilitates message redirection to two different components at the same time.

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
For example,
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;tee&gt;
    &lt;config /&gt;
    &lt;ruleset name="mytee" &gt;
        &lt;rule name="myfirstrule"&gt;
            &lt;xpath keyExpression="/Employee/FirstName"/&gt;            
            &lt;destination id="1" /&gt;
            &lt;destination id="2" /&gt;
        &lt;/rule&gt;
    &lt;/ruleset&gt;
&lt;/tee&gt;

Content-Based Routing Aspect

The Content-Based Routing Aspect is used to forward a message to the correct destination based on the content of the message payload. For example, a typical scenario for this may be that on receipt of a purchase order, the message needs to be routed to the appropriate order management system, based on the type of item that has been ordered (which will be obtained by parsing an XPath expression in the message payload). The routing will happen based on a configurable Rule Set which can be configured from the Web Console.

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,

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

Priority-Based Queuing Aspect

For one way messages, the Priority-Based Queuing Aspect would prioritize new higher priority messages ahead of older lower priority messages. It would have rules for allowing only x un-acknowledged messages to be outstanding and would queue up the rest.

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

Add ability to configure the HTTP BC security settings from the AspectsUI. This would allow someone to indicate that a service is secure by http basic auth or http digest or add ssl or WS-Security Basic Profile or ... In addition you would be able to configure the users that can access this. Would require integration with Access Manager. One-Way and Request-Reply.

The Aspect Service Engine




The Aspect Service Engine is a JSR-208 Engine Component Container that provides an implementation framework where multiple aspects are implemented.



Project Plan

Aspect Demo

Configure and Use Aspect Service Engine



Table of Contents


About Aspect Service Engine

Detailed Definition of Aspect SE can be found here

Aspects Supported

  1. Cache Aspect
  2. Throttling (a.k.a. Choking) Aspect
  3. Retry (a.k.a. Auto-Reconnect) Aspect

Aspects On the Way ...

  1. Logging Aspect
  2. Tee Aspect

Complete List of Planned Aspects

Aspect SE Editor

Aspect Service Engine draws its run-time configuration from AspectMap.xml . The aspect map is created as part of the service unit generation. It contains following configurable information that determines how service connections are generated for the aspect unit :
  1. Defines Provides end point configuration with its partnerlink, role name, port type, message type and operation name.
  2. Defines Consumes end point configuration with its partnerlink, role name, port type, message type and operation name. Some of the Aspects can potentially invoke Multiple services (e.g. Tee, Content Based Routing) for which aspect map can define variors consume end points.
  3. Defines the list of advice and the order in which these would be applied between the provides and consumed end points.
  4. Defines the configuration and rule set for each individual advice in the advice chain in the aspect map.
  5. Defines the Exchange Types (Filter One Way/Filter Rqst-Resp MEPs) as applicable to the advice types.

Further details about the Aspect Map XML can be found here :: Aspect Map Details

Aspect Editor facilitates creation of AspectMap.xml file for the Aspect Service Engine. Aspect Editor is available as a plug-in with the Netbeans 6.0. Netbeans 6.0 also provides plug-in for Aspect SE Project system which is used for building Aspect Service Unit.

Working with the Aspect Editor is simple. The pictorial guide below shows how aspect map can be build from the scratch which supports injecting 3 advices in the order specified:
Aspect SE(Provides)End Point --> Logging --> Cacheing --> Throttling --> Aspect SE (Consumes) End Point

Step 1. Creating the Aspect Project Module (Aspect Service Unit Artifacts)

  1. From Netbeans 6.0, go to file and select New Project
  2. On the Project wizard, select SOA followed by Aspect Module in the Projects list.
  3. Select Next, select the project name and location on the file system and Finish. New Aspect SE Module will be created with the Blank AspectMap.xml file.

Step 2. Adding Advice

  1. Double click on the aspectmap.xml as shown in the project tree to open up the Aspect Editor (Design/Source view)
  2. Use Source/Design view buttons on the top of the editor to toggle between the Aspect Editor views. Select the Design view at the moment.
  3. On the Editor pane, right click to see the options available on the editor. Select Add Advice to add a new advice into the Aspect SE. Advices can be selected from the list available on selecting this option.

Step 3. Chaining the Advice

  1. Make sure to take a note of Insert After drop down list which allows the user to chain the advices in the right order. This, however, can also be organised later using the option, Edit Advice Chain

Step 4. Verify the change in AspectMap.xml using Source View

  1. AspectMap.xml is built in the background as the advices are added from the design view. This can be seen and verified using Source view of the Aspect Map Editor.

* Footnote: Aspect Editor is still evolving and imminent changes in its functinality will be updated here whenever applicable.

Running and Deplying Aspect SE

Refer to some of our Quality Demos to learn about Building, Injecting and Deplying Aspects from Aspect SE between BPEL and external web services.


Access Count: 64
StatCounter Access Count :

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This particular version was published on 14-Jun-07 11:42 AM, -0700 by Gopalan Suresh Raj